<<
>>

Сбор данных

Если вы еще не занимались сбором исторических данных, начните с очень маленького набора. Размер (строки программного кода или другой показатель, который можно получить после выпуска программы).

Объем работы (человеко-месяцы). Время (календарные месяцы). Дефекты (с классификацией по степени тяжести).

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

Наряду с признанием того факта, что этих четырех видов данных достаточно для калибровки моделей оценки, большинство экспертов рекомендует начинать с малого и хорошо разобраться в сути собираемых данных (Pietrasanta 1990, NASA SEL 1995). В противном случае может оказаться, что собранные данные не согласуются между проектами и потому становятся бессмысленными. В зависимости от того, как именно определяются эти четыре показателя, полученные числа могут отличаться в два раза и более.

Проблемы определения размера

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

измерять исторические данные, относящиеся к размеру проектов, в строках программного кода. (Достоинства и недостатки измерения в строках программного кода обсуждаются в разделе 18.1.)

Чтобы вычислить размер проекта в строках кода, необходимо принять решения по нескольким вопросам, в том числе: Учитывать ли весь код, или только код, входящий в выпущенную версию программы? (Например, нужно ли считать временный связующий код, код фиктивных объектов, код модульных тестов и код тестирования системы?) Как учитывать код, позаимствованный из предыдущих версий? Как учитывать свободно распространяемый код или код библиотек сторонних производителей? Включать ли в подсчет пустые строки и комментарии? Как учитывать интерфейсы классов? Как учитывать объявления данных? Как подсчитывать одну логическую строку кода, разбитую на несколько физических строк для удобства чтения?

Никаких отраслевых стандартов на этот счет не существует.

Более того, не так уж важно, как именно вы на них ответите[5]. Важно другое: чтобы вы не меняли принятых решений между проектами, а предположения, заложенные в уже собранные данные, сознательно распространялись на ваши будущие оценки.

Проблемы измерения объема работ

Аналогичные проблемы возникают при сборе данных по объему работ. Как измеряется время — в часах, днях или других единицах? Сколько рабочих часов в день заложено в вычисления? Стандартные 8 часов или фактическое время, действующее в конкретном проекте? Учитывать ли неоплаченные сверхурочные? Учитывать ли выходные, отпуска и время обучения? Учитывать ли время, проведенное на собраниях уровня компании? Какие работы включать в подсчет? Тестирование? Управление первого уровня? Написание документации? Требования? Проектирование? Исследования? Как учитывать время, разделенное между несколькими проектами? Как учитывать время, потраченное на поддержку предыдущих версий той же программы? Как учитывать время, потраченное на общение со службой продаж, на проведение выставок и т. д.? Как учитывать время командировок? Как учитывать нечеткий первоначальный период — время, потраченное на проработку концепции программы до полного определения проекта?

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

Проблемы измерения календарного времени

Как ни странно, во многих организациях возникают затруднения с определением сроков работы над тем или иным проектом. Что следует считать началом работы над проектом? Формальное согласование бюджета? Начало первых обсуждений проекта? Полное комплектование персоналом? Кейперс Джонс сообщает, что четко определенная начальная точка встречается менее чем в 1 % проектов (Jones 1997).

Когда проект может считаться завершенным? Когда будет собрана окончательная версия? Когда предполагаемая окончательная версия передается на тестирование? А если большинство программистов прекратило работу над проектом за месяц до выхода официальной версии? Джонс сообщает, что в 15 % проектов встречаются неоднозначные сроки завершения (Jones 1997).

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

Проблемы измерения дефектов

Наконец, результаты измерения дефектов также могут изменяться в 2-3 раза в зависимости от того, что именно считается дефектом. Считаются ли дефектами все запросы на изменения или только те, которые в конечном итоге были отнесены к дефектам (то есть за исключением запросов на внесение новых возможностей)? Как рассматривать разные сообщения об одном дефекте — как один или как несколько дефектов? Учитывать ли дефекты, обнаруженные разработчиками, или только дефекты, обнаруженные при тестировании? Учитывать ли дефекты программирования, обнаруженные до начала аль- фа- или бета-тестирования? Учитывать ли дефекты, о которых сообщили пользователи после выпуска программы?

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

Другие проблемы сбора данных

Исторические данные проще всего собирать во время работы над проектом. Трудно будет вернуться через полгода после завершения проекта и попытаться припомнить «нечеткий первоначальный период», чтобы определить дату начала проекта, сколько приходилось работать сверхурочно в конце проекта и т. д.

СОВЕТ № 38

Собирайте исторические данные как можно раньше после начала проекта.

Данные, собранные в конце проекта, также полезны, но еще полезнее «моментальные снимки», сделанные непосредственно в ходе работы. Статистика по размерам, объему работ и дефектам, собираемая каждые 1-2 недели, способна дать ценную информацию о динамике проекта.

Например, сбор информации о выявленных дефектах помогает прогнозировать частоту обнаружения дефектов и их исправления в будущих проектах. Данные о распределении объема работы по времени помогут понять, в какой степени ваша организация способна мобилизовать персонал на поддержку проекта. Если комплектование персоналом одного проекта происходит медленнее, чем требуется, возможно, это случайное отклонение. Если же исторические данные указывают на то, что три последних проекта комплектовались с одинаковой скоростью, вполне возможно, что вы столкнулись с организационным фактором влияния, который не удастся легко изменить в следующем проекте.

СОВЕТ № 39

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

<< | >>
Источник: Макконнелл С.. Сколько стоит программный проект. 2007

Еще по теме Сбор данных:

  1. СБОР ДАННЫХ
  2. Сбор и анализ данных Роль компьютерных технологий в анализе рынка
  3. Базы данных и системы управления базами данных
  4. ТИПЫ ДАННЫХ В EXCEL. ВВОД ДАННЫХ И ИХ РЕДАКТИРОВАНИЕ
  5. АКЦИЗНЫЙ СБОР
  6. 16.31. Сбор за право торговли
  7. 16.35. Сбор с владельцев собак
  8. 16.39. Сбор за парковку автотранспорта
  9. ОФФШОРНЫЙ СБОР
  10. 16.47. Сбор за открытие игорного бизнеса
  11. РЕНТНЫЙ СБОР
  12. 16.43. Сбор с лиц, участвующих в игре на тотализаторе на ипподроме