![]() Главная страница Случайная страница КАТЕГОРИИ: АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатикаИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханикаОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторикаСоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансыХимияЧерчениеЭкологияЭкономикаЭлектроника |
Часть II. Технологии быстрого тестирования и советы. На мой первый ответ по электронной почте пришло письмо следующего содержания: Я благодарю вас за то
На мой первый ответ по электронной почте пришло письмо следующего содержания: " Я благодарю вас за то, что вы не пожалели своего времени, чтобы ответить мне, однако ваш ответ привел меня в еще большее замешательство. Вот почему я так долго не от-вечал вам — я даже не знаю, что больше всего меня озадачило. Предложенный вами подход хорош, однако он предполагает, что необходимые данные находятся где-то ря-дом. В то же время у нас нет доступа к данным о трудозатратах, а то, что у нас есть, особой ценности не представляет. Единственное, что приходит в голову, так это найти аналогичный завершенный проект и воспользоваться фактическим количеством строк кода в нем как оценкой текущего проекта. Находите ли вы мое суждение имеющим
СМЫСЛ? "
Я отправил по электронной почте второе послание, в котором заметил: " Да, это один из способов стабилизации вашей оценки, например, с помощью базиса оценки программ-ного кода предыдущего проекта. Вы также можете собрать меньшие оценки уровней LOE для используемого набора ролей и количество исполнителей на каждой роли, на- пример, число руководителей проектов, программистов, тестировщиков различных cne-циальностей, специалистов по управлению конфигурациями, лиц, ответственных за каче-ство программного продукта, специалистов по подготовке сборок, по проведению ис-пытаний, лиц, осуществляющих контроль производством и прочих. Сюда следует вклю-чить и расширенные группы, такие как группа подготовки документации, группа инст-рукторов, занимающихся обучением пользователей, группа специалистов, проводящих пробные испытания, группа экономистов, решающих вопросы конъюнктуры, группа суб-подрядчиков и т.п. Если вы располагаете такими сведениями, разделите соответствую-щие значения на общее число сотрудников, чтобы получить процентное отношение тру-дозатрат, а затем воспользуйтесь этими данным для нового подсчета трудозатрат. Точ ность этих расчетов находится в пределах 30%. Между прочим, 30% — это, на мой взгляд, несколько лучше, чем ошибки в 2 или даже в 4 раза, которые допускают раз-работчики программного обеспечения, раздувая сметную стоимость и трудозатраты. Удачи."
Формулы, используемые в этом исследовании, заимствованы из модели СОСОМО, предложенной Боемом (Boehm). Описанные выше семь шагов используют для полу чения коэффициента EAF скорее метод инженерного анализа, а не подход д-ра Бое-ма, описание которого можно будет найти далее в главе.
При получении оценок возможны просчеты, причина которых кроется в стати стических данных за прошлый период:
• В предыдущем и текущем проектах могли использоваться различные языки программирования, различные этапы жизненного цикла, различные техноло гии экспертных оценок и т.д. Из-за несоответствий в упомянутых областях применение статистических данных может привести к получению неточных рабочих графиков и оценок затрат.
• Часто трудно противиться желанию вычислять временные затраты и трудоза траты, исходя из предположения их линейной зависимости от производитель ности, вычисленной для прошлого проекта. Например, в рамках прошлого проекта была достигнута производительность в размере 1 строки программно го кода за один рабочий час на программе в 5 KESLOC, следовательно, для раз работки программы, состоящей из 50 KESLOC, при производительности 1 строка программного кода за один рабочий час, потребуется в 10 раз большее время. Это неверно, поскольку с увеличением размеров программы трудозатра ты возрастают по экспоненциальному закону, а не по линейному.
В — количество строк программного кода, соответствующее одному функциональному баллу С — количество команд на выходном языке транслятора, соответствующее строке программного кода
Вывод, который непосредственно можно получить из этого исследования, заклю чается в том, что в условиях мелкомасштабных проектов каждый исполнитель знает все, что происходит ежедневно, а члены команды поддерживают друг друга, помогая решать сложные проблемы, разбираться в кодах и отлаживать модули. Ни у кого не возникает необходимости в документировании процесса, поэтому никто не задумы вается над тем, чтобы упаковать данные измерений. В условиях небольших проектов каждый член группы вынужден брать на себя ответственность за судьбу всего проек-
|