`

СПЕЦІАЛЬНІ
ПАРТНЕРИ
ПРОЕКТУ

Чи використовує ваша компанія ChatGPT в роботі?

BEST CIO

Определение наиболее профессиональных ИТ-управленцев, лидеров и экспертов в своих отраслях

Человек года

Кто внес наибольший вклад в развитие украинского ИТ-рынка.

Продукт года

Награды «Продукт года» еженедельника «Компьютерное обозрение» за наиболее выдающиеся ИТ-товары

 

Разработка ПО: оценка результата

Статья опубликована в №34 (553) от 12 сентября

0 
 

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

...слабо развиты наши методы оценок. В сущности, они отражают молчаливое и совершенно неверное предположение, что все будет идти хорошо.
Фредерик Брукс

В одной из своих мини-статей Джоэль Спольски (Joel Spolsky) – бывший менеджер команды разработчиков Microsoft Excel, автор нескольких книг по созданию ПО, основатель и бессменный руководитель компании Fog Creek Software – удачно подметил, что софтверные организации склонны вознаграждать программистов, которые: а) пишут много кода; б) исправляют много ошибок. Соответственно, наилучший способ отличиться в таких условиях – это создать большое количество некачественного кода, а потом героически устранять в нем собственные же промахи.

Казалось бы, любая формальная система оценки результата будет стимулировать прежде всего карьеризм и лишь потом – послужит толчком к положительным изменениям в самой организации и создаваемых продуктах. Подобное отношение со стороны персонала, а нередко и руководства, только способствует признанию ее несостоятельной – вместо совершенствования и поиска более эффективных альтернатив. Чаще всего это приводит к полному отказу от применения научного подхода: по данным Software Engineering Institute (SEI), около 80% всех внедренных систем количественной оценки процесса разработки ПО оказываются практически невостребованными на протяжении первых двух лет.

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

Линейный подход

В простейшем случае определить стоимость разработки ПО можно исходя из количественной оценки трудозатрат Т (в неких единицах, например человеко-месяцах или человеко-часах) и их удельной стоимости Ц:

С = Т × Ц.

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

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

Т = Р × П,

где Р – размер исходного кода ПО; П – временнаóя производительность.

Эта примитивная формула активно применяется и по сей день, хотя ее несостоятельность была установлена довольно давно. Пожалуй, самой известной работой, в которой критикуется данный подход, является выдержавшая более двадцати изданий по-настоящему классическая книга Фредерика Брукса (Frederick Brooks) «Мифический человеко-месяц, или Как создаются программные системы», впервые увидевшая свет еще в 1977 г.

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

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

Функциональные точки и их разновидности

Наверное, наиболее удачной заменой количеству строк кода для измерения производительности стали функциональные точки (function points), впервые предложенные сотрудником IBM Аланом Альбрехтом (Allan Albrecht) в 1979 г. Данный подход уже достаточно подробно рассматривался на страницах нашего журнала, и мы не будем останавливаться на его деталях, отметим только самые важные преимущества: поскольку применение функциональных точек основано на изучении требований, то оценка необходимых трудозатрат может быть выполнена на самых ранних стадиях работы над проектом и далее будет уточняться по ходу жизненного цикла, а явная связь между требованиями к создаваемой системе и получаемой оценкой позволяет заказчику понять, за что именно он платит, и во что выльется изменение первоначального задания.

Постепенно метод функциональных точек превратился в индустриальный стандарт, и в 1986 г. для его поддержки и развития была создана некоммерческая организация IFPUG (International Function Point User Group). Кроме того, он послужил основой для множества производных подходов.

Точки свойств. В условиях, когда сформулированные требования не отражают истинной сложности реализации (что особенно характерно для системного ПО, критически важных программных комплексов и пр.), метод функциональных точек себя не оправдывает. В этом случае на помощь приходит его модифицированный вариант, предложенный в 1988 г. Кейперсом Джонсом (Capers Jones), который учитывает не только требования к системе, но и внутренние особенности ее реализации – метод точек свойств (feature points). Он очень близок к методу функциональных точек, с тем лишь отличием, что предусматривает корректирование получаемой оценки с учетом алгоритмической сложности.

Метод Mark II. Еще одна примечательная модификация метода функциональных точек, представленная Чарльзом Саймонсом (Charles Symons) также в 1988 г. Автор стремился избавиться от многих известных его недостатков и сделать более пригодным для оценки сложных систем. В частности, Mark II позволяет добиться одного и того же результата как при оценке системы в целом, так и при суммировании оценок, полученных для составляющих ее подсистем.

Трехмерные функциональные точки. Еще одно логическое развитие оригинального подхода было предложено софтверным подразделением корпорации Boeing в 1991 г. В основу этого метода положена идея о том, что сложность задачи в программной среде можно представить в трех измерениях – данные (количество вводов/выводов), функции (сложность вычислений) и контроль (управляющая логика). Важно отметить, что он выходит за рамки исключительно программных проектов и позволяет оценивать трудоемкость решения задач в различных сферах – деловой, научной и т. д.

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

Оценка с использованием эмпирических данных

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

Wideband Delphi. Широко используемая в классическом менеджменте технология экспертной оценки по методу Delphi, созданная в Rand Corporation еще в 1966 г., нашла свое применение и в программных проектах. Часто используемая в софтверной индустрии его вариация получила название Wideband Delphi и отличается от традиционных «дельфийских» оценок ускоренной процедурой выработки решения.

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

Метод ДеМарко. Относительно простой, но эффективный подход к оценке стоимости ПО на основе накопленного опыта был разработан Томом ДеМарко (Tom DeMarco) в 1982 г. Основан он на использовании так называемой «бэнг-метрики» (Bang Metric), близкой по своему содержанию к функциональным точкам. Но главная его особенность состоит в том, что оценки корректируются с учетом хронологических данных по выполненным ранее проектам, что позволяет получить не абстрактные показатели, а приближенные значения реальных затрат ресурсов и времени. Последовательное и систематическое применение данного метода позволяет постепенно повышать точность оценок и добиваться очень хороших результатов.

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

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

Вероятно, первой нелинейной моделью, использующей эмпирические данные и нашедшей практическое применение при оценке стоимости ПО, стала SLIM (Software Life-cycle Model), предложенная в 1978 г. Лоуренсом Патнамом (Lawrence Putnam). Согласно ей трудоемкость вычисляется по следующей формуле:

Разработка ПО оценка результата

Размер проекта (P) чаще всего исчисляется в количестве строк кода, хотя известны случаи успешного применения модели и для других единиц, например функциональных точек. C – фактор среды, некая технологическая константа, учитывающая, помимо уровня технологий, также и производительность персонала, которая может различаться от команд к команде. td – ограничение на срок поставки (в годах).

SLIM была создана на базе реальных данных, собранных в Министерстве обороны США, и ориентирована в первую очередь на крупные проекты. Несмотря на возможность калибровки модели на основе хронологической информации, что несколько повышает качество результатов, она не приобрела широкой популярности, хотя существуют организации, успешно использующие ее в проектном менеджменте и сегодня (qsm.com).

COCOMO. Пожалуй, самой популярной моделью для оценки стоимости разработки ПО, которая де-факто стала стандартом, является COCOMO (COnstructive COst MOdel). Она была представлена в 1981 г. Барри Боэмом (Barry Boehm), известным ученым, внесшим огромный вклад в развитие научных подходов к управлению программными проектами – им разработаны спиральная модель проектирования ПО и Wideband Delphi, кроме того, когда-то именно он предсказал, что в будущем стоимость ПО превысит стоимость оборудования.

COCOMO создана на основе анализа статистических данных 63 проектов различных типов. Фактически под общим названием скрываются три уровня детализации: базовый, промежуточный и подробный. Также предусмотрено три режима использования модели в зависимости от размеров команды и проекта (табл. 1).

Таблица 1. Режимы модели COCOMO
Название режима Размер проекта Описание
Органичный До 50 KLOC Некрупный проект разрабатывается небольшой командой, для которой нехарактерны нововведения, и среда остается стабильной
Сблокированный 50–300 KLOC Относительно небольшая команда занимается проектом среднего размера, в процессе разработки необходимы определенные инновации, среда характеризуется незначительной нестабильностью
Внедренный Более 300 KLOC Большая команда разработчиков трудится над крупным проектом, необходим значительный объем инноваций, среда состоит из множества элементов, которые не характеризуются стабильностью

Для оценки трудозатрат на базовом уровне модели COCOMO применяется следующая формула:

Т = a × Р b,

где a и b – константы, которые зависят от режима использования модели.

В соответствии с этой формулой трудозатраты вообще нелинейно зависят от размера проекта и скачкообразно изменяются при смене режима (табл. 2). Другая интересная особенность COCOMO – рост трудозатрат при переходе к более высокому режиму не означает безусловного увеличения длительности (F) выполнения проекта, которая вычисляется по формуле:

F = 2,5 × Т k,

поскольку при этом изменяется значение константы k.

Таблица 2. Значения коэффициентов модели COCOMO в зависимости от режима использования
Название режима Значение коэффициента a Значение коэффициента b Значение коэффициента k
Органичный 2,4 1,05 0,38
Сблокированный 3,0 1,12 0,35
Внедренный 3,6 1,20 0,32

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

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

При построении COCOMO II для обработки статистических данных использовался Байесовский анализ, который дает лучшие результаты для программных проектов, характеризующихся неполнотой и неоднозначностью, в отличие от многофакторного регрессионного, примененного в COCOMO. Также в ней допускается измерять размер проекта не только числом строк кода, но и более современными функциональными и объектными точками. Помимо прочего, при расчете показателей COCOMO II учитывает уровень зрелости процесса разработки в соответствии с моделями SEI CMM/CMMI.

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

Таблица 3. Модель COCOMO II фактически объединяет три различные подмодели
Название модели Описание
Композиционная прикладная Ориентирована на проекты, создаваемые с применением современных инструментальных средств и UML, использует в качестве метрики объектные точки
Ранней разработки проекта Применяется для получения приближенных оценок по проекту до определения его архитектуры, использует в качестве метрик количество строк кода или функциональные точки
Постархитектурная модель Наиболее детализированная модель, используется после разработки архитектуры проекта и позволяет получить самые точные оценки, применяет в качестве метрик количество строк кода или функциональные точки

Заключение

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

Так может на текущий момент не существует надежных методов измерения, и потому стоит отказаться от любых попыток их применения? Возьмем на себя смелость ответить на этот вопрос отрицательно. Программная индустрия невероятно сложна как предметная область, и результат зависит не только от объективных, но и от множества субъективных факторов, плохо поддающихся формализации и оценке. Аналогично тому как Фредерик Брукс в 1986 г. в своей статье «Серебряной пули нет – сущность и акциденция в программной инженерии» пришел к выводу, что «создание программных систем всегда будет трудным», можно утверждать, что точно так же будет трудной и оценка этого процесса.

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

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

e-mail автора: [email protected]

Ready, set, buy! Посібник для початківців - як придбати Copilot для Microsoft 365

0 
 

Напечатать Отправить другу

Читайте также

 

Ukraine

 

  •  Home  •  Ринок  •  IТ-директор  •  CloudComputing  •  Hard  •  Soft  •  Мережі  •  Безпека  •  Наука  •  IoT