Менеджмент разработки программных изделий 5 ориентированных программных проектов
advertisement
Менеджмент разработки программных изделий 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 Действия, связанные с новыми проектными требованиями • • Требования, возникающие и изменяемые в течение этапов итерации, разделяются на принимаемые и отвергаемые Для каждого отвергаемого требования составляется мотивированное заключение о том, почему оно не принимается: – – – – • • Заключение согласовывается с автором требования и с заказчиком Для каждого из принимаемых требований (их элементарных составляющих) определяется, когда оно может быть удовлетворено и когда его целесообразно удовлетворять. Критериями служат: – – • • • • • невозможно удовлетворить, нецелесообразно принимать (достижимо иным путем), запланировано в качестве перспективы, может быть принято при изменении финансовых и календарных планов и др. приоритетность требования; сложность рабочих продуктов и зависимостей рабочих продуктов от требования; Простые требования реализуются непосредственно в момент утверждения; Сложные требования откладываются до завершения конструкторских работ итерации, которое рассматривается как начало работ по учету комплекса предъявленных требований; Требования, откладываемые до последующих итераций, реализуются согласно общему плану проекта (корректируемому) Учитывается, что ранее принятое требование может оказаться отвергнутым вследствие принятия новых требований → необходимо подготовить и согласовать с автором требования и заказчиком заключение об отказе от реализации требований, Изменения планов и объемов работ, возникающие и/или планируемые в связи с изменениями требований, всегда согласуются с заказчиком.
