Анализ основных отчетов Яндекс.Метрики: предупреждён и вооружён. Создание, использование и анализ метрик

Поскольку количественные методы хорошо зарекомендовали себя в других областях, многие теоретики и практики информатики пытались перенести данный подход и в разработку программного обеспечения . Как сказал Том ДеМарко, «вы не можете контролировать то, что не можете измерить».

Метрики

Набор используемых метрик включает:

• порядок роста (имеется в виду анализ алгоритмов в терминах асимптотического анализа и O-нотации),
• анализ функциональных точек,
• количество ошибок на 1000 строк кода,
• степень покрытия кода тестированием,
• количество классов и интерфейсов ,
• метрики программного пакета от Роберта Сесиль Мартина,

Критика

Потенциальные недостатки подхода, на которые нацелена критика:

• Неэтичность: Утверждается, что неэтично судить о производительности программиста по метрикам, введенным для оценки эффективности программного кода. Такие известные метрики, как количество строк кода и цикломатическая сложность, часто дают поверхностное представление об "удачности" выбора того или иного подхода при решении поставленных задач, однако, нередко они рассматриваются, как инструмент оценки качества работы разработчика. Такой подход достаточно часто приводит к обратному эффекту, приводя к появлению в коде более длинных конструкций и избыточных необязательных методов.
• Замещение «управления людьми» на «управление цифрами», которое не учитывает опыт сотрудников и их другие качества
• Искажение: Процесс измерения может быть искажён за счёт того, что сотрудники знают об измеряемых показателях и стремятся оптимизировать эти показатели, а не свою работу. Например, если количество строк исходного кода является важным показателем, то программисты будут стремиться писать как можно больше строк и не будут использовать способы упрощения кода, сокращающие количество строк.
• Неточность: Нет метрик, которые были бы одновременно и значимы и достаточно точны. Количество строк кода - это просто количество строк, этот показатель не даёт представление о сложности решаемой проблемы. Анализ функциональных точек был разработан с целью лучшего измерения сложности кода и спецификации, но он использует личные оценки измеряющего, поэтому разные люди получат разные результаты.

См. также

• Основные метрики кода: LOC, SLOC, Джилб, Маккейб, Холстед, ООП и другие

Wikimedia Foundation . 2010 .

• Одометр
• Стетоскоп

Смотреть что такое "Метрика программного обеспечения" в других словарях:

Качество программного обеспечения

Оценка затрат на разработку программного обеспечения - При разработке программного обеспечения очень важной является проблема оценки материальных затрат и/или затрат времени на успешное завершение проекта. Существует множество методов для выполнения такой оценки, среди которых можно выделить общие… … Википедия

Метрика - имеет несколько значений: В математике Метрика функция, определяющая расстояния в метрическом пространстве. Метрика альтернативное название метрического тензора, в частности Метрика пространства времени 4 тензор, который… … Википедия

Покрытие кода - У этого термина существуют и другие значения, см. Покрытие. Покрытие кода мера, используемая при тестировании программного обеспечения. Она показывает процент, насколько исходный код программы был протестирован. Техника покрытия кода была… … Википедия

Количество строк кода - См. также: Объем кода Количество строк кода (англ. Source Lines of Code SLOC) это метрика программного обеспечения, используемая для измерения его объёма с помощью подсчёта количества строк в тексте исходного кода. Как правило,… … Википедия

Нагрузочное тестирование - (англ. Load Testing) определение или сбор показателей производительности и времени отклика программно технической системы или устройства в ответ на внешний запрос с целью установления соответствия требованиям, предъявляемым к данной системе … Википедия

Тестирование производительности - В этой статье не хватает ссылок на источники информации. Информация должна быть проверяема, иначе она может быть поставлена под сомнение и удалена. Вы можете … Википедия

Scrum - Разработка программного обеспечения Процесс разработки ПО Шаги процесса Анализ Проектирование Программирование Докумен … Википедия

Цикломатическая сложность - программы (англ. Cyclomatic complexity of a program) структурная (или топологическая) мера сложности программ, используемая для измерения качества программного обеспечения, основанная на методах статического анализа кода. ЦСП равна… … Википедия

Zabbix - 1.1 alpha 6 running under GNU/Linux … Википедия

Берг О.Ю.

МЕТРИКИ ОЦЕНКИ КАЧЕСТВА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Поскольку обработка данных затрагивает нашу жизнь всё в большей степени, ошибки ЭВМ могут теперь иметь такие последствия, как нанесение материального ущерба, нарушение секретности и многие другие, включая смерть. Надёжность программного обеспечения (ПО) есть вероятность его работы без отказов в течение определённого периода времени, рассчитанная с учётом стоимости для пользователя каждого отказа. Следовательно, необходимо иметь возможность измерять качество ПО на протяжении всего цикла разработки. Качество ПО целесообразно оценивать на основе критериев качества , которые должны:

Численно характеризовать основную целевую функцию программы;

Обеспечивать возможность определения затрат, необходимых для достижения требуемого уровня качества, а также степени влияния на показатель качества различных внешних факторов;

Быть по возможности простым, хорошо измеримым и иметь малую дисперсию.

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

Метрика качества программ - система измерений качества программ. Эти измерения могут проводиться на уровне критериев качества программ или на уровне отдельных характеристик качества. В первом случае система измерений позволяет непосредственно сравнивать программы по качеству. При этом сами измерения не могут быть проведены без субъективных оценок свойств программ. Во втором случае измерения характеристик можно выполнить объективно и достоверно, но оценка качества ПО в целом будет связана с субъективной интерпретацией получаемых оценок.

В исследовании метрик ПО различают два основных направления:

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

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

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

Метрики, оценивающие отклонение от нормы характеристик исходных проектных материалов. Они устанавливают полноту заданных технических характеристик исходного кода.

Метрики, позволяющие прогнозировать качество разрабатываемого ПО. Они заданы на множестве

возможных вариантов решений поставленной задачи и их реализации и определяют качество ПО, которое

будет достигнуто в итоге.

Метрики, по которым принимается решение о соответствии конечного ПО заданным требованиям. Они позволяют оценить соответствие разработки заданным требованиям.

В настоящее время в мировой практике используется несколько сотен метрик программ. Существующие качественные оценки программ можно сгруппировать по шести направлениям:

Оценки топологической и информационной сложности программ;

Оценки надежности программных систем, позволяющие прогнозировать отказовые ситуации;

Оценки производительности ПО и повышения его эффективности путем выявления ошибок проектирования;

Оценки уровня языковых средств и их применения;

Оценки трудности восприятия и понимания программных текстов, ориентированные на

психологические факторы, существенные для сопровождения и модификации программ;

Оценки производительности труда программистов для прогнозирования сроков разработки программ и планирования работ по созданию программных комплексов.

В зависимости от характеристик и особенностей применяемых метрик им ставятся в соответствие различные измерительные шкалы:

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

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

Интервальной шкале соответствуют метрики, которые показывают не только относительное положение программ, но и то, как далеко они отстоят друг от друга;

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

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

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

метрика должна иметь смысл, как для заказчика, так и для исполнителя;

метрика должна быть объективна и ее определение недвусмысленно;

метрика должна давать возможность отслеживать тенденцию изменений;

метрика может быть автоматизирована.

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

ЛИТЕРАТУРА

1. Liu K., Zhou S. Yang H., Quality Metrics of Object Oriented Design for Software Development and Re-development,- Proceedings of the First Asia-Pacific Conference on Quality Software, 2000 IEEE

2. Boehm B. W., Brown J. R., Lipow M. QUANTITATIVE EVALUATION OF SOFTWARE QUALITY Proceedings of the 2nd International Conference on Software Engineering on International conference on software engineering October 1976

3. Houdek F., Kempter H. Quality patterns - An approach to packaging software engineering experience ACM SIGSOFT Software Engineering Notes , Proceedings of the 1997 symposium on Symposium on software reusability May 1997

4. У. Ройс Управление проектами по созданию программного обеспечения, Москва, ЛОРИ

Метрика - это количественный масштаб и метод, который может использоваться для измерения.

От себя добавим, что введение и использование метрик необходимо для улучшения контроля над процессом разработки, а в частности над процессом тестирования , который мы и будем рассматривать далее.

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

Создание, использование и анализ метрик

На наш взгляд, для большей наглядности имеет смысл сгруппировать метрики по типам сущностей, участвующих в обеспечении качества и тестировании программного обеспечения, а именно:

1. Метрики по тестовым случаям (Test Cases)
2. Метрики по багам / дефектам
3. Метрики по задачам

Давайте более детально разберем каждую из них:

Метрики по тест кейсам

Метрики по багам

Хотим отметить, что метрики "Open/Closed Bugs", "Bugs by Severity" и "Bugs by Priority" хорошо визуализируют степень приближения продукта к достижению критериев качества по багам. Имея требования к количеству открытых багов , после каждой итерации тестирования мы сравниваем их с реальными данными, тем самым видя места, где нам нужно прибавить, для скорейшего достижения цели.

Метрики "Reopened/Closed Bugs" и "Rejected/Opened Bugs" направлены на отслеживание работы отдельных участников групп разработки и тестирования.

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

1. Некачественное поверхностное решение проблемы (фикс бага)

Второй пример покажет для чего необходима метрика "Rejected/Opened Bugs":
Мы наблюдаем, что процент отклоненных (Rejected) багов очень большой. Это может значить:

1. Требования к функции можно трактовать по разному
2. Тестировщик не точно описал проблему
3. Разработчик не желает исправлять допущенную им ошибку или не считает, что это на самом деле ошибка. (Эта проблема является прямым следствием 2-ой, возникшей из-за не точного описания)

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

Метрики по задачам

Название	Описание
Deployment tasks	Метрика показывает количество и результаты установок приложения. Процедура установки приложения была описана в статье Процедура проведения установки новой версии ПО (Deployment WorkFlow) . В случае, если количество отклоненных командой тестирования версий будет критически высоким, рекомендуется срочно проанализировать и выявить причины, а также в кротчайшие сроки решить имеющуюся проблему.
Still Opened Tasks	Метрика показывает количество все еще открытых задач. К окончанию проекта все задачи должны быть закрыты. Под задачами понимаем следующие виды работ: написание документации (архитектура, требования, планы), имплементация новых модули или изменение существующих по запросам на изменения, работы по настройке стендов, различные исследования и многое другое

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

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

5). Сопровождаемость

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

Cопровождаемость включает подхарактеристики:

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

– изменяемость – атрибут, определяющий усилия, которые затрачиваются на модификацию, удаление ошибок или внесение изменений для устранения ошибок или введения новых возможностей в ПО или в среду функционирования;

– стабильность – атрибут, указывающие на риск модификации;

– тестируемость – атрибут, показывающий на усилия при проведении валидации, верификации с целью обнаружения ошибок и несоответствий требованиям, а также на необходимость проведения модификации ПО и сертификации;

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

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

Переносимость включает подхарактеристики:

– адаптивность – атрибут, определяющий усилия, затрачиваемые на адаптацию к различным средам;

– настраиваемость (простота инсталлирования) – атрибут, который определяет на необходимые усилия для запуска или инсталляции данного ПО в специальной среде;

– сосуществование – атрибут, который определяет возможность использования специального ПО в среде действующей системы;

– заменяемость – атрибут, который обеспечивают возможность интероперабельности при совместной работе с другими программами с необходимой инсталляцией или адаптацией ПО;

– согласованность – атрибут, который показывают на соответствие стандартам или соглашениями по обеспечению переноса ПО.

9.1.1. Метрики качества программного обеспечения

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

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

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

Согласно стандарта метрики определяются по модели измерения атрибутов ПО на всех этапах ЖЦ (промежуточная, внутренняя метрика) и особенно на этапе тестирования или функционирования (внешние метрики) продукта.

Остановимся на классификации метрик ПО, правилах для проведения метрического анализа и процесса их измерения.

Типы метрик . Существует три типа метрик:

– метрики программного продукта, которые используются при измерении его характеристик – свойств;

– метрики процесса, которые используются при измерении свойства процесса, используемого для создания продукта.

– метрики использования.

Метрики программного продукта включают:

– внешние метрики, обозначающие свойства продукта, видимые пользователю;

– внутренние метрики, обозначающие свойства, видимые только команде разработчиков.

Внешние метрики продукта включают такие метрики:

– надежности продукта, которые служат для определения числа дефектов;

– функциональности, с помощью которых устанавливается наличие и правильность реализации функций в продукте;

– сопровождения, с помощью которых измеряются ресурсы продукта (скорость, память, среда);

– применимости продукта, которые способствуют определению степени доступности для изучения и использования;

– стоимости, которыми определяется стоимость созданного продукта.

Внутренние метрики продукта включают метрики:

– размера, необходимые для измерения продукта с помощью его внутренних характеристик;

– сложности, необходимые для определения сложности продукта;

– стиля, которые служат для определения подходов и технологий создания отдельных компонент продукта и его документов.

Внутренние метрики позволяют определить производительность продукта и они являются релевантными по отношению к внешним метрикам.

Внешние и внутренние метрики задаются на этапе формирования требований к ПО и являются предметом планирования способов достижения качества конечного программного продукта.

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

– требований;

– сценариев и действующих лиц;

– объектов, включенных в сценарий, и локализация требований к каждому сценарию;

– параметров и операций объекта и др.

Стандарт ISO/IEC 9126–2 определяет следующие типы мер:

– мера размера ПО в разных единицах измерения (число функций, строк в программе, размер дисковой памяти и др.);

– мера времени (функционирования системы, выполнения компонента и др.);

– мера усилий (производительность труда, трудоемкость и др.);

– меры учета (количество ошибок, число отказов, ответов системы и др.).

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

– общее число объектов и число повторно используемых;

– общее число операций, повторно используемых и новых операций;

– число классов, наследующих специфические операции;

– число классов, от которых зависит данный класс;

– число пользователей класса или операций и др.

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

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

Примером широко используемых внешних метрик программ являются метрики Холстеда – это характеристики программ, выявляемые на основе статической структуры программы на конкретном языке программирования: число вхождений наиболее часто встречающихся операндов и операторов; длина описания программы как сумма числа вхождений всех операндов и операторов и др.

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

Метрики процессов включают метрики:

– стоимости, определяющие затраты на создание продукта или на архитектуру проекта с учетом оригинальности, поддержки, документации разработки;

– оценки стоимости работ специалистов за человека–дни либо месяцы;

– ненадежности процесса – число не обнаруженных дефектов при проектировании;

– повторяемости, которые устанавливают степень использования повторных компонентов.

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

– общее время разработки и отдельно время для каждой стадии;

– время модификации моделей;

– время выполнения работ на процессе;

– число найденных ошибок при инспектировании;

– стоимость проверки качества;

– стоимость процесса разработки.

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

9.1.2. Стандартный метод оценки значений показателей качества

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

По определению стандарта ISO/IES 9126–2 метрика качества ПО представляет собой “модель измерения атрибута, связываемого с показателем его качества”. Для пользования метриками при измерения показателей качества данный стандарт позволяет определять следующие типы мер:

– меры размера в разных единицах измерения (количество функций, размер программы, объем ресурсов и др.);

– меры времени – периоды реального, процессорного или календарного времени (время функционирования системы, время выполнения компонента, время использования и др.);

– меры усилий – продуктивное время, затраченное на реализацию проекта (производительность труда отдельных участников проекта, коллективная трудоемкость и др.);

– меры интервалов между событиями, например, время между последовательными отказами;

– счетные меры – счетчики для определения количества обнаруженных ошибок, структурной сложности программы, числа несовместимых элементов, числа изменений (например, число обнаруженных отказов и др.).

Метрики качества используются при оценки степени тестируемости после проведения испытаний ПО на множестве тестов (безотказная работа, выполнимость функций, удобство применения интерфейсов пользователей, БД и т.п.).

Наработка на отказ, как атрибут надежности определяет среднее время между появлением угроз, нарушающих безопасность, и обеспечивает трудно измеримую оценку ущерба, которая наносится соответствующими угрозами.

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

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

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

Т.е. при проведении оценки отдельного показателя с помощью оценочных элементов просчитывается весомый коэффициент k – метрика, j – показатель, i – атрибут. Например, в качестве j – показателя возьмем переносимость. Этот показатель будет вычисляться по пяти атрибутам (i = 1, ..., 5 ), причем каждый из них будет умножаться на соответствующий коэффициент k i .

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

В конечном итоге результат оценки качества является критерием эффективности и целесообразности применения методов проектирования, инструментальных средств и методик оценивания результатов создания программного продукта на стадиях ЖЦ.

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

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

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

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

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

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

– метрическая (1.1 – абсолютная, 1.2 – относительная, 1.3 – интегральная);

– порядковая (ранговая), позволяющая ранжировать характеристики путем сравнения с опорными;

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

Показатели, вычисляемые с помощью метрических шкал, называются количественными, а с помощью порядковых и классификационных – качественными.

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

– номинальная шкала отражает категории свойств оцениваемого объекта без их упорядочения;

– порядковая шкала служит для упорядочивания характеристики по возрастанию или убыванию путем сравнения их с базовыми значениями;

– интервальная шкала задает существенные свойства объекта (например, календарная дата);

– относительная шкала задает некоторое значение относительно выбранной единицы;

– абсолютная шкала указывает на фактическое значение величины (например, число ошибок в программе равно 10).

9.1.3. Управление качеством ПС

Под управлением качества понимается совокупность организационной структуры и ответственных лиц, а также процедур, процессов и ресурсов для планирования и управления достижением качества ПС. Управление качеством – SQM (Software Quality Management) базируется на применении стандартных положений по гарантии качества – SQA(Software Quality Assurance) .

Цель процесса SQA состоит в гарантировании того, что продукты и процессы согласуются с требованиями, соответствуют планам и включает следующие виды деятельности:

– внедрение стандартов и соответствующих процедур разработки ПС на этапах ЖЦ;

– оценка соблюдения положений этих стандартов и процедур.

Гарантия качества состоит в следующем:

– проверка непротиворечивости и выполнимости планов;

– согласование промежуточных рабочих продуктов с плановыми показателями;

– проверка изготовленных продуктов заданным требованиям;

– анализ применяемых процессов на соответствие договору и планам;

– среда и методы разработки согласуются с заказом на разработку;

– проверка принятых метрик продуктов, процессов и приемов их измерения в соответствии с утвержденным стандартом и процедурами измерения.

Цель процесса управления SQM состоит в том, чтобы провести мониторинг (систематический контроль) качества для гарантии, что продукт будет удовлетворять потребителю и предполагает выполнение следующих видов деятельности:

– определение количественных свойств качества, основанных на выявленных и предусмотренных потребностях пользователей;

– управление реализацией поставленных целей для достижения качества.

SQM основывается на гарантии того, что:

– цели достижения требуемого качества установлены для всех рабочих продуктов в контрольных точках продукта;

– определена стратегия достижения качества, метрики, критерии, приемы, требования к процессу измерения и др.;

– определены и выполняются действия, связанные с предоставлением продуктам свойств качества;

– проводится контроль качества (SQA, верификация и валидация) и целей, если они не достигнуты, то проводится регулирование процессов;

– выполняются процессы измерения и оценивании конечного продукта на достижение требуемого качества.

Основные стандартные положения по созданию качественного продукта и оценки уровня достигнутого выделяют два процесса обеспечения качества на этапах ЖЦ ПС:

– гарантия (подтверждение) качества ПС, как результат определенной деятельности на каждом этапе ЖЦ с проверкой соответствия системы стандартам и процедурам, ориентированным на достижении качества;

– инженерия качества, как процесс предоставления продуктам ПО свойств функциональности, надежности, сопровождения и других характеристик качества.

Процессы достижения качества предназначены для:

а) управления, разработки и обеспечения гарантий в соответствии с указанными стандартами и процедурами;

б) управления конфигурацией (идентификация, учет состояния и действий по аутентификации), риском и проектом в соответствии со стандартами и процедурами;

в) контроль базовой версии ПС и реализованных в ней характеристик качества.

Выполнение указанных процессов включает такие действия:

– оценка стандартов и процедур, которые выполняются при разработке программ;

– ревизия управления, разработки и обеспечение гарантии качества ПО, а также проектной документации (отчеты, графики разработки, сообщения и др.);

– контроль проведения формальных инспекций и просмотров;

– анализ и контроль проведения приемочного тестирования (испытания) ПС.

Для организации, которая занимается разработкой ПС в том числе из компонентов, инженерия качества ПС должна поддерживаться системой качества, управлением качеством (планирование, учет и контроль).

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

Система качества (Quality systems – QS) - это набор организационных структур, методик, мероприятий, процессов и ресурсов для осуществления управления качеством. Для обеспечения требуемого уровня качества ПО применяются два подхода. Один из них ориентирован на конечный программный продукт, а второй - на процесс создания продукта.

При подходе, ориентированном на продукт, оценка качества проводится после испытания ПС. Этот подход базируется на предположении, что чем больше обнаружено и устранено ошибок в продукте при испытаниях, тем выше его качество.

При втором подходе предусматриваются и принимаются меры по предотвращению, оперативному выявлению и устранению ошибок, начиная с начальных этапов ЖЦ в соответствии с планом и процедурами обеспечения качества разрабатываемой ПС. Этот подход представлен в серии стандартов ISO 9000 и 9000-1,2,3. Цель стандарта 9000–3 состоит в выдаче рекомендаций организациям-разработчикам создать систему качества по схеме, приведенной на рис.9.3.

Совместная

Система контроль Руководитель работа Ответственный

Качества от исполнителя от заказчика

Общая политика

Ответственность

и полномочия

Средства контроля

План достижения

качества ПС

Рис.9.3. Требования стандарта к организации системы качества

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

Планирование качества представляет собою деятельность, направленную на определение целей и требований к качеству. Оно охватывает идентификацию, установление целей, требований к качеству, классификацию и оценку качества. Составляется календарный план–график для проведения анализа состояния разработки и последовательного измерения спланированных показателей и критериев на этапах ЖЦ.

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

Обеспечение качества заключается в выполнении и проверки того, что объект разработки выполняет указанные требования к качеству. Цели обеспечения качества могут быть внутренние и внешние. Внутренние цели - создание уверенности у руководителя проекта, что качество обеспечивается. Внешние цели - это создание уверенности у пользователя, что требуемое качество достигнуто и результатом является качественное программное обеспечение.

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

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

9.2. Модели оценки надежности

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

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

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

Для многих систем (программ и данных) надежность является главной целевой функцией реализации. К некоторым типам систем (реального времени, радарные системы, системы безопасности, медицинское оборудование со встроенными программами и др.) предъявляются высокие требования к надежности, такие как недопустимость ошибок, достоверность, безопасность, защищенность и др.

ПрограммноеДокумент

Т.д. Цветная паутина, предлагаемая в учебниках , сложна для восприятия и понимания... его использования. М.М. Петрухин ГОУ ВПО « ... средства . На сегодняшний день в программной инженерии можно выделить два основных подхода к разработке программного обеспечения ...

Черников Алексей

1. Введение

В отличие от большинства отраслей материального производства, в вопросах проектов создания ПО недопустимы простые подходы, основанные на умножении трудоемкости на среднюю производительность труда. Это вызвано, прежде всего, тем, что экономические показатели проекта нелинейно зависят от объема работ, а при вычислении трудоемкости допускается большая погрешность.

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

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

• предварительная, постоянная и итоговая оценка экономических параметров проекта: трудоемкость, длительность, стоимость;
  
• оценка рисков по проекту: риск нарушения сроков и невыполнения проекта, риск увеличения трудоемкости на этапах отладки и сопровождения проекта и пр.;
  
• принятие оперативных управленческих решений – на основе отслеживания определенных метрик проекта можно своевременно предупредить возникновение нежелательных ситуаций и устранить последствия непродуманных проектных решений.

1 Введение
2 Метрики
2.1 Размерно-ориентированные метрики (показатели оценки объема)
2.1.1 LOC-оценка (Lines Of Code)
2.1.1.1 Метрика стилистики и понятности программ
2.1.2 Итого по SLOC
2.2 Метрики сложности
2.2.2 Метрики Холстеда
2.2.4 Метрики Чепина

2.4 Общий списочный состав метрик
2.4 Подведение итогов
6 Ресурсы интернет

2. Метрики

Метрики сложности программ принято разделять на три основные группы:

• метрики размера программ;
  
• метрики сложности потока управления программ;
  
• метрики сложности потока данных программ.
  

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

Метрики второй группы базируются на анализе управляющего графа программы. Представителем данной группы является метрика Маккейба.

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

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

2.1 Размерно - ориентированные метрики (показатели оценки объема)

2.1.1 LOC-оценка (Lines Of Code)

Размерно-ориентированные метрики прямо измеряют программный продукт и процесс его разработки. Основываются такие метрики на LOC-оценках.

Этот вид метрик косвенно измеряет программный продукт и процесс его разработки. Вместо подсчета LOC-оценок при этом рассматривается не размер, а функциональность или полезность продукта.

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

• общие трудозатраты (в человеко-месяцах, человеко-часах);
  
• объем программы (в тысячах строках исходного кода -LOC);
  
• стоимость разработки;
  
• объем документации;
  
• ошибки, обнаруженные в течение года эксплуатации;
  
• количество людей, работавших над изделием;
  
• срок разработки.
  

На основе этих данных обычно подсчитываются простые метрики для оценки производительности труда (KLOC/человеко-месяц) и качества изделия.

Эти метрики не универсальны и спорны, особенно это относится к такому показателю как LOC, который существенно зависит от используемого языка программирования.

Количество строк исходного кода (Lines of Code – LOC, Source Lines of Code – SLOC) является наиболее простым и распространенным способом оценки объема работ по проекту.

Изначально данный показатель возник как способ оценки объема работы по проекту, в котором применялись языки программирования, обладающие достаточно простой структурой: «одна строка кода = одна команда языка». Также давно известно, что одну и ту же функциональность можно написать разным количеством строк, а если возьмем язык высокого уровня (С++, Java), то возможно и в одной строке написать функционал 5-6 строк – это не проблема. И это было бы полбеды: современные средства программирования сами генерируют тысячи строк кода на пустяковую операцию.

Потому метод LOC является только оценочным методом (который надо принимать к сведению, но не опираться в оценках) и никак не обязательным.

В зависимости от того, каким образом учитывается сходный код , выделяют два основных показателя SLOC:

1. количество «физических» строк кода – SLOC (используемые аббревиатуры LOC, SLOC, KLOC, KSLOC, DSLOC) – определяется как общее число строк исходного кода, включая комментарии и пустые строки (при измерении показателя на количество пустых строк, как правило, вводится ограничение – при подсчете учитывается число пустых строк, которое не превышает 25% общего числа строк в измеряемом блоке кода).
   
2. Количество «логических» строк кода – SLOC (используемые аббревиатуры LSI, DSI, KDSI, где «SI» - source instructions) – определяется как количество команд и зависит от используемого языка программирования. В том случае, если язык не допускает размещение нескольких команд на одной строке, то количество «логических» SLOC будет соответствовать числу «физических», за исключением числа пустых строк и строк комментариев. В том случае, если язык программирования поддерживает размещение нескольких команд на одной строке, то одна физическая строка должна быть учтена как несколько логических, если она содержит более одной команды языка.
   

Для метрики SLOC существует большое число производных, призванных получить отдельные показатели проекта, основными среди которых являются:

• число пустых строк;
  
• число строк, содержащих комментарии;
  
• процент комментариев (отношение строк кода к строкам комментария, производная метрика стилистики);
  
• среднее число строк для функций (классов, файлов);
  
• среднее число строк, содержащих исходный код для функций (классов, файлов);
  
• среднее число строк для модулей.
  

2.1.1.1 Метрика стилистики и понятности программ

Иногда важно не просто посчитать количество строк комментариев в коде и просто соотнести с логическими строчками кода, а узнать плотность комментариев. То есть код сначала был документирован хорошо, затем – плохо. Или такой вариант: шапка функции или класса документирована и комментирована, а код нет.

Fi = SIGN (Nкомм. i / Ni – 0,1)

Суть метрики проста: код разбивается на n-равные куски и для каждого из них определяется Fi

2.1.2 Итого по SLOC

Потенциальные недостатки SLOC, на которые нацелена критика:

• некрасиво и неправильно сводить оценку работы человека к нескольким числовым параметрам и по ним судить о производительности. Менеджер может назначить наиболее талантливых программистов на сложнейший участок работы; это означает, что разработка этого участка займёт наибольшее время и породит наибольшее количество ошибок, из-за сложности задачи. Не зная об этих трудностях, другой менеджер по полученным показателям может решить, что программист сделал свою работу плохо.
  
• Метрика не учитывает опыт сотрудников и их другие качества
  
• Искажение: процесс измерения может быть искажён за счёт того, что сотрудники знают об измеряемых показателях и стремятся оптимизировать эти показатели, а не свою работу. Например, если количество строк исходного кода является важным показателем, то программисты будут стремиться писать как можно больше строк и не будут использовать способы упрощения кода, сокращающие количество строк (см. врезку про Индию).
  
• Неточность: нет метрик, которые были бы одновременно и значимы и достаточно точны. Количество строк кода - это просто количество строк, этот показатель не даёт представления о сложности решаемой проблемы. Анализ функциональных точек был разработан с целью лучшего измерения сложности кода и спецификации, но он использует личные оценки измеряющего, поэтому разные люди получат разные результаты.
  

И главное помнить: метрика SLOC не отражает трудоемкости по созданию программы
.

Пример из жизни : В одной из компаний при внедрении мы применили данную метрику – считали строки кода. Руководитель организации был в отпуске, но по возвращении из него решил воспользоваться прозрачностью и трассируемостью изменений и посмотреть, как же идут дела в проектах у его менеджеров. И чтоб полностью войти в курс , опустился на самый низкий уровень (то есть не стал оценивать плотность дефектов, количество исправленных багов) – на уровень исходных текстов. Решил посчитать, кто и сколько строк написал. А чтоб было совсем весело – соотнести количество рабочих дней в неделю и количество написанного кода (логика проста: человек работал 40 часов в неделю, значит, должен много чего написать). Естественно, нашелся человек, который за неделю написал всего одну строку, даже не написал, а только откорректировал существующую… Гневу руководителя не было предела – нашел бездельника! И плохо было бы программисту, если бы менеджер проекта не объяснил, что: была найдена ошибка в программе, нашел ее VIP- клиент, ошибка влияет на бизнес клиента и ее нужно было срочно устранить, для этого был выбран вот этот конкретный исполнитель, который развернул стенд, залил среду клиента, подтвердил проявление ошибки и начал ее искать и устранять. Естественно, в конце концов, он поменял фрагмент кода, в котором было неправильное условие и все заработало.

Согласитесь, считать трудозатраты по данной метрике глупо – необходима комплексная оценка…

2.2 Метрики сложности

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

2.2.1 Объектно-ориентированные метрики

В современных условиях большинство программных проектов создается на основе ОО подхода, в связи с чем существует значительное количество метрик, позволяющих получить оценку сложности объектно-ориентированных проектов.

Метрика	Описание
Взвешенная насыщенность класса 1 (Weighted Methods Per Class (WMC)	Отражает относительную меру сложности класса на основе цикломатической сложности каждого его метода. Класс с более сложными методами и большим количеством методов считается более сложным. При вычислении метрики родительские классы не учитываются.
Взвешенная насыщенность класса 2 (Weighted Methods Per Class (WMC2))	Мера сложности класса, основанная на том, что класс с большим числом методов, является более сложным, и что метод с большим количеством параметров также является более сложным. При вычислении метрики родительские классы не учитываются.
Глубина дерева наследования (Depth of inheritance tree)	Длина самого длинного пути наследования, заканчивающегося на данном модуле. Чем глубже дерево наследования модуля, тем может оказаться сложнее предсказать его поведение. С другой стороны, увеличение глубины даёт больший потенциал повторного использования данным модулем поведения, определённого для классов-предков.
Количество детей (Number of children)	Число модулей, непосредственно наследующих данный модуль.Большие значения этой метрики указывают на широкие возможности повторного использования; при этом слишком большое значение может свидетельствовать о плохо выбранной абстракции .
Связность объектов (Coupling between objects)	Количество модулей, связанных с данным модулем в роли клиента или поставщика. Чрезмерная связность говорит о слабости модульной инкапсуляции и может препятствовать повторному использованию кода.
Отклик на класс (Response For Class)	Количество методов, которые могут вызываться экземплярами класса; вычисляется как сумма количества локальных методов, так и количества удаленных методов

2.2.2 Метрики Холстеда

Метрика Холстеда относится к метрикам, вычисляемым на основании анализа числа строк и синтаксических элементов исходного кода программы.

Основу метрики Холстеда составляют четыре измеряемые характеристики программы:

• NUOprtr (Number of Unique Operators) - число уникальных операторов программы, включая символы-разделители, имена процедур и знаки операций (словарь операторов);
  
• NUOprnd (Number of Unique Operands) - число уникальных операндов программы (словарь операндов);
  
• Noprtr (Number of Operators) - общее число операторов в программе;
  
• Noprnd (Number of Operands) - общее число операндов в программе.
  

На основании этих характеристик рассчитываются оценки:

• Словарь программы
  (Halstead Program Vocabulary, HPVoc): HPVoc = NUOprtr + NUOprnd;
  
• Длина программы
  (Halstead Program Length, HPLen): HPLen = Noprtr + Noprnd;
  
• Объем программы
  (Halstead Program Volume, HPVol): HPVol = HPLen log2 HPVoc;
  
• Сложность программы
  (Halstead Difficulty, HDiff): HDiff = (NUOprtr/2) × (NOprnd / NUOprnd);
  
• На основе показателя HDiff предлагается оценивать усилия программиста при разработке при помощи показателя HEff (Halstead Effort) : HEff = HDiff × HPVol.
  

2.2.3 Метрики цикломатической сложности по Мак-Кейбу

Показатель цикломатической сложности является одним из наиболее распространенных показателей оценки сложности программных проектов. Данный показатель был разработан ученым Мак-Кейбом в 1976 г., относится к группе показателей оценки сложности потока управления программой и вычисляется на основе графа управляющей логики программы (control flow graph). Данный граф строится в виде ориентированного графа, в котором вычислительные операторы или выражения представляются в виде узлов, а передача управления между узлами – в виде дуг.

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

Упрощенная формула вычисления цикломатической сложности представляется следующим образом:

C = e – n + 2,

где e – число ребер, а n – число узлов
на графе управляющей логики.

Как правило, при вычислении цикломатической сложности логические операторы не учитываются.

В процессе автоматизированного вычисления показателя цикломатической сложности, как правило, применяется упрощенный подход, в соответствии с которым построение графа не осуществляется, а вычисление показателя производится на основании подсчета числа операторов управляющей логики (if, switch и т.д.) и возможного количества путей исполнения программы.

Цикломатическое число Мак-Кейба показывает требуемое количество проходов для покрытия всех контуров сильносвязанного графа или количества тестовых прогонов программы, необходимых для исчерпывающего тестирования по принципу «работает каждая ветвь».

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

Существует значительное количество модификаций показателя цикломатической сложности.

• «Модифицированная» цикломатическая сложность – рассматривает не каждое ветвление оператора множественного выбора (switch), а весь оператор как единое целое.
  
• «Строгая» цикломатическая сложность – включает логические операторы.
  
• «Упрощенное» вычисление цикломатической сложности – предусматривает вычисление не на основе графа, а на основе подсчета управляющих операторов.
  

2.2.4 Метрики Чепина

Существует несколько ее модификаций. Рассмотрим более простой, а с точки зрения практического использования – достаточно эффективный вариант этой метрики.

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

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

Q = a1P + a2M + a3C + a4T, где a1, a2, a3, a4 – весовые коэффициенты.

Q = P + 2M + 3C + 0.5T.

2.3 Предварительная оценка на основе статистических методов в зависимости от этапов разработки программы

При использовании интегрированных инструментальных средств у компаний, разрабатывающих типовые решения (под эту категорию попадают так называемые «инхаузеры» – компании, занимающиеся обслуживанием основного бизнеса) появляется возможность строить прогнозы сложности программ, основываясь на собранной статистике. Статистический метод хорошо подходит для решения подобных типовых задач и практически не подходит для прогноза уникальных проектов. В случае уникальных проектов применяются иные подходы, обсуждение которых находится за рамками данного материала.

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

Выделим типовые этапы в разработке программ:

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

Теперь попробуем рассмотреть ряд метрик, часто используемых для предварительной оценки на первых двух этапах.

2.3.1 Предварительная оценка сложности программы на этапе разработки спецификации требований к программе

Для оценки по результатам работы данного этапа может быть использована метрика прогнозируемого числа операторов Nпрогн программы:

Nпрогн =NF*Nед

Где: NF – количество функций или требований в спецификации требований к разрабатываемой программе;
Nед – единичное значение количества операторов (среднее число операторов, приходящихся на одну среднюю функцию или требование). Значение Nед - статистическое.

2.3.2 Предварительная оценка сложности на этапе определения архитектуры

Си = NI / (NF * NIед * Ксл)

Где:
NI – общее количество переменных, передаваемых по интерфейсам между компонентами программы (также является статистической);
NIед–единичное значение количества переменных, передаваемых по интерфейсам между компонентами (среднее число передаваемых по интерфейсам переменных, приходящихся на одну среднюю функцию или требование);
Ксл – коэффициент сложности разрабатываемой программы, учитывает рост единичной сложности программы (сложности, приходящейся на одну функцию или требование спецификации требований к программе) для больших и сложных программ по сравнению со средним ПС.

2.4 Общий списочный состав метрик

Таблица 1 содержит краткое описание метрик, не вошедших в детальное описание выше, но тем не менее даные метрики нужны и важны, просто по статистике они встречаются гораздо реже.

Также отметим, что цель этой статьи показать принцип, а не описать все возможные метрики во множестве комбинаций.