Измерение усилия / метрики для кода конфигурации программного обеспечения

Question

Я думал о метриках программного обеспечения, которые будут использоваться при анализе усилий по разработке части программного обеспечения.Когда я думал об использовании функциональных точек, подобных метрикам, для объектно-ориентированного программного обеспечения, я столкнулся с интересным вопросом / вопросом.

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

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

Кто-нибудь имеет представление о такой функциональной точке, как метрика (или любая другая метрика), которая может измерять код конфигурации?

Answer 1

Вызов кода BR «код конфигурации» не меняет проблему.(Что вы называете собакой с 3 ногами? Неважно, как вы это называете, это собака с 3 ногами.)(обычно со сложным интерфейсом к «некоммерческой части правил» системы, которую БР не может сделать).С этой точки зрения программирование BR не сильно отличается от других языков, особенно если вы покупаете модель с функциональными точками (только потому, что у вас есть механизм BR, вы не будете писать код для генерации отчетов!).

То, что ребята из BR обычно пытаются сделать, - это заявить, что программирование в BR - это дешево, потому что вы можете делать это на ходу.Чего они не говорят, так это того, что программировать BR сложно, потому что сам факт незавершенного кодирования правил BR означает, что вы сначала избегаете анализа требований на том основании, что «вы можете просто кодировать BR позже».И нет никакой гарантии, что ваша система BR или данные, к которым она имеет доступ, действительно готовы к той проблеме, с которой вы столкнулись.(Идея, которую я действительно ненавижу, заключается в том, что «BR позволяет менеджерам понять ...» Вы видели настоящие правила BR?)

Answer 2

Определенно имеет смысл измерить усилия по созданию «кода конфигурации». В зависимости от вашего приложения, код конфигурации может быть даже большей частью усилий.

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

Answer 3

Я полностью согласен с Ира и KC, поэтому мы используем только стандартные языки сценариев для правил в приложении. Вы можете использовать V8 или seamonkey для встраивания интерпретатора JavaScript в ваше программное обеспечение, а затем использовать любой оценщик, который понимает JS (например, ProjectCodeMeter) в коде ваших бизнес-правил.