Часть II. Технологии быстрого тестирования и советы. На мой первый ответ по электронной почте пришло письмо следующего содержания: Я благодарю вас за то

На мой первый ответ по электронной почте пришло письмо следующего содержания: " Я благодарю вас за то, что вы не пожалели своего времени, чтобы ответить мне, однако ваш ответ привел меня в еще большее замешательство. Вот почему я так долго не от-вечал вам — я даже не знаю, что больше всего меня озадачило. Предложенный вами подход хорош, однако он предполагает, что необходимые данные находятся где-то ря-дом. В то же время у нас нет доступа к данным о трудозатратах, а то, что у нас есть, особой ценности не представляет. Единственное, что приходит в голову, так это найти аналогичный завершенный проект и воспользоваться фактическим количеством строк кода в нем как оценкой текущего проекта. Находите ли вы мое суждение имеющим

СМЫСЛ? "

Я отправил по электронной почте второе послание, в котором заметил: " Да, это один из способов стабилизации вашей оценки, например, с помощью базиса оценки программ-ного кода предыдущего проекта. Вы также можете собрать меньшие оценки уровней LOE для используемого набора ролей и количество исполнителей на каждой роли, на- пример, число руководителей проектов, программистов, тестировщиков различных cne-циальностей, специалистов по управлению конфигурациями, лиц, ответственных за каче-ство программного продукта, специалистов по подготовке сборок, по проведению ис-пытаний, лиц, осуществляющих контроль производством и прочих. Сюда следует вклю-чить и расширенные группы, такие как группа подготовки документации, группа инст-рукторов, занимающихся обучением пользователей, группа специалистов, проводящих пробные испытания, группа экономистов, решающих вопросы конъюнктуры, группа суб-подрядчиков и т.п. Если вы располагаете такими сведениями, разделите соответствую-щие значения на общее число сотрудников, чтобы получить процентное отношение тру-дозатрат, а затем воспользуйтесь этими данным для нового подсчета трудозатрат. Точ ность этих расчетов находится в пределах 30%. Между прочим, 30% — это, на мой взгляд, несколько лучше, чем ошибки в 2 или даже в 4 раза, которые допускают раз-работчики программного обеспечения, раздувая сметную стоимость и трудозатраты. Удачи."

Формулы, используемые в этом исследовании, заимствованы из модели СОСОМО, предложенной Боемом (Boehm). Описанные выше семь шагов используют для полу­ чения коэффициента EAF скорее метод инженерного анализа, а не подход д-ра Бое-ма, описание которого можно будет найти далее в главе.

При получении оценок возможны просчеты, причина которых кроется в стати­ стических данных за прошлый период:

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

• Часто трудно противиться желанию вычислять временные затраты и трудоза­ траты, исходя из предположения их линейной зависимости от производитель­ ности, вычисленной для прошлого проекта. Например, в рамках прошлого проекта была достигнута производительность в размере 1 строки программно­ го кода за один рабочий час на программе в 5 KESLOC, следовательно, для раз­ работки программы, состоящей из 50 KESLOC, при производительности 1 строка программного кода за один рабочий час, потребуется в 10 раз большее время. Это неверно, поскольку с увеличением размеров программы трудозатра­ ты возрастают по экспоненциальному закону, а не по линейному.

В — количество строк программного кода, соответствующее одному функциональному баллу

С — количество команд на выходном языке транслятора, соответствующее строке программного кода

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