Описание метрик Холстеда
1 Цель работы: Изучение основ метрической теории программ Холстеда, расчет количественных характеристик для индивидуального модуля.
Краткие теоретические и учебно-методические материалы по теме практической работы
Описание метрик Холстеда
Метрики Холстеда предлагают разумный подход к решению следующих задач:
-предсказание условий, необходимых для программирования по предложенным проектам;
-определение норм первоначальных ошибок;
-количественная оценка языков программирования и эффекта модульности;
-обоснование метода измерения различий между программами, написанными специалистами разного уровня.
В основе вычисления метрик Холстеда лежит концепция, согласно которой алгоритм состоит только из операторов и операндов (проверяется рассмотрением простых вычислительных машин с форматом команд, содержащим две части: код операции и адрес операнда). Операнды -переменные или константы, используемые в данной реализации алгоритма.
#2 Как изучать метрические книги?
Операторы-комбинации символов, влияющие на значение или порядок операндов.
В основе вычисляемых свойств алгоритма лежат следующие характеристики:
-n1 -число различных операторов данной реализации;
-n2 -число различных операндов данной реализации;
-N1 -общее число всех операторов;
-N2 -общее число всех операндов;
-n2*-число различных входных и выходных операндов.
На основании приведенных выше характеристик вычисляются:
-словарь n = n1 + n2;
-длина реализации N = N1 + N2.
Метрики Холстеда включают следующие характеристики:
1) Длина программы: N’= n1 * log2(n1) + n2 * log2(n2).
Если программа состоит из нескольких модулей (m -число модулей), то для каждого модуля определяется n1 среднее (n1 ср) и n2 среднее (n2 ср). В этом случае длина программы
N’ = m*(n1ср* log2(n1 cp) + n2 cp* log2(n2 cp)).
2) Объем программы: V = N * log2(n).
Такая интерпретация дает объем программы в битах. Объем зависит от языка программирования, на котором реализован алгоритм.
3) Потенциальный (минимальный) объем: V* = (2+ n2*) * log2(2+ n2*).
Минимально возможный объем предполагает существование языка, в котором действия, выполняемые индивидуальным модулем, уже определены или реализованы, возможно, в виде процедуры или функции.
4) Граничный объем: V** = (2+ (n2*)* log2(n2*)) * log2(2+ n2*).
5) Соотношения между операциями и операндами (зависимость числа операндов n2 от числа операций n1: A = n2* /(n2* +2) * log2(n2*/2)
-это частота использования операндов.
6) Уровень программы: L = V*/V,
где V* -потенциальный объем, V -объем программы.
L=1 для потенциального языка, в котором присутствует любая процедура, которая могла бы понадобиться (число таких процедур близко к бесконечности).
Альтернативное определение уровня L: L’ = (n1*) * n2/(n1*N2), где n1*=2.
8) Работа по программированию (общее число элементарных мысленных различий, требуемых для порождения программы): E=V/L или E = V 2/ V*,где Е –общее число элементарных умственных различений, требуемых для порождения программы.
Что такое МЕТРИЧЕСКИЕ КНИГИ и как их ИСКАТЬ
Это умственная работа, затрачиваемая на превращение заранее разработанного алгоритма в фактическую реализацию на языке программирования.
Правильное разбиение на модули уменьшает работу по программированию:
9) Приближенное время программирования: T’ = E/S, где S = 18 моментов (различий)/секунд
Момент -время, требуемое человеческому мозгу для выполнения элементарных различений. Альтернативное определение времени Т: Т’ = n1*N2*N*log2(n)/(2*S*n2).
10) Уровень языка: A = L * L* V.
Уровень языка определяет его производительность.
11) Уравнение ошибок:
Число переданных ошибок в программе: B = V/E0,
где E0 = V* x V* x V*/(A x A) -среднее число элементарных различений между возможными ошибками в программировании.
«Переданные ошибки» -ошибки, остающиеся после отладки модуля.
Пример программного кода:
For I=1 to 10 do
Write (‘Vvedi chislo’);
Writeln (‘MIN=’, Min);
Подсчет характеристик программы:
| Оператор | Номер | Число вхождений |
| Readln | ||
| Writeln | ||
| ; | ||
| := | ||
| Begin…end | ||
| Write | ||
| If | ||
| For | ||
| = | ||
| n1=10 | N1=23 |
| Операнд | Номер | Число вхождений |
| A | ||
| I | ||
| Min | ||
| n2=3 | N2=11 |
Длина реализации N=N1+N2=23+11=34.
Число входных и выходных операндов n2*=3.
Расчёт с помощью формул Холстеда:
1. Длина программы: N’=10*log(10) +3*log(3)=11,4
2. Объём программы: V=34*log2(13)=125.8
3. Потенциальный (минимальный) объём: V* = (2+ 3) * log2(2+ 3)=11.6
4. Граничный объем: V** = (2+ (3)* log2(3)) * log2(2+ 3)=15.7
5. Соотношения между операциями и операндами (зависимость числа операндов n2 от числа операций n1: A = 3 /(3 +2) * log2(3/2) = 0.4
B = 3-2*0.4 = 2.2
n2 = 0.4*10+2.2 = 6.2
6. Уровень программы: L = 11.6/125.8 = 0.1
8. Работа по программированию (общее число элементарных мысленных различий, требуемых для порождения программы): E=125.8/0.1 = 1258
9. Приближенное время программирования: T’ = 1258/18 = 69.9
10. Уровень языка: A = 0.1 * 0.1* 125.8 = 1.258
11. Уравнение ошибок:
Число переданных ошибок в программе: B = 125.8/9755.6 = 0.01
Е0 = 11.6 * 11.6 *11.6/(0.4 * 0.4) = 9755.6
Контрольные вопросы:
1. Где можно использовать метрики Холстеда?
В программировании для решения следующих задач:
-предсказание условий, необходимых для программирования по предложенным проектам;
-определение норм первоначальных ошибок;
-количественная оценка языков программирования и эффекта модульности;
-обоснование метода измерения различий между программами, написанными специалистами
2. Чем определяются характеристики программы?
В основе вычисления метрик Холстеда лежит концепция, согласно которой алгоритм состоит только из операторов и операндов, на анализе которых и происходит определение хар-к программ.
3. Как оценить качество реализации алгоритма по метрикам?
4. В чем недостаток программометрии?
Неэтичность: утверждается, что неэтично судить о производительности программиста по метрикам, введённым для оценки эффективности программного кода.
Замещение «управление людьми» на «управление цифрами», которые не учитывает опыт сотрудника и их другие качества.
Искажение: Процесс измерения может искажён за счёт того, что сотрудник знают об измеряемых показателях и стремятся оптимизировать эти показатели, а не свою работу.
Неточность: Нет метрик, которые были бы одновременно и значимы и достаточно точны.
Вывод: В результате выполнения данной работы была изучена тема «Оценка характеристик программ системой метрик Холстеда».
Источник: poisk-ru.ru
Роскомнадзор добился блокировки сайта за использование Google Analytics при обработке персональных данных
В конце ноября 2018 года политиком Алексеем Навальным был запущен сайт «Умное голосование», на котором был представлен способ калькуляции голосов избирателей, демонстрирующий возможность их объединения в пользу одного из кандидатов (предложенного в качестве наиболее сильного, исходя из результатов предыдущих выборов в регионах и социологических опросов) против его оппонента из политической партии «Единая Россия». Однако уже вскоре Роскомнадзором было подано исковое заявление о несоответствии данного сайта закону о персональных данных, которое 19 декабря было полностью удовлетворено Таганским районным судом.
Согласно материалам дела, сайт осуществлял сбор персонифицированной информации о пользователях, с чем сами пользователи соглашались путем проставления «галочки» в всплывающем уведомлении. При этом, согласно заявленным исковым требованиям, подобное согласие не сопровождалось предоставлением какой-либо информации об операторе, целях обработки, сроках хранения, а также перечне обрабатываемых персональных данных, что является нарушением части 1 статьи 9 Федерального закона «О персональных данных».
Ведомством также было выявлено нарушение части 2 статьи 18.1 Федерального закона «О персональных данных», выразившееся в несоответствии положений Политики об обработке и защите персональных данных действительным сведениям, а именно несоответствии данных об операторе, его юридическом адресе, а также об администраторе сайта.
Кроме того, согласно представленным данным, серверы, содержащие персональные данные пользователей сайта «Умное голосование» (https://2019.vote/), находятся в компании Cloudflare, Inc., расположенной на территории США. В связи с этим суд установил, что были нарушены требования о локализации персональных данных, то есть об осуществлении сбора и хранения персональных данных граждан Российской Федерации с использованием отечественных баз данных (серверов) (часть 5 статьи 18 Федерального закона «О персональных данных»).
Наибольший интерес в данном деле представляет выявленное Роскомнадзором «нарушение ФЗ№152», связанное с использованием на сайте сервисов Google Analytics и «Яндекс.Метрика», осуществляющих обработку данных пользователей в целях мониторинга активности аудитории сайта. При этом Решение не содержит подробного описания названного «нарушения»:
Представитель истца отмечает и то, что ответчик и третьи лица используют сервисы Гугл Аналитикс и Яндекс Метрика, предназначенные для оценки посещаемости веб-сайтов и анализа поведения пользователей, их серверы также расположены на территории США, использование сервисов является действиями по сбору и обработке персональных данных, в Политике конфиденциальности интернет-ресурса https://2019.vote/ об использовании сервисов при обработке персональных данных, сведений не содержится, что также является нарушением ФЗ № 152.
Прежде всего Ведомство отмечает, что используемые ответчиком серверы Google Analytics и «Яндекс.Метрика» находятся в США. Согласно Политике Google Analytics, их серверы расположены в разных регионах, не включая Россию. При этом Политика «Яндекс.Метрики» говорит о расположении своих серверов в ЕС и России, что вообще не соответствует доводам истца.
Несмотря на неточность данных, представленных Роскомнадзором в отношении расположения серверов метрической программы «Яндекс.Метрика», сам факт того, что суд признал использование подобных сервисов нарушением требования о локализации персональных данных является весьма неоднозначным.
В связи с появлением подобной судебной практики, в случае использования метрических программ, серверы которых расположены за пределами Российской Федерации (например сервис Google Analytics), есть прямой риск признания подобного использования нарушением законодательства в области персональных данных.
Кроме того, истец также ссылался на то, что использование таких сервисов является действиями по сбору и обработке персональных данных, однако в Политике об обработке и защите персональных данных отсутствуют какие-либо сведения об использовании сайтом Google Analytics и «Яндекс.Метрика», что, по сути, является нарушением часть 2 статьи 18.1 Федерального закона «О персональных данных».
Примечательно, что метрические программы используются практически на каждом интернет-ресурсе, в частности, сервис «Яндекс.Метрика» используется на сайтах Государственной Думы и Единой России без уведомления об этом пользователей, получения их согласия на обработку персональных данных, а также в отсутствие документа, регламентирующего политику конфиденциальности.
Подводя итог, Решение Таганского районного суда города Москвы закрепило возможность блокировки интернет-сайтов, обрабатывающих данные российских граждан в связи с использованием метрических программ. В связи с такой тенденцией, администраторам доменных имен следует более настороженно отнестись к использованию подобных сервисов, а в случае их применения в целях мониторинга активности аудитории сайта, необходимо явным и конкретным образом указывать на сайте соответствующую информацию.
Источник: zakon.ru
Организационно-экономический раздел. Программометрика.
Метрическая теория программ — программометрика — это научное и прикладное направление, возникшее в информатике около 30 лет назад. Программометрика позволяет решать следующие задачи:
· количественный анализ возможности и целесообразности разработки автоматизированных процедур и функций информационных систем (ИС) в заданной постановке;
· численная оценка основных параметров (объем, количество модулей, уровней иерархии, надежность в начальный период эксплуатации) будущих программных средств (ПС) на основе постановки задачи;
· планирование и управление разработкой ПС, оценка трудоемкости его создания, технико-экономическое обоснование;
· решение некоторых вопросов, связанных с метрологией качества ПС.
Наиболее разработанной и проверенной на практике является объемная метрика Холстеда. Холстед теоретически получил соотношение, связывающее размер словаря программы h и ее длину N:
(4.1)
Дальнейший расчет метрических характеристик производится по метрике Холстеда, изложенной в [1].
4.2. Основные метрические характеристики
h — число слов в словаре программы. Словарь программы состоит из h1 операторов и h2 операндов. Размер словаря программы h = h1 + h2. К словарю операторов относят имена арифметических и логических операций, присваивания, условных и безусловных переходов, разделители, скобки, имена процедур и функций и т.п. Словарь операндов — это множество имен переменных, которое должно обрабатывать проектируемое ПС.
— длина программы. Это математическое ожидание количества слов в тексте программы при фиксированном словаре. Длина программы — исходная величина для расчета остальных метрических характеристик программы. Т.к. h = h1 + h2, то 
. Можно утверждать, что 
, тогда
(4.2)
— количество имен входных и выходных переменных, представленных в предельно краткой записи. Это основной исходный параметр, на котором базируются все расчеты метрических характеристик будущего ПС. Тогда в соответствии с соотношением (4.1)
(4.3)
k — число модулей. Наименьшее количество ошибок обнаруживается в модулях с числом входных переменных . Тогда оптимальное число модулей ПС находим по формуле:
(4.4)
В этом случае число входных переменных одного модуля . Тогда выражение для длины программы будет иметь вид:
, (4.5)
где — длина одного модуля, найденная по формуле (4.2).
V — объем программы. Измеряется числом двоичных разрядов.
(4.6)
Календарное время программирования определяется по формуле:
(4.7)
где n — количество программистов,
v — заданная производительность труда, которая составляет от 5 до 30 отлаженных команд ассемблера за рабочий день,
— количество команд ассемблера в ПС из N слов.
Начальное количество ошибок (перед комплексной отладкой):
(4.8)
Надежность ПС оценивается средним временем проявления ошибок 
. 
(4.9)
где t — период отладки в пределах календарного времени разработки. Исходя из практического опыта, его определяют из неравенства
(4.10)
4.3. Расчет метрических характеристик
4.3.1 Рассматриваемые процедуры
Translate — анализа строки запроса;
Select — передача запроса в базу данных и обработка полученных результатов;
Value — определение типа значения, содержащегося в строке;
Equal — эквивалентность нечетких значений;
DeleteFuzzyObjectList — удаляет требуемый элемент из списка нечетких объектов базы данных.
4.3.2 Пример расчет метрических характеристик
Процедура Translate.
Входные параметры:
1. Анализируемая строка запроса
Выходные параметры:
2. Модифицированная строка запроса
3. Список нечетких условий
4. Индекс типа запроса
Структурные параметры ПС:
Количество имен входных и выходных переменных
Источник: vunivere.ru
Метрики качества программного обеспечения
В настоящее время в программной инженерии еще не сформировалась окончательно система метрик. Действуют разные подходы и методы определения их набора и методов измерения [6–8, 14, 15].
Система измерения ПО включает метрики и модели измерений, которые используются для количественной оценки его качества.
При определении требований к ПО задаются соответствующие им внешние характеристики и их подхарактеристики (атрибуты), определяющие разные стороны функционирования и управления продуктом в заданной среде. Для набора характеристик качества ПО, заданных в требованиях, определяются соответствующие метрики, модели их оценки и диапазон значений мер для измерения отдельных атрибутов качества.
Согласно стандарта [1] метрики определяются по модели измерения атрибутов ПО на всех этапах ЖЦ (промежуточная, внутренняя метрика) и особенно на этапе тестирования или функционирования (внешние метрики) продукта.
Остановимся на классификации метрик ПО, правилах для проведения метрического анализа и процесса их измерения.
Типы метрик. Существует три типа метрик:
– метрики программного продукта, которые используются при измерении его характеристик – свойств;
– метрики процесса, которые используются при измерении свойства процесса, используемого для создания продукта.
Метрики программного продукта включают:
– внешние метрики, обозначающие свойства продукта, видимые пользователю;
– внутренние метрики, обозначающие свойства, видимые только команде разработчиков.
Внешние метрики продукта включают такие метрики:
– надежности продукта, которые служат для определения числа дефектов;
– функциональности, с помощью которых устанавливается наличие и правильность реализации функций в продукте;
– сопровождения, с помощью которых измеряются ресурсы продукта (скорость, память, среда);
– применимости продукта, которые способствуют определению степени доступности для изучения и использования;
– стоимости, которыми определяется стоимость созданного продукта.
Внутренние метрики продукта включают метрики:
– размера, необходимые для измерения продукта с помощью его внутренних характеристик;
– сложности, необходимые для определения сложности продукта;
– стиля, которые служат для определения подходов и технологий создания отдельных компонент продукта и его документов.
Внутренние метрики позволяют определить производительность продукта и они являются релевантными по отношению к внешним метрикам.
Внешние и внутренние метрики задаются на этапе формирования требований к ПО и являются предметом планирования способов достижения качества конечного программного продукта.
Метрики продукта часто описываются комплексом моделей для установки различных свойств и значений модели качества или для прогнозирования. Измерения проводятся, как правило, после калибровки метрик на ранних этапах проекта. Общей мерой является степень трассируемости, которая определяется числом трасс, прослеживаемых с помощью моделей сценариев (например, UML) и которыми могут быть количество:
– сценариев и действующих лиц;
– объектов, включенных в сценарий, и локализация требований к каждому сценарию;
– параметров и операций объекта и др.
Стандарт ISO/IEC 9126–2 определяет следующие типы мер:
– мера размера ПО в разных единицах измерения (число функций, строк в программе, размер дисковой памяти и др.);
– мера времени (функционирования системы, выполнения компонента и др.);
– мера усилий (производительность труда, трудоемкость и др.);
– меры учета (количество ошибок, число отказов, ответов системы и др.).
Специальной мерой может выступать уровень использования повторных компонентов и измеряется как отношение размера продукта, изготовленного из готовых компонентов, к размеру системы в целом. Данная мера используется при определении стоимости и качества ПО. Примерами метрик являются:
– общее число объектов и число повторно используемых;
– общее число операций, повторно используемых и новых операций;
– число классов, наследующих специфические операции;
– число классов, от которых зависит данный класс;
– число пользователей класса или операций и др.
При оценки общего количества некоторых величин часто используются средне статистические метрики (например, среднее число операций в классе, среднее число наследников класса или операций класса и др.).
Как правило, меры в значительной степени являются субъективными и зависят от знаний экспертов, производящих количественные оценки атрибутов компонентов программного продукта.
Примером широко используемых внешних метрик программ являются метрики Холстеда – это характеристики программ, выявляемые на основе статической структуры программы на конкретном языке программирования: число вхождений наиболее часто встречающихся операндов и операторов; длина описания программы как сумма числа вхождений всех операндов и операторов и др.
На основе этих атрибутов можно вычислить время программирования, уровень программы (структурированность и качество) и языка программирования ( абстракция средств языка и ориентации на данную проблему) и др.
Метрики процессов включают метрики:
– стоимости, определяющие затраты на создание продукта или на архитектуру проекта с учетом оригинальности, поддержки, документации разработки;
– оценки стоимости работ специалистов за человека–дни либо месяцы;
– ненадежности процесса – число не обнаруженных дефектов при проектировании;
– повторяемости, которые устанавливают степень использования повторных компонентов.
В качестве метрик процесса могут быть время разработки, число ошибок, найденных на этапе тестирования и др. Практически используются следующие метрики процесса:
– общее время разработки и отдельно время для каждой стадии;
– время модификации моделей;
– время выполнения работ на процессе;
– число найденных ошибок при инспектировании;
– стоимость проверки качества;
– стоимость процесса разработки.
Метрики использованияслужат для измерения степени удовлетворения потребностей пользователя при решении его задач. Они помогают оценить не свойства самой программы, а результаты ее эксплуатации – эксплуатационное качество. Примером может служить точность и полнота реализации задач пользователя, а также ресурсы ( трудозатраты, производительность и др.), потраченные на эффективное решение задач пользователя. Оценка требований пользователя проводится в основном с помощью внешних метрик.
Как выбрать специалиста по управлению гостиницей: Понятно, что управление гостиницей невозможно без специальных знаний. Соответственно, важна квалификация.
Почему человек чувствует себя несчастным?: Для начала определим, что такое несчастье. Несчастьем мы будем считать психологическое состояние.
Почему 1285321 студент выбрали МегаОбучалку.
Система поиска информации
Источник: megaobuchalka.ru