1. Оценка эффективности от внедрения и использования методологии и инструментальных средств IBM Rational. Обзор технологии IBM Rational Новичков Александр

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

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

13. Посчитаем ежегодные затраты $50278 ИТОГО (ежегодные затраты без оптимизации) $24000 15-18% Поддержка вендора (стоимость лицензий) $26278 Внутр: 1,5 специалиста * 30-35% рабочего времени Внедр: 15-25% стоимости контракта внедрения Стоимость поддержки (внутренняя + поддержка внедрившей организации) Расчет Специалист / работа

14. Посчитаем . Эффект по годам

15. Отрицательные эффекты

16. Положительные эффекты

18. Статистика использования лицензий за 3 года. «Фотография» одного рабочего дня

19. Качественный эффект от автоматизации тестирования

20. Эффективность обработки запросов от бизнеса

21. Эффективность на уровне разработки Относительное влияние средств конфигурационного управления с увеличением сложности задачи

28. Место систем IBM Rational в ряду КИС

31. Модель трассировки: от запроса HP SD до кода и тестов

33. IBM Rational Software Delivery Platform

37. Способы формирования требований

38. Управление требованиями Разметка требований Трассировка требований Формирование Use Case диаграмм Определение типов и атрибутов требований

43. Диаграмма состояний Запроса

44. Диаграмма состояний Запроса

45. Техническая реализация Запроса

46. Диаграмма состояний Задачи

47. Диаграмма состояний Дефекта

48. Общий вид формы запроса на изменение

49. Планирование и реализация запроса

50. История изменений (журнал)

51. WEB- доступ

52. IBM Rational ClearQuest и модуль проектного управления

53. Статистика по запросам на изменение

54. Статистика по запросам на изменение

55. Консолидированный отчет по Дефектам и Задачам

56. Отчетность в ClearQuest Время жизни запроса в днях. До одного, 1-2 дня и более двух дней. Отчет позволяет отслеживать эффективность реакции исполнителей на разных этапах исполнения

58. ClearCase – ключ к созданию автоматизированных систем качества производства ПО

61. Простая модель версионного управления

62. Традиционная модель

63. Возможный вариант версионного дерева в ClearCase

65. Интеграция с Borland

66. Интеграция на уровне ОС

67. Сравнение и слияние версий . Связь версий с запросами на изменение Сравнение версий Слияние версий Запросы на изменение Версия элемента

74. Отчетность Тренды по проекту или команде Детализация Текущий статус итераций

78. Пирамида значимости составляющих процесса Фундамент процесса (стандарты) Цели и задачи процесса Роли, виды деятельности Метрики и отчеты Средства реализации Элемент средства

79. Адаптация и внедрение процессов Горизонтальное внедрение Вертикальное внедрение Моделирование Управление требованиями УК и УИ Тестирование В организацию Управление проектом Для подразделения Для проекта

81. Спецификация SPEM (Software Process Engineering Metamodel ) Выполняют Артефакты (документы, продукты) Отвечают Роли Задачи Процессы (дисциплины) Работы Шаблоны документов Инструментальная поддержка Стадии Жизненный цикл

83. Дисциплина УК в «коротком» и «большом» RUP Большой Короткий Наименование задачи Да Нет Написать план управления конфигурацией (УК) Да Нет Подтвердить изменения в сборке Да Нет Обновить рабочее пространство Да Нет Обновить запрос на изменение Да Да Внести запрос на изменение Да Да Настроить среду управления изменениями Да Да Рассмотреть запросы на изменения Да Нет Создать отчёт о состоянии конфигурации Да Нет Продвигать базовые версии Да Нет Провести аудит конфигурации Да Нет Внести изменения Да Нет Установить политику управления конфигурацией (УК) Да Нет Наладить процесс управления изменениями Да Нет Применить изменения Да Нет Создать рабочие пространства интеграции Да Нет Создать рабочие пространства разработки Да Нет Создать единицу развертывания Да Нет Создать базовые версии Да Да Подтвердить повторный или отклонённый запрос на изменение Задачи Управление конфигурацией и изменениями

84. Пример адаптации задачи «Create Project (CM) Environments» Так было Так перевели Так сейчас Так адаптировали

86. Пример описания проектной фазы

87. Пример описания проектной фазы

88. Структурная схема управления Проектом

89. Структура проектной НМД

90. Структура классификатора проектов

91. Структура НМД процесса разработки

102. Интерпретация некоторых метрик - 1 Анализируется увеличение или уменьшение усилий разработчика во времени. На предварительных этапах метрику можно использовать для прогноза. Понимание того, насколько интеллектуально-затратной для разработчика была та или иная функция. Для определения сложности реализации того или иного блока кода (класса, функции и т.д.) Усилия программиста при разработке. Сложность растет или нет? Используем для прогноза сложности на ранних этапах на основе статистики. Оценку сложности изменений Анализ цикломатической сложности. Увеличивается или уменьшается объем программы во времени. Используем для прогноза сложности на ранних этапах на основе статистики. Оценку объема изменений Длина и объем программы Можно анализировать усилия разработчика во временном срезе или в срезе по релизам или проектам. Выявлять, на каких задачах программист полностью выкладывается, а какие ему не по душе. Тренд позволит менеджеру лучше понимать, кто и каких задачах максимально эффективен при формировании команды нового проекта, а также какие подсистемы относительно сложны, а какие – просты. Точность прогнозов оценки трудоемкости при выполнении организацией типовых или мало отличающихся запросов Насколько эффективен труд разработчика. Усилия разработчика при реализации. Анализ на основе статистических данных (как тренд, так и прогноз) Влияет на… Зачем нужен Фактор

103. Интерпретация некоторых метрик - 2 Анализ на основе статистических данных (как тренд, так и прогноз) Влияет на… Зачем нужен Фактор Глубокий анализ изменений по релизам (версиям, сборкам) дает понять: Количество изменений (на что угодно) – сколько раз один и тот же блок кода корректировался. Возможно выявить узкое место в программе: интенсивно меняющийся блок кода может влиять на общее качество программы (потенциальное место возникновения ошибок). Возможно, необходимо изменить архитектуру блока. Количество добавленных, удаленных и измененных строк по отношению к предыдущей версии. Отношение новых функций к измененным. Прочие количественные метрики (число функций, классов, файлов). Общая культура разработчиков растет или нет? Если растет – хорошо. Если нет – плохо. Если скачкообразно – соотносим менеджеровуководителей проектов со скачками. Выделяем сложные проекты, проблемные модули или подсистемы Качество кода, его прозрачность. Код должен быть документирован. Если соотношение кода к комментарию не 1:4, то разработчик обязан доработать. Количество комментариев на единицу кода. Сигнал опасности при выявлении увеличения количества строк во время выполнения типового запроса Используем для оценки сложности на ранних этапах на основе статистики. Понимание КПД.Отслеживаем всплески. Меряем общую температуру. Эта метрика принимается во внимание при анализе реализации запроса. Количество строк на реализацию требования.