SNAP - это аббревиатура от «Software Non-function Assessment Process», измерение размера нефункционального программного обеспечения . Метод определения размера SNAP дополняет ISO / IEC 20926: 2009, который определяет метод определения размера функциональных требований пользователя. Протокол SNAP является продуктом Международной группы пользователей функциональных точек ( IFPUG ), и его размер определяется с использованием «Руководства по методам нефункциональной оценки программного обеспечения» (APM), которое теперь в версии 2.4. Методология SNAP соответствует стандарту IEEE IEEE2430-2019.
Вступление
«Определение размера программного обеспечения или оценка размера программного обеспечения - это деятельность в программной инженерии, которая используется для определения или оценки размера программного приложения или компонента, чтобы иметь возможность реализовать другие действия по управлению программным проектом (такие как оценка или отслеживание). Размер является неотъемлемой характеристикой программного обеспечения, так же как вес является неотъемлемой характеристикой материального материала ».
Программное приложение может предоставить своим пользователям два аспекта ценности. Первый аспект - это способность к обработке данных. В основном это поток и хранение данных через приложение. Этот поток и хранилище можно определить как его «функциональность». Одним из показателей, используемых для измерения размера одной единицы этой функциональности, является «функциональная точка». Используя стандартную метрику функционального определения размеров (FSM), такую как в IFPUG «Руководство по методам подсчета функциональных точек» [1] (FSM ISO / IEC 20926: 2009), [2], специалист по подсчету функциональных точек может проверить функциональную часть программного приложения и измерьте его функциональный размер в единицах функциональных точек.
Дополнительные сведения о метрике функциональных точек и метриках определения размеров функционального программного обеспечения других организаций см. В библиографии, статье « Функциональная точка » в Википедии и в многочисленных ссылках в литературе.
Программное приложение может также обеспечивать другие аспекты, помимо возможностей обработки данных. IFPUG определяет эти типы программного обеспечения как «нефункциональные». Их размер измеряется по протоколу SNAP. IFPUG APM [3] подробно описывает, как определять нефункциональные аспекты программных приложений. Методология SNAP соответствует стандарту IEEE IEEE2430-2019. [4] Нефункциональные аспекты определены и классифицированы в ISO / IEC 25010: 2011 «Системная и программная инженерия - Требования и оценка качества систем и программного обеспечения (SQuaRE) - Модели качества систем и программного обеспечения». [5]
Функциональный размер вместе с нефункциональным размером следует использовать для измерения размера программных проектов. Эти два размера следует использовать для измерения производительности программного проекта, установки контрольных показателей и оценки стоимости и продолжительности программных проектов.
Нефункциональный метод определения размеров
Подобно определению размера функциональной точки, одной единицей нефункциональности является «точка SNAP», и размер нефункциональной части приложения можно измерить с помощью процедуры в APM. Подобно функциональным точкам, используя IFPUG APM, специалист по подсчету точек SNAP может проверить программное приложение и измерить размер его нефункциональной части в единицах точек SNAP. Также, как и функциональные точки, количество точек SNAP в приложении коррелирует с трудозатратами на разработку нефункциональной части этого приложения. Оригинальное исследование, детализирующее эту корреляцию, опубликовано в CrossTalk The Journal of Defense Software Engineering в виде статьи «Новая метрика программного обеспечения для дополнения функциональных точек процесса нефункциональной оценки программного обеспечения (SNAP)». [6]
Каждая часть (функциональная и нефункциональная) программного проекта требует усилий для разработки, которые пропорциональны размеру их программного обеспечения. Организации, занимающиеся разработкой программного обеспечения, могут использовать свои корреляции между функциональными точками и своими рабочими усилиями, а также между точками SNAP и своими рабочими усилиями, чтобы помочь спрогнозировать свои затраты и графики разработки программного обеспечения, а также для аудита проектов, чтобы определить, насколько хорошо было потрачено финансирование и соблюдены графики
SNAP распознает четыре категории и 14 подкатегорий нефункциональности. Они находятся в таблице ниже из APM.
- 1. Операции с данными
1.1. Проверка ввода данных1.2. Логико-математические операции1.3. Форматирование данных1.4. Внутренние перемещения данных1.5. Обеспечение добавленной стоимости для пользователей за счет конфигурации данных
- 2. Дизайн интерфейса
2.1. Пользовательские интерфейсы2.2. Методы помощи2.3. Множественные методы ввода2.4. Множественные форматы вывода
- 3. Техническая среда
3.1. Множественная платформа3.2. Технология баз данных3.3. Пакетные процессы
- 4. Архитектура
4.1. Компонентное программное обеспечение4.2. Несколько интерфейсов ввода / вывода
Например, разработка программного обеспечения для изменения размеров полей данных в таблице данных не отражает изменений в производительности обработки данных. Однако это развитие требует трудовых усилий. Форматирование данных считается нефункциональным и учитывается в подкатегории 1.3 SNAP.
Методы помощи (подкатегория 2.2) обычно считаются нефункциональными. По сравнению с процессом функциональной точки, который требует, чтобы данные пересекали границы приложения и поддерживали внутренний логический файл, данные справки могут быть закодированы для внутреннего хранения как часть разработки приложения и доступны по команде от пользователя. Этот доступ может быть любым, от всплывающей подсказки над значком на экране до доступа к части внутреннего руководства по эксплуатации приложения. Данные не обрабатываются как таковые, поэтому справка обычно считается нефункциональной.
Функциональные точки и точки SNAP измеряют два разных аспекта программного обеспечения и поэтому не складываются. Например, приложение из 500 функциональных точек и 300 точек SNAP не может считаться размером 800 некоторой метрики; функциональные точки и точки SNAP должны быть ортогональными. Хорошая ссылка на дополнительную подробную информацию о взаимосвязи между функциональностью и нефункциональностью находится в документе «Глоссарий терминов для нефункциональных требований и требований проекта, используемых при измерении, сравнительном анализе и оценке производительности программного проекта». [7]
Преимущества
SNAP предоставляет пользователям и командам разработчиков программного обеспечения множество преимуществ помимо использования только функциональных точек. Ниже приведены пять из многих примеров.
- Измерение нефункциональных требований улучшает оценку трудозатрат при разработке программного обеспечения, основываясь только на функциональном определении размеров.
- Эта улучшенная оценка трудозатрат также должна привести к более точным оценкам планирования, распределения ресурсов и рисков.
- Включение показателя нефункционального размера улучшает оценку трудозатрат на поддержку программного обеспечения после его развертывания.
- Уровень продуктивности проектных команд может быть лучше определен, потому что больше факторов включается в их измеренный результат работы.
- Включение как функциональных, так и нефункциональных рабочих продуктов лучше демонстрирует ценность, предоставляемую пользователю.
Кроме того, некоторые усилия по разработке программного обеспечения могут быть измерены как отсутствие функциональных точек. Например, спринт обслуживания программного обеспечения Agile может потребоваться только для изменения длины полей данных в таблицах данных. Было бы измерено, что у него есть нулевые точки функции, потому что это нефункционально; тем не менее, эта работа будет подотчетна в SNAP. SNAP, по крайней мере, частично решает проблему «нулевой функциональной точки».
Направления будущих исследований
Бета-тестирование SNAP в 2012 году проводилось с использованием 48 приложений. Будем надеяться, что дополнительные исследования улучшат калибровку весовых коэффициентов подкатегорий, чтобы получить еще более сильную статистическую корреляцию. Рекомендуется представить результаты будущих исследований в Комитет по нефункциональным калибровочным стандартам IFPUG (NFSSC) для проверки.
Смотрите также
Библиография
Буглионе, Луиджи, и Сантильо, Лука, «NFR: L» Altra Meta Della Mela », Ньюлсеттер, Итальянская ассоциация показателей программного обеспечения Gruppo Utenti Function Point Italia, www.gufpi-isma.org, декабрь 2011 г.
Международная группа пользователей функциональных точек, «Как функциональные точки и SNAP работают вместе», MetricViews, www.ifpug.org, Princeton Junction, NJ, 08550, США, август 2015 г.
Джонс, Каперс, «Руководство по выбору программных показателей и показателей», CRC Press, Бока Ротан, Флорида, 33487, США, 2017.
Джонс, Каперс, «Количественная оценка глобальных и отраслевых перспектив программного обеспечения», CRC Press, Бока Ротан, Флорида, 33487, США, 2018.
Рекомендации
- ^ IFPUG, «Руководство по методам подсчета функциональных точек» v. 4.3, Princeton Junction, NJ, 08550 USA 2009.
- ^ Международная организация по стандартизации, ISO / IEC 20926: 2009, https://www.iso.org/standard/51717.html , Женева, Швейцария, 2009.
- ^ IFPUG, «Руководство по практике оценки нефункционального процесса оценки программного обеспечения» v. 2.4, Princeton Junction, NJ, 08550 USA 2017.
- ^ IEEE 2430-2019, «Проект стандарта для нефункциональных измерений размеров программного обеспечения». Штаб-квартира IEEE, 3 Park Avenue, 17th Floor, New York, NY 10016-5997 USA, 2019.
- ^ ISO / IEC 25010: 2011, Системная и программная инженерия - Требования и оценка качества систем и программного обеспечения (SQuaRE) - Модели качества систем и программного обеспечения.
- ^ CrossTalk Журнал инженерии оборонного программного обеспечения, «Новая метрика программного обеспечения для дополнения функциональных точек процесса нефункциональной оценки программного обеспечения», Ogden ALC / TISE, База ВВС США Хилл, Юта, июль-август 2013 г.
- ^ COSMIC, IFPUG, «Глоссарий терминов для нефункциональных требований и требований проекта, используемых при измерении, сравнительном анализе и оценке производительности программных проектов», версия 1.0, сентябрь 2015 г.