Что такое метрические программы
Основные направления применения метрик. Метрические шкалы.
МЕТРИКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ.
Основные понятия.
Критерии качества включают следующие характеристики : экономичность, документированность, гибкость, модульность, надёжность, обоснованность, тестируемость, ясность, точность, модифицируемость, эффективность, легкость сопровождения и т.д.
Критерий качества должен:
— численно характеризовать основную целевую функцию программы;
— обеспечивать возможность определения затрат, необходимых для достижения требуемого уровня качества, а также степени влияния на показатель качества различных внешних факторов;
— быть по возможности простым, хорошо измеримым и иметь малую дисперсию.
Для измерения характеристик и критериев качества используют метрики качества программ.
Основные направления применения метрик. Метрические шкалы.
В настоящее время в мировой практике используется несколько сотен метрик программ. Существующие качественные оценки программ можно сгруппировать по шести направлениям :
— оценки топологической и информационной сложности программ;
— оценки надежности программных систем, позволяющие прогнозировать отказовые ситуации;
— оценки производительности ПО и повышения его эффективности путем выявления ошибок проектирования;
— оценки уровня языковых средств и их применения;
— оценки трудности восприятия и понимания программных текстов, ориентированные на психологические факторы, существенные для сопровождения и модификации программ;
— оценки производительности труда программистов для прогнозирования сроков разработки программ и планирования работ по созданию программных комплексов.
В зависимости от характеристик и особенностей применяемых метрик им ставятся в соответствие различные измерительные (метрические) шкалы.
Номинальной шкале соответствуют метрики, классифицирующие программы на типы по признаку наличия или отсутствия некоторой характеристики без учета градаций.
Порядковой шкале соответствуют метрики, позволяющие ранжировать некоторое характеристики путем сравнения с опорными значениями, т.е. измерение по этой шкале фактически определяет взаимное положение конкретных программ.
Интервальной шкале соответствуют метрики, которые показывают не только относительное положение программ, но и то, как далеко они отстоят друг от друга.
Относительной шкале соответствуют метрики, позволяющие не только расположить программы определенным образом и оценить их положение относительно друг друга, но и определить, как далеко оценки отстоят от границы, начиная с которой характеристика может быть измерена.
Программы для обработки данных из метрических книг
г.Гатчина, Ленинградская область
Сообщений: 3380
На сайте с 2008 г.
Рейтинг: 2265
Поделюсь некоторыми своими соображениями по поводу обработки данных из метрических книг.
Может быть, программы с такими функциями уже есть, например, у тех же мормонов
(я сейчас не об их программе индексации пишу, а именно о «настольном» варианте программы).
1. Сначала в отдельную таблицу выписываем браки из метрических книг.
Таблица вида:
ID брака (порядковый номер)
Приход
Год
Число и месяц совершения брака
Имя и отчество жениха
Откуда (из заранее составленного списка населенных пунктов)
Возраст
Примечания (заметки)
Имя и отчество невесты
Откуда
Возраст
Примечания (заметки)
Поскольку встречаются различные варианты написания имени, например, Иван и Иоанн, то можно было бы имя-отчество формировать из заранее составленных списков.
2. На основе этой таблицы составляем таблицу по первой части метрических книг (рождения).
Таблица вида:
Год
Порядковый номер мальчика //из метрической книги
Порядковый номер девочки //из метрической книги
Число и месяц
Имя и отчество (сформированное от имени отца)
Имя и отчество отца
Откуда
Имя и отчество матери
Откуда
ID брака отца и матери (из таблицы браков)
При заполнении сведений об отце и матери можно воспользоваться поиском по таблице браков и подставить нужное значение (ID брака).
Шаблон поиска при этом может быть таким:
Имя и отчество жениха (первые буквы, например, Иоанн* или И*)
Откуда (из списка населенных пунктов)
Имя и отчество невесты
После этого у нас получается список браков и список связанных с ним рождений.
3. Дальше можно выбрать из списка браков, например, всех, проживавших в одной деревне (по жениху или по невесте), вместе с детьми от этого брака.
Построить генограммы в GenoPro и посмотреть, как все полученные данные согласуются между собой.
Например, взять имя-отчество детей (вместе с местом рождения их отца) и поискать эти данные в таблице браков. При этом смотрим,чтобы возраст жениха или невесты соотносился бы с его/ее датой рождения.
Теоретически, этот процесс можно автоматизировать так, чтобы программа сама находила бы такие соответствия и в качестве отчета рисовала бы генограммы, например, по выбранному населенному пункту.
Также можно использовать Access или Excel (или аналогичные программы из Libre Office).
Возможно, что такие программы уже есть.
—
Ссылки на каталоги с метрическими книгами приходов Псковской епархии на Яндекс-диске:
http://i-nventory.ru/index.php?id=4
Интересуют приходы Богородицкое и Дубровно (Порховский уезд)
Самара
Сообщений: 4432
На сайте с 2010 г.
Рейтинг: 2059
Роскомнадзор добился блокировки сайта за использование 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 Федерального закона «О персональных данных».
Примечательно, что метрические программы используются практически на каждом интернет-ресурсе, в частности, сервис «Яндекс.Метрика» используется на сайтах Государственной Думы и Единой России без уведомления об этом пользователей, получения их согласия на обработку персональных данных, а также в отсутствие документа, регламентирующего политику конфиденциальности.
Подводя итог, Решение Таганского районного суда города Москвы закрепило возможность блокировки интернет-сайтов, обрабатывающих данные российских граждан в связи с использованием метрических программ. В связи с такой тенденцией, администраторам доменных имен следует более настороженно отнестись к использованию подобных сервисов, а в случае их применения в целях мониторинга активности аудитории сайта, необходимо явным и конкретным образом указывать на сайте соответствующую информацию.
Метрики кода и практическая реализация по их сбору и анализу. Часть 1 – метрики
В отличие от большинства отраслей материального производства, в вопросах проектов создания ПО недопустимы простые подходы, основанные на умножении трудоемкости на среднюю производительность труда. Это вызвано, прежде всего, тем, что экономические показатели проекта нелинейно зависят от объема работ, а при вычислении трудоемкости допускается большая погрешность.
Поэтому для решения этой задачи используются комплексные и достаточно сложные методики, которые требуют высокой ответственности в применении и определенного времени на адаптацию (настройку коэффициентов).
Современные комплексные системы оценки характеристик проектов создания ПО могут быть использованы для решения следующих задач:
Оглавление
2. Метрики
Метрики сложности программ принято разделять на три основные группы:
Метрики первой группы базируются на определении количественных характеристик, связанных с размером программы, и отличаются относительной простотой. К наиболее известным метрикам данной группы относятся число операторов программы, количество строк исходного текста, набор метрик Холстеда. Метрики этой группы ориентированы на анализ исходного текста программ. Поэтому они могут использоваться для оценки сложности промежуточных продуктов разработки.
Метрики второй группы базируются на анализе управляющего графа программы. Представителем данной группы является метрика Маккейба.
Управляющий граф программы, который используют метрики данной группы, может быть построен на основе алгоритмов модулей. Поэтому метрики второй группы могут применяться для оценки сложности промежуточных продуктов разработки.
Метрики третьей группы базируются на оценке использования, конфигурации и размещения данных в программе. В первую очередь это касается глобальных переменных. К данной группе относятся метрики Чепина.
2.1 Размерно — ориентированные метрики (показатели оценки объема)
2.1.1 LOC-оценка (Lines Of Code)
Размерно-ориентированные метрики прямо измеряют программный продукт и процесс его разработки. Основываются такие метрики на LOC-оценках.
Этот вид метрик косвенно измеряет программный продукт и процесс его разработки. Вместо подсчета LOC-оценок при этом рассматривается не размер, а функциональность или полезность продукта.
Наибольшее распространение в практике создания программного обеспечения получили размерно-ориентированные метрики. В организациях, занятых разработкой программной продукции для каждого проекта принято регистрировать следующие показатели:
На основе этих данных обычно подсчитываются простые метрики для оценки производительности труда (KLOC/человеко-месяц) и качества изделия.
Эти метрики не универсальны и спорны, особенно это относится к такому показателю как LOC, который существенно зависит от используемого языка программирования.
| Пример из жизни: На наш взгляд оценка по количеству строк в коде влечёт за собой соблазн написать побольше строк, дабы взять побольше денег. Разумеется, об оптимизации в таком продукте никто уже думать не станет. Вспомним историю о том, как планетарный центр аутсорсинга — Индия, после того, как заказчики вменили им метрику LOC, на второй день показал удвоение и утроение строк кода. |
Количество строк исходного кода (Lines of Code – LOC, Source Lines of Code – SLOC) является наиболее простым и распространенным способом оценки объема работ по проекту.
Изначально данный показатель возник как способ оценки объема работы по проекту, в котором применялись языки программирования, обладающие достаточно простой структурой: «одна строка кода = одна команда языка». Также давно известно, что одну и ту же функциональность можно написать разным количеством строк, а если возьмем язык высокого уровня (С++, Java), то возможно и в одной строке написать функционал 5-6 строк – это не проблема. И это было бы полбеды: современные средства программирования сами генерируют тысячи строк кода на пустяковую операцию.
Потому метод LOC является только оценочным методом (который надо принимать к сведению, но не опираться в оценках) и никак не обязательным.
В зависимости от того, каким образом учитывается сходный код, выделяют два основных показателя SLOC:
Для метрики SLOC существует большое число производных, призванных получить отдельные показатели проекта, основными среди которых являются:
2.1.1.1 Метрика стилистики и понятности программ
Иногда важно не просто посчитать количество строк комментариев в коде и просто соотнести с логическими строчками кода, а узнать плотность комментариев. То есть код сначала был документирован хорошо, затем – плохо. Или такой вариант: шапка функции или класса документирована и комментирована, а код нет.
Fi = SIGN (Nкомм. i / Ni – 0,1)
Суть метрики проста: код разбивается на n-равные куски и для каждого из них определяется Fi
2.1.2 Итого по SLOC
Потенциальные недостатки SLOC, на которые нацелена критика:
И главное помнить: метрика SLOC не отражает трудоемкости по созданию программы
.
Согласитесь, считать трудозатраты по данной метрике глупо – необходима комплексная оценка…
2.2 Метрики сложности
Помимо показателей оценки объема работ по проекту очень важными для получения объективных оценок по проекту являются показатели оценки его сложности. Как правило, данные показатели не могут быть вычислены на самых ранних стадиях работы над проектом, поскольку требуют, как минимум, детального проектирования. Однако эти показатели очень важны для получения прогнозных оценок длительности и стоимости проекта, поскольку непосредственно определяют его трудоемкость.
2.2.1 Объектно-ориентированные метрики
В современных условиях большинство программных проектов создается на основе ОО подхода, в связи с чем существует значительное количество метрик, позволяющих получить оценку сложности объектно-ориентированных проектов.
Метрика
Описание
Мера сложности класса, основанная на том, что класс с большим числом методов, является более сложным, и что метод с большим количеством параметров также является более сложным. При вычислении метрики родительские классы не учитываются.
Связность объектов (Coupling between objects)
Количество модулей, связанных с данным модулем в роли клиента или поставщика. Чрезмерная связность говорит о слабости модульной инкапсуляции и может препятствовать повторному использованию кода.
2.2.2 Метрики Холстеда
Метрика Холстеда относится к метрикам, вычисляемым на основании анализа числа строк и синтаксических элементов исходного кода программы.
Основу метрики Холстеда составляют четыре измеряемые характеристики программы:
На основании этих характеристик рассчитываются оценки:
Показатель цикломатической сложности позволяет не только произвести оценку трудоемкости реализации отдельных элементов программного проекта и скорректировать общие показатели оценки длительности и стоимости проекта, но и оценить связанные риски и принять необходимые управленческие решения.
Упрощенная формула вычисления цикломатической сложности представляется следующим образом:
C = e – n + 2,
где e – число ребер, а n – число узлов
на графе управляющей логики.
Как правило, при вычислении цикломатической сложности логические операторы не учитываются.
В процессе автоматизированного вычисления показателя цикломатической сложности, как правило, применяется упрощенный подход, в соответствии с которым построение графа не осуществляется, а вычисление показателя производится на основании подсчета числа операторов управляющей логики (if, switch и т.д.) и возможного количества путей исполнения программы.
Показатель цикломатической сложности может быть рассчитан для модуля, метода и других структурных единиц программы.
Существует значительное количество модификаций показателя цикломатической сложности.
2.2.4 Метрики Чепина
Существует несколько ее модификаций. Рассмотрим более простой, а с точки зрения практического использования – достаточно эффективный вариант этой метрики.
Суть метода состоит в оценке информационной прочности отдельно взятого программного модуля с помощью анализа характера использования переменных из списка ввода-вывода.
Все множество переменных, составляющих список ввода-вывода, разбивается на четыре функциональные группы.
Далее вводится значение метрики Чепина:
Q = a1P + a2M + a3C + a4T, где a1, a2, a3, a4 – весовые коэффициенты.
Весовые коэффициенты использованы для отражения различного влияния на сложность программы каждой функциональной группы. По мнению автора метрики наибольший вес, равный трем, имеет функциональная группа С, так как она влияет на поток управления программы. Весовые коэффициенты остальных групп распределяются следующим образом: a1=1; a2=2; a4=0.5. Весовой коэффициент группы T не равен нулю, поскольку «паразитные» переменные не увеличивают сложности потока данных программы, но иногда затрудняют ее понимание. С учетом весовых коэффициентов выражение примет вид:
Q = P + 2M + 3C + 0.5T.
2.3 Предварительная оценка на основе статистических методов в зависимости от этапов разработки программы
При использовании интегрированных инструментальных средств у компаний, разрабатывающих типовые решения (под эту категорию попадают так называемые «инхаузеры» – компании, занимающиеся обслуживанием основного бизнеса) появляется возможность строить прогнозы сложности программ, основываясь на собранной статистике. Статистический метод хорошо подходит для решения подобных типовых задач и практически не подходит для прогноза уникальных проектов. В случае уникальных проектов применяются иные подходы, обсуждение которых находится за рамками данного материала.
Типовые задачи как из рога изобилия падают на отделы разработки из бизнеса, потому предварительная оценка сложности могла бы сильно упростить задачи планирования и управления, тем более что есть накопленная база по проектам, в которой сохранены не только окончательные результаты, но и все начальные и промежуточные.
Выделим типовые этапы в разработке программ:
Теперь попробуем рассмотреть ряд метрик, часто используемых для предварительной оценки на первых двух этапах.
2.3.1 Предварительная оценка сложности программы на этапе разработки спецификации требований к программе
Для оценки по результатам работы данного этапа может быть использована метрика прогнозируемого числа операторов Nпрогн программы:
Nпрогн =NF*Nед
Где: NF – количество функций или требований в спецификации требований к разрабатываемой программе;
Nед – единичное значение количества операторов (среднее число операторов, приходящихся на одну среднюю функцию или требование). Значение Nед — статистическое.
2.3.2 Предварительная оценка сложности на этапе определения архитектуры
Си = NI / (NF * NI ед * Ксл)
Где:
NI – общее количество переменных, передаваемых по интерфейсам между компонентами программы (также является статистической);
NIед–единичное значение количества переменных, передаваемых по интерфейсам между компонентами (среднее число передаваемых по интерфейсам переменных, приходящихся на одну среднюю функцию или требование);
Ксл – коэффициент сложности разрабатываемой программы, учитывает рост единичной сложности программы (сложности, приходящейся на одну функцию или требование спецификации требований к программе) для больших и сложных программ по сравнению со средним ПС.
2.4 Общий списочный состав метрик
Таблица 1 содержит краткое описание метрик, не вошедших в детальное описание выше, но тем не менее даные метрики нужны и важны, просто по статистике они встречаются гораздо реже.
Также отметим, что цель этой статьи показать принцип, а не описать все возможные метрики во множестве комбинаций.