Программная инженерия. Учебное пособие для магистрантов направления подготовки 09.04.02 – Информационные системы и технологии

Производительность = Длина / Затраты [тыс.LOC / чел.-мес.], Качество = Ошибки / Длина [Единиц / тыс.LOC], УдельнаяСтоимость = Стоимость / Длина [тыс.УЕ./тыс.LOC],

Документированность= СтраницДокумента/Длина [Страниц/тыс.LOC]. Достоинства размерно-ориентированных метрик: 1) широко распространены;

2) просты и легко вычисляются.

Недостатки размерно-ориентированных метрик: 1) зависимы от языка программирования; 2) требуют исходных данных, которые трудно получить на начальной стадии проекта; 3) не приспособлены к непроцедурным языкам программирования.

Функционально-ориентированные метрики

Существенным недостатком моделей, основанных на тысячах условных строк кода, как метрике размера программного комплекса, является невозможность использования их на ранних этапах разработки проекта. Видимо, одной из первых попыток отойти от данной метрики размера ПО была разработка Аланом Альбрехтом (Alan Albrecht) в середине 70-х годов метода функциональных точек с целью разработки механизма предсказания усилий, сопряженных с разработкой программных систем (опубликован в 1979 г.). В 1984 году Альбрехт усовершенствовал свой метод и с 1986 года, в котором была сформирована Международная Ассоциация Пользователей Функциональных Точек (International Function Point User Group – IFPUG), было опубликовано несколько ревизий метода.

Чарльз Саймон (Charles Symon) разработал другой, аналогичный, но несколько более логичный и использующий более современную терминологию, метод функциональных точек Mark II. В отличие от FPA IFPUG, MK II FPA использует единое понятие транзакции, имеющей вход, обработку и выход. MK II FPA принят в качестве национального стандарта Великобритании. Другими аналогичными методами являются Feature Points, разработанный Кэйперсом Джонсом (Capers Jones) и 3D Points, разработанный в компаниии Боинг (Boeing). Рассмотрим ниже подход FPA IFPUG.

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

Используется 5 информационных характеристик.

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

2)Количество внешних выводов. Подсчитываются все выводы, по которым к пользователю поступают результаты, вычисленные программным приложением.

Вэтом контексте выводы означают отчеты, экраны, распечатки, сообщения об

41

ошибках. Индивидуальные единицы данных внутри отчета отдельно не подсчитываются.

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

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

5)Количество внешних интерфейсных файлов. Подсчитываются все логические файлы из других приложений, на которые ссылается данное приложение.

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

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

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

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

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

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

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

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

42

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

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

Метрики указателей свойств (Features Points)

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

Вот системные параметры Метрики указателей свойств:

1 Передачи данных − Сколько средств связи требуется для передачи или обмена информацией с приложением или системой?

2 Распределенная обработка данных − Как обрабатываются распределенные данные и функции обработки?

3 Производительность − Нуждается ли пользователь в фиксации времени ответа или производительности?

4 Распространенность используемой конфигурации − Насколько распространена текущая аппаратная платформа, на которой будет выполняться приложение?

5 Скорость транзакций − Как часто выполняются транзакции? (каждый день, каждую неделю, каждый месяц)

6 Оперативный ввод данных − Какой процент информации надо вводить в

режиме онлайн?

7 Эффективность работы конечного пользователя − Приложение проектировалось для обеспечения эффективной работы конечного пользователя?

8 Оперативное обновление − Как много внутренних файлов обновляется в онлайновой транзакции?

9 Сложность обработки − выполняет ли приложение интенсивную логическую или математическую обработку?

10 Повторная используемость − Приложение разрабатывалось для удовлетворения требований одного или многих пользователей?

11 Легкость инсталляции − Насколько трудны преобразование и инсталляция приложения?

43

12 Легкость эксплуатации − Насколько эффективны и/или автоматизированы процедуры запуска, резервирования и восстановления?

13 Разнообразные условия размещения − была ли спроектирована, разработана и поддержана возможность инсталляции приложения в разных местах для различных организаций?

14 Простота изменений − была ли спроектирована, разработана и поддержана в приложении простота изменений?

Достоинства функционально-ориентированных метрик: 1) Не зависят от языка программирования. 2) Легко вычисляются на любой стадии проекта. Недостаток функционально-ориентированных метрик: результаты основаны на субъективных данных, используются не прямые, а косвенные измерения.

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

Количество строк программного кода зависит не только от языка программирования, но и от технологии разработки программного обеспечения, стиля оформления и др. Более точно оценить LOC можно по историческим данным для определенного типа проектов. С помощью метода оценки первого порядка можно рассчитать приблизительное время реализации проекта T. Для этого необходимо общее количество функциональных пунктов FP возвести в степень типа программы S. Для объектно-ориентированной программы средний показатель S равен 0,36, для клиент-серверной программы – 0,37, для бизнес систем – 0,39, для научной системы и публичной Интернет-системы – 0,4: T = FPS, мес.

В уточненных методиках в расчетах оценок участвуют дополнительно такие критерии (факторы) как:

−фактор персонала;

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

−навыки владением языками и инструментарием – этот пункт противоположен предыдущему;

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

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

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

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

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

−сложность продукта – этот фактор является основным в модели СОСОМО, он определяется типом создаваемой программы;

44

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

−ограничения по быстродействию – снижение времени отклика приводит к увеличению объема работ;

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

Контрольные вопросы:

1.Что такое метрика – по отношению к программе, программному продукту, их качеству?

2.Чем характеризуется спецификация требований к программному обеспечению?

3.Какие компоненты (составляющие) включает в себя набор используемых метрик?

4.Перечислите основные информационные характеристики функциональности и полезности программного продукта

5.Уточните системные параметры метрики указателей основных свойств

Литература:

Основная:

1.Лаврищева Е.М. Технология программирования и программная инженерия. Учебник для вузов. – М.: Ось-М, 2018. – 287 с.

2.Лешек А.М. Практическая программная инженерия на основе учебного примера. – Новосибирск: ЦРНС, 2017. – 254 с.

3.Черткова Е.А. Программная инженерия. Визуальное моделирование программных систем. М.: Академкнига, 2017. – 356 с.

Дополнительная:

1.Беркун С. Искусство управления IT-проектами. – СПб.: Питер, 2018. – 186

с.

2.Гайдышев И.Н. Решение научных и инженерных задач средствами Excel, VBA и C/C++. – М.: Инфра-М, 201. – 288 с.

45

РАЗДЕЛ 3 - ПРОЦЕДУРЫ И МЕХАНИЗМЫ ОЦЕНКИ КАЧЕСТВА ИНФОРМАЦИОННОГО ПРОЕКТА

3.1. Метрики сложности и надежности кода программного обеспечения

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

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

Количественные метрики

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

Кроме SLOC к количественным характеристикам относят также:

46

–количество пустых строк,

–количество комментариев,

–процент комментариев (отношение числа строк, содержащих комментарии к общему количеству строк, выраженное в процентах),

–среднее число строк для функций (классов, файлов),

–среднее число строк, содержащих исходный код для функций (классов, файлов),

–среднее число строк для модулей.

Иногда дополнительно различают оценку стилистики программы (F). Она заключается в разбиении программы на n равных фрагментов и вычислении оценки для каждого фрагмента по формуле

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

где Nкомм.i – количество комментариев в i-м фрагменте, Ni – общее количество строк кода в i-м фрагменте.

Тогда общая оценка для всей программы будет определяться следующим об-

разом: F = СУММА Fi.

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

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

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

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

Гневу руководителя не было предела – нашел бездельника! И плохо было бы программисту, если бы менеджер проекта не объяснил, что: была найдена ошибка в программе, нашел ее VIPклиент, ошибка влияет на бизнес клиента и ее нужно было срочно устранить, для этого был выбран вот этот конкретный исполнитель, который развернул стенд, залил среду клиента, подтвердил

47

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

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

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

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

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

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

Продолжая тему анализа управляющего графа программы, можно выделить еще одну подгруппу метрик – метрики Харрисона, Мейджела. Данные меры учитывает уровень вложенности и протяженность программы.

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

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

Функциональная мера (SCOPE) программы – это сумма приведенных сложностей всех вершин управляющего графа.

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

SCORT может принимать разные значения для графов с одинаковым цикломатическим числом.

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

48

(Ассемблер, Фортран). Точка пересечения возникает при выходе управления за пределы двух вершин, являющихся последовательными операторами.

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

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

Следующий класс метрик – метрики сложности потока управления данных. Метрика Чепина: суть метода состоит в оценке информационной прочности

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

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

1.P – вводимые переменные для расчетов и для обеспечения вывода,

2.M – модифицируемые, или создаваемые внутри программы переменные,

3.C – переменные, участвующие в управлении работой программного модуля (управляющие переменные),

4.T – не используемые в программе («паразитные») переменные. Поскольку каждая переменная может выполнять одновременно несколько

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

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

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

Первой из таких метрик является тестирующая М-Мера. Тестирующей мерой М называется мера сложности, удовлетворяющая следующим условиям:

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

49

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

Связанность по данным – если модули взаимодействуют через передачу параметров и при этом каждый параметр является элементарным информационным объектом. Это наиболее предпочтительный тип связанности (сцепления).

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

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

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

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

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

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

Отсутствие связанности – модули не взаимодействуют между собой. Подклассовая связанность – отношение между классом-родителем и классом-

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

потому, что ввиду обстоятельств они происходят в одно время.

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

В связи с развитием объектно-ориентированных языков программирования появился новый класс метрик, также называемый объектно-ориентированными метриками. В данной группе наиболее часто используемыми являются наборы метрик Мартина и набор метрик Чидамбера и Кемерера. Для начала рассмотрим первую подгруппу.

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

50