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

В связи с этим потребуется электродвигатель для каталки. Он должен выполнять две основные задачи перемещения в пространстве:

1. Рыскание — Поворот каталки вправо или влево. Это основное движение для вращения каталки. Оно достигается с помощью левой ручки газа влево или вправо на пульте.

2. Тангаж — это движение каталки вперед или назад. Подача вперед обычно достигается нажатием ручки газа вперед, что заставляет каталку двигаться вперед от вас. Шаг назад достигается перемещением ручки газа назад.

Материалы и методы

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

1. Пульт управления, работающий по радиоканалу. Такое устройство не предусматривает обратной связи с каталкой. С его помощью регулируют высоту и повороты при движении. Для этого на пульте установлены два отдельных джойстика. Один предназначен для уменьшения и увеличения высоты, другой — для плавного управления поворотами. Главное достоинство радиопульта в большой дальности работы, а недостаток – сигнал можно перехватить или заглушить.

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

Результаты и их обсуждение

Основные функциональные узлы электропривода следующие:

1.Сам привод – мотор, превращающий электрическую энергию в механическую (силу поворота); для снижения скорости до необходимой снабжен редуктором, передающим крутящий момент.

2.Энкодер – датчик обратной связи, преобразующий угол поворота в управляющий сигнал, контролирующий вращение выходного вала (на последнем закреплен инструмент или какой-то другой орган выполнения действия).

3.Электронная начинка, принимающая входящие параметры, считывающая и сравнивающая значения, выполняющая операции включения/выключения – это тоже то, из чего состоит сервопривод.

4.Проводка – подключение питания (два кабеля) и доставка сигнала контроля (еще один).

Принцип работы сервопривода сводится к следующему:

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

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

Основные преимущества при использовании сервопривода: помехоустойчивость и быстрый отклик объекта управления на команды.

Главные недостатки: небольшой радиус действия сигнала и его долгая настройка.

Абстрагируясь от электроприводов и возвращаясь к радиосигналам, для автономного передвижения устройства (радиоуправляемой машинки) необходимо иметь передатчик (пульт управления), приёмник (печатная плата) и комплект антенн.

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

Плата радиоуправляемой модели(машинки) состоит из трех частей: 1 радиоприемник, 2 микросхема-дешифратор, 3 Н-мост для управления двигателями.

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

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

Заключение

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

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

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

Перед тем, как приступить к исследованию, необходимо дать определение первостепенным терминам:

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

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

4.PhpMyAdmin – это бесплатный программный инструмент, написанный на PHP, предназначенный для управления администрированием MySQL через Web.

5.MySQL – это система управления реляционными базами данных с открытым исходным кодом (СУРБД), работающая по модели клиент-сервер.

6.Объектно-реляционные СУБД (ОРСУБД) – реляционные СУБД, поддерживающие некоторые технологии, реализующие объектно-ориентированный подход (объекты, классы и наследование реализованы в структуре БД и языке запросов).

7.Транзакция – последовательность операций над БД, рассматриваемых СУБД как единое целое. Инициализируется пользователем или прикладной программой.

Материалы и методы

Предположим, перед нами стоит решение трёх задач:

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

Задача 2: провести учёт кадрового состава (т. е. занести исходные данные во внешнюю память с возможностью их удаления, корректирования и добавления) во второй файл.

Задача 3: произвести учёт экономии фонда оплаты труда в связи с болезнью некоторых сотрудников. Изменения занести в третий файл.

Это типичные ситуации, возникающие в каждом отделе кадров любой организации. При этом возникают закономерные недостатки:

1.Информация дублируется. В файлах будут присутствовать поля ФИО,

ОКЛ, ПРЕМ и т.д.

2.При внесении изменений (например, фамилии) приходится вносить одно значение в разные файлы и, как следствие, тратить дополнительное время.

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

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

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

Для описания этого вида данных, собственно, и вводится новое понятие – «база данных».

Роль интерфейса между прикладными программами и БД (базой данных), обеспечивающего их независимость, играет программный комплекс – система управления базами данных (СУБД). Её архитектура должна обеспечивать разграничение пользовательского и системного уровней.

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

Говоря об архитектуре, стоит рассматривать два подхода: 2–уровневый (созданный в 1971 году рабочей группой CODASYL и состоящий из системного и пользовательского представлений) и 3–уровневый (созданный в 1978 году комитетом SPARC ANSI и состоящий из внешнего, внутреннего и концептуального уровней).

Касательно внешнего (пользовательского) уровня он относится к основному приложению, с которым взаимодействует БД в режиме реального времени. (к примеру, можно взять программу 1С). Внешнее представление – несколько внешних схем, соответствующих разным пользовательским представлениям данных. Также каждый тип пользователей может применять свой язык общения с БД. Какой бы базовый язык высокого уровня ни использовался, он должен включать в себя подъязык работы с данными (SQL).

Для БД на концептуальном уровне имеется одна концептуальная схема, которая содержит:

1.Сущности, их атрибуты и связи между сущностями.;

2.Ограничения, накладываемые на данные;

3.Семантическую информацию о данных;

4.Обеспечение поддержки целостности данных

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

Этот уровень не содержит сведений о методах хранения данных.

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

Информация, хранимая на внутреннем уровне, распределяет дисковое пространство для сохранения данных и индексов, описывает подробности сохранения записей, сведения о размещении записей, сведения о сжатии данных и выбранных методах шифрования.

Сейчас повсеместно используется трёхуровневая архитектура. Её назначение в том, чтобы низкоуровневые функции никак не влияли на высокоуровневые, в логической независимости (защищённости внешних схем от изменений в концептуальной схеме) и физической (защищенности концептуальной схемы от изменений, во внутренней схеме).

С точки зрения пользователя СУБД реализует следующие высокоуровневые функции:

1.хранение данных;

2.изменение данных;

3.обработка данных;

4.получение выходных документов.

Высокоуровневые функции, в свою очередь, используют следующие низкоуровневые функции:

1.поддержка словаря данных;

2. управление данными во внешней памяти;

3. управление буферами оперативной памяти;

4. управление транзакциями;

5.ведение журнала изменений БД;

6.поддержка целостности и безопасности данных;

7.управление параллельным доступом

Говоря про типовую организацию современной СУБД, стоит отметить два важнейших аспекта:

Ядро СУБД – программный комплекс, обеспечивающий непосредственное выполнение физических операций над БД. Основная резидентная часть СУБД. В архитектуре «клиент-сервер» – основная составляющая серверной части системы.

Среда – совокупность интерфейсных модулей, обеспечивающих связь пользователей с ядром и через него с БД. Включает пользовательские интерфейсы и утилиты администратора БД (АБД).

1. менеджер данных (управление данными во внешней памяти);

2. менеджер буферов (управление буферами оперативной памяти);

3. менеджер транзакций (управление транзакциями);

4. менеджер журнала (журнализация)

Функции компонентов взаимосвязаны. Компоненты взаимодействуют по продуманным протоколам.

Ядро СУБД имеет собственный интерфейс. Он недоступен пользователям напрямую. Используется в программах, производимых компилятором SQL, и утилитах БД.

Транзакция – последовательность операций над БД, рассматриваемых СУБД как единое целое. Инициализируется пользователем или прикладной программой. Транзакция либо успешно выполняется, и СУБД фиксирует произведенные изменения во внешней памяти, либо ни одно из этих изменений не фиксируется (происходит откат). Поддержание механизма транзакций – обязательное условие для любых СУБД (особенно важно для многопользовательских).

Затрагивая тему СУБД стоит их классифицировать:

1.Иерархические СУБД – основаны на иерархической модели. Первые СУБД, 1950–60 годов. (Information Management System фирмы IBM).

2.Сетевые СУБД – основаны на сетевой модели. Первая сетевая СУБД разработана Чарльзом Бахманом в 1960 г. (IDS – Integrated Data Store корп. General Electric).

3.Реляционные СУБД – управляют реляционными базами данных. Практически все разработчики современных приложений баз данных ориентируются на РСУБД.

4.Объектно-ориентированные СУБД – основаны на объектной модели данных (данные – объекты, наделенные свойствами и использующие методы взаимодействия с другими объектами.

5.Объектно-реляционные СУБД (ОРСУБД) – реляционные СУБД, поддерживающая некоторые технологии, реализующие объектно-ориентированный подход (объекты, классы и наследование реализованы в структуре БД и языке запросов). ОРСУБД являются широко известные Oracle Database, Informix, DB2, PostgreSQL.

Все вышеперечисленные СУБД действуют по одному большому паттерну, называемому «Big Data» – совокупности подходов, инструментов и методов обработки структурированных и неструктурированных данных огромных объемов и многообразия для получения воспринимаемых результатов, в условиях непрерывного прироста, распределения по многочисленным узлам вычислительной сети.

Определяющими характеристиками для данного паттерна являются «три V»:

1.объем (Volume) – в смысле физического объема;

2.скорость (Velocity) – в смысле скорости прироста и необходимости высокоскоростной обработки и получения результатов);

3.многообразие (Variety) – в смысле возможности одновременной обработки различных типов структурированных и полуструктурированных данных.

Результаты и их обсуждение

Родоначальником всех современных СУБД является NoSQL. Она применялась к БД, в которых делается попытка решить проблемы масштабируемости и доступности за счет атомарности и согласованности данных. На данный момент самыми распространёнными СУБД являются Oracle 12c, Microsoft sql server и MySQL. В чём же преимущества каждой из них? Какие недостатки в них обнаружены?

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

Преимущества:

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

2.Оракул является крайне надёжной, фактически это эталон надёжности среди подобных систем.

Недостатки:

1.Стоимость Oracle может оказаться непомерно высокой, особенно для небольших организаций.

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

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

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

Преимущества:

1.Распространяется бесплатно.

2.Прекрасно документирована.

3.Предлагает много функций, даже в бесплатной версии.

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

5.Поддерживает набор пользовательских интерфейсов.

6.Может работать с другими базами данных, включая DB2 и Oracle.

Недостатки:

1.Придётся потратить много времени и усилий, чтобы заставить 2. MySQL выполнять несложные задачи, хотя другие системы делают это автоматически, например: создавать инкрементные резервные копии.

2.Отсутствует встроенная поддержка XML или OLAP.

3.Для бесплатной версии доступна только платная поддержка.

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

Ещё одной из популярных СУБД является программный продукт – Microsoft SQL-сервер. Это система управления базами данных, движок которой работает на облачных серверах, а также локальных серверах, причем можно комбинировать типы применяемых серверов одновременно. Вскоре после выпуска Microsoft SQL Server 2016, Microsoft адаптировала продукт для операционной системы Linux, а на платформе Windows он работал изначально.

Преимущества:

1.Продукт очень прост в использовании.

2.Текущая версия работает быстро и стабильно.

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

4.Вы сможете получить доступ к визуализации на мобильных устройствах.

5.Он очень хорошо взаимодействует с другими продуктами Microsoft.

Недостатки:

1.Цена для юридических лиц оказывается неприемлемой для большей части организаций.

2.Даже при тщательной настройке производительности SQL Server способен задействовать все что есть.

3.Сообщается о проблемах с использованием службы интеграции для импорта файлов.

4.Есть смысл покупать лицензию на этот продукт, если уже имеется ряд программ Microsoft.

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

Заключение

Если сравнивать частоту использования реляционных баз данных на момент времени 2017 года и по настоящее время, то лидирующие позиции будут занимать MySQL и MS SQL Server. Первая – из-за того, что есть открытый исходный код СУБД и поддержка веб приложений, что очень актуально. Вторая – из-за бесплатной поддержки, частичного русификатора и интуитивно понятного интерфейса.

Актуальность разработки (цель исследования) обоснована тем, что в настоящий момент в связи с экономической политикой Российской Федерации по импортозамещению любой производящийся программно-аппаратный продукт в нашей стране может иметь какие-либо скрытые дефекты. Необходимо разработать комплекс критериев и метрик оценивания надёжности какого-либо программного продукта.
В связи с этим попробуем выполнить эту задачу на примере игрушки «Тетрис».
Основной функционал:
Случайные фигурки тетрамино падают сверху в прямоугольный стакан шириной 10 и высотой 20 клеток. В полёте игрок может поворачивать фигурку на 90° и двигать её по горизонтали. Также можно «сбрасывать» фигурку, то есть ускорять её падение, когда уже решено, куда фигурка должна упасть. Фигурка летит до тех пор, пока не наткнётся на другую фигурку либо на дно стакана. Если при этом заполнился горизонтальный ряд из 10 клеток, он пропадает и всё, что выше него, опускается на одну клетку. Дополнительно показывается фигурка, которая будет следовать после текущей — это подсказка, которая позволяет игроку планировать действия. Темп игры постепенно ускоряется. Игра заканчивается, когда новая фигурка не может поместиться в стакан. Игрок получает очки за каждый заполненный ряд, поэтому его задача — заполнять ряды, не заполняя сам стакан (по вертикали) как можно дольше, чтобы таким образом получить как можно больше очков.
Цель: развивать сообразительность, память, воображение ребёнка, знакомить с цветом, формой, величиной, а также способствовать развитию речи, развивать мелкие мышцы рук.
Требования к оборудованию:
В качестве аппаратной среды используется ПК типа IBM PC.
Системные требования:
1. Компьютер Pentium 200 МГц
2. Оперативная память 32 RAM
3. Видеокарта 800х600
4. Операционная система Microsoft Windows 98/ME/2000/XP/Vista/7
5. Клавиатура
6. Мышь
7. Размеры свободного дискового пространства 200 кб

Теперь оценим надёжность данного программного продукта по четырём критериям:
Зрелость:
Метрика “Объем модуля”. Как правило, наиболее весомые модули имеют больший объем кода. Если обозначить: А — объем модуля (например, число строк кода); В — объем кода аналогичного по функциональности модуля, взятый из статистических данных организации разработчика программного средства, то числовую оценку метрики можно найти по формуле
X =
При этом справедливо 0<А; 0<X<=1.
В качестве модуля A возьмём весь код программы. Он содержит 10+68+4+119+12+128+18+11 = 370 строк кода из всех подмодулей.
В качестве модуля B возьмём весь код программы разработчика данного средства.
Он содержит 142 + 194 + 54 = 390 строк кода из всех подмодулей.
X = 370/1029 = 0,356.
Метрика “Время, затраченное на разработку модуля”. Как правило, на разработку наиболее весомого модуля затрачивается больше времени. Если обозначить: А — время, затраченное на разработку модуля; В — время, затраченное на разработку аналогичного по функциональности модуля, взятое из статистических данных организации-разработчика программного средства, то числовую оценку метрики можно найти по формуле

X =
При этом справедливо 0<А; 0<X<=1.
Пускай время будет исчисляться в часах. У одного разработчика на создание общего, функционально простого модуля ушло 32 часа. У команды из пяти человек на создание общего модуля с клиентским уклоном ушло 70 часов.
Получаем что Х = А/B = 0,457
Метрика “Потребляемые ресурсы модулем”. Как правило, более весомый модуль потребляет и больше ресурсов. Если обозначить: А — объем потребляемых ресурсов модулем (объем оперативной памяти и т.п.); В — общий объем потребляемых программным средством ресурсов, то числовую оценку метрики можно найти по формуле X=A/B. При этом справедливо: 0<А < B; 0< X <1.
В качестве потребляемых ресурсов взята используемая оперативная память, а программным средством является студия разработки модуля InteliJ IDEA Community Edition.
Под модулем подразумевается наше ПО. Оно потребляет 0,036 Мб оперативной памяти компьютера.
Для нормальной работы InteliJ IDEA требуется 1200 Mб оперативной памяти.
Х = A/B = 0,036/1200 = 0,00003
Способность к восстановлению:
Метрика “Зависимость модулей”. Как правило, в программном средстве модули связаны в древовидную структуру, где неправильная работа одного модуля приводит к неправильной работе других модулей. Если обозначить: А — количество модулей, зависящих от данного модуля; В — общее количество всех модулей, то числовую оценку метрики можно найти по формуле X=A/B. При этом справедливо 0<=А < B; 0< X <1.
Пускай под модулями будем подразумевать классы (структуры) программы. Всего классов у программы восемь. Все они связаны между собой. Поэтому X=A/B = 1 / 8 = 0,125
Метрика “Частота использования модуля”. Вероятность появления ошибки возрастает с ростом количества вызовов модуля, поэтому часто вызываемые модули более весомы, нежели модули, вызываемые реже.
Если обозначить: А — количество вызовов модуля; В — общее количество всех вызовов модулей, то числовую оценку метрики можно найти по формуле X=A/B. При этом справедливо 1<=А < B; 1/B< X <1.
Пускай под вызовами моделей будем иметь ввиду событие нажатия кнопки интерфейса программы либо нажатие клавиши на клавиатуре.
Используя клавиши со стрелками влево, вправо и вверх мы заставляем падающую сверху фигуру менять своё местоположение в пространстве. Задействовано 3 модуля т.е. А=3. Четвёртым не всегда задействованным модулем будет являться клавиша со стрелкой вниз. Она отвечает за скорость падения фигуры.
Итак, X=A/B = 3 / 4= 0,75
Метрика “Время работы модуля”. Как правило, чем большее время находится модуль в работе, тем он более весом. Если обозначить: А — время работы модуля; В — общее время выполнения всей задачи, то числовую оценку метрики можно найти по формуле X=A/B. При этом справедливо 0<А<B; 0<X<1
Стандартное время выполнения модуля А – 90 секунд.
Время выполнения всей задачи – 120 секунд.
X =А/В=90/120 =0,75.
Соответствие стандартам:
Метрика “Команда разработки модуля”. Как правило, в разработке наиболее весомых модулей принимает участие большее количество разработчиков. Если обозначить: А — количество разработчиков, принимающих участие в разработке модуля; В — количество разработчиков, принимавших участие в создании аналогичного по функциональности модуля, взятое из статистических данных организации-разработчика программного средства, то числовую оценку метрики можно найти по формуле
X =
При этом справедливо 0<А; 0<X<=1.
Под модулем A будем считать кол-во разработчиков данного программного продукта. Участие принимал один разработчик.
В — количество разработчиков, принимавших участие в создании аналогичного по функциональности модуля.
Предположим, это будут: Аналитик – человек отвечающий за анализ ТЗ и сбор информации, человек отвечающий за создание переменных и логику программы, человек отвечающий за интерфейс программы, человек отвечающий за компоновку всех подмодулей и работоспособность программы в целом, тестировщик. Всего пять человек.
X =1/5 = 0,2.
Метрика “Квалификация команды разработчиков”. Как правило, в разработке наиболее весомых модулей принимают участие более квалифицированные разработчики. Если обозначить: А — уровень квалификации команды разработчиков, принимающих участие в разработке модуля (А — может быть определенно экспертным путем, 0<А<=1); В — уровень квалификации команды разработчиков, принимавших участие в создании аналогичного по функциональности модуля, взятый из статистических данных организации-разработчика программного средства, то числовую оценку метрики можно найти по формуле
X =
При этом справедливо 0<А<=1; 0<X<=1.
В разработке данного модуля принимал участие один человек. Его уровень – юниор – оценивается единицей. Команда разработчиков предприятия имеет уровень – опытный – оценивается числом 2.
X =A/B = 1 / 2= 0,5
Метрика “Документирование модуля”. Как правило, более весомые модули должны иметь больший объем документации. Если обозначить: А — суммарный объем документов, описывающих анализируемый модуль; В — суммарный объем документов аналогичного по функциональности модуля, взятый из статистических данных организации-разработчика программного средства, то числовую оценку метрики можно найти по формуле
X =
При этом справедливо 0<А;0<X<=1
Под документацией будем подразумевать всю информацию, касающуюся конкретно данного модуля.
Пусть А будет включать только список файлов, позволяющих использовать модуль на сторонних аппаратных средствах. Их будет 5.
B – будет включать тот же список необходимых документов. Но добавятся три новых: ТЗ, спецификации и доклад руководству.
X =A/B = 5/ 8= 0,625

Отказоустойчивость:
Метрика “Тестовые наборы модуля”. Как правило, более весомые модули имеют большее количество тестовых наборов данных. Если обозначить: А — количество тестовых наборов разрабатываемого модуля; В — количество тестовых наборов аналогичного по функциональности модуля, взятое из статистических данных организации-разработчика программного средства, то числовую оценку метрики можно найти по формуле
X =
При этом справедливо 0<А;0<X<=1
Так как объём исходного модуля и модуля организации-разработчика почти различаются, функционал также будет различен и кол-во тестовых наборов будет не одним и тем же. Организация-разработчик создала более масштабную программу с клиентским уклоном.
А = 1
B = 2
Х = А/В = 0,5
Метрика “Время тестирования модуля”. Как правило, более весомые модули тестируются более продолжительное время. Если обозначить А — время тестирования разрабатываемого модуля; В — время тестирования аналогичного по функциональности модуля, взятое из статистических данных организации-разработчика программного средства, то числовую оценку метрики можно найти по формуле
X =
При этом справедливо 0<А; 0<X<=1.
Предположим, что разработчик исходной программы тестирует код белого ящика, а разработчик-тестировщик организации – код черного ящика.
Тогда параметр А будет равен 12 секундам.
Параметр В будет равен 600 секундам.
X = А/В = 0,02
Оценку надёжности программного средства будем проводить по формуле:

=., где n – кол-во модулей в программном средстве
Si – вес i-го модуля
Pi – оценка надежности i-го модуля

=,=1-
Для оценки надёжности i-го модуля данную формулу использовать не будем, т.к пользователь никаких данных не вводит. Программа запускается при нажатии кнопки Run.
Программным продуктом является сама игра Тетрис, написанная на java. Её модулями являются классы. Их всего восемь. Пользователи игры доступа к модулям не имеют. Имеет доступ только сам разработчик и тестировщик. Поэтому будем рассматривать программный продукт с точки зрения тестировщика.
Пусть вероятность просмотра модулей равна соответственно 0,05;0,1;0,05;0,4;0,05;0,25;0,05;0,05.
Вероятность ошибки возможно в самых крупных по числу строк модулях. Это 4 и 6 модули. В четвёртом модуле произошла ошибка типа Medium, а в шестом – типа High.
Вес ошибок Priceless, High, Medium, Low, None, Detrimental соответственно равны 0,4; 0,25; 0,2; 0,1; 0,04; 0,01.
Тогда оценка надежности всех модулей будет равна:
P = 1 – (0 * 0,05+0*0,1+0*0,05+0,2*0,4+0*0,05;0,25*0,25;0*0,05;0*0,05)
P = 1 – 0,1425 = 0,8575
Чтобы рассчитать веса модулей, сначала найдём знаменатель. Он должен равняться 1:

V1 = 0,356
V2 = 0,157
V3 = 0,00003
V4 = 0,025
V5 = 0,05
V6 = 0,15
V7 = 0,003
V8 = 0,1
V9 = 0,09
V10 = 0,05
V11 = 0,01897
Значения Xij возьмём из ранее найденных значений метрик:
X1 = 370/1029 = 0,356
Х2 = А/B = 0,457
Х3 = A/B = 0,036/1200 = 0,00003
X4=A/B = 1 / 8 = 0,125
X5=A/B = 3 / 4= 0,75
X6 =А/В=90/120 =0,75.
X7 =1/5 = 0,2
X8 =A/B = 1 / 2= 0,5
X9 =A/B = 5/ 8= 0,625
Х10 = А/В = 0,5
X11 = А/В = 0,02
Находим числитель по формуле 

(0,356*0,356) +( 0,157*0,457) +( 0,00003*0,00003) +( 0,025*0,125) +
+(0,05*0,75) +(0,15*0,75) + (0,003*0,2) + (0,1*0,5) +(0,09+0,625) +
+ (0,05*0,5) +( 0,01897*0,02) = 0,1267+0,071+0,00000001+0,0031+
+0,0375+0,1125+0,0006+0,05+0,0562+0,025+0,0003 = 0,4829

Делим на единицу в знаменателе.
S = 0, 4829
Наконец находим оценку надёжности всего программного средства:
Pпс = P * S = 0,8575*0, 4829 = 0,414

Оценка надёжности программного средства показала, что данная программа является надёжной только на 40%.
В связи с этим рекомендуются следующие действия по увеличению надёжности ПП:
1. Проведение обширного тестирования (в особенности юнит-тесты, модульные тесты, интеграционные тесты, функциональные тесты);
2. Уменьшение числа классов (модулей программы) для лучшей производительности;
3. Постараться упростить функциональность (логику) программы, сделать код более гибким, не создавать лишнего.
4. Низкоуровневый подход к написанию кода (то есть создавать более простые структуры, методы поля, классы).

В любой технике, аппаратно-программном обеспечении, системе есть шанс возникновения отказа. Отказ — событие, заключающееся в нарушении работоспособ­ного состояния объекта. В зависимости от целей исследования отказы подразделяют на: независимые и зависимые; внезапные и постепенные; параметрические и функциональные; конструкционные, производственные и эксплуатационные; перемежающие, сбои и т.д. Если пользователь (потребитель, покупатель, заказчик) хочет, чтобы его устройство прослужило ему как можно дольше, производитель обязан произвести оценку продукта по вышеуказанным критериям.