* Best Practices of Project Execution According to IBM Rational

Лучшие практики методологии разработки ИС

Михаил Кумсков Luxoft

Lead Expert on System Analysis and Business Systems, Professor At Lomonosov Moscow State University

Учебный Центр ЛюксофтLuxoft-training.com

itarena.lviv.ua/

itarena.lviv.ua/*Историческая справка

2000

1998

1995

1994

28%23% 49%

26%28% 46%

27%40% 33%

16%31% 53%

На диаграмме изображены результаты разработки 30,000 приложений в больших, средних и малых компаниях США, работающих в различных секторахи тестировавшихся Standish Group с 1994 года.

Источники: The Standish Group International, "CHAOS 2005", "Extreme Chaos", "Chaos Report", 1994-2004

SucceededChallengedFailed

2004 34%15% 51%

itarena.lviv.ua/*Сложность*Метафора «Хомячок и Медведь»

itarena.lviv.ua/

* Develop only what is necessary* Lean process, agility

*Minimize paperwork* Be flexible* Requirements, plan, usage of people,

etc…* Learn from earlier mistakes* Feedback loops* Process improvement

* Revisit risks regularly* Establish objective, measurable criteria

for progress* Automate* Support process with software

development tools

Best PracticesProcess Made Practical

Develop IterativelyManage Requirements

Use Component Architectures

Model Visually (UML)Continuously Verify Quality

Manage Change

itarena.lviv.ua/

1.Attack major risks early and continuously… or they attack you

2.Ensure that you deliver value to your customer3.Have a maniacal focus on working software4.Accommodate change early in the project5.Baseline an executable architecture early on6.Build your system with components7.Work closely together as one team8.Make quality a way of life, not an afterthought

itarena.lviv.ua/

* Взаимодействие с партнерами* Поощрение открытого общения* Общее видение проекта* Качество – это ежедневная работа каждого

сотрудника* Оставайтесь гибкими, адаптируйтесь к

изменениям* Внедрение проекта должно стать привычкой* Постоянная демонстрация прогресса для

заказчика

itarena.lviv.ua/

Лучшие ПрактикиСделайте Процесс Реальным

Разрабатывайте ИтеративноУправляйте Требованиями

Используйте Компонентную Архитектуру

Моделируйте Визуально (UML)

Постоянно Проверяйте Качество

Управляйте Изменениями

*Разрабатывайте Итеративно

itarena.lviv.ua/* Каскадная модель ЖЦ ПО (waterfall)

Анализ

Проектирование

Кодирование

Интеграция

Внедрение

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

Winston Royce, 1970

Стандарт МО США

DOD 2167A

itarena.lviv.ua/*Характеристики Каскадной Разработки

*Задержки подтверждений снятия критических рисков*Измеряет процесс по оценке рабочих продуктов, плохо прогнозируется время завершения проекта*Поздно проводит интеграцию и тестирование.*Нет ранней поставки прототипа заказчику*Редко заканчивается в срок – незапланированные итерации

Код-е и тест-е

Дизайн

Интеграция подсистемы

Тест-е системы

Каскадный Процесс

Анализ требований

Планирование

itarena.lviv.ua/Принципы «чистого» каскадного подхода:

• Фиксация требований к системе до ее сдачи заказчику

• Переход на следующую стадию только после полного завершения работ на текущей стадии, без возвратов на пройденные стадии

Преимущества :· на каждой стадии формируется законченный набор проектной

документации, отвечающий критериям полноты и согласованности

· выполняемые в логичной последовательности стадии работ облегчают планирование сроков завершения всех работ и соответствующих затрат

itarena.lviv.ua/* Реальный процесс разработки ПО

Анализ

Проектирование

Кодирование

Интеграция

Внедрение

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

itarena.lviv.ua/

• Позднее обнаружение проблем• Выход из календарного графика,

запаздывание с получением результатов• Избыточное количество документации• Невозможность разбить систему на части

(весь продукт разрабатывается за один раз)• Высокий риск создания системы, не

удовлетворяющей изменившимся потребностям пользователей

Выход из положения - итерационный подход

Недостатки каскадного подхода:

itarena.lviv.ua/Спиральная модель ЖЦ ПОBarry Boehm, 1988

itarena.lviv.ua/

¨ Идентификация и анализ риска на каждой итерации¨ Назначение приоритетов пользовательским

требованиям¨ Разработка последовательности прототипов, начиная

с требований наивысшего приоритета¨ Использование каскадной модели для реализации

окончательного прототипа¨ Оценка результатов по завершении каждой итерации

и планирование следующей итерации¨ Завершение проекта при нецелесообразности его

продолжения

Основные особенности «спиральной» модели

itarena.lviv.ua/

Виды прототипов

Прототип пользовательского интерфейса

Функциональный прототип

Исследовательский прототип

Основные особенности итерационной модели разработки ПО

itarena.lviv.ua/

Достоинства:· ускорение разработки (раннее получение

результата за счет прототипирования)· (!) постоянное участие заказчика в процессе

разработки· разбиение большого объема работы на

небольшие части· снижение риска (повышение вероятности

предсказуемого поведения системы)

Основные особенности итерационной модели разработки ПО

itarena.lviv.ua/

Проблемы:· сложность планирования (определения

количества и длительности итераций, оценки затрат и рисков)

· сложность применения модели с точки зрения менеджеров и заказчиков

· напряженный режим работы для разработчиков

Основные особенности итерационной модели разработки ПО

itarena.lviv.ua/

Время (месяцы)

Реализация(% кода)

100908070605040302010

Каскаднаяразработка

Устранениеобнаруженныхпроблем

Демо

Итерационнаяразработка

Демо

Демо

Тестирование

Началосборки

Сопоставление каскадного и итерационного подхода

itarena.lviv.ua/* Характеристики Итеративной Разработки

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

процессВыделяет краткосрочные объективные проектные стадииДает возможность поставки по частям

ВРЕМЯ

Итерация 1 Итерация 2 Итерация 3 П

АД

КИ

T

ПА

ДК

ИT

ПА

ДК

ИT

itarena.lviv.ua/

Результат каждой итерации –

исполнимый прототип ПО

* Итеративная Разработка

itarena.lviv.ua/

Время

Риск

Каскадный Риск

Итеративный Риск

*Профиль Риска

Сокращение Риска

itarena.lviv.ua/*Управляйте ТребованиямиЛучшие Практики

Сделайте Процесс Реальным

Разрабатывайте ИтеративноУправляйте Требованиями

Используйте Компонентную Архитектуру

Моделируйте Визуально (UML)

Постоянно Проверяйте Качество

Управляйте Изменениями

itarena.lviv.ua/

Решайте «верную» проблему и создавайте «правильную»систему

Систематический подход к:

*Пониманию проблемы*Выявлению, организации и документированию требований*Управлению изменяющимися требованиями программного приложения.

*Управление Требованиями

itarena.lviv.ua/* Используйте Компонентную Архитектуру

Лучшие ПрактикиСделайте Процесс Реальным

Разрабатывайте ИтеративноУправляйте Требованиями

Используйте Компонентную Архитектуру

Моделируйте Визуально (UML)Постоянно Проверяйте

КачествоУправляйте Изменениями

itarena.lviv.ua/*Гибкие Компонентные Архитектуры

Гибкие*Соответствуют настоящим и последующим требованиям*Улучшают расширяемость*Позволяют повторно их использовать*Формируют системные взаимосвязи

Компонентные*Используют компоненты повторно или подстраивают их

под требования заказчика*Выбирают из коммерчески доступных компонентов*Развивают существующие программные продукты по

частям

itarena.lviv.ua/*Цель Компонентной Архитектуры

Основа для повторного использования*Компонент *Архитектура

Основа для управления проектом*Планирование*Персонал*Поставка

Интеллектуальный контроль*Управление сложностью*Поддержание целостности

Система-программа

Промежуточный слой

Специфична для бизнеса

Специфична для приложения

Компонентная архитектура по

слоям

itarena.lviv.ua/*Моделируйте Визуально (UML)

Лучшие ПрактикиСделайте Процесс Реальным

Разрабатывайте ИтеративноУправляйте Требованиями

Используйте Компонентную Архитектуру

Моделируйте Визуально (UML)

Постоянно Проверяйте Качество

Управляйте Изменениями

itarena.lviv.ua/* Зачем Моделировать Визуально?Зафиксировать структуру и поведениеПоказать, как системные элементы согласуются друг с другом

Согласовать дизайн и реализациюСворачивать и разворачивать детали где уместно

Поддерживать бесконфликтное общение

ДиаграммаАктивностей

Модели

Статические Диаграммы

Последов.Диаграмма

СовместнаяДиаграмма

StatechartДиаграмма

ДиаграммаПоставки

ДиаграммаКомпонентов

ДиаграммаОбъектов

ДиаграммаКлассовДиаграмма

СИ

UML создает единый язык для всех специалистов.

itarena.lviv.ua/*Постоянно Проверяйте Качество

Лучшие ПрактикиСделайте Процесс Реальным

Разрабатывайте ИтеративноУправляйте Требованиями

Используйте Компонентную Архитектуру

Моделируйте Визуально (UML)

Постоянно Проверяйте Качество

Управляйте Изменениями

itarena.lviv.ua/Характеристики Качества

НадежностьТестируйте

приложение на постоянное и предсказуемое

поведение.

ПродуктивностьТестируйте отклик ПО

online под средней и пиковой загрузкой

Функциональность

Тестируйте функции на основе Сценариев Использования

ПрименимостьТестируйте

приложение с точки зрения удобства

для конечного пользователя.

ПоддержкаТестируйте легкость

сопровождения и поддержки ПО в рабочем

состоянии

itarena.lviv.ua/* Постоянно Проверяйте Качество Программы

Цена

Найти и устранить программные проблемы после поставки в 100 и

более раз дороже

Цена исправления ПО Цена потерь возможностей Цена потери заказчиков

itarena.lviv.ua/

Модель UML и реализация

Тесты

Итерация 1

Набор тестов 1

Итерация 2

Набор тестов 2

Итерация 3

Набор тестов 3

*Тестируем Каждую Итерацию

Набор тестов 4

Итерация 4

itarena.lviv.ua/*Управляйте Изменениями

Лучшие ПрактикиСделайте Процесс Реальным

Разрабатывайте ИтеративноУправляйте Требованиями

Используйте Компонентную Архитектуру

Моделируйте Визуально (UML)

Постоянно Проверяйте Качество

Управляйте Изменениями

itarena.lviv.ua/

Заявки на изменение приходят из многих источников в период жизненного цикла продукта.

*Управление Запросами на Изменения

Влияние Пользователя Help Desk

Влияние Программистов и Тестеров

Влияние Заказчика и Пользователя

Маркетинг

Новое Свойство

Новое Требование

Ошибка

Утвержденный Процесс Принятия

Решений на Комитете по Контролю за Изменениями

(CCB)

Единый канал на одобрение

Заявка на Изменение (CR)

Треб

Дизайн

Код

Тест

Сопр

Weinberg, ‘95

itarena.lviv.ua/* Лучшие Практики Усиливают Друг Друга

Привлекает пользователей по мере возрастания требований

Лучшие Практики

Разрабатывайте Итеративно

Управляйте Требованиями

Используйте Компонентную Архитектуру

Моделируйте Визуально (UML)

Постоянно Проверяйте Качество

Управляйте Изменениями

Проверяет архитектурные решения на ранних этапах

Рассматривает сложность дизайна/постепенная

реализация

Качество измеряется заранее и часто

Постепенное развитие исходного плана проекта

itarena.lviv.ua/*Резюме

*Лучшие Практики организуют программную разработку так, чтобы снять корневые причины неудачи проекта

*Лучшие Практики усиливают друг друга

*Процесс руководит командой: кто, что, когда и как делает

*IBM RUP - это средство достижения Лучших Практик

itarena.lviv.ua/* IBM RUP Реализует Лучшие Практики

Лучшие ПрактикиСделайте Процесс Реальным

Разрабатывайте Итеративно

Управляйте Требованиями

Используйте Компонентную Архитектуру

Моделируйте Визуально (UML)

Постоянно Проверяйте Качество

Управляйте Изменениями

itarena.lviv.ua/*Реализация Лучших Практик

* Итеративный подход* Руководство по Задачам

и рабочим материалам* Процесс,

ориентированный на архитектуру

* Сценарии Использования управляют дизайном и реализацией

* Модели, документирующие ПО

itarena.lviv.ua/*Что такое IBM Rational Unified

Process - RUP?

Философия и практика успешной разработки ПО, набор принципов, сформулированных на основе анализа реального опыта разработки ПО

Формальное описание процесса разработки ПО

Web-сайт, содержащий формальное описание процесса разработки ПО

itarena.lviv.ua/Определение Командного

ПроцессаПроцесс определяет Кто делает Что, Когда и Как для достижения определенной цели

Новые или измененные

Требования

Новая или измененная

Система

Процесс работы

itarena.lviv.ua/

Inception Elaboration Construction Transition

*Структура Процесса – Фазы Жизненного Цикла

RUP

Время

Управляйте бизнес рисками(финансовая пригодность проекта)

Управляйте техническими рисками проекта

Управляйте рисками по “переделкам и исправлениям”

Управляйте рисками по организации поставки ПО

itarena.lviv.ua/*Итерации и Фазы

Итерация - это четкая последовательность активностей, основанных на установленном плане и критериях разработки, результатом которой является

выполняемый запуск программы в производство (внутреннее или внешнее).

Первичная Итерация

Архитектурная Итерация

Архитект. Итерация

Итерация Разработки

Итерация Разработки

Итерация Передачи

Итерация Передачи

Малые Стадии (ОЖЦ, АЖЦ, НФВ): Выпуски продукта

Inception Elaboration Construction Transition

itarena.lviv.ua/*Соединяем Все Вместе: Итеративный Подход

Активности сгруппированы в

дисциплины

В одной итерации вы проходите все дисциплины.

itarena.lviv.ua/

*Дисциплины Формируют

Модели

Модели

Бизнес Модель по СИ

Реализуется

Бизнес Модель по Объектам

Дизайн Модель Модель Реализации

Модель СИ

Реализуется

Автоматизируется

Реализуется

*Дисциплины

РеализацияАнализ и Дизайн

ТребованияБизнес моделирование

itarena.lviv.ua/*Итеративная Разработка по ДисциплинамРабочий Цикл Бизнес

Моделирования

Рабочий Цикл Требований

itarena.lviv.ua/

Управление проектомСоздание инфраструктуры

Построение бизнес-моделей

РеализацияТестирование

Анализ и проектирование

Предварит.итерация

Итер.#1

Стадии

Основные процессы

Итерации

Вспомогательные процессы

Итер.#2

Итер.#n

Итер.#n+1

Итер.#n+2

Итер.#m

Итер.#m+1

Развертывание

Управление конфигурацией и изм.

Определение требований

Разработка Ввод вдействие

Начальнаястадия Конструирование

*Общее представление RUP

itarena.lviv.ua/*Сопоставление RUP с другими подходами

Каскадный подход

Высокаяформализованность

Низкаяформализованность

Итерационный подход

Легкая конфигурация

RUP

Средняя конфигурация

RUP

Полная конфигурация

RUP

Agile Software Development CMMI

CMM

DOD-STD-2167A

MIL-STD-498

itarena.lviv.ua/*Проблемы программной инженерии – «тяжелые»

процессы

Проблемы «тяжелых» процессов: а) высокая стоимость; б) длительный и трудоемкий процесс внедрения

Альтернатива – адаптивный (гибкий) процесс

Особенности «тяжелого» процесса:• необходимость документировать каждое действие разработчиков• множество рабочих продуктов (в первую очередь - документов),

создаваемых в бюрократической атмосфере• отсутствие гибкости• детерминированность (долгосрочное детальное планирование и

предсказуемость всех видов деятельности, распределение человеческих ресурсов на длительный срок, охватывающий большую часть проекта

itarena.lviv.ua/* Идеи, определенные в Манифесте быстрой разработки (Agile Alliance's Manifesto) Личности и сотрудничество важнее

процессов и инструментальных средств Работающее ПО важнее полноты

документации Совместная работа с заказчиками

важнее формального контракта Реагирование на изменения важнее

строгого следования плану

itarena.lviv.ua/*Положения Манифеста быстрой разработки - 1

Наиболее приоритетной задачей является удовлетворение заказчика посредством ранней и частой поставки полезного ПО

Поставлять ПО следует часто, с интервалами от пары недель до пары месяцев, отдавая предпочтение более короткой временной шкале

Работающее ПО - основной критерий продвижения вперед

itarena.lviv.ua/*Положения Манифеста быстрой разработки -2

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

Бизнес-эксперты и разработчики работают совместно на протяжении всего времени выполнения проекта

Выстраивайте проекты вокруг мотивированных людей. Обеспечьте им необходимую среду, поддержку и доверьте выполнение работы

itarena.lviv.ua/

Наиболее эффективным способом передачи информации внутри команды разработчиков является общение лицом к лицу

Лучшие архитектуры, требования и проекты появляются в самоорганизующихся командах

Постоянное внимание к техническому совершенству и хорошее проектирование усиливают «быстроту»

*Положения Манифеста быстрой разработки -3

itarena.lviv.ua/

"Быстрые" процессы содействуют устойчивому развитию. Спонсоры, разработчики и пользователи должны быть способны неограниченно долго поддерживать постоянный темп

Простота - искусство максимально уменьшить объем необходимой работы - имеет очень важное значение

Через регулярные интервалы времени команда размышляет о том, как стать более эффективной, а затем соответственно изменяет свое поведение

* Положения Манифеста быстрой разработки - 4

itarena.lviv.ua/*Принципы Agile в оценке технологии

• Интерактивное общение лицом к лицу - это самый дешевый и быстрый способ обмена информацией

• Избыточная "тяжесть" технологии (доп. рабочие продукты, планы, диаграммы, документы) стоит дорого

• Более многочисленные команды требуют более "тяжелых" технологий

itarena.lviv.ua/*Принципы Agile в оценке технологии

• Большая формальность подходит для проектов с большей критичностью

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

• Дисциплина, умение и понимание противостоят процессу, формальности и документированию

• Потеря эффективности в некритических видах деятельности вполне допустима

itarena.lviv.ua/

Agile методы

*XP (Kent Beck)*SCRUM (Ken Schwaber)*Agile IBM Rational Unified Process (RUP)*Agile-MSF*…some others

itarena.lviv.ua/

* Взаимодействие с партнерами* Поощрение открытого общения* Общее видение проекта* Качество – это ежедневная работа каждого

сотрудника* Оставайтесь гибкими, адаптируйтесь к

изменениям* Внедрение проекта должно стать привычкой* Постоянная демонстрация прогресса для

заказчика

itarena.lviv.ua/*Управление и качество*Принцип 1 – Ориентация на потребителя

*Принцип 2 – Ключевая роль руководства фирмыРуководитель должен создать условия, необходимые для успешной

реализации всех принципов системного управления качеством

*Принцип 3 – Вовлечение сотрудниковКаждый работник должен быть вовлечен в деятельность по управлению

качеством. У каждого возникла внутренняя потребность в улучшениях

* Принцип 4 – Процессный подход к управлениюКаждый работник ОЦЕНИВАЕТСЯ ПО РЕЗУЛЬТАТАМ ВСЕГО ПРОЦЕССА. Владелец процесса отвечает за отработку запросов на улучшение ПРОЦЕССА и своей властью ИЗМЕНЯЕТ РЕГЛАМЕНТ ПРОЦЕССА

* Пятый принцип – Системный подход к управлениюПроизводство товаров, услуг и управление рассматривается как

совокупность взаимосвязанных процессов, а каждый процесс – как система, имеющая вход и выход, своих «поставщиков» и «потребителей» к управлению,

itarena.lviv.ua/*Управление и качество

*Принцип 6– Постоянное улучшение («Заточка пилы»)Устанавливать пределы улучшению недопустимо, само улучшение должно быть системой и составной частью системы управления. ПРОБЛЕМА МЕТРИК.

*Принцип 7– Принятие решений на ОСНОВЕ фактовНеобходимо собирать и анализировать фактические данные и принимать решения на их основе. Наиболее распространенными сейчас являются статистические методы контроля, анализа и регулирования

*Принцип 8 – Взаимовыгодные отношения с подрядчиками

по отношению, как к внешним, так и внутренним поставщикам

itarena.lviv.ua/*Выводы Сходство принципов «гибких» методологий и

процессного управления позволяет сделать практические выводы:

*Менеждерам ИТ-проектов следует знать принципы управления на основе качества и минимизации рисков*Менеджемент на основе качества хорошо

масштабируется (в отличии от обычного Agile подхода)

Эта масштабируемость была не раз показана на крупных и очень крупных предприятиях, включая Тойота

*Есть «свет в конце туннеля» –управляя на основе качества возможно введение крупных ИТ-проектов с соответствующим расширением Agile принципов

itarena.lviv.ua/*Цикл Деминга

Изменение стратегических систем контроля

 Скажи мне по каким показателям тебя оценивают и я скажу, как ты будешь себя вести.

И. Голдрат

itarena.lviv.ua/

«Я учу вас только одному – как делать больше прибыли»

Эдвард Деминг

Деминг - Теория управления на основе

качества

itarena.lviv.ua/*Выход из кризиса

itarena.lviv.ua/

• Крачтен Ф. Введение в Rational Unified Process. М.: Вильямс, 2002.

• Кролл П., Крачтен Ф. Rational Unified Process - это легко. Руководство по RUP для практиков: М.: КУДИЦ-ОБРАЗ, 2004.

• Поллис Г., Огастин Л., Лоу К., Мадхар Д. Разработка программных проектов на основе Rational Unified Process (RUP). М. 'Бином-Пресс', 2005.

• Соммервилл И. Инженерия программного обеспечения. 6-е издание.: Пер. с англ.: – М.: Вильямс, 2002

• Фатрелл Р., Шафер Д., Шафер Л. Управление программными проектами: достижение оптимального качества при минимуме затрат.: Пер. с англ.: – М.: Вильямс, 2003

*Литература

itarena.lviv.ua/* «Как наверху - так и внизу»

itarena.lviv.ua/

Вопросы?

itarena.lviv.ua/

*СПАСИБО ЗА ВНИМАНИЕ!

Skype: kumskov

E-mail: kumskov@mail.ru

mkumskov@luxoft.com

Докладчик: Михаил Кумсков

*Радость была?