метрические программы что это

Программы для обработки данных из метрических книг

г.Гатчина, Ленинградская область
Сообщений: 3380
На сайте с 2008 г.
Рейтинг: 2266

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

1. Сначала в отдельную таблицу выписываем браки из метрических книг.
Таблица вида:

ID брака (порядковый номер)
Приход
Год
Число и месяц совершения брака
Имя и отчество жениха
Откуда (из заранее составленного списка населенных пунктов)
Возраст
Примечания (заметки)
Имя и отчество невесты
Откуда
Возраст
Примечания (заметки)

Поскольку встречаются различные варианты написания имени, например, Иван и Иоанн, то можно было бы имя-отчество формировать из заранее составленных списков.

2. На основе этой таблицы составляем таблицу по первой части метрических книг (рождения).
Таблица вида:

Год
Порядковый номер мальчика //из метрической книги
Порядковый номер девочки //из метрической книги
Число и месяц
Имя и отчество (сформированное от имени отца)
Имя и отчество отца
Откуда
Имя и отчество матери
Откуда
ID брака отца и матери (из таблицы браков)

При заполнении сведений об отце и матери можно воспользоваться поиском по таблице браков и подставить нужное значение (ID брака).

Шаблон поиска при этом может быть таким:

Имя и отчество жениха (первые буквы, например, Иоанн* или И*)
Откуда (из списка населенных пунктов)
Имя и отчество невесты

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

3. Дальше можно выбрать из списка браков, например, всех, проживавших в одной деревне (по жениху или по невесте), вместе с детьми от этого брака.

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

Например, взять имя-отчество детей (вместе с местом рождения их отца) и поискать эти данные в таблице браков. При этом смотрим,чтобы возраст жениха или невесты соотносился бы с его/ее датой рождения.

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

Также можно использовать Access или Excel (или аналогичные программы из Libre Office).
Возможно, что такие программы уже есть.

—
Ссылки на каталоги с метрическими книгами приходов Псковской епархии на Яндекс-диске:
http://i-nventory.ru/index.php?id=4

Интересуют приходы Богородицкое и Дубровно (Порховский уезд)

Самара
Сообщений: 4432
На сайте с 2010 г.
Рейтинг: 2059

Источник

Метрическая теория программ. Разновидности метрик. Шкалы

Метрика – это мера, определяющая расстояние между элементами множества, которая обладает следующими свойствами:

1. Неотрицательна (>=0)

2. Нулевая при совпадении элементов

3. Симметрична (AB = BA)

4. Подчиняется закону треугольника (AB + BC > AC)

Метрика качества программ – система измерений качества программ. Эти измерения могут поводится на уровне критериев качества программ (сравнение программ по качеству) или на уровне отдельных характеристик качества.

В исследовании метрик выделяют два основных подхода:

1. Метрики оценки самого ПО (поиск метрик, характеризующих наиболее специфические свойства программ)

2. Метрики оценки технологии разработки ПО (оценка технических характеристик и факторов разработки программ)

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

1. Метрики, оценивающие отклонение от нормы характеристик исходных проектных материалов (устанавливают полноту заданных технических характеристик исходного кода);

2. Метрики, позволяющие прогнозировать качество разрабатываемого ПО;

3. Метрики, по которым принимается решение о соответствии конечного ПО заданным требованиям.

В зависимости от характеристик и особенностей применяемых метрик им ставятся в соответствие различные измерительные шкалы:

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

Например: программы можно группировать как «нетрудные для понимания», умеренно трудные для понимания», «трудные для понимания», «очень трудные для понимания».

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

Например: некоторые программы А,В,С, относятся к разряду «умеренно трудных для понимания», но программа В труднее программы А, а программа А труднее программы С.

3. Метрики интервальной шкалыпоказывают не только относительное положение программ, но и то на сколько условных единиц отстоит одна программа от другой.

Например: можно сказать: программа В труднее программы А на 10 единиц.

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

Например: можно сказать, программа В в два раза труднее программы А.

3.В настоящее время в мировой практике используется несколько сотен метрик программ. Существующие качественные оценки можно сгруппировать по 6 основным направлениям:

1. Оценка топологической и информационной сложности программ.

2. Оценка надёжности ПС, позволяющая прогнозировать отказы и отказовые ситуации.

3. Оценка производительности ПО и повышения его эффективности путем выявления ошибок проектирования.

4. Оценка уровня языковых средств и их применения.

5. Оценка трудности восприятия и понимания программных текстов, ориентированная на психологические факторы, существенные для сопровождения и модификации программ.

6. Оценка производительности труда программиста для прогнозирования сроков и этапов разработки программ.

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

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

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

Т.о., оценка размера программы – оценка по номинальной шкале.

К группе оценок размера программ можно отнести метрику Холстеда. За базу принят подсчет количества операторов и операндов, используемых в программе., т.е. также определение размера программы.

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

η₁ – число уникальных, различных операторов программы, включая символы-разделители, знаки операций, имена процедур и функций (словарь операций).

η₂ – число уникальных, различных операндов программы (словарь операндов).

N₁ – общее количество операторов в программе.

N₂ – общее количество операндов в программе.

Опираясь на эти характеристики, получаемые непосредственно при анализе исходных текстов программ, М.Холстед вводит следующие оценки:

словарь программы η = η₁ + η₂ (1)

объем программы V = Nlog₂ η (3)

Например: согласно М.Холстеду, возможное осуществление процедуры выделения простого числа могло бы выглядеть так:

где Y- массив численных значений, содержащих искомое число X.

Теоретический словарь в данном случае будет состоять из

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

Задание:

Для одной из своих программ рассчитать:

1) Реальную длину программы, (N).

2) Теоретическую длину программы, (η * )

3) Реальный объем программы, (V)

4) Потенциальный объем программы(V * ).

КОНТРОЛЬНЫЕ ВОПРОСЫ

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

2. Перечислите основные требования к критериям качества ПО.

3. Перечислите разновидности метрик, шкал. Поясните принципы двух основных подходов в исследовании метрик.

4. Как с помощью метрик сложности программ определить длину и объём программы?

ЛИТЕРАТУРА

1. Липаев В.В. Качество программного обеспечения. – М.: Финансы и статистика, 1983.

Источник

Метрики кода и практическая реализация по их сбору и анализу. Часть 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 Объектно-ориентированные метрики

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

Метрика

Описание

Взвешенная насыщенность класса 1 (Weighted Methods Per Class (WMC) Отражает относительную меру сложности класса на основе цикломатической сложности каждого его метода. Класс с более сложными методами и большим количеством методов считается более сложным. При вычислении метрики родительские классы не учитываются. Взвешенная насыщенность класса 2 (Weighted Methods Per Class (WMC2))

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

Глубина дерева наследования (Depth of inheritance tree) Длина самого длинного пути наследования, заканчивающегося на данном модуле. Чем глубже дерево наследования модуля, тем может оказаться сложнее предсказать его поведение. С другой стороны, увеличение глубины даёт больший потенциал повторного использования данным модулем поведения, определённого для классов-предков. Количество детей (Number of children) Число модулей, непосредственно наследующих данный модуль.Большие значения этой метрики указывают на широкие возможности повторного использования; при этом слишком большое значение может свидетельствовать о плохо выбранной абстракции.

Связность объектов (Coupling between objects)

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

Отклик на класс (Response For Class) Количество методов, которые могут вызываться экземплярами класса; вычисляется как сумма количества локальных методов, так и количества удаленных методов

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 содержит краткое описание метрик, не вошедших в детальное описание выше, но тем не менее даные метрики нужны и важны, просто по статистике они встречаются гораздо реже.

Также отметим, что цель этой статьи показать принцип, а не описать все возможные метрики во множестве комбинаций.

Источник

Основные направления применения метрик. Метрические шкалы.

МЕТРИКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ.

Основные понятия.

Критерии качества включают следующие характеристики : экономичность, документированность, гибкость, модульность, надёжность, обоснованность, тестируемость, ясность, точность, модифицируемость, эффективность, легкость сопровождения и т.д.

Критерий качества должен:

— численно характеризовать основную целевую функцию программы;

— обеспечивать возможность определения затрат, необходимых для достижения требуемого уровня качества, а также степени влияния на показатель качества различных внешних факторов;

— быть по возможности простым, хорошо измеримым и иметь малую дисперсию.

Для измерения характеристик и критериев качества используют метрики качества программ.

Основные направления применения метрик. Метрические шкалы.

В настоящее время в мировой практике используется несколько сотен метрик программ. Существующие качественные оценки программ можно сгруппировать по шести направлениям :

— оценки топологической и информационной сложности программ;

— оценки надежности программных систем, позволяющие прогнозировать отказовые ситуации;

— оценки производительности ПО и повышения его эффективности путем выявления ошибок проектирования;

— оценки уровня языковых средств и их применения;

— оценки трудности восприятия и понимания программных текстов, ориентированные на психологические факторы, существенные для сопровождения и модификации программ;

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

В зависимости от характеристик и особенностей применяемых метрик им ставятся в соответствие различные измерительные (метрические) шкалы.

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

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

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

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

Источник