1 Менеджмент разработки программных изделий 5.Моделирование жизненного цикла объектно- ориентированных программных проектов. - презентация

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

2 2 Принципы объектно-ориентированного проектирования 1.Итеративность развития возможность перейти от последовательного развития к стратегии итеративного наращивания возможностей 2.Изменение функциональности пересмотр требований при развитии проекта 3.Формирование системы понятий проекта развивающийся глоссарий проекта 4.Наращивание функциональности в соответствии со сценариями реализация выделенных сценариев; последующие итерации реализуют другие сценарии 5.Ничто не делается однократно отказ от завершенности работ классических этапов, повторное прохождение их на новых итерациях (с новым набором сценариев) 6.Оперирование на размножающихся фазах подобно обычные этапы при выполнении любой итерации развития проекта: Определение требований, или планирование итерации; Анализ; Моделирование пользовательского интерфейса /новое/; Конструирование; Реализация (программирование); Тестирование; Оценка результатов (итерации) Вне итераций: 1.Начальная фаза проекта: требования, ближайшая и перспективные задачи, критерии оценки результатов; 2.Фаза завершения проекта: поставка и сопровождение + выделение переиспользуемых компонентов

3 3 Моделирование при объектно- ориентированном проектировании 1.Распределение реализуемых требований по итерациям: Совокупность сценариев, реализуемых на очередной итерации + набор ранее реализованных сценариев образуют законченную, хотя и неполную версию системы, предлагаемую пользователям модели уровня анализа 2.Особый стиль наращивания возможностей системы и ее развития : Основа декомпозиции проекта при ООП подходе набор связанных различными отношениями классов; новая итерация расширяет этот набор. Это расширение строится на базе построения моделей уровня конструирования Моделирование организационно- техническая (производственная) функция всего процесса развития проекта, а не один из этапов! Следствие : Пополнение базового окружения проекта дополнительный этап (вложенный в оценку), содержание которого анализ возможного переиспользования накапливаемых компонентов ПО как для проекта, так и для будущего

4 5 Спецификации утверждены 6 Автономная проверка завершена, комплексное тестирование началось Программирование Оценка Использование Фазы (этапы) Тестирование завершилось, начата подготовка век подготовка новой итерации 7 Конт- рольные точки (события): Итеративное зацикливание Пополнение базового окружения проекта Общие требования и общий план составлены, ближайшая и перспективная задачи, критерии оценки результатов определены Окончание работ Начало проекта Исследования Завершение проекта Анализ осуществимо- сти вание Конструиро- Жизненный цикл при объектно-ориентированном развитии проекта (фазовое измерение) 0 Необходимость разработки признана 1 Ресурсы распределены 4 Спецификации реализуемых сценариев составлены 3 Требования к очередной итерации утверждены 2 Требования к очередной итерации сформулированы Требования к новой итерации приняты 8 Начато использование изделия 9 Изделие или его версия передано на распространение 10 Извещение о прекращении поддержки изделия (версии) выпущено 11 Изделие (версия) снято с производства 12 Взаимодействие с планировщиком с целью выяснения возможностей предоставления ресурсов для проекта. Планирование предоставления ресурсов Начала стационарного цикла развития проекта. Различия первой и последующих итераций: формирование и корректировка критериев предпочтения того, что считается целесообразным для реализации Все, что представляет проект (итерацию) как развивающуюся разработку утверждается. Важно: это момент подведения первых итогов проекта (итерации) Декомпозиция решаемых проектом (итерацией) задач. Построение архитектуры, подготовка реализуемых сценариев для утверждения, определение реализуемых модулей Архитектура утверждена, задачи распределены между разработчиками (группами) Начало этапа пополнения базового окружения проекта: выделение общих лишь для данного проекта переиспользуемых компонентов выделение общих, не привязанных к проекту переиспользуемых компонентов Сбор сведений для новой итерации Оформление принимаемых для новой итерации требований. Одновременное существование двух (возможно, более) версий системы. Время для ревизии априорных гипотез, корректировка показателей и нормативов проекта Оповещение о прекращении сопро- вождения и сворачивание деятель- ности по поддержке версии или всех версий к определенному сроку Возможно откладывание события (на определенный или неопределенный срок) Начало работ над проектом (замысел). Цель указать на потребность проектных результатов, фиксировать стратегию, обозначить ресурсные потребности, планы формирования команды исполнителей и др. У разработчиков появилась возможность проверки априорных суждений о проекте (итерации) на практике. Важно: слияние контрольных точек 3, 4, 5 и объявление точки 6 как вехи в быстрых методологиях не означает ликвидации соответствующих процессов! Начало Фазы завершения (бета-тестирование): поставка сопровождение этап окончания работ Новое качество: у версии появляются пользователи, нуждающиеся в обслуживании

5 5 Контрольные точки и вехи Контрольные точки (check points) точки линии жизни жизненного цикла проекта, в которых возникают определенные события. Эти события рассматриваются как существенные, поскольку их необходимо отслеживать с целью управляемого развития проекта (такого, которое оставляет траекторию в рамках области допустимых операционных маршрутов) Вехи (mail stones) это контрольные точки, прохождение которых сопровождается определенными планируемыми мероприятиями. Без успешного (результат соответствует цели) проведения таких мероприятий, прохождение вехи блокируется с целью выполнения активностей, направленных на исправление ситуации. Оценка полученных результатов и планирование получения результатов основное содержание деятельности, связанной с вехами Конкретизация контрольных точек и вех задача, которую приходится решать в рамках выполнения функции планирования. Эта конкретизация делается на основе знания специфики выполняемого проекта и процесса его выполнения (т.е. принятой для проекта методологии). Специфика проекта и процесса определяет необходимость и количество вех. В жестких методологиях к прохождению вехи приурочивается утверждение соответствующих ей рабочих продуктов, в том числе и документов; быстрых методологиях вехи служат лишь ориентирами продвижения в своем развитии (мероприятия не имеющие отношения к процедурам утверждения)

6 6 Для каждой итерации должны быть определены: Общие требования что требуется от проекта в целом в данный момент Общий план как предполагается достигать цели (стратегия) Ближайшая задача набор конкретных реализуемых требований и сценариев критерии предпочтения того, что планируется реализовывать Перспективные задачи те, которые рассматриваются (в данный момент) как основа для планирования дальнейших итераций (в проектах жесткой отчетности) Критерии предпочтения: 1)Актуальность для пользователя 2)Полнота и функциональная замкнутость предлагаемых средств –Функциональная полнота –Реализационная полнота –Интерфейсная полнота 3)Системная значимость (внутрипроектные предпочтения) 4)Демонстрационная значимость 5)Скорость реализации Общие требования, общий план, ближайшая и перспективные задачи Характеристики значимости: Возможные ограничения: время, объем работ, затраты (треугольник менеджмента) Всегда лучше то, что актуально! Автоматизация деятельности в целом. Растет по мере увеличения объема уже выполненных работ Реализационные предпочтения. Конкурирует с (1). Более значим для начальных итераций Конкурирует с (1), (2) и (3) Максимально значимо для начальных итераций Лучше то, что быстрее. Если время фиксировано, то для реализации определяется пул работ. Иногда время не критерий, а ограничение Минимизация реализуемого является критерием лишь для некоторых методологий!

7 7 Жизненный цикл при объектно-ориентированном развитии проекта (функциональное измерение) Планирование Разработка Обслуживание Выпуск документации Испытания Поддержка Сопровождение Моделирование Планирование Разработка Обслуживание Выпуск документации Испытания Поддержка Сопровождение Моделирование Исследова- ния Программирование Оценка Использование Фазы (этапы) Итеративное зацикливание Пополнение базового окружения проекта 6 8 Окончание работ 1 Контрольные точки (события) Анализ осущест- Конструиро- вимости вание

8 8 Оценка как технологическая функция Оценка Исследова- ния Программирование Оценка Использование Фазы (этапы) Итеративное зацикливание Пополнение базового окружения проекта Окончание работ Анализ осущест- Конструиро- вимости вание Контрольные точки (события)

9 9 Непрерывность поступления требований в моделях жизненного цикла Трассировка требований (в модели Гантера) Варианты поступления требований: –требование или группа требований обрабатываются до начала итерации (при разработке ее сценариев) –требование или группа требований поступают, когда работы итерации начались –требование или группа требований поступают, когда релиз системы передан в эксплуатацию Возможные результаты анализа требований: –требование отклоняется работа с требованием прекращается –требование принимается к реализации на текущей итерации –реализация требования откладывается до следующих итераций Функциональное измерение меняется, но учесть это вне контекста конкретного проекта нереально Почти все модели жизненного цикла слабо приспособлены к учету непрерывности поступления требований Укладывается в представ- ленную ранее схему модели фазы – функции Схема дополняется мини-циклом обработки требований До мини-цикла необходим предварительный анализ требований

10 10 (b) Решение о требовании принято 8 Контроль- ные точки (события): Программирование Оценка Использование Фазы (этапы) Итеративное зацикливание Пополнение базового окружения проекта Окончание работ Начало проекта Исследования Завершение проекта Анализ осуществимо- сти вание Конструиро- Жизненный цикл при объектно-ориентированном развитии проекта (фазовое измерение) (a) Требование поступило, начало мини-цикла Требование отклоняется Шаги обработки требования или группы требований: поступление в любой момент конструирования, программирования или оценки расщепление, переход к анализу анализ принятие решения /на общем участке этапов анализа и конструирования/ планирование срока или будущей итерации реализации Требование реализуется на более поздней итерации Требование реализуется на текущей итерации Варианты решения Анализ нового требования

11 11 Использование Проверка реализации Решение о реализации ама требований принято (c) Накопление, система- тизация и группировка требований Пополнение базового окружения проекта вание Анализ осуществи- Требования, поступающие в ходе эксплуатации (b) Решение о требовании принято 8 Программи- Оценка Фазы (этапы) Итеративное зацикливание Окончание работ Начало проекта Исследования Завершение проекта мости Конструиро Сообщение о требовании поступило (a) Требование отклоняется рование Первичный анализ Извлечение требования Решение реализовать: в другом проекте в следующих релизах в текущем релизе немедленная реакция в другом проекте в следующих релизах в текущем релизе немедленная реакция Период сопровождения Контроль- ные точки (события): Реализация требований

12 12 Шаги обработки требований Поступление сообщения, содержащего требования в любой момент периода сопровождения Первичный анализ принятие первоначального решения о реализации: –немедленная реакция быстрое устранение замечаний, пояснения для пользователей и др. Выполняется всегда, в том числе совместно с другими решениями –требование отклоняется объяснение причин отклонения, путей преодоления трудностей –реализация требования в текущем релизе если претензии обоснованы, а устранение замечаний, ошибок и т.п. возможно в обслуживаемом релизе, то организуется мини-цикл обработки требований в итерации –реализация требования в одном из следующих релизов если устранение замечаний в рамках обслуживаемого релиза невозможно или нецелесообразно, то требование передается для исполнения на одной из следующих итераций проекта –реализация требования в другом проекте если выясняется, что в данном проекте требование реализовать невозможно или нецелесообразно, то, быть может, оно станет одним из аргументов в пользу организации нового проекта Мини-цикл обработки требований начинается с анализа (возобновленный процесс), определяющего группу требований для реализации в текущем релизе в рамках обычных задач этапа Реализация отобранных требований на данной итерации осуществляется по обычной схеме: конструирование, программирование, оценка. Особая роль проверочных работ дополнительный этап проверки реализации. Обязательно повторение проверки того, что было отлажено ранее (пополнение тестовой базы) Распространение изменений сделанные исправления должны стать доступными для всех пользователей. При массовом применении эта работа может потребовать значительных ресурсов

13 Действия, связанные с новыми проектными требованиями Требования, возникающие и изменяемые в течение этапов итерации, разделяются на принимаемые и отвергаемые Для каждого отвергаемого требования составляется мотивированное заключение о том, почему оно не принимается: –невозможно удовлетворить, –нецелесообразно принимать (достижимо иным путем), –запланировано в качестве перспективы, –может быть принято при изменении финансовых и календарных планов и др. Заключение согласовывается с автором требования и с заказчиком Для каждого из принимаемых требований (их элементарных составляющих) определяется, когда оно может быть удовлетворено и когда его целесообразно удовлетворять. Критериями служат: –приоритетность требования; –сложность рабочих продуктов и зависимостей рабочих продуктов от требования; Простые требования реализуются непосредственно в момент утверждения; Сложные требования откладываются до завершения конструкторских работ итерации, которое рассматривается как начало работ по учету комплекса предъявленных требований; Требования, откладываемые до последующих итераций, реализуются согласно общему плану проекта (корректируемому) Учитывается, что ранее принятое требование может оказаться отвергнутым вследствие принятия новых требований необходимо подготовить и согласовать с автором требования и заказчиком заключение об отказе от реализации требований, Изменения планов и объемов работ, возникающие и/или планируемые в связи с изменениями требований, всегда согласуются с заказчиком.