Метрика программного обеспечения - Software metric
| Разработка программного обеспечения |
|---|
| Активность ядер |
| Парадигмы и модели |
| Методологии и рамки |
| Вспомогательные дисциплины |
| Практики |
| инструменты |
| Стандарты и свод знаний |
| Глоссарии |
| Контуры |
А метрика программного обеспечения - это эталон меры степени, в которой программная система или процесс обладает некоторыми свойствами. Даже если метрика не является измерением (метрики - это функции, а измерения - это числа, полученные путем применения метрик), часто два термина используются как синонимы. Поскольку количественные измерения необходимы во всех науках, постоянные усилия Информатика практикам и теоретикам привнести аналогичные подходы к разработке программного обеспечения. Целью является получение объективных, воспроизводимых и поддающихся количественной оценке измерений, которые могут иметь множество ценных применений в планировании расписания и бюджета, оценке затрат, обеспечении качества, тестировании, отладке программного обеспечения, оптимизации производительности программного обеспечения и оптимальном распределении кадровых задач.
Общие программные измерения
Общие программные измерения включают:
- Метрика программного обеспечения ABC
- Сбалансированная система показателей
- Ошибки за строку кода
- Покрытие кода
- Сплоченность
- Плотность комментариев[1]
- Компоненты программного обеспечения Connascent
- Конструктивная модель затрат
- Связь
- Цикломатическая сложность (Сложность Маккейба)
- Плотность дефектов - дефекты, обнаруженные в компоненте
- Потенциал дефекта - ожидаемое количество дефектов в конкретном компоненте
- Скорость удаления дефектов
- DSQI (индекс качества проектной конструкции)
- Функциональные точки и автоматизированные функциональные точки, Группа управления объектами стандарт[2]
- Сложность Холстеда
- Длина пути к инструкции
- Индекс ремонтопригодности
- Количество строк кода
- Время выполнения программы
- Время загрузки программы
- Размер программы (двоичный)
- Взвешенные микро-функциональные точки
- CISQ автоматизированные измерения характеристик качества
Ограничения
Поскольку разработка программного обеспечения представляет собой сложный процесс, с большим разбросом как методологий, так и целей, трудно определить или измерить качество и количество программного обеспечения и определить действительную и параллельную метрику измерения, особенно при выполнении такого прогноза до детального проектирования. Еще один источник трудностей и споров - определение того, какие показатели имеют значение и что они означают.[3][4]Таким образом, практическая полезность программных измерений ограничена следующими областями:
- Планирование
- Размер программного обеспечения
- Сложность программирования
- Оценка усилий по разработке программного обеспечения
- Качество программного обеспечения
Конкретное измерение может быть нацелено на один или несколько из вышеперечисленных аспектов или на баланс между ними, например, как индикатор мотивации команды или результативности проекта.
Принятие и общественное мнение
Некоторые специалисты по разработке программного обеспечения отмечают, что упрощенные измерения могут принести больше вреда, чем пользы.[5] Другие отметили, что метрики стали неотъемлемой частью процесса разработки программного обеспечения.[3]Влияние измерения на психологию программистов вызвало опасения по поводу вредного воздействия на производительность из-за стресса, беспокойства по поводу производительности и попыток обмануть метрики, в то время как другие считают, что это положительно влияет на ценность разработчиков по отношению к их собственной работе и предотвращает их недооценку. Некоторые утверждают, что определение многих методологий измерения неточно, и, следовательно, часто неясно, как инструменты для их вычисления достигают определенного результата.[6] в то время как другие утверждают, что несовершенная количественная оценка лучше, чем ее отсутствие («Вы не можете контролировать то, что не можете измерить»).[7]Факты свидетельствуют о том, что показатели программного обеспечения широко используются правительственными учреждениями, вооруженными силами США, НАСА,[8] ИТ-консультанты, академические учреждения,[9] и коммерческие и академические программное обеспечение для оценки разработки.
Смотрите также
- Целевой вопрос-показатель
- Список инструментов для статического анализа кода
- Классификация ортогональных дефектов
- Программный кризис
- Программная инженерия
- Метрики программного пакета
Рекомендации
- ^ «Пороговые значения метрики описательной информации (DI)». Инженерный центр наземного программного обеспечения. Архивировано из оригинал 6 июля 2011 г.. Получено 19 октября 2010.
- ^ «OMG принимает автоматическую спецификацию функциональных точек». Omg.org. 2013-01-17. Получено 2013-05-19.
- ^ а б Бинсток, Эндрю. «Integration Watch: эффективное использование метрик». SD Times. BZ Media. Получено 19 октября 2010.
- ^ Колава, Адам. «Когда, почему и как: анализ кода». Проект кода. Получено 19 октября 2010.
- ^ Канер, доктор Джем, Показатели разработчика программного обеспечения: что они измеряют и откуда мы знаем?, CiteSeerX 10.1.1.1.2542
- ^ Линке, Рюдигер; Лундберг, Йонас; Лёве, Велф (2008), «Сравнение программных метрик инструментов» (PDF), Международный симпозиум по тестированию и анализу программного обеспечения, 2008 г., стр. 131–142
- ^ Демарко, Том. Управление проектами программного обеспечения: управление, измерение и оценка. ISBN 0-13-171711-1.
- ^ «Рабочая группа НАСА по планированию показателей и отчетности (MPARWG)». Earthdata.nasa.gov. Архивировано из оригинал на 2011-10-22. Получено 2013-05-19.
- ^ «Центр системной и программной инженерии USC». Sunset.usc.edu. Получено 2013-05-19.