Основы программирования

Основы технологии - Трассировка и контроль
Индекс материала
Основы технологии
Организация процесса конструирования
Классический жизненный цикл
Макетирование
Быстрая разработка приложений
Спиральная модель
Тяжеловесные и облегченные процессы
Модели качества процессов конструирования
Контрольные вопросы
Руководство программным проектом
Начало проекта
Трассировка и контроль
Достоинства размерно-ориентированных метрик:
Примеры элементов данных
Достоинства функционально-ориентированных метрик:
Конструктивная модель стоимости
Модель композиции приложения
Модель раннего этапа проектирования
Модель этапа постархитектуры
Факторы продукта:
ПРИМЕЧАНИЕ
Предварительная оценка программного проекта
Анализ чувствительности программного проекта
Сценарий понижения зарплаты
Сценарий уменьшения средств на завершение проекта
Выводы.
Классические методы анализа
Все страницы

 

Трассировка и контроль

 

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

В результате повторного планирования:

q могут быть перераспределены ресурсы;

q могут быть реорганизованы задачи;

q могут быть пересмотрены выходные обязательства.

Планирование проектных задач

 

Основной задачей при планировании является определение WBS — Work Breakdown Structure (структуры распределения работ). Она составляется с помощью утилиты планирования проекта. Типовая WBS приведена на рис. 2.2.

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

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

1) выяснения потребностей заказчика;

2) оценки выполнимости системы;

3) выполнения экономического и технического анализа;

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

5) определения стоимости и ограничений планирования;

6) создания системной спецификации.

В системной спецификации описываются функции, характеристики системы, ограничения разработки, входная и выходная информация.

Анализ требований дает возможность:

1) определить функции и характеристики программного продукта;

2) обозначить интерфейс продукта с другими системными элементами;

3) определить проектные ограничения программного продукта;

4) построить модели: процесса, данных, режимов функционирования продукта;

5) создать такие формы представления информации и функций системы, которые можно использовать в ходе проектирования.

 

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

Как видно из типовой структуры, задачи по проектированию и планированию тестов могут быть распараллелены. Благодаря модульной природе ПО для каждого модуля можно предусмотреть параллельный путь для детального (процедурного) проектирования, кодирования и тестирования. После получения всех модулей ПО решается задача тестирования интеграции — объединения элементов в единое целое. Далее проводится тестирование правильности, которое обеспечивает проверку соответствия ПО требованиям заказчика.

Ромбиками на рис. 2.2 обозначены вехи — процедуры контроля промежуточных результатов. Очень важно, чтобы вехи были расставлены через регулярные интервалы (вдоль всего процесса разработки ПО). Это даст руководителю возможность регулярно получать информацию о текущем положении дел. Вехи распространяются и на документацию как на один из результатов успешного решения задачи.

Параллельность действий повышает требования к планированию. Так как параллельные задачи выполняются асинхронно, планировщик должен определить межзадачные зависимости. Это гарантирует «непрерывность движения к объединению». Кроме того, руководитель проекта должен знать задачи, лежащие на критическом пути. Для того чтобы весь проект был выполнен в срок, необходимо выполнять в срок все критические задачи.

Основной рычаг в планирующих методах — вычисление границ времени выполнения задачи.

Обычно используют следующие оценки:

1. Раннее время начала решения задачи (при условии, что все предыдущие задачи решены в кратчайшее время).

2. Позднее время начала решения задачи (еще не вызывает общую задержку проекта).

3. Раннее время конца решения задачи .

.

4. Позднее время конца решения задачи .

.

5. Общий резерв — количество избытков и потерь планирования задач во времени, не приводящих к увеличению длительности критического пути Тк.п.

Все эти значения позволяют руководителю (планировщику) количественно оценить успех в планировании, выполнении задач.

Рекомендуемое правило распределения затрат проекта — 40-20-40:

q на анализ и проектирование приходится 40% затрат (из них на планирование и системный анализ — 5%);

q на кодирование — 20%;

q на тестирование и отладку — 40%.

Размерно-ориентированные метрики

 

Размерно-ориентированные метрики прямо измеряют программный продукт и процесс его разработки. Основываются размерно-ориентированные метрики на LOC-оценках (Lines Of Code). LOC-оценка — это количество строк в программном продукте.

Исходные данные для расчета этих метрик сводятся в таблицу (табл. 2.1).

 

Таблица 2.1. Исходные данные для расчета LOC-метрик

Проект

Затраты, чел.-мес

Стоимость, тыс. $

KLOC, тыс. LOC

Прогр. док- ты, страниц

Ошибки

Люди

ааа01

24

168

12,1

365

29

3

bbb02

62

440

27,2

1224

86

5

ссс03

43

314

20,2

1050

64

6

 

Таблица содержит данные о проектах за последние несколько лет. Например, запись о проекте aaa01 показывает: 12 100 строк программы были разработаны за 24 человеко-месяца и стоили $168 000. Кроме того, по проекту aaa01 было разработано 365 страниц документации, а в течение первого года эксплуатации было зарегистрировано 29 ошибок. Разрабатывали проект aaa01 три человека.

На основе таблицы вычисляются размерно-ориентированные метрики производительности и качества (для каждого проекта):