🗊Управление изменениями в сложных информационных системах Вебинар, 28 октября 2010

Категория: Новости
Нажмите для полного просмотра!
Управление изменениями в сложных информационных системах Вебинар, 28 октября 2010, слайд №1Управление изменениями в сложных информационных системах Вебинар, 28 октября 2010, слайд №2Управление изменениями в сложных информационных системах Вебинар, 28 октября 2010, слайд №3Управление изменениями в сложных информационных системах Вебинар, 28 октября 2010, слайд №4Управление изменениями в сложных информационных системах Вебинар, 28 октября 2010, слайд №5Управление изменениями в сложных информационных системах Вебинар, 28 октября 2010, слайд №6Управление изменениями в сложных информационных системах Вебинар, 28 октября 2010, слайд №7Управление изменениями в сложных информационных системах Вебинар, 28 октября 2010, слайд №8Управление изменениями в сложных информационных системах Вебинар, 28 октября 2010, слайд №9Управление изменениями в сложных информационных системах Вебинар, 28 октября 2010, слайд №10Управление изменениями в сложных информационных системах Вебинар, 28 октября 2010, слайд №11Управление изменениями в сложных информационных системах Вебинар, 28 октября 2010, слайд №12Управление изменениями в сложных информационных системах Вебинар, 28 октября 2010, слайд №13Управление изменениями в сложных информационных системах Вебинар, 28 октября 2010, слайд №14Управление изменениями в сложных информационных системах Вебинар, 28 октября 2010, слайд №15Управление изменениями в сложных информационных системах Вебинар, 28 октября 2010, слайд №16Управление изменениями в сложных информационных системах Вебинар, 28 октября 2010, слайд №17Управление изменениями в сложных информационных системах Вебинар, 28 октября 2010, слайд №18Управление изменениями в сложных информационных системах Вебинар, 28 октября 2010, слайд №19Управление изменениями в сложных информационных системах Вебинар, 28 октября 2010, слайд №20Управление изменениями в сложных информационных системах Вебинар, 28 октября 2010, слайд №21Управление изменениями в сложных информационных системах Вебинар, 28 октября 2010, слайд №22Управление изменениями в сложных информационных системах Вебинар, 28 октября 2010, слайд №23Управление изменениями в сложных информационных системах Вебинар, 28 октября 2010, слайд №24Управление изменениями в сложных информационных системах Вебинар, 28 октября 2010, слайд №25Управление изменениями в сложных информационных системах Вебинар, 28 октября 2010, слайд №26Управление изменениями в сложных информационных системах Вебинар, 28 октября 2010, слайд №27Управление изменениями в сложных информационных системах Вебинар, 28 октября 2010, слайд №28
Скачать

Содержание ▲

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

Слайды и текст этой презентации

Слайд 1


Управление изменениями в сложных информационных системах Вебинар, 28 октября 2010
Описание слайда:
Управление изменениями в сложных информационных системах Вебинар, 28 октября 2010

Слайд 2


О чем поговорим Не каждое изменение есть улучшение, Но каждое улучшение является изменением Разные мотивации За разработку и эксплуатацию (поддержку) чаще всего отвечают разные подразделения, а иногда и разные компании. Продаются фичи, а в процессе эксплуатации "вылезают" другие вопросы Надежность / отсутствие багов Масштабируемость / требования к инфраструктуре Гибкость / скорость внесения изменений Архитектура / скорость локализации ошибок
Описание слайда:
О чем поговорим Не каждое изменение есть улучшение, Но каждое улучшение является изменением Разные мотивации За разработку и эксплуатацию (поддержку) чаще всего отвечают разные подразделения, а иногда и разные компании. Продаются фичи, а в процессе эксплуатации "вылезают" другие вопросы Надежность / отсутствие багов Масштабируемость / требования к инфраструктуре Гибкость / скорость внесения изменений Архитектура / скорость локализации ошибок

Слайд 3


План Общее понимание «изменений» Заказчик всегда прав? Разработка с учетом эксплуатации Контроль качества
Описание слайда:
План Общее понимание «изменений» Заказчик всегда прав? Разработка с учетом эксплуатации Контроль качества

Слайд 4


Голосование 1 Вы были на наших вебинарах по тематике ITSM ранее? Да, в текущем году Да, но давно это было Нет, это первый
Описание слайда:
Голосование 1 Вы были на наших вебинарах по тематике ITSM ранее? Да, в текущем году Да, но давно это было Нет, это первый

Слайд 5


Поехали!
Описание слайда:
Поехали!

Слайд 6


Коротко о главном Изменения – неотъемлемая и наиболее опасная часть жизни любой системы Цель процесса управления изменениями — обеспечение внесения изменений в IT-инфраструктуру в соответствии со стандартизованными процедурами, для эффективного проведения изменений и минимизации рисков внесения изменений на функционирование инфраструктуры (ITILv2). Базовые требования к внесению изменений изменение согласовано, т.е. известно, кто какие изменения должен согласовывать изменение оттестировано, т.е. есть тесты и документация есть план Б (возврат к предыдущей версии), т.е. предыдущая версия вообще есть!
Описание слайда:
Коротко о главном Изменения – неотъемлемая и наиболее опасная часть жизни любой системы Цель процесса управления изменениями — обеспечение внесения изменений в IT-инфраструктуру в соответствии со стандартизованными процедурами, для эффективного проведения изменений и минимизации рисков внесения изменений на функционирование инфраструктуры (ITILv2). Базовые требования к внесению изменений изменение согласовано, т.е. известно, кто какие изменения должен согласовывать изменение оттестировано, т.е. есть тесты и документация есть план Б (возврат к предыдущей версии), т.е. предыдущая версия вообще есть!

Слайд 7


Классификация изменений Форма выполнения (workflow) Проекты Стандартные изменения Срочные (экстренные) Масштаб имеет значение Деньги/трудоемкость Бизнес риски Технические риски
Описание слайда:
Классификация изменений Форма выполнения (workflow) Проекты Стандартные изменения Срочные (экстренные) Масштаб имеет значение Деньги/трудоемкость Бизнес риски Технические риски

Слайд 8


Что должно быть в Системе Прием и классификация запросов на изменения. Гибкие жизненные циклы и маршруты согласования Информирование пользователей о планах изменений, в частности о периодах недоступности сервисов Связь с CMDB и Релизами Связь с инцидентами Связь с проблемами Связь с системами управления проектами и разработкой
Описание слайда:
Что должно быть в Системе Прием и классификация запросов на изменения. Гибкие жизненные циклы и маршруты согласования Информирование пользователей о планах изменений, в частности о периодах недоступности сервисов Связь с CMDB и Релизами Связь с инцидентами Связь с проблемами Связь с системами управления проектами и разработкой

Слайд 9


Голосование 2 Как у вас организована работа с изменениями 1. Как придется 2. Регламентированы и согласуются в бумажном виде 3. Регламентированы и автоматизированы 4. Другое (поясните в чате)
Описание слайда:
Голосование 2 Как у вас организована работа с изменениями 1. Как придется 2. Регламентированы и согласуются в бумажном виде 3. Регламентированы и автоматизированы 4. Другое (поясните в чате)

Слайд 10


Миф серебряной пули…
Описание слайда:
Миф серебряной пули…

Слайд 11


Заказчик и изменения Нужен «владелец» продукта Право сказать "нет" Релизная политика: багфиксы, минорные изменения, крупные проекты Не все нужно строить "на века". Коммуникации Торговля за функции. Частая ситуация - разрозненные требования и приоритеты, нет возможности принимать "авторитарные" решения Быстрая оценка доработок За все нужно платить. Не всегда удается сделать систему сразу надежной, быстрой, функциональной, красивой и т.д.
Описание слайда:
Заказчик и изменения Нужен «владелец» продукта Право сказать "нет" Релизная политика: багфиксы, минорные изменения, крупные проекты Не все нужно строить "на века". Коммуникации Торговля за функции. Частая ситуация - разрозненные требования и приоритеты, нет возможности принимать "авторитарные" решения Быстрая оценка доработок За все нужно платить. Не всегда удается сделать систему сразу надежной, быстрой, функциональной, красивой и т.д.

Слайд 12


Разработка не должна быть…
Описание слайда:
Разработка не должна быть…

Слайд 13


Голосование 3 Вы представляете 1. Блок эксплуатации 2. Блок разработки/развития 3. Заказчик 4. Другое (поясните в чате)
Описание слайда:
Голосование 3 Вы представляете 1. Блок эксплуатации 2. Блок разработки/развития 3. Заказчик 4. Другое (поясните в чате)

Слайд 14


Участие эксплуатации в разработке Разработка с учетом эксплуатации Эксплуатационные требования при выборе ПО. При чем это должно быть что-то более конкретное нежели "доступность три девятки" и "работа 3000 пользователей". нужно предусматривать планы по изменчивости функциональности, время жизни ПО, кол-во специалистов для поддержки и т.д. Ответственный за эксплуатацию - в команде проекта еще на этапе внедрения Должно оставаться время на нефункциональные улучшения
Описание слайда:
Участие эксплуатации в разработке Разработка с учетом эксплуатации Эксплуатационные требования при выборе ПО. При чем это должно быть что-то более конкретное нежели "доступность три девятки" и "работа 3000 пользователей". нужно предусматривать планы по изменчивости функциональности, время жизни ПО, кол-во специалистов для поддержки и т.д. Ответственный за эксплуатацию - в команде проекта еще на этапе внедрения Должно оставаться время на нефункциональные улучшения

Слайд 15


Участие разработки в эксплуатации Обратная связь Не "что конкретно поправить", а "какую задачу решить" Правило McDonald's Факты а не обобщения Разработка ориентированная на клиента Максимально близкая к рабочей тестовая среда Право на рефакторинг Стоимость поиска и исправления ошибок растет со временем
Описание слайда:
Участие разработки в эксплуатации Обратная связь Не "что конкретно поправить", а "какую задачу решить" Правило McDonald's Факты а не обобщения Разработка ориентированная на клиента Максимально близкая к рабочей тестовая среда Право на рефакторинг Стоимость поиска и исправления ошибок растет со временем

Слайд 16


Что может помочь? Не экономьте на инфраструктуре разработки Системы автоматизированного тестирования, непрерывной интеграции, документация снижают стоимость изменений Непосредственно разработка - меньшая часть затрат на реализацию изменения Иногда совпадение нескольких факторов приводит к действительно неожиданным (и зачастую более серьезным чем можно было бы ожидать) последствиям Человеческий фактор – ключевой, из-за чего возникают ошибки. роботы не ошибаются:)
Описание слайда:
Что может помочь? Не экономьте на инфраструктуре разработки Системы автоматизированного тестирования, непрерывной интеграции, документация снижают стоимость изменений Непосредственно разработка - меньшая часть затрат на реализацию изменения Иногда совпадение нескольких факторов приводит к действительно неожиданным (и зачастую более серьезным чем можно было бы ожидать) последствиям Человеческий фактор – ключевой, из-за чего возникают ошибки. роботы не ошибаются:)

Слайд 17


Основные принципы Agile Итерационный подход Регулярное планирование Командная работа с привлечением заказчиков Проблемы выявляются, обсуждаются и решаются Ретроспектива (что сделано, что будет сделано, какие проблемы)
Описание слайда:
Основные принципы Agile Итерационный подход Регулярное планирование Командная работа с привлечением заказчиков Проблемы выявляются, обсуждаются и решаются Ретроспектива (что сделано, что будет сделано, какие проблемы)

Слайд 18


Арбитр
Описание слайда:
Арбитр

Слайд 19


Контроль качества Сдержки и противовесы Контроль качества не должен подчиняться напрямую разработке Не только функциональное тестирование Законы Мерфи никто не отменял Никогда не знаешь, какой ошибкой отразится изменение При разработке требований уделять внимание сценариям использования и тестирования Для исключения рисков - нужно проводить максимально доступное по ширине тестирование. Именно поэтому автоматизированные тесты и всякие штуки типа SOA это хорошо.
Описание слайда:
Контроль качества Сдержки и противовесы Контроль качества не должен подчиняться напрямую разработке Не только функциональное тестирование Законы Мерфи никто не отменял Никогда не знаешь, какой ошибкой отразится изменение При разработке требований уделять внимание сценариям использования и тестирования Для исключения рисков - нужно проводить максимально доступное по ширине тестирование. Именно поэтому автоматизированные тесты и всякие штуки типа SOA это хорошо.

Слайд 20


Несколько слов про NAUMEN
Описание слайда:
Несколько слов про NAUMEN

Слайд 21


NAUMEN Сделано в полную силу… И это работает! Российская компания, партнеры в России и СНГ, своя команда внедрения Более 200 внедрений Naumen Service Desk на территории СНГ в отраслях: Поддержка до 24х7 на русском языке Широкая линейка продуктов
Описание слайда:
NAUMEN Сделано в полную силу… И это работает! Российская компания, партнеры в России и СНГ, своя команда внедрения Более 200 внедрений Naumen Service Desk на территории СНГ в отраслях: Поддержка до 24х7 на русском языке Широкая линейка продуктов

Слайд 22


Лицензирование Naumen Service Desk Организационная структура и учет контрагентов Запросы (инциденты и сервисные запросы) Проблемы Сервисы и соглашения Задачи (наряды на работы) Регламентные работы Отчетность Модуль администрирования и управления справочной информацией
Описание слайда:
Лицензирование Naumen Service Desk Организационная структура и учет контрагентов Запросы (инциденты и сервисные запросы) Проблемы Сервисы и соглашения Задачи (наряды на работы) Регламентные работы Отчетность Модуль администрирования и управления справочной информацией

Слайд 23


Итого…
Описание слайда:
Итого…

Слайд 24


Еще раз остановимся на главном Взаимное вовлечение и обеспечение обратной связи позволит избегать конфликтов и обеспечить кач-во для конечного заказчика Размер инвестиций в инфраструктуру и технологию разработки зависит от требований к надежности создаваемого ПО и его жизненного цикла При оценке стоимости изменения учитывать прежде всего стоимость внедрения, а не реализации «на рабочем месте разработчика» Могут помочь правильные KPI кол-во ошибки/функционал время доставки доработки (изменения) до заказчика % документированных изменений % покрытия тестами
Описание слайда:
Еще раз остановимся на главном Взаимное вовлечение и обеспечение обратной связи позволит избегать конфликтов и обеспечить кач-во для конечного заказчика Размер инвестиций в инфраструктуру и технологию разработки зависит от требований к надежности создаваемого ПО и его жизненного цикла При оценке стоимости изменения учитывать прежде всего стоимость внедрения, а не реализации «на рабочем месте разработчика» Могут помочь правильные KPI кол-во ошибки/функционал время доставки доработки (изменения) до заказчика % документированных изменений % покрытия тестами

Слайд 25


Одна цитата из рабочей переписки В новой версии должно быть хотя бы на одну ошибку меньше, но при этом, ни на одну фичу больше. Фича - не синоним слова "хорошо", любая фича - изменение поведения системы, в хорошую сторону или плохую - это дело субъективной оценки пользователя, и под это изменение клиент должен перестроить свое поведение. Мы не должны вынуждать его делать это. Он должен делать это сам, осознанно, и переходить на другой, нежели в комплекте поставки набор функций, только добровольно и явно проявляя на то свою волю. Выход каждого релиза должен быть доведен до клиентов, с описанием изменений.
Описание слайда:
Одна цитата из рабочей переписки В новой версии должно быть хотя бы на одну ошибку меньше, но при этом, ни на одну фичу больше. Фича - не синоним слова "хорошо", любая фича - изменение поведения системы, в хорошую сторону или плохую - это дело субъективной оценки пользователя, и под это изменение клиент должен перестроить свое поведение. Мы не должны вынуждать его делать это. Он должен делать это сам, осознанно, и переходить на другой, нежели в комплекте поставки набор функций, только добровольно и явно проявляя на то свою волю. Выход каждого релиза должен быть доведен до клиентов, с описанием изменений.

Слайд 26


Источники SCRUM http://ru.wikipedia.org/wiki/Scrum. Гибкая методология разработки ПО. ГОСТ Р ИСО/МЭК 12207-99 Разработан именно для ПО. Определяет требования к организации процессов и взаимодействий на всем жизненном цикле ПО. В частности, рассматривает эксплуатацию как один из этапов. Обсуждение http://www.smartsourcing.ru http://sd-naumen.livejournal.com/
Описание слайда:
Источники SCRUM http://ru.wikipedia.org/wiki/Scrum. Гибкая методология разработки ПО. ГОСТ Р ИСО/МЭК 12207-99 Разработан именно для ПО. Определяет требования к организации процессов и взаимодействий на всем жизненном цикле ПО. В частности, рассматривает эксплуатацию как один из этапов. Обсуждение http://www.smartsourcing.ru http://sd-naumen.livejournal.com/

Слайд 27


Голосование 4 Ваше мнение о содержании прошедшего вебинара? Было интересно и актуально, хочу узнать больше Мало конкретики про автоматизацию Тема не интересна Другое (поясните в чате)
Описание слайда:
Голосование 4 Ваше мнение о содержании прошедшего вебинара? Было интересно и актуально, хочу узнать больше Мало конкретики про автоматизацию Тема не интересна Другое (поясните в чате)

Слайд 28


Спасибо за внимание! Обращайтесь к нам и нашим партнерам
Описание слайда:
Спасибо за внимание! Обращайтесь к нам и нашим партнерам

Скачать

Похожие презентации
Mypresentation.ru
Загрузить презентацию