Из Википедии, свободной энциклопедии
  (Перенаправлено из функциональных точек )
Перейти к навигации Перейти к поиску

Точка функции является «единицей измерения» , чтобы выразить количество функциональных возможностей бизнеса - информационная система (как продукт) обеспечивает пользователь. Функциональные точки используются для вычисления измерения функционального размера (FSM) программного обеспечения. Стоимость (в долларах или часах) одной единицы рассчитывается на основе прошлых проектов. [1]

Стандарты [ править ]

Существует несколько признанных стандартов и / или общедоступных спецификаций для определения размеров программного обеспечения на основе Function Point.

1. Стандарты ISO

  • 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] Спецификация OMG Automated Function Point (AFP), разработанная Консорциумом качества программного обеспечения ИТ , обеспечивает стандарт для автоматизации функции Подсчет точек в соответствии с рекомендациями Международной группы пользователей функциональных точек ( IFPUG ). Однако текущие реализации этого стандарта имеют ограничение в возможности отличать внешний выход (EO) от внешних запросов (EQ) из коробки, без каких-либо предварительная конфигурация. [3]

Введение [ править ]

Функциональные точки были определены в 1979 году в книге «Измерение производительности разработки приложений » Аллана Альбрехта из IBM . [4] В требования функционального пользовательскомпрограммного обеспечения идентифицируются, и каждый из них подразделяется на один из пяти типов: выходы, запросы, входы, внутренние файлы и внешние интерфейсы. После того, как функция идентифицирована и отнесена к типу, она оценивается на предмет сложности и присваивается ряд функциональных баллов. Каждое из этих функциональных требований пользователя сопоставляется с бизнес-функцией конечного пользователя, такой как ввод данных для ввода или пользовательский запрос для запроса. Это различие важно, потому что оно позволяет легко преобразовать функции, измеренные в функциональных точках, в ориентированные на пользователя требования, но также имеет тенденцию скрывать внутренние функции (например, алгоритмы), которые также требуют ресурсов для реализации.

В настоящее время не существует признанного ISO метода конечного автомата, который включает алгоритмическую сложность в результат определения размера. Недавно были предложены различные подходы к устранению этой предполагаемой слабости, реализованные в нескольких коммерческих программных продуктах. Варианты метода IFPUG на основе Альбрехта, разработанные для компенсации этого (и других недостатков), включают:

  • Ранние и простые функциональные точки - корректируются с учетом проблемы и сложности данных с помощью двух вопросов, которые дают несколько субъективное измерение сложности; упрощает измерения, устраняя необходимость подсчета элементов данных.
  • Баллы инженерных функций - подсчитываются элементы (имена переменных) и операторы (например, арифметика, равенство / неравенство, логические значения). Этот вариант подчеркивает вычислительную функцию. [5] Назначение аналогично измерению сложности Холстеда на основе операторов / операндов .
  • Показатель взрыва - определяет показатель функции, основанный на двенадцати примитивных (простых) подсчетах, которые влияют на или показывают показатель взрыва, определяемый как «мера истинной функции, которая должна быть доставлена, как она воспринимается пользователем». Мера Банга может быть полезна при оценке ценности программного модуля с точки зрения того, сколько полезных функций оно обеспечивает, хотя в литературе мало свидетельств такого применения. Использование меры Bang может применяться при рассмотрении реинжиниринга (полного или частичного), как обсуждается в разделе «Обслуживание операционных систем - Обзор».
  • Особенности - добавляет изменения для улучшения применимости к системам со значительной внутренней обработкой (например, операционным системам, системам связи). Это позволяет учитывать функции, которые не всегда понятны пользователю, но необходимы для правильной работы.
  • Взвешенные микро-функциональные точки - одна из новых моделей (2009 г.), которая регулирует функциональные точки с использованием весов, полученных на основе сложности программы, словаря операндов и операторов, использования объектов и алгоритмов.
  • Нечеткие функциональные точки - Предлагает нечеткий и постепенный переход между низкой x средней и средней x высокой сложностью [6]

Контраст [ править ]

Использование функциональных точек вместо строк кода позволяет решить несколько дополнительных проблем:

  • Риск «раздувания» созданных строк кода и, таким образом, снижения ценности системы измерения, если разработчики будут заинтересованы работать более продуктивно. Сторонники FP называют это измерением размера решения, а не размера проблемы.
  • Строки кода ( LOC ) позволяют оценивать языки низкого уровня, потому что требуется больше строк кода, чтобы предоставить аналогичный объем функциональности языку более высокого уровня. [7] К. Джонс предлагает способ исправить это в своей работе. [8]
  • Меры LOC бесполезны на ранних этапах проекта, когда оценка количества строк кода, которые будут доставлены, является сложной задачей. Однако функциональные точки могут быть получены из требований и поэтому полезны в таких методах, как оценка по доверенности.

Критика [ править ]

В своем исследовании Альбрехт заметил, что функциональные точки сильно коррелировали со строками кода [9], что привело к сомнению в ценности такой меры, если доступна более объективная мера, а именно подсчет строк кода. Кроме того, было предпринято несколько попыток устранить предполагаемые недостатки этой меры путем улучшения режима подсчета. [10] [11] [12] [13] [14] [15] Другие предложили решения для обхода проблем путем разработки альтернативных методов, которые создают прокси для объема предоставляемых функций. [16]

См. Также [ править ]

Ссылки [ править ]

  1. ^ Томас Каттинг, Оценка уроков, извлеченных в управлении проектами - традиционный , последнее обращение 28 мая 2010 г.
  2. ^ ISO / IEC JTC 1 / SC 7 Программное обеспечение и системная инженерия (2007-02-01). «ИСО / МЭК 14143» . Международная организация по стандартизации . Проверено 26 февраля 2019 .
  3. ^ Спецификация OMG / CISQ «Автоматизированные функциональные точки», февраль 2013 г., номер документа OMG ptc / 2013-02-01 http://www.omg.org/spec/AFP/1.0
  4. ↑ AJ Albrecht, «Измерение производительности разработки приложений», Труды совместного симпозиума SHARE, GUIDE и IBM Application Development Symposium, Монтерей, Калифорния, 14–17 октября, IBM Corporation (1979), стр. 83–92.
  5. ^ Технические функциональные точки и система отслеживания, Центр поддержки программных технологий. Архивировано 11 ноября 2010 г.на Wayback Machine , получено 14 мая 2008 г.
  6. ^ Лима, Осиас де Соуза; Фариас, Педро Порфирио Мунис; Бельчиор, Арнальдо Диас (01.06.2003). «Нечеткое моделирование для анализа функциональных точек». Журнал качества программного обеспечения . 11 (2): 149–166. DOI : 10,1023 / A: 1023716628585 . ISSN 1573-1367 . S2CID 19655881 .  
  7. ^ Джонс, С. и О. Bonsignour Экономика программного обеспечения качества, Addison-Wesley, 2012. стр. 105-109.
  8. ^ Джонс, К. Измерение прикладного программного обеспечения: обеспечение производительности и качества. Макгроу-Хилл. Июнь 1996 г.
  9. ^ Альбрехт, А. Функции программного обеспечения, исходные строки кода и оценка усилий при разработке - проверка науки о программном обеспечении. 1983 г.
  10. ^ Саймонс, CR "Анализ функциональных точек: трудности и улучшения". IEEE Transactions по разработке программного обеспечения. Январь 1988. С. 2-111.
  11. ^ Хеммстра, Ф. и Кустерс Р. "Анализ функциональных точек: оценка модели оценки стоимости программного обеспечения". Европейский журнал информационных систем. 1991. Том 1, № 4. С. 229–237.
  12. ^ Джеффри, Р. и Статис, Дж. «Определение размеров программного обеспечения на основе спецификации: эмпирическое исследование функциональных показателей». Труды восемнадцатого ежегодного семинара по разработке программного обеспечения. 1993. С. 97-115.
  13. ^ Саймонс, С. Определение размеров и оценка программного обеспечения: Mk II FPA (анализ функциональных точек). John Wiley & Sons, Inc., Нью-Йорк, 1991 г.
  14. ^ Демарко, Т. "Алгоритм определения размеров программных продуктов". Обзор оценки производительности ACM Sigmetrics. 1984. Том 12, Выпуск 2. С. 13–22.
  15. ^ Джеффри, Д. Р., Лоу, Г. К. и Барнс, М. «Сравнение методов подсчета функциональных точек». IEEE Transactions по разработке программного обеспечения. 1993. Том 19, Выпуск 5. С. 529-532.
  16. ^ Шварц, Адам. «Использование тестовых примеров для определения размера систем: тематическое исследование». 2012 Девятая международная конференция по информационным технологиям - новые поколения. Апрель 2012. С. 242–246.

Внешние ссылки [ править ]

  • Международная группа пользователей функциональных точек (IFPUG)