Метрики. Работа проверена рецензент
 Скачать 1.3 Mb.
|
|
Метрики программного продукта включают: внешние метрики, обозначающие свойства продукта, видимые пользователю; внутренние метрики, обозначающие свойства, видимые только команде разработчиков. Внешние метрики продукта - это метрики: надежности продукта, которые служат для определения числа дефектов; функциональности, с помощью которых устанавливаются наличие и правильность реализации функций в продукте; сопровождения, с помощью которых измеряются ресурсы продукта (скорость, память, среда);применимости продукта, которые способствуют определению степени доступности для изучения и использования; стоимости, которыми определяется стоимость созданного продукта. Внутренние метрики продукта включают: метрики размера, необходимые для измерения продукта с помощью его внутренних характеристик; метрики сложности, необходимые для определения сложности продукта; метрики стиля, которые служат для определения подходов и технологий создания отдельных компонентов продукта и его документов. Внутренние метрики позволяют определить производительность продукта и являются релевантными по отношению к внешним метрикам. Внешние и внутренние метрики задаются на этапе формирования требований к ПО и являются предметом планирования и управления достижением качества конечного программного продукта. Метрики продукта часто описываются комплексом моделей для установки различных свойств, значений модели качества или прогнозирования. Измерения проводятся, как правило, после калибровки метрик на ранних этапах проекта. Общая мера - степень трассируемости, которая определяется числом трасс, прослеживаемых с помощью моделей сценариев и оценкой количества: требований; сценариев и действующих лиц; объектов, включенных в сценарий, и локализация требований к каждому сценарию; параметров и операций объекта и др. Стандарт ISO/IEC 9126-2 определяет следующие типы мер: мера размера ПО в разных единицах измерения (число функций, строк в программе, размер дисковой памяти и др.); мера времени (функционирования системы, выполнения компонента и др.); мера усилий (производительность труда, трудоемкость и др.); мера учета (количество ошибок, число отказов, ответов системы и др.). Специальной мерой может служить уровень использования повторных компонентов и измеряется как отношение размера продукта, изготовленного из готовых компонентов, к размеру системы в целом. Данная мера используется также при определении стоимости и качества ПО. Примеры метрик: общее число объектов и число повторно используемых; общее число операций, повторно используемых и новых операций; число классов, наследующих специфические операции; число классов, от которых зависит данный класс; число пользователей класса или операций и др. При оценке общего количества некоторых величин часто используются среднестатистические метрики (среднее число операций в классе, наследников класса или операций класса и др.). Как правило, меры в значительной степени являются субъективными и зависят от знаний экспертов, производящих количественные оценки атрибутов компонентов программного продукта. [8, 9] Примером широко используемых внешних метрик программ являются метрики Холстеда - это характеристики программ, выявляемые на основе статической структуры программы на конкретном языке программирования: число вхождений наиболее часто встречающихся операндов и операторов; длина описания программы как сумма числа вхождений всех операндов и операторов и др. На основе этих атрибутов можно вычислить время программирования, уровень программы (структурированность и качество) и языка программирования (абстракции средств языка и ориентация на проблему) и др. В качестве метрик процесса могут быть время разработки, число ошибок и др. Практически используются следующие метрики процесса: общее время разработки и отдельно время для каждой стадии; время модификации моделей; время выполнения работ на процессе; число найденных ошибок при инспектировании; стоимость проверки качества; стоимость процесса разработки. Метрики использования служат для измерения степени удовлетворения потребностей пользователя при решении его задач. Они помогают оценить не свойства самой программы, а результаты ее эксплуатации - эксплуатационное качество. Примером может служить - точность и полнота реализации задач пользователя, а также затраченные ресурсы (трудозатраты, производительность и др.) на эффективное решение задач пользователя. Оценка требований пользователя проводится с помощью внешних метрик. 1.3.1 Основные направления применения метрик В настоящее время в мировой практике используется несколько сотен метрик программ. Существующие качественные оценки программ можно сгруппировать по шести направлениям: оценки топологической и информационной сложности программ; оценки надежности программных систем, позволяющие прогнозировать отказовые ситуации; оценки производительности ПО и повышения его эффективности путем выявления ошибок проектирования; оценки уровня языковых средств и их применения; оценки трудности восприятия и понимания программных текстов, ориентированные на психологические факторы, существенные для сопровождения и модификации программ; оценки производительности труда программистов для прогнозирования сроков разработки программ и планирования работ по созданию программных комплексов. 1.3.2 Метрические шкалы В зависимости от характеристик и особенностей применяемых метрик им ставятся в соответствие различные измерительные шкалы. Номинальной шкале соответствуют метрики, классифицирующие программы на типы по признаку наличия или отсутствия некоторой характеристики без учета градаций. Порядковой шкале соответствуют метрики, позволяющие ранжировать некоторое характеристики путем сравнения с опорными значениями, т.е. измерение по этой шкале фактически определяет взаимное положение конкретных программ. Интервальной шкале соответствуют метрики, которые показывают не только относительное положение программ, но и то, как далеко они отстоят друг от друга. Относительной шкале соответствуют метрики, позволяющие не только расположить программы определенным образом и оценить их положение относительно друг друга, но и определить, как далеко оценки отстоят от границы, начиная с которой характеристика может быть измерена. Абсолютная шкала указывает на фактическое значение величины (например, число ошибок в программе равно 10). 1.3.3 Метрики сложности программ Теория сложности программ ориентирована на управление качеством ПО и контроль ее эталонной сложности в период эксплуатации. В настоящее время многообразие показателей (в той или иной степени описывающих сложность программ) столь велико, что для их употребления требуется предварительное упорядочение. В ряде случаев удовлетворяются тремя категориями метрик сложности. Первая категория определяется как словарная метрика, основанная на метрических соотношениях Холстеда, цикломатических мерах Мак-Кейба и измерениях Тейера. Вторая категория ориентирована на метрики связей, отражающих сложность отношений между компонентами системы - это метрики Уина и Винчестера. Третья категория включает семантические метрики, связанные с архитектурным построением программ и их оформлением. Согласно другой классификации, показатели сложности делятся на две группы: сложность проектирования и сложность функционирования. Сложность проектирования, которая определяется размерами программы, количеством обрабатываемых переменных, трудоемкостью и длительностью разработки и др. факторами, анализируется на основе трех базовых компонентов: сложность структуры программы, сложность преобразований (алгоритмов), сложность данных. Во вторую группу показателей отнесены временная, программная и информационная сложности, характеризующие эксплуатационные качества ПО. При оценке сложности программ, как правило, выделяют три основные группы метрик: метрики размера программ метрики сложности потока управления программ и метрики сложности потока данных программ Метрики первой группы базируются на определении количественных характеристик, связанных с размером программы, и отличаются относительной простотой. К наиболее известным метрикам данной группы относятся число операторов программы, количество строк исходного текста, набор метрик Холстеда. Метрики этой группы ориентированы на анализ исходного текста программ. Поэтому они могут использоваться для оценки сложности промежуточных продуктов разработки. Метрики второй группы базируются на анализе управляющего графа программы. Представителем данной группы является метрика Мак-Кейба. Управляющий граф программы, который используют метрики данной группы, может быть построен на основе алгоритмов модулей. Поэтому метрики второй группы могут применяться для оценки сложности промежуточных продуктов разработки. Метрики третьей группы базируются на оценке использования, конфигурации и размещения данных в программе. В первую очередь это касается глобальных переменных. К данной группе относятся метрики Чепина. Существует еще ряд подходов к классификации мер сложности, однако они, фиксируя частные стороны исследуемых программ, не позволяют (пусть с большим допущением) отразить общее, то, чьи замеры могут лечь в основу производственных решений. [11] Метрики Таблица 1
В таблице 1 представлены разнообразные метрики сложности ПО для различных форм их представления, модели прогнозирующие ход развития процессов разработки ПО и вероятностные модели по оценке надежности. Общим, инвариантно присущим любому ПО (и связанной с его корректностью), является его структура. Важно связать это обстоятельство с определенным значением структурной сложности в совокупности мер сложности ПО. И более того, при анализе структурной сложности целесообразно ограничиться только ее топологическими мерами, т.е. мерами, в основе которых лежат топологические характеристики граф-модели программы. Эти меры удовлетворяют подавляющему большинству требований, предъявляемых к показателям: общность применимости, адекватность рассматриваемому свойству, существенность оценки, состоятельность, количественное выражение, воспроизводимость измерений, малая трудоемкость вычислений, возможность автоматизации оценивания. Именно топологические меры сложности наиболее часто применяются в фазе исследований, формирующей решения по управлению производством (в процессах проектирования, разработки и испытаний) и составляют доступный и чувствительный эталон готовой продукции, контроль которого необходимо регулярно осуществлять в период ее эксплуатации. Первой топологической мерой сложности является цикломатическая мера Мак-Кейба. В ее основе лежит идея оценки сложности ПО по числу базисных путей в ее управляющем графе, т.е. таких путей, компонуя которые можно получить всевозможные пути из входа графа в выходы. Цикломатическое число (G) орграфа G с n-вершинами, m-дугами и p-компонентами связности есть величина (G) = m - n + p. Практически цикломатическая сложность ПО равна числу предикатов плюс единица, что позволяет вычислять ее без построения управляющего графа простым подсчетом предикатов. Данная мера отражает психологическую сложность ПО. Дж. Майерс предложил в качестве меры сложности интервал [ 1 2], где 1- цикломатическая мера, а 2 - число отдельных условий плюс единица. При этом, оператор DO считается за одно условие, а CASE c n - исходами за n-1- условий. Введенная мера получила название интервальной мерой. У. Хансену принадлежит идея брать в качестве меры сложности ПО пару (цикломатической число, число операторов). Известна топологическая мера Z(G), чувствительная к структурированности ПО. При этом, она Z(G) = V(G) (равна цикломатической сложности) для структурированных программ и Z(G) > V(G) для неструктурированных. К вариантам цикломатической меры сложности относят также меру М(G) = (V(G),C,Q), где С - количество условий, необходимых для покрытия управляющего графа минимальным числом маршрутов, а Q - степень связности структуры графа программы и ее протяженность. К мерам сложности, учитывающим вложенность управляющих конструкций, относят тестирующую меру М и меру Харрисона-Мейджела, учитывающих уровень вложенности и протяженности ПО, меру Пивоварского - цикломатическую сложность и глубину вложенности, и меру Мак-Клура - сложность схемы разбиения ПО на модули с учетом вложенности модулей и их внутренней сложности. Функциональная мера сложности Харрисона-Мейджела предусматривает приписывание каждой вершине графа своей собственной сложности (первичной) и разбиение графа на сферы влияния предикатных вершин. Сложность сферы называют приведенной и слагают ее из первичных сложностей вершин, входящих в сферу ее влияния, плюс первичную сложность самой предикатной вершины. Первичные сложности вычисляются всеми возможными способами. Отсюда функциональная мера сложности ПО есть сумма приведенных сложностей всех вершин управляющего графа. Мера Пивоварского ставит целью учесть в оценке сложности ПО различия не только между последовательными и вложенными управляющими конструкциями, но и между структурированными и неструктурированными программами. Она выражается отношением N(G) = *(G) + Pi , где *(G) - модифицированная цикломатическая сложность, вычисленная так же, как и V(G), но с одним отличием: оператор CASE с n- выходами рассматривается как один логический оператор, а не как n-1 операторов. Рi - глубина вложенности i - той предикатной вершины. Для подсчета глубины вложенности предикатных вершин используется число сфер влияния. Под глубиной вложенности понимается число всех сфер влияния предикатов, которые либо полностью содержаться в сфере рассматриваемой вершины, либо пересекаются с ней. Глубина вложенности увеличивается за счет вложенности не самих предикатов, а сфер влияния. Сравнительный анализ цикломатических и функциональных мер с обсуждаемой для десятка различных управляющих графов программы показывает, что при нечувствительности прочих мер этого класса, мера Пивоварского возрастает при переходе от последовательных программ к вложенным и далее к неструктурированным. Мера Мак-Клура предназначена для управления сложностью структурированных программ в процессе проектирования. Она применяется к иерархическим схемам разбиения программ на модули, что позволяет выбрать схему разбиения с меньшей сложностью задолго до написания программы. Метрикой выступает зависимость сложности программы от числа возможных путей исполнения, числа управляющих конструкций и числа переменных (от которых зависит выбор пути). Методика расчета сложности по Мак-Клуру четко ориентирована на хорошо структурированные программы. Тестирующей мерой М называется мера сложности, удовлетворяющая следующим условиям: Мера сложности простого оператора равна 1; М ({F1; F2; ┘;Fn}) = еin M(Fi); М (if P then F1 else F2) = 2 MAX (M (F1), M (F2)); М (while P do F) = 2 M(F). Мера возрастает с глубиной вложенности и учитывает протяженность программы. К тестирующей мере близко примыкает мера на основе регулярных вложений. Идея этой меры сложности программ состоит в подсчете суммарного числа символов (операндов, операторов, скобок) в регулярном выражении с минимально необходимым числом скобок, описывающим управляющий граф программы. Все меры этой группы чувствительны к вложенности управляющих конструкций и к протяженности программы. Однако возрастает уровень трудоемкости вычислений. Рассмотрим меры сложности, учитывающие характер разветвлений. В основе узловой меры Вудворда, Хедли лежит идея подсчета топологических характеристик потока управления. При этом, под узловой сложностью понимается число узлов передач управления. Данная мера отслеживает сложность линеаризации программы и чувствительна к структуризации (сложность уменьшается). Она применима для сравнения эквивалентных программ, предпочтительнее меры Холстеда, но по общности уступает мере Мак-Кейба. Топологическая мера Чена выражает сложность программы числа пересечений границ между областями, образуемыми блок - схемой программы. Этот подход применим только к структурированным программам, допускающим лишь последовательное соединение управляющих конструкций. Для неструктурированных программ мера Чена существенно зависит от условных и безусловных переходов. В этом случае можно указать верхнюю и нижнюю границы меры. Верхняя - есть m+1, где m - число логических операторов при их гнездовой вложенности. Нижняя - равна 2. Когда управляющий граф программы имеет только одну компоненту связности, мера Чена совпадает с цикломатической мерой Мак-Кейба. Метрики Джилба оценивают сложность графо-ориентированных модулей программ отношением числа переходов по условию к общему числу исполняемых операторов. Хорошо зарекомендовала себя метрика, относящаяся число межмодульных связей к общему числу модулей. Названные метрики использовались для оценки сложности эквивалентных схем программ, в особенности схем Янова. Используются также меры сложности, учитывающие историю вычислений, характер взаимодействия модулей и комплексные меры. Совокупность цикломатических мер пригодна для оценивания сложности первичных формализованных спецификаций, задающих в совокупности исходные данные, цели и условия построения искомого ПО. Оценка этой первичной программы или сравнение нескольких альтернативных ее вариантов позволит изначально гармонизировать процесс разработки ПО и от стартовой точки контролировать и управлять его текущей результирующей сложностью. 1.3.4 Объектно-ориентированные метрики В современных условиях большинство программных проектов создается на основе ОО подхода, в связи с чем существует значительное количество метрик, позволяющих получить оценку сложности объектно-ориентированных проектов. [10] Объектно-ориентированные метрики Таблица 2
1.3.5 Метрики Холстеда Метрика Холстеда относится к метрикам, вычисляемым на основании анализа числа строк и синтаксических элементов исходного кода программы. Основу метрики Холстеда составляют четыре измеряемые характеристики программы: NUOprtr (Number of Unique Operators) — число уникальных операторов программы, включая символы-разделители, имена процедур и знаки операций (словарь операторов); NUOprnd (Number of Unique Operands) — число уникальных операндов программы (словарь операндов); Noprtr (Number of Operators) — общее число операторов в программе; Noprnd (Number of Operands) — общее число операндов в программе. Метрики Холстеда отражают лексический подход к измерению характеристик программного обеспечения, основанный на измеримых свойствах алгоритмов. Свойства любого описания алгоритма (или программы для ЭВМ), по мнению Холстеда, могут быть измерены или вычислены на основе следующих метрических характеристик (оценочных элементов): n1 - количество различных операторов программы; n2 - количество различных операндов программы; N1 - общее количество операторов программы; N2 - общее количество операндов программы. На их основе Холстед определяет следующие метрики: словарь программы (в условных единицах) n = n1+n2, (1) теоретический словарь программы, т.е. словарный запас, необходимый для написания программы, с учетом того, что необходимая функция уже реализована в данном языке и, следовательно, программа сводится к вызову этой функции. n* = n1* + n2* длина программы (в условных единицах) N = N1+N2 (2) теоретическая длина программы (в условных единицах) Ñ = (n1 log2 n1)+(n2log2 n2), (3) Вводя эту оценку, Холстед исходит из основных концепций теории информации, по аналогии с которыми частота использования операторов и операндов в программе пропорциональна двоичному логарифму количества их типов. Таким образом, выражение (3) представляет собой идеализированную аппроксимацию (2), т. е. справедливо для потенциально корректных программ, свободных от избыточности или несовершенств (стилистических ошибок). Несовершенствами можно считать следующие ситуации: последующая операция уничтожает результаты предыдущей без их использования; присутствуют тождественные выражения, решающие совершенно одинаковые задачи; одной и той же переменной назначаются различные имена и т. п. Подобные ситуации приводят к изменению N без изменения n. Холстед утверждает, что для стилистически корректных программ отклонение в оценке теоретической длины Ñ от реальной N не превышает 10%. Предлагается использовать Ñ как эталонное значение длины программы со словарем n. Длина корректно составленной программы N, т. е. программы, свободной от избыточности и имеющей словарь n, не должна отклоняться от теоретической длины программы Ñ более чем на 10%. Таким образом, измеряя n1, n2, N1 и N2 и сопоставляя значения N и Ñ для некоторой программы, при более чем 10%-ном отклонении можно говорить о наличии в программе стилистических ошибок, т. е. несовершенств. На практике N и Ñ часто существенно различаются. объем программы (в битах, определение объема программы предполагает, что обозначение операндов и операторов требует не более одного символа). V = N log2(n) (4) потенциальный объем программы (полагая, что в программах, идеальных с точки зрения экономии затрат памяти, во-первых: операторы и операнды не повторяются, во-вторых: все операнды являются либо входными, либо выходными параметрами и в-третьих: для записи текста программы достаточно двух операторов (описания заголовка процедуры-функции и присваивания значения)) V* = n* log2 n* (5) где n2* - общее число входных и выходных параметров. уровень качества программы (в условных единицах, если n2*=2) L = V*/ V (6) Исходным для введения этой характеристики является предположение о том, что при снижении стилистического качества программирования уменьшается содержательная нагрузка на каждый компонент программы и, как следствие, расширяется объем реализации исходного алгоритма. Учитывая это, можно оценить качество программирования на основании степени расширения текста относительно потенциального объема V*. Очевидно, для идеальной программы L=1, а для реальной - всегда L<1. Нередко целесообразно определить уровень программы, не прибегая к оценке ее теоретического объема, поскольку список параметров программы часто зависит от реализации и может быть искусственно расширен. Это приводит к увеличению метрической характеристики качества программирования. М. Холстед предлагает аппроксимировать эту оценку выражением, включающим только фактические параметры, т. е. параметры реальной программы: L* = 2 n2 / (n1 N2) уровень языка - это коэффициент пропорциональности изменения объема программы при переводе с одного языка на другой так, что обеспечивается постоянство произведения уровня программы на потенциальный объем. =L V* (7) интеллектуальное содержание программы (инвариантное по отношению к используемым языкам реализации, в условных единицах) I=L* V (8) Преобразуя выражение (8) с учетом (6), получаем I = L* V = LV = V*V/V = V*. Эквивалентность I и V* свидетельствует о том, что мы имеем дело с характеристикой информативности программы. Введение характеристики I позволяет определить умственные затраты на создание программы. Процесс создания программы условно можно представить как ряд операций: осмысление предложения известного алгоритма; запись предложения алгоритма в терминах используемого языка программирования, т. е. поиск в словаре языка соответствующей инструкции, ее смысловое наполнение и запись. Используя эту формализацию в методике Холстеда, можно сказать, что написание программы по заранее известному алгоритму есть N^-кратная выборка операторов и операндов из словаря программы n, причем число сравнений (по аналогии с алгоритмами сортировки) составит log2(n). Если учесть, что каждая выборка-сравнение содержит, в свою очередь, ряд мысленных элементарных решений, то можно поставить в соответствие содержательной нагрузке каждой конструкции программы сложность и число этих элементарных решений. Количественно это можно характеризовать с помощью характеристики L, поскольку 1/L имеет смысл рассматривать как средний коэффициент сложности, влияющий на скорость выборки для данной программы. Следовательно можно рассчитать оценку необходимых интеллектуальных усилий. оценка интеллектуальных усилий (в условных единицах) E = N* log2 (n / L) (9) E характеризует число требуемых элементарных решений при написании программы. Однако следует заметить, что E адекватно характеризует лишь начальные усилия по написанию программ, поскольку при построении E не учитываются отладочные работы, которые требуют интеллектуальных затрат иного характера. Суть интерпретации этой характеристики состоит в оценке не затрат на разработку программы, а затрат на восприятие готовой программы. При этом вместо теоретической длины программы N* используется ее реальная длина: E* = N log2 (n / L) Характеристика E* введена, исходя из предположения, что интеллектуальные усилия на написание и восприятие программы очень близки по своей природе. Однако если при написании программы стилистические погрешности в тексте практически не должны отражаться на интеллектуальной трудоемкости процесса, то при попытке понять такую программу их присутствие может привести к серьезным осложнениям. Эта посылка достаточно хорошо согласуется с нашими выводами относительно взаимосвязи N и N^, изложенными выше. Преобразуя формулу (9) с учетом выражений (4) и (6), получаем E = V V / V* Такое представление E', а соответственно и E, так как E=E', наглядно иллюстрирует целесообразность разбиения программ на отдельные модули, поскольку интеллектуальные затраты оказываются пропорциональными квадрату объема программы, который всегда больше суммы квадратов объемов отдельных модулей. время на программирование (в условных единицах) T = E/S, (10) или Т(n1N2log2n(n1log2n1+n2log2n2))/(2n2S), (11) где S - число Страуда (5 Число Страуда Холстед принял равным 18 - число умственных операций в единицу времени. Потенциальный объем программы является мерой минимально необходимого объема программы с заданным словарем. При этом потенциальный объем не зависит от языка реализации. При переводе программы с одного языка на другой потенциальный объем не меняется, но действительный объем V или увеличивается, или уменьшается в зависимости от языка реализации. Используя выражение для потенциального объема программы, Холстедом получены следующие метрики: Число Страуда S определяется как число «страудовских моментов» в секунду. «Страудовский момент» - это время, необходимое человеку для выполнения элементарного различения объектов, подобно различению кадров фильма. Страуд обнаружил, что человек способен различать от 5 до 20 объектов в секунду. Уровень программы L1 характеризует эффективность реализации алгоритма относительно затрат памяти. Только для наиболее сжатой формы реализации алгоритма (V=V*) уровень программы имеет значение 1. Всем другим вариантам реализации соответствуют значения L<1. Интеллектуальное содержание характеризует меру «сказанного» в программе, или ее «информативность». Интеллектуальное содержание (уровень) программы сильно коррелирует с потенциальным объемом (LV*) и тоже не зависит от языка реализации. Работа по программированию (уравнение мысленной работы) характеризует величину умственной работы, связанной с написанием программного кода. Так как сумма квадратов двух величин всегда меньше квадрата их суммы, уравнение работы дает основание для разбиения программы на составные части - модули. Модульность снижает работу по программированию. Исследования возможностей оперативного мышления человека дают основания считать, что наиболее продуктивна ситуация, при которой для получения одного результата используется не более пяти объектов. В прикладном отношении этот результат называют гипотезой о «шести объектах». Для определения количества модулей M в программе Холстед рекомендует использовать выражение M= n2*/6, (12) где n2* - общее количество входных и выходных переменных в программе. Из уравнения работы получено следующее уравнение ошибок в программе B=LE/E0, (13) где В - количество ошибок в программе, Е0 - среднее число элементарных отличий между возможными ошибками программирования. Используя преобразованное уравнение работы Е= (V*)3/2, (14) значение уровня английского языка (=2,16) в качестве аналога языка программирования и гипотезу о «шести объектах» идеальной по затратам памяти программы (n1=n1*=2, n2=n2*=6), Холстед вывел следующее уравнение для прогноза количества ошибок в программе: В=Е 2/3 /3000, (15) или В=V/3000, (16) где V - объем программы. Кроме своего прямого назначения в практическом отношении метрики длины программы (3) и длины реализации (2) можно использовать для выявления несовершенств программирования. Если расчеты длины программы и длины реализации отличаются более чем на десять процентов, то это свидетельствует о возможном наличии в программе следующих шести классов несовершенств: Наличие последовательности дополняющих друг друга операторов к одному и тому же операнду, например, А+C-А. Наличие неоднозначных операндов, например, A=D и A=С. Наличие синонимичных операндов, например, А=В и Т=В. Наличие общих подвыражений, например (А+В)С+D(А+В). Ненужное присваивание, например С=А+В, если переменная С используется в программе только один раз. Наличие выражений, которые не представлены в свернутом виде как произведение множителей, например XX+2XY+YY не представлено как (X+Y)(X+Y). Длину реализации N (2) можно использовать для прогноза числа фактических машинных команд P с помощью выражения  (17)или более грубо, с помощью неравенства 2P N 4P. (18) Уравнение работы (9) можно использовать для оценки экономической эффективности использования того или иного языка программирования. Относительное сокращение работы по программированию в зависимости от уровня языка используют как показатель эффективности внедрения языка программирования в производственную практику. Уровень программы 0L1 можно использовать для оценки сложности вариантов реализации заданного алгоритма D (чем меньше затрат памяти, тем сложнее вариант программы):  (19)Отметим, что уровень программы играет двойственную роль в оценке трудности или легкости ее понимания . Специалист, который хорошо знает язык программирования, поймет программу тем быстрее, чем меньше ее объем, то есть выше уровень. Но для человека, менее разбирающегося в программировании, требуется больший объем и меньший уровень. Установлено, что для любого алгоритма, описанного разными языками, с увеличением объема программы V уровень программы L уменьшается в той же пропорции. Поэтому произведение уровня программы на объем является постоянной величиной, равной потенциальному объему реализации данного алгоритма. L V = V* = const. (20) Вместе с тем, если язык не меняется, а меняется только алгоритм, то для любого языка произведение потенциального объема на уровень программы остается постоянной величиной, равной уровню языка [14] L V = = const. (21) 1.3.6 Метрики цикломатической сложности по Мак-Кейбу Показатель цикломатической сложности является одним из наиболее распространенных показателей оценки сложности программных проектов. Данный показатель был разработан ученым Мак-Кейбом в 1976 г., относится к группе показателей оценки сложности потока управления программой и вычисляется на основе графа управляющей логики программы (control flow graph). Данный граф строится в виде ориентированного графа, в котором вычислительные операторы или выражения представляются в виде узлов, а передача управления между узлами - в виде дуг. Показатель цикломатической сложности позволяет не только произвести оценку трудоемкости реализации отдельных элементов программного проекта и скорректировать общие показатели оценки длительности и стоимости проекта, но и оценить связанные риски и принять необходимые управленческие решения. Для вычисления цикломатического числа Мак-Кейба (G) применяется формула: (G) = m - n + 2p, где m - число дуг ориентированного графа G; n - число вершин; p - число компонентов связности графа. Мак-Кейб использует следующую теорему: в сильно связанном графе G цикломатическое число равно максимальному числу линейно-независимых циклов. Применяя эту теорему, число компонентов связности графа можно рассматривать как количество дуг, которые необходимо добавить для преобразования графа в сильно связный. Сильно связным называется граф, любые две вершины которого взаимно достижимы. Для графов корректных программ, т. е. графов, не имеющих недостижимых от точки входа участков и "висячих" точек входа и выхода, сильно связный граф, как правило, получается путем замыкания дугой вершины, обозначающей конец программы, на вершину, обозначающую точку входа в эту программу. Упрощенная формула вычисления цикломатической сложности представляется следующим образом: (G) = m - n + 2 Как правило, при вычислении цикломатической сложности логические операторы не учитываются. В процессе автоматизированного вычисления показателя цикломатической сложности, как правило, применяется упрощенный подход, в соответствии с которым построение графа не осуществляется, а вычисление показателя производится на основании подсчета числа операторов управляющей логики (if, switch и т.д.) и возможного количества путей исполнения программы. Общий подход состоит в оценке сложности программы с помощью вычисления числа линейно-независимых путей, цикломатической сложности (G), а также управления размером программ с помощью ограничения (G) и использования (G) как основы для методологии тестирования. Мак-Кейб обнаружил, что разумной верхней границей для цикломатической сложности является 10. Если программисты переступают эту границу, им следует или переписать программу, или разбить ее на модули. В физическом смысле цикломатическое число для каждой дуги m=(v, u)| mM графа управления первая вершина (v) является исходной, а вторая (u) – конечной. Путь от одной вершины к другой вершине графа, если он состоит более чем из одной дуги, описывают последовательностью вершин соответствующих дуг (v, а,…, u) так, что исходная вершина будет первой в перечислении, а конечная – последней. Контур – это плоскость, ограниченная циклическим путем, в котором начальная и конечная вершина графа совпадают. Каждому контуру соответствует ограничивающий его путь, ведущий из начальной вершины графа в конечную. Цикломатическое число определяет количество независимых контуров в полносвязном графе и, как следствие, количество различных путей, ведущих из начальной вершины в конечную. В практическом аспекте цикломатическое число является мерой сложности программы и определяет количество тестов, достаточных для тестирования по критерию покрытия всех ветвей программы. При оценке сложности программы с использованием цикломатического числа Мак-кейба действует следующее правило: если цикломатическое число больше десяти, программа обладает излишней сложностью и ее следует разбить на составные части (независимые модули или подпрограммы) с меньшим значением цикломатического числа. Показатель цикломатической сложности может быть рассчитан для модуля, метода и других структурных единиц программы. Оценка цикломатической сложности Мак-Кейба полезна при подготовке тестовых данных и может дать нужную информацию о логической сложности программы. Однако при такой оценке не принимается во внимание выбор структур данных, алгоритмов, мнемонических имен переменных или комментариев, отсутствует обсуждение таких важных понятий, как удобство переноса, гибкость, эффективность. Вычисление метрики в ходе реализации проекта (а при детальном проектировании оно возможно еще на этом этапе, не дожидаясь стадии кодирования) позволяет своевременно определить наиболее сложные, сопровождающиеся высокими рисками, структурные единицы и принять меры по устранению рисков за счет внесения корректив. Рассмотрим пример. Пусть имеется программа, которая считывает из входного потока символы до тех пор, пока не будет обнаружен символ «#». Текст программы на языке Паскаль представлен на рис 6. Соответствующий граф управления программы показан на рис 7.  Рис 6. Программа ввода данных Для представления программы в виде графа требуются определенные соглашения о том, что считать узлом графа, так как синтаксис операторов в языках программирования довольно разнообразен. При этом обычно учитывают только исполнимые операторы, исключая операторы описания данных. Желательно подобрать такие синтаксические формы операторов, которые в наибольшей степени подходят для отображения узлом графа. Линейные участки программы можно заменить одним узлом графа. В этом отношении использование схем алгоритмов или описание программ на псевдокоде может оказаться даже более предпочтительной формой описания программы, чем текст на языке программирования. В любом случае желательно преобразовать операторы цикла в эквивалентную последовательность операторов ветвления, добавив, при необходимости, операторы суммирования (счетчики) числа повторений цикла с «верхним» или «нижним» окончанием.  Рис 7. Граф управления программы ввода данных  Рис 8. Преобразование графа управления программы ввода данных в полносвязный граф Определим цикломатическое число Маккейба для графа управления программы, изображенного на рис 7. Количество ребер графа равно пяти, количество вершин тоже равно пяти, поэтому цикломатическое число равно: (G)=5-5+2=2 Программа организации ввода данных, имеющая граф управления с цикломатическим числом, равным 2, не обладает излишней сложностью и для ее тестирования достаточно подобрать два теста, покрывающие ветви (а, b, с) и (а, u) (рис 4). Заметим, что вершины v и а графа управления программы можно объединить, что не приведет к изменению цикломатического числа. Цикломатическое число зависит только от количества управляющих операторов, содержащих условные выражения (предикаты). При этом сложность предиката не учитывается. Если в операторе цикла while программы организации ввода данных (рис 4) усложнить условное выражение (предикат), изменив заголовок while(s<>'#') на while(s<>'#' or s<>'*') граф управления и цикломатическое число останутся прежними. Если программа содержит только операторы ветвления (без операторов выбора и переключения), цикломатическое число можно определить, используя выражение M=u+1, где u – количество операторов ветвления. При необходимости операторы выбора или переключения с n ветвями, можно рассматривать как n операторов ветвления. К достоинствам меры относят простоту ее вычисления и повторяемость результата, а также наглядность и содержательность интерпретации. В качестве недостатков можно отметить: нечувствительность к размеру ПО, нечувствительность к изменению структуры ПО, отсутствие корреляции со структурированностью ПО, отсутствие различия между конструкциями Развилка и Цикл, отсутствие чувствительности к вложенности циклов. Недостатки цикломатической меры привело к появлению ее модификаций, а также принципиально иных мер сложности. Модификации показателя цикломатической сложности: «Модифицированная» цикломатическая сложность - рассматривает не каждое ветвление оператора множественного выбора (switch), а весь оператор как единое целое. «Строгая» цикломатическая сложность - включает логические операторы. «Упрощенная» вычисление цикломатической сложности - предусматривает вычисление не на основе графа, а на основе подсчета управляющих операторов. «актуальная» сложность - определяется как число независимых путей, которые проходит программа при тестировании; метрика сложности глобальных данных - вычисляется как цикломатическая сложность модуля и увеличивается на количество взаимосвязей с глобальными данными. 1.3.7 Метрики Чепина Существует несколько ее модификаций. Рассмотрим более простой, а с точки зрения практического использования - достаточно эффективный вариант этой метрики. Суть метода состоит в оценке информационной прочности отдельно взятого программного модуля с помощью анализа характера использования переменных из списка ввода-вывода. Все множество переменных, составляющих список ввода-вывода, разбивается на четыре функциональные группы. Множество «Р» - вводимые переменные для расчетов и для обеспечения вывода. Примером может служить используемая в программах лексического анализатора переменная, содержащая строку исходного текста программы, то есть сама переменная не модифицируется, а только содержит исходную информацию. Множество «М» - модифицируемые или создаваемые внутри программы переменные. Множество «C» - переменные, участвующие в управлении работой программного модуля (управляющие переменные). Множество «Т» - не используемые в программе (“паразитные”) переменные. Поскольку каждая переменная может выполнять одновременно несколько функций, необходимо учитывать ее в каждой соответствующей функциональной группе. Далее вводится значение метрики Чепина: 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 дней в неделю. Легко добавлять новые возможности. Удовлетворяет потребности пользователей. Хорошо документировано. Все это действительно имеет непосредственное отношение к качеству ПО. Но эти ответы выделяют характеристики, важные для конкретного пользователя, разработчика или группы таких лиц. Для того чтобы удовлетворить потребности всех сторон (конечных пользователей, заказчиков, разработчиков, администраторов систем, в которых оно будет работать, регулирующих организаций и пр.), для достижения прочного положения разрабатываемого ПО на рынке и повышения потенциала его развития необходим учет всей совокупности характеристик ПО, важных для всех заинтересованных лиц. Приведенные выше ответы показывают, что качество ПО может быть описано большим набором разнородных характеристик. Такой подход к описанию сложных понятий называется холистическим (от греческого слова όλος, целое). Он не дает единой концептуальной основы для рассмотрения затрагиваемых вопросов, какую дает целостная система представлений (например, механика Ньютона в физике или классическая теория вычислимости на основе машин Тьюринга), но позволяет, по крайней мере, не упустить ничего существенного. Что делает программу высококачественной: Шломи Фиш (Shlomi Fish) проанализировал факторы определяющие высокое качество программного обеспечения: Программа должна часто обновляться и быть всегда доступна для скачивания или покупки. Должно быть легко узнать номер версии. Лучше если номер версии можно узнать без установки и запуска из пути для скачивания и из имени архива или из имени папки установки. Код программы должен быть открытым, лучше если лицензия позволяет свободное использование кода. Программа не должна требовать существенной настройки или дополнительного обучения (изменения привычек). Программа должна иметь качественную веб-страницу, где легко найти всю необходимую информацию. Программа не должна быть сложной в компиляции и запуске, не должна использовать особенности компиляторов и должна иметь немного зависимостей. Должны быть легко доступны готовые собранные пакеты или должно быть легко их собрать. Программа должна быть хорошо документирована. Программа должна быть переносимой (работать на как можно большем количестве распространенных платформ). Высококачественная программа должна быть безопасна - это означает что должно быть немного проблем с безопасностью и баги должны исправляться быстро. При выходе новых версий должна сохраняться совместимость со старыми. Высококачественная программа имеет хорошие пути поддержки пользователей - почтовые рассылки, IRC, техподдержку по email, форумы, wiki. Программа должна быть быстрой и не должна потреблять много ресурсов. И конечно же высококачественная программа должна быть эстетичной и не перегружать пользователя излишней информацией. Как сделать программу высококачественной? Код программы должен быть модульным и хорошо написанным. В разработке должны использоваться автоматические тесты, лучше если тест пишется до начала написания тестируемого кода. Нужно иметь хороший контакт с сообществом пользователей, которые будут тестировать бета-версии и предлагать улучшения. Релизы должны быть частыми. Управление проектом должно быть объективным и дальновидным. Слишком навязчивая реклама вредна, и совершенно недопустима неправдивая реклама. И последнее: хорошее название программы важно. Качество ПО по МакКолу Первой широко известной моделью качества ПО стала предложенная в 1977 МакКолом. В ней характеристики качества разделены на три группы Факторы (factors), описывающие ПО с позиций пользователя и задаваемые требованиями. Критерии (criteria), описывающие ПО с позиций разработчика и задаваемые как цели. Метрики (metrics), используемые для количественного описания и измерения качества. Факторы качества, которых было выделено 11, группируются в три группы по различным способам работы людей с ПО. Полученная структура изображается в виде треугольника МакКола.  Рис. 9. Треугольник МакКола. Критерии качества - это числовые уровни факторов, поставленные в качестве целей при разработке. Объективно оценить или измерить факторы качества непосредственно довольно трудно. Поэтому, МакКол ввел метрики качества, которые с его точки зрения легче измерять и оценивать. Оценки в его шкале принимают значения от 0 до 10. Вот эти метрики качества: Удобство проверки на соответствие стандартам (auditability) Точность управления и вычислений (accuracy) Степень стандартности интерфейсов (communication commonality) Функциональная полнота (completeness) Однородность используемых правил проектирования и документации (consistency) Степень стандартности форматов данных (data commonality) Устойчивость к ошибкам (error tolerance) Эффективность работы (execution efficiency) Расширяемость (expandability) Широта области потенциального использования (generality) Независимость от аппаратной платформы (hardware independence) Полнота протоколирования ошибок и других событий (instrumentation) Модульность (modularity) Удобство работы (operability) Защищенность (security) Самодокументированность (selfdocumentation) Простота работы (simplicity) Независимость от программной платформы (software system independence) Возможность соотнесения проекта с требованиями (traceability) Удобство обучения (training) Каждая метрика влияет на оценку нескольких факторов качества. Числовое выражение фактора представляет собой линейную комбинацию значений влияющих на него метрик. Коэффициенты этого выражения определяются по-разному для разных организаций, команд разработки, видов ПО, используемых процессов и т.п. Качество ПО по Боему В 1978 Боем предложил свою модель, по существу представляющую собой расширение модели МакКола. Атрибуты качества подразделяются по способу использования ПО (primary use). Определено 19 промежуточных атрибутов (intermediate construct), включающих все 11 факторов качества по МакКолу. Промежуточные атрибуты разделяются на примитивные (primitive construct), которые, в свою очередь, могут быть оценены на основе метрик. В дополнение к факторам МакКола атрибуты качества по Боему включают следующие: ясность (clarity), удобство внесения изменений (modifiability), документированность (documentation), способность к восстановлению функций (resilience), понятность (understandability), адекватность (validity), функциональность (functionality), универсальность (generality), экономическая эффективность (economy). [13] 1.5 Оценка результата Оценка результата программных проектов - задача весьма сложная. Зачастую какие-то показатели нужны еще до начала работ, чтобы спланировать будущие расходы, другие используются для определения размера вознаграждения за уже выполненный труд. Наука не стоит на месте и предлагает все новые подходы к решению этой задачи, однако до сих пор нет надежной универсальной методики, дающей гарантированный результат. Поэтому в большинстве случаев приходится опробовать различные методы. 1.5.1 Линейный подход В простейшем случае определить стоимость разработки ПО можно исходя из количественной оценки трудозатрат Т (в неких единицах, например человеко-месяцах или человеко-часах) и их удельной стоимости Ц: С = Т × Ц. Цена одной единицы трудозатрат для индустрии разработки ПО формируется, в основном, исходя из заработной платы и связанных с ней начислений. Как правило, другие составляющие имеют гораздо меньший удельный вес, и ими зачастую можно пренебречь. Что касается самих трудозатрат, то их достоверное вычисление в сфере интеллектуальной деятельности, к которой, несомненно, относится разработка ПО, выполнить достаточно сложно. Простейший подход может быть основан на следующей линейной формуле: Т = Р × П, где Р - размер исходного кода ПО; П - временная производительность. Эта примитивная формула активно применяется и по сей день, хотя ее несостоятельность была установлена довольно давно. Пожалуй, самой известной работой, в которой критикуется данный подход, является выдержавшая более двадцати изданий по-настоящему классическая книга Фредерика Брукса (Frederick Brooks) «Мифический человеко-месяц, или Как создаются программные системы», впервые увидевшая свет еще в 1977 г. По мнению Брукса, «...наши методы оценки ошибочно путают достигнутый прогресс с затраченными усилиями...». В первую очередь, это утверждение касается способа, которым измеряется результат, - на заре программирования не было найдено ничего лучшего, чем использование в этих целях количества строк кода. Об абсурдности такого показателя для оценки программного проекта сказано очень много, что, впрочем, вовсе не означает, что он не применяется сегодня. С ростом мастерства программист обычно делается «лаконичнее», т. е. выдаваемый им код для решения одних и тех же задач становится все компактнее, а это означает, что его проще и дешевле отлаживать и сопровождать. Однако вышеуказанная формула вовсе не стимулирует данного процесса. 1.5.2 Оценка с использованием эмпирических данных Несмотря на определенные достижения рассмотренных методов при оценке трудоемкости реализации программных проектов, опытный менеджер скажет, что лучший способ узнать длину пути - это пройти его. Действительно, ничто не вселяет в нас больше уверенности, чем прошлый опыт. SLIM. Вернемся к нашей линейной формуле определения трудозатрат - как мы уже говорили, она была признана несостоятельной, но если ранее мы сомневались только в способе исчисления размера ПО, то теперь задумаемся о ее линейном характере. О том, что трудоемкость и, соответственно, стоимость программного проекта нелинейно зависит от объема работ, было известно еще в 1970-х годах, когда появились первые научные публикации, подкрепленные результатами серьезных исследований. Вероятно, первой нелинейной моделью, использующей эмпирические данные и нашедшей практическое применение при оценке стоимости ПО, стала SLIM (Software Life-cycle Model), предложенная в 1978 г. Лоуренсом Патнамом (Lawrence Putnam). Согласно ей трудоемкость вычисляется по следующей формуле:  Размер проекта (P) чаще всего исчисляется в количестве строк кода, хотя известны случаи успешного применения модели и для других единиц, например функциональных точек. C - фактор среды, некая технологическая константа, учитывающая, помимо уровня технологий, также и производительность персонала, которая может различаться от команд к команде. td - ограничение на срок поставки (в годах). SLIM была создана на базе реальных данных, собранных в Министерстве обороны США, и ориентирована в первую очередь на крупные проекты. Несмотря на возможность калибровки модели на основе хронологической информации, что несколько повышает качество результатов, она не приобрела широкой популярности, хотя существуют организации, успешно использующие ее в проектном менеджменте и сегодня (qsm.com). COCOMO. Пожалуй, самой популярной моделью для оценки стоимости разработки ПО, которая стала стандартом, является COCOMO (COnstructive COst MOdel). Она была представлена в 1981 г. Барри Боэмом (Barry Boehm), известным ученым, внесшим огромный вклад в развитие научных подходов к управлению программными проектами - им разработаны спиральная модель проектирования ПО и Wideband Delphi, кроме того, когда-то именно он предсказал, что в будущем стоимость ПО превысит стоимость оборудования. COCOMO создана на основе анализа статистических данных 63 проектов различных типов. Фактически под общим названием скрываются три уровня детализации: базовый, промежуточный и подробный. Также предусмотрено три режима использования модели в зависимости от размеров команды и проекта (табл. 1). Режимы модели COCOMO Таблица 3.
Для оценки трудозатрат на базовом уровне модели COCOMO применяется следующая формула: Т = a × Р b, где a и b - константы, которые зависят от режима использования модели. В соответствии с этой формулой трудозатраты вообще нелинейно зависят от размера проекта и скачкообразно изменяются при смене режима (табл. 2). Другая интересная особенность COCOMO - рост трудозатрат при переходе к более высокому режиму не означает безусловного увеличения длительности (F) выполнения проекта, которая вычисляется по формуле: F = 2,5 × Т k, поскольку при этом изменяется значение константы k. Значения коэффициентов модели COCOMO в зависимости от режима использования Таблица 4
На более высоких уровнях COCOMO рассмотренные формулы усложняются, они обрастают дополнительными коэффициентами, позволяющими повысить точность оценок. Также модель допускает калибровку на основе хронологических данных по выполненным проектам. COCOMO II. Сегодня оригинальная COCOMO уже считается устаревшей. Ей на смену пришла COCOMO II, представленная в 1997 г. Хотя она и имеет много общего со своей предшественницей, однако во многом основана на новых идеях, а также адаптирована к современным методологиям разработки ПО (в частности, если COCOMO подразумевала только каскадную модель жизненного цикла, то COCOMO II также пригодна для спиральной и итеративной). При построении COCOMO II для обработки статистических данных использовался Байесовский анализ, который дает лучшие результаты для программных проектов, характеризующихся неполнотой и неоднозначностью, в отличие от многофакторного регрессионного, примененного в COCOMO. Также в ней допускается измерять размер проекта не только числом строк кода, но и более современными функциональными и объектными точками. Помимо прочего, при расчете показателей COCOMO II учитывает уровень зрелости процесса разработки в соответствии с моделями SEI CMM/CMMI. Как и COCOMO, COCOMO II также имеет несколько вариантов использования, однако они отличаются не столько детализацией, сколько характером - фактически это разные модели для решения разных (хотя и схожих) задач, объединенные под одним общим названием. При этом формулы для вычисления различных показателей значительно усложнились. При сохранении основных принципов модель стала намного гибче и учитывает гораздо большее число факторов, влияющих на выполнение программного проекта. [15] Модель COCOMO II фактически объединяет три различные подмодели Таблица 5
1.6 Методы контроля качества Как контролировать качество системы? Как точно узнать, что программа делает именно то, что нужно, и ничего другого? Как определить, что она достаточно надежна, переносима, удобна в использовании? Ответы на эти вопросы можно получить с помощью процессов верификации и валидации. Верификация обозначает проверку того, что ПО разработано в соответствии со всеми требованиями к нему, или что результаты очередного этапа разработки соответствуют ограничениям, сформулированным на предшествующих этапах. Валидация - это проверка того, что сам продукт правилен, т.е. подтверждение того, что он действительно удовлетворяет потребностям и ожиданиям пользователей, заказчиков и других заинтересованных сторон. Эффективность верификации и валидации, как и эффективность разработки ПО в целом, зависит от полноты и корректности формулировки требований к программному продукту. Основой любой системы обеспечения качества являются методы его обеспечения и контроля. Методы обеспечения качества представляют собой техники, гарантирующие достижение определенных показателей качества при их применении. Мы будем рассматривать подобные методы на протяжении всего курса. Методы контроля качества позволяют убедиться, что определенные характеристики качества ПО достигнуты. Сами по себе они не могут помочь их достижению, они лишь помогают определить, удалось ли получить в результате то, что хотелось, или нет, а также найти ошибки, дефекты и отклонения от требований. Методы контроля качества ПО можно классифицировать следующим образом: Методы и техники, связанные с выяснением свойств ПО во время его работы. (Это, прежде всего, все виды тестирования, а также профилирование и измерение количественных показателей качества, которые можно определить по результатам работы ПО - эффективности по времени и другим ресурсам, надежности, доступности и пр.) Методы и техники определения показателей качества на основе симуляции работы ПО с помощью моделей разного рода. (К этому виду относятся проверка на моделях (model checking), а также прототипирование (макетирование), используемое для оценки качества принимаемых решений.) Методы и техники, нацеленные на выявление нарушений формализованных правил построения исходного кода ПО, проектных моделей и документации. (К методам такого рода относится инспектирование кода, заключающееся в целенаправленном поиске определенных дефектов и нарушений требований в коде на основе набора шаблонов, автоматизированные методы поиска ошибок в коде, не основанные на его выполнении, методы проверки документации на согласованность и соответствие стандартам.) Методы и техники обычного или формализованного анализа проектной документации и исходного кода для выявления их свойств. (К этой группе относятся многочисленные методы анализа архитектуры ПО, о которых пойдет речь в следующей лекции, методы формального доказательства свойств ПО и формального анализа эффективности применяемых алгоритмов). [9] 1.7 Автоматизированные программные продукты по оценке качества ПО. Эта категория инструментов позволяет рассчитать различные метрики проекта, прежде всего на основе исходного кода и UML-диаграмм (в первую очередь прецедентов и классов), хотя в общем случае может быть использовано практически все, относящееся к проекту и поддающееся измерению (требования, спецификации, документация, активность работы с системой контроля версий, прохождение тестов и пр.). Почетное место занимают средства подсчета числа строк кода (метрики SLOC и ее производных) - их абсолютное большинство, как среди коммерческих, так и среди бесплатных продуктов, в том числе с открытым кодом. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||