|
Модели жизненного цикла высокотехнологичных проектов
Автор: Рассел Арчибальд
Два основных типа моделей жизненного цикла в сфере высоких технологий.
Как показано в Таблице 3, существуют два основных типа моделей жизненного цикла для категории тех проектов, что мы называем "высокотехнологичными". Это прогнозирующий и адаптивный типы. Ниже приводятся примеры для проектов разработки информационных систем, однако, сказанное может быть применено и к некоторым другим видам высокотехнологичным проектам.
Прогнозирующие модели жизненного цикла "ставят оптимизацию выше адаптивности" (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 представителей пользователей этой адаптивной модели жизненного цикла был выпущен "Манифест скоростной разработки программного обеспечения", и эта инициатива получила широкое развитие в отрасли информационных технологий. См. 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: Технические заказы: базовая модель, фазовая модель, модель с несколькими решениями.
|
|
Таблица 3. Модели жизненного цикла проекта и ссылки: общие и применительно к различным категориям проектов (Источник: Archibald 2003, pp. 45 - 46).
Управление проектами разработки программного обеспечения с использованием "Рационального Унифицированного Процесса" / RUP. RUP - это разработанная фирмой IBM и широко используемая модель процесса, которая состоит из 6 наиболее хорошо зарекомендовавших себя практических методик:
- Разрабатывать программное обеспечение итеративно.
- Управлять требованиями.
- Использовать архитектуры, основанные на компонентах.
- Визуально моделировать программное обеспечение.
- Непрерывно проверять качество программного обеспечения.
- Контролировать изменения программного обеспечения.
Wideman (2002) представляет подробный труд о методике RUP, который можно увидеть по адресу: www.maxwideman.com/papers/acquisition/intro.htm . RUP - это процессно-ориентированный программный продукт, поддерживаемый комплектом программных средств от фирмы IBM (на CD-ROM или через интернет по адресу www.us.ibm.com).
Улучшение процесса управления жизненным циклом проекта
После того, как жизненные циклы разработаны и задокументированы для каждой категории или подкатегории проектов, становится возможно определить и задокументировать систему управления жизненным циклом для каждой из них. Только когда такая документация существует, система может совершенствоваться систематическим, комплексным образом. Для того чтобы сделать возможным подход к совершенствованию процессов управления проектами, основанный на принципах (TQM), и избежать неоптимальных фрагментарных попыток улучшений, рекомендуется использовать следующий подход:
- Описать модель интегрированного процесса жизненного цикла: как было рассмотрено выше.
- Задокументировать получившуюся в результате систему управления жизненным циклом проекта (PLCMS) для каждой категории проектов в организации: также рассмотрено выше.
- Выполнять реинжиниринг интегрированного процесса с целью применять наиболее подходящие методы реинжиниринга к PLCMS каждой категории. Цель такого реинжиниринга состоит в следующем:
- Определять системные ограничения, разрывы и слабые места.
- Определять "замедлители", которые непреднамеренно препятствуют процессу, и потенциальные ускорители, способные его ускорить. (Githens 2002).
- Соотносить нежелательные результаты проекта и их возможные причины с PLCMS везде, где это возможно.
- Выполнять перепроектирование PLCMS, начиная с наиболее очевидных ограничений, разрывов и слабых мест, и документировать результаты.
- Осуществлять улучшения.
- Получать требуемые согласия и проводить необходимые тесты или анализ для подтверждения валидности и осуществимости предлагаемых вариантов изменений системы.
- Планировать, утверждать и выполнять проекты внедрения улучшений PLCMS.
- Повторять шаги по мере необходимости до получения оптимальной работоспособной PLCMS.
Команда по внесению улучшений в PLCMS должна включать опытных практиков из сотрудников организации, знакомых с существующими процессами управления проектами.
|
