Стандарты жизненного цикла ИС. Service Level Agreement – SLA. Аутсорсинг и инсорсинг (лекция 2)

1.

Стандарты жизненного цикла ИС
Service Level Agreement – SLA
Аутсорсинг и инсорсинг
Марина Аншина
Председатель Правления Российского Союза ИТ-Директоров
Доцент Финансового Университета,
Старший преподаватель МИРЭА
[email protected]
+7-916-633-53-42

2.

• ГОСТ Р 57193— 2016 «Системная и программная
инженерия. Процессы жизненного цикла систем»
• ГОСТ Р ИСО/МЭК 12207-2010 «Информационная
технология. Системная и программная инженерия.
Процессы жизненного цикла программных средств»
• ГОСТ Р 59793 – 2021 «Информационные технологии
комплекс стандартов на автоматизированные
системы Автоматизированные системы. Стадии
создания» (ГОСТ 34)
Методики управления ЖЦ ИС
• SWEBoK
• PRINCE
Стандарты сервисного подхода ИСО/МЭК 20000
Стандарты качества процессов ИСО/МЭК 9001

3.

• ГОСТ Р 57193—
2016 «Системная
и программная
инженерия.
Процессы
жизненного
цикла систем»

4.

«Системная и программная
инженерия. Процессы
жизненного цикла систем»

5.

ГОСТ Р 57193— 2016
«Системная и
программная инженерия.
Процессы жизненного
цикла систем»

6.

7.

8.

Процессы
жизненного
цикла ПО в
ГОСТ
ИСО/МЭК
12207-2010

9.

10.

11.

12.

Жизненный цикл ИС по ГОСТ Р
59793 – 2021 (ранее ГОСТ
34.601)

13.

14.

Формирование требований к АС
• Обследование объекта и обоснование
необходимости создания АС
• Формирование требований
пользователя к АС
• Оформление отчета о выполненной
работе

15.

Разработка концепции АС
• Изучение объекта
• Проведение необходимых научноисследовательских работ
• Разработка вариантов концепции АС и
выбор варианта концепции АС,
удовлетворяющего требованиям
пользователя
• Оценка рисков проекта
• Оформление отчета о выполненной
работе

16.

Эскизный проект
• Разработка предварительных
проектных решений по АС и ее частям
• Разработка документации на АС и ее
части

17.

Технический проект
• Разработка проектных решений по АС и ее
частям
• Разработка документации на АС и ее части
• Разработка и оформление документации на
поставку изделий для комплектования АС и
(или) технических требований (технических
заданий) на их разработку
• Разработка заданий на проектирование в
смежных частях проекта объекта
автоматизации

18.

Рабочая документация
• Разработка рабочей документации на
АС и ее части
• Разработка или адаптация отдельных
видов обеспечения АС

19.

Ввод в действие
• Подготовка объекта автоматизации к вводу АС в
действие
• Подготовка персонала
• Комплектация АС поставляемыми изделиями
(программными и техническими средствами,
программно-техническими комплексами,
информационными изделиями)
• Строительно-монтажные работы
• Пусконаладочные работы
• Проведение предварительных испытаний
• Проведение опытной эксплуатации
• Проведение приемочных испытаний

20.

Сопровождение АС
• Выполнение работ в соответствии с
гарантийными обязательствами
• Послегарантийное обслуживание

21.

ТЕХНИЧЕСКОЕ ЗАДАНИЕ
ГОСТ 34.602— 2020 «Техническое задание на создание
автоматизированной системы»

22.

ТЗ на АС содержит следующие
обязательные разделы
- общие сведения;
- цели и назначение создания автоматизированной системы;
- характеристика объектов автоматизации;
- требования к автоматизированной системе;
- состав и содержание работ по созданию автоматизированной
системы;
• - порядок разработки автоматизированной системы;
• - порядок контроля и приемки автоматизированной системы;
• - требования к составу и содержанию работ по подготовке объекта
автоматизации к вводу автоматизированной системы в действие;
• - требования к документированию;
• - источники разработки.
В ТЗ на АС могут быть включены приложения.
Примечание — В случае отсутствия требований по разделу,
соответствующий раздел сохраняется, и в нем приводится запись об
отсутствии требований

23.

Раздел «Общие сведения»
- полное наименование АС и ее условное обозначение;
- шифр темы (при наличии);
- наименование организации — заказчика АС, наименование
организации-разработчика (при наличии сведений о ней);
• - перечень документов, на основании которых создается АС, кем и
когда утверждены эти документы;
• - плановые сроки начала и окончания работ по созданию АС;
• - общие сведения об источниках и порядке финансирования работ.
Примечание — К документам, на основании которых или в соответствии с
которыми создается АС, могут относиться, например, следующие:
- договорные документы на создание АС;
- нормативно-правовые и нормативно-технические документы,
регламентирующие создание АС;
- техническое задание на создание ранее разрабатывавшейся АС

24.

Раздел «Цели и назначение
создания автоматизированной
системы»
• цели создания АС: наименования и требуемые
значения технических, технологических,
производственно-экономических или других
показателей объекта автоматизации, которые
должны быть достигнуты в результате создания АС,
и критерии оценки достижения целей создания АС.
• назначение АС: вид автоматизируемой деятельности
(управление, проектирование и т. п.) применительно
к объекту автоматизации в целом. Для сложного
объекта автоматизации приводится общий перечень
объектов, на которых планируется использовать АС.

25.

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

26.

Раздел «Требования к
автоматизированной системе»
Подразделы:
• - требования к структуре АС в целом;
• - требования к функциям (задачам), выполняемым АС;
• - требования к видам обеспечения АС;
• - общие технические требования к АС.
Состав требований к АС, включаемых в данный раздел ТЗ
на АС, устанавливают в зависимости от вида, назначения,
специфических особенностей и условий
функционирования конкретной автоматизированной
системы. В каждом подразделе приводят ссылки на
действующие НТД, определяющие требования к
автоматизированным системам соответствующего вида.

27.

Подраздел «Требования к
структуре АС в целом» у
• - перечень подсистем (при их наличии), их назначение и
основные характеристики. Дополнительно могут быть
приведены требования к числу уровней иерархии и степени
централизации АС;
• - требования к способам и средствам обеспечения
информационного взаимодействия компонентов АС;
• - требования к характеристикам взаимосвязей создаваемой АС
со смежными АС, требования к интероперабельности,
требования к ее совместимости, в том числе указания о
способах обмена информацией;
• - требования к режимам функционирования АС;
• - требования по диагностированию АС;
• - перспективы развития, модернизации АС.

28.

Подраздел «Требования к
функциям (задачам),
выполняемым АС»
• - перечень функций (задач), подлежащих автоматизации для АС в
целом или для каждой подсистемы (при их наличии). В перечень
включаются в том числе функции (задачи), обеспечивающие
взаимодействие частей АС. Для каждой функции (задачи) должен быть
указан результат ее выполнения и, при необходимости, приведены
основные характеристики результата.
При необходимости дополнительно могут быть указаны следующие
данные:
• - временной регламент реализации каждой функции (задачи)
• - требования к реализации каждой функции (задачи), к форме
представления выходной информации, характеристики необходимой
точности и времени выполнения, требования одновременности
выполнения группы функций, достоверности выдачи результатов;
• - перечень и критерии отказов для каждой функции, по которой
задаются требования по надежности

29.

Подраздел «Требования к
видам обеспечения АС»
• требования к математическому,
информационному, лингвистическому,
программному, техническому,
метрологическому, организационному,
методическому и другим видам
обеспечения АС

30.

Для математического
обеспечения АС
• требования к составу, области
применения (ограничениям) и способам
использования в АС математических
методов и моделей, типовых
алгоритмов и алгоритмов, подлежащих
разработке.

31.

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

32.

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

33.

Для программного
обеспечения АС
• - требования к составу и видам
программного обеспечения;
• - требования к выбору используемого
программного обеспечения;
• - требования к разрабатываемому
программному обеспечению;
• - перечень допустимых покупных
программных средств (при наличии)

34.

Для технического
обеспечения АС
Требования:
• - к видам технических средств, в том
числе к видам комплексов технических
средств, программно-технических
комплексов и других комплектующих
изделий, допустимых к использованию
в АС;
• - к функциональным, конструктивным и
эксплуатационным характеристикам
средств технического обеспечения АС.

35.

Требованиях к метрологическому
обеспечению АС
• - количественные значения показателей метрологического
обеспечения;
• - требования к методам (методикам) измерений и
измерительного контроля параметров и их характеристик;
• - требования к средствам измерений и измерительного
контроля;
• - требования к метрологическому обеспечению испытаний
АС;
• - требования к программе метрологического обеспечения
АС;
• - требования к метрологической совместимости технических
средств АС;
• - требования проведения метрологической экспертизы
технической документации (при необходимости).

36.

Для организационного
обеспечения АС
Требования:
• - к структуре и функциям подразделений,
участвующих в функционировании АС или
обеспечивающих эксплуатацию;
• - к организации функционирования АС и порядку
взаимодействия персонала и пользователей АС;
• - к организации функционирования АС при сбоях,
отказах и авариях;
• - к порядку обеспечения нормативными документами,
необходимыми для разработки АС

37.

Для методического
обеспечения АС
• - перечень применяемых при
разработке и функционировании АС
нормативно-технических документов
(стандартов, нормативов, методик,
профилей и т. п.);
• - порядок и правила обеспечения
разработчиков АС нормативнотехнической документацией.

38.

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

39.

Требования к численности и
квалификации персонала и
пользователей АС
• - требования к численности персонала
и пользователей АС;
• - требования к квалификации
персонала и пользователей АС,
порядку их подготовки и контроля
знаний и навыков;
• - требуемый режим работы персонала и
пользователей АС.

40.

Требования к показателям
назначения АС
• Значения параметров,
характеризующих степень соответствия
АС ее назначению (при их наличии)

41.

Требования к надежности
• - состав и количественные значения показателей
надежности для АС в целом или ее подсистем
(составных частей);
• - перечень аварийных ситуаций, по которым должны
быть регламентированы требования к надежности, и
значения соответствующих показателей;
• - требования к надежности технических средств и
программного обеспечения;
• - требования к методам оценки и контроля
показателей надежности на разных стадиях создания
АС в соответствии с действующими нормативнотехническими документами.

42.

Требования по безопасности
• требования по обеспечению
безопасности при монтаже, наладке,
эксплуатации, обслуживании и ремонте
технических средств АС (защита от
воздействий электрического тока,
электромагнитных полей и т. п.), по
допустимым уровням вибрационных и
шумовых нагрузок, а также по
обеспечению экологической
безопасности.

43.

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

44.

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

45.

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

46.

Требования к защите информации от
несанкционированного доступа
• требования, установленные в НТД,
действующей в отрасли (ведомстве)
заказчик

47.

Требования по сохранности
информации
• перечень событий: аварий, отказов
технических средств (в том числе —
потеря питания) и т. п., при которых
должна быть обеспечена сохранность
информации в АС.

48.

Требования к защите от
внешних воздействий
• - требования к радиоэлектронной
защите средств АС;
• - требования по стойкости,
устойчивости и прочности к внешним
воздействиям (среде применения).

49.

Требования к патентной
чистоте и патентоспособности
• требования по патентной чистоте и
патентоспособности АС и ее частей,
включая требования по проведению
патентных исследований

50.

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

51.

Дополнительные требования
• - требования к оснащению АС учебнотренировочными средствами и
документацией на них;
• - требования к сервисной аппаратуре,
стендам для проверки элементов АС;
• - требования к АС, связанные с особыми
условиями эксплуатации;
• - специальные требования по
усмотрению разработчика или заказчика
АС.

52.

Раздел «Состав и содержание
работ по созданию
автоматизированной системы»
• Перечень этапов работ по созданию АС
и сроки их выполнения.

53.

Раздел «Порядок разработки
автоматизированной системы»
• - порядок организации разработки АС;
• - перечень документов и исходных данных для разработки АС;
• - перечень документов, предъявляемых по окончании
соответствующих этапов работ;
• - порядок проведения экспертизы технической документации;
• - перечень макетов (при необходимости), порядок их разработки,
изготовления, испытаний, необходимость разработки на них
документации, программы и методик испытаний;
• - порядок разработки, согласования и утверждения плана совместных
работ по разработке АС;
• - порядок разработки, согласования и утверждения программы работ по
стандартизации;
• - требования к гарантийным обязательствам разработчика;
• - порядок проведения технико-экономической оценки разработки АС;
• - порядок разработки, согласования и утверждения программы
метрологического обеспечения, программы обеспечения надежности,
программы эргономического обеспечения.

54.

Раздел «Порядок контроля и
приемки автоматизированной
системы»
• - виды, состав и методы испытаний АС и ее
составных частей;
• - общие требования к приемке работ, порядок
согласования и утверждения приемочной
документации;
• - статус приемочной комиссии (государственная,
межведомственная, ведомственная и др.).
Примечание — Порядок согласования и утверждения
приемочной документации, а также статус приемочной
комиссии указываются при необходимости

55.

Раздел «Требования к составу и содержанию
работ по подготовке объекта автоматизации к
вводу автоматизированной системы в
действие»
перечень мероприятий, которые необходимо осуществить при
подготовке объекта автоматизации к вводу АС в действие:
• - создание условий функционирования объекта автоматизации,
при которых гарантируется соответствие создаваемой АС
требованиям, содержащимся в ТЗ на АС;
• - проведение необходимых организационно-штатных
мероприятий;
• - порядок обучения персонала и пользователей АС.

56.

Раздел «Требования к
документированию»
• - перечень подлежащих разработке
документов;
• - вид представления и количество
документов;
• - требования по использованию ЕСКД и
ЕСПД при разработке документов.

57.

Раздел «Источники
разработки»
• документы и информационные
материалы (технико-экономическое
обоснование, отчеты о законченных
научно-исследовательских работах,
информационные материалы на
отечественные, зарубежные системыаналоги и др.), на основании которых
разрабатывалось ТЗ и которые должны
быть использованы при создании АС.

58.

ИСО/МЭК 20000

59.

Состав ИСО/МЭК - 20000

60.

ГОСТ Р ИСО/МЭК 20000-12021
• НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ
ФЕДЕРАЦИИ
ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ.
МЕНЕДЖМЕНТ СЕРВИСОВ
Часть 1
Требования к системе менеджмента сервисов
• Information technology. Service management. Part
1: Service management system requirements

61.

Содержание

62.

63.

Отношения между сторонами,
задействованными в ЖЦ сервиса

64.

Менеджмент уровня сервиса

65.

66.

Цикл PDCA в ИСО 20000-2014

67.

PRINCE
PROJECTS IN CONTROLLED
ENVIRONMENTS

68.

PRINCE
• Структурированный метод управления проектами,
одобренный правительством Великобритании в качестве
стандарта управления проектами в социальной сфере.
• Методология PRINCE2 включает в себя подходы к
менеджменту, контролю и организации проектов.
• Разработан в 1989 году Central Computer and
Telecommunications Agency (CCTA) в Великобритании.
• В 2013 году права на PRINCE2 переданы AXELOS Ltd
(совместное предприятие правительства Великобритании
и компании Capita).
• Исторически методология создавалась для руководства
проектами в сфере IT, но в настоящее время является «de
facto» стандартом для руководства проектами в
Великобритании.

69.

70.

PRINCE

71.

7 принципов PRINCE
CONTINUED BUSINESS JUSTIFICATION (Постоянная оценка
целесообразности). Спонсор проекта (в русских договорных
отношениях это чаще всего Заказчик, даже если он внутренний)
должен быть постоянно уверен в необходимости реализации проекта,
если такая необходимость отпала, то проект следует прекратить.
Ожидаемые выгоды должны быть больше затрат и рисков.
LEARN FROM EXPERIENCE (Учет предыдущего опыта). Принцип
призывает руководителей проектов постоянно анализировать и
использовать извлеченные уроки других проектов, а также
фиксировать собственный опыт в ходе своего проекта.
DEFINED ROLES AND RESPONSIBILITIES (Определенные роли и
обязанности). В каждом проекте должна быть сформирована
матрица ответственности в рамках проекта и его организационной
структуре. Авторы PRINCE2 выделяют три заинтересованные стороны
проекта: бизнес (определяет цели проекта и инвестирует его),
пользователи (используют продукт проекта) и поставщики
(предоставляют ресурсы).

72.

7 принципов PRINCE
MANAGE BY STAGES (Управления по стадиям). Проект
должен планироваться, отслеживаться и контролироваться по
стадиям, в конце каждой стадии должен обновляться план
следующей стадии с учетом результатов завершающейся
текущей стадии. Между каждой стадией должны присутствовать
точки принятия основных решений.
MANAGE BY EXCEPTION (Управление по
исключениям). Руководство проектами следует осуществлять
путем определения обязанностей и ответственности на каждом
уровне проекта при помощи строгого делегирования полномочий.
Такой способ управления позволяет экономить как время
высшего руководства, спонсоров проекта, так и самого
менеджера проекта. Допустимые отклонения должны быть
определены для каждого уровня плана проекта.

73.

7 принципов PRINCE
FOCUS ON PRODUCT (Фокус на продукте). Акцент в
проекте должен быть на конечном продукте и его
качестве. Процедура управления изменениями снижает
увеличение скоупа проекта. Акцент на качестве и
утвержденном описании продукта снижает
неудовлетворенность пользователей (потребителей)
конченного продукта проекта.
TAILOR TO SUIT THE PROJECT ENVIRONMENT
(Адаптация к внешним условиям). Проектная
команда должна осознавать, каким образом происходит
адаптация принципов PRINCE2 к внешним условиям
проекта (корпоративные стандарты, корпоративная
культура), подходит ли используемый метод для
окружения проекта.

74.

7 тем - аспектов проекта, которые
требуют постоянного внимания
• Экономическое обоснование (Business Case) позволяет
сформировать механизмы для определения востребованности,
выполнимости и жизнеспособности проекта, а также остается
ли проект таковым на протяжении всего его выполнения. На
основании экономического обоснования с учетом выгоды,
затрат и рисков должно приниматься решение о дальнейшем
продолжении проекта и его инвестициях.
• Организация (Organization). Как и в любой методологии
проектного управления заинтересованными лицами проекта
являются лицо или группа лиц, которая может влиять на проект
или на которую может влиять проект (включая процессы и риски
проекта). В проекте должна быть определена и сформирована
четкая структура ответственности и обязанностей проекта.
Подробное описание каждой роли можно прочитать в
стандарте.

75.

76.

7 тем - аспектов проекта, которые
требуют постоянного внимания
Управление качеством (Quality) – определение и внедрение средств
в рамках проекта для подтверждения, что продукты проекта
соответствуют утвержденному описанию и подходят для тех целей,
для которых они предназначены. Любой продукт проекта должен
обладать определенным комплексом свойств и неотъемлемых или
установленных характеристик, которые дают понимание, что продукт
отвечает ожиданиям или удовлетворяет установленным потребностям,
требованиям или спецификации.
Планы работ (Plans) – широко описывает понятия и уровни планов в
проекте (план стадии инициации проекта, план самого проекта, планы
стадий создания продуктов, планы исключений, планы команды).
Анализ и управление рисками проекта (Risk). Здесь по классике:
управление рисками должно осуществляться не только при инициации
проекта или в момент наступления риска, а на протяжении всего срока
реализации проекта. Тема анализа и управления риска предоставляет
подход к выявлению, оценке и контролю рисков во время проекта и, как
результат, повышению успеха проекта.

77.

7 тем - аспектов проекта, которые
требуют постоянного внимания
Управление изменениями содержания (Change) =
определение, оценка и последующее управление любыми
потенциальными и одобренными изменениями конечных
продуктов проекта. При управлении изменениями всегда
должен использоваться предыдущий опыт, запросы на
изменения и отклонения от спецификации должны
оцениваться с точки зрения влияния на экономическое
обоснование проекта.
Принятие решений (Progress) – предназначена для
формирования и утверждения механизмов мониторинга
фактических результатов и достижений проекта и их
сравнение с запланированными, прогнозирование целей
проекта и его отклонения.

78.

79.

7 процессов для управления и
реализации проекта

80.

7 процессов для управления и
реализации проекта
Начало проекта (Starting up a Project). Цель процесса – выполнить
минимальные необходимые действия для принятия решения, стоить
ли приступать к стадии инициирования проекта. Данный процесс
подразумевает подготовку наброска экономического обоснования
проекта для принятия решения о финансировании и необходимости
проекта.
Руководство проектом (Directing a Project) – принятие ключевых
решений управляющим советом (Directing), делегируя оперативное
управление менеджеру проекта. Данный процесс не равен
фактическому управлению проектом менеджером проекта.
Инициация проекта (Initiating a Project) предполагает подготовку
стратегий управления риском, качеством, коммуникациями и
конфигурацией проекта, создание плана проекта и установку средств
контроля проекта. Данный процесс выполняется уже менеджером
проекта.

81.

7 процессов для управления и
реализации проекта
Контроль стадии (Controlling a Stage) – делегирование и отслеживание
выполнения работы в рамках каждой стадии проекта, формирование
отчетов о прогрессе, принятие решений по инцидентам и обеспечение
корректирующих действий в проекте.
Управление границами стадии (Managing a Stage Boundary) –
предоставление необходимой информации менеджером проекта для оценки
управляющим советом проекта успехов текущей стадии и утверждения
плана следующей стадии с учетом экономической обоснованности.
Управление созданием продукта (Managing Product Delivery) –
управление связью между менеджером проекта и менеджером команды
посредством установления формальных требований к приемке,
выполнению и поставке результатов проектной работы по созданию
продукта проекта.
Закрытие проекта (Closing a Project) – обеспечение конкретного
момента для подтверждения приемки продукта и признания достижения
целевых показателей проекта, либо отсутствия экономического
обоснования продолжения проекта в случае его досрочного прекращения.

82.

SERVICE LEVEL AGREEMENT
SLA

83.

Что такое качество сервиса
• Качество услуги — это совокупность
характеристик услуги, определяющих
ее способность удовлетворять
установленные или предполагаемые
потребности потребителя.

84.

Service Level Agreement - SLA
• Соглашение об уровне предоставления
сервиса
(англ. Service Level Agreement, SLA) —
термин методологии ITIL, обозначающий
формальный SLA между заказчиком* услуги и
её поставщиком, содержащий описание
услуги, права и обязанности сторон и, самое
главное, согласованный уровень качества
предоставления данной услуги.
* - в рекомендациях ITIL заказчик и потребитель — разные понятия

85.

86.

87.

88.

89.

АУТСОРСИНГ

90.

Что такое аутсорсинг
• Передача непрофильных для компании видов
деятельности внешнему исполнителю
• Услуги, чаще всего переводимые на аутсоросинг:
Уборка
Транспортное обслуживание
Охрана
Бухгалтерский учет
Питание
ИТ

91.

Виды аутсорсинга

92.

The Outsourcing Professional
Body of Knowledge (OPBOK)
• Аутсорсинг есть долгосрочное, ориентированное на результат
бизнес-сотрудничество с внешним специализированным
поставщиком услуг. На аутсорсинг может передаваться одна
или несколько отдельных бизнес-функций либо сквозной
бизнес-процесс полностью.

93.

Содержание ОРВоК

94.

Инсорсинг
• Инсорсинг — это создание дочернего
сервисного предприятия или
выделенного общего центра
обслуживания (ОЦО), объединяющего
сервисы, которые используются более
чем одним подразделением внутри
предприятия/группы компаний

95.

Усложнение аутсорсинговых
цепочек
Аутсорсер
1
Ген.
подрядчик
Заказчик
SLA
Подрядчик
2
SLA
Аутсорсер
2
Аутсорсер
3
SLA
Аутсорсер
1
Подрядчик
1
SLA
SLA
Заказчик
SLA
Аутсорсер
2
SLA
Подрядчик
1
SLA
SLA
Аутсорсер
4
Подрядчик
3

96.

SLA облачный сервисов
ГОСТ Р ИСО/МЭК
19086-1-2019
Информационные
технологии.
Облачные
вычисления.
Структура
соглашения об
уровне
обслуживания (SLA).
Часть 1. Обзор и
концепции

97.

Цикл Деминга - Шухарта

98.

99.

DevX (Developer Experience)
• Документация: Хорошая документация необходима разработчикам
для понимания того, как эффективно использовать продукт, услугу
или внутренний сервис. Сюда входят примеры кода, документация по
API и руководства по использованию продукта или услуги.
• Инструментарий: Инструменты и фреймворки разработчика должны
быть хорошо спроектированы, просты в использовании и учитывать
технологический стек и экосистему, используемые целевой
аудиторией разработчиков.
• Поддержка: Разработчики должны иметь доступ к ресурсам
поддержки, таким как форумы, базы знаний и группы поддержки
клиентов, чтобы помочь им решить любые проблемы, с которыми они
сталкиваются.
• Сообщество: Сильное сообщество разработчиков может быть ценным
ресурсом для разработчиков, поскольку оно предоставляет
разработчикам место для обмена знаниями, обращения за помощью и
совместной работы над проектами.

100.

?
ВОПРОСЫ

101.

Домашнее задание на
семинар
• Сформировать требования к ИС и завести их
в DevProm
• Использовать ГОСТ 34 как шаблон