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

Семейство методов оценки, объединенных общим названием опосредованных методов, помогают решать подобные проблемы. При опосредованной оценке сначала идентифицируется посредник — показатель, коррелированный с оцениваемым, который проще вычисляется или подсчитывается (или становится доступным на более ранней стадии проекта, чем интересующая вас величина. Скажем, если вы хотите оценить количество тестовых сценариев, может оказаться, что оно коррелируется с количеством требований; если оценивается размер в строках кода, может оказаться, что оно коррелируется с количеством функций (с поправкой на категорию размера).

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

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

12.1. Нечеткая логика.

Метод, называемый нечеткой логикой, применяется для оценки размера проекта в строках кода (Putnam and Myers 1992, Humphrey 1995). Оценщики обычно могут классифицировать функции по таким группам: «очень малые», «малые», «средние», «большие» и «очень большие». Затем по историческим данным мы определяем, сколько строк кода в среднем требует очень малая функция, сколько — малая и т. д. В табл. 12.1 показан пример создания подобных оценок.

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

Содержимое столбца «Среднее количество строк кода на функцию» базируется на исторических данных вашей организации и фиксируется до начала оценки. В столбце «Количество’функций» содержится количество функций в каждой категории размера. Содержимое столбца «Оценка количества строк кода» вычисляется по двум другим столбцам. Как видно из таблицы, оценка состоит из 5 значащих цифр, что выходит за пределы точности базовых данных. Я бы представлял эту оценку как «96 ООО строк кода» или даже «100 ООО строк кода» (то есть с 1-2 значащими цифрами), чтобы не создавать ложного впечатления высокой точности.

Как получить средние размеры.

Метод нечеткой логики лучше всего работает при калибровке размеров по историческим данным вашей организации. Обычно размеры смежных категорий должны отличаться как минимум в два раза. Некоторые эксперты рекомендуют использовать 4-кратные различия (Putnam and Myers 1992).

Начальные средние показатели размеров создаются на основе данных, получаемых классификацией одной или нескольких законченных систем. Проанализируйте старую систему и отнесите каждую функцию к одной из категорий — очень малая, малая, средняя, большая или очень большая. Затем подсчитайте суммарное количество строк кода в функциях одной категории и разделите его на количество функций; вы получите средний размер в строках кода одной функции данной категории. Пример приведен в табл. 12.2.

Таблица 12.2. Пример вычисления среднего размера функции в строках кода

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

СОВЕТ № 55 -.

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

Классификация новой функциональности.

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

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

• Проведите обучение оценщиков, чтобы они правильно классифицировали функции.

• Документируйте критерии классификации, чтобы оценщики последовательно применяли их в своей работе.

Как не следует использовать нечеткую логику.

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

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

71 мелких функций в прошлом состояла в среднем из 235 строк кода, то и в будущем каждая из 15 мелких функций будет состоять примерно из 253 строк. Тем не менее из этого вовсе не следует, что любая отдельная функция будет действительно состоять из 253 строк. Размеры отдельных мелких функций могут лежать в диапазоне от 50 до 1000 строк кода. Следовательно, хотя монолитная оценка, полученная с применением нечеткой логики, может быть на удивление точной, не следует расширять методику для оценки размеров отдельных функций.

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

Расширения нечеткой логики.

Нечеткая логика также может использоваться для оценки объема работ — разумеется, если вы располагаете соответствующими данными. Пример показан в табл. 12.3.

Таблица 12.3. Пример использования нечеткой логики для оценки объема работ

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

Окончательная оценка в 3217 человеко-дней снова получилась излишне четкой. Ее желательно упростить до 3200 человеко-дней, 3000 человеко-дней или.

13 человеко-лет (для 250 рабочих дней в году). Также всегда следует рассматривать возможность представления результата в виде диапазона — скажем, от 10 до 15 человеко-лет. Такая оценка создает совершенно иное ощущение точности, чем 3217 человеко-дней.

12.2. Стандартные компоненты.

Если вы разрабатываете несколько программ со сходной архитектурой, для оценки размера можно воспользоваться методом стандартных компонентов. Сначала необходимо найти подходящие элементы для подсчета в предыдущих системах. Более конкретные рекомендации зависят от работы, которую вы хотите выполнять. Типичная система содержит динамические и статические веб-страницы, таблицы баз данных, бизнес-логику, диаграммы, диалоговые окна, отчеты и т. д.

После идентификации стандартных компонентов вычисляется среднее количество строк кода на компонент в прошлых системах. В табл. 12.4 показан пример исторических данных для стандартных компонентов.

Таблица 12.4. Пример исторических данных по количеству строк кода на стандартный компонент

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

Таблица 12.5. Пример использования стандартных компонентов для создания оценки размера

В столбцах 3-5 вводятся ваши оценки. Столбец 3 содержит минимальное количество компонентов, которые, по вашему представлению, может содержать проект. Например, для динамических веб-страниц в данном примере этот показатель равен 11. В следующем столбце вводится число, по вашему мнению наиболее вероятное (в нашем примере 25). Затем в столбце 5 вводится максимально возможное количество (50). Оценка в столбце 6 вычисляется по формуле PERT (Program Evaluation and Review Technique), обсуждавшейся в главе 9. Вот как выглядит эта формула для оценки количества компонентов:.

ФОРМУЛА № 7 -.

ОжидаемоеКоличествоКомпонентов = [Минимум + (4 х НаиболееВероятноеКоличество) + Максимум]^.

В нашем примере оцениваемое количество динамических веб-страниц оказывается равным [11 + (4 х 25) + 50]/6 = 26,8

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

Использование стандартных компонентов с процентилями.

В одной из разновидностей представленной методики вместо количества компонентов оценивается количество процентилей. Для этого вам также потребуется достаточное количество исторических проектов для вычисления осмысленных процентилей (иначе говоря, по меньшей мере 10 исторических проектов, а в идеале ближе к 20). Но если вы располагаете таким объемом исторических данных, вместо оценки количества можно оценить предполагаемое отклонение от среднего значения по каждому из компонентов. В табл. 12.6 показано, как выглядит составляемая таблица.

Таблица 12.6. Пример таблицы с эталонными данными для стандартных компонентов

Данные в таблице определяют размер стандартных компонентов по отношению к другим проектам, выполнявшимся вашей организацией. Согласно таблице, у 10 % проектов организации динамические веб-страницы содержали 5105 строк кода и менее, у 50 % проектов статические веб-страницы содержали 2111 строк кода и менее, у 75 % проектов бизнес-правила содержали 10 663 строки кода и менее и т. д.

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

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

Такой подход дает оценку в 54 893 строки кода. Как и прежде, при представлении оценки желательно упростить ее до 55 ООО или 60 ООО строк (то есть до одной или двух значащих цифр).

Ограничения метода стандартных компонентов.

К преимуществам метода стандартных компонентов следует отнести то, что он требует минимальных усилий с вашей стороны; собственно, все сводится к интуитивной оценке размера стандартных компонентов в новой системе и поиску по таблице. Немного времени потребуется на конструирование и сопровождение справочной таблицы (вроде тех, что представлены в табл. 12.4 и 12.6).

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

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

СОВЕТ № 56 -.

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

12.3. Абстрактные рейтинги.

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

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

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

В результате оценки строится список наподобие представленного в табл. 12.9. Таблица 12.9. Список историй с присвоенными пунктами

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

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

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

Таблица 12.10. Данные итерации 1 и начальная калибровка

На основании исходной калибровки руководитель проекта составляет оценку оставшейся части проекта, базирующуюся на абстрактных данных. Пример показан в табл. 12.11.

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

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

СОВЕТ № 57 -.

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

О шкале абстрактных рейтингов.

В методе нечеткой логики используется описательная шкала размеров: очень малый, малый и т. д. В методе абстрактных рейтингов используются степени 2 или числа Фибоначчи. Что лучше?.

На числовой шкале отношения между числами предполагают, что измеряемые величины также находятся в соответствующем отношении. Например, если абстрактные рейтинги присваиваются по шкале Фибоначчи, шкала 1, 2, 3, 5, 8, 13 наводит на мысль, что объем работ для выполнения истории из 5 пунктов составит 5/3 от объема работ для истории из 3 пунктов, а история из 13 пунктов будет выполняться почти в 4 раза дольше, чем история из 3 пунктов.

Такие отношения оказываются «палкой о двух концах». Если вы приняли необходимые меры, чтобы 13-пунктовая история действительно занимала примерно в 4 раза больший объем работ, чем 3-пунктовая — замечательно. Это означает, что вы сможете вычислить средний объем работ на пункт абстрактного рейтинга (см. ранее), умножить его на общее количество пунктов и получить осмысленный результат.

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

Если не принять мер к обеспечению точности числовых соотношений, обусловленных шкалой Фибоначчи или степенью 2, то результаты, вычисленные на базе абстрактных рейтингов, могут оказаться менее состоятельными, чем кажется на первый взгляд. Применение числовой шкалы подразумевает возможность выполнения числовых операций: умножения, сложения, вычитания и т. д. Но если базовые отношения не состоятельны (то есть 13-пунктовая история в действительности не требует в 13/3 больших усилий, чем 3-пунктовая), то выполнение математических операций с числом 13 оказывается ничуть не более осмысленным, чем выполнение математических операций с оценкой «большой» или «очень большой».

В табл. 12.2 представлен другой способ описания этой проблемы.

Таблица 12.12. Пример того, что может произойти при деформации числовой шкалы

В этом примере числовая шкала заставила нас поверить, что 180 пунктов образуют разумную оценку общего объема работ, но реальный объем оказался примерно на 30 % выше.

СОВЕТ № 58 -.

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

12.4. Метод футболки.

Участникам проекта, не обладающим технической квалификацией, часто приходится принимать решения относительно объема проекта в широкой части конуса неопределенности. Хороший оценщик не станет предоставлять четкую оценку, пока проект находится на этой стадии. Специалисты по продажам и маркетингу запротестуют: «Как я могу сказать, нужна мне эта функция или нет, если я не знаю, сколько она стоит?» На что хороший оценщик скажет: «А я не могу ответить, сколько она стоит, пока мы не получим более подробные требования». Ситуация заходит в тупик.

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

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

Таблица 12.13. Пример использования метода футболки для классификации функций по коммерческой ценности и затратах на разработку

Определение подобных отношений между коммерческой ценностью pi затратами ка разработку позволяет специалисту, не обладающему технической квалификацией, высказывать мнения вроде следующего: «Если реализация функции В требует больших затрат, она мне не нужна, потому что функция обладает малой коммерческой ценностью». Возможность принятия таких решений на ранней стадии работы над функцией чрезвычайно полезна. Если бы вместо этого функция прошла через определенную работу по постановке требований, проектированию, выработке архитектуры и т. д., может оказаться, что вы напрасно расходуете усилия на функцию, не оправданную по затратам. В области разработки программного обеспечения ранний ответ «Нет» дорогого стоит. Метод футболки позволяет принимать решения об исключении функций на ранней стадии работы над проектом и исключить дальнейшее перемещение этих функций по конусу неопределенности.

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

Таблица 12.14. Вычисление чистой стоимости по соотношению затрат к коммерческой ценности

Наличие подобной таблицы позволит включить третий столбец в исходную таблицу затрат/коммерческой ценности (см. табл. 12.13) и отсортировать ее по чистой стоимости, как показано в табл. 12.15.

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

Помните, что последний столбец содержит приближенные данные. Я не предлагаю вычислить список и провести «пороговую линию» — сортировка по приближенной коммерческой ценности полезна прежде всего тем, что она позволяет быстро дать ответ «определенно да» для функций в верхней части списка и «определенно нет» для функций в нижней части списка. Основное обсуждение перемещается в середину списка, где оно будет наиболее продуктивным.

СОВЕТ № 59 -.

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

12.5. Другие применения опосредованных методов.

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

СОВЕТ № 60 -.

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

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

СОВЕТ № 61 -.

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

Дополнительные ресурсы.

Cohn, Mike. «Agile Estimating and Planning». Upper Saddle River, NJ: Prentice Hall Professional Technical Reference, 2006. В книге Кона приводится более подробное обсуждение абстрактных рейтингов, включая факторы планирования и методы оценки.

Humphrey, Watts S. «А Discipline for Software Engineering». Reading, MA: Addison-Wesley, 1995. В главе 5 книги Хамфри рассматривается опосредованный метод, названный автором «методом PROBE», а также более подробно рассматриваются статистические методы, на которых он основывается. Кроме того, в главе 5 обсуждается метод нечеткой логики.