Определение размера программного обеспечения

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

Предыстория

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

Например, если инженер-программист создал небольшое веб-приложение-калькулятор, мы можем сказать, что трудозатраты на проект составили 280 человеко-часов. Однако это не дает никакой информации о размере самого программного продукта . И наоборот, мы можем сказать, что размер приложения составляет 5000 LOC (строк кода) или 30 FP (функциональных точек), не указывая, какие усилия по проекту необходимы для его создания.

Функциональные методы определения

Исторически сложилось так, что наиболее распространенным методом определения размера программного обеспечения был подсчет строк кода , написанных в исходном коде приложения. Другой подход заключается в измерении функционального размера, чтобы выразить размер функциональности в виде числа путем выполнения анализа функциональных точек . Исходный метод определения размера — IFPUG . Метод функционального определения размера (FSM) IFPUG FPA использовался успешно, несмотря на то, что он менее точен при оценке сложных алгоритмов и его относительно сложнее использовать, чем при оценке строк кода. Появились адаптации исходной методологии измерения функционального размера, и этими стандартами являются: функциональные точки COSMIC , функциональные точки Mk II , функциональные точки Nesma и функциональные точки FiSMA. Другие варианты этих стандартов включают объектно-ориентированные функциональные точки (OOFP) и более новые варианты, такие как взвешенные микрофункциональные точки , которые учитывают сложность алгоритмов и потоков управления .

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

Другие методы определения размера программного обеспечения включают определение размера программного обеспечения на основе вариантов использования , которое основано на подсчете количества и характеристик вариантов использования, обнаруженных в части программного обеспечения, и измерение функционального размера COSMIC , которое касается определения размера программного обеспечения, которое имеет очень ограниченный объем хранимых данных, таких как как системы «управления процессами» и «реального времени».

И метод IFPUG , и методы COSMIC являются стандартами ISO/IEC.

Нефункциональный метод определения

Метод IFPUG для определения размера нефункциональных аспектов программного обеспечения или компонента называется SNAP, поэтому нефункциональный размер измеряется в баллах SNAP . Модель SNAP состоит из четырех категорий и четырнадцати подкатегорий для измерения нефункциональных требований. Нефункциональные требования сопоставляются с соответствующими подкатегориями. Каждая подкатегория имеет размер, а размер требования представляет собой сумму размеров ее подкатегорий. Процесс определения размера SNAP очень похож на процесс определения размера функциональной точки. В пределах приложения нефункциональные требования связаны с соответствующими категориями и их подкатегориями. Используя стандартизированный набор основных критериев, каждая из подкатегорий затем определяется в соответствии с ее типом и сложностью; размер такого требования представляет собой сумму размеров его подкатегорий. Затем эти размеры суммируются, чтобы получить оценку нефункционального размера программного приложения.

Дополнительная информация

Некоторые стандарты качества программного обеспечения организации разработки программного обеспечения требуют использования допустимого метода определения размера в рамках стандартного жизненного цикла . Например, интеграция модели зрелости возможностей ( CMMI такое требование предъявляет ). Организация не может быть оценена (сертифицирована) как уровень CMMI 2 или 3, если не используется адекватный подход к определению размера программного обеспечения.

См. также

• ИЗВИНИ
• ЦЕНА Системы
• Сравнение программного обеспечения для оценки разработки