Дипломная работа: Исследование и разработка информационной системы учета сбыта продукции на примере ТОО "GT MACHINERY"
Внимание! Если размещение файла нарушает Ваши авторские права, то обязательно сообщите нам
100
Рисунок 18 - Блок-схема формирования отчета о заказах
Введенный период должен соответствовать двум критериям. Во-первых,
дата начала период должна быть раньше даты конца периода. Во-вторых, дата
начала и дата конца должны быть раньше текущей даты. Формирование отчета
заключается в запросе к базе данных к таблице «Заказы» и выборке заказов
соответствующих критериям поиска (дата совершения заказа).
Далее представлена блок-схема формирования плана закупок.
101
Рисунок 19 - Блок-схема формирования плана закупок
План закупок формируется на основании отчета о заказах за предыдущий
квартал. Системой вычисляется среднее арифметическое число по заказам каждой
модели за каждый месяц квартала. Так же при формировании плана есть
102
возможность выбора конкретной категории товаров. В случае если категория не
выбрана, будет сформирован план закупок по всем товарам компании.
В последней блок-схеме отображен процесс формирования отчета о чистой
прибыли.
Рисунок 20 - Блок-схема формирования отчета о чистой прибыли
Критерии верности введённого периода такие же, как и для отчета о заказах.
Дата начала период должна быть раньше даты конца периода. Так же дата начала
и дата конца должны быть раньше текущей даты. Для расчета чистой прибыли
система формирует отчет о заказах за выбранный период. Далее выполняется
запрос к таблице «Товары» в базе данных. Для расчета чистой прибыли по заказу
система отнимает от стоимости заказа себестоимость и стоимость доставки
товара. Полученные результаты сохраняются в таблицу отчета о чистой прибыли.
103
2.5 Апробация результатов исследования
Апробация результатов исследования заключается в общей
макроорганизации тестирования. На данном этапе вырабатываются
принципиальные правила и нормы тестирования:
определяются цели и задачи тестирования;
определяется место и техническая инфраструктура тестирования;
определяются макропараметры ресурсозатрат тестирования;
определяется группа участников тестирования с двух сторон;
определяется период, этапы и последовательность выполнения
тестирования;
распределяются и доводятся макрозадачи и ответственность до
участников тестирования;
разрабатывается нормативно-правовая база, в том числе регламент,
план-графики.
В данном случае тестирование проводилось на стороне Заказчика, а в роли
тестировщика выступал Тестировщик и Менеджер по продажам. Дополнительные
участники тестирования не привлекались. Основной целью тестирования
являлась информация о соответствии реакций функций модулей. Начальными
условиями и исходными данными тестирования были приняты:
требования к свойствам системы, зафиксированные в ТЗ и
требования Заказчика;
объем, глубина тестирования;
масштаб тестирования.
Далее был определен объем тестирования, то есть состав функций. Для того
чтобы протестировать функции разработанной системы, их необходимо
выделить, то есть разделить систему на отдельные функции. Таким образом,
разработанная система была разделена на 26 отдельных модулей. Каждая функция
была идентифицирована, идентифицированные функции отображены на рисунке
16.
На основании результатов апробации системы были определенны условия
функций создания каталога товаров, а также условия функции формирования
отчета. Функцией создания каталога товаров является функция проверки
104
ненулевых значений полей формы, а так же функция проверки на повтор. Так
пользователем не может быть создан товар, категория или услуга с реквизитами,
которые уже были занесены в БД ранее. Функция формирования отчета в свою
очередь проверяет соответствие периода, в случае его соответствия функция
высчитывает необходимые данные, хранящиеся в базе данных.
Далее тестировалась функция проверки вводимых значений. В случае
несоответствия введенных данных поставленным условиям, функция должна
вывести сообщение о несоответствии вводимых значений заданным требованиям.
Пример сообщения отображен в приложении 9. На данном этапе была выявлена
ошибка. Существует несколько видов ошибок и неисправностей
информационных систем:
- по виду программного обеспечения;
- по характеру воздействия на функциональность информационной
системы;
- по характеру проявления и действия;
- по программному уровню.
По виду программного обеспечения:
- в приложениях;
- в ООПО- при совмещении АИС с другими приложениями на одной
физической операционной платформе могут возникать коллизии между задачами
операционной системы;
- в ОБ-ПО-в работе самих модулях СУБД, при размещении БД на
общие не выделенные ресурсы БД возникают коллизии в ресурсопотреблении
сервера БД и коллизии в обращении к данным в БД.
По характеру воздействия на функциональность информационной системы.
- критические;
- не критические.
По характеру проявления и действия
- устойчивые, стабильные;
- стохастические.
По программному уровню
- синтаксические-на уровне исходного кода;
Источник: https://baza.diplomsite.ru/previewfile/8737