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

      M=u+1,

      где u – количество операторов ветвления.

      При необходимости операторы выбора или переключения с n ветвями, можно  рассматривать как n операторов ветвления.

      К достоинствам меры относят простоту ее вычисления и повторяемость результата, а также наглядность и содержательность интерпретации. В качестве недостатков можно отметить: нечувствительность к размеру ПО, нечувствительность к изменению структуры ПО, отсутствие корреляции со структурированностью ПО, отсутствие различия между конструкциями Развилка и Цикл, отсутствие чувствительности к вложенности циклов. Недостатки цикломатической меры привело к появлению ее модификаций, а также принципиально иных мер сложности.

      Модификации показателя цикломатической сложности:

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

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

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

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

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

1. Множество «Р» - вводимые переменные для расчетов и для обеспечения вывода. Примером может служить используемая в программах лексического анализатора переменная, содержащая строку исходного текста программы, то есть сама переменная не модифицируется, а только содержит исходную информацию.
2. Множество «М» - модифицируемые или создаваемые внутри программы переменные.
3. Множество «C» - переменные, участвующие в управлении работой программного модуля (управляющие переменные).
4. Множество «Т» - не используемые в программе (“паразитные”) переменные. Поскольку каждая переменная может выполнять одновременно несколько функций, необходимо учитывать ее в каждой соответствующей функциональной группе.

      Далее вводится значение метрики Чепина:

          Q = a1P + a2M + a3C + a4T

где a1, a2, a3, a4 - весовые коэффициенты.

      Весовые коэффициенты использованы для отражения  различного влияния на сложность  программы каждой функциональной группы. По мнению автора метрики наибольший вес, равный трем, имеет функциональная группа С, так как она влияет на поток управления программы. Весовые коэффициенты остальных групп распределяются следующим образом: a1=1; a2=2; a4=0.5. Весовой коэффициент группы T не равен нулю, поскольку “паразитные” переменные не увеличивают сложности потока данных программы, но иногда затрудняют ее понимание. С учетом весовых коэффициентов выражение примет вид:

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

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

      Размерно-ориентированные метрики прямо измеряют программный продукт и процесс его разработки. Самой распространенной метрикой исходного кода ПО, отражающей размер программного проекта, является показатель количества строк кода (Source Lines Of Code, SLOC). [6, 7]

1.3.8.1 SLOC - оценка (Source Lines Of Code)

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

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

      Литера  «D» (Delivered) означает «поставленный» код, т. е. только вошедший в законченный программный продукт. Очень часто возникает необходимость учитывать не только поставленный код, но и вспомогательный или промежуточный, который не входит в законченный продукт, но нужен для реализации проекта и требует определенных затрат труда.

      Что касается вычисления показателя SLOC, то здесь следует отметить, что не существует единственного общепризнанного  подхода, приемлемого для различных  языков программирования и ориентированного на универсальное применение. Чаще всего SLOC определяется как общее число строк кода за исключением пустых строк и комментариев. В большинстве случаев подсчитывается именно число «физических» SLOC, и наличие нескольких операторов на одной строке не учитывается. Также отметим, что если в контексте SLOC конкретный язык программирования не называется, это обычно означает, что речь идет о величине, выраженной в базовых единицах, – количестве строк кода языка Basic Assembler. Для сопоставления значений показателя для различных языков программирования применяются специальные таблицы преобразования.

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

• оценка показателя SLOC по аналогии. Данная методика позволяет получать оценку показателя для всего разрабатываемого проекта или отдельных его составляющих посредством сравнения функциональных свойств с существующими аналогами. При оценке показателя по данной методике подбирается близкий по функциональности аналог с известным значением SLOC, далее на его основании определяется прогнозная оценка с учетом различий в функциональности, применяемых языках, возможности оптимизации на основе кода аналога и пр.;
• оценка показателя SLOC «снизу-вверх» экспертным методом. Этой методикой предусмотрено разбиение проекта на иерархическую структуру задач (Work Breakdown Structure, WBS), на основании которых производится экспертная оценка показателя, в итоге суммируемая для всего проекта. Как правило, экспертами предоставляются три оценки (наиболее вероятная, максимальная и минимальная), а далее они усредняются с помощью бета - распределения (рассчитывается сумма минимальной, максимальной и четырехкратной наиболее вероятной оценок, которая затем делится на шесть).

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

• число пустых строк (Blank Lines Of Code, BLOC);
• число строк, содержащих комментарии (Comment Lines Of Code, CLOC);
• число строк, содержащих исходный код и комментарии (Lines with Both Code and Comments, C&SLOC);
• число строк, содержащих декларативный исходный код;
• число строк, содержащих императивный исходный код;
• процент комментариев (число строк комментариев, умноженное на 100 и деленное на число строк кода);
• среднее число строк для функций (методов);
• среднее число строк, содержащих исходный код для функций (методов);
• среднее число строк для модулей;
• среднее число строк для классов.

      Также наряду со SLOC применяются другие показатели, отражающие количественную оценку отдельных  составляющих проекта: число модулей, функций / методов, классов, страниц документации и пр. Однако помимо метрик, подсчитывающих число элементов проекта, к метрикам размера следует отнести также функциональные точки (Function Points, FP), их производные и разновидности, вычисляемые на базе не исходного кода, а пользовательских требований, спецификаций, описаний прецедентов (например, точки прецедентов, Use Case Points, UCP) и пр. В большинстве случаев главное предназначение этой группы метрик, независимо от способа их вычисления, состоит в том, чтобы оценить объем работ по проекту, и, соответственно, быть основой для таких показателей, как стоимость и длительность его реализации.

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

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

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

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

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

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

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

1.4 Альтернативные подходы  к измерению качества

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

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

• Легко использовать.
• Хорошая производительность.
• Нет ошибок.
• Не портит пользовательские данные при сбоях.
• Можно использовать на разных платформах.
• Может работать 24 часа в сутки и 7 дней в неделю.
• Легко добавлять новые возможности.
• Удовлетворяет потребности пользователей.
• Хорошо документировано.

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