диплом2015. Преимущества штрихового кодирования
 Скачать 0.69 Mb.
|
|
4.3 Тестирование программного обеспечения По окончании разработки программное обеспечение подверглось тщательному тестированию. Тестирование выполнялось в локальной сети ЗАО МЗХ «Атлант». На сервере была размещена база данных штрих-кодов изделий предприятия, сформированная ранее. Процедура тестирования заключалась в следующем: а) Выполнение стандартных действий при считывании штрих-кодов. С помощью программы выполнялись операции считывания штрих-кодов с этикеток, проверка по базе данных и добавление данных в таблицу. При этом не было замечено никаких отклонений от нормального хода выполнения программы, т.е. все ее действия были предсказуемы. Тестирование выполнялось на довольно значительном массиве данных. При этом каких-то значительных задержек при обработке и сохранению в базу данных не было. При считывании информации и добавлении в окно главной формы программы происходили небольшие задержки времени. Это объясняется тем, что для избегания перегрузки процессора бесконечным циклом была специально установлена задержка в 50 миллисекунд и временной задержкой сканера между двумя считываниями. б) Создание нестандартных ситуаций, требующих особой обработки. При тестировании программного обеспечения создавались ситуации типа считывания штрих-кода длинной более двенадцати символов. Программа корректно обрабатывала данные, как, и было задумано. Другой исключительной ситуацией было открытие последовательного порта, когда он был занят уже другим приложением. Это событие обрабатывалось программой аналогичным образом. При попытке открытии таблицы, занятой другим приложением, было выдано сообщение о данной проблеме. В ходе испытаний была доказана полная совместимость и правильность работы программного средства с OC Windows XP. Произведём оценку надежности ПО. Все модели надежности ПО можно разделить на два класса: иерархические и математические. Иерархические модели надежности ПО позволяют выполнить интегральную количественную оценку надежности ПС, учитывающую различные критерии надежности[13]. Математические модели надёжности ПО позволяют определить оценки показателей надёжности ПО: вероятность безотказной работы  , интенсивность отказов  , математическое ожидание времени наработки на отказ  , число ошибок в ПО до начала тестирования  [13].Произведём оценку надежности данного программного обеспечения с помощью математической модели Джелинского-Моранды. Допущения модели[13]: а) время до очередного отказа распределено по экспоненциальному закону; б) все ошибки равновероятны и их появление не зависит друг от руга; в) частота появления ошибок (интенсивность отказов, в англоязычной литературе так же имеет название функция риска) пропорциональна числу не выявленных ошибок:  (4.1)где: – число ошибок в ПО до начала тестирования и отладки;  – коэффициент Джелинского-Моранды;  – интервал времени между  -й и -й обнаруженными ошибками;  – число ошибок, обнаруженных к моменту отладки .г)  на интервале между двумя смежными моментами появления ошибок;д) каждая обнаруженная ошибка в ПО немедленно устраняется и число оставшихся ошибок уменьшается на 1; е) ошибки корректируются без внесения новых ошибок. Характеристиками модели (то, что нужно определить) являются: – – вероятность отсутствия следующего -ого отказа; – – среднее время до очередного -ого отказа; – – коэффициент Джелинского-Моранды; – – число ошибок в ПО до начала тестирования и отладки. Характеристики модели определяются при помощи метода максимального правдоподобия. При тестировании фиксировались интервалы времени между отказами вследствие ошибок в ПО {  = 1,n} случайной величины Т – времени между отказами ПО. Интервалы времени между отказами ПО равны t1=10 часов, t2=15 часов, t3=20 часов, t4=25 часов. Всего обнаружено n = 4 ошибки.Введём понятие о функции правдоподобия L как о совместной n-мерной плотности распределения вероятностей события, заключающегося в том, что в процессе тестирования ПО случайная величина T примет значение t1=10 часов, t2=15 часов, t3=20 часов, t4=25 часов. Функция правдоподобия согласно допущению модели Джелинского – Моранди, что все ошибки равновероятны и их появления не зависят друг от друга, будет иметь вид (4.2):  или, подставив значения функции плотности,  В качестве оценок неизвестных параметров и выбираются такие функции  , которые максимизируют функцию правдоподобия. Затем, на основании известных правил дифференциального исчисления для нахождения оценок максимального правдоподобия  и  составляется система уравнений (4.4) и выбирается то решение, которое обращает функцию правдоподобия в максимум. Так как экстремум функций L и lnL достигается при одних и тех же значениях и , то для упрощения вычислений пользуются логарифмической функцией правдоподобия. Возьмём натуральный логарифм от функции правдоподобия, чтобы произведение функций заменить суммой:  Возьмём частные производные по и и найдём условия экстремума: Полагая  и  и решая систему уравнений, получаем:а) оценка коэффициента Джелинского – Моранды  б) оценка числа ошибок в ПО до начала тестирования  Интенсивность отказов до следующей пятой ошибки  Средняя наработка до обнаружения следующей пятой ошибки  Вероятность безотказной работы, т.е. отсутствия следующего пятого отказа  Оценка надежности программного обеспечения с помощью модели Джелинского-Моранды показала, что разработанное ПО автоматизированной системы идентификации готовой продукции соответствует предъявляемым требованиям надежности. Средняя наработка до обнаружения пятой ошибки составила 58,82 часа.
При нажатии на кнопку «START» происходит открытие COM порта. Если последовательный порт не занят другим приложением, то выдаётся сообщение об успешном открытии порта (рисунок 4.1). Иначе выдаётся сообщение об ошибке открытия порта (рисунок 4.2).  Рисунок 4.1 – Сообщение об успешном открытии порта  Рисунок 4.2 – Сообщение об ошибке открытия порта Далее делается пять попыток открыть таблицу test.dbf. При положительном результате можно переходить к работе, при отрицательном результате – сообщение об ошибке (рисунок 4.3).  Рисунок 4.3 – Сообщение об ошибке открытия таблицы Дальнейшая работа происходит считыванием штрих-кодов с этикеток и отображением их в окне главной формы, изображенной на рисунке 4.4.  Рисунок 4.4 – Главная форма программы Перед тем как штрих-код записывается в окно главной формы, он проверяется по таблице на наличие такого. Если совпадений не обнаружено, штрих-код добавляется в таблицу test.dbf с датой и временем, когда его считали сканером с этикетки. Таблица штрих-кодов приведена на рисунке 4.5.  Рисунок 4.5 – Таблица штрих-кодов
5.1 Введение Целью данного дипломного проекта является разработка программного обеспечения для автоматизированной системы идентификации готовой продукции. В настоящем технико-экономическом обосновании рассчитывается сумма расходов, связанных с разработкой программного обеспечения и экономический эффект от применения разработанного программного обеспечения на предприятии. 5.2 Исходные данные для расчетов Таблица 5.1 – Исходные данные
Продолжение таблицы 5.1
5.3 Расчет себестоимости программного обеспечения Для того, чтобы рассчитать себестоимость разработанного программного обеспечения, необходимо составить смету затрат, которая включает следующие статьи: – заработная плата исполнителей основная (ЗО) и дополнительная (ЗД); – отчисления в фонд социальной защиты населения (ЗСЗ); – отчисления на развитие здравоохранения и охрану здоровья (ЗОЗ); – налоги, от фонда оплаты труда (Не); – материалы и комплектующие (М); – спецоборудование (РС); – машинное время (РМ); – расходы на научные командировки (РНК); – прочие прямые затраты (Пз); – накладные расходы (РН). Объем программного обеспечения определяется на основе нормативных данных, приведенных в таблице 5.2. Общий объем программного обеспечения рассчитывается по формуле (5.1):  (5.1)где  – общий объем ПО;  – объем функций ПО;  – общее число функций. Таблица 5.2 – Характеристика функций и их объем
В итоге общий объем ПО составляет:  условных машинных команд. Учитывая современные технологии программирования, технические и инструментальные средства, полученное значение используются с поправочным коэффициентом 0,3: (условных машинных команд)В соответствии с нормативами определятся, что разрабатываемое программное обеспечение относится к третьей группе сложности. По таблице укрупненных норм времени на разработку ПО находится, что программному обеспечению данной группы сложности объемом около 5500 условных машинных команд соответствует норма времени 127 человеко-дней. Таким образом, нормативная трудоемкость ТН оценивается в 127 человеко-дней. С учетом дополнительного коэффициента сложности рассчитывается общая трудоемкость ПО:  (5.2)где  – общая трудоемкость ПО,  – нормативная трудоемкость ПО; – дополнительный коэффициент сложности ПО.Исходя из того, что планируется функционирование разрабатываемого программного модуля в расширенной операционной среде (связь с другими программными модулями) и программное средство обеспечивает хранение и поиск данных в сложных структурах, принимается дополнительный коэффициент сложности равным 0,15. Тогда общая трудоемкость составит:  человеко-дней.На основании значения общей трудоемкости определяется уточненная трудоемкость с учетом распределения по стадиям разработки по формуле (5.3):  где  - трудоемкость разработки ПО на i-ой стадии (человеко-дней); – количество стадий.Трудоемкость разработки ПО ТСТi на каждой i-ой стадий (технического задания, эскизного проекта, технического проекта, рабочего проекта и внедрения) определяется по формуле (5.4):  (5.4)где  - удельный вес трудоемкости i-ой стадии разработки ПО в общей трудоемкости ПО (для ПО степени новизны В); – поправочный коэффициент, учитывающий степень новизны ПО, принимаем равным 0,7; – поправочный коэффициент, учитывающий степень использования в разработке типовых программ и ПО, принимаем равным 0,8.Для каждой из стадий уточненная трудоемкость следующая:  (человеко-дней) – уточненная трудоемкость на стадии технического задания; (человеко-дней) – уточненная трудоемкость на стадии эскизного проекта; (человеко-дней) – уточненная трудоемкость на стадии технического проекта; (человеко-дней) – уточненная трудоемкость на стадии рабочего проекта; (человеко-дней) – уточненная трудоемкость на стадии внедрения.Тогда уточненная трудоемкость ТУ разработки программного обеспечения по всем стадиям составляет:  (человеко-дня).На основании уточненной трудоемкости разработки ПО и установленного периода разработки рассчитываем общую плановую численность разработчиков:  где  – плановая численность разработчиков (чел.);  – годовой эффективный фонд времени работы одного работника в течение года (дней в год); – плановая продолжительность разработки ПО (лет).Эффективный фонд времени работы одного работника ( ) рассчитывается по формуле (5.5): ДГ – ДП – ДВ – ДО, (5.5)где ДГ – количество дней в году; ДП – количество праздничных дней в году; ДВ – количество выходных дней в году; ДО – количество дней отпуска. ФЭФ составит:  дней.Тогда плановая численность разработчиков ЧР = 81,75 /  человек. Уточненная трудоемкость и общая плановая численность работников служит базой для расчета основной заработной платы. Исполнитель-разработчик ПО: – Инженер-программист без категории (тарифный разряд 12, тарифный коэффициент 2,84, продолжительность участия в разработке ПО 90 дней) Месячная тарифная ставка исполнителя (ТМ) определяется путем умножения действующей месячной тарифной ставки 1-го разряда (ТМ1 = 200000) на тарифный коэффициент (ТК), соответствующий тарифному разряду: ТМ = ТМ1  ТК.Тогда для каждого исполнителя ТМ = 200000 2,84 = 568000 бел. руб.Часовая тарифная ставка рассчитывается путем деления месячной тарифной ставки на установленный при восьмичасовом рабочем дне фонд рабочего времени (  ):  где  – часовая тарифная ставка (бел. руб.);  – месячная тарифная ставка (бел. руб.).В результате расчета для исполнителя часовая тарифная ставка составляет:  Основная заработная плата исполнителя рассчитывается по формуле (5.6):  (5.6)где – количество исполнителей, занятых разработкой программного модуля;TЧi – часовая тарифная ставка i-го исполнителя (бел. руб.); ФЭi – эффективный фонд рабочего времени i-го исполнителя (дней); ТЧ – количество часов работы в день (ч); К – коэффициент премирования.  бел. руб.Определяем дополнительную заработную плату ЗД на разрабатываемый программный модуль по нормативу НД в процентах к основной заработной плате по формуле (5.7):  (5.7)  Отчисления в фонд социальной защиты населения ЗСЗ определяются по формуле (5.8):  где  – норматив отчислений в фонды социальной защиты населения(%).Сумма отчислений в фонд социальной защиты населения:  Налог, рассчитываемый по фонду оплаты труда (на страхование), определяется по формуле (5.9):   Расходы по статье «Материалы» (М) определяются на основании сметы затрат, разрабатываемой на ПО с учетом действующих нормативов. Норма расхода материалов (носители, бумага, красящие ленты и т.п.) в суммарном выражении (НМ = 430 бел. руб.) определяется в расчете на 100 строк исходного кода программного модуля. Сумма затрат на материалы рассчитывается по следующей формуле с учетом коэффициента снижения расхода материалов на разработку и отладку (принимаем равным 0,5):  где НМ – норма расхода материалов в расчете на 100 строк исходного кода ПО (бел. руб.); – общий объем программного модуля (строк исходного кода).  Расходы по статье «Машинное время» (РМ) включают оплату машинного времени, необходимого для разработки и отладки программного обеспечения, которое определяется по нормативам (в машино-часах) на 100 строк исходного кода (НМВ) машинного времени в зависимости от характера решаемых задач и типа ПЭВМ. Так как разрабатываемый программный модуль предназначен для учета и контроля средств, в соответствии с нормативами значение НМВ принимаем равным 13ч/100 строк исходного кода. Сумма расходов по данной статье определяется по формуле (5.11):  где ЦМ – расходы на оплату 1 машино-часа, принимаем равным 100 бел. руб.; – общий объем ПО (строк исходного кода);НМВ – норматив расхода машинного времени на отладку 100 строк исходного кода (машино-часов).  Расходы по статье «Прочие затраты» (ПЗ) включают затраты на приобретение и подготовку специальной научно-технической информации и литературы. Сумму этих расходов определяем следующим образом:  где НПЗ – норматив прочих затрат в целом по организации (20 %).  Общую сумму расходов по всем статьям сметы рассчитываем по формуле (5.12):  (5.12) бел. руб.Общую сумму расходов на разработку программного модуля (с затратами на сопровождение и адаптацию) как его полную себестоимость (СП) определяем по следующей формуле (5.13):  где НРСА - норматив расходов на сопровождение и адаптацию программного средства (10 %).  Общая сумма расходов на разработку программного модуля (с затратами на сопровождение и адаптацию) составила  |
