Рубрики

Свежие записи

Оценка трудозатрат разработки программной компоненты

GD Star Rating
loading...
GD Star Rating
loading...




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

Данный материал перекликается с другими статьями, размещенными в моем блоге:

Тема метрик очень мне интересна и близка. В ближайшее время планирую опубликовать еще пару-тройку материалов, но они слишком объемные. На верстку уйдет много времени. Как только – так сразу :)

План не предсказывает будущего.
Он лишь позволяет должным образом
реагировать на неизвестное будущее.

Аноним

Введение

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

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

  1. Постановка задачи

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

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

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

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

    1. Оценка трудозатрат по созданию программной компоненты должна опираться на предшествующий опыт оценки аналогичных компонент.
    2. Оценка должна оценивать как новую работу, так и работу по внесению изменений и переработку алгоритмов работы компоненты.
    3. Оценка должна учитывать квалификацию сотрудников.
    4. Оценка должна учитывать расходы на весь цикл создания программной компоненты, включая руководство процессом и этап тестирования.
    5. Необходимо иметь оценку точности.
  2. Существующие решения

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

    1) Оценка трудозатрат по количеству строчек кода. Она появилась в середине 80-х годов легла в основу методики COCOMO (Constructive Cost Model), см. [1], стр. 380. В основе этой методики лежит оценка объёма работ по количеству строчек кода (Lines Of Code — LOC). Базовая формула оценки трудозатрат COCOMO:

    (1)

    где Eтрудозатраты, выраженные в человеко-месяцах; a и b – константы, определенные на основе регрессионного анализа, в зависимости от проекта. KSLOC – количество тысяч строк кода (под строчками кода SLOC понимаются логические строки кода, а именно строки в понимании используемого языка программирования, без учета комментариев); EAF (Effort Adjustment Factor) – фактор корректировки трудозатрат;

    Фактор корректировки трудозатрат EAF увеличивает или уменьшает трудозатраты в зависимости от факторов среды:

    (2)

    где Ci – один из факторов среды.

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

    2) Оценка трудозатрат по функциональным точкам. Метод оценки трудозатрат по функциональным точкам основывается на предположении, что существует связь между языком программирования и количеством строчек кода приходящимся на одну функцию. В процессе оценивания, происходит оценка количества функций, приходящихся на реализацию одного функционального требования, с учетом его сложности. В итоге, количество полученных функциональных точек пересчитывается в условные строчки кода или непосредственно в трудозатраты (см.[1], стр. 331).

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

    3) Экспертная оценка или трёх точечное оценивание (см. [2], стр. 138). Метод основывается на том, что эксперты дают три оценки затрат для каждого функционального требования системы: наилучшую, наихудшую и наиболее вероятную. Общая оценка определяется по формуле:

    (3)

    , где Bi – наилучшая оценка, Wi – наихудшая оценка, Mi – наиболее вероятная оценка. Исходя из предположения, что оценки имеют нормальное распределение, определяется псевдо стандартное отклонение:

    (4)

    Эта формула позволяет получить диапазон изменения объёма трудозатрат для реализации набора функциональных требований.

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

    Таким образом каждое из рассмотренных решений обладает рядом недостатков. В описываемом далее решении делается попытка частично устранить отмеченные недостатки.

  3. Предлагаемое решение

  4. Планирование

    За основу оценки трудозатрат по разработке программной компоненты возьмем оценку трудозатрат по количеству строчек кода по формуле (1) и (2). Будем оценивать каждое функциональное требование отдельно, при этом примем значение константы b равной 1. Предположим, что объём работ, зависит от вида работы, а время его выполнения зависит от мощности ресурса, необходимого для его выполнения. Тогда формула (1) преобразуется к виду:

    (5)

    , где Wj – мощность ресурса, необходимого для выполнения j-ого вида работы; KSLOC(i,j) – количество строк кода j-го вида работ для реализации i-го требования.

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

  • Код, описывающий интерфейс системы. Обычно это код описывающий сам интерфейс. Для компонент работающих в среде Интернет — это HTML код. Обозначим его как SLOCR;
  • Код, обрабатывающий элементы интерфейса и связывающий его с другими частями системы. Обычно это классы обработки ошибок ввода данных, записи данных в базу и т.п. Обозначим его как SLOCI;
  • Код, обеспечивающий определенную логику работы системы. Обычно, это классы, описывающие свойства объектов системы, взаимосвязь между бизнес функциями . Обозначим его как SLOCP;

Для расчета KSLOC можно воспользоваться формулой:

(6)

где Kp – фактор изменения логики работы системы; Ki – фактор изменения обработки интерфейсных элементов системы; Kr – фактор изменения интерфейса системы; Факторы K подбираются опытным путем. Например, для изменений менее 20% фактор изменений может быть равен 0,2; для 50% изменений — 0,7; для вновь создаваемых компонент — 1,0.

Мощность W определяется опытным путём, исходя из опыта работы над предыдущими компонентами.

Определение факторов среды EAF.

  • Фактор учета технологии разработки (ФУТР). Под этим фактором учитывается увеличение количества трудозатрат в результате того, что в процесс разработки вовлекается разное количество сотрудников.

    Сам процесс можно представить следующим образом. Процесс кодирования длится в течение времени «l» (см. рис.1).

    В это время задействованы «M» менеджеров проекта и «P» программистов. Процесс тестирования начинается сразу после кодирования, длится он в течении времени «lt», и в нем участвуют «M» менеджеров проекта, «T» тестеров и «P» программистов. Время тестирования является величиной зависимой от времени кодирования так, что (5).

    Таким образом, (7).

    При этом длительность разработки (8)

  • Фактор учета сложности и опыта разработки (ФУСОР). Фактор ФУСОР определен эмпирически и состоит из следующих значений:
    • Надо поправить то, что есть = 1,00;
    • Уже делали раньше, есть опыт = 1,10;
    • Есть опыт и не видно трудностей = 1,30;
    • Опыта нет, но есть помощь = 2,00;
    • Нет ни опыта, ни помощи = 4,00

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

    Таким образом, длительность кодирования и тестирования можно вычислить по формуле:

    (9)

    Трудозатраты на кодирования и тестирования можно вычислить по формуле:

    (10)

  1. Уточнение основных показателей

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

    Плановый расчет времени, для одного вида работ, описывается линейной зависимостью от объема выполняемой работы и мощности ресурсов:

    ,    (11)

    где V – объём работ, измеряемый в KSLOC; – величина, обратно пропорциональная мощности ресурса W и учитывающая факторы корректировки EAF.


    Рис. 2 График зависимости длительности разработки от объема работ и мощности ресурса

    Первоначальное значение, вычисленное по (11) для одной из работ имеет точку с координатами (t,V). После выполнения работы получим время t’. Полученная ошибка может быть следствием двух причин. Первая причина заключается в том, что была допущена ошибка в объёме работ. В этом случае, объём работ должен был бы быть V’ (см. рис.2). Вторая причина заключается в том, что была допущена ошибка в значении R, зависимой от мощности ресурса и факторов EAF. В этом случае, объём работ должен был остаться равным V. Таким образом, выполненный объём работ V» находится в промежутке между V и V’.

    Введем коэффициенты, учитывающие ошибки в объеме и в мощности KV и KR:

    (12)

    Выберем новую точку, находящуюся на отрезке между V и V’, соответствующую времени t’. У новой точки будут координаты (t’,V»), определяемые формулой:

    t’=t’, (13).

    Для корректировки параметров уравнения (11), воспользуемся методом оптимизации способом наименьших квадратов. Для этого посчитаем следующие значения:

    (14)

    (15)

    , где n – количество сделанных наблюдений, i = 1..n. , а и — средние значения.

    Новый скорректированный коэффициент (16)

    Для того чтобы узнать, каков диапазон изменения параметра R для среднего времени выполнения одной работы, построим 100(1-e)% доверительные интервалы:

    (17)

    (18)

    где te/2 — табличное значение распределения Стьюдента с n-2 степенями свободы.

    Делая расчёты по каждому из видов работ раздельно, можно уточнить предположения об объёмах и мощности ресурсов сделанных на этапе планирования.

    Уточнённое значение мощности с учетом усредненных коэффициентов EAF для выбранного вида работ будет (19).

    Уточнённое значение базовых объёмов для выбранного вида работ можно получить по формуле:

    (20)

  2. Примеры

    Пример 1. Определить стоимость работы по созданию макета Интернет системы на основе существующей системы. Работа заключается в изменении дизайна системы (около 50 форм), модификации и создании макета 30 форм. В проекте участвуют один менеджер проекта и три разработчика. Тестирование не требуется.

    В результате анализа существующей системы было выявлены следующие закономерности:

    Описание работы

    SLOC

    Объём кода логики

    SLOCP

    Объём

    кода

    обработки

    SLOCI

    Объём кода

    SLOCR

    Средний модуль проекта

    4000

    250

    150

    Было также определено, что мощность выполнения работ при создании Интернет систем аналогичного вида составляет W= 2,5.

    Количество строк кода для изменения дизайна интерфейса (из расчета изменения менее 20% полей формы) и форм макета (создание 100% полей формы):

    Фактор учета технологии разработки будет равен:

    Фактор учета сложности и опыта примем равным 1,1 (Делали раньше и есть опыт).

    Таким образом, длительность работы, исходя из расчета работы трех человек, составит:

    [мес]

    Полные трудозатраты с учетом тестирования составят:

    [чел/мес]

    Пример 2. В результате выполнения работ, были получены данные представленные в таблице 1. Показатель ΔR вычислен из прогноза на среднюю продолжительность работ. Необходимо провести анализ и уточнить базовые показатели для выполненных видов работ.

    Виды работ

    SLOCP

    SLOCI

    SLOCR

    R

    Время план.

    Время реал.

    SLOCP’

    SLOCI’

    SLOCR’

    R’

    ± ΔR

    №1

    2500

    200

    150

    0,4

    1,294

    1,545

    2463

    197

    148

    0,484

    0,05

    №2

    2500

    250

    200

    0,4

    1,28

    0,818

    1643

    164

    131

    0,389

    0,05

    №3

    1000

    50

    50

    0,4

    0,46

    0,92

    1667

    83

    83

    0,48

    4,0×10-08

    Таблица 1

    Работа №1.

    Из данных видно, что задержка выполнения работ составляет 1,545-1,294=0,251 месяца. Необходимо внести коррекцию равную . Возможны следующие виды коррекций:

    1. Коррекция по мощности
    2. Коррекция по объёму

    При таких значениях, коррекция по времени составит искомый коэффициент 1,21*0,985=1,19.

    При корректировке можно пренебречь коррекцией по объёму, в запас по времени.

    Работа №2.

    Из данных видно, что перевыполнение работ составляет 0,818-1,28=-0,462 месяца. Необходимо внести коррекцию равную . Возможны следующие виды коррекций:

    1. Коррекция по мощности
    2. Коррекция по объёму

    При таких значениях, коррекция по времени составит искомый коэффициент 0,9725*0,657=0,639.

    При корректировке можно пренебречь коррекцией по мощности в запас по времени.

    Работа №3.

    Из данных видно, что задержка выполнения работ составляет 0,92-0,46=0,46 месяца. Необходимо внести коррекцию равную . Возможны следующие виды коррекций:

    1. Коррекция по мощности
    2. Коррекция по объёму

    При таких значениях, коррекция по времени составит искомый коэффициент 1,2*1,667=2,0.

    Для принятия решения необходимо проанализировать реальный объём выполненных работ. Если не подтвердится предположение о превышении объёма сделанной работы в 1,7 раза, то в сочетании с низким значением показателя ΔR это может говорить о необходимости коррекции по мощности в два раза.

  3. Выводы

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

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

  • Управление Программными проектами. Достижение оптимального качества при минимуме затрат. Роберт Т. Фатрепп, Дональд Ф. Шафер., Линда И. Шафер. Издательский дом «Вильямс». 2003 год.
  • Быстрая и качественная разработка программного обеспечения. Э.Кармайкл, Д.Хейвуд. Издательский дом «Вильямс». 2003 год.

Авторы: Гольфанд И. Я., Хлебутин П. C.

Оценка трудозатрат разработки программной компоненты, 9.5 out of 10 based on 2 ratings

Связные и просто интересные записи:

Метки:loc, sloc, код, компонент, маккейб, метрики, программа, программирование, сложность, трудозатраты, цикломатичность

Leave a Reply

 

 

 

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Spam protection by WP Captcha-Free