# Что такое функциональная точка COSMIC и чем она отличается от оценки в часах?

Mesterséges Intelligencia Központ Kft., компания по разработке ПО из Будапешта, измеряет размер ПО в функциональных точках COSMIC: так размер становится свойством самого ПО, а не ощущением оценщика, поэтому его можно проверить, измерить повторно и с его помощью сравнить два предложения.

> **Коротко:** COSMIC (ISO/IEC 19761) измеряет функциональный размер ПО: каждое перемещение данных, будь то ввод (Entry), вывод (Exit), чтение (Read) или запись (Write), даёт 1 функциональную точку COSMIC (CFP). Оценка в часах говорит о том, сколько работы ожидает оценщик; измеренный размер показывает, насколько велика задача. Поэтому его можно проверить, измерить повторно и с его помощью сравнить два предложения, а трудозатраты выводятся из размера и производительности, измеренной на практике.

## Что такое измерение функционального размера?

Размер ПО можно выразить по-разному: в строках кода, в часах, в баллах. Измерение функционального размера (по-английски functional size measurement, FSM) определяет, что ПО должно уметь с точки зрения его пользователей, а не то, как это реализовано. Его базовые понятия закреплены в стандарте [ISO/IEC 14143-1:2007](https://www.iso.org/standard/38931.html); согласно описанию стандарта, цель как раз в том, чтобы измерение было сосредоточено не на способе реализации, а на функциях, которые требуются пользователю.

Основой измерения служит совокупность функциональных пользовательских требований (functional user requirements, FUR): та часть пользовательских требований, которая описывает, какие задачи и услуги должно выполнять ПО. Производительность, безопасность или выбранная технология сюда не относятся; о них мы пишем ниже, в разделе об ограничениях.

Существует несколько стандартизированных методов измерения функционального размера. Самые известные из них: COSMIC ([ISO/IEC 19761:2011](https://www.iso.org/standard/54849.html)) и метод IFPUG ([ISO/IEC 20926:2009](https://www.iso.org/standard/51717.html)); ISO стандартизировала и другие методы (NESMA, FiSMA, Mk II). Все они исходят из требований, но по разным правилам и в разных единицах, поэтому числа, полученные разными методами, напрямую сравнивать нельзя.

## Что такое COSMIC?

COSMIC расшифровывается как Common Software Measurement International Consortium: это некоммерческая организация, которая развивает метод и организует сертификацию специалистов по измерениям. Метод сложился в конце девяностых годов как развитие более ранних методов функциональных точек, в 2003 году стал стандартом ISO, а действующей редакцией является ISO/IEC 19761:2011. Подробное описание метода, руководство [COSMIC Measurement Manual](https://cosmic-sizing.org/measurement-manual/) версии 5.0, можно скачать бесплатно; его первая часть издана в 2021 году, вторая вышла в 2024 году.

Согласно стандарту, метод подходит для измерения прикладного ПО (например, бизнес-систем), ПО реального времени и их сочетаний, то есть с его помощью можно измерить и ERP-, CRM-систему или интернет-магазин, и управляющее ПО.

## Понятия модели COSMIC

COSMIC описывает ПО простой моделью: ПО обменивается данными со своими функциональными пользователями через свою границу, а внутри границы читает данные из постоянного хранилища и записывает их туда.

| Понятие | Что означает | Пример |
|---|---|---|
| Функциональный пользователь | тот или то, что отправляет данные в ПО или ожидает от него данные: человек, другое ПО или устройство | сотрудник, система выставления счетов |
| Граница | условный интерфейс между измеряемым ПО и его функциональными пользователями | веб-интерфейс и интерфейс, открытый для других систем |
| Инициирующее событие | событие, в ответ на которое функциональный пользователь запускает процесс | обращается новый клиент |
| Функциональный процесс | элементарная, самостоятельно выполнимая единица требований, связная последовательность перемещений данных | «регистрация нового клиента» |
| Группа данных | набор элементов данных, описывающих один объект, данные о котором должно обрабатывать ПО | Клиент: имя, адрес, налоговый номер, e-mail |
| Перемещение данных | перемещение одной группы данных; существует четыре вида | см. ниже |

Четыре вида перемещений данных:

- **Entry (ввод):** группа данных поступает от функционального пользователя через границу в процесс.
- **Exit (вывод):** группа данных уходит из процесса через границу к функциональному пользователю.
- **Read (чтение):** процесс читает группу данных из постоянного хранилища.
- **Write (запись):** процесс записывает группу данных в постоянное хранилище; удаление тоже считается записью.

Некоторые из правил измерения, которые определяют подсчёт:

- Каждое перемещение данных даёт 1 CFP. Размер функционального процесса равен сумме его перемещений данных, а размер ПО равен сумме размеров его процессов.
- Каждый функциональный процесс состоит как минимум из двух перемещений данных: инициирующего ввода и как минимум одного вывода или одной записи.
- В пределах одного процесса один вид перемещения одной и той же группы данных учитывается только один раз, сколько бы полей в ней ни было.
- Все сообщения об ошибках и подтверждения процесса вместе составляют один вывод.
- Размер зависит от видов, а не от количества повторений: регистрируют ли за день десять клиентов или десять тысяч, на размер это не влияет.
- Обработку данных (вычисления, проверки) метод отдельно не измеряет: она входит в соответствующее перемещение данных.

Результат выражается по шкале отношений, то есть размеры можно складывать и сравнивать: две части по 40 CFP вместе дают 80 CFP, а промежуточный итог можно показать и по каждой группе функций.

## Разобранный пример: «регистрация нового клиента»

Возьмём простое требование: «Сотрудник регистрирует данные нового клиента (имя, адрес, налоговый номер, e-mail). Система проверяет, не зарегистрирован ли уже этот клиент, сохраняет запись и сообщает об успехе или об ошибке». Шаги измерения:

1. **Функциональный пользователь:** сотрудник; **инициирующее событие:** обращение нового клиента.
2. **Группа данных:** Клиент; четыре элемента данных описывают один и тот же объект, поэтому образуют одну группу.
3. **Перемещения данных** мы определяем по предложениям требования и подсчитываем каждое из них.

| Шаг | Перемещение данных | Группа данных | Размер |
|---|---|---|---|
| Сотрудник отправляет форму | Entry (ввод) | Клиент | 1 CFP |
| Система проверяет, существует ли уже клиент | Read (чтение) | Клиент | 1 CFP |
| Система сохраняет нового клиента | Write (запись) | Клиент | 1 CFP |
| Сообщение об успехе или о любой ошибке | Exit (вывод) | сообщение об ошибке и подтверждение | 1 CFP |
| Итого | четыре перемещения данных | одна группа данных | 4 CFP |

Точно так же построен пример «регистрация нового сотрудника» (create employee) в руководстве, опубликованном на сайте COSMIC. Изменения требования отражаются в размере так:

- Если система должна передавать нового клиента ещё и в систему выставления счетов, это ещё один вывод, направленный другому функциональному пользователю: 5 CFP.
- Если почтовый индекс нужно проверять по таблице населённых пунктов, это ещё одно чтение, потому что оно касается другой группы данных: ещё 1 CFP.
- Если форма запрашивает о клиенте двенадцать полей вместо четырёх, размер не меняется, потому что группа данных та же.
- Если нужно изменить существующий процесс, размер изменения равен сумме добавленных, изменённых и удалённых перемещений данных.

Пример показывает и то, почему измерение можно проверить: за каждой CFP стоят названное требование, группа данных и правило. Если кто-то оспаривает результат, можно точно указать, о какой строке идёт речь.

## Измерять рано, уточнять позже

Измерение по COSMIC начинается с фиксации цели и границ измерения: что мы измеряем, что в него входит и для чего будет использован результат. Для точного измерения нужны настолько подробные требования, чтобы по ним можно было определить функциональные процессы и их перемещения данных. В начале проекта их часто ещё нет; для этого случая COSMIC публикует приближённые методы ранней оценки размера, а после проработки требований может последовать точное измерение.

Руководство по методу предупреждает и о том, что многие требования, которые поначалу кажутся нефункциональными (например, время отклика или удобство использования), в ходе проекта превращаются в функции ПО, и от этого размер кажется растущим. Это не ошибка измерения: это показывает, что требование стало точнее. Поэтому на практике стоит писать спецификацию поэлементно, повторно измерять изменения тем же методом и показывать размер каждого изменения отдельно. Тогда рост объёма работ происходит не незаметно, а виден в цифрах.

## Сравнение: часы, story points, IFPUG, COSMIC

| Критерий | Оценка в часах | Story points | Функциональные точки IFPUG | Функциональные точки COSMIC |
|---|---|---|---|---|
| Что выражает | работу, которую ожидает оценщик | относительную оценку команды; не всегда ясно, чего именно: размера, трудозатрат или времени | функциональный размер | функциональный размер |
| Стандартизирован ли | нет | нет | да, ISO/IEC 20926:2009 | да, ISO/IEC 19761:2011 |
| От чего зависит | от опыта, осторожности и команды оценщика | от конкретной команды; в каждой команде означает своё | от требований | от требований |
| Можно ли проверить со стороны | только по объяснениям оценщика | вне команды почти нельзя | да, по открытым правилам | да, по открытым и бесплатно доступным правилам |
| Единица измерения | час | собственный балл команды | функциональная точка IFPUG | CFP, 1 CFP = 1 перемещение данных |
| Для чего подходит лучше всего | для планирования коротких, хорошо знакомых задач | для собственного планирования спринтов команды | для измерения размера, сравнения | для измерения размера, сравнения, как основа предложения и графика работ |

Оценка в часах является неплохим инструментом, просто она измеряет другое: ожидаемую работу, которая зависит не только от размера задачи, но и от знаний, инструментов и осторожности команды. Story points полезны для планирования внутри команды, но, согласно руководству, опубликованному на сайте COSMIC, они субъективны, и их значение в каждой команде своё. IFPUG и COSMIC оба дают стандартный функциональный размер, но по разным правилам, поэтому числа двух методов не взаимозаменяемы.

## Почему измеренный размер служит более надёжной основой?

Если точно отвечать на вопрос из заголовка: COSMIC не оценивает часы точнее, а измеряет величину задачи, и благодаря этому оценка трудозатрат становится надёжнее. Причины:

- **Измеряется требование, а не реализация.** Функциональный размер следует только из требований, поэтому он не зависит ни от технологии, ни от процесса, ни от того, кто разрабатывает ПО.
- **Можно измерить повторно по открытым правилам.** Правила открыты, результат измерения необходимо документировать, поэтому другой специалист по измерениям может проверить его по той же спецификации.
- **Размер и производительность разделены.** Оценка трудозатрат получается из размера и производительности, измеренной на практике (трудозатраты = размер / производительность). Так видно, какой фактор меняется и почему.
- **Измерение улучшает требования.** Согласно руководству COSMIC, раннее измерение помогает выявить неоднозначные, противоречивые или отсутствующие требования.
- **Сопоставимость.** Два предложения по одной и той же спецификации получают одинаковый размер, поэтому цены относятся к одному и тому же объёму работ.

Руководство COSMIC ссылается на несколько исследований, в которых размер, измеренный в CFP, теснее соотносился с фактическими трудозатратами, чем оценка в story points. То же руководство предупреждает и о том, что оценка трудозатрат по размеру надёжна, если процесс разработки достаточно воспроизводим и трудозатраты определяются прежде всего размером. Таким образом, измеренный размер является лучшей отправной точкой, но для хорошей оценки нужно знать и производительность.

## Чего не измеряет COSMIC?

Размер по COSMIC измеряет функции, и описание метода прямо об этом говорит. Чего он не выражает:

- **Сложные алгоритмы.** Согласно стандарту, метод не предназначен для измерения ПО, которое характеризуется сложными математическими алгоритмами или особыми системами правил (например, экспертные системы, моделирование, самообучающееся ПО, прогноз погоды).
- **Обработка непрерывных сигналов.** Обработка звука и изображений, а также, например, такие части компьютерных игр тоже находятся вне области применения стандарта.
- **Собственно нефункциональные требования.** Технологические ограничения, ограничения производительности и ограничения проекта по методу нужно фиксировать, но в CFP мы их не измеряем.
- **Творческая работа.** Согласно руководству COSMIC, чисто творческие задачи, например создание художественных произведений, не являются предметом метода; поэтому работу над графикой и индивидуальным визуальным дизайном размер не выражает.
- **Внедрение готового пакета.** Если требования в основном покрываются настройкой готового продукта, трудозатраты лучше оценивать способом, характерным для этого пакета.

Поэтому в хорошем предложении наряду с измеренным размером отдельно показано то, чего размер не выражает: интеграции, нефункциональные требования, индивидуальный интерфейс и графика, несколько платформ, миграция данных, сложные вычисления и работа в реальном времени. В наших предложениях эти позиции указаны именно так, о чём мы пишем на странице [Ценообразование](https://www.mestersegesintelligenciakozpont.hu/ru/pricing).

## Как мы используем его в собственной работе?

Функциональный размер разработки мы измеряем в функциональных точках COSMIC. Для измерения мы построили собственный рабочий процесс с поддержкой искусственного интеллекта, а результат проверяет человек на этапе проверки. Шаги:

1. **Поэлементная спецификация:** мы разбиваем разработку на группы функций и описываем каждую по одному и тому же шаблону: цель, участники, данные, функции, функции ИИ и то, что в объём не входит (см. [Как мы работаем](https://www.mestersegesintelligenciakozpont.hu/ru/how-we-work)).
2. **Несколько независимых подсчётов:** каждую группу функций несколько языковых моделей подсчитывают по нескольку раз; разброс подсчётов показывает неопределённость.
3. **Этап сверки:** гарантирует, что каждый функциональный процесс учитывается ровно один раз, даже если он фигурирует в нескольких описаниях.
4. **Проверка:** мы просматриваем измерение, проясняем неясные места и при необходимости вручную корректируем автоматические объединения.
5. **Фиксация:** готовое измерение можно зафиксировать как неизменяемую версию, и она становится основой договора.

При доработке существующей системы мы описываем существующую часть отдельно, поэтому в размер входит только новая часть. Измерение отмечает и то, чего функциональный размер не выражает.

## Как из размера получаются предложение и график работ?

Цена предложения вытекает из измеренного размера с добавлением позиций, которые размер не выражает. Поскольку размер мы видим и по каждой группе функций, на нём мы строим и график работ: порядок этапов, содержание демонстраций и сроки. Если по ходу работы появляется новое требование, мы измеряем его так же, и видно, насколько меняется объём работ и что это означает для цены и графика. Поэтому конкретную цену и срок мы называем только после измерения, а не на основании первого разговора.

## Сравнение двух предложений по размеру

Если вы запрашиваете предложения у нескольких разработчиков, размер помогает понять, составлены ли они на одну и ту же задачу. Действовать стоит так:

1. **Одна и та же спецификация:** все, кто подаёт предложение, получают одно и то же поэлементное описание.
2. **Размер и перечень процессов:** спросите, на какой размер и на какие функциональные процессы рассчитана цена.
3. **Причины различий:** если два предложения различаются, проверьте, в чём именно: в размере, в позициях, которые размер не выражает, или в цене за единицу размера.
4. **Отдельные позиции:** спросите, что указано отдельной строкой (интеграция, миграция данных, эксплуатация) и что в цену не входит.
5. **Работа с изменениями:** спросите, как измеряются и оцениваются изменения, вносимые по ходу работы.

Если кто-то из подающих предложение не измеряет функциональный размер, его предложение всё равно можно сравнить, если цена рассчитана на тот же поэлементный перечень процессов. О других критериях выбора разработчика мы пишем в статье [Как выбрать компанию по разработке ПО?](https://www.mestersegesintelligenciakozpont.hu/ru/knowledge-base/how-to-choose-a-software-development-company); а нужна ли вообще заказная разработка, поможет решить статья [Заказное ПО или готовое решение?](https://www.mestersegesintelligenciakozpont.hu/ru/knowledge-base/custom-software-vs-off-the-shelf)

## Частые вопросы

### Что такое функциональная точка COSMIC?

Функциональная точка COSMIC (CFP) является единицей функционального размера ПО по стандарту ISO/IEC 19761. Одна CFP соответствует одному перемещению данных: ввод, вывод, чтение или запись группы данных в функциональном процессе. Размер ПО равен сумме перемещений данных его процессов.

### Чем она отличается от оценки в часах?

Оценка в часах выражает ожидаемую работу и зависит от оценщика и команды. COSMIC измеряет размер задачи по требованиям, по открытым правилам, поэтому другой специалист по той же спецификации может прийти к тому же результату. Часы затем можно вывести из размера и производительности, измеренной на практике.

### Чего не измеряет COSMIC?

Согласно стандарту, метод не предназначен для измерения обработки сложных математических алгоритмов и непрерывных сигналов (звука, изображений) и не выражает в CFP собственно нефункциональные требования, например ограничения производительности или технологические ограничения. В хорошем предложении они показаны отдельными позициями.

### Кто проводит измерение и можно ли его проверить?

Измерение выполняет специалист, знающий метод; у нас подсчёт ведёт рабочий процесс с поддержкой ИИ, а результат проверяет человек. Правила открыты, измерение задокументировано по каждому процессу, поэтому другой специалист, знающий метод, может проверить его по той же спецификации.

### Как из размера получается предложение?

Цена вытекает из измеренного размера с добавлением того, чего размер не выражает: интеграций, нефункциональных требований, индивидуальной графики, нескольких платформ, миграции данных. График работ строится на размере по каждой группе функций, а изменения мы измеряем так же. Подробности см. на странице [Ценообразование](https://www.mestersegesintelligenciakozpont.hu/ru/pricing).

## Как мы можем помочь?

Если вы планируете [заказное ПО](https://www.mestersegesintelligenciakozpont.hu/ru/services/custom-software-development), мы вместе пишем поэлементную спецификацию, измеряем её размер в функциональных точках COSMIC и на этой основе составляем предложение и график работ. По запросу мы заключаем соглашение о неразглашении (NDA), а после передачи также берём на себя эксплуатацию и сопровождение. Вопросы исходного кода и прав на использование регулируются договором. Первая консультация бесплатна: напишите нам по контактам, указанным на странице [Контакты](https://www.mestersegesintelligenciakozpont.hu/ru/contact).

## Источники

- [COSMIC: Measurement Manual v5.0, Part 1: Principles, Definitions and Rules (PDF)](https://cosmic-sizing.org/wp-content/uploads/2020/06/Part-1-MM-Principles-Definitions-Rules-v5.0-Aug-2021.pdf)
- [COSMIC: Measurement Manual v5.0, Part 2: Guidelines (PDF)](https://cosmic-sizing.org/wp-content/uploads/2024/09/Part-2-MM-Guidelines-v5.0-Sep-2024.pdf)
- [COSMIC: A Guide to Software Size Measurement (PDF)](https://cosmic-sizing.org/wp-content/uploads/2020/08/Measuring-software-size-v1.0-August-2020-1.pdf)
- [COSMIC Measurement Manual: страница загрузки](https://cosmic-sizing.org/measurement-manual/)
- [ISO: ISO/IEC 19761:2011, COSMIC: a functional size measurement method](https://www.iso.org/standard/54849.html)
- [ISO: ISO/IEC 14143-1:2007, Functional size measurement, Part 1: Definition of concepts](https://www.iso.org/standard/38931.html)
- [ISO: ISO/IEC 20926:2009, IFPUG functional size measurement method](https://www.iso.org/standard/51717.html)