Лекции по управлению программными проектами

2009 г.

Лекции по управлению программными проектами

Модели процесса разработки ПО

Модели (или, как еще любят говорить, методологии) процессов разработки ПО принято классифицировать по «весу» — количеству формализованных процессов (большинство процессов или только основные) и детальности их регламентации. Чем больше процессов документировано, чем более детально они описаны, тем больше «вес» модели.

Наиболее распространенные современные модели процесса разработки ПО представлены на Рисунке 3.

Рисунок 3 Различные модели процесса разработки ПО и их распределение по «весу»

ГОСТы

ГОСТ 19 «Единая система программной документации» и ГОСТ 34 «Стандарты на разработку и сопровождение автоматизированных систем» ориентированы на последовательный подход к разработке ПО. Разработка в соответствии с этими стандартами проводится по этапам, каждый из которых предполагает выполнение строго определенных работ, и завершается выпуском достаточно большого числа весьма формализованных и обширных документов. Таким образом, строгое следование этим гостам не только приводит к водопадному подходу, но и требует очень высокой степени формализованности разработки. На основе этих стандартов разрабатываются программные системы по госзаказам в России.

SW-CMM

В середине 80-х годов минувшего столетия Министерство обороны США крепко задумалось о том, как выбирать разработчиков ПО при реализации крупномасштабных программных проектов. По заказу военных Институт программной инженерии, входящий в состав Университета Карнеги-Меллона, разработал SW-CMM, Capability Maturity Model for Software [9] в качестве эталонной модели организации разработки программного обеспечения.

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

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

Документация с полным описанием SW-CMM занимает около 500 страниц и определяет набор из 312 требований, которым должна соответствовать организация, если она планирует аттестоваться по этому стандарту на 5-ый уровень зрелости.

RUP

Унифицированный процесс (Rational Unified Process, RUP) [10] был разработан Филиппом Крачтеном (Philippe Kruchten), Иваром Якобсоном (Ivar Jacobson) и другими сотрудниками компании "Rational Software" в качестве дополнения к языку моделирования UML. Модель RUP описывает абстрактный общий процесс, на основе которого организация или проектная команда должна создать конкретный специализированный процесс, ориентированный на ее потребности. Именно эта черта RUP вызывает основную критику — поскольку он может быть чем угодно, его нельзя считать ничем определенным. В результате такого общего построения RUP можно использовать и как основу для самого что ни на есть традиционного водопадного стиля разработки, так и в качестве гибкого процесса.

MSF

Microsoft Solutions Framework (MSF) [11] — это гибкая и достаточно легковесная модель, построенная на основе итеративной разработки. Привлекательной особенностью MSF является большое внимание к созданию эффективной и небюрократизированной проектной команды. Для достижения этой цели MSF предлагает достаточно нестандартные подходы к организационной структуре, распределению ответственности и принципам взаимодействия внутри команды.

PSP/TSP

Одна из последних разработок Института программной инженерии Personal Software Process / Team Software Process [12,13]. Personal Software Process определяет требования к компетенциям разработчика. Согласно этой модели каждый программист должен уметь:

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

Team Software Process делает ставку на самоуправляемые команды численностью 3-20 разработчиков. Команды должны:

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

Последовательное применение модели PSP/TSP позволяет сделать нормой в организации пятый уровень CMM.

Agile

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

Выбор модели процесса

Тяжелые и легкие модели производственного процесса имеют свои достоинства и свои недостатки (Таблица 1).

Таблица 1. Плюсы и минусы тяжелых и легких моделей процессов разработки ПО

Вес модели Плюсы Минусы

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

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

Те, кто пытается следовать описанным в книгах моделям, не анализируя их применимость в конкретной ситуации, показания и противопоказания, уподобляются последователям культа «Карго» — религии самолетопоклонников. В Меланезии верят, что западные товары (карго, англ. груз) созданы духами предков и предназначены для меланезийского народа. Считается, что белые люди нечестным путём получили контроль над этими предметами. В наиболее известных культах карго из кокосовых пальм и соломы строятся точные копии взлётно-посадочных полос, аэропортов и радиовышек. Члены культа строят их, веря в то, что эти постройки привлекут транспортные самолёты (которые считаются посланниками духов), заполненные грузом (карго). Верующие регулярно проводят строевые учения («муштру») и некое подобие военных маршей, используя ветки вместо винтовок и рисуя на теле ордена и надписи «USA». Все это для того чтобы снова с неба спустились самолеты и этих предметов стало больше.

Алистер Коуберн, один из авторов «Манифеста гибкой разработки ПО» [14] проанализировал очень разные программные проекты, которые выполнялись по разным моделям от совершенно облегченных и «гибких» до тяжелых (СММ-5) за последние 20 лет [15, 16]. Он не обнаружил корреляции между успехом или провалом проектов и моделями процесса разработки, которые применялись в проектах. Отсюда он сделал вывод о том, что эффективность разработки ПО не зависит от модели процесса, а также о том, что :

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

Это означает, что не существует единственного правильного процесса разработки ПО, в каждом новом проекте процесс должен определяться каждый раз заново, в зависимости от проекта, продукта и персонала, в соответствие с «Законом 4-х П» (Рисунок 4). Совершенно разные процессы должны применяться в проектах, в которых участвуют 5 человек, и в проектах, в которых участвуют 500 человек. Если продуктом проекта является критическое ПО, например, система управления атомной электростанцией, то процесс разработки должен сильно отличаться от разработки, например, сайта «отдохни.ру». И, наконец, по-разному следует организовывать процесс разработки в команде вчерашних студентов и в команде состоявшихся профессионалов.

Рисунок 4. «Закон 4-х П». Процесс в проекте должен определяться в зависимости от проекта, продукта и персонала

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

Что надо делать для успеха программного проекта

Стив Макконнелл в своей книге [17] приводит тест программного проекта на выживание. Этот чек-лист из 33-х пунктов, который я считаю необходимым процитировать с небольшими корректировками. Руководитель программного проекта должен его периодически использовать для внутреннего аудита своих процессов.

Чтобы программный проект стал успешным, необходимо:

Четко ставить цели.
Определять способ достижения целей.
Контролировать и управлять реализацией.
Анализировать угрозы и противодействовать им.
Создавать команду.

Ставим цели
1.1. Концепция определяет ясные недвусмысленные цели.
1.2. Все члены команды считают концепцию реалистичной.
1.3. У проекта имеется обоснование экономической эффективности.
1.4. Разработан прототип пользовательского интерфейса.
1.5. Разработана спецификация целевых функций программного продукта.
1.6. С конечными пользователями продукта налажена двухсторонняя связь
Определяем способ достижения целей
2.1. Имеется детальный письменный план разработки продукта.
2.2. В список задач проекта включены «второстепенные» задачи (управление конфигурациями, конвертация данных, интеграция с другими системами).
2.3. После каждой фазы проекта обновляется расписание и бюджет.
2.4. Архитектура и проектные решения документированы.
2.5. Имеется план обеспечения качества, определяющий тестирование и рецензирование.
2.6. Определен план многоэтапной поставки продукта.
2.7. В плане учтены обучение, выходные, отпуска, больничные.
2.8. План проекта и расписание одобрен всеми участниками команды.
Контролируем и управляем реализацией
3.1. У проекта есть куратор. Это такой топ-менеджер исполняющей компании, который лично заинтересован в успехе данного проекта.
3.2. У проекта есть менеджер, причем только один!
3.3. В плане проекта определены «бинарные» контрольные точки.
3.4. Все заинтересованные стороны могут получить необходимую информацию о ходе проекта.
3.5. Между руководством и разработчиками установлены доверительные отношения.
3.6. Установлена процедура управления изменениями в проекте.
3.7. Определены лица, ответственные за решение о принятии изменений в проекте.
3.8. План, расписание и статусная информация по проекту доступна каждому участнику.
3.9. Код системы проходит автоматическое рецензирование.
3.10. Применяется система управления дефектами.
Анализируем угрозы
4.1. Имеется список рисков проекта. Осуществляется его регулярный анализ и обновление.
4.2. Руководитель проекта отслеживает возникновение новых рисков.
4.3. Для каждого подрядчика определено лицо, ответственное за работу с ним.
Работаем над созданием команды
5.1. Опыт команды достаточен для выполнения проекта.
5.2. У команды достаточная компетенция в прикладной области.
5.3. В проекте имеется технический лидер.
5.4. Численность персонала достаточна.
5.5. У команды имеется достаточная сплоченность.
5.6. Все участники привержены проекту.

Оценка и интерпретация теста

Оценка: сумма баллов, каждый пункт оценивается от 0 до 3:

0 — даже не слышали об этом;
1 — слышали, но пока не применяем;
2 — применяется частично;
3 — применяется в полной мере.

Поправочные коэффициенты:

для малых проектов (до 5 человек) — 1.5;
для средних (от 5 до 20 человек) — 1.25.

Результат:

<40 — завершение проекта сомнительно.
40-59 — средний результат. В ходе проекта следует ожидать серьезные проблемы.
60-79 — хороший результат. Проект, скорее всего, будет успешным.
80-89 — отличный результат. Вероятность успеха высока.
>90 — великолепный результат. 100% шансов на успех.

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

Выводы

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

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

Чтобы программный проект стал успешным, необходимо:

Четко ставить цели.
Определять способ достижения целей.
Контролировать и управлять реализацией.
Анализировать угрозы и противодействовать им.
Создавать команду.

Дополнительная литература и источники

IEEE Std 610.12-1990, IEEE Standard Glossary of Software Engineering Terminology.
IEEE Std 1074-1995, IEEE Standard for Developing Software Life Cycle Processes.
«Руководство к своду знаний по программной инженерии». The Guide to the Software Engineering Body of Knowledge, SWEBOK, IEEE Computer Society Professional Practices Committee, 2004.
David Rubinstein, «Standish Group Report: There's Less Development Chaos Today». 2007
Брукс Фредерик, «Мифический человеко-месяц, или Как создаются программные комплексы», Пер. с англ., СПб., Символ-Плюс, 1999.
«PMBOK. Руководство к Своду знаний по управлению проектами», 3-е изд., PMI, 2004.
Уолкер Ройс, «Адаптивный стиль управления программными проектами». Открытые системы. 2006. № 1.
Ершов А. П., «О человеческом и эстетическом факторе в программировании». Информатика и образование. 1993. № 6.
Paulk, Mark C., and others, Capability Maturity Model for Software, Version 1.1 (CMU/SEI-93-TR-24). Pittsburgh, Pa.: Software Engineering Institute, Carnegie Mellon University, 1993.
Филипп Крачтен, «Введение в Rational Unified Process», Вильямс, 2002 г.
«MSF, Microsoft, Microsoft Solutions Framework», Отдел MSF, Microsoft, 2002.
M. Pomeroy-Huff, J. Mullaney, R. Cannon, M. Sebern, «The Personal Software Process (PSP) Body of Knowledge», version 1.0, SPECIAL REPORT CMU/SEI, 2005
Watts S. Humphrey, «The Team Software Process (TSP)», Technical Report CMU/SEI, 2000
Kent Beck, and others, «Manifesto for Agile Software Development», 2001
А. Коуберн, «Люди как нелинейные и наиболее важные компоненты в создании программного обеспечения», Humans and Technology Technical Report, Oct.1999 (русский перевод — К.Максимов, А.Максимова)
А. Коуберн, «Каждому проекту своя методология», Humans and Technology Technical Report, TR 99.04, Oct.1999 (русский перевод — К.Максимов, А.Максимова).
С. Макконнелл, «Остаться в живых. Руководство для менеджеров программных проектов», «Питер», 2006.

Назад Содержание Вперёд