БИЗНЕС-БИБЛИОТЕКА
> Информационные технологии
> Управление проектами
Два основных типа моделей жизненного цикла в сфере высоких технологий
Рассел Арчибальд
Дата публикации: 17.01.2005
Источник: Российская Ассоциация Управления
Проектами "СОВНЕТ"
Как показано в Таблице, существуют два основных типа моделей
жизненного цикла для категории тех проектов, что мы называем
"высокотехнологичными". Это прогнозирующий и адаптивный типы. Ниже
приводятся примеры для проектов разработки информационных систем,
однако, сказанное может быть применено и к некоторым другим видам
высокотехнологичным проектам.
Прогнозирующие модели жизненного цикла
"ставят оптимизацию выше адаптивности" (Desaulniers and Anderson 2002). К этим моделям относятся:
- Водопад (известна также как "традиционная" или "сверху вниз"):
линейное упорядочивание фаз, которые могут быть строго
последовательными или в некоторой степени перекрываться, ни одна из фаз
обычно не повторяется.
- Прототипирование: разработка функциональных требований и топологическое проектирование осуществляются одновременно.
- Быстрая разработка приложения (Rapid Application Development,
RAD): основана на использовании эволюционирующего прототипа, который не
отбрасывается.
- Инкрементное построение: разбиение большого объема
проектно-конструкторских работ на последовательность более малых
составляющих частей.
- Спираль: повторение одного и того же набора фаз жизненного
цикла, таких как планирование, проектирование, построение и оценивание,
до тех пор, пока разработка продукта не будет завершена.
Адаптивные жизненные циклы
"принимают и схватывают изменения в ходе процесса разработки и
отвергают детальное планирование" (Desaulniers and Anderson, 2002). К
этим моделям относятся:
- Адаптивная разработка программного обеспечения (Adaptive Software
Development, ASD): определяемая миссией, основанная на компонентах,
подразумевает итеративные циклы и циклы с известной длительностью,
определяемые степенью риска, допускающая изменения.
- Экстремальное программирование (Extreme Programming, XP):
команды разработчиков, менеджеров и пользователей, программирование
выполняется парами, итеративный характер процесса, коллективное
владение кодами программ.
- SCRUM: подобен приведенным выше адаптивным жизненным циклам,
выполняется на итеративной основе, итерации носят название "спринтов",
имеют длительность порядка 30 дней (типовое значение); каждый "спринт"
должен дать на выходе определенную степень функциональности продукта;
активная роль руководства в течение всего жизненного цикла.
Модели скоростной разработки программного обеспечения
Эти адаптивные модели также носят название моделей "скоростного"
жизненного цикла (Bullock 2003). В 2001 году группой, состоявшей из 17
представителей пользователей этой адаптивной модели жизненного цикла
был выпущен "Манифест скоростной разработки программного обеспечения",
и эта инициатива получила широкое развитие в отрасли информационных
технологий. См. http://www.agilemanifesto.org/.
Влияние окружения проекта на модель жизненного цикла проекта
Разработка и адаптация модели жизненного цикла для каждой категории
или подкатегории проектов должна отражать важные характеристики
окружения проекта.
"Организационные характеристики, степень владения
технологией, которая будет использоваться, и обусловленноы конкуренцией
предпосылки к инициации проекта - это лишь некоторые факторы окружения,
которые могут меняться от проекта к проекту". (Desaulniers and Anderson
2002).
Категории проектов: модели жизненного цикла и ссылки
Категории проектов*
|
Модели жизненных циклов и
ссылки
|
Общие модели проектов: все (или многие) категории,
приведенные ниже
|
Belanger 1998, pp. 62-72. Модели: общая, водопада,
параллельная, эволюционирования.
Morris, 1994, pp. 245-248. Модели: стандартная, водопада,
циклическая, спиральная.
|
1. Аэрокосмические / оборонные проекты
1.1. Оборонные системы
1.2. Космос
1.3. Военные действия
|
DOD 2000: Модель государственных заказов.
NASA 2002: Process Based Mission Assurance (PBMA)
Program Life Cycle, 8 фаз: 1. Управление программой, 2. Разработка
концепции, 3. Приобретение, 4. Проектирование аппаратуры,
5. Проектирование программного обеспечения, 6. Производство,
7. Предварительная сборка (монтаж) и испытания, 8. Ввод в
эксплуатацию.
|
2. Проекты реорганизации бизнеса
2.1. Слияния/поглощения
2.2. Совершенствование процессов управления
2.3. Венчурные проекты
2.4. Реструктурирование организаций
2.5. Судопроизводство
|
См. общие модели, приведенные выше
|
3. Проекты в сфере коммуникационных систем
3.1. Сетевые коммуникационные системы
3.2. Коммутаторные коммуникационные системы
|
См. общие модели, приведенные выше
|
4. Крупные события
4.1. Международные события
4.2. Национальные события
|
См. общие модели, приведенные выше
|
5. Проекты в сфере капитального строительства
5.1. Вывод из эксплуатации
5.2. Разборка и снос
5.3. Обслуживание и модификация сооружений
5.4. Проектирование/поставки/строительство сооружений
|
См. общие модели, приведенные выше
|
6. Проекты информационных систем (разработки
программного обеспечения)
|
Desaulniers and Anderson 2002: Прогнозирующие
модели (водопада, прототипирования, RAD, инкрементного построения,
спиральная) и адаптивные модели (ASD, XP, SCRUM).
Whitten 1995, pp. 19-22. Code and Fix. Модели: водопада, инкрементная,
итеративная.
Muench 1994: Спиральная модель разработки программного обеспечения.
Lewin 2002, p. 47: V-образная модель разработки программного
обеспечения; p. 50: модель разработки информационных технологий
- "Формула".
Kezsbom and Edward 2001, p. 122: Усовершенствованная спиральная
модель процесса.
|
7. Проекты международного развития
7.1. Развития сельского хозяйства / сельских местностей
7.2. В сфере образования
7.3. В сфере здравоохранения
7.4. В сфере обеспечения питания
7.5. Демографические
7.6. Малые предприятия
7.7. Инфраструктура: энергетика (нефть, газ, уголь, производство
и распределение электроэнергии, промышленность, телекоммуникации,
транспорт, урбанизация, выработка воды, канализация, ирригация)
|
World Bank Institute 2002, Module 1.Проекты
в развивающихся странах, требующие участия большого количества
людей и выполнения большого количества процессов, финансируемые
Всемирным Банком, банками регионального развития, US AID,
UNIDO, другими агентствами ООН или правительств.
Проекты с большим объемом капитального строительства и строительных
работ - эти проекты отличны от категории 5, так как могут
включать - как часть проекта - создание организационной единицы
для обеспечения или поддержания функционирования сооружения,
и кредитные организации, устанавливающие свои требования в
части организации жизненного цикла проекта и ведения отчетности
|
8. Культурно-массовые и развлекательные проекты
8.1. Кино
8.2. Телевидение
8.3. Шоу
|
|
9. Проекты разработки продукта или услуги
9.1. Аппаратное обеспечение для информационных технологий
9.2. Промышленный продукт / процесс
9.3. Потребительский продукт / процесс
9.4. Фармацевтический продукт / процесс
9.5. Профессиональные услуги (в финансовой или иной сфере)
|
Cooper and Kleinschmidt 1993: Ступенчато-шлюзовая
модель процесса.
Kezsbom and Edward 2001, pp. 108: Ступенчато-шлюзовая модель
разработки продукта.
Thamhain 2000: Фазово-шлюзовая модель процесса Murphy 1989:
Фармацевтическая модель
|
10. НИОКР-проекты
10.1. Связанные с окружающей средой
10.2. Промышленные
10.3. Экономического развития
10.4. В сфере медицины
10.5. В сфере науки
|
Eskelin 2002, p. 46: Технические заказы: базовая
модель, фазовая модель, модель с несколькими решениями.
|
Таблица. Модели жизненного цикла проекта и ссылки: общие и применительно
к различным категориям проектов (Источник: Archibald 2003, pp. 45
- 46).
Управление проектами разработки программного обеспечения с использованием "Рационального Унифицированного Процесса" / RUP
RUP - это разработанная фирмой IBM и широко используемая модель
процесса, которая состоит из 6 наиболее хорошо зарекомендовавших себя
практических методик:
- Разрабатывать программное обеспечение итеративно
- Управлять требованиями
- Использовать архитектуры, основанные на компонентах
- Визуально моделировать программное обеспечение
- Непрерывно проверять качество программного обеспечения
- Контролировать изменения программного обеспечения
Wideman (2002) представляет подробный труд о методике RUP, который можно увидеть по адресу: www.maxwideman.com/papers/acquisition/intro.htm.
RUP - это процессно-ориентированный программный продукт, поддерживаемый
комплектом программных средств от фирмы IBM (на CD-ROM или через
интернет по адресу http://www.us.ibm.com/).
Улучшение процесса управления жизненным циклом проекта
После того, как жизненные циклы разработаны и задокументированы для
каждой категории или подкатегории проектов, становится возможно
определить и задокументировать систему управления жизненным циклом для
каждой из них. Только когда такая документация существует, система
может совершенствоваться систематическим, комплексным образом. Для того
чтобы сделать возможным подход к совершенствованию процессов управления
проектами, основанный на принципах (TQM), и избежать неоптимальных
фрагментарных попыток улучшений, рекомендуется использовать следующий
подход:
- Описать модель интегрированного процесса жизненного цикла: как было рассмотрено выше.
- Задокументировать получившуюся в результате систему управления жизненным циклом проекта (PLCMS) для каждой категории проектов в организации: также рассмотрено выше.
- Выполнять реинжиниринг интегрированного процесса
с целью применять наиболее подходящие методы реинжиниринга к PLCMS
каждой категории. Цель такого реинжиниринга состоит в следующем:
- Определять системные ограничения, разрывы и слабые места.
- Определять "замедлители", которые непреднамеренно препятствуют
процессу, и потенциальные ускорители, способные его ускорить. (Githens
2002).
- Соотносить нежелательные результаты проекта и их возможные причины с PLCMS везде, где это возможно.
- Выполнять перепроектирование PLCMS, начиная с наиболее
очевидных ограничений, разрывов и слабых мест, и документировать
результаты.
- Осуществлять улучшения.
- Получать требуемые согласия и проводить необходимые тесты или
анализ для подтверждения валидности и осуществимости предлагаемых
вариантов изменений системы.
- Планировать, утверждать и выполнять проекты внедрения улучшений PLCMS.
- Повторять шаги по мере необходимости до получения оптимальной работоспособной PLCMS.
Команда по внесению улучшений в PLCMS должна включать опытных
практиков из сотрудников организации, знакомых с существующими
процессами управления проектами.