Jump to content

Функциональная точка

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

Введение

[ редактировать ]

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

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

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

Контраст

[ редактировать ]

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

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

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

См. также

[ редактировать ]
  1. Томас Каттинг, Оценка уроков, извлеченных в управлении проектами – традиционное , дата обращения 28 мая 2010 г.
  2. ^ ISO/IEC JTC 1/SC 7 Программное обеспечение и системная инженерия (01 февраля 2007 г.). «ИСО/МЭК 14143» . Международная организация по стандартизации . Проверено 26 февраля 2019 г. {{cite web}}: CS1 maint: числовые имена: список авторов ( ссылка )
  3. ^ Спецификация OMG/CISQ «Точки автоматизированных функций», февраль 2013 г., номер документа OMG ptc/2013-02-01 http://www.omg.org/spec/AFP/1.0
  4. ^ А. Дж. Альбрехт, «Измерение продуктивности разработки приложений», Труды совместного симпозиума SHARE, GUIDE и IBM по разработке приложений, Монтерей, Калифорния, 14–17 октября, IBM Corporation (1979), стр. 83–92.
  5. Инженерные функциональные точки и система отслеживания, Центр поддержки программных технологий. Архивировано 11 ноября 2010 г. на Wayback Machine , проверено 14 мая 2008 г.
  6. ^ ЛИМА, Осиас-де-Соуза; ФАРИАС, Педро Порфирио Мунис; Бельчиор, Арнальдо Диас (1 июня 2003 г.). «Нечеткое моделирование для анализа функциональных точек». Журнал качества программного обеспечения . 11 (2): 149–166. дои : 10.1023/A:1023716628585 . ISSN   1573-1367 . S2CID   19655881 .
  7. ^ Джонс, К. и Бонсиньур О. Экономика качества программного обеспечения, Аддисон-Уэсли, 2012. стр. 105-109.
  8. ^ Джонс, К. Измерение прикладного программного обеспечения: обеспечение производительности и качества. МакГроу-Хилл. Июнь 1996 года.
  9. ^ Альбрехт, А. Функция программного обеспечения, исходные строки кода и оценка усилий по разработке - проверка науки о программном обеспечении. 1983.
  10. ^ Саймонс, CR «Анализ функциональных точек: трудности и улучшения». Транзакции IEEE по разработке программного обеспечения. Январь 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 по разработке программного обеспечения. 1993. Том 19, выпуск 5. стр. 529–532.
  16. ^ Шварц, Адам. «Использование тестовых примеров для определения размера систем: практический пример». 2012 Девятая международная конференция по информационным технологиям – Новые поколения. Апрель 2012 г., стр. 242–246.
[ редактировать ]
Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: 5f2a6c47ede106fca8e7aae3e9e584b0__1710344640
URL1:https://arc.ask3.ru/arc/aa/5f/b0/5f2a6c47ede106fca8e7aae3e9e584b0.html
Заголовок, (Title) документа по адресу, URL1:
Function point - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)