лекция. Сборник лекций по МДК _Технология разработки программного обеспе. Курс лекций для специальности спо базовой подготовки

• Название: Курс лекций для специальности спо базовой подготовки
• Анкор: лекция
• Дата: 02.09.2022
• Размер: 4.41 Mb.
• Имя файла: Сборник лекций по МДК _Технология разработки программного обеспе.docx
• Тип: Курс лекций; #660044
• страница: 35 из 62

От рамок проекта к экспресс-планированию

Начальную, самую грубую оценку проекта можно сделать на основании документа "Видение". Так, шаблон Vision/Scope MSF содержит список ключевых характеристик/функций, критерии приемлемости и (что очень важно) перечень характеристик/функций, которые лежат "вне рамок" проекта. Параллельно с проработкой концепции, первая фаза MSF содержит работы по анализу рисков: выявляются и оцениваются главные риски проекта.

Чтобы сделать первое приближение плана и сметы проекта на ранних этапах анализа, в [15.1] предлагается следующий подход:

• 
  Выделить 25 - 99 функций, характеризующих систему (совместно, Заказчик и Разработчик);
  
• 
  Установить приоритеты для каждой из функций (Заказчик);
  
• 
  Оценить трудозатраты (Разработчик);
  
• 
  Оценить риски (Разработчик, возможно привлечение Заказчика);
  

Все оценки делаются по 3-балльной шкале (высокий, низкий, средний; критический, важный, полезный и т.п.) и сводятся в таблицу:

№ пп.

Функция

Приоритет

Трудоемкость

Риск

Затем, в процессе консультаций Заказчика и Разработчика на основе полученной информации определяется набор функций, который войдет в базовую версию проекта.

Результаты планирования на концептуальном уровне, проделанные, например, на основе вышеуказанного шаблона, позволяют дать первую оценку размерам проекта. Такая оценка не отличается особой точностью, но при определенных условиях (опыт решения Разработчиком аналогичных задач; доверительные отношения между Заказчиком и Разработчиком) может служить отправной точкой для заключения контракта на всю систему.

Планирование проекта на основе требований, путь RUP

RUP поддерживает двухуровневую схему планирования работ над проектом, разделяя план проекта и план итерации. Исходя из базовой концепции планирования итерационных проектов, план проекта разбивается на фазы:

• 
  Начало,
  
• 
  Уточнение,
  
• 
  Конструирование,
  
• 
  Переход.
  

Исходя из рекомендаций методологии по декомпозиции работ проекта в зависимости от степени сложности проекта и квалификации команды, в каждой фазе выделяется одна или более итераций.

Назначаются даты главных вех (окончания фаз):

• 
  целей жизненного цикла (конец фазы начала, рамки проекта и его бюджет);
  
• 
  архитектуры жизненного цикла (конец фазы уточнения, законченная архитектура);
  
• 
  начальной работоспособности (конец фазы конструирования, бета-версия продукта);
  
• 
  выпуска изделия (конец фазы перехода и полного цикла разработки).
  

Назначаются даты малых вех, приуроченные к окончанию итераций и их главные цели. Основные цели итераций - выпуск релизов, демонстрируемых, либо передаваемых Заказчику, однако не всякая итерация приводит к выпуску релиза.

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

Что это означает на практике:

1. 
   укрупненный план работ составляется "как можно раньше", например - через месяц после начала работ;
   
2. 
   бюджет появляется лишь к окончанию первой фазы (а она, в зависимости от сложности проекта может длиться месяц, а может и полгода);
   
3. 
   как план, так и бюджет проекта представляют собой лишь прогноз, который может корректироваться на протяжении работ над проектом;
   
4. 
   на момент появления плана и бюджета должно появиться подробное описание лишь 20% ключевой функциональности системы и "широкое, но неглубокое" [15.2] описание 80% функциональности.
   

Таким образом, концепция укрупненного планирования в RUP, как типичном представителе класса прогнозирующих методологий, предполагает базировать отношения между Заказчиком и Разработчиком на прогнозах, степень достоверности которых зависит от таких факторов, как качество проработки требований, квалификация команды Разработчика, сложность и новизна проекта.

Более конкретная информация представлена в плане итерации. Основные его особенности:

1. 
   План итерации базируется на функциональных требованиях. К моменту начала итерации совершенно точно известно, какие требования должны быть обработаны (детализированы, спроектированы, запрограммированы) в данной итерации.
   

План итерации составляется, исходя из сформулированных выше оценок требований - приоритетности, степени риска, трудоемкости.

2. 
   План итерации имеет жесткие сроки. В случае проявления незапланированных рисков удовлетворительным вариантом является достижение договоренности о реализации требований данной итерации не в полном объеме, либо переносе требований в следующую итерацию; переносить сроки текущей итерации не рекомендуется;
   
3. 
   Точный план составляется на одну, очередную итерацию. К моменту окончания текущей итерации должен быть сверстан план очередной итерации. Такой подход позволяет более гибко работать с рисками.
   

Таким образом, следует отметить, что требования являются решающим фактором в планировании итерационного проекта.