Баллы SNAP
 | Судя по всему, основной автор этой статьи тесно связан с ее предметом. ( декабрь 2017 г. ) |
SNAP — это аббревиатура от «Процесс нефункциональной оценки программного обеспечения». Это измерение размера программного обеспечения, полученное путем количественного определения нефункциональных требований пользователей к этому программному обеспечению. Метод определения размера SNAP дополняет стандарт ISO/IEC 20926:2009, который определяет метод определения функциональных требований пользователей программного обеспечения. SNAP — это продукт Международной группы пользователей функциональных точек ( IFPUG ), размер которого определяется с использованием «Руководства по практике оценки процесса нефункциональной оценки программного обеспечения (SNAP)» (APM), которое теперь доступно в версии 2.4. Ссылка «IEEE 2430-2019-IEEE Standard Trial-Use для нефункциональных измерений размеров», опубликованная 19 октября 2019 г. ( [1] ). Также обратитесь к стандарту ISO «Разработка программного обеспечения — стандарт пробного использования для измерения нефункциональных размеров программного обеспечения» ( https://www.iso.org/standard/81913.html ), опубликованному в октябре 2021 года. Для получения дополнительной информации о SNAP посетите YouTube. и найдите «IFPUG SNAP»; это предоставит серию видеороликов с обзором методологии SNAP.
Введение
[ редактировать ]Программное приложение может предоставить своим пользователям два аспекта ценности. В этом контексте первый аспект — это «что» будет делать программное обеспечение, а именно: «Подмножество требований пользователя. Требования, которые описывают, что должно делать программное обеспечение с точки зрения задач и услуг». (Определение ISO/IEC 14143-1) Это можно определить как «функциональность». Одной метрикой, используемой для измерения размера одной единицы этой функциональности, является «функциональная точка». Используя метрику функционального определения размера (FSM) стандарта ISO, такую как в IFPUG «Руководство по практике подсчета функциональных точек», [1] (ФСМ ИСО/МЭК 20926:2009), [2] Специалист по подсчету функциональных точек может изучить часть функциональных требований пользователя программного приложения и измерить ее функциональный размер в единицах функциональных точек.
Более подробную информацию о метрике функциональной точки и метриках функционального определения размера программного обеспечения других организаций см. в библиографии, статье Википедии « функциональная точка » и многочисленных ссылках в литературе.
Требование пользователя программного обеспечения также может указывать, «как» программное обеспечение будет это делать, а именно: «Требование к программному обеспечению, которое описывает не то, что программное обеспечение будет делать, а то, как оно будет это делать». (Определение ISO/IEC/IEEE 24765:2010) Эти типы программного обеспечения определяются IFPUG как «нефункциональные». Их размер измеряется SNAP. IFPUG APM [3] подробно описывает, как оценить нефункциональные аспекты пользовательских требований к программным приложениям. Нефункциональные аспекты определены и классифицированы в ISO/IEC 25010:2011 «Инженерия систем и программного обеспечения. Требования и оценка качества систем и программного обеспечения (SQuaRE). Модели качества систем и программного обеспечения». [4]
Функциональный размер требований пользователя программного обеспечения вместе с нефункциональным размером требований пользователя программного обеспечения следует использовать для измерения размера требований пользователя к проектам программного обеспечения. Эти два размера следует использовать для измерения производительности программного проекта, установления контрольных показателей и оценки стоимости и продолжительности программных проектов.
Метод определения нефункциональных пользовательских требований
[ редактировать ]Подобно определению размера функциональной точки, одной единицей нефункциональности является «точка SNAP». Размер программного обеспечения, полученный путем количественного определения нефункциональных требований пользователей к программной части приложения, можно измерить с помощью процедуры, описанной в APM. Подобно функциональным баллам, используя IFPUG APM, специалист по подсчету баллов SNAP может изучить программное приложение и измерить размер его нефункциональной части требований пользователя в единицах баллов SNAP. Также, как и в случае с функциональными точками, количество точек SNAP в приложении коррелирует с трудозатратами на разработку нефункциональной части требований пользователя к программному обеспечению этого приложения. Оригинальное исследование, подробно описывающее эту корреляцию, опубликовано в CrossTalk The Journal of Defense Software Engineering в статье «Новая метрика программного обеспечения, дополняющая функциональные точки процесса нефункциональной оценки программного обеспечения (SNAP)». [5]
Для разработки каждой части требований пользователя программного обеспечения (функциональной и нефункциональной) программного проекта требуются трудозатраты, пропорциональные их размерам. Организации, занимающиеся разработкой программного обеспечения, могут использовать корреляции между функциональными точками и своими рабочими усилиями, а также между точками SNAP и своими рабочими усилиями, чтобы прогнозировать затраты и графики разработки программного обеспечения, а также проводить аудит проектов, чтобы определить, насколько хорошо было потрачено финансирование и были ли соблюдены графики.
SNAP признает четыре категории и 14 подкатегорий нефункциональных требований пользователей. Они приведены в таблице ниже из APM.
- 1. Операции с данными
1.1. Data Entry Validations 1.2. Logical and Mathematical Operations 1.3. Data Formatting 1.4. Internal Data Movements 1.5. Delivering Added Value to Users by Data Configuration
- 2. Дизайн интерфейса
2.1. User Interfaces 2.2. Help Methods 2.3. Multiple Input Methods 2.4. Multiple Output Formats
- 3. Техническая среда
3.1. Multiple Platform 3.2. Database Technology 3.3. Batch Processes
- 4. Архитектура
4.1. Component Based Software 4.2. Multiple Input / Output interfaces
Например, разработка программного обеспечения для изменения размеров полей данных в таблице данных не представляет собой изменений в функциональности согласно методам IFPUG. Однако это развитие требует трудовых усилий. Форматирование данных считается нефункциональным и учитывается в подкатегории SNAP 1.3.
Справочные методы (подкатегория 2.2) обычно считаются нефункциональными. По сравнению с процессом функциональной точки, который требует, чтобы данные пересекали границы приложения и сохраняли внутренний логический файл, данные справки могут быть закодированы так, чтобы они находились внутри в рамках разработки приложения и были доступны по команде пользователя. Этот доступ может быть любым: от всплывающей подсказки над значком на экране до доступа к части внутреннего руководства по эксплуатации приложения. Данные сами по себе не обрабатываются, поэтому справка обычно считается нефункциональной.
Функциональные точки и точки SNAP измеряют два разных аспекта определения размера программного обеспечения и поэтому не суммируются. Например, заявка на 500 функциональных баллов и 300 баллов SNAP не может считаться размером 800 какого-либо показателя; функциональные точки и точки SNAP должны быть ортогональными. Хорошим справочником для получения дополнительной подробной информации о взаимосвязи между функциональностью и нефункциональностью является документ «Глоссарий терминов для нефункциональных требований и требований проекта, используемых при измерении, сравнительном анализе и оценке производительности программного проекта». [6]
Преимущества
[ редактировать ]SNAP предоставляет пользователям и группам разработчиков программного обеспечения множество преимуществ в дополнение к единоличному использованию функциональных точек. Ниже приведены шесть из многих примеров.
- Измерение размера программного обеспечения, полученное путем количественного определения нефункциональных требований пользователей к программному обеспечению, улучшает оценку трудозатрат на разработку программного обеспечения на основе только определения функциональных требований пользователя.
- Измеряет размер алгоритмов, используя подкатегорию 1.2.
- Эта улучшенная оценка трудозатрат также должна привести к более точным оценкам планирования, распределения ресурсов и рисков.
- Включение размера SNAP улучшает оценку трудозатрат на поддержку программного обеспечения после его развертывания.
- Уровень производительности проектных команд может быть лучше определен, поскольку в измеряемую производительность их работы включено больше факторов.
- Включение как функциональных, так и нефункциональных рабочих продуктов лучше демонстрирует ценность, предоставляемую пользователю.
Кроме того, некоторые усилия по разработке программного обеспечения могут быть оценены как имеющие нулевые функциональные точки. Например, спринт по сопровождению программного обеспечения Agile может потребоваться только для изменения длины полей данных в таблицах данных. Было бы измерено, что он имеет ноль функциональных точек, поскольку он нефункционален; однако эта работа будет подотчетна SNAP. SNAP, по крайней мере, частично решает проблему «0 функциональной точки».
Области будущих исследований
[ редактировать ]Бета-тестирование SNAP в 2012 году проводилось с использованием 48 приложений. Надеемся, что дополнительные исследования позволят улучшить калибровку весовых коэффициентов подкатегорий и получить еще более сильную статистическую корреляцию. Рекомендуется, чтобы результаты будущих исследований были представлены на рассмотрение Комитету по стандартам нефункциональных размеров (NFSSC) IFPUG.
См. также
[ редактировать ]Библиография
[ редактировать ]Бульоне, Луиджи, и Сантильо, Лука, «NFR: Другая мета Apple», Ньюлсеттер, Итальянская ассоциация показателей программного обеспечения группы пользователей 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, «Руководство по практике подсчета функциональных точек», версия 4.3, Принстон-Джанкшен, Нью-Джерси, 08550 США, 2009.
- ^ «ИСО/МЭК 20926:2009» . ИСО . Проверено 27 марта 2024 г.
- ^ IFPUG, «Руководство по практике оценки процесса нефункциональной оценки программного обеспечения», версия 2.4, Принстон-Джанкшен, Нью-Джерси, 08550 США, 2017.
- ^ ISO/IEC 25010:2011, Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Модели качества систем и программного обеспечения.
- ^ CrossTalk, Журнал оборонной разработки программного обеспечения, «Новая метрика программного обеспечения, дополняющая функциональные точки процесса нефункциональной оценки программного обеспечения», Огден ALC / TISE, База ВВС Хилл, Юта, июль-август 2013 г.
- ^ COSMIC, IFPUG, «Глоссарий терминов для нефункциональных требований и требований проекта, используемых при измерении, сравнительном анализе и оценке производительности программного проекта», версия 1.0, сентябрь 2015 г.