8. Модель ЖЦ IT проекта

1.

МОДЕЛЬ
ЖИЗНЕННОГО
ЦИКЛА IT-ПРОЕКТА
Практическое занятие курса «Управление информационнотехнологическими проектами №5»

2.

Жизненный цикл проекта
(ГОСТ Р ИСО 21500 -2014)
• Жизненный цикл проекта –
это определенная последовательность фаз,
продолжающаяся
• от начала
• до конца проекта.
Границы фаз: точки принятия решений,
• состав зависит от организационного окружения проекта.
На момент окончания последней фазы цикла все
результаты проекта должны быть получены.

3.

Жизненный цикл продукта
• Жизненный цикл продукта - набор фаз, которые представляют собой эволюцию
Объем продаж
продукта от концепции через поставку, рост, зрелость до изъятия из обращения.
Изменение объема продаж в зависимости от времени.
Выход
Рост
на рынок
Зрелость
Упадок
Время

4.

Фаза ЖЦ (PMBoK)
• Фаза проекта – совокупность логически связанных операций проекта,
завершающихся достижением одного или ряда поставляемых результатов/
• Свойства фазы ЖЦ проекта:
• 1.
Название (произвольное – А, 1, и пр.)
• 2.
Количество фаз (исходя из особенностей проекта)
• 3.
Длительность
• 4.
Требования к ресурсам
• 5.
Входы для перехода на данную фазу
• 6.
Выходы, позволяющие завершить данную фазу
• Ворота фазы: Исполнение и прогресс проекта сравниваются с документами
проекта (планами) и бизнес-документами

5.

Пример фаз типового it-проекта
• 1.
Анализ –спецификация требований
• 2.
Первичное и детальное проектирование
• 3. Разработка/реализация с тестированием
• 4. Интеграция с тестированием
(сборка готового продукта)
• 5.
Передача в эксплуатацию или на сопровождение
• 6. Вывод из эксплуатации

6.

Модели жизненных циклов
Agile Practice Guide
• 1. Предиктивный
• 2. Итеративный
• 3. Инкрементный
4. Гибкий (Agile)

7.

Предиктивный ЖЦ
(или предсказуемый жизненный цикл)
Все этапы и результаты
проекта могут быть
предсказаны и
спланированы заранее
Требования/
Верификация
Часто используется в
традиционных отраслях:
Проектирование/
Верификация
• Строительство
• Производство
Кодирование и
тестирование/
Верификация
Реализация. Передача.
Сопровождение/
верификация

8.

Предиктивный ЖЦ
Требования
Операции
Поставка
результата
Цель
Фиксированные
Один раз за
время проекта
Разовая
поставка
Управление
стоимостью

9.

Итеративный ЖЦ
• Основывается на повторяющихся циклах (итерациях)
для постепенного улучшения и адаптации продукта
• Позволяет учитывать в процессе разработки:
• изменения требований
• условий
Анализ
Прототип
Доводка
Анализ
Дизайн
Разработка
Тестирование
Поставка

10.

Итеративный жц
Требования
Операции
Поставка
результата
Цель
Динамичные
Повторяются
Разовая
поставка
Правильность
решения

11.

Инкрементный ЖЦ
• Каждый инкремент представляет собой завершенный набор
функций, который может быть протестирован и интегрирован в
Инкремент 1
основное приложение.
Проектирование
Кодирование
Релиз
Требования/
верификация 1
2
Инкремент 2
N
Инкремент N

12.

Инкрементный ЖЦ
Требования
Операции
Поставка
результата
Цель
Динамические
Один раз для
каждого
инкремента
Частые
поставки
небольшими
частями
Скорость

13.

Гибкий жц (agile)
Планирование
Дизайн
Разработка
Тестирование
Проверка
Запуск
1
2
3

14.

Гибкий ЖЦ
Требования
Динамичные
Операции
Поставка
результата
Цель
Повторяются
Частые
поставки
небольшими
частями
Ценность для
заказчика за
счет частых
поставок и
обратной связи

15.

Гибкий жц (agile)
Инкрементный
Agile
Структура и
планирование
более четко
определенные этапы и
планирование
основывается на гибком
подходе, где акцент
ставится на адаптацию и
изменение требований в
процессе
Процесс итераций
каждая итерация
включает добавление
нового функционала
итерации могут
включать пересмотр
существующих функций
и их улучшение
Фокус на инкрементах
законченные части
продукта, готовые к
релизу
фокус на коллаборации и
постоянной обратной
связи, с целью
адаптации продукта
Управление
изменениями
изменения могут быть
менее гибкими и
планируются заранее
открыто относится к
изменениям и включает
их в процесс разработки

16.

Неопределенность требований
Модель неопределенности и
сложности. Матрица Ральфа
Стейси
Принципиально
рискованный
Хаос
Сложный
Адаптивные подходы
Усложненный
Простой
Предиктивный подход
Техническая степень неопределенности
Какой подход в каком случае используется?

17.

Выбор модели ЖЦ
Оценка применимости Agile для проекта и организации проводится по трем
категориям:
1. Культура
2. Команда
3. Проект
• Ответы на вопросы – коллективно
• Оценка от 1 до 10
• Для интерпретации результата использовать лепестковую диаграмму.
• 1- 4 – применим гибкий подход
• 5- 7 – гибридный
• 8-10 – предиктивный

18.

Вопросы по категориям
Культура:
Поддерживает ли Agile –подход Заказчик, Спонсор? ДА-1 балл, НЕТ- 10 баллов
Доверие заказчика команде, ДА – 1 балл, НЕТ – 10 баллов
Самостоятельность команды в принятии решений ДА -1 балл, НЕТ – 10 баллов
Команда:
Размер 1-9 чел – 1 балл, более 201 чел – 10 баллов
Опыт работы по Agile все -1, частично – 5, никто – 10
Ежедневный доступ команды к представителю Заказчика, ДА- 1, НЕТ- 10.
Проект:
Насколько вероятны изменения (% в месяц): 50% - 1 балл, 25%- 5 баллов, 5% - 10
баллов.
Критичность дефектов продукта: время – 1 балл, деньги – 5 баллов, жизни людей –
10 баллов.
Возможность инкрементной поставки да – 1 балл, иногда – 5 баллов, нет -10 баллов.

19.

Выбор модели ЖЦ для системы
безопасности на производстве
Проект
изменения
доступ
критичность
10
8
6
4
2
0
опыт
Команда
поставка
поддержка
ИТУР
доверие
размер
принятие
решений
Культура
РАСШИФРУЙТЕ ОТВЕТЫ ПО ДИАГРАММЕ

20.

Кейс 1. Внедрение PLM- системы
• Швейное производство внедряет систему управления жизненным циклом
изделий.
• Со стороны предприятия команда проекта состоит из 5 человек, команда
внедрения – 24 человека.
• Директор завода пытается внедрить Kanban
на отдельных этапах хозяйственной деятельности.
• Компания – дистрибьютор имеет представительный портфель выполненных
проектов.
• Команды Заказчика и Исполнителя работают совместно, новые требования к
работе программы выявляются своевременно и реализуются в течение трехчетырех недель.
• Прогнозируются незначительные временные задержки при реализации
проекта.
• Работа ведется по нескольким областям продукта.
• Выберете модель ЖЦ проекта и обоснуйте свой выбор.

21.

Кейс 2. Построение Системы единого
точного времени на базе «ССВ-1Г»
в ПАО «Ростелеком»
• Сервер точного времени предназначен для синхронизации частотно-
временных показателей на удаленных объектах:
• принимая сигналы со спутников глобальных систем позиционирования GPS и Глонасс,
• сервер передает их клиентским устройствам
• синхронизирует параметры.
• Система модульная.
• Специалисты компании-исполнителя (8 человек) имеют сертификаты ведущих
мировых производителей оборудования, процессы компании соответствуют
ГОСТ 9001-2015.
• Ростелеком по отдельным направлениям внедряет гибкие методологии
управления.
• Постоянные изменения, вносимые Заказчиком, способны оказать существенные
задержки по времени проекта.
• В работе Исполнителя достаточно высока степень самоорганизации.
• Контакты между исполнителями с обеих сторон проходят согласно графику
коммуникаций еженедельно.
• При необходимости есть возможность напрямую обращаться к РП со стороны
Заказчика в режиме реального времени.

22.

Кейс 3. Внедрение «Системы удаленного учета
LoRaWAN» газораспределительной компанией
• Система удаленного мониторинга и учета потребления газа позволяет
• проводить опрос объектов контроля по установленному графику,
• отображать в режиме постоянного времени показатели всех счетчиков и
датчиков, сведение баланса газа,
• немедленно оповещать о возникновении нестандартных ситуаций.
• Система LoRaWan обладает рядом уникальных характеристик и
меньшими издержками эксплуатации по сравнению с более известными
аналогами.
• Над системой работали доктора наук известного НИИ.
• В проекте внедрения задействованы 12 человек со стороны
Исполнителя и 7 со стороны Заказчика.
• Команды работают в постоянном контакте.
• Требования к системе зафиксированы в ТЗ.
• Срок запуска системы под вниманием главы города.