Управление проектом ИС

1. Лк.3 Управление проектом ИС

1. Стандарты проектного менеджмента
2. Microsoft Solutions Framework
3. Методики гибкой разработки Agile. Scrum
4. ГОСТ Р ISO 21500:2014 и ГОСТ Р 57101—2016/ISO/IEC/IEEE
16326:2009 Системная и программная инженерия. ПРОЦЕССЫ
ЖИЗНЕННОГО ЦИКЛА. Управление проектом
5. Автоматизированные средства управления проектами

2. Проектный менеджмент при создании/внедрении ИС

Проект создания и внедрения информационной системы должен управляться по
правилам проектного менеджмента
Проект - комплекс взаимосвязанных мероприятий, направленный на создание
уникального продукта или услуги в условиях временных и ресурсных
ограничений (ГОСТ Р 54869-2011). Проект включает в себя замысел
(проблему), средства его реализации (решения проблемы) и получаемые в
процессе реализации результаты
Реализация проекта осуществляется полномочным руководством проекта,
менеджером проекта и командой проекта, работающей под этим
руководством, другими участниками проекта, выполняющими отдельные
специфические виды деятельности, процессы по проекту.
Управление проектом представляет собой методологию организации,
планирования, руководства, координации человеческих и материальных
ресурсов на протяжении жизненного цикла проекта (говорят также проектного цикла), направленную на эффективное достижение его целей
путем применения системы современных методов, техники и технологий
управления для достижения определенных в проекте результатов по составу
и объему работ, стоимости, времени, качеству.

3. Задачами управления проекта являются:

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

4. Жизненный цикл проекта

На
прединвестиционной стадии проводятся: анализ инвестиционных
возможностей; предварительное ТЭО; доклад об инвестиционных
возможностях; планирование; определение вариантов финансирования.
На инвестиционной стадии: переговоры и заключение контрактов;
проектирование; строительство; маркетинг; обучение.
На стадии эксплуатации: приемка и запуск; производство; замена
оборудования;
На стадии ликвидации проекта проводится завершение проекта как
одноразового мероприятия.
Функции управления проектом включают: планирование, контроль, анализ,
принятие решений, составление и сопровождение бюджета проекта,
организацию осуществления, мониторинг, оценку, отчетность, экспертизу,
проверку и приемку, бухгалтерский учет, администрирование.
Подсистемы управления проектом включают: управление содержанием и
объемами работ, управление временем, продолжительностью, управление
стоимостью, управление качеством, управление закупками и поставками,
управление распределением ресурсов, управление человеческими ресурсами,
управление рисками, управление запасами ресурсов, интеграционное
управление, управление информацией и коммуникациями

5. Распространенные методики управления проектами

ГОСТ 19.XXX, 34.XXX (601-90)
ГОСТ Р ИСО/МЭК ТО 16326-2002 +
ГОСТ Р ИСО/МЭК 12207-2010.
ГОСТ Р 54869—2011 «Проектный менеджмент. Требования к управлению
проектом»
ГОСТ Р 54870—2011 «Проектный менеджмент. Требования к управлению
портфелем проектов»
ГОСТ Р 54871—2011 «Проектный менеджмент. Требования к управлению
программой»
ГОСТ Р 21500—2014 «Руководство по управлению поектами».
ГОСТ Р 57101—2016/ISO/IEC/IEEE 16326:2009 Системная и программная
инженерия. ПРОЦЕССЫ ЖИЗНЕННОГО ЦИКЛА. Управление проектом.
ANSI/PMI 99-001-2004(2008) (PMBOK 5.0)
Custom Development Method (CDM) Oracle
Rational Unified Process (RUP)
Microsoft Solution Framework (MSF)
Extreme Programming (XP)
5
SCRUM

6. Распространенные методики управления проектами

Различные модели процесса разработки ПО и их распределение по «весу»
6

7. Действия в процессе разработки программного обеспечения, составляющие основу работ по проекту

Анализ требований к продукту
Заказчик чаще всего представляет весьма размытую идею о том,
каким должен быть конечный результат, и не имеет
представления о том, как должна работать программа.
Незаконченные, нелепые, а иногда противоречащие друг другу
требования распознаются хорошими инженерами на этой стадии.
Один из методов нахождения проблем такого рода — это анализ
элементов программного обеспечения.
Когда общие требования получены от клиента, их необходимо
уточнить и документировать.
Спецификация
Спецификация - задача, описывающая до мелочей программный
продукт, который будет создан, по возможности, в виде строгого
описания. На практике большинство удачных спецификаций
написаны для того, чтобы понять и отточить уже написанные
приложения. Спецификации наиболее важны для внешних
интерфейсов, которые должны оставаться стабильными. Способ
определить качество спецификации — анализ её независимым
экспертом.

8. Действия в процессе разработки программного обеспечения, составляющие основу работ по проекту

Архитектура
Архитектура системы приложения создаётся для того, чтобы быть
уверенным, что программное обеспечение будет выполнять
требования к нему, а так же создать возможность добавлять
решения для новых требований. На этапе архитектурной
проработки
решаются
проблемы
интерфейсов
между
программным обеспечением и операционной системой, или
оборудованием.
Проектирование, реализация и тестирование
Проектирование — процесс создания общей архитектуры и
алгоритмов согласно спецификациям.
Реализация (имплементация) — это та часть процесса, во время
которой программисты собственно создают программный код
продукта.
Тестирование — всеобъемлющая и важная часть процесса
разработки программного обеспечения. Эта часть процесса
заключается в том, чтобы выявить и решить различные ошибки.
Документирование проводится для того, чтобы в будущем было
проще поддерживать и улучшать программный продукт.

9. Действия в процессе разработки программного обеспечения, составляющие основу работ по проекту

Распространение и поддержка
Распространение начинается после того, как код достаточно
оттестирован,
и
признан
готовым
к
релизу.
Техническая поддержка и обучение важны, так как много проектов
проваливается, если их результаты никто не может использовать.
Поддержка и улучшение продукта вместе с исправлением
найденных ошибок может занимать больше времени, чем
собственно процесс разработки этого продукта.

10. Разработка по ГОСТ-ам ЕСПД и ИТ. Каскадная модель

ГОСТы 19 «Единая система программной документации» и ГОСТы 34
«Стандарты на разработку и сопровождение автоматизированных
систем» ориентированы на последовательный подход к разработке ИС.
Разработка в соответствии с этими стандартами проводится по этапам,
каждый из которых предполагает выполнение строго определенных
работ, и завершается выпуском достаточно большого числа весьма
формализованных и обширных документов. Таким образом, строгое
следование этим гостам не только приводит к водопадному подходу,
но и требует очень высокой степени формализованности разработки. На
основе этих стандартов разрабатываются программные системы по
госзаказам в России.
В модели предусмотрено, что каждая последующая фаза начинается лишь
тогда, когда полностью завершено выполнение предыдущей фазы.
Каждая фаза имеет определенные критерии входа и выхода: входные и
выходные данные. В результате выполнения генерируются внутренние
или внешние данные проекта, включая документацию и ПО. Документы
по анализу требований впоследствии передаются системным
специалистам, которые в свою очередь передают их разработчикам
программных систем более высокого уровня. Разработчики передают
детальные технические характеристики программистам, которые уже
представляют готовый код тестерам.

11. Разработка по ГОСТ-ам ЕСПД и ИТ. Каскадная модель

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

12. Каскадная модель ЖЦ ИТ инфраструктуры

13. Каскадная модель ЖЦ ИТ инфраструктуры

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

14. Каскадная модель ЖЦ ИТ инфраструктуры

процесс реализации — в результате его выполнения эскизное
описание ПО превращается в полноценный программный продукт.
При этом создается исходный код, база данных и документация,
которые лежат в основе физического преобразования проекта.
Если программный продукт представляет собой приобретенный
пакет прикладных программ, основными действиями по его
реализации будут являться установка и тестирование пакета
программ. Если программный продукт разрабатывается на заказ,
основными действиями являются программирование и кодтестирование;
процесс установки — включает установку ПО, его проверку и
официальную приемку заказчиком для операционной среды;
процесс эксплуатации и поддержки - подразумевает запуск
пользователем системы и текущее обеспечение, включая
предоставление технической помощи, обсуждение возникших
вопросов с пользователем, регистрацию запросов пользователя
на
модернизацию
и
внесение
изменений,
а
также
корректирование или устранение ошибок;

15. Каскадная модель ЖЦ ИТ инфраструктуры

процесс сопровождения— связан с разрешением программных
ошибок, неисправностей, сбоев, модернизацией и внесением
изменений, генерируемых процессом поддержки. Состоит из
итераций разработки и предполагает обратную связь по
предоставлению информации об аномалиях;
процесс вывода из эксплуатации — вывод существующей
системы из ее активного использования либо путем прекращения
ее работы, либо благодаря ее замене новой системой или
модернизированной версией существующей системы;
интегральные задачи — включают начало работы над проектом,
мониторинг проекта и его управление, управление качеством,
верификацию и аттестацию, менеджмент конфигурации,
разработку документации и профессиональную подготовку на
протяжении всего жизненного цикла.

16. Методика разработки Microsoft Solutions Framework

Методология MSF сочетает в себе свойства двух стандартных моделей
проектирования: каскадной (waterfall) и спиральной (spiral). Процесс MSF
ориентирован на “вехи” (milestones) – ключевые точки проекта,
характеризующие достижение в его рамках какого-либо существенного
(промежуточного либо конечного) результата.
В соответствии с методологией MSF ИТ команда представлена ИТ специалистами,
распределенными по нескольким ролевым кластерам.
MSF содержит:
модели:
модель проектной группы
модель процессов
дисциплины:
дисциплина управление проектами
дисциплина управление рисками
дисциплина управление подготовкой

17. Microsoft Solutions Framework

MSF включает в себя ряд основных принципов. Вот те из них, которые имеют
отношение к успешной работе команды:
1.Распределение ответственности при фиксации отчетности
2.Наделяйте членов команды полномочиями
3.Концентрируйтесь на бизнес-приоритетах
4.Единое видение проекта
5.Проявляйте гибкость — будьте готовы к переменам
6.Поощряйте свободное общение
Успешное использование модели проектной группы MSF основывается на ряде
ключевых концепций (key concepts):
1.Команда соратников
2.Сфокусированность на нуждах заказчика
3.Нацеленность на конечный результат
4.Установка на отсутствие дефектов
5.Стремление к самосовершенствованию
6.Заинтересованные команды работают эффективно

18. Ролевая модель управления проектами

это система распределения обязанностей и ответственности,
привязанная не к конкретным людям или должностям, а к ролям –
обобщенным кластерам исполнителей
Управление
выпуском
Управление
продуктом
Удовлетворение
потребителя
Ролевая
модель
MSF
Управление
программой
Тестирование
Разработка
18

19. Microsoft Solutions Framework

В малых проектных группах объединение ролей является необходимым.
При этом должны соблюдаться два принципа:
1.Роль команды разработчиков не может быть объединена ни с какой
другой ролью.
2.Избежание сочетания ролей, имеющих предопределенные конфликты
интересов.
Как и в любой другой командной деятельности, подходящая комбинация
ролей зависит от самих членов команды, их опыта и профессиональных
навыков. На практике совмещение ролей встречается нередко. И если
проектная группа производит его обдуманно и управляет связанными с
таким объединением рисками, возникающие проблемы будут
минимальными.
Как следует из вышесказанного, одна из характерных особенностей MSF
— отсутствие должности менеджера проекта!
Модель проектной группы MSF предлагает разбиение больших команд
(более 10 человек) на малые многопрофильные группы направлений
(feature teams). Эти малые коллективы работают параллельно, регулярно
синхронизируя свои усилия . Кроме того, когда ролевому кластеру
требуется много ресурсов, формируются т. н. функциональные группы
(functional teams), которые затем объединяются в ролевые кластеры.

20. Microsoft Solutions Framework

Ролевые кластеры
1. Управление продуктом. Цель - удовлетворенные заказчики. Область
компетенций – маркетинг, бизнес-отдача (бизнес - приоритеты), представление
интересов заказчика, планирование продукта.
Состав функций: выступает в роли представителя заказчика, формирует общее
видение/рамки проекта, организует работу с требованиями заказчика, развивает
сферы применения в бизнесе, формирует ожидания заказчика, определяет
компромиссы между параметрами «возможности продукта / время / ресурсы»,
организует маркетинг, PR и евангелизацию, разрабатывает, поддерживает и
исполняет план коммуникаций.
2. Управление программой. Цель - достижение результата в рамках проектных
ограничений. Область компетенций –
управление проектом, выработка
архитектуры
решения,
контроль
производственного
процесса,
административные службы.
Состав функций: управляет процессом разработки с целью получения готового
продукта в отведенные сроки, формулирует спецификацию продукта и
разрабатывает его архитектуру, регулирует взаимоотношения и коммуникацию
внутри проектной группы, следит за временным графиком проекта и готовит
отчетность о его состоянии, проводит в жизнь важные компромиссные
решения, разрабатывает, поддерживает и исполняет сводный план и
календарный график проекта, организует управление рисками.

21. Microsoft Solutions Framework

Ролевые кластеры
3. Разработка. Цель - создание продукта в соответствии со спецификацией.
Область компетенций - технологическое консультирование, проектирование и
осуществление
реализации,
разработка
приложений,
разработка
инфраструктуры.
Состав функций: определяет детали физического дизайна, оценивает необходимые
время и ресурсы на реализацию каждого элемента дизайна, разрабатывает или
контролирует разработку элементов, подготавливает продукт к внедрению,
консультирует команду по технологическим вопросам.
4. Тестирование. Цель - одобрение выпуска продукта только лишь после того, как
все дефекты выявлены и улажены. Область компетенций - планирование
тестов, разработка тестов, отчетность по тестам.
Состав функций: обеспечивает обнаружение всех дефектов, разрабатывает
стратегию и планы тестирования, осуществляет тестирование.

22. Microsoft Solutions Framework

Ролевые кластеры
5. Удовлетворение потребителя. Цель - повышение эффективности
пользователя, увеличение потребительской ценности продукта. Область
компетенций - обеспечение технической поддержки, обучение, эргономика,
графический дизайн, интернационализация решения, общедоступность
(обеспечение возможности работы для пользователей с ограниченными
физическими возможностями).
Состав функций: представляет интересы потребителя в команде, организует
работу с требованиями пользователя, проектирует и разрабатывает системы
поддержки производительности, определяет компромиссы, относящиеся к
удобству использования и потребительским качествам продукта, определяет
требования к системе помощи и её содержание, разрабатывает учебные
материалы и осуществляет обучение пользователей.
6. Управление выпуском. Цель - беспроблемное внедрение и сопровождение
продукта. Область компетенций: инфраструктура, сопровождение, бизнеспроцессы, управление выпуском готового продукта.
Состав функций: представляет интересы отделов поставки и обслуживания
продукта, организует снабжение проектной группы, организует внедрение
продукта, вырабатывает компромиссы в управляемости и удобстве
сопровождения продукта, организует сопровождение и инфраструктуру
поставки, организует логистическое обеспечение проектной группы.

23. Microsoft Solutions Framework

Этапы и контрольные точки модели MSF

24. Состав и содержание работ для различных фаз разработки ИС по методологии MSF

1. Этап выработки концепции (envisioning phase)
Управление продуктом
Общие цели проекта; выявление нужд и требований заказчика; документ общего
описания и рамок проекта.
Управление программой
Цели дизайна; концепция решения; структура проекта.
Разработка
Прототипирование;
анализ
технологических
возможностей;
анализ
осуществимости.
Удовлетворение потребителя
Необходимые эксплуатационные характеристики решения и их влияние на его
разработку.
Тестирование
Стратегии тестирования; критерии приемлемости, их влияние на разработку
решения.
Управление выпуском
Требования внедрения и их влияние на разработку решения; требования
сопровождения.

25. Состав и содержание работ для различных фаз разработки ИС по методологии MSF

2. Этап планирования (planning)
Управление продуктом
Концептуальный дизайн; анализ бизнес-требований; коммуникационный план.
Управление программой
Концептуальный и логический дизайн; функциональная спецификация; сводный
план и сводный календарный график проекта; бюджет.
Разработка
Оценка технологий; логический и физический дизайн; план и календарный график
разработки; смета разработки (development estimates).
Удовлетворение потребителя
Сценарии/примеры использования, пользовательские требования, требования
локализации
и
общедоступности
(accessibility);
пользовательская
документация/план обучения/график тестирования удобства эксплуатации;
обучение.
Тестирование
Оценка дизайна; требования тестирования; план и календарный график
тестирования.
Управление выпуском
Оценка дизайна; эксплуатационные требования; план и календарный график
пилотного и окончательного внедрения.

26. Состав и содержание работ для различных фаз разработки ИС по методологии MSF

3. Этап разработки
Управление продуктом
Ожидания заказчика
Управление программой
Управление функциональной спецификацией; мониторинг проекта; доработка
планов.
Разработка
Разработка программного кода и инфраструктуры; документирование
конфигураций.
Удовлетворение потребителя
Обучение; доработка плана обучения; тестирование удобства эксплуатации
(usability testing); графический дизайн.
Тестирование
Функциональное тестирование; выявление проблем; тестирование документации;
доработка плана тестирования.
Управление выпуском
Чеклисты развертывания (rollout checklists); доработка планов внедрения (включая
пилотное внедрение); чеклисты подготовки к внедрению (site preparation
checklists).

27. Состав и содержание работ для различных фаз разработки ИС по методологии MSF

4. Этап стабилизации (опытной эксплуатации)
Управление продуктом
Исполнение коммуникационного плана; планирование премьеры продукта.
Управление программой
Мониторинг проекта; приоритезация ошибок.
Разработка
Устранение ошибок; оптимизация кода.
Удовлетворение потребителя
Доработка эксплуатационных руководств; учебные материалы.
Тестирование
Тестирование; сообщение об ошибках и их статусе; тестирование конфигурации.
Управление выпуском
Развертывание и поддержка пилотного внедрения; планирование внедрения;
обучение персонала сопровождения.

28. Состав и содержание работ для различных фаз разработки ИС по методологии MSF

5. Этап внедрения
Управление продуктом
Получение отзывов и оценок заказчика; акт о приеме выполненной работы.
Управление программой
Сопоставление рамок проекта с поставленным решением; управление
стабилизацией.
Разработка
Разрешение проблем; поддержка эскалации.
Удовлетворение потребителя
Обучение и управление календарным графиком
Тестирование
Тестирование производительности.
Управление выпуском
Управление внедрением; одобрение изменений.

29. Особенности управления ИТ проектами

Главной особенностью ИКТ проектов является наличие как минимум
трёх групп участников проекта с чётко выраженными и часто
различными интересами:
будущие пользователи, для которых создаётся система, включая
руководство подразделений, не подотчётных ИТ службе;
ИТ служба, выступающая представителем заказчика, приёмщиком и в
дальнейшем обязанная поддерживать и развивать систему;
подрядная проектная и внедренческая организация.
Обычно по проекту назначают двух менеджеров — со стороны заказчика и со
стороны подрядчика, тщательно продумывают механизмы преодоления
разногласий.
Для получения качественного проекта рекомендуется проведение
двухступенчатого конкурса: первая ступень — разработка концепции и
ТЗ, вторая — проектирование и реализация. Проблема — потери
времени при синхронизации с графиком бюджетного процесса
29

30. Особенности управления ИТ проектами

Для обеспечения результативности разработок целесообразно:
детально прорабатывать концепцию создаваемой системы и
техническое задание, требования к реализации
широко использовать средства согласования интересов больших групп
людей
четко выполнять архитектурную проработку решений
шире использовать схемы итерационной разработки, делая акцент на
документировании результатов работ в рамках каждой итерации
где это возможно, использовать механизмы быстрой разработки (XP
или SCRUM)
использовать механизм внешней экспертизы
30

31. Организационные формы управления проектированием

При разработке больших проектов применяется выделение, как минимум, четырех
групп специалистов в составе коллектива разработчиков.
Ядро группы системного анализа и проектирования сохраняется и на этапе
реализации (рабочего или техно - рабочего проектирования), на котором
специалисты группы возглавляют группы программистов. Разделение труда в
группе системного анализа и проектирования, как правило, - на основе
пооперационного принципа, а в группе реализации - на основе подсистемного
принципа. Группа выполняет системный анализ, разрабатывает спецификации к
автоматизированной системе, осуществляет проектирование ИС, во время
реализации проекта выполняет контрольные функции и документирование
системы в соответствии с требованиями стандартов.
Группа реализации осуществляет разработку рабочей документации.
Группа тестирования проводит комплексную отладку и приемочные испытания
системы.
Административная группа выполняет технические и административные
функции, включая подготовку проектной документации, контроль
документации, отчетности и т.п.

32. Методики гибкой разработки Agile. Scrum

Основная идея всех гибких моделей заключается в том, что применяемый в
разработке ПО процесс должен быть адаптивным. Они декларируют
своей высшей ценностью ориентированность на людей и их
взаимодействие, а не на процессы и средства. По сути, это набор
практик, которые могут позволить (а могут и нет) добиваться
эффективной разработки ПО, основываясь на итеративности,
инкрементальности, самоуправляемости команды и адаптивности
процесса.
Scrum (толкучка) - одна из самых популярных методик гибкой разработки.
Одна из причин ее популярности - простота. Scrum по-настоящему
прост, его можно описать достаточно коротко.
Роли
В методологии Scrum всего три роли.
Scrum Master
Product Owner
Team

33. Методики гибкой разработки Agile. Scrum

Основа Scrum

34. Методики гибкой разработки Agile. Scrum

Скрам Мастер (Scrum Master) - самая важная роль в методологии. Скрам
Мастер отвечает за успех Scrum в проекте. По сути, Скрам Мастер
является интерфейсом между менеджментом и командой. Как правило,
эту роль в проекте играет менеджер проекта или тимлид. Важно
подчеркнуть, что Скрам Мастер не раздает задачи членам команды. В
Agile команда является самоорганизующейся и самоуправлямой.
Основные обязанности Скрам Мастера таковы:
Создает атмосферу доверия,
Участвует в митингах в качестве фасилитатора
Устраняет препятствия
Делает проблемы и открытые вопросы видимыми
Отвечает за соблюдение практик и процесса в команде
Скрам Мастер ведет Daily Scrum Meeting и отслеживает прогресс команды
при помощи Sprint Backlog, отмечая статус всех задач в спринте.
ScrumMaster может также помогать Product Owner создавать Backlog для
команды

35. Методики гибкой разработки Agile. Scrum

Product Owner - это человек, отвечающий за разработку продукта. Как
правило, это product manager для продуктовой разработки, менеджер
проекта для внутренней разработки и представитель заказчика для
заказной разработки. Product Owner - это единая точка принятия
окончательных решений для команды в проекте, именно поэтому это
всегда один человек, а не группа или комитет.
Обязанности Product Owner таковы:
Отвечает за формирование product vision
Управляет ROI
Управляет ожиданиями заказчиков и всех заинтересованных лиц
Координирует и приоритизирует Product backlog
Предоставляет понятные и тестируемые требования команде
Взаимодействует с командой и заказчиком
Отвечает за приемку кода в конце каждой итерации
Product Owner ставит задачи команде, но он не вправе ставить задачи
конкретному члену проектной команды в течении спринта.

36. Методики гибкой разработки Agile. Scrum

Команда (Team)
Команда является самоорганизующейся и самоуправляемой, берет
обязательства по выполнению объема работ на спринт перед Product
Owner. Вклад отдельных членов проектной команды не оценивается, так
как это разрушает самоорганизацию команды.
Обязанности команды:
Отвечает за оценку элементов баклога
Принимает решение по дизайну и имплементации
Разрабатывает софт и предоставляет его заказчику
Отслеживает собственный прогресс (вместе со Скрам Мастером).
Отвечает за результат перед Product Owner
Типичный размер команды - 7 плюс минус 2. Она кроссфункциональна,
входят люди с различными навыками - разработчики, аналитики,
тестировщики. Нет заранее определенных и поделенных ролей в
команде, ограничивающих область действий членов команды.
Для облегчения коммуникаций команда должна находиться в одном месте
(colocated). Предпочтительно размещать команду не в кубиках, а в одной
общей комнате для того, чтобы уменьшить препятствия для свободного
общения.

37. Методики гибкой разработки Agile. Scrum

Product Backlog - это приоритезированный список имеющихся на данный
момент бизнес-требований и технических требований к системе.
Включает в себя use cases, defects, enhancements, technologies, stories,
features, issues, и т.д., а также задачи, важные для команды, например
"провести тренинг", "добавить всем памяти".
Product Backlog постоянно пересматривается и дополняется - в него
включаются новые требования, удаляются ненужные, пересматриваются
приоритеты. За Product Backlog отвечает Product Owner. Он также
работает совместно с командой для того, чтобы получить
приближенную оценку на выполнение элементов Product Backlog для
того, чтобы более точно расставлять приоритеты в соответствии с
необходимым временем на выполнение.
Sprint Backlog содержит функциональность, выбранную Product Owner из
Product Backlog. Все функции разбиты по задачам, каждая из которых
оценивается командой. Каждый день команда оценивает объем работы,
который нужно проделать для завершения задач.Сумма оценок
оставшейся работы может быть построена как график зависимости от
времени. Такой график называется Sprint Burndown chart. Он
демонстрирует прогресс команды по ходу спринта.

38. Методики гибкой разработки Agile. Scrum

Пример Product Backlog

39. Методики гибкой разработки Agile. Scrum

Пример Spint Backlog

40. Методики гибкой разработки Agile. Scrum

Спринт (Sprint)
В Scrum итерация называется Sprint. Ее длительность составляет 1 месяц
(30 дней).
Результатом Sprint является готовый продукт (build), который можно
передавать (deliver) заказчику (по крайней мере, система должна быть
готова к показу заказчику).
Короткие спринты обеспечивают быстрый feedback проектной команде от
заказчика. Заказчик получает возможность гибко управлять scope
(рамками) системы, оценивая результат спринта и предлагая улучшения
к созданной функциональности. Такие улучшения попадают в Product
Backlog, приоритезируются наравне с прочими требованиями и могут
быть запланированы на следующий (или на один из следующих)
спринтов.
Каждый спринт представляет собой маленький "водопад". В течение
спринта делаются все работы по сбору требований, дизайну,
кодированию и тестированию продукта.
Scope спринта должен быть фиксированным. Это позволяет команде давать
обязательства на тот объем работ, который должен быть сделан в
спринте. Это означает, что Sprint Backlog не может быть изменен никем,
кроме команды.

41. Методики гибкой разработки Agile. Scrum

Пример Sprint Burndown chart

42. Жизненный цикл спринта

Планирование спринта
В планировании спринта участвуют заказчики, пользователи, менеджмент,
Product Owner, Скрам Мастер и команда. Планирование состоит из двух
последовательных митингов.
Планирование спринта, митинг первый
Участники: команда, Product Owner, Scrum Master, пользователи,
менеджемент
Цель: Определить цель спринта (Sprint Goal) и Sprint Backlog функциональность, которая будет разработана в течение следующего
спринта для достижения цели спринта.
Артефакт: Sprint Backlog
Планирование спринта, митинг второй
Участники: Скрам Мастер, команда
Цель: определить, как именно будет разрабатываться определенная
функциональность для того, чтобы достичь цели спринта. Для каждого
элемента Sprint Backlog определяется список задач и оценивается их
продолжительность.
Артефакт: в Sprint Backlog появляются задачи

43. Методики гибкой разработки Agile. Scrum

Остановка спринта (Sprint Abnormal Termination)
Остановка спринта производится в исключительных ситуациях.
Инициаторы: команда, если понимает, что не может достичь цели
спринта в отведенное время; Product Owner, если необходимость в
достижении цели спринта исчезла. После остановки проводится митинг
с командой, где обсуждаются причины остановки, и начинается новый
спринт: производится его планирование и стартуются работы.
Daily Scrum Meeting
Проходит каждое утро в начале дня для того, чтобы все члены команды
знали, кто и чем занимается в проекте. Длительность не должна
превышать 15 минут. Цель - поделиться информацией. Он не
предназначен для решения проблем в проекте. Все требующие
специального обсуждения вопросы должны быть вынесены за пределы
митинга. Митинг проводит Скрам Мастер. Он по кругу задает вопросы
каждому члену команды
Что сделано вчера?
Что будет сделано сегодня?
С какими проблемами столкнулся?
Скрам Мастер собирает все открытые для обсуждения вопросы в виде
Action Items, например в формате что/кто/когда.

44. Методики гибкой разработки Agile. Scrum

Демо и ревью спринта
Рекомендованная длительность: 4 часа
Команда демонстрирует инкремент продукта, созданный за последний
спринт. Product Owner, менеджмент, заказчики, пользователи, в свою
очередь, его оценивают. Команда рассказывает о поставленных задачах,
о том как они были решены, какие препятствия были у них на пути,
какие были приняты решения, какие проблемы остались нерешенными.
На основании ревью принимающая сторона может сделать выводы о
том, как должна дальше развиваться система. Участники миитинга
делают выводы о том, как шел процесс в команде и предлагает решения
по его улучшению.
Скрам Мастер отвечает за организацию и проведение этого митинга.
Команда помогает ему составить адженду и распланировать кто и в
какой последовательности что представляет.
Подготовка к митингу не должна занимать у команды много времени
(правило - не более двух часов). В частности, именно поэтому
запрещается использовать презентации в Power Point. Подготовка к
митингу не должна занимать у команды более 2-х часов.

45. ГОСТ Р ISO 21500:2014 «Руководство по проектному менеджменту»

Стандарт устанавливает принципы и процедуры, образующие
передовой опыт управления проектами. Менеджеры проектов
смогут использовать этот стандарт в качестве руководства по
повышению успеха проектов и достижения бизнес-результатов.
Применение стандарта ISO 21500 обеспечивает:
стимулирование
обмена
знаниями
между
проектами
организациями для улучшения реализации проектов
и
обеспечение эффективных процедур проведения тендеров с
помощью единой терминологии управления проектами
обеспечение гибкости привлечения сотрудников по управлению
проектами и возможности работы в международных проектах
описание универсальных принципов и процедур управления
проектами

46. ГОСТ Р ISO 21500:2014 «Руководство по проектному менеджменту»

ISO 21500 – первый стандарт серии по управлению проектами. Он
предназначен
для
согласования
с
сопутствующими
международными стандартами, такими как:
ISO 10006:2003 «Системы менеджмента качества. Руководство по
управлению качеством в проектах»,
ISO 10007:2003 «Системы менеджмента качества. Руководство по
управлению конфигурациями»,
ISO 31000:2009 «Управление рисками. Принципы и руководство»,
а также со специализированными отраслевыми стандартами,
например, для авиакосмической, атомной промышленности или
ИТ.
В отличие от продуктов PMI, международный стандарт более
краток и удобен для начинающих.

47. ГОСТ Р ISO 21500:2014 «Руководство по проектному менеджменту»

Распределение процессов по группам по ГОСТ 21500:2014:
Инициирование (3)
Планирование (16)
Исполнение (7)
Контроль (11)
Завершение (2)

48. ГОСТ Р ISO 21500:2014 «Руководство по проектному менеджменту»

Распределение процессов по Областям знания:
Управление интеграцией (7)
Управление содержанием (4)
Управление сроками (4)
Управление стоимостью (3)
Управление качеством (3)
Управление человеческими ресурсами (6)
Управление коммуникациями (3)
Управление рисками (4)
Управление заинтересованными сторонами (2)
Управление закупками (3)

49. ГОСТ Р 57101—2016/ISO/IEC/IEEE 16326:2009 Системная и программная инженерия. ПРОЦЕССЫ ЖИЗНЕННОГО ЦИКЛА. Управление проектом

Дата введения — 2017—09—01
Настоящий стандарт предназначен для помощи руководителям
проектов в управлении для успешного ведения проектов,
касающихся программных средств и систем. Настоящий
стандарт
определяет
необходимое
содержание
плана
управления проектом (ПУПРП). Этот стандарт также
формулирует цели и содержание результатов процессов проекта
согласно ИСО/МЭК 12207:2008 (ИИЭР 12207:2006) и ИСО/МЭК
15286:2008 (ИИЭР 15288:2008) и добавляет детальные
положения для управления проектами. в которых используются
эти процессы.

50. Управление коммуникациями проекта

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

51. Управление рисками проекта

Неопределенность ― это неполнота или неточность информации об условиях
реализации проекта, в том числе связанных с ними затратах и результатах.
Риск ― потенциальная, численно измеримая возможность неблагоприятных
ситуаций и связанных с ними последствий в виде потерь, ущерба, убытков в
связи с неопределенностью, т.е. со случайным изменением условий
экономической деятельности, неблагоприятными, в том числе форсмажорными обстоятельствами, общим падением цен на рынке; возможность
получения непредсказуемого результата в зависимости от принятого
хозяйственного решения, действия.
Измерение рисков ― определение вероятности наступления рискового события.
Степень допустимых рисков, как правило, определяется с учетом таких
параметров, как размер и надежность инвестиций в проект, запланированный
уровень рентабельности и др.
Управление рисками ― совокупность методов анализа и нейтрализации
факторов рисков, объединенных в систему планирования, мониторинга и
корректирующих воздействий.

52. Процесс управления рисками проекта

Стадии процесса:
Выявление и идентификация предполагаемых рисков
Анализ и оценка рисков
Выбор методов управления риском
Применение выбранных методов и принятие решений в условиях рисков
Реагирование на наступление рискового события
Разработка и реализация мер снижения рисков
Контроль, анализ и оценка действий по снижению рисков и выработка решений
Методы управления рисками:
Разработка и реализация стратегии управления рисками
Методы компенсации рисков, включающие прогнозирование внешней среды
проекта, маркетинг проектов и продуктов проекта, мониторинг социальноэкономической и правовой среды и создание системы резервов проекта
Методы локализации рисков, применяемые для высокорисковых проектов в
многопроектной системе, подразумевающие создание отдельных специальных
подразделений для реализации особо рисковых проектов
Методы ухода от рисков, включающие отказ от рискованных проектов и
ненадежных партнеров, страхование рисков, поиск гарантов

53. Процесс управления рисками проекта

Методы анализа и оценки рисков:
- Анализ чувствительности
- Проверка устойчивости
- Определение точки безубыточности
- Корректировка параметров проектов
- Формализованное описание неопределенности
- Анализ сценариев
- Метод Монте-Карло
- Метод построения «дерева решений» и пр.
Последовательность работ по анализу рисков:
- Подбор опытной команды экспертов
- Подготовка специального вопросника и встречи с экспертами
- Выбор техники анализа рисков
- Установление факторов рисков и их значимости
- Создание модели механизма действия рисков
- Установление взаимосвязи отдельных рисков и совокупного эффекта от их
воздействия
- Распределение рисков между участниками проекта
- Рассмотрение результатов анализа рисков – обычно в форме специально
подготавливаемого отчета (доклада)

54. Выбор системы управления проектами

Для поддержки различных управленческих задач используются различные
программные средства.
1. Для укрупненного описания и анализа проекта на прединвестиционной стадии в
большей степени подходит специализированное ПО анализа проектов,
которое позволяет выполнить оценки основных показателей рентабельности
проекта в целом и обосновать эффективность капиталовложений. Примером
системы для анализа проектов является хорошо известная на российском рынке
программа Project Expert фирмы PRO-INVEST-Consulting.
Необходимо отметить, что для описания плана инвестиций в Project Expert
используются традиционные подходы сетевого планирования, предполагающие
разбиение проекта на комплекс взаимозависимых задач и описание требуемых
для их выполнения ресурсов. В Project Expert реализованы Gantt- и PERTдиаграммы.
2. Если управление проектами в организации не завершается обоснованием
инвестиций и существует потребность в контроле за ходом реализации проекта,
то необходимо переходить к использованию ПО управления проектами.
Следует отметить, что Project Expert имеет возможность обмена данными с
пакетами управления проектами MS Project и Time Line.

55. Выбор системы управления проектами

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

56.

Выбор системы управления проектами
Примеры инструментов управления проектами (PCS):
MS Project,
Time Line,
Primavera Project Planner Professional,
Artemis Views
Collabtive 0.4.5,
ProjectLibre,
1С: Управление Проектным Офисом,
IBS Project Center,
ИНТАЛЕВ: Корпоративные проекты
Spider Project и ряд других.

57.

Системы УП решают следующие задачи:
разработку расписания исполнения проекта без учета ограниченности
ресурсов;
разработку
расписания исполнения проекта с учетом ограниченности
ресурсов (leveling);
определение критического пути и резервов времени исполнения операций
проекта;
определение
потребности проекта в финансировании, материалах и
оборудовании;
определение
распределения во времени загрузки возобновляемых
ресурсов;
анализ рисков и планирование расписания с учетом рисков;
учет исполнения проекта;
анализ отклонений хода работ от запланированного и прогнозирование
основных параметров проекта.

58. Базовые функциональные возможности систем УП

Средства поддержки информации о ресурсах и затратах по проекту и назначения ресурсов и затрат
по отдельным работам над проектом:
1. Ведение списка наличных ресурсов, возможность задания нормального и максимального объемов
ресурса.
2. Поддержка ресурсов с фиксированной стоимостью и ресурсов, стоимость которых зависит от
длительности их использования.
3. Расчет требуемых объемов ресурсов.
4. Ресурсное планирование (выделение перегруженных ресурсов и использующих их задач,
автоматическое/командное выравнивание профилей загрузки ресурсов с учетом ограничений, с
учетом приоритетов задач).
Средства контроля за ходом выполнения проекта:
1. Средства отслеживания состояния задач проекта.
2. Средства контроля за фактическим использованием ресурсов (бюджетное количество и стоимость
ресурса, фактическое количество и стоимость ресурса, количество и стоимость ресурсов,
требуемых для завершения работы).
Графические средства:
1. Диаграмма Гантта (часто совмещенная с электронной таблицей и позволяющая отображать
различную дополнительную информацию).
2. PERT-диаграмма (сетевая диаграмма).
3. Средства создания необходимых для планирования отчетов (отчет по состоянию выполнения
расписания, отчеты по ресурсам и по назначению ресурсов, профиль ресурса, отчет по стоимости).

59. Недостатки систем УП

Общим недостатком рассмотренных продуктов с точки зрения
планирования трудоёмкости проекта является отсутствие встроенных
средств определения трудоемкости работ за исключением
экспертной оценки руководителя проекта, которая выполняется вне
системы, а результат в виде детерминированного значения
записывается в соответствующее свойство работы. Ряд продуктов
допускает расширение набора свойств при описании работ,
соответственно, можно использовать и вероятностные оценки.
Разработчики СУП не включают в них калькуляторы трудоёмкости,
чтобы не ограничивать универсальность продукта, поскольку для разных
отраслей и видов работ существуют различные методики оценки
трудоёмкости работ. Однако, оперативно определить общую
трудоёмкость проекта и трудоёмкости отдельных работ на основе
признанных в отрасли методов и норм для руководителя проекта бывает
важно не только во взаимоотношениях с заказчиком, но и с командой
проекта.

60. Традиционный подход к организации управления ИТ

Среди различных подсистем предприятия организуется и развивается
подсистема информационно-технологического обеспечения и её
программно-аппаратная и ресурсная компонента, представляемая под
названиями АИС, АСУП, АСОУ и т. п.
ИТ служба при этом играет роль равноправного среди других структур
подразделения, достаточно обособленного в плане организации
деятельности и способного проводить относительно независимую от
пользователей техническую политику. Организационно это может
быть ВЦ, ИВЦ, отдел АСУП и т.п., подчиняющийся обычно главному
инженеру, реже – заместителю по экономике. Вычислительный ресурс,
как и все другие, распределяется централизованно, и тот, кто владеет
им, может на равных участвовать в диалоге с другими структурами.
Подразделение-владелец ИТ ресурса кровно заинтересовано в удобстве
владения им – большей технологичности поддержки и развития, и
только во вторую очередь – в эффективности использования ресурса
другими службами. При таком подходе ИТ службы вовлечены в гонку
технологий, не имея чёткого ориентира в области экономической и
управленческой целесообразности капитальных вложений.

61. Традиционный подход к организации управления ИТ

С развитием персональных вычислений широкое развитие получили
децентрализованные
по
структурным
подразделениям
информационные системы. Этому способствовала, помимо технических
аспектов, и совпавшая по времени общая децентрализация (или хаос) в
управлении предприятием. В условиях перманентного дефицита
финансовых средств и отсутствия прямой видимой зависимости
текущего результата деятельности предприятия в рыночной стихии от
автоматизации управления центр тяжести автоматизации сместился на
офисные технологии и создание имиджа их обладателей.

62.

Современные подходы к организации управления ИТ
Новые подходы к организации управления ИТ основаны на концепции
предоставления услуг ИТ службой основным подразделениям,
являющимся обычно владельцами ИТ активов. Информационнотехнологическая
услуга
является
основным
продуктом
ИТ
инфраструктуры и протекающих в ней процессов. Предполагается, что
между пользователями и ИТ службой существуют формализованные
соглашения об уровне предоставления этих услуг (Service Level
Agreement - SLA), который должен иметь чёткие объективные
измерители и процедуры измерения и устранения разногласий. Каждая
услуга имеет свою стоимость, которая компенсируется пользователем за
счёт отведённого ему бюджета. Предоставление ИТ услуг
обеспечивается соответствующими каждому виду услуги деловыми и
технологическими процессами

63. Организация предоставления ИТ услуг

Стандарты организации управления ИТ инфраструктурой:
COBIT® (Control Objectives for Information and related Technology,
http://www.isaca.ru);
CMMI® (Capability Maturity Model Integration);
Библиотека инфраструктур ИТ ITIL (Information Technology
Infrastructure Library);
ISO/IEC 20000:2005 (International Standardization Organization, IT
Service Management, части 1 и 2). ГОСТ Р ИСО/МЭК 20000:2010
"Информационная
технология.
Менеджмент
услуг",
состоящий из двух частей (Часть 1. "Спецификация", Часть 2.
"Кодекс практической деятельности") содержит детальные
рекомендации по управлению процессами предоставления ИТ
услуг.;
Методология ITSM фирмы НР;
Методология управления ИТ инфраструктурой Microsoft Operations
Framework (MOF);
ISO/IEC 38500 (International Standardization Organization, IT
Governance).

64.

Библиотека ITIL
Основой многих стандартов и решений в области ИТ-управления стала
ITIL — Information Technology Infrastructure Library. Начиная с 1986
года Британское агентство правительственной связи (CCTA) вело работы
по формализации и стандартизации методов внедрения и эксплуатации
ИТ-систем в различных правительственных ведомствах в рамках
некоммерческой программы. Накапливаемый в процессе этой работы
опыт формулировался в «библиотеке IT-инфраструктур». Спустя 10 лет
документация, объединяющая эти методики, стала доступна всем. 30 мая
2007 года Правительство GB объявило о выходе третьей версии
библиотеки.
ITIL — это описание модели жизненного цикла ИТ организации, примеры
реализации и комментарии специалистов. Подход ITIL заключается в
разделении процесса управления ИТ на несколько дисциплин,
каждая из которых нацелена на решение определенных круга функций.
ITIL предлагает структурированный подход к разработке, внедрению и
эксплуатации каждой дисциплины.
Ключевая концепция ITIL — управление сервисом. Управление
сервисом включает множество процедур, позволяющих быстро и
эффективно формулировать, изменять и контролировать определенные
для каждого пользователя уровни сервиса по заранее заданным
критериям и параметрам функционирования системы.

65.

Библиотека ITIL
В Библиотеке рассматриваются типовые модели, которые описывают
цели, основные активности, входы и выходы разнообразных процессов,
подлежащих внедрению в ИТ-подразделении. Таким образом, ITIL
предоставляет подтвержденные практикой методы планирования
процессов, ролей и активностей с перечислением их взаимосвязей и
взаимозависимостей.
Разделы библиотеки:
Стратегия услуг (Service Strategy);
Проектирование услуг (Service Design);
Преобразование услуг (Service Transition);
Эксплуатация услуг (Service Operation);
Постоянное улучшение услуг (Continual Service Improvement).
Эти
группы
процессов
структурированы
в
виде
иерархии,
представляющей ядерную, или «луковичную» модель: в центре ядра —
процессы управления стратегией предоставления сервисов, Service
Strategy, вокруг них три сегмента: Service Design, Service Transition, Service
Operation, процессы группы Continual Service Improvement окружают
конструкцию снаружи.
Значительное внимание в методологии уделено описанию моделей
информационных
ресурсов,
используемых
в
управлении
ИТ
инфраструктурой, и ролей ИТ специалистов и менеджеров. В этой версии

66.

Библиотека ITIL
Жизненный цикл ИТ сервиса по методологии ITIL

67.

Библиотека ITIL
Сегмент Service Strategy.
Модели:
Delivery Model (Модель предоставления услуг);
Service Model (Модель услуги).
Процессы:
Service Portfolio Management (Управление портфелем услуг);
Demand management (Управление требованиями);
Financial Management (Управление финансами).
Сегмент Service Design.
Модели:
Service Portfolio (Портфель услуг);
Service Catalogue (Каталог услуг).
Процессы:
Service Catalogue Management (Управление Каталогом услуг);
Service Level Management (Управление уровнем услуг);
Supplier Management (Управление поставщиками);
Availability Management (Управление доступностью);
Information Security Management (Управление безопасностью
информации);
Capacity Management (Управление мощностями);
IT Service Continuity Management (Управление непрерывностью).

68.

Библиотека ITIL
Сегмент Service Transition.
Модели:
V-модель;
Модель DIKW;
Service Knowledge Management System, SKMS (Система управления
знаниями);
Configuration Item (Конфигурационная единица);
Configuration Management System (CMS);
Definitive Media Library (DML).
Процессы:
Knowledge Management (Управление знаниями);
Change Management (Управление изменениями);
Service Asset and Configuration Management (Управление активами и
конфигурациями);
Release and Deployment Management (Управление релизами и
развёртыванием).

69.

Библиотека ITIL
Сегмент Service Operation.
Функции:
Функция Service Desk;
Функция Technical Management;
Функция Application Management;
Функция IT Operations Management.
Процессы:
Event management (Управление событиями);
Incident Management (Управление инцидентами);
Request Fulfillment (Выполнение запросов на обслуживание);
Problem Management (Управление проблемами);
Access Management (Управление доступом).
Continual Service Improvement (Непрерывное улучшение качества
услуг) The 7-Step Improvement Process (7 шагов измерения и улучшения)
Цикл Деминга (PDCA: план — действие — контроль - анализ)

70.

Стандарт BS ISO/IEC 20000-1:2005
Определены 13 важнейших процессов, собранных в пять ключевых групп:
1. Процессы оказания услуг (Service delivery process). В группу входят
управление уровнем услуг (Service level management), управление
доступностью (Service continuity and availability management) и управление
возможностями сервисов (Capacity management);
2. Процессы взаимоотношений (Relationship processes). Эта область
включает в себя связи и отношения между поставщиком услуг, клиентом и
подрядными организациями;
3. Процессы решения проблем (Resolution processes). Разработчики
стандарта фокусируются на инцидентах, которые удалось предотвратить
или успешно разрешить;
4. Процессы контроля (Control processes). В данном разделе
рассматриваются процессы управления изменениями, активами и
конфигурациями;
5. Процессы релиза (Release process). Речь идет о выработке новых и
коррекции уже имеющихся решений.
Кроме того, выдвигаются требования к мере ответственности
руководителей компании, предоставляющей ИТ-услуги, а также к
управлению документацией, компетенции, осведомленности и подготовке
персонала.

71.

Стандарт BS ISO/IEC 20000-1:2005
Процессы ISO/IEC 20000

72. Методология Microsoft Operations Framework

Корпорация Microsoft в 2000 году предложила опирающуюся на ITIL
методологию управления ИТ инфраструктурой Microsoft
Operations Framework (MOF). В базовую методологию ITIL при
разработке MOF внесены существенные дополнения и
изменения, которые позволяют использовать ее в гетерогенных
средах. MOF, наряду с Microsoft Solutions Framework (MSF) и
Microsoft Readiness Framework (MRF), является одной из
составляющих инициативы Microsoft Enterprise Services. Каждая
из методологий позволяет управлять информационной системой
на определенной стадии ее развития. MOF фокусируется на
эксплуатации информационной системы, MSF — на ее
построении и внедрении, а MRF —на стадии подготовки и
обеспечения готовности. Для стадии планирования у корпорации
нет четко оформленной методологии; предлагается только ряд
средств и служб, систематизирующих процессы, которые
протекают в информационной системе на этой стадии.
С 2009 года поддерживается модель MOF v4.0

73. Методология Microsoft Operations Framework

Жизненный цикл сервиса по модели MOF 4.0

74. Методология Microsoft Operations Framework

Ядро управления жизненным циклом услуги согласно MOF 4.0
состоит из трёх фаз: планирования (Plan), развертывания
(Deliver)
и
операционной
деятельности
(Operate),
базирующихся на процессах одного общего уровня – уровня
управления (Manage).
Основные SMF функции фазы планирования (Plan):
- функция согласования бизнеса и ИТ (Business/IT Alignment SMF);
- функция обеспечения надёжности (Reliability SMF);
- функция управления политиками (Policy SMF);
- функция управления финансами (Financial Management SMF).
Основные SMF функции фазы развертывания (Deliver):
- функция ознакомления (Envision SMF);
- функция проектного планирования (Project Planning SMF);
- функция создания (Build SMF);
- функция стабилизации условий выполнения услуги (Stabilize
SMF);
- функция размещения (Deploy SMF).

75. Методология Microsoft Operations Framework

Основные SMF функции фазы операционной деятельности
(Operate):
- функция операционной деятельности (Operations SMF);
- функция мониторинга и управления сервисом (Service Monitoring
and Control SMF);
- функция поддержки пользователей (Customer Service SMF);
- функция управления проблемами (Problem Management SMF).
Основные SMF функции уровня управления (Manage):
- функции взаимодействия с государственными органами,
управления
рисками
и
обеспечения
законопослушности
Governance, Risk, and Compliance SMF;
- функции управления изменениями и поддержки конфигурации
(Change and Configuration SMF);
- функция команды (Team SMF).

76. Методология ITSM от HP

Типовая модель НР ITSM-2003

77. Методология ITSM - развитие

Современноё состояние развития темы можно наблюдать на
различных
сайтах,
в
частности:
http://www.itsmonline.ru/phparticles/show_news1.php

78. «Горизонтальные» и «вертикальные» сервисы

Базовый набор «горизонтальных» ИТ сервисов:
1. диспетчирование заявок и консультирование пользователей;
2. обеспечение доступа в сеть Интернет;
3. обеспечение работы электронной почты (внутренней и Интернет);
4. обеспечение работы пользователей в правовых БД и с другими информационными
ресурсами коллективного пользования;
5. поддержка формирования и ведения автоматизированных информационных ресурсов
(АИР) пользователей;
6. поддержка технологий обработки информации пользователей (по конкретным
программным продуктам);
7. поддержка комплекса технических и системных программных средств пользователей;
8. антивирусная защита ИТ активов;
9. подготовка пользователей к применению автоматизированных ИТ и другие.
Примеры «вертикальных» сервисов:
1. консалтинговые услуги в области организации управления и использования ИТ в
управлении предприятием;
2. разработка концепции, стратегии, программы и проектов развития автоматизированной
системы предприятия и экспертиза проектных материалов;
3. выполнение функций заказчика по программам и проектам информатизации;
4. подготовка сводных заявок и контроль использования средств на информатизацию;
5. обеспечение учёта и инвентаризации ИТ активов предприятия;
6. централизованное управление лицензиями на ПО и ИР;
7. поставка оргтехники, ПО и расходных материалов;
8. обеспечение автоматизации делопроизводства и документооборота, других
централизованных управленческих функций
9. обеспечение необходимой живучести АСУ при чрезвычайных ситуациях и другие.

79.

Основные разделы SLA:
заказчик и исполнитель работ;
нормативные документы, определяющие существенные аспекты предоставления сервиса;
определение предоставляемого сервиса и основных его элементов с выделением
используемых ресурсов;
стороны, вовлеченные в соглашение;
сроки действия соглашения;
точки контакта;
связанные сервисы, влияющие на качество предоставления данного сервиса и наоборот;
примерный график предоставления сервиса;
число и размещение пользователей и оборудования, использующих сервис;
спецификации целевых уровней качества сервиса, измерители уровней качества и их
пороговые значения
методики расчета метрик качества элементов сервиса;
порядок и частота представления отчетов, краткое содержание отчёта об объёме и качестве
сервиса с указанием приёмщика работ;
действия и ответственность сторон при использовании сервиса и порядок разрешения
споров.

80. Генеральное соглашение о комплексе предоставляемых услуг

Между администрацией предприятия и ИТ службой может заключаться
генеральное соглашение о комплексе предоставляемых услуг,
содержащее основной перечень услуг, основные показатели их
объёма и качества, перечень и размещение автоматизированных
рабочих мест, общие условия их предоставления, формы и размеры
обеспечения деятельности ИТ службы, процедуры согласования и
устранения противоречий и проч.
Важной частью соглашения является чёткое описание прав и процедур
владения и распоряжения ИТ активами, например: «Исполнитель по
поручению Заказчика организует получение счетов для оплаты
приобретаемых ИТ активов и участвует в их приёмке. Получение,
доставку и бухгалтерский учёт ИТ активов производит Заказчик.
Исполнитель ведёт технологический учёт ИТ активов, необходимый
для организации их оперативной технической поддержки...»
Следующий раздел Генерального соглашения – финансовые условия
предоставления услуг.

81. Генеральное соглашение о комплексе предоставляемых услуг

«Обязанности Заказчика:
1. В течение всего срока действия Соглашения Заказчик обязан
соблюдать требования руководств по эксплуатации оборудования,
программного обеспечения и действующие лицензионные соглашения.
2. Заказчик определяет и предоставляет Исполнителю перечень лиц,
ответственных за использование и развитие информационных
технологий в своих структурных подразделениях и уполномоченных
на размещение заказов, прием и передачу компьютерного
оборудования. Заказчик вправе изменять перечень уполномоченных
лиц, с обязательным переоформлением и предварительным
уведомлением Исполнителя.
3. Заказчик обязуется обеспечить представителям Исполнителя
беспрепятственный доступ к компьютерному и сетевому
оборудованию. На руководителей и специалистов Исполнителя,
которым необходим доступ к ИТ активам, содержащим информацию
ограниченного распространения, Заказчик оформляет необходимые
режимные документы

82. Генеральное соглашение о комплексе предоставляемых услуг

4. Заказчик планирует, создаёт и поддерживает за счёт собственных
средств
необходимые
резервы
технологических
и
телекоммуникационных мощностей, компьютерного оборудования,
комплектующих и расходных материалов, резервные копии
информационных ресурсов и средств их ведения, планирует и
осуществляет мероприятия по их использованию.
5. Заказчик обязан своевременно извещать Исполнителя о возникающих
изменениях в размещении оборудования, составе информационных
ресурсов и систем, обеспечить выполнение необходимых погрузочноразгрузочных и транспортных работ при их поставке и перемещениях,
а также оформление необходимых сопроводительных документов.
6.
Заказчик
предоставляет
Исполнителю
рабочие
места,
оборудованные необходимой компьютерной техникой и программным
обеспечением для администрирования локальных сетей и баз данных,
а также помещения для ведения склада комплектующих и расходных
материалов и архивов программного обеспечения и технической
документации.
7. Заказчик обязан обеспечить достаточный для самостоятельной работы
с компьютерной техникой уровень подготовки пользователей.

83. Генеральное соглашение о комплексе предоставляемых услуг

Обязанности Исполнителя:
1. Исполнитель гарантирует предоставление услуг по соглашению в
объеме, в сроки и с качеством, которые определяются
дополнительными соглашениями об уровне конкретных сервисов.
2. Исполнитель организует учёт и представление Заказчику в
согласованные сроки регулярной отчётности по объёмам и качеству
предоставленных услуг.
3. Исполнитель обязуется соблюдать конфиденциальность сведений
Заказчика, ставших известными специалистам Исполнителя в связи с
выполнением ими работ по настоящему соглашению, при
соответствующем официальном предуведомлении уполномоченными
лицами Заказчика о конфиденциальности конкретной информации на
конкретных носителях.
4. Исполнитель обязуется принимать все возможные меры для
сохранения целостности и доступности ИТ активов Заказчика и
незамедлительно уведомлять последнего о возникших угрозах.

84. Генеральное соглашение о комплексе предоставляемых услуг

Далее следует описание общих процедур предоставления услуг,
например:
«1. Услуги предоставляются по согласованным Сторонами планам и
графикам работ, а также по заявкам пользователей и
уполномоченных Заказчиком лиц.
2. Заявки пользователей и уполномоченных Заказчиком лиц подлежат
регистрации Исполнителем: устные - в оперативном журнале (базе
данных) диспетчерской службы Исполнителя, письменные – там же и в
соответствии с правилами делопроизводства. Заявителю сообщается
регистрационный номер заявки, а в случае длительного исполнения
периодически представляется информация о ходе выполнения заявки.
На заявки, требующие выхода специалистов Исполнителя к Заказчику,
оформляется наряд на выполнение работ (форма заказа-наряда
представлена в Приложении к соглашению).

85. Генеральное соглашение о комплексе предоставляемых услуг

3. Работы, необходимые для выполнения заявки, производятся в
соответствии с сервисным соглашением на рабочем месте заявителя
или, если того требует обстановка и технология – на площадях
Исполнителя
или
специализированных
организаций.
Время
выполнения работ согласуется с заявителем.
4. По факту выполнения работ составляется акт, один экземпляр
которого передается уполномоченному Заказчиком лицу в структурном
подразделении. В акте отображаются характеристики объекта,
описание заявки и выявленной проблемы, перечень выполненных
работ и замененных компонент. Акт скрепляется подписями заявителя,
исполнителя и уполномоченных представителей Сторон.
5. Все работы фиксируются в учетной карточке единицы оборудования,
один экземпляр которой хранится у Исполнителя, а другой – у
уполномоченного лица в структурном подразделении Заказчика, и
заверяются подписями представителей Сторон».

86. Генеральное соглашение о комплексе предоставляемых услуг

Не должна остаться без внимания и процедура решения проблем по
уровню сервиса, например:
«При возникновении проблем, которые могут привести к снижению
качества услуг ниже определённого дополнительным соглашением об
уровне сервиса и не устранимы в оперативном режиме, Сторона,
выявившая проблему, в письменном виде извещает об этом другую
Сторону и организует совещание с участием уполномоченных
представителей Сторон для определения мер по решению проблемы.
Если предусмотренных настоящим соглашением полномочий и
ресурсов Сторон не достаточно для адекватного и взаимоприемлемого
решения проблемы, разрабатывается программа мер, направленных
на решение проблемы, и вместе с протоколом о временном изменении
уровней сервиса представляется на утверждение Сторон».

87. Генеральное соглашение о комплексе предоставляемых услуг

Далее следует процедура направления и рассмотрения запросов на
изменение и процедура приёмки сервиса и оценки его качества,
например, путём утверждения руководителем ежемесячных и годовых
отчётов Исполнителя об объёме и качестве предоставленных услуг. В
отчётах обычно приводятся данные о выполнении объёмных и
качественных показателей услуг, состоянии ИТ активов Заказчика. В
случае возникновения расхождения в оценках производится разбор
спорных ситуаций на совещании у вышестоящего руководителя. Если
в течение недели со дня представления отчёта к нему не предъявлено
замечаний, сервисы считаются принятыми с заявленными объёмом и
качеством работ.
Отдельно прописывается процедура разрешения разногласий, связанных
с предоставлением сервиса. Наконец, в прочих условиях указывают
срок действия соглашения, процедуры и условия его расторжения
или пролонгации.

88. Организация предоставления ИТ услуг

После заключения соглашений об уровне сервиса следует выстраивание
внутренних процессов предоставления услуг в ИТ службе, расчёт и
балансирование мощностей обслуживания, выделение звена оперативного
диспетчирования и контроля, решение проблем кадрового и материальнотехнического обеспечения, постоянное развитие отношений с заказчиком.
Предоставление ИТ услуг обеспечивается соответствующими каждому виду
услуги деловыми и технологическими процессами. Современная
организация управления предполагает наличие и использование моделей ИТ
процессов, которые детализируются по видам услуг или по стадиям
жизненного цикла.
Чтобы экономически оправданно и обоснованно построить стратегию
развития IT в компании, определить, какие информационные технологии
нужны для бизнеса, какими IT-сервисами должны быть обеспечены бизнесподразделения, какой уровень этих IT-сервисов, предоставляемых ITдепартаментом, им необходим, какие для этого требуются ресурсы и как
наладить контроль обеспечения необходимого уровня IT-сервисов
производится моделирование управления ИТ. В результате моделирования
появляется и организационная структура ИТ службы, включая основные
роли персонала и их распределение по штатным единицам, должностные
инструкции и регламенты работников (функции и требования к уровню
знаний и навыков, ответственность, подчинённость и проч.).

89. Специализация подразделений ИТ служб

Варианты специализации:
по группам пользователей, подразделений - приближает ИТ к нуждам конечных
пользователей, но чревато более поверхностным уровнем решения ИТ
проблем;
по видам технологий (которые автоматизируют) - позволяет более
профессионально решать технические проблемы, но требует серьёзной
координации работ между ИТ специалистами
по компонентам системы (функциональная): железо, ПО, сети, часто в сочетании
одного с другим в рамках системы.
В крупных организациях ИТ служба имеет, как правило, программистские,
технические и сетевые подразделения с выделением группы системных
администраторов. Службы защиты информации обычно являются
независимыми от ИТ подразделениями, подчиняясь руководителю службы
безопасности предприятия.
Вне зависимости от местной специфики в ИТ подразделении выделяется Служба
Заказчика (служба управления проектами развития), Сервисная Служба (служба
оперативной поддержки системы) и вспомогательные службы: управление ИТ
персоналом, учёт ИТ активов, МТО, экономика и бюджет, управление
документооборотом и архивом, юридическая служба, реклама, протокол и т. п.
В состав ИТ подразделения могут входить также различные специализированные
на конкретных задачах отделы