Russian
Russian
English
English
Логин  
Пароль  
Зарегистрируйтесь, и вы сможете получить доступ ко всем ресурсам нашего сайта

События Главная События Главная

Поиск

Наши друзья
Журнал "Управление проектами" издается при поддержке Московского отделения PMI c 2004 года. В качестве авторов статей привлекаются известные отраслевые эксперты, специалисты-практики. Журнал ориентируется на широкий круг читателей: руководителей высшего и среднего звена, профессионалов-практиков различных отраслей промышленности, государственного управления и социальной сферы, профессиональных преподавателей и тренеров, начинающих специалистов...

Главная   Услуги   Обучение  События   Наши книги  Белые страницы  Глоссарий 
На главную страницу Связаться с авторами сайта

Модели жизненного цикла высокотехнологичных проектов

Автор: Рассел Арчибальд

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

Как показано в Таблице 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 наиболее хорошо зарекомендовавших себя практических методик:

  1. Разрабатывать программное обеспечение итеративно.
  2. Управлять требованиями.
  3. Использовать архитектуры, основанные на компонентах.
  4. Визуально моделировать программное обеспечение.
  5. Непрерывно проверять качество программного обеспечения.
  6. Контролировать изменения программного обеспечения.

Wideman (2002) представляет подробный труд о методике RUP, который можно увидеть по адресу: www.maxwideman.com/papers/acquisition/intro.htm . RUP - это процессно-ориентированный программный продукт, поддерживаемый комплектом программных средств от фирмы IBM (на CD-ROM или через интернет по адресу www.us.ibm.com).

Улучшение процесса управления жизненным циклом проекта

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

  1. Описать модель интегрированного процесса жизненного цикла: как было рассмотрено выше.
  2. Задокументировать получившуюся в результате систему управления жизненным циклом проекта (PLCMS) для каждой категории проектов в организации: также рассмотрено выше.
  3. Выполнять реинжиниринг интегрированного процесса с целью применять наиболее подходящие методы реинжиниринга к PLCMS каждой категории. Цель такого реинжиниринга состоит в следующем:
    1. Определять системные ограничения, разрывы и слабые места.
    2. Определять "замедлители", которые непреднамеренно препятствуют процессу, и потенциальные ускорители, способные его ускорить. (Githens 2002).
    3. Соотносить нежелательные результаты проекта и их возможные причины с PLCMS везде, где это возможно.
    4. Выполнять перепроектирование PLCMS, начиная с наиболее очевидных ограничений, разрывов и слабых мест, и документировать результаты.
  4. Осуществлять улучшения.
    1. Получать требуемые согласия и проводить необходимые тесты или анализ для подтверждения валидности и осуществимости предлагаемых вариантов изменений системы.
    2. Планировать, утверждать и выполнять проекты внедрения улучшений PLCMS.
  5. Повторять шаги по мере необходимости до получения оптимальной работоспособной PLCMS.

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


Глоссарий

Finish-to-Finish (FF)
Финиш-Финиш (ФФ)


Зависимость между двумя операциями (работами) проекта или между операцией проекта и контрольным событием. См. также отношение предшествования (precedence relationship). Существуют четыре типа логических взаимосвязей:
  • Финиш-Старт: последующая операция может начаться лишь после...
Подробнеe

П редставляем Вашему вниманию уникальную возможность задать Ваши вопросы наиболее авторитетным экспертам мирового уровня в сфере управления проектами. Задать вопрос может любой зарегистрировавшийся гость сайта.

Каждую неделю мы отбираем наиболее интересные вопросы и направляем их специально приглашаемому эксперту.
Rambler's Top100
Rambler's Top100

© p.m.Office 2003-2007