Д. А. Градусов а. В. Шутов теоретические вопросы разработки программного обеспечения учебное пособие

129 
стоит обсудить различия и добиться консенсуса от всех участников 
группы. 
Исследования показали, что средняя величина относительной 
ошибки для индивидуальных оценок составляет 55%. У оценок, 
прошедших обсуждение в группах, она уменьшается до 30%.
Широкополосный 
дельфийский 
метод 
относится 
к 
структурированным 
методам 
групповой 
оценки. 
Исходный 
Дельфийский метод был разработан в Rand Corporation в конце 1940-х 
годов для прогнозирования технологический тенденций. Его название 
происходит от древнегреческого города Дельфы, где находился 
оракул. В базовом варианте Дельфийского метода несколько 
экспертов создают независимые оценки, а затем встречаются до тех 
пор, пока им не удастся согласовать одну оценку. 
Первоначальные исследования применения Дельфийского 
метода для оценки программного обеспечения покали, что базовый 
Дельфийский метод не обеспечивает большей точности, чем менее 
структурированные групповые обсуждения. Барри Боэм и его коллеги 
сделали вывод, что общие собрания слишком подвержены 
политическому давлению, и на них слишком часто доминируют 
наиболее настойчивые оценщики в группе. По этой причине Боэм с 
коллегами доработали базовый Дельфийский метод и превратили его 
в то, что сейчас известно под названием широкополосного 
Дельфийского метода.
Основная процедура заключается в следующем: 
1.
Координатор 
предоставляет 
каждому 
оценщику 
спецификацию и форму оценки. 
2.
Оценщики по отдельности готовят исходные оценки. 
3.
Координатор созывает собрание группы, на котором 
оценщики обсуждают проблемы, связанные с оценкой текущего 
проекта.

130 
4.
Оценщики анонимно передают индивидуальные оценки 
координатору. 
5.
Координатор готовит сводку оценок в итеративной форме и 
представляет форму оценщикам, чтобы они видели, как выглядят их 
оценки в сравнении с оценками других участников группы. 
6.
Координатор организует встречу, на которой оценщики 
обсуждают расхождения в оценках. 
7.
Оценщики проводят анонимное голосование по принятию 
средней оценки. Если хотя бы один из оценщиков проголосует 
отрицательно, процедура возвращается к шагу 3. 
8.
Окончательной считается точечная оценка, полученная по 
Дельфийской процедуре. Также окончательная оценка может 
представлять собой диапазон, созданный в ходе обсуждения, а 
точечная оценка представляет ожидаемый случай. 
Итерация 1
Итерация 3
Итерация 2
Человеко-месяцы
0
20
15
10
5
0
0
5
5
10
10
15
15
20
20
Рис. 6.1 - Итерации процесса оценивания 
Все итерации оценок полезно отображать на одной шкале, 
чтобы разработчики могли проследить за их схождением (а в 
некоторых случаях – за расхождением) (рис. 6.1). 
Исследования эффективности широкополосного Дельфийского 
метода показали, что он снижает ошибку примерно на 40% по 
сравнению с усредненной оценкой группы. Наиболее полезным он 
является при оценке работы, проводимой в малознакомой деловой 

131 
области, базирующейся на новой технологии или направленной на 
разработку нового вида программного обеспечения. Он помогает 
создавать приближенные оценки «с точностью до порядка» на стадии 
определения продукта или выработки концепции, пока многие 
требования еще не были сформулированы. Он также хорошо работает 
в 
проектах, 
связанных 
с 
несколькими 
разнородными 
специализациями. Кроме того, широкополосный Дельфийский метод 
способствует более четкому определению объема работы и помогает 
избавиться от лишних предположений. Таким образом, наибольшую 
пользу он приносит при оценке одиночных показателей, 
использующих входные данные из разных областей в очень широкой 
части конуса неопределенности. 
Но для множества задач для получения подробных оценок метод 
не подходит, поскольку требует проведения собраний, а 
следовательно больших затрат рабочего времени. Поэтому главным 
недостатком широкополосного Дельфийского метода считается его 
дороговизна. 
6.5
Линейный метод 
В простейшем случае определить стоимость разработки ПО 
можно, исходя из количественной оценки трудозатрат (в неких 
единицах, например, человеко-месяцах или человеко-часах) и их 
удельной стоимости: 
Ц
T
C


(3) 
Цена одной единицы трудозатрат для индустрии разработки ПО 
формируется, в основном, исходя из заработной платы и связанных с 
ней начислений. Как правило, другие составляющие имеют гораздо 
меньший удельный вес, и ими зачастую можно пренебречь. 

132 
Что касается самих трудозатрат, то их достоверное вычисление 
в сфере интеллектуальной деятельности, к которой, несомненно, 
относится разработка ПО, выполнить достаточно сложно. 
Простейший подход может быть основан на следующей линейной 
формуле: 
П
Р
Т


(4) 
где Р – размер исходного кода ПО;
П – временная производительность. 
Эта примитивная формула активно применяется и сейчас, хотя 
ее несостоятельность была установлена довольно давно. Пожалуй, 
самой известной работой, в которой критикуется данный подход, 
является выдержавшая более двадцати изданий по-настоящему 
классическая книга Фредерика Брукса «Мифический человеко-месяц, 
или Как создаются программные системы», впервые увидевшая свет 
еще в 1977 г. 
По мнению Брукса, методы оценки ошибочно путают 
достигнутый прогресс с затраченными усилиями. В первую очередь, 
это касается способа, которым измеряется результат, – на заре 
программирования не было найдено ничего лучшего, чем 
использование в этих целях количества строк кода. С ростом 
мастерства программист обычно делается «лаконичнее», т. е. 
выдаваемый им код для решения одних и тех же задач становится все 
компактнее, а это означает, что его проще и дешевле отлаживать и 
сопровождать. Однако вышеуказанная формула вовсе не стимулирует 
данного процесса. 

133 
6.6
Методы, основанные на функциональных пунктах 
Наверное, наиболее удачной заменой количеству строк кода для 
измерения производительности стали функциональные пункты 
(function points), впервые предложенные сотрудником IBM Аланом 
Альбрехтом в 1979г. Наиболее важное преимущество данного метода: 
поскольку применение функциональных пунктов основано на 
изучении требований, то оценка необходимых трудозатрат может 
быть выполнена на самых ранних стадиях работы над проектом и 
далее будет уточняться по ходу жизненного цикла, а явная связь 
между требованиями к создаваемой системе и получаемой оценкой 
позволяет заказчику понять, за что именно он платит, и во что 
выльется изменение первоначального задания. 
Постепенно метод функциональных пунктов превратился в 
индустриальный стандарт, и в 1986 г. для его поддержки и развития 
была создана некоммерческая организация IFPUG (International 
Function Point User Group). Кроме того, он послужил основой для 
множества производных подходов. 

жүктеу/скачать 2,75 Mb.

Достарыңызбен бөлісу: