Единица измерения
Функциональная точка — это «единица измерения», выражающая объем бизнес-функциональности, которую информационная система (как продукт) предоставляет пользователю. Функциональные точки используются для вычисления функционального размера измерения (FSM) программного обеспечения. Стоимость (в долларах или часах) одной единицы рассчитывается на основе прошлых проектов. [1]
Стандарты
Существует несколько признанных стандартов и/или общедоступных спецификаций для оценки программного обеспечения на основе Function Point.
1. Стандарты ИСО
- FiSMA: ISO/IEC 29881:2010 Информационные технологии – Системная и программная инженерия – Метод измерения функционального размера FiSMA 1.1.
- IFPUG : ISO/IEC 20926:2009 Программное обеспечение и системная инженерия. Измерение программного обеспечения. Метод измерения функционального размера IFPUG.
- Mark-II: ISO/IEC 20968:2002 Программная инженерия – Анализ функциональных точек Ml II – Руководство по практике подсчета
- Nesma: ISO/IEC 24570:2018 Программная инженерия – Метод измерения функциональных размеров Nesma версии 2.3 – Определения и рекомендации по подсчету для применения анализа функциональных точек
- COSMIC : ISO/IEC 19761:2011 Программная инженерия. Метод измерения функционального размера.
- OMG : ISO/IEC 19515:2019 Информационные технологии — Автоматизированные функциональные точки (AFP) группы управления объектами, 1.0
Первые пять стандартов являются реализациями всеобъемлющего стандарта для измерения функциональных размеров ISO/IEC 14143. [2] Спецификация автоматизированных функциональных точек (AFP) OMG, возглавляемая Консорциумом по качеству ИТ-ПО , предоставляет стандарт для автоматизации подсчета функциональных точек в соответствии с рекомендациями Международной группы пользователей функциональных точек ( IFPUG ). Однако текущие реализации этого стандарта имеют ограничение в возможности отличать внешний вывод (EO) от внешних запросов (EQ) из коробки, без некоторой предварительной настройки. [3]
Введение
Функциональные точки были определены в 1979 году в работе «Измерение производительности разработки приложений» Алланом Дж. Альбрехтом из IBM . [4] Функциональные требования пользователя к программному обеспечению идентифицируются, и каждое из них классифицируется по одному из пяти типов: выходные данные, запросы, входные данные, внутренние файлы и внешние интерфейсы. После того, как функция идентифицирована и классифицирована по типу, она оценивается на предмет сложности и ей назначается ряд функциональных точек. Каждая из этих функциональных пользовательских точек сопоставляется с бизнес-функцией конечного пользователя, такой как ввод данных для Входных данных или запрос пользователя для Запроса. Это различие важно, поскольку оно позволяет легко сопоставлять функции, измеряемые в функциональных точках, с требованиями, ориентированными на пользователя, но также скрывает внутренние функции (например, алгоритмы), которые также требуют ресурсов для реализации.
В настоящее время не существует признанного ISO метода FSM, который включает алгоритмическую сложность в результат определения размера. Недавно были предложены различные подходы для устранения этой предполагаемой слабости, реализованные в нескольких коммерческих программных продуктах. Вариации метода IFPUG на основе Альбрехта, разработанные для устранения этой (и других слабостей) слабости, включают:
- Ранние и простые функциональные точки — настраиваются на сложность проблемы и данных с помощью двух вопросов, которые дают несколько субъективное измерение сложности; упрощают измерение, устраняя необходимость подсчета элементов данных.
- Точки инженерной функции – подсчитываются элементы (имена переменных) и операторы (например, арифметика, равенство/неравенство, булевы). Этот вариант подчеркивает вычислительную функцию. [5] Цель аналогична цели мер сложности Холстеда на основе оператора/операнда .
- Мера взрыва – определяет функциональную метрику на основе двенадцати примитивных (простых) счетчиков, которые влияют или показывают Бэнг, определяемый как «мера истинной функции, которая должна быть предоставлена, как воспринимается пользователем». Мера взрыва может быть полезна при оценке ценности программного модуля с точки зрения того, сколько полезной функции он предоставляет, хотя в литературе мало свидетельств такого применения. Использование меры взрыва может применяться при рассмотрении реинжиниринга (как полного, так и кусочного), как обсуждается в Maintenance of Operational Systems—An Overview.
- Особые моменты – Добавляет изменения для улучшения применимости к системам со значительной внутренней обработкой (например, операционные системы, системы связи). Это позволяет учитывать функции, которые не сразу воспринимаются пользователем, но необходимы для правильной работы.
- Взвешенные микрофункциональные точки – одна из новейших моделей (2009 г.), которая корректирует функциональные точки с использованием весов, полученных на основе сложности потока программы, словаря операндов и операторов, использования объектов и алгоритма.
- Нечеткие функциональные точки — предлагают нечеткий и постепенный переход между низкой x средней и средней x высокой сложностью [6]
Контраст
Использование функциональных точек вместо строк кода направлено на решение нескольких дополнительных проблем:
- Риск «раздувания» созданных строк кода и, таким образом, снижения ценности системы измерения, если разработчиков стимулируют быть более производительными. Сторонники ФП называют это измерением размера решения вместо размера проблемы.
- Меры измерения строк кода ( LOC ) вознаграждают языки низкого уровня, поскольку для предоставления аналогичного объема функциональности языку более высокого уровня требуется больше строк кода. [7] К. Джонс предлагает метод исправления этого в своей работе. [8]
- Меры LOC бесполезны на ранних этапах проекта, когда оценка количества строк кода, которые будут поставлены, является сложной задачей. Однако функциональные баллы могут быть получены из требований и, следовательно, полезны в таких методах, как оценка по доверенности.
Критика
Альбрехт заметил в своем исследовании, что функциональные баллы были сильно коррелированы со строками кода, [9] что привело к сомнению ценности такой меры, если доступна более объективная мера, а именно подсчет строк кода. Кроме того, было предпринято несколько попыток устранить предполагаемые недостатки с помощью меры путем расширения режима подсчета. [10] [11] [12] [13] [14] [15] Другие предложили решения для обхода проблем путем разработки альтернативных методов, которые создают прокси для объема предоставленной функциональности. [16]
Смотрите также
Ссылки
- ^ Томас Каттинг, Оценка уроков, извлеченных из управления проектами – традиционное, получено 28 мая 2010 г.
- ^ ISO/IEC JTC 1/SC 7 Программное обеспечение и системная инженерия (2007-02-01). "ISO/IEC 14143". Международная организация по стандартизации . Получено 2019-02-26 .
{{cite web}}
: CS1 maint: числовые имена: список авторов ( ссылка ) - ^ Спецификация OMG/CISQ «Автоматизированные функциональные точки», февраль 2013 г., номер документа OMG ptc/2013-02-01 http://www.omg.org/spec/AFP/1.0
- ^ А. Дж. Альбрехт, «Измерение производительности разработки приложений», Труды совместного симпозиума SHARE, GUIDE и IBM по разработке приложений, Монтерей, Калифорния, 14–17 октября, IBM Corporation (1979), стр. 83–92.
- ^ Инженерные функциональные точки и система отслеживания, Центр поддержки программных технологий. Архивировано 11 ноября 2010 г. на Wayback Machine . Получено 14 мая 2008 г.
- ^ Лима, Осиас де Соуза; Фариас, Педро Порфирио Мунис; Бельчиор, Арнальдо Диас (1 июня 2003 г.). «Нечеткое моделирование для анализа функциональных точек». Журнал качества программного обеспечения . 11 (2): 149–166. дои : 10.1023/А: 1023716628585. ISSN 1573-1367. S2CID 19655881.
- ^ Джонс, К. и Бонсиньор О. Экономика качества программного обеспечения, Addison-Wesley, 2012. С. 105-109.
- ^ Джонс, К. Прикладное программное обеспечение: измерение производительности и качества. McGraw-Hill. Июнь 1996 г.
- ^ Альбрехт, А. Функция программного обеспечения, исходные строки кода и оценка усилий по разработке – проверка науки о программном обеспечении. 1983.
- ^ Саймонс, CR «Анализ функциональных точек: трудности и улучшения». Труды IEEE по программной инженерии. Январь 1988 г. С. 2-111.
- ^ Хеммстра, Ф. и Кустерс Р. «Анализ функциональных точек: оценка модели оценки стоимости программного обеспечения». Европейский журнал информационных систем. 1991. Том 1, № 4. С. 229-237.
- ^ Джеффери, Р. и Статис, Дж. «Определение размера программного обеспечения на основе спецификаций: эмпирическое исследование метрик функций». Труды Восемнадцатого ежегодного семинара по программной инженерии. 1993. С. 97-115.
- ^ Саймонс, К. Размер и оценка программного обеспечения: Mk II FPA (анализ функциональных точек). John Wiley & Sons, Inc. Нью-Йорк, 1991
- ^ Демарко, Т. «Алгоритм определения размера программных продуктов». Обзор оценки производительности ACM Sigmetrics. 1984. Том 12, выпуск 2. стр. 13–22.
- ^ Джеффри, DR, Лоу, GC и Барнс, M. «Сравнение методов подсчета точек функций». Труды IEEE по программной инженерии. 1993. Том 19, выпуск 5. стр. 529-532.
- ^ Шварц, Адам. «Использование тестовых случаев для определения размера систем: исследование случая». Девятая международная конференция по информационным технологиям 2012 г. — Новые поколения. Апрель 2012 г., стр. 242–246.
Внешние ссылки
- Международная группа пользователей функциональных точек (IFPUG)