Вот как стать лучше в оценках программного обеспечения

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

Вот что вы можете сделать, чтобы улучшить оценки.

Как работают модели оценки?

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

  • СТРОЙНЫЙ
  • КОКОМО
  • Функциональные точки
  • ВИДЯЩАЯ модель

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

Коэффициент производительности является мерой эффективности процесса⁵. Соотношение строк кода и рабочей силы дает коэффициент производительности. Наращивание рабочей силы является следствием изменения графика разработки⁵.

Эти числа рассчитываются двумя способами. Откалибруйте модель по эмпирическим данным. Используйте похожие прошлые проекты и получайте факторы. Или ответьте на 22 вопроса и получите оценку MBP и PF.²

SLIM фокусируется на персонале. Он дает оценки в зависимости от производительности персонала и всего жизненного цикла проекта.

Целью SLIM является изучение взаимосвязей между уровнями укомплектования персоналом, расписанием и усилиями⁵.

После кодирования вы можете использовать метод SLIM. Это основная проблема с этой метрикой.

COCOMO или МОДЕЛЬ КОНСТРУКТИВНЫХ ЗАТРАТ зависит от размера системы. Несколько факторов для базовой модели — это человеко-месяцы и тысячи доставленных строк кода².

Промежуточная модель более сложная. Принимает 15 факторов в фактической оценке. Принимая во внимание эти факторы, получаем очищенный, промежуточный COCOMO.

Оценщик проходит через все факторы стоимости. Оценивает проект на основе оценок. Выбирает драйвер стоимости, коэффициент из этой таблицы.

Умножьте эти 15 факторов, чтобы получить EAF. Этот поправочный коэффициент усилия используется в формуле для получения очищенного COCOMO.

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

Модель функция точки не рассматривает строки исходного кода. Функциональные баллы — это единицы измерения, единица бизнес-функциональности.

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

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

SEER (система оценки и оценки ресурсов) — это собственная модель⁵. Эта модель обеспечивает оценку, планирование усилий и необходимые ресурсы.

Данная модель работает по следующим параметрам:

  • эффективные строки кода
  • технология разработчика
  • время разработки

Производит оценку усилий, дефектов и затрат. С точки зрения размера SEER учитывает как функциональные точки, так и строки кода.

Помогают ли эти модели с оценками?

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

Эти модели плохо работают в некалиброванных средах². Средняя частота ошибок составляет около 500%. Это ожидаемо, поскольку эти модели не откалиброваны и не могут быть универсальными.

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

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

Модели, использующие функциональные точки и т.п., оценивают лучше².

Критики утверждают, что COCOMO маскирует догадки об оценке³.

Много факторов, когда дело доходит до строк кода. Качество кода, креативность разработчиков и повторное использование кода.

Великие разработчики многое делают с помощью 50 строк кода. Плохие не могут сделать то же самое с 200 строками кода.

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

Кейперс Джонс, аналитик программного обеспечения, утверждает следующее⁴. Проекты, использующие модель FP, имеют меньшее расползание объема, на 25% меньше отклонений от графика и экономят 25–75 долларов на единицу функции.

Вывод

Все вышеперечисленные методы могут быть использованы для оценки программного обеспечения. Не стоит так глубоко вникать в это дело.

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

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

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

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

Команда разработчиков влияет на оценку. Больше отличных разработчиков в оценке влияния команды.

Посмотрите на факторы затрат для модели COCOMO в разделе «Персонал». Пятая часть показателей связана с персоналом.

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

Ресурсы

[1] K Moløkken-Østvold, NC Haugen (10–13 апреля 2007 г.). Объединение оценок с покером планирования — эмпирическое исследование. 18-я Австралийская конференция по разработке программного обеспечения. IEEE: 349–58. doi: 10.1109/ASWEC.2007.15. ISBN 978–0–7695–2778–9. S2CID 11429738.

[2] Крис Ф. Кемерер. 1987. Эмпирическая проверка моделей оценки стоимости программного обеспечения. коммун. ACM 30, 5 (май 1987 г.), 416–429. DOI: https://doi.org/10.1145/22899.22906

[3] Хорхе Аранда и Стив Истербрук. 2005. Привязка и настройка в оценке программного обеспечения. ‹i›SIGSOFT Software. англ. Примечания‹/i› 30, 5 (сентябрь 2005 г.), 346–355. DOI: https://doi.org/10.1145/1095430.1081761

[4] Использование функциональных единиц для оценки и измерения программного обеспечения Джо Шофилд ppt

[5] Баша, Салим и Дхавачельван, Поннурангам. (2010). Анализ эмпирических моделей оценки усилий по программному обеспечению. Международный журнал компьютерных наук и информационной безопасности. 7.