Измерение усилия / метрики для кода конфигурации программного обеспечения
Я думал о метриках программного обеспечения, которые можно использовать при анализе усилий по разработке части программного обеспечения. Когда я думал об использовании функциональных точек, таких как метрики, для объектно-ориентированного программного обеспечения, я столкнулся с интересным вопросом / вопросом.
Рассмотрим двигатель бизнес-правил. Это приложение, которое состоит из компонентов, необходимых для запуска бизнес-правил, а затем необходимо преобразовать бизнес-правила или политики компании в код конфигурации для механизма бизнес-правил. Я предполагаю, что для таких приложений, как механизм бизнес-правил, этот код конфигурации также может стать весьма существенным. Однако, рассматривая это с точки зрения реализации, код конфигурации по существу создает экземпляры частей API.
Итак, во-первых, я ошибаюсь, полагая, что усилия по написанию кода конфигурации достаточно существенны, чтобы их измерение имело смысл?
Кто-нибудь имеет представление о такой функциональной точке, как метрика (или любая другая метрика), которая может измерять код конфигурации?
3 ответа
Вызов кода "Конфигурация" кода BR не меняет проблему. (Что вы называете собакой с 3 ногами? Неважно, как вы это называете, это собака с 3 ногами).
Не обращая внимания на большую шумиху, движки бизнес-правил - это просто забавные языки программирования (обычно со сложным интерфейсом к "части, не связанной с бизнес-правилами" системы, что невозможно сделать с помощью BR). С этой точки зрения программирование BR не сильно отличается от других языков, особенно если вы покупаете модель с функциональными точками (только потому, что у вас есть механизм BR, вы не будете писать код для генерации отчетов!).
То, что ребята из BR обычно пытаются сделать, - это заявить, что программирование в BR - это дешево, потому что вы можете делать это по ходу дела. Чего они не говорят, так это того, что программировать BR сложно, потому что сам факт незавершенного кодирования правил BR означает, что вы сначала избегаете анализа требований на том основании, что "вы можете просто кодировать BR позже". И нет никакой гарантии, что ваша система BR или данные, к которым она имеет доступ, действительно готовы к той проблеме, с которой вы столкнулись. (Идея, которую я действительно ненавижу, заключается в том, что "BR позволяет менеджерам понять..." Вы видели настоящие правила BR?)
Определенно имеет смысл измерить усилия по созданию "кода конфигурации". В зависимости от вашего приложения, код конфигурации может быть даже большей частью усилий.
Я не знаю ни одной метрики, специально разработанной для кода конфигурации. Уже существует много языков конфигурации, и любой может создать новый. Вероятно, вы должны увидеть, насколько ваш язык конфигурации похож на популярные языки программирования, и адаптировать метрику, которая работает с этим языком программирования.
Я полностью согласен с Ира и KC, поэтому мы используем только стандартные языки сценариев для правил в приложении. Вы можете использовать V8 или seamonkey для встраивания интерпретатора JavaScript в ваше программное обеспечение, а затем использовать любой оценщик, который понимает JS (например, ProjectCodeMeter) в вашем коде бизнес-правил.