Управление релизами и развертыванием
продукта (Release and Deployment)
● Планирование управлением поставками
продукта
● Определение артефактов
● Формирование плана конфигурации поставки
продукта
● Определение и формирование плана релиза
продукта
Коммерческое предложение
Определение RFI, RFP (Proposal)
Определение MSA, SOW
Структура MSA, SOW
Структура КП (RFP Proposal)
Типы контрактов
Фиксированная стоимость (Fixed Price)
Время и стоимость (Time & Material)
Командный контракт (Dedicated Team)
Подходы к выбору контракта и методологии проекта
Управление содержанием проекта (Project Scope)
● Определение содержания
● Критерии приёмки продукта
● Допущения и ограничения поставляемого продукта.
● Создание ИСР
● Декомпозиция работ по созданию проекта.
● Примеры разбивки проекта на ИСР ● Подтверждение содержания
● Процесс мониторинга содержания проекта и продукта
Управление внедрением проекта
Разработка устава проекта
● 1. Описание работ (SOW)
● 2. Определение бизнес-ценности проекта
● 3. Определение высокоуровневых потребностей бизнеса
● 4. Определение допущений и ограничений проекта
● 5. Определение границ проекта
● 6. Определение списка заинтересованных сторон.
Модуль 2: Лекция 5-6. Определение стейкхолдеров и проектаYana Brodetski
Определение стейкхолдеров
Кто такие стейкхолдеры (Stakeholders)
Способы идентификации стейкхолдеров
Анализ вовлеченности стейхолдеров
Способы коммуникации на проекте
Проект
Структура проекта
Управление проектом
Система ограничений
Организационная структура
Целеполагание
Успешный проект
Модуль 2: Лекция 7-8. Обзор моделей, методологий и фреймворковYana Brodetski
Обзор моделей, методологий и фреймворков
● Введение
● Определение модели
● Определение методологии
● Определение фреймворка
● Каскадная модель (Waterfall)
● Модель прототипирования (Prototype)
● Итеративная модель ( Iterative)
● Спиральная модель (Spiral)
● V-образная модель (V-model)
● Agile методология (Agile Methodology)
Модуль 4. Лекция 19-20. Управление содержанием проектаYana Brodetski
Управление содержанием проекта (Project Scope)
Создание плана управления содержанием проекта
Свойства и функции проекта
План работ для достижения результата.
Сбор требований
Инструменты и методы сбора требований
Что такое бизнес-требования?
Определение функциональных требований
Определение нефункциональных требований
Правила описания требований
Как описывать нефункциональные требования
Структура документа для описания требованиий
Матрица отслеживания требований. (документация)
Фреймворк Scrum
Основные понятия фреймворка
Преимущества и недостатки фреймворка
Артефакты Scrum
Роли в Scrum
Event - ы в Scrum
Работа с Backlog. Приоритезация задач
Планирование и мониторинг спринта
Выбор методологии для проекта:
Подходы
Рекомендации
Коммерческое предложение
Определение RFI, RFP (Proposal)
Определение MSA, SOW
Структура MSA, SOW
Структура КП (RFP Proposal)
Типы контрактов
Фиксированная стоимость (Fixed Price)
Время и стоимость (Time & Material)
Командный контракт (Dedicated Team)
Подходы к выбору контракта и методологии проекта
Управление содержанием проекта (Project Scope)
● Определение содержания
● Критерии приёмки продукта
● Допущения и ограничения поставляемого продукта.
● Создание ИСР
● Декомпозиция работ по созданию проекта.
● Примеры разбивки проекта на ИСР ● Подтверждение содержания
● Процесс мониторинга содержания проекта и продукта
Управление внедрением проекта
Разработка устава проекта
● 1. Описание работ (SOW)
● 2. Определение бизнес-ценности проекта
● 3. Определение высокоуровневых потребностей бизнеса
● 4. Определение допущений и ограничений проекта
● 5. Определение границ проекта
● 6. Определение списка заинтересованных сторон.
Модуль 2: Лекция 5-6. Определение стейкхолдеров и проектаYana Brodetski
Определение стейкхолдеров
Кто такие стейкхолдеры (Stakeholders)
Способы идентификации стейкхолдеров
Анализ вовлеченности стейхолдеров
Способы коммуникации на проекте
Проект
Структура проекта
Управление проектом
Система ограничений
Организационная структура
Целеполагание
Успешный проект
Модуль 2: Лекция 7-8. Обзор моделей, методологий и фреймворковYana Brodetski
Обзор моделей, методологий и фреймворков
● Введение
● Определение модели
● Определение методологии
● Определение фреймворка
● Каскадная модель (Waterfall)
● Модель прототипирования (Prototype)
● Итеративная модель ( Iterative)
● Спиральная модель (Spiral)
● V-образная модель (V-model)
● Agile методология (Agile Methodology)
Модуль 4. Лекция 19-20. Управление содержанием проектаYana Brodetski
Управление содержанием проекта (Project Scope)
Создание плана управления содержанием проекта
Свойства и функции проекта
План работ для достижения результата.
Сбор требований
Инструменты и методы сбора требований
Что такое бизнес-требования?
Определение функциональных требований
Определение нефункциональных требований
Правила описания требований
Как описывать нефункциональные требования
Структура документа для описания требованиий
Матрица отслеживания требований. (документация)
Фреймворк Scrum
Основные понятия фреймворка
Преимущества и недостатки фреймворка
Артефакты Scrum
Роли в Scrum
Event - ы в Scrum
Работа с Backlog. Приоритезация задач
Планирование и мониторинг спринта
Выбор методологии для проекта:
Подходы
Рекомендации
Курс Управления Проектами.
Лекция 1- 2 .
Содержание:
Вступление
Что такое Project Management
Кто такие менеджеры проектов в IT?
Должностные обязанности менеджера проектов.
Разница между Product и Project Manager.
Перспективы развития: горизонтальная и вертикальная карьерная лестница.
Типы IT компаний.
Разница между аутсорс, аутстафф и продуктовой.
Жизненный цикл разработки ПО (SDLC)
Этапы жизненного цикла разработки
Этап планирования
Этап разработки
Этап поддержки
Роли в жизненном цикле разработки ПО
Артефакты в жизненном цикле разработки ПО
Терминология
Модуль 10. Лекция 43-44. Управление коммуникация проектаYana Brodetski
Управление коммуникация проекта
● Планирование управления коммуникациями:
● Входы
● Инструменты и методы
● Коммуникационные технологии
● Коммуникационные модели
● Методы коммуникаций
● Выходы
● Управление коммуникациями
● Входы
● Инструменты и методы
● Выходы
● Контроль коммуникаций
● Входы
● Инструменты и методы
● Выходы
MS Project 2010 schedule template for large NASA procurements $10-450 millionSelf employed
MS Project Schedule Template for large NASA Procurements $10-50M
Objectives
To identify repeatable process steps in small and large procurements that can be called out in MS Project
schedule templates.
* To support load balancing for procurement actions throughout the year. It will help prevent a log jam of actions in the fourth quarter.
* Simplified WBS for $25-125K procurements
* “Plug-in” Schedule template for $25-125K
* “Plug-in” Schedule template for $10-50M
* Roles & Responsibility Matrix for $10-50M
Each project task in the template is set to start as early as possible. All durations are “business days.”
Using the templates will help project managers avoid surprises in procurement schedules.
Each template shows all procurement process steps and nominal duration of tasks from start of requirements definition to finish with award to a vendor.
Templates have no “date constrained” tasks and can be directly inserted in new or existing schedules.
They will cascade forward from the start date of the procurement action.
JIRA Software Introduction prepared by Francis Yan, an Atlassian Certified Professional in Agile Development with JIRA Software based in Hong Kong.
It is an introduction cover basic function of JIRA with overview and screenshot, it aim to help JIRA beginner to know basic of JIRA and prepare for first JIRA requirement discussion meeting :)
This PPT throws light on some of the essential elements of the Agile methodology which has become crucial to ensure quality in this day and age. To know more on agile methodology, Scrum Model, Agile Principles and Scrum Board go through this presentation as well as the ones coming soon.
La última versión se encuentra aquí: http://www.slideshare.net/xalbaladejo/la-alternativa-agil-v57
Guía del curso de métodos ágiles (Scrum y Kanban, con unas pinceladas de Lean y XP) impartido en Octubre de 2010 en el marco de los Executive Education - Custom Programs de La Salle Business Engineering School (Universidad Ramon Llull, Barcelona). Parte de una presentación de Agile-Spain con slides específicos de proyectosagiles.org y uno de Henrik Kniberg (crisp.se).
Communication is a project manager’s most important skill.
Project Managers have to communicate with management, customers, the project team members, and the rest of the stakeholders involved with the projects.
An Overview of PRINCE2
PRINCE2® means PRojects IN Controlled Environment. PRINCE2® is a process-based approach for project management providing an easily tailored and scalable method for the management of all types of projects. The method is the de-facto standard for project management in the UK and is practised worldwide.
This presentation covers following PRINCE2 aspects.
Elements of PRINCE2
Seven Principles of PRINCE2
Seven Themes of PRINCE2
Seven Processes of PRINCE2
We at projectingIT prepare the delegates to appear for the APMG PRINCE2 Foundation and Practitioner Level Project Management Certification and pass it successfully.
Delegates will be provided with a project scenario and the course will use PRINCE2 to run the project. Templates will be provided to prepare the project documentation. The delegates will learn the key concepts in project management such as business case, project planning, scheduling, reporting, monitoring and controlling, risk and change management, project organization, step-by-step process for managing projects.
PRINCE2 Foundation Qualification Overview
Multiple choice format
75 questions per paper
5 questions to be trial and not counted in scores
35 marks required (out of 70 available) to pass - 50%
PRINCE2 Practitioner Exam Qualification Overview
Objective testing format
9 questions per paper with 12 marks available per question i.e. 108 marks total
Duration is 2.5 hours
Open book exam (Official PRINCE2 Manual only)
59 marks required (out of 108 available) to pass - 55%
Register today to get a quote or call us to know about PRINCE2 course.
and speak to one of our executives about the benefits of PRINCE2 and why you should do this course from us!
Visit us on www.projectingit.com to know more about us.
Курс Управления Проектами.
Лекция 1- 2 .
Содержание:
Вступление
Что такое Project Management
Кто такие менеджеры проектов в IT?
Должностные обязанности менеджера проектов.
Разница между Product и Project Manager.
Перспективы развития: горизонтальная и вертикальная карьерная лестница.
Типы IT компаний.
Разница между аутсорс, аутстафф и продуктовой.
Жизненный цикл разработки ПО (SDLC)
Этапы жизненного цикла разработки
Этап планирования
Этап разработки
Этап поддержки
Роли в жизненном цикле разработки ПО
Артефакты в жизненном цикле разработки ПО
Терминология
Модуль 10. Лекция 43-44. Управление коммуникация проектаYana Brodetski
Управление коммуникация проекта
● Планирование управления коммуникациями:
● Входы
● Инструменты и методы
● Коммуникационные технологии
● Коммуникационные модели
● Методы коммуникаций
● Выходы
● Управление коммуникациями
● Входы
● Инструменты и методы
● Выходы
● Контроль коммуникаций
● Входы
● Инструменты и методы
● Выходы
MS Project 2010 schedule template for large NASA procurements $10-450 millionSelf employed
MS Project Schedule Template for large NASA Procurements $10-50M
Objectives
To identify repeatable process steps in small and large procurements that can be called out in MS Project
schedule templates.
* To support load balancing for procurement actions throughout the year. It will help prevent a log jam of actions in the fourth quarter.
* Simplified WBS for $25-125K procurements
* “Plug-in” Schedule template for $25-125K
* “Plug-in” Schedule template for $10-50M
* Roles & Responsibility Matrix for $10-50M
Each project task in the template is set to start as early as possible. All durations are “business days.”
Using the templates will help project managers avoid surprises in procurement schedules.
Each template shows all procurement process steps and nominal duration of tasks from start of requirements definition to finish with award to a vendor.
Templates have no “date constrained” tasks and can be directly inserted in new or existing schedules.
They will cascade forward from the start date of the procurement action.
JIRA Software Introduction prepared by Francis Yan, an Atlassian Certified Professional in Agile Development with JIRA Software based in Hong Kong.
It is an introduction cover basic function of JIRA with overview and screenshot, it aim to help JIRA beginner to know basic of JIRA and prepare for first JIRA requirement discussion meeting :)
This PPT throws light on some of the essential elements of the Agile methodology which has become crucial to ensure quality in this day and age. To know more on agile methodology, Scrum Model, Agile Principles and Scrum Board go through this presentation as well as the ones coming soon.
La última versión se encuentra aquí: http://www.slideshare.net/xalbaladejo/la-alternativa-agil-v57
Guía del curso de métodos ágiles (Scrum y Kanban, con unas pinceladas de Lean y XP) impartido en Octubre de 2010 en el marco de los Executive Education - Custom Programs de La Salle Business Engineering School (Universidad Ramon Llull, Barcelona). Parte de una presentación de Agile-Spain con slides específicos de proyectosagiles.org y uno de Henrik Kniberg (crisp.se).
Communication is a project manager’s most important skill.
Project Managers have to communicate with management, customers, the project team members, and the rest of the stakeholders involved with the projects.
An Overview of PRINCE2
PRINCE2® means PRojects IN Controlled Environment. PRINCE2® is a process-based approach for project management providing an easily tailored and scalable method for the management of all types of projects. The method is the de-facto standard for project management in the UK and is practised worldwide.
This presentation covers following PRINCE2 aspects.
Elements of PRINCE2
Seven Principles of PRINCE2
Seven Themes of PRINCE2
Seven Processes of PRINCE2
We at projectingIT prepare the delegates to appear for the APMG PRINCE2 Foundation and Practitioner Level Project Management Certification and pass it successfully.
Delegates will be provided with a project scenario and the course will use PRINCE2 to run the project. Templates will be provided to prepare the project documentation. The delegates will learn the key concepts in project management such as business case, project planning, scheduling, reporting, monitoring and controlling, risk and change management, project organization, step-by-step process for managing projects.
PRINCE2 Foundation Qualification Overview
Multiple choice format
75 questions per paper
5 questions to be trial and not counted in scores
35 marks required (out of 70 available) to pass - 50%
PRINCE2 Practitioner Exam Qualification Overview
Objective testing format
9 questions per paper with 12 marks available per question i.e. 108 marks total
Duration is 2.5 hours
Open book exam (Official PRINCE2 Manual only)
59 marks required (out of 108 available) to pass - 55%
Register today to get a quote or call us to know about PRINCE2 course.
and speak to one of our executives about the benefits of PRINCE2 and why you should do this course from us!
Visit us on www.projectingit.com to know more about us.
Ограничения на поставку программного обеспечения и услуг по его технической поддержке со стороны западных вендоров создают угрозу для стабильной работы ИТ-инфраструктуры. Снизить связанные с этим риски помогают продукты с открытым кодом, решения от разработчиков из России и других стран, не поддерживающих санкции.
Подробнее на http://www.croc.ru/promo/independence/
www.cmcons.com. Практика и технология внедрения процесса конфигурационного управления и управления изменениями с применением IBM Rational ClearCase и ClearQuest
Сергей Смирнов (Altair Engineering Inc.) | Организация работы распределенной ...RIF-Technology
В рамках доклада рассмотрим вопросы формирования команды с помощью модели МакКинси 7с (McKinsey 7s), поговорим о процессах разработки программного продукта, системе релизов, системном инжиниринге и рекомендациях по системе управления процессами.
Выступление будет интересно руководителям команд разработчиков, особенно тем, кто фокусируется на предсказуемости сроков и качестве создаваемого решения.
Понятие юзабилити
● Работа с guidelines
● Особенности создания продукта/проекта
● Знакомство с юзабилити для e-commerce
● Знакомство с юзабилити для корпоративных сайтов
● Особенности юзабилити для форумов
● Особенности создания мобильных приложения
● Обзор языков программирования для IOS и Android
● Особенности разработки пользовательского интерфейса для
мобильных приложений
● Структура сборки приложения
● Обзор языков программирования:
● PHP
● .NET
● Python
● Ruby on Rails
● C#
Модуль 15. Лекция 57-58. Обзоры платформ для различных проектовYana Brodetski
Обзоры платформ для различных
проектов (e-commerce, corporate, forum):
● Prestashop
● Wordpress
● Joomla
● Opencart
● YII
● Bitrix 24
● WIX
● Saas – платформы
● Рекомендации по выбору CMS и фреймворков для
создания сайтов
Модуль 12. Лекция 51-52. Управление изменениями проектаYana Brodetski
Управление изменениями проекта
● Планирование управления изменениями
на проекте
● Составление плана управления
изменениями
● Разница между изменением и багом
● Методы оценки влияния изменения на
проект
● Утверждение и внесение изменений на
всех этапах проекта
Модуль 11. Лекция 49-50. Управление рисками проектаYana Brodetski
Управление рисками проекта
● Планирование реагирования на риски:
● Входы
● Инструменты и методы
● Стратегия реагирования на угрозы
● Стратегия реагирования на возможности
● Стратегия реагирования на потери
● Выходы
● Контроль рисков
● Входы
● Инструменты и методы
● Аудиты и переоценка рисков
● Выходы
Модуль 11. Лекция 47-48. Управление рисками проектаYana Brodetski
Управление рисками проекта
● Качественный анализ рисков:
● Входы
● Инструменты и методы
● Формирование матрицы вероятности и воздействия.
● Определение категорий рисков
● Выходы
● Количественный анализ рисков
● Входы
● Инструменты и методы
● Методы сбора и представления информации
● Методы количественного анализа и моделирования рисков
● Выходы
Модуль 11. Лекция 45-46. Управление рисками проектаYana Brodetski
Управление рисками проекта
● Планирование управления рисками:
● Входы
● Инструменты и методы
● Коммуникационные технологии
● Коммуникационные модели
● Методы коммуникаций
● Выходы
● Идентификация рисков
● Входы
● Инструменты и методы
● Выходы
Модуль 9. Лекция 41-42. Управление человеческими ресурсами проектаYana Brodetski
Управление человеческими ресурсами проекта
● Развитие команды проекта:
● Входы
● Инструменты и методы
● Навыки межличностного общения
● Обучение
● Выходы
● Управление командой проекта
● Входы
● Инструменты и методы
● Выходы
Модуль 9. Лекция 39-40. Управление человеческими ресурсами проектаYana Brodetski
Управление человеческими ресурсами проекта
● Планирование управление
человеческими ресурсами:
● Входы
● Инструменты и методы
● Выходы
● Набор команды проекта
● Входы
● Инструменты и методы
● Выходы
Модуль 8. Лекция 37-38. Управление качеством проектаYana Brodetski
Управление качеством проекта
● Планирование управление качеством
● Определение и характеристики дефекта;
● Задачи управления дефектами;
● Классификация важности дефектов;
● Виды тестирования;
● Правильное описание дефекта;
● Жизненный цикл дефекта;
● Работа с базами дефектов;
● Метрики на основе дефектов.
● Составление тест плана
Модуль 8. Лекция 35-36. Управление качеством проектаYana Brodetski
Управление качеством проекта
● Обеспечение качества
● Входы
● Инструменты и методы
● Диаграммы сходства
● Диаграммы процесса осуществления программы
● Ориентированные графы взаимоотношений
● Древовидные диаграммы
● Матрицы приоритетов
● Диаграммы сети операций
● Матричные диаграммы
● Выходы
● Контроль качества
● Входы
● Методы и инструменты
● Выходы
Модуль 8. Лекция 33-34. Управление качеством проектаYana Brodetski
Управление качеством проекта
● Определение управлением качества
● Качество продукта и проекта
● Принципы качество ISO 9000
● Планирование качества
● Входы
● Методы и инструменты
● Диаграмма причинно-следственных связей
● Блок –схемы
● Листы сбора данных
● Диаграмма Парето
● Гистограммы
● Контрольные карты
● Диаграммы разброса
● Выходы
Модуль 6. Лекция 29-30. Управление сроками проектаYana Brodetski
Разработка расписания
● Анализ сети расписания
● Метод критического пути
● Метод критической цепи
● Методы оптимизации ресурсов
● Методы моделирования: “что если”;имитация
● Опережения и задержки
● Сжатие расписания
● Диаграммы: Ганта, контрольных событий, сети расписания проекта
● Контроль расписания проекта
Модуль 6. Лекция 27-28. Управление сроками проектаYana Brodetski
Управление сроками проекта
● Определение последовательности операций
● Метод диаграмм предшествования (PDM)
● Определение зависимостей
● Опережение и задержки
● Оценка ресурсов операций
● Оценка “Снизу верх”
● Оценка длительности операций
● Аналоговая оценка
● Параметрическая оценка
● Оценка по 3 точкам
● Метод Дельфи
Модуль 6. Лекция 25-26. Управление срока проектаYana Brodetski
Управление сроками проекта
● Планирование управление расписанием
● Входы
● Инструменты и методы
● Выходы
● Определение операций
● Инструменты: планирование методом набегающей волны. ● Выходы:
● Список и параметры операций
● Список контрольных событий
● Расписание согласно методологии
User Stories vs. Use Cases
● User Stories
● Определение User Story
● Структура пользовательской истории
● Принципы проверки на качество User Story
● Use Cases
● Определение Use Cases
● Структура Use Cases
● Принципы составления Use Cases
Модуль 3. Лекция 17-18. Управление интеграцией проектаYana Brodetski
Управление внедрением проекта
Разработка проектного плана (процессы планирования)
Создание и структура плана проекта
Содержание плана проекта
Правила составления технической документации
Написание технического задания
Руководство и управление работами проекта
Мониторинг и контроль работ проекта
Интегрированный контроль изменений проекта
Закрытие проекта или фазы проекта
2. Лекция 55-56
Управление релизами и развертыванием
продукта (Release and Deployment)
● Планирование управлением поставками
продукта
● Определение артефактов
● Формирование плана конфигурации поставки
продукта
● Определение и формирование плана релиза
продукта
3. Процесс управления релизами
● Изменения ИТ-инфраструктуры происходят в сложной распределенной среде. В
современных приложениях клиент/сервер это часто отражается как на
клиентской части, так и на серверной. В таких случаях запуск и внедрение новых
версий программных и аппаратных средств требует тщательного планирования.
Релизом называется набор новых и/или измененных Конфигурационных Единиц
(CI), которые вместе испытываются и внедряются в рабочую среду. Релиз чаще
определяется запросом на изменение(RFC), для исполнения которого он
вводится в работу.
● Объектом Процесса Управления Релизами является программное обеспечение.
● Расходы, возникающие при запуске процесса, не столь значительны по
сравнению с потенциальными потерями, вызванными недостатками в
планировании и контроле за программными и аппаратными средствами, к
которым можно отнести следующие:
● большие перерывы в работе из-за плохого планирования выпуска релизов;
● дублирование работ из-за наличия копий различных версий;
● неэффективное использование ресурсов из-за отсутствия информации об их
местонахождении;
● потеря исходных файлов, приводящая к повторной закупке программ;
● отсутствие защиты от вирусов, приводящее к необходимости «лечения» всей
сети.
4. Основные определения
Релизы- содержат одно или несколько авторизованных изменений
(проблем или улучшений). Они могут классифицироваться в первую
очередь по уровню релиза. Часто релизы разделяют на:
● Значительные релизы – крупномасштабное развертывание новых
аппаратных и программных средств, обычно со значительно
расширенными функциональными возможностями. Такие релизы
часто помогают в устранении ряда известных ошибок, включая
известные обходные решенияи быстрые исправления
● Малые программные релизы и модернизация аппаратного
обеспечения (апгрейды) – эти релизы обычно представляют собой
незначительные усовершенствования и исправления известных
ошибок. Среди них могут быть такие, которые внедрялись ранее в
виде срочных исправлений и теперь окончательно проработаны и
включены в данный релиз. За счет такого релиза обеспечивается
обновление «Прежнего стабильного состояния», являющегося
отправной точкой для всех испытаний.
● Срочные исправления – обычно внедряются как быстрые
исправления проблем и известных ошибок.
5. Планирование релизов. Как?
● Определить основные роли и обязанности в рамках Управления
релизами, чтобы обеспечить понимание каждым сотрудником своей
роли и уровня полномочий.
● Ввести правила нумерации Релизов, их частоту и уровни в ИТ-
инфраструктуре, которые будут контролироваться этими Релизами.
● Присвоить им уникальный идентификатор, он будет использоваться
при управлении конфигурациями
● Выбрать уровень единицы релиза для каждого элемента ПО или типа
ПО.
● При выборе уровня единица релиза, учитывать следующие факторы:
● объем необходимых изменений на каждом возможном уровне;
● объем ресурсов и время, требуемое на сборку, тестирование,
распространение и внедрение Релизов на каждом возможном уровне;
● простота внедрения;
● сложность интерфейсов между предлагаемой единицей и остальной ИТ-
инфраструктурой;
● доступное дисковое пространство в среде сборки, в тестовой среде, в
среде распространения и в среде
6. Идентификация релизов
Копии программ могут распространяться из Библиотеки DSL по соответствующим средам:
● Среда разработки — разработка новых версий может вестись на основе более ранних
версий из Библиотеки DSL. С каждой новой версией увеличивается ее номер.
Изменение программного обеспечения возможно только в среде разработки.
● Среда испытаний – среда для тестирования версий. Часто тестирование разделяют на
технические испытания разработчиками, функциональные испытания
пользователями, испытания внедрения компоновщиками релизов и, возможно,
окончательные приемочные испытания пользователями и руководством.
● Рабочая среда – активная среда, где информационные системы доступны для
пользователей.
● Архив – служит для хранения старых версий программных единиц, которые больше
не используются.
Так как возможно использование нескольких релизов, им присваиваются уникальные
идентификаторы. В идентификационном номере релиза должна быть ссылка на
соответствующую Конфигурационную Единицу, и он должен включать номер версии из
двух или более цифр, например:
● Значительные релизы – система расчета зарплаты v.1, v.2, v.3 и т. п.
● Малые релизы – система расчета зарплаты v.1.1, v.1.2, v.1.3 и т. п.
● Релизы - срочные исправления – система расчета зарплаты v.1.1.1, v.1.1.2, v.1.1.3 и т.
п.
7. Типы релизов
● Дельта-релиз – в дельта-релиз включаются только измененные аппаратные и программные средства.
Это часто связано с экстренными и быстрыми исправлениями. Недостатком этого типа релизов
является то, что часто невозможно проверить все связи с остальной частью среды, в результате чего не
удаляются модули, к которым программа больше не обращается. Дельта-релиз удобен в случае, если
программное обеспечение может быть изолировано от остальной части ИТ-среды. Преимуществом
дельта-релиза является то, что для создания тестовой среды требуется меньше усилий.
● Полный релиз – при полном релизе идет распространение полного комплекта ПО, включая
неизмененные модули. Такой подход предпочтителен в случаях, когда точно не известно, что
изменено в программном обеспечении. Более тщательные испытания программных и аппаратных
средств обеспечивают в этом случае меньшее число инцидентов после внедрения. При подготовке
полного релиза легче определить, достигается ли запланированный уровень производительности.
Преимуществом полного релиза является возможность одновременного внедрения нескольких
изменений. Подготовка облегчается благодаря возможности использования стандартных сценариев
инсталляции. Также при инсталляции может быть «очищена» программная среда. Однако полный
релиз требует большей подготовки и ресурсов, чем дельта-релиз.
● Пакетный релиз – пакетный релиз, или комплект
релизов, обеспечивает пользователям более длительные
периоды стабильной работы. Исправление незначительных
программных ошибок, с которыми пользователи могут
мириться, и внедрение новых функций часто являются
действиями, которые можно эффективно объединить.
Так же плановые апгрейды, например системного
программного обеспечения и офисных приложений от
внешних разработчиков, могут включаться в
пакетные релизы.
8. Основные определения
● Библиотека эталонного программного обеспечения(DSL) - это надежное хранилище для эталонных
авторизованных версий (мастер-копий) всех Конфигурационных Единиц программного обеспечения.
Физически библиотека DSL может находиться в разных местах и состоять из нескольких надежных
хранилищ и огнеустойчивых сейфов для носителей информации. Управление Релизами начинает
контролировать жизненный цикл программ с момента их включения в библиотеку DSL. Релизы
конфигурируются из известного надежного программного обеспечения, хранящегося в DSL. После этого
разрабатываются инсталляционные скрипты, а в децентрализованной среде могут быть записаны
соответствующие компакт-диски. В библиотеке DSL может храниться несколько версий одного и того
же программного обеспечения, включая архивные версии, документацию и исходные коды. Поэтому
необходимо создание резервных копий.Библиотеки DSL, поскольку она содержит не только текущую
версию программного обеспечения, но и копии на случай возврата к прежней версии. При наличии в
компании нескольких территориальных объектов с локальным руководством, на каждом из них
должна быть копия Библиотеки DSL на случай развертывания программного обеспечения.
● Склад эталонного аппаратного обеспечения предназначен для хранения запасных аппаратных
средств. Это запасные компоненты и узлы, состояние которых поддерживается на том же уровне, что и
у соответствующих им компонентов в активной среде. Аппаратные средства со склада DHS
используются для замены или ремонта аналогичных Конфигураций в ИТ-инфраструктуре. Информация
о составе этих Конфигураций должна содержаться в базе CMDB.
● Конфигурационная База Данных (CMDB)- в рамках всего Процесса Управления Релизами
рекомендуется проверять информацию о Конфигурационных Единицах в базе CMDB. Как только
версии программного обеспечения добавляются в Библиотеку DSL, а версии аппаратных средств – на
Склад DHS, производится обновление CMDB. Для поддержки Процесса Управления Релизами база
данных CMDB должна содержать информацию по следующим вопросам:
● содержание запланированных релизов, включая Конфигурационные Единицы аппаратного и
программного обеспечения со ссылкой на исходный Запрос на Изменения (RFC);
● аппаратные и программные Конфигурационные Единицы, на которые может повлиять релиз;
● данные о физическом местонахождении аппаратных средств, имеющих отношение к релизу.
9. Цель процесса управления релизами
● Процесс Управления Релизами занимается управлением и распространением (дистрибуцией)
используемых в рабочей среде версий программного и аппаратного обеспечения, находящихся
на поддержке ИТ-подразделения для обеспечения необходимого уровня услуг.
● Задачами Процесса Управления Релизами являются:
● Планирование, координация и внедрение (или организация внедрения) программных и
аппаратных средств.
● Разработка и внедрение рациональных процедур для распространения и инсталляции
изменений в ИТ-системах.
● Обеспечение отслеживаемости и безопасности программных и аппаратных средств,
подвергшихся изменениям, и гарантирование того, что в рабочей среде находятся только
корректные, авторизованные и тестированные версии.
● Коммуникации и оповещение пользователей, учет их ожиданий при планировании и
развертывании новых релизов.
● Определение состава релизов и планирование их развертывания совместно с Процессом
Управления Изменениями.
● Внедрение новых версий программных и аппаратных средств в рабочую инфраструктуру
под контролем Управления Изменениями и при поддержке Управления Конфигурациями.
Релиз может включать любое количество Конфигурационных Единиц, а также не только
программные и аппаратные средства, но и документацию, например, отчеты, планы,
руководства по поддержке.
● Обеспечение сохранности оригинальных копий программ в Библиотеке эталонного
программного обеспечения (DSL) и регулярного обновления базы данных CMDB; то же
касается аппаратных средств на Складе DHS.
10. Преимущества управления релизами.
● Вместе с эффективными Процессами Управления Конфигурациями и Управления Изменениями
Процесс Управления Релизами способствует тому, чтобы:
● Использовалось программное и аппаратное обеспечение высокого качества, которое разрабатывалось
и тестировалось с проведением процедур контроля качества.
● Сводилась к минимуму возможность возникновения ошибок в программно-аппаратных комплексах,
или ошибок выпуска некорректных версий.
● Бизнес-подразделения внимательно контролировали инвестиции в программное обеспечение, от
которых во многом зависит бизнес.
● Уменьшалось общее количество отдельно взятых внедрений, и проводились серьезные испытания
каждого внедрения.
● Уменьшалась опасность возникновения инцидентов и известных ошибок за счет тестирования и
контроля внедрения.
● Пользователи больше привлекались к участию в тестировании релизов.
● Заранее публиковалась программа ввода релизов для улучшения координации ожиданий
пользователей с политикой и практикой появления новых релизов.
● Для целей бизнеса существовали структуры централизованного проектирования и компоновки
программных и аппаратных средств или структуры для их закупки с последующим распространением
по пользователям.
● Бизнес-подразделения могли стандартизировать версии программного и аппаратного обеспечения в
своих подразделениях для облегчения их поддержки.
● Уменьшалась опасность использования пиратских программ, а также опасность возникновения
инцидентов и проблем из-за интегрирования в активную среду дефектных или зараженных вирусом
версий программного и аппаратного обеспечения.
● Облегчалось обнаружение неавторизованных копий и некорректных версий.
11. Процесс управления релизами.
Состоит из следующих видов деятельности:
● разработка политики в отношении релизов и их планирование;
● компоновка и конфигурирование релизов;
● тестирование и приемка релизов;
● планирование развертывания релизов;
● оповещение, подготовка и обучение;
● распространение и инсталляция релизов.
В действительности эти виды
деятельности не
располагаются в
хронологическом порядке.
Определение политики и
планирование релизов
могут проводиться раз в
полгода или в год,
в то время как другие действия могут проводиться
ежедневно.
12. Процесс управления релизами.
● Управление Конфигурациями отвечает за регистрацию доступных версий
программного и аппаратного обеспечения в базе данных CMDB в качестве Базисных
Конфигураций. Программы, включаемые в Библиотеку DSL, и аппаратные средства
для DHS регистрируются в CMDB с согласованным уровнем детализации. Мониторинг
статуса, выполняемый Процессом Управления Конфигурациями, отражает статус
каждой Конфигурационной Единицы, например, «В активном использовании», «В
разработке», «В тестировании», «В запасе» или «В архиве».
● Управление Изменениями- деятельность по распространению (тиражированию)
релизов контролируется Процессом Управления Изменениями. Кроме того,
Управление Изменениями гарантирует, чтобы было проведено адекватное
тестирование релизов. Управление Изменениями также принимает решение о
количестве изменений, которые могут быть скомбинированы в одном релизе.
Управление Изменениями определяет процедуры, обеспечивающие авторизацию
изменений, включая анализ степени воздействия и анализ необходимых ресурсов. В
большинстве случаев Руководитель Процесса Управления Релизами несет
ответственность за внедрение программных и аппаратных изменений и он обычно
участвует в работе Консультативного комитета по изменениям.
● Управление Уровнем Услуг- ИТ-сервис обычно включает в себя инфраструктурное
аппаратное обеспечение вместе со стандартным или разработанным собственными
силами программным обеспечением. Управление Релизами отвечает за ввод в
работу программных и аппаратных средств и отслеживает соглашения о доступности
программных средств, заключенные в рамках Процесса Управления Уровнем Услуг.
13. Виды деятельности в рамках процесса управления релизами
Все компоненты должны эффективно управляться,
начиная с их разработки или закупки и до настройки и
конфигурирования, от тестирования и внедрения до
работы в среде эксплуатации.
14. Виды деятельности в рамках процесса управления релизами
Выработка политики в отношении релизов и планирование:
● Руководитель Процесса Управления Релизами разрабатывает политику в отношении релизов, определяя когда и каким образом
производится конфигурирование релизов. Значительные релизы могут планироваться заранее, одновременно с присвоением номера
версии, чтобы в определенные моменты времени можно было рассмотреть возможность внесения изменений.
● Руководитель Процесса Управления Релизами также определяет, на каком уровне Конфигурационные Единицы могут распространяться
независимо друг от друга (релизные единицы). Это зависит от:
● Потенциального воздействия релиза на другие компоненты.
● Количества человеко-часов и времени на компоновку и тестирование раздельных изменений, в сравнении с усилиями,
необходимыми для их объединения и одновременного внедрения.
● Трудности инсталляции на местах пользователей. Возможно, что инсталлировать полную программу легче благодаря наличию для
этого стандартных методов.
● Сложности взаимосвязей между новым программным и аппаратным обеспечением и остальной частью ИТ-инфраструктуры – чем
легче изолировать программные или аппаратные средства, тем легче их тестировать.
● Перед планированием релиза необходимо собрать информацию о жизненном цикле внедряемого продукта, а также обо всех
подготовленных к сдаче в рамках данного релиза продуктах, описании соответствующих ИТ-услуг и их уровней и данные об авторизации
соответствующих Запросов на Изменения (RFC) и т. д. При планировании релиза рассматриваются следующие вопросы:
● координация содержания релиза;
● разработка графика ввода релиза;
● согласование графика, территориальных объектов, на которых произойдет распространение релиза, и организационных единиц;
● посещение объектов для определения реально используемых аппаратных и программных средств;
● разработка плана оповещения (коммуникаций);
● согласование ролей и ответственностей;
● получение подробных коммерческих предложений и переговоры с поставщиками о новых аппаратных и программных средствах, а
также услугах по их инсталляции;
● разработка планов на случай возврата к исходному состоянию;
● разработка плана обеспечения качества релиза;
● планирование приемки релиза руководством и пользователями.
● Результаты этой деятельности представляют собой часть плана проведения изменения и включают планы релиза, планы тестирования и
критерии приемки.
15. Проектирование, компоновка и конфигурирование
● Рекомендуется выработать стандартные процедуры проектирования, компоновки и
конфигурирования релизов. Основой релизов могут быть наборы компонентов
(Конфигурационных Единиц – CI), разработанные внутри организации или
закупленные у третьей стороны и прошедшие этап конфигурирования. Руководства
по инсталляции и конфигурированию релизов должны рассматриваться как часть
релиза и в качестве Конфигурационных Единиц должны включаться в число объектов,
находящихся под контролем Процессов Управления Изменениями и Управления
Конфигурациями.
● Перед инсталляцией на месте рекомендуется настроить и протестировать все
аппаратное и программное обеспечение в «лабораторных условиях». Компоненты
программных и аппаратных средств необходимо тщательно конфигурировать и
зарегистрировать, чтобы обеспечить возможность их многократного
воспроизведения. Необходимо разработать рабочие инструкции таким образом,
чтобы каждый раз воспроизводился один и тот же набор компонентов. Часто в
резерве имеются стандартизированные аппаратные средства, которые используется
только для компилирования или создания образов ПО. Для надежности желательно,
чтобы эта часть процесса была автоматизирована. Необходимые для этого
программные и аппаратные средства также попадают в сферу действия Процесса
Управления Релизами. В среде разработки программ такая деятельность называется
Управлением Компоновкой и входит в зону ответственности Управления Релизами.
16. План возврата к исходному состоянию
● В плане возврата к исходному состоянию на уровне релиза в целом определяются действия, необходимые для
восстановления услуг в случае сбоя во время внедрения (имплементации) релиза. Ответственность за разработку
планов возврата несет Процесс Управления Изменениями. В частности, при внедрении пакетного релиза,
объединяющего несколько Запросов на Изменения (RFC), может возникнуть необходимость координации различных
планов возврата для этого релиза. Если возникает сбой Полного релиза или Дельта-релиза, рекомендуется свернуть
релиз полностью до Прежнего стабильного состояния . На случай невозможности полного свертывания релиза должны
существовать Планы восстановления на случай чрезвычайных обстоятельств для возобновления предоставления услуг.
● Требования плана возврата к исходному состоянию, такие как создание резервных копий и обеспечение запасного
сервера, рекомендуется выполнять заранее. В случаях, если внедрение может занять больше времени, чем
предполагается, и если задержка может поставить под угрозу нормальное предоставление услуг, в план возврата
должен включаться крайний срок, определяющий время приведения в действие плана возврата. Это требуется для
своевременного возобновления услуг (например, не позднее 7:00 в понедельник). План возврата к исходному
состоянию должен включаться в анализ рисков изменения и должен быть одобрен пользователями.
● Реальная компоновка релиза может включать компилирование и связывание программных модулей, или наполнение
баз данных тестовыми данными, или такими данными, как таблицы почтовых индексов, налоговых ставок, часовых
поясов и валютных курсов, а также информацией о пользователях. Часто это выполняется автоматизированными
инсталляционными скриптами, хранящимися в Библиотеке DSL вместе с планами возврата. Полные релизы должны
отражаться в базе CMDB как Стандартные Конфигурации для облегчения конфигурирования в будущем. Планы
тестирования должны включать тестирование и приемку по качеству программного и аппаратного обеспечения,
процедур, инструкций по операционной деятельности и сценариев (скриптов) развертывания перед выходом релиза и,
возможно, оценочные испытания после внедрения релиза. Должно также проводиться тестирование инсталляционных
скриптов. Для этого требуется следующая информация:
● определение релиза;
● график ввода релиза;
● инструкции по конфигурированию и компоновке релиза
● описание позиций, требующих приобретения или лицензирования, с приложением графиков закупки
● автоматизированные инсталляционные скрипты и планы тестирования;
● исходные копии кодов программ для включения в библиотеку DSL;
● планы возврата к исходному состоянию
17. Тестирование и приемка релиза
● Наиболее частой причиной неудовлетворительного внедрения изменений и релизов является неадекватность
тестирования. Для предотвращения этого перед внедрением релиза должно проводиться функциональное
тестирование представителями пользователей и операционное (эксплуатационное) тестирование персоналом ИТ,
оценивающим технические характеристики, функциональность, операционные (эксплуатационные) аспекты,
производительность и интеграцию с остальной частью инфраструктуры. Также должны тестироваться
инсталляционные скрипты, процедуры возврата и любые изменения процедур управления. Формальная приемка
каждого этапа должна быть представлена в Процессе Управления Изменениями. Последним этапом является
утверждение внедрения релиза.
● Перед тем, как Процесс Управления Релизами начнет развертывание релиза, Процесс Управления Изменениями
должен организовать формальную приемку релиза пользователями и его окончательную сдачу разработчиками.
● Релизы должны приниматься в контролируемой тестовой среде, состоящей из Базовых Конфигураций, которые
должны быть подробно описаны в ходе определения релиза. Соответствующие Базовые Конфигурации должны быть
зарегистрированы в CMDB. Если релиз не принимается, он возвращается в Процесс Управления Изменениями.
● Результатами деятельности по тестированию и приемке релиза являются:
● протестированные процедуры инсталляции;
● протестированные компоненты релиза;
● известные ошибки и недостатки релиза;
● результаты тестирования;
● документация для управления и поддержки;
● перечень систем, подвергающихся воздействию;
● операционные (эксплуатационные) инструкции и средства диагностики
● планы на случай непредвиденных ситуаций и протестированные планы возврата;
● программы обучения персонала, руководителей и пользователей
● подписанные приемо-сдаточные документы;
● авторизация из Процесса Управления Изменениями для выполнения релиза.
18. Планирование внедрения
● Составленный на предыдущих этапах план теперь дополняется информацией о действиях по
внедрению.
● Планирование развертывания релиза включает:
● составление графика, а также перечня задач и требуемых людских ресурсов;
● составление перечня инсталлируемых и снимаемых с использования Конфигурационных Единиц,
с указанием способа вывода из операционной среды;
● составление плана действий для каждого территориального объекта с учетом запаса времени на
развертывание и часовых поясов, если речь идет о географически распределенных организациях;
● рассылку уведомлений о релизе и другие контакты с вовлеченными сторонами;
● составление планов закупки аппаратного и программного обеспечения;
● закупку, размещение на хранение, определение и регистрацию всех новых CI для данного релиза
в базе CMDB;
● планирование встреч с руководством, управляющими подразделениями, персоналом по
Управлению Изменениями и представителями пользователей.
● Существует несколько способов осуществления развертывания:
● полное развертывание релиза – подход «большого скачка»;
● поэтапное развертывание релиза, включающее несколько разновидностей:
● функциональное наращивание, когда все пользователи получают одновременно новые элементы
функциональности;
● наращивание по объектам, когда развертывание ведется от одной группы пользователей к
другой;
● эволюционное развертывание с поэтапным расширением функциональности.
20. Оповещение, подготовка и обучение
● Персонал, находящийся в контакте с заказчиками (Служба
Service Desk и Управление Взаимоотношениями с Заказчиками –
CRM), операционный (обслуживающий) персонал и
представители пользователей должны быть в курсе планов
внедрения и его возможных последствий для повседневной
деятельности. Для этого можно организовать совместное
обучение, сотрудничество и совместное участие в приемке
релиза. Необходимо согласовать распределение
ответственностей, с соответствующим уведомлением каждого.
При поэтапном развертывании релиза пользователи должны
быть проинформированы о планах и времени, когда для них
будут доступны новые функции.
● Необходимо заранее информировать весь задействованный
персонал об изменениях в Соглашениях об Уровне Услуг (SLA),
Операционных Соглашениях об Уровне Услуг (OLA) и Внешних
Договорах (UC).
21. Release notes
● Release Notes — это примечания к версии продукта, в которых
описываются изменения между выпускаемой и предыдущей версиями
этого продукта. Такой документ может составляться для пользователей и
для внутренних команд: тестировщиков, маркетологов, службы
поддержки.
● Основными целями документы являются:
● информирование пользователям об исправленных ошибках,
расширении функциональности продукта.
● обращение внимания тестировщиков на проверку ошибок, их
исправление.
● подготовка изменений в руководствах пользователя и обучающих
материалах по продукту.
● В составлении Release Notes может помочь трекинговая система или
один из популярных инструментов для управления продуктами
● Примечания к релизу распространяются вместе с продуктами. Иногда —
когда продукты все еще находятся в разработке или тестировании.
Документ может быть доставлен клиентам при выпуске обновления (для
продуктов, которые уже были использованы клиентами).
22. Release notes- Как писать?
Содержание документа зависит от типа релиза. Вот пример основных пунктов:
● Заголовок с названием продукта, датой релиза и его номером, версией
примечания.
● Краткая информация — обзор продукта и изменений.
● Ссылки на инструкции по установке, руководство для пользователя, архив,
если необходимо.
● Цели — краткий обзор целей примечаний к релизу с перечислением нового в
этой версии (исправления ошибок и новые функции).
● Резюме — краткое описание ошибок и проблем.
● Шаги по устранению ошибок.
● Решение — оптимизация, которая была сделана для исправления ошибок.
● Влияние пользователей и поддержки, если необходимо.
● Примечания — все примечания относительно установки продукта, его
обновлений и документации.
● Юридическая информация — лицензии, гарантии, отказ от ответственности и
т.д.
● Контакты — контактная информация службы поддержки продукта.
23. Распространение релизов и инсталляция
● Управление Релизами осуществляет мониторинг процессов логистики/материально-
технического обеспечения по закупке, хранению, транспортировке, поставке и
передаче программного и аппаратного обеспечения. Этот процесс поддерживается
процедурами, регистрационными записями и такими сопроводительными
документами, как упаковочные листы, что необходимо для предоставления
достоверной информации в Процесс Управления Конфигурациями. Склады
аппаратного и программного обеспечения должны быть надежными и доступными
только для авторизованного персонала.
● Для распространения и инсталляции программного обеспечения рекомендуется, по
возможности, использовать автоматизированные инструментальные средства. Это
позволит сократить время, необходимое для распространения ПО, и повысить
качество при сокращении затрат на ресурсы. Часто такие инструментальные средства
также облегчают проверку успешности инсталляции. Перед началом любой
инсталляции необходимо проверить, удовлетворяет ли среда, где предполагается
внедрение релиза, необходимым требованиям, таким как достаточное дисковое
пространство, безопасность, требованиям к окружающей среде или ограничениям
эксплуатационных условий, например, кондиционирование воздуха, площадь
помещения, источники бесперебойного питания (UPS), сетевое питание и т. п.
● После инсталляции необходимо обновить информацию в базе данных CMDB для
облегчения проверки лицензионных соглашений.
24. Затраты и проблемы
Затраты на Процесс Управления Релизами включают:
● затраты на персонал;
● затраты на хранение в Библиотеке DSL и Складе DHS, а также на поддержку среды компоновки,
тестирования и распространения релизов;
● затраты на инструментальные программные средства и необходимое аппаратное обеспечение.
Проблемы:
Возможно возникновение следующих проблем:
● Сопротивление изменениям – вначале возможно сопротивление персонала, привыкшего к
старым привычным методам работы. Например, некоторым сотрудникам бывает трудно
принять тот факт, что для проведения определенной деятельности они будут получать
инструкции из другого подразделения. Для устранения таких ситуаций необходимо
информировать этих сотрудников о преимуществах подхода ITIL.
● Обход Процесса Управления Релизами – использование неавторизованных программ может
привести к распространению вирусов, отрицательно повлиять на услуги и затруднить поддержку.
Поэтому в отношении персонала и пользователей, пытающихся использовать неавторизованные
программы, особенно в среде PC, должны быть предприняты решительные действия.
● Срочные исправления – не следует действовать в обход Процесса Управления Релизами даже
при необходимости срочных изменений.
● Распространение – при развертывании программ на нескольких объектах необходимо
обеспечить их синхронизацию, для предотвращения разницы версий на разных объектах.
● Тестирование – без создания соответствующей тестовой среды будет трудно произвести оценку
правильности новых версий или новых программ перед их развертыванием.