Разделы презентаций
- Разное
- Английский язык
- Астрономия
- Алгебра
- Биология
- География
- Геометрия
- Детские презентации
- Информатика
- История
- Литература
- Математика
- Медицина
- Менеджмент
- Музыка
- МХК
- Немецкий язык
- ОБЖ
- Обществознание
- Окружающий мир
- Педагогика
- Русский язык
- Технология
- Физика
- Философия
- Химия
- Шаблоны, картинки для презентаций
- Экология
- Экономика
- Юриспруденция
Управление проектами в цифровую эпоху
Содержание
- 1. Управление проектами в цифровую эпоху
- 2. Современные вызовы и системные причины появления гибких подходов к управлению проектами
- 3. Информация развивается так, что мы глупеем каждое
- 4. Со стратегической точки зрения самыми важными факторами,
- 5. Ключевыми ответами на эти вызовы станут“Суперпластичные “
- 6. Кьелл Нордстрём 40 — 4000. За последние
- 7. Не разрабатывайте свои решения — сотрудничайте с
- 8. Мы в начале пути самой быстрой урбанизации.
- 9. Подходы в управлении проектами
- 10. Относительная цена итерации продуктаСтепень неопределенности требований к
- 11. 7 методологий управления проектами
- 12. «Waterfall Model» (каскадная модель или «водопад»)Когда требования
- 13. «V Model» Если требуется тщательное тестирование продукта,
- 14. «Incremental Model» (инкрементная модель)Когда основные требования к
- 15. «RAD Model» (rapid application development model или
- 16. «Iterative Model» (итеративная или итерационная модель)Требования к
- 17. «Spiral Model» (спиральная модель)Для сложных и дорогих
- 18. «Agile Model» (гибкая модель)Когда потребности пользователей постоянно
- 19. Agile в работе над проектами и продуктами
- 20. ценности Agile
- 21. 12 принципов Agile
- 22. Agile - это не гибкая методология разработки,
- 23. Самоорганизующаяся командаНад проектом работают мотивированные люди.Создаются все
- 24. Больше общенияПотенциальные пользователи системы и разработчики должны
- 25. Scrum
- 26. В основе метода лежат: 3 роли 3
- 27. Фундаментом для SCRUM являются три принципа:
- 28. Владелец продукта (Product owner )Представитель бизнеса (это
- 29. Скрам мастер (Scrum Master)Участник команды, обучает команду
- 30. Команда (Team)Профессионалы, выполняющие конкретный объем работы для
- 31. Слайд 31
- 32. Планирование (Sprint Planning)Проводится в начале спринтаУчаствует вся
- 33. Product Backlog(описание продукта)Полный список задач и понятные
- 34. Слайд 34
- 35. Sprint BacklogЗадачи, которые команда берет в работу
- 36. Спринт (Sprint)Фаза разработки состоит из нескольких итераций – спринтов.Обычно спринт длится 2-4 недели.Этапы:ПланированиеРазработкаДемонстрацияРетроспектива
- 37. Ретроспектива спринтаПериодический пересмотр того, что работает, а
- 38. Ежедневный скрам (Daily Scrum)Проводится каждый день в
- 39. Демонстрация (ревью)В конце каждого спринта проводится ревьюЭто
- 40. Слайд 40
- 41. Слайд 41
- 42. Чек-лист запуска Scrum-командыЦЕЛЬ КОМАНДЫУ команды есть цельЦель
- 43. Чек-лист запуска Scrum-командыТЕХНИЧЕСКАЯ ВОЗМОЖНОСТЬ ПОСТАВЛЯТЬ КАЧЕСТВЕННЫЙ РЕЗУЛЬТАТКоманда
- 44. Чек-лист запуска Scrum-командыРЕГЛАМЕНТЫ КОМПАНИИСуществующие регламенты организации позволяют
- 45. KANBAN
- 46. Слайд 46
- 47. А Б В Г Д Е Ж
- 48. А Б В Г Д Е Ж
- 49. Разные цвета карточек - разные типы работВ работе - не более 5 карточек
- 50. KANBAN-ДОСКИ
- 51. Битрикс 24CRM- система, помимо Канбан, есть традиционные
- 52. WrikeCервис управления проектами. У каждого пользователя есть
- 53. TrelloПросто и понятно. Можно создать сколько угодно
- 54. Демо: работа по Scrum в Trellohttps://www.coursera.org/learn/upravleniya-proektami-agile-scrum/lecture/LMsbb/diemo-rabota-po-scrum-v-trello https://trello.com/ru
- 55. PMBOK PMP PMIPMP (Project management professional) –
- 56. PMBOKГруппы процессов согласно PMBOK:ИнициированиеПланированиеВыполнениеМониторинг и контрольЗавершениеВ рамках
- 57. PMBOK. Группа процессов инициированияРазработка устава проектаОпределение заинтересованных сторон проекта
- 58. PMBOK. Группа процессов планированияРазработка плана управления проектомПланирование
- 59. PMBOK. Группа процессов исполненияРуководство и управление исполнением
- 60. PMBOK. Группа процессов мониторинга и управленияМониторинг и
- 61. PMBOK. Группа завершающих процессовЗакрытие проектаЗакрытие контрактов
- 62. Группы процессов управления проектом
- 63. Соотношение групп процессов и областей знаний
- 64. Инструменты PMBoK Диаграмма Ганта (Gantt Chart).Диаграмма Парето
- 65. Методы PMBoK Анализ дерева решений (Decision Tree
- 66. Стандартный ЖЦ по PMBOK
- 67. SWX: Характеристики жизненных циклов проекта – ЭТАПЫCreation
- 68. https://onagile.ru/trends/lean-startup
- 69. Скачать презентанцию
Современные вызовы и системные причины появления гибких подходов к управлению проектами
Слайды и текст этой презентации
Слайд 3Информация развивается так, что мы глупеем каждое утро
Оцифровка мира
Моментальное копирование
успешного результата
Реструктуризация времени: турбулентность ежедневных бифуркации
Реструктуризация пространства: расстояний больше нет
ВЫЗОВЫ
внешней
средыКьелл Нордстрём
Фредерик Лалу
Артем Чапцов
FAANG задает новые стандарты бизнес-среды
Ценность высшего образования падает
Глобализация:
общие правила, всеобщая конкуренция
Человеческое сознание эволюционирует: новые формы совместной работы
Слайд 4Со стратегической точки зрения самыми важными факторами, которые повлияют на
организации, будут
Высокая частота точек бифуркации макросистем, требующая качественно новой степени
адаптивности организацийВысочайшая скорость устаревания информации, знаний и навыков, требующая новых принципов устройства организации и управления компетенциями подчиненных
Моментальное копирование успеха, требующее постоянной инновационности для создания временных монополий в сознании пользователей продукта
Слайд 5Ключевыми ответами на эти вызовы станут
“Суперпластичные “ организации, центральной структурной
единицей которых станет неконкурентный кластер
Смена парадигмы при отборе и обучении
персонала - отбор по генетическим и ценностным признакам, моментальное не столь глубокое, но постоянное обучение - переход от инвестиций в статические активы знаний и навыков к борьбе за скорость цикла их обновленияНовое метафункциональное разделение - хранители активов / “рой” предпринимателей
Слайд 6Кьелл
Нордстрём
40 — 4000. За последние 40 лет человечество
сделало для себя столько же, сколько за предыдущие 4000 лет.
50
: 50. Ровно такая пропорция людей живущих в городах и вне их, но в ближайшие 30 лет ситуация драматически изменится.7 лет — это уникальный срок для цивилизации, поскольку за это время большинство привычных вещей сейчас меняется до неузнаваемости.
В мире всё зависит от чего-то, поэтому очень сложно исследовать любые процессы.
Если раньше для познания мира (рынка, отношений, трендов) нужно было исследовать 3 составляющие — Технологии, Институты, Ценности, то сегодня всё происходящее определяют лишь Технологии.
Слайд 7Не разрабатывайте свои решения — сотрудничайте с FAANG.
Если не можете
сотрудничать с FAANG-компаниями — не конкурируйте с ними «в лоб»
своими решениями и продуктами. Вы проиграете.Сейчас зарождается Капитализм 4.0: Правила, Регуляция, Экологичность.
Из-за экономического роста ухудшаются демографические показатели.
Мир стал лучше: продолжительность жизни растёт, наступило самое мирное время, преступность самая низкая. Кстати, нам кажется, что это не так из-за наступившей гиперреальности — излишней информированности и осведомлённости.
FAANG-компании растут экспоненциально. Поэтому в будущем будут выживать только такие бизнесы. Например, Google и Facebook контролируют 80% существующего рынка мобильной рекламы и обеспечивают 99,7% его роста. Появление новых игроков там полностью исключено.
Слайд 8Мы в начале пути самой быстрой урбанизации.
Сейчас есть 220
стран, но уже через 30 лет в мире будет около
600 городов, в которых будет жить 80-85% всей популяции и где будет сосредоточено 95% всего мирового ВВП.Всё, что может быть оцифровано, будет оцифровано. Всё, что может быть оцифровано, будет оцифровано и скопировано.
Чем больше в мире будет оцифровано — тем более ценными и дорогими становятся вещи и явления, которые невозможно оцифровать.
Раньше людей нанимали за навыки, а затем “притирали” их к корпоративной культуре компаний. Сейчас людей будут нанимать за отношение, а затем обучать их навыкам.
Мы живём в Матрице, состоящей из трёх ключевых компонентов: Рыночной экономики, Урбанизации и Диджитализации.
Слайд 10Относительная цена итерации продукта
Степень неопределенности требований к продукту и методам
его создания
Обработка обратной связи
Компетентностно-ориентированные системы управления
Процессно-ориентированные системы управления
Слайд 12«Waterfall Model» (каскадная модель или «водопад»)
Когда требования известны, понятны и
зафиксированы. Противоречивых требований не имеется.
Нет проблем с доступностью людей
нужной квалификации.В относительно небольших проектах.
Слайд 13«V Model»
Если требуется тщательное тестирование продукта, то V-модель оправдает
заложенную в себя идею: validation and verification (Проверка и подтверждение).
Для
малых и средних проектов, где требования четко определены и фиксированы.В условиях доступности людей необходимой квалификации, особенно тестировщиков.
Слайд 14«Incremental Model» (инкрементная модель)
Когда основные требования к проекту четко определены
и понятны. В то же время некоторые детали могут дорабатываться
с течением времени.Требуется быстрое исполнение проекта.
Могут появиться новые возможности (фичи).
Слайд 15«RAD Model»
(rapid application development model или быстрая разработка приложений)
Может
использоваться только при наличии высококвалифицированных и узкоспециализированных специалистов.
Бюджет проекта
большой, чтобы оплатить этих специалистов вместе со стоимостью готовых инструментов автоматизированной сборки. Может быть выбрана при уверенном знании конечной цели и необходимости срочного исполнения проекта в течение 2-3 месяцев.
Слайд 16«Iterative Model»
(итеративная или итерационная модель)
Требования к конечному результату проекта
заранее четко определены и понятны.
Проект большой или очень большой.
Основная задача
должна быть определена, но детали реализации могут эволюционировать с течением времени.
Слайд 17«Spiral Model»
(спиральная модель)
Для сложных и дорогих проектов (н-р государственных).
На
каждом витке 4 этапа:
планирование;
анализ рисков;
конструирование;
оценка результата и при удовлетворительном качестве
переход к новому витку
Слайд 18«Agile Model»
(гибкая модель)
Когда потребности пользователей постоянно меняются в динамическом
бизнесе.
Изменения на Agile реализуются за меньшую цену из-за частых инкрементов
(операций увеличения переменной).В отличие от модели водопада, в гибкой модели для старта проекта достаточно лишь небольшого планирования.
Слайд 22Agile - это не гибкая методология разработки, это система ценностей,
философия или даже образ мышления.
Agile - это собирательный бренд,
любых подходов, принципов, методов или методологии, позволяющих действовать согласно ценностям и принципов Agile manifest.Agile - это процессы, продукты и инструменты.
Agile-подходы
Слайд 23Самоорганизующаяся команда
Над проектом работают мотивированные люди.
Создаются все условия, поддержка и
полное доверие.
Самые лучшие архитектуры, требования и дизайны систем создаются
самоорганизующимися командами. Команда сама организует оптимальный процесс.
Слайд 24Больше общения
Потенциальные пользователи системы и разработчики должны работать вместе
на
протяжении всего проекта.
Самый действенный и эффективный способ обмена информацией
как внутри команды разработчиков, так и
с внешним миром - непосредственное общение. 
Слайд 26В основе метода лежат:
3 роли
3 артефакта
5 событий
владелец продукта
скрам-мастер
команда
Бэклог продукта
Планирование Спринта
Бэклог спринта
СПРИНТ
1-4 недель
Ежедневный спринт (15 мин)
Завершение работы
(инкремент продукта)Обзор спринта
+
Ретроспектива
Слайд 27Фундаментом для SCRUM являются три принципа:
• Прозрачность. Важные
документы и элементы должны быть доступны тем, кто за них
отвечает. Информация должна быть структурирована таким образом, чтобы обеспечить свободный обмен внутри команды проекта и между внешними участниками проекта. Прозрачность обеспечивается с целью построения эффективных коммуникаций, оперативного выявления проблем и реализации изменений.• Рефлексия. Участники проекта должны на постоянной основе собирать информацию о продукте, состоянии проекта и окружении с целью выявления отклонений, рисков и потенциальных возможностей. В этот процесс должны быть вовлечены все участники проекта.
• Непрерывное улучшение. Команда постоянно ищет возможности для улучшения своего продукта и рабочего процесса. Целью улучшений в первую очередь должна являться удовлетворённость заказчика.
Слайд 28Владелец продукта (Product owner )
Представитель бизнеса (это может быть другой
отдел или целая компания).
Знает, как должен работать или выглядеть
конечный продукт и заинтересован в его качестве, отвечает за максимальную его ценность.
Слайд 29Скрам мастер (Scrum Master)
Участник команды, обучает команду и компанию фреймворку.
Согласовывает с представителем бизнеса изменения или внедрение какого-либо решения
Проводится каждый
день в фиксированное времяРекомендуется проводить стоя в течение 10-15 минут
Если что-то нужно обсудить, назначается время после скрама
Scrum Master спрашивает каждого:
Что ты делал?
Что ты собираешься делать?
Какие были проблемы?
Слайд 30Команда (Team)
Профессионалы, выполняющие конкретный объем работы для создания продукта, который
должен соответствовать требованиям.
от 3 до 9 человек
Слайд 32Планирование (Sprint Planning)
Проводится в начале спринта
Участвует вся команда
User stories разбиваются
на задачи и оцениваются членами команды
В результате команда подписывается на
ту функциональность, на которую хватает времени спринта
Слайд 33Product Backlog
(описание продукта)
Полный список задач и понятные требования для создания
конечного продукта
Product backlog один на весь релиз
Им владеет менеджер продукта
(“product owner”)Он не статичен – записи можно добавлять, удалять, менять им приоритет - живой документ
Общедоступен, но поддерживается одним человеком
Слайд 35Sprint Backlog
Задачи, которые команда берет в работу из Product Backlog
на время спринта
Описывает задачи, запланированные командой на спринт
Задачи – действия,
необходимые для реализации запланированной на спринт функциональностиВ описание задачи входит ее оценка
Члены команды выбирают работу на свой выбор
Задачи никогда не назначаются принудительно
Слайд 36Спринт (Sprint)
Фаза разработки состоит из нескольких итераций – спринтов.
Обычно спринт
длится 2-4 недели.
Этапы:
Планирование
Разработка
Демонстрация
Ретроспектива
Слайд 37Ретроспектива спринта
Периодический пересмотр того, что работает, а что нет
После каждого
спринта
Участвуют все члены команды
Цель - осознать:
Что было хорошо?
Что могло бы
быть лучше15-30 минут
Ретроспектива
Ретроспектива
Ретроспектива
Обратная связь
Обратная связь
Обратная связь
Слайд 38Ежедневный скрам (Daily Scrum)
Проводится каждый день в фиксированное время
Рекомендуется проводить
стоя в течение 10-15 минут
Если что-то нужно обсудить, назначается время
после скрама
Слайд 39Демонстрация (ревью)
В конце каждого спринта проводится ревью
Это демонстрация реализованной функциональности
В
ней может участвовать любой человек, задействованный в проекте
В идеале после
каждой демонстрации можно отправлять продукт заказчику
Слайд 42Чек-лист запуска Scrum-команды
ЦЕЛЬ КОМАНДЫ
У команды есть цель
Цель определена бизнессом
Цель понятна
Цель
достижима
Цель команды не противоречит целям организации
Цель не токсична по отношению
к участникам командыЦель не токсична по отношению к ключевым заинтересованным лицам команды
СОСТАВ КОМАНДЫ
Определён владелец продукта, который обладает полномочиями, достаточным количеством времени и доступом к заинтересованным лицам
В команду включены специалисты, обладающие всеми критическими компетенциями для достижения цели
Участники команды выделены в неё на 100%
Состав команды фиксирован
КОЛЛОКАЦИЯ
Команда занимает помещение, где может свободно общаться друг с другом
Есть место для доски задач и других информационных радиаторов
Есть место для проведения Скрам-событий
Команда не мешает никому и ей никто не будет мешать
Слайд 43Чек-лист запуска Scrum-команды
ТЕХНИЧЕСКАЯ ВОЗМОЖНОСТЬ ПОСТАВЛЯТЬ КАЧЕСТВЕННЫЙ РЕЗУЛЬТАТ
Команда имеет в наличии
все технические средства поставки результата
Команда обладает всеми необходимыми доступами в
физических и виртуальных средах для эффективной работыВнутри компании есть специалисты, которые смогут помочь в случае необходимости для решения технических и инфраструктурных проблем
ГОТОВНОСТЬ К ПОСТАВКЕ БИЗНЕСА И ПОДРЯДЧИКА (ВЕНДОРА)
Представители бизнеса и руководство подрядчика ознакомлены с принципами итеративной и инкрементальной разработки и морально готовы так работать
Представители бизнеса готовы уделять достаточно времени команде
Руководство подрядчика понимает, что несет ответственность за выделение людей в команду на 100%
СИСТЕМА БОНУСИРОВАНИЯ, НЕ ОСНОВАННАЯ НА ЛИЧНОМ ВКЛАДЕ
Система KPI не порождает конкуренцию внутри команды, включая ИТ, бизнес, подрядчика
Договорная система с подрядчиком не токсична по отношению к общим целям команды
Система KPI не порождает конфликты с внешними по отношению к команде службами компании
Члены команды не оцениваются индивидуально, а только команда целиком
ОКРУЖЕНИЕ КОМАНДЫ
Системы и команды, относительно которых есть зависимости, известны и понятны
Жизненный цикл работы внешних команд, от которых есть зависимости, не препятствует быстрой поставке результата
Есть понимание, как команды могут взаимодействовать с друг другом для быстрого решения зависимостей
Слайд 44Чек-лист запуска Scrum-команды
РЕГЛАМЕНТЫ КОМПАНИИ
Существующие регламенты организации позволяют работать по Agile,
включая правила по: бюджетированию, проектному управлению, выводу систем в продуктивное
окружение и перевод систем на поддержку, безопасность, юристы и т.д.Бюджет формируется для каждой существующей цепочки создания ценности (команды, набора команд) и не зависит от состава работ.
Слайд 47А Б В Г Д Е Ж З И К
Л М Н О П Р
С1 2 3 4 5 6 7 8 9 10 11 12 13 15 16 17 18 19
Многозадачность
Слайд 51Битрикс 24
CRM- система, помимо Канбан, есть традиционные списки, диаграмма Ганта.
В канбан представлении есть по умолчанию три колонки: новые, выполняются
и сделаны, между которыми можно произвольно перемещать задачи. Доступно создание множества проектов с разделением сотрудников (бесплатная версия до 12 человек).
Слайд 52Wrike
Cервис управления проектами.
У каждого пользователя есть личная и совместная
доски + можно добавлять новые доски для каждого проекта.
В
карточке задачи можно оставлять комментарии, предоставлять доступ другим пользователям, прикреплять файлы. В бесплатной версии недоступны некоторые функции, например, учет времени, добавление зависимостей задач, лента новостей, панель задач и другое.
Размер команды на Free тарифе ограничен пятью пользователями
Слайд 53Trello
Просто и понятно.
Можно создать сколько угодно списков (проектов) с
карточками.
В карточках есть сроки, метки, возможность прикреплять файлы, писать
комментарии и прочее. Ограничений на количество пользователей для доски нет. Деньги придется платить только за дополнительные фичи: календарь, голосование, и визуальные изменения.
Весь основной канбан-функционал предоставляется бесплатно.
Особенность Trello – красивый интерфейс и множество интеграций, например Slack для корпоративного общения.
Слайд 54Демо: работа по Scrum в Trello
https://www.coursera.org/learn/upravleniya-proektami-agile-scrum/lecture/LMsbb/diemo-rabota-po-scrum-v-trello
https://trello.com/ru
Слайд 55PMBOK PMP PMI
PMP (Project management professional) – сертификация PM, введена
в 1984 г. американским Институтом управления проектами PMI (Project management
institute).PMI (www.pmi.org) - это:
всемирно известная организация, объединяющая PM земного шара
американский национальный институт стандартов
несколько программ сертификации, утвержденных Международной организацией по стандартизации ISO 9001
организация, разработавшая стандарт PMBOK
PMP и PMBOK (Project Management Body of Knowledge)
американский национальный стандарт
консолидированные профессиональные знания по управлению проектами
набор процессов и областей знаний, общепринятых в качестве наилучшей практики
источник ответов на вопросы о процессах управления проектами. инструментах и методах
Слайд 56PMBOK
Группы процессов согласно PMBOK:
Инициирование
Планирование
Выполнение
Мониторинг и контроль
Завершение
В рамках данного стандарта управление
проектами рассматривается сквозь призму 5 ключевых групп процессов и 10
областей знаний.Области знаний PMBOK:
Управление интеграцией
Управление содержанием
Управление сроками
Управление стоимостью
Управление качеством
Управление человеческими ресурсами
Управление коммуникациями
Управление рисками
Управление закупками
Управление стейкхолдерами
Слайд 57PMBOK. Группа процессов инициирования
Разработка устава проекта
Определение заинтересованных сторон проекта
Слайд 58PMBOK. Группа процессов планирования
Разработка плана управления проектом
Планирование содержания
Определение содержания
Создание иерархической
структуры работ (ИСР)
Определение состава операций
Определение взаимосвязей операций
Оценка ресурсов
Оценка длительности операций
Разработка
расписанияСтоимостная оценка
Разработка бюджета расходов
Планирование качества
Планирование человеческих ресурсов
Планирование коммуникаций
Планирование управления рисками
Идентификация рисков
Качественный анализ рисков
Количественный анализ рисков
Планирование реагирования на риски
Планирование покупок
Планирование контрактов
Слайд 59PMBOK. Группа процессов исполнения
Руководство и управление исполнением проекта
Процесс обеспечения качества
Набор
команды проекта
Развитие команды проекта
Распространение информации
Запрос информации у продавцов
Выбор продавцов
Слайд 60PMBOK. Группа процессов мониторинга и управления
Мониторинг и управление работами проекта
Общее
управление изменениями
Подтверждение содержания
Управление содержанием
Управление расписанием
Управление стоимостью
Процесс контроля качества
Управление командой проекта
Отчетность
по исполнениюУправление участниками проекта
Наблюдение и управление рисками
Администрирование контрактов
Слайд 64Инструменты PMBoK
Диаграмма Ганта (Gantt Chart).
Диаграмма Парето (Pareto Chart).
Иерархическая структура рисков
(Risk Breakdown Structure, RBS).
Информационная система управления проектами (Project Management Information
System, PMIS).Матрица вероятности и воздействия (Probability and Impact Matrix).
Матрица ответственности (Responsibility Assignment Matrix, RAM).
Расписание контрольных событий (Milestone Schedule).
Сетевая модель (Schedule Model).
Система санкционирования выполнения работ (Work Authorization System).
Система управления изменениями (Change Control System).
Система управления конфигурацией (Configuration Management System).
Слайд 65Методы PMBoK
Анализ дерева решений (Decision Tree Analysis).
Анализ допущений (Assumptions Analysis).
Анализ
ожидаемого денежного значения (Expected Monetary Value (EMV) Analysis).
Анализ отклонений (Variance
Analysis).Анализ сети (Schedule Network Analysis или Network Analysis).
Анализ сильных и слабых сторон, возможностей и угроз (Strengths, Weaknesses, Opportunities, and Threats Analysis, или SWOT Analysis).
Анализ характера и последствий отказов (Failure Mode and Effect Analysis, FMEA).
Aнализ чувствительности (Sensitivity Analysis).
Быстрый проход (Fast Tracking).
Выравнивание ресурсов (Resource Leveling).
Декомпозиция (Decomposition).
Метод «операции в узлах» (метод диаграмм предшествования) (Precedence Diagramming Method, PDM).
Метод Дельфи (дельфийский метод) (Delphi Technique).
Метод критического пути (Critical Path Methodology, CPM).
Метод критической цепи (Critical Chain Method).
Метод Монте-Карло (Monte Carlo Analysis).
Метод освоенного объема (Earned Value Technique, EVT).
Метод оценки и анализа программ (Program Evaluation and Review Technique, PERT).
Мозговой штурм (Brainstorming).
Оценка «снизу вверх» (Bottom-up Estimating).
Планирование методом набегающей волны (Rolling Wave Planning).
Управление освоенным объемом (Earned Value Management, EVM).
Слайд 67SWX: Характеристики жизненных циклов проекта – ЭТАПЫ
Creation of software deliverables
typically requires a variety of project life cycle processes. According
to ISO/IEC/IEEE Standard 12207, development of software includes the following processes (see also Figure 1 of 12207):Analyze: Software Requirements Analysis Process,
Architect: Software Architectural Design Process,
Design: Software Detailed Design Process,
Construct: Software Construction Process,
Integrate: Software Integration Process, and
Test: Software Qualification Testing.
2.4.1 Characteristics of Project Life Cycles
