Менеджмент разработки программных изделий 5 ориентированных программных проектов

реклама
Менеджмент разработки
программных изделий
5. Моделирование жизненного цикла объектноориентированных программных проектов
1
Принципы объектно-ориентированного
проектирования
Итеративность развития — возможность перейти от последовательного развития к
стратегии итеративного наращивания возможностей
2.
Изменение функциональности — пересмотр требований при развитии проекта
3.
Формирование системы понятий проекта — развивающийся глоссарий проекта
4.
Наращивание функциональности в соответствии со сценариями — реализация
выделенных сценариев; последующие итерации реализуют другие сценарии
5.
Ничто не делается однократно — отказ от завершенности работ классических
этапов, повторное прохождение их на новых итерациях (с новым набором сценариев)
6.
Оперирование на размножающихся фазах подобно — обычные этапы при
выполнении любой итерации развития проекта:
•
Определение требований, или планирование итерации;
•
Анализ;
•
Моделирование пользовательского интерфейса /новое/;
•
Конструирование;
•
Реализация (программирование);
•
Тестирование;
•
Оценка результатов (итерации)
Вне итераций:
1.
Начальная фаза проекта: требования, ближайшая и перспективные задачи,
критерии оценки результатов;
2.
Фаза завершения проекта: поставка и сопровождение + выделение
переиспользуемых компонентов
1.
2
Моделирование при объектноориентированном проектировании
1.
Распределение реализуемых требований
по итерациям: Совокупность сценариев,
реализуемых на очередной итерации + набор
ранее реализованных сценариев образуют
законченную, хотя и неполную версию системы,
предлагаемую пользователям
2.
— модели уровня анализа
Особый стиль наращивания
возможностей системы и ее развития:
Основа декомпозиции проекта при ООП подходе
— набор связанных различными отношениями
классов; новая итерация расширяет этот набор.
Это расширение строится на базе построения
Моделирование —
организационнотехническая
(производственная)
функция всего
процесса развития
проекта, а не один
из этапов!
— моделей уровня конструирования
Следствие:
Пополнение базового окружения проекта — дополнительный
этап (вложенный в оценку), содержание которого — анализ
возможного переиспользования накапливаемых компонентов ПО
как для проекта, так и для будущего
3
Жизненный цикл при объектно-ориентированном
развитии проекта (фазовое измерение)
Начало
проекта
Итеративное
зацикливание
Завершение
Декомпозиция
решаемых
проектом
(итерацией)
задач.
Начало
этапа пополнения
базового
окружения
проекта:
У разработчиков
появилась
возможность
проверки
Построение
архитектуры,
подготовка
реализуемых
▪ выделение
общих
лишь
для
данного
проекта
проекта
априорных
суждений
о проекте
(итерации)
на практике.
Архитектура
утверждена,
задачи
распределены
между
сценариев
для
утверждения,
определение
реализуемых
переиспользуемых
компонентов
Важно:
слияние контрольных
точек 3, 4, 5 и объявление
разработчиками
(группами)
Пополнение базового
модулей
▪ выделение
общих,
неАнализ
привязанных
к проекту

осуществимоточки
6 как вехи
в быстрых
методологиях
не означает
окружения проекта
Начало
Фазы
завершения
Оформлениекомпонентов
принимаемых
для новой
итерации
требований.
Исследования
сти процессов!
переиспользуемых
ликвидации
соответствующих
Взаимодействие
с планировщиком
с целью
выяснения
Все,
чторабот
представляет
проект
(итерацию)
как—
(бета-тестирование):
Одновременное
существование
двухНачало
(возможно,
более)
над проектом
(замысел).
Цель
указать
итерации
КонструироСбор сведений
для новой
Начала
стационарного
цикла
развития
проекта.
Различия
возможностей
предоставления
ресурсов
для
проекта.
Окончание
работ
развивающуюся
разработку
утверждается.
▪априорных
поставка
Фазыверсий системы. Время длявание
ревизиина
гипотез,
потребность
проектных результатов, фиксировать
первой
и
последующих
итераций:
формирование
и
Планирование
предоставления
ресурсов
это
момент
подведения
первых
итогов проекта
▪Важно:
сопровождение
корректировка показателей и нормативов
проекта
стратегию,
обозначить
ресурсные
потребности,
планы
(этапы)
 Программирование

корректировка
критериев
предпочтения того, что
▪(итерации)
этап окончания
работ исполнителей
формирования
команды
 Оценка для реализации
 и др.
считается целесообразным
 Использование
Контрольные
точки
(события):

5 Спецификации утверждены
Новое качество: у версии
появляются пользователи,
4 Спецификации реализуемых сценариев составлены
нуждающиеся
в обслуживании
3 Требования
к очередной
итерации утверждены
Оповещение
о прекращении
сопро6 Автономная проверка завершена,
и сворачивание
деятель2вождения
Требования
к очередной
Возможно
откладывание
тестирование
итерации
сформулированы
ности
по поддержке
версии
или всехкомплексное
события (на
определенный
началось
1 Ресурсы
распределены
версий
к определенному
сроку срок)
или неопределенный
Общие
0 Необходимость разработки признана
требования
Тестирование завершилось, начата подготовка век
и общий план
подготовка новой итерации 7
составлены,
Требования к новой итерации приняты 8
ближайшая и
перспективная
Начато использование изделия 9
задачи, критерии
Изделие или его версия передано на распространение 10
оценки
Извещение о прекращении поддержки изделия (версии) выпущено 11
результатов
определены
Изделие (версия) снято с производства 12
Контрольные точки и вехи
•
•
•
•
•
Контрольные точки (check points) — точки линии жизни жизненного цикла
проекта, в которых возникают определенные события. Эти события
рассматриваются как существенные, поскольку их необходимо отслеживать с
целью управляемого развития проекта (такого, которое оставляет траекторию в
рамках области допустимых операционных маршрутов)
Вехи (mail stones) — это контрольные точки, прохождение которых
сопровождается определенными планируемыми мероприятиями. Без
успешного (результат соответствует цели) проведения таких мероприятий,
прохождение вехи блокируется с целью выполнения активностей,
направленных на исправление ситуации.
Оценка полученных результатов и планирование получения
результатов — основное содержание деятельности, связанной с вехами
Конкретизация контрольных точек и вех — задача, которую приходится
решать в рамках выполнения функции планирования. Эта конкретизация
делается на основе знания специфики выполняемого проекта и процесса его
выполнения (т.е. принятой для проекта методологии). Специфика проекта и
процесса определяет необходимость и количество вех.
В жестких методологиях к прохождению вехи приурочивается утверждение
соответствующих ей рабочих продуктов, в том числе и документов; быстрых
методологиях вехи служат лишь ориентирами продвижения в своем развитии
(мероприятия не имеющие отношения к процедурам утверждения)
5
Общие требования, общий план,
ближайшая и перспективные задачи
Для каждой итерации должны быть определены:
•
Общие требования — что требуется от проекта в целом в данный момент
•
Общий план — как предполагается достигать цели (стратегия)
•
Ближайшая задача — набор конкретных реализуемых требований и
сценариев ← критерии предпочтения того, что планируется реализовывать
•
Перспективные задачи — те, которые рассматриваются (в данный
момент) как основа для планирования дальнейших итераций (в проектах
жесткой отчетности)
Характеристики значимости:
•
Критерии предпочтения:
1)
2)
Актуальность для пользователя
Полнота и функциональная
замкнутость предлагаемых средств
–
–
–
3)
4)
5)
Функциональная полнота
Реализационная полнота
Интерфейсная полнота
Системная значимость
(внутрипроектные предпочтения)
Демонстрационная значимость
Скорость реализации
Иногда время
Возможные ограничения: время, объем
не критерий, а
работ, затраты (треугольник менеджмента)
ограничение
Минимизация реализуемого является критерием
лишь для некоторых методологий!
Всегда лучше то, что актуально!
Автоматизация деятельности в целом.
Растет по мере увеличения объема уже
выполненных работ
Реализационные предпочтения.
Конкурирует с (1). Более значим для
начальных итераций
Конкурирует с (1), (2) и (3)
Максимально значимо для начальных
итераций
Лучше то, что быстрее. Если время
фиксировано, то для реализации
определяется пул работ.
6
Жизненный цикл при объектно-ориентированном
развитии проекта (функциональное измерение)
 Исследова-
Пополнение
базового окружения
проекта
ния
Итеративное зацикливание
Анализ осуществимости 
Конструирование
 Программирование 
 Оценка
Фазы
(этапы)
Окончание работ

 Использование 
Планирование
Разработка
Обслуживание
Выпуск документации
Испытания
Поддержка
Сопровождение
Моделирование
0
1
2
3
4
5
6
7
Контрольные точки (события)
8 9 10
11 12
7
Оценка как технологическая функция
 Исследования
Пополнение
базового
окружения
проекта
Итеративное зацикливание
Анализ осуществимости 
Конструирование
 Программирование
Фазы
(этапы)
Окончание работ

 Оценка

 Использование 
Оценка
0
1
2
3
4
5
6
7
8 9 10
11 12
Контрольные точки (события)
8
Непрерывность поступления требований в
моделях жизненного цикла
Трассировка требований (в модели Гантера)
• Варианты поступления требований:
– требование или группа требований обрабатываются
до начала итерации (при разработке ее сценариев)
– требование или группа требований поступают,
когда работы итерации начались
– требование или группа требований поступают,
когда релиз системы передан в эксплуатацию
• Возможные результаты анализа требований:
Укладывается в представленную ранее схему
модели фазы – функции
Схема дополняется
мини-циклом обработки
требований
До мини-цикла необходим
предварительный анализ
требований
– требование отклоняется — работа с требованием прекращается
– требование принимается к реализации на текущей итерации
– реализация требования откладывается до следующих итераций
Функциональное измерение меняется, но учесть это вне контекста
конкретного проекта нереально
Почти все модели жизненного цикла слабо приспособлены к учету
непрерывности поступления требований
9
Жизненный цикл при объектно-ориентированном
развитии проекта (фазовое измерение)
Начало проекта
Исследования
Фазы
(этапы)
Итеративное зацикливание
 Анализ осуществимо-
сти 
 Конструирование
Варианты
решения
Завершение
проекта
Требование реализуется на
более поздней итерации
 Программирование

 Оценка
Пополнение базового
окружения проекта
Окончание работ

 Использование
Контроль- 0
ные точки
(события):
1
2
3
4
Требование
отклоняется
Анализ нового требования
5
6
7
8 9 10

11 12
Требование реализуется на текущей итерации
 (a) Требование поступило, начало мини-цикла
 (b) Решение о требовании принято
Шаги обработки требования или группы требований:
• поступление — в любой момент конструирования, программирования или оценки
• расщепление, переход к анализу
• анализ
• принятие решения /на общем участке этапов анализа и конструирования/
• планирование срока или будущей итерации реализации
10
Требования, поступающие в ходе
эксплуатации
Начало
проекта
Исследования
 Использование

 Период
сопровождения 
 Анализ осуществи- Пополнение
мости 
Первичный
анализ
базового
 Конструироокружения
вание
проекта
Программирование
 Оценка
Фазы
(этапы)
Контрольные точки 0
(события):
Завершение проекта
Итеративное зацикливание
1
2
3
4
5 6
7

8
9
Окончание
Решение
работ
реализовать:
• в другом проекте
• в следующих релизах
• в текущем релизе
• немедленная реакция
10
11 12
Требование
 Реализация требований

отклоняется
Накопление, системаПроверка
тизация и группировка
реализации 
требований
 (b) Решение о требовании
Сообщение о требовании поступило (a) →
принято
Решение о реализации ама
Извлечение
требований принято (c) →
требования
11
Шаги обработки требований
•
•
Поступление сообщения, содержащего требования — в любой момент периода
сопровождения
Первичный анализ — принятие первоначального решения о реализации:
–
–
–
–
–
•
•
•
немедленная реакция — быстрое устранение замечаний, пояснения для пользователей и др.
Выполняется всегда, в том числе совместно с другими решениями
требование отклоняется — объяснение причин отклонения, путей преодоления трудностей
реализация требования в текущем релизе — если претензии обоснованы, а устранение
замечаний, ошибок и т.п. возможно в обслуживаемом релизе, то организуется мини-цикл
обработки требований в итерации
реализация требования в одном из следующих релизов — если устранение замечаний в
рамках обслуживаемого релиза невозможно или нецелесообразно, то требование передается
для исполнения на одной из следующих итераций проекта
реализация требования в другом проекте — если выясняется, что в данном проекте
требование реализовать невозможно или нецелесообразно, то, быть может, оно станет одним
из аргументов в пользу организации нового проекта
Мини-цикл обработки требований начинается с анализа (возобновленный процесс),
определяющего группу требований для реализации в текущем релизе в рамках
обычных задач этапа
Реализация отобранных требований на данной итерации осуществляется по обычной
схеме: конструирование, программирование, оценка. Особая роль проверочных работ
— дополнительный этап проверки реализации. Обязательно повторение проверки
того, что было отлажено ранее (пополнение тестовой базы)
Распространение изменений — сделанные исправления должны стать доступными
для всех пользователей. При массовом применении эта работа может потребовать
значительных ресурсов
12
Действия, связанные с новыми
проектными требованиями
•
•
Требования, возникающие и изменяемые в течение этапов итерации, разделяются на
принимаемые и отвергаемые
Для каждого отвергаемого требования составляется мотивированное заключение о
том, почему оно не принимается:
–
–
–
–
•
•
Заключение согласовывается с автором требования и с заказчиком
Для каждого из принимаемых требований (их элементарных составляющих)
определяется, когда оно может быть удовлетворено и когда его целесообразно
удовлетворять. Критериями служат:
–
–
•
•
•
•
•
невозможно удовлетворить,
нецелесообразно принимать (достижимо иным путем),
запланировано в качестве перспективы,
может быть принято при изменении финансовых и календарных планов и др.
приоритетность требования;
сложность рабочих продуктов и зависимостей рабочих продуктов от требования;
Простые требования реализуются непосредственно в момент утверждения;
Сложные требования откладываются до завершения конструкторских работ
итерации, которое рассматривается как начало работ по учету комплекса
предъявленных требований;
Требования, откладываемые до последующих итераций, реализуются согласно
общему плану проекта (корректируемому)
Учитывается, что ранее принятое требование может оказаться отвергнутым
вследствие принятия новых требований → необходимо подготовить и согласовать с
автором требования и заказчиком заключение об отказе от реализации требований,
Изменения планов и объемов работ, возникающие и/или планируемые в связи с
изменениями требований, всегда согласуются с заказчиком.
Скачать