Определение размера программного обеспечения или оценка размера программного обеспечения — это деятельность в области разработки программного обеспечения , которая используется для определения или оценки размера программного приложения или компонента, чтобы иметь возможность реализовать другие действия по управлению программными проектами (такие как оценка или отслеживание). Размер — это неотъемлемая характеристика части программного обеспечения, так же как вес — это неотъемлемая характеристика материального материала.
Размер программного обеспечения отличается от оценки усилий по созданию программного обеспечения . Размер оценивает вероятный размер части программного обеспечения, в то время как оценка усилий предсказывает усилия, необходимые для его создания. Соотношение между размером программного обеспечения и усилиями, необходимыми для его создания, называется производительностью .
Например, если инженер-программист создал небольшое веб-приложение-калькулятор, мы можем сказать, что проектные усилия составили 280 человеко-часов. Однако это не дает никакой информации о размере самого программного продукта . И наоборот, мы можем сказать, что размер приложения составляет 5000 LOC (строки кода) или 30 FP (функциональные точки), не определяя проектные усилия, необходимые для его создания.
Исторически наиболее распространенной методологией измерения размера программного обеспечения был подсчет строк кода, написанных в исходном коде приложения. Другой подход заключается в выполнении измерения функционального размера, чтобы выразить размер функциональности в виде числа путем выполнения анализа функциональных точек . Первоначальным методом измерения является IFPUG . Метод функционального измерения размера IFPUG FPA (FSM) успешно использовался, несмотря на то, что он был менее точным при оценке сложных алгоритмов и был относительно более сложным в использовании, чем оценка строк кода. Появились адаптации оригинальной методологии измерения функционального размера, и этими стандартами являются: COSMIC Function Points , Mk II Function Points, Nesma Function Points и FiSMA Function Points. Другие варианты этих стандартов включают Object-Oriented Function Points (OOFP) и более новые варианты, такие как Weighted Micro Function Points , которые учитывают сложность алгоритма и потока управления .
Лучший метод функционального определения размера зависит от ряда факторов, включая функциональную область приложений, зрелость процесса в организации-разработчике и степень использования метода FSM. [1] [2] Существует множество применений и преимуществ функциональных точек [3], помимо измерения производительности проекта и оценки запланированных проектов, к ним относятся мониторинг хода выполнения проекта и оценка покрытия требований готовых коммерческих пакетов (COTS).
Другие методы оценки программного обеспечения включают оценку программного обеспечения на основе вариантов использования , которая основана на подсчете количества и характеристик вариантов использования, обнаруженных в программном обеспечении, и измерение функционального размера COSMIC , которое касается оценки программного обеспечения, имеющего очень ограниченный объем хранимых данных, например, систем «управления процессами» и «реального времени».
Оба метода — IFPUG и COSMIC — соответствуют стандартам ISO/IEC.
Метод IFPUG для определения размера нефункциональных аспектов программного обеспечения или компонента называется SNAP, поэтому нефункциональный размер измеряется с помощью точек SNAP . Модель SNAP состоит из четырех категорий и четырнадцати подкатегорий для измерения нефункциональных требований. Нефункциональные требования сопоставляются с соответствующими подкатегориями. Каждая подкатегория имеет размер, а размер требования представляет собой сумму размеров ее подкатегорий. Процесс определения размера SNAP очень похож на процесс определения размера функциональных точек. В границах приложения нефункциональные требования связаны с соответствующими категориями и их подкатегориями. Используя стандартизированный набор основных критериев, каждая из подкатегорий затем определяется в соответствии с ее типом и сложностью; размер такого требования представляет собой сумму размеров его подкатегорий. Затем эти размеры суммируются, чтобы получить меру нефункционального размера программного приложения.
Несколько стандартов качества программного обеспечения предписывают использование допустимого метода определения размера как части стандартного жизненного цикла разработки программного обеспечения организации . Например, Интеграция модели зрелости возможностей ( CMMI ) выдвигает такое требование. Организация не может быть оценена (сертифицирована) как CMMI уровня 2 или 3, если определение размера программного обеспечения не используется адекватно.