Управление разработкой ПО

Метрики ПО

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

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

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

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

Одна из первых идей, которая приходит в голову при оценке трудоемкости и времени разработки ПО, — оценить сначала сложность или размер программы, а потом умножить полученную оценку на производительность исполнителей. Похоже, однако, что природа разработки программ такова, что ее трудоемкость слабо связана с размерами результата (например, приводимая ниже модель COCOMO, выражает эту связь в достаточно сложном виде). Часто оказывается, что оценить сразу трудоемкость по аналогии с имеющимся примерами можно точнее, чем оценив сначала размер. Тем не менее, метрики размера и сложности ПО часто используются для оценки трудоемкости разработки.

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

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

Более хитрой метрикой сложности программы являются функциональные точки (functional points, FP) [4,5]. Количество функциональных точек в программной системе вычисляется примерно следующим образом.

увеличить изображение
Рис. 16.4. Схема рассмотрения системы при оценке ее сложности в функциональных точках

• Выделяются обращения к системе с целью ввода данных, с целью получения каких-то уже имеющихся в ней данных (отчеты), и с запросами, в ходе которых данные вводятся в систему, перерабатываются и выдаются какие-то результаты. Дополнительно определяются группы взаимосвязанных данных (называемые файлами) внутри системы и аналогичные группы, лежащие вне ее, но используемые в ее работе.
• Для всех данных из перечисленных пяти категорий оценивается их сложность (по шкале "низкая"–"средняя"–"высокая").
• Итоговая сложность программной системы вычисляется как сумма сложностей выявленных отдельных представителей этих пяти категорий. Сложность ввода, вывода, запроса или группы данных вычисляется умножением оценки сложности составляющих данных на весовой коэффициент, который можно найти в стандартах [4,5] или определить на основе собственного опыта. Обычно весовые коэффициенты групп данных больше, чем коэффициенты для вводов, выводов или запросов.

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

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

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

Наиболее известным методом оценки трудоемкости и времени проекта, основанным на большом количестве данных из проведенных ранее проектов, является конструктивная модель стоимости версии II ( Constructive Cost Model II, COCOMO II ) [7,8,9].

В рамках этой модели оценки трудоемкости проекта и времени, требующегося на его выполнение, определяются тремя разными способами на разных этапах проекта:

• На самых ранних этапах, когда примерно известны только общие требования, а проектирование еще не начиналось, используется модель состава приложения (Application Composition Model). В ее рамках трудоемкость проекта оценивается в человеко-месяцах по формуле

  Effort = A*Size.

  • Size представляет собой оценку размера в терминах экранов, форм, отчетов, компонентов и модулей будущей системы. Каждый такой элемент оценивается с коэффициентом от 1 до 10 в зависимости от своей сложности.
  • Коэффициент A учитывает возможное переиспользование части компонентов и производительность разработки, зависящую от опытности команды и используемых инструментов и оцениваемую числом от 4 до 50.

    A = (100 – (процент переиспользования))/производительность.
• На следующих этапах, когда требования уже в основном известны и начинается разработка архитектуры ПО, используется модель этапа предварительного проектирования (Early Design Model) и следующие формулы.

  Для трудоемкости (в человеко-месяцах):

  Effort = A*(Size)B*ME + (трудозатраты на автоматически генерируемый код)

  Для времени (в месяцах):

  Time = T*EffortS (0.28+0.2*(B-1.01))*Sced.

  • Коэффициент A считается равным 2,45, а T считается равным 3,67.
  • Size — оценка размера ПО в тысячах строк кода.
  • B — фактор процесса разработки, который вычисляется по формуле
    

    где факторы W_i принимают значения от 0 до 5:

    • W₁ — предсказуемость проекта для данной организации, от полностью знакомого (0) до совсем непредсказуемого (5);
    • W₂ — гибкость процесса разработки, от полностью определяемого командой при выполнении общих целей проекта (0) до полностью фиксированного и строгого (5);
    • W₃ — степень удаления рисков, от полной (0) до небольшой (5), оставляющей около 80% рисков;
    • W₄ — сплоченность команды проекта, от безукоризненного взаимодействия (0) до больших трудностей при взаимодействии (5);
    • W₅ — зрелость процессов в организации, от 0 до 5 в виде взвешенного количества положительных ответов на вопросы о поддержке ключевых областей процесса в модели CMM (лекция 2).
  • M_E — произведение семи коэффициентов затрат, каждый из которых лежит в интервале от 1 до 6:
    • возможности персонала;
    • надежность и сложность продукта;
    • требуемый уровень повторного использования;
    • сложность платформы;
    • опытность персонала;
    • использование инструментов;
    • плотность графика проекта.
  • Effort_S обозначает оценку трудоемкости без учета плотности графика, а Sced — требуемое сжатие времени выполнения проекта.
• После того, как разработана архитектура ПО, оценки должны выполняться с использованием постархитектурной модели (Post-Architecture Model).

  Формула для трудоемкости (в человеко-месяцах):

  Effort= A*(Kreq*Size)B*MP + (трудозатраты на автоматически генерируемый код)

  Для времени — та же формула, что и в предыдущей модели (в месяцах):

  Time = T*EffortS(0.28+0.2*(B-1.01))*Sced.

  • Size = (размер нового кода в тыс. строк) + RSize, где

    RSize = (размер переиспользуемого кода в тыс. строк) * (100 – AT)/100 *
     (AA + 0,4*DM + 0,3*CM + 0,3*IM + SU)/100

    • AT — процент автоматически генерируемого кода;
    • AA — фактор трудоемкости перевода компонентов в повторно используемые, от 0 до 8;
    • DM — процент модифицируемых для переиспользования проектных моделей;
    • CM — процент модифицируемого для переиспользования кода;
    • IM — процент затрат на интеграцию и тестирование повторно используемых компонентов;
    • SU — фактор понятности переиспользуемого кода, от 10 для простого, хорошо структурированного, до 50 для сложного и непонятного; равен 0, если CM = DM = 0.
  • Все коэффициенты, кроме K_req и M_P, имеют те же значения, что и в предыдущей модели.
  • Коэффициент K_req вычисляется как (1 + (процент кода, выброшенного из-за изменений в требованиях)/100).
  • Коэффициент M_P является произведением 17 коэффициентов затрат, имеющих значения от 1 до 6:
    • надежность продукта;
    • сложность продукта;
    • размер базы данных разрабатываемого приложения;
    • требуемый уровень повторного использования;
    • требуемый уровень документированности;
    • уровень производительности по времени;
    • уровень требований к занимаемой оперативной памяти;
    • изменчивость платформы;
    • возможности аналитика проекта;
    • возможности программистов;
    • опыт работы команды в данной предметной области;
    • опыт работы команды с используемыми платформами;
    • опыт работы команды с используемыми языками и инструментами;
    • уровень текучести персонала в команде ;
    • возможности используемых инструментов;
    • возможности общения между членами команды ;
    • фактор сжатия графика проекта.

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