Автоматизация процесса работы отдела продаж "Новый Стиль Украина"
Анализ публикаций по вопросу системы автоматизации учета движения товаров и формирования отчетности на промышленных предприятиях Украины. Методологии и технологии проектирования. Системная архитектура "клиент-сервер". Требование к аппаратному обеспечению.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | дипломная работа |
| Язык | русский |
| Дата добавления | 02.06.2017 |
| Размер файла | 1,4 M |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
На вход блока «анализ информации» подаются заказ товара и информация о наличии товаров на складе. Анализ информации ведется директором отдела продаж и экономистами. В ходе анализа информации рассматриваются декларации на товар, льготы на продукцию. Выписывается накладная получения товара на складе, рассматривается квитанция об оплате. После того, как был получен товар, формируется отчет на выходе информация о движении товаров и средств полученных при операции с количеством товара и его ценой.
Рисунок 2.2 - Диаграмма бизнес-процесса «Учет товаров и формирование отчетности»
Рисунок 2.3 - Декомпозиция продаж на АОЗТ «Новый Стиль Украина»
Рисунок 2.4 - Формирование отчетности
На вход подаются информации о продажи определенного товара, затем идет оформление прайс-листа, при этом идет запись об информации товара, прибыли и взаиморасчета, а на выходе информация об отчетности движении товаров.
2.6 Построение модели базы данных на основе диаграмм ER-типа
В результате декомпозиции предметной области выделим следующие обобщенные сущности, которые представляют собой базы данных и таблицы [14, 33, 27]:
Отдел по продажам;
Работники;
Главный директор отдела продаж;
Разновидность товаров;
Отчет о проделанной работе.
При таком подходе имеем следующую структуру ПО:
На самом верхнем уровне расположен управляющий модуль программы, который управляет всем ПО, в управляющий модуль входят: модуль управляющий доступам на вход, второй модуль управление БД, третий модуль главная экранная форма которая включает в себя два модуля - это модуль выбора даты и модуль поиска каталогов товаров [27].
Выделение сущностей
Список подразделения «PART»
|
ID - Код подразделения |
NAME VARCHAR - Наименование подразделения |
Список закупки «NALK_IN»
|
ID - Код закупки |
PART_ID INTEGER - Код продавца; FIRM_ID INTEGER - Код контрагента; OPER_ID INTEGER - Код типа операции; DD_D - Дата закупки; NUM VARCHAR - Номер приходного документа; SKID_P - Процент скидки (не используется в программе); NDS_P - Процент НДС (не используется в программе); TRANS - Транспортные расходы (не используется в программе). |
Внутренние перемещения между подразделениями «INSIDE»
|
ID - Код перемещения |
PART1_ID INTEGER - Из какого подразделения; PART2_ID INTEGER - В какое подразделение; D - Дата; NUM VARCHAR - Номер документа; TRANS - Транспортные расходы (не используется в программе). |
Список подразделения «PART»
|
ID - Код подразделения |
NAME VARCHAR - Наименование подразделения |
Список закупки «NALK_IN»
|
ID - Код закупки |
PART_ID INTEGER - Код продавца; FIRM_ID INTEGER - Код контрагента; OPER_ID INTEGER - Код типа операции; DD_D - Дата закупки; NUM VARCHAR - Номер приходного документа; SKID_P - Процент скидки (не используется в программе); NDS_P - Процент НДС (не используется в программе); TRANS - Транспортные расходы (не используется в программе). |
Типы операций «OPER»
|
ID - Код типа операции; |
NAME VARCHAR - Наименование типа |
Список закупки «NALK_IN»
|
ID - Код закупки |
PART_ID INTEGER - Код продавца; FIRM_ID INTEGER - Код контрагента; OPER_ID INTEGER - Код типа операции; DD_D - Дата закупки; NUM VARCHAR - Номер приходного документа; SKID_P - Процент скидки (не используется в программе); NDS_P - Процент НДС (не используется в программе); TRANS - Транспортные расходы (не используется в программе). |
Контрагенты «FIRM»
|
ID - Код контрагента |
FIRM_GROUP_ID INTEGER - Код группы контрагентов; NAME VARCHAR - Наименование; OKPO VARCHAR - Код ОКПО; INN VARCHAR - Индивидуальный налоговый номер; SVID VARCHAR - № налогового свидетельства; PHONE VARCHAR - Телефон; ADDR VARCHAR - Адрес; BANC VARCHAR - Наименование банка; BANC_ADDR VARCHAR - Адрес банка; MFO VARCHAR - Код МФО; ACCN VARCHAR - Расчетный счет; REGION VARCHAR - Область (или страна). |
Спецификация закупки (Товар в закупках) «NALK_IN_POS»
|
ID - Код позиции прихода |
NAKL_IN_ID INTEGER - Код закупки; GOODS_ID INTEGER - Код товара; CNT - Количество товара; PRICE - Цена закупки; TRANS - Транспортные расходы (не используется в программе); REST - Остаток прихода. |
Список закупки «NALK_IN»
|
ID - Код закупки |
PART_ID INTEGER - Код продавца; FIRM_ID INTEGER - Код контрагента; OPER_ID INTEGER- Код типа операции; DD_D - Дата закупки; NUM VARCHAR - Номер приходного документа; SKID_P - Процент скидки (не используется в программе); NDS_P - Процент НДС (не используется в программе); TRANS - Транспортные расходы (не используется в программе). |
Спецификация закупки (Товар в закупках) «NALK_IN_POS»
|
ID - Код позиции прихода |
NAKL_IN_ID INTEGER - Код закупки; GOODS_ID INTEGER - Код товара; CNT - Количество товара; PRICE - Цена закупки; TRANS - Транспортные расходы (не используется в программе); REST - Остаток прихода. |
Товары «GOODS»
|
ID - Код товара |
GOODS_GROUP_ID INTEGER- Код группы товаров; NAME VARCHAR - Наименование; ONE VARCHAR - Единица измерения; USE CHAR - Использовать?; PRICE - Цена последней закупки; CODE VARCHAR - Артикул. |
Товары «GOODS»
|
ID - Код товара |
GOODS_GROUP_ID INTEGER- Код группы товаров; NAME VARCHAR - Наименование; ONE VARCHAR - Единица измерения; USE CHAR - Использовать?; PRICE - Цена последней закупки; CODE VARCHAR - Артикул. |
Группы товаров «GOODS_GROUP»
|
ID - Код группы товаров |
NAME VARCHAR - Наименование группы товаров |
Спецификация внутреннего перемещения (товар в перемещении) «INSIDE_POS»
|
ID - Код позиции перемещения |
INSIDE_I INTEGER - Код перемещения; CNT - Количество; IN_ID INTEGER - Код позиции прихода; IN_WHAT INTEGER - Тип прихода (покупка или вн. перемещение); GOODS_ID INTEGER - Код товара; PRICE - Входная цена товара; REST - Остаток товара (после дальнейших перемещений или продаж); TRANS - Транспортные расходы (не используется в программе). |
Товары «GOODS»
|
ID - Код товара |
GOODS_GROUP_ID INTEGER- Код группы товаров; NAME VARCHAR - Наименование; ONE VARCHAR - Единица измерения; USE CHAR - Использовать?; PRICE - Цена последней закупки; CODE VARCHAR - Артикул. |
Спецификация внутреннего перемещения (товар в перемещении) «INSIDE_POS»
|
ID - Код позиции перемещения |
INSIDE_I INTEGER - Код перемещения; CNT - Количество; IN_ID INTEGER - Код позиции прихода; IN_WHAT INTEGER - Тип прихода (покупка или вн. перемещение); GOODS_ID INTEGER - Код товара; PRICE - Входная цена товара; REST - Остаток товара (после дальнейших перемещений или продаж); TRANS - Транспортные расходы (не используется в программе). |
Внутренние перемещения между подразделениями «INSIDE»
|
ID - Код перемещения |
PART1_ID INTEGER - Из какого подразделения; PART2_ID INTEGER - В какое подразделение; D - Дата; NUM VARCHAR - Номер документа; TRANS - Транспортные расходы (не используется в программе). |
Продажи «NAKL_OUT»
|
ID - Код продажи |
PART_ID - Код подразделения; FIRM_ID INTEGER - Код покупателя; OPER_ID INTEGER - Код типа операции; D - Дата продажи; NUM VARCHAR - Номер расходного документа; SKID_P - Процент скидки (не используется в программе); NDS_P - Процент НДС (не используется в программе); TRANS - Транспортные расходы (не используется в программе); ZPL_PERC - Процент из суммы продажи на зарплату продавцам (не используется в программе). |
Список подразделения «PART»
|
ID - Код подразделения |
NAME VARCHAR - Наименование подразделения |
Продажи «NAKL_OUT»
|
ID - Код продажи |
PART_ID - Код подразделения; FIRM_ID INTEGER - Код покупателя; OPER_ID INTEGER - Код типа операции; D - Дата продажи; NUM VARCHAR - Номер расходного документа; SKID_P - Процент скидки (не используется в программе); NDS_P - Процент НДС (не используется в программе); TRANS - Транспортные расходы (не используется в программе); ZPL_PERC - Процент из суммы продажи на зарплату продавцам (не используется в программе). |
Контрагенты «FIRM»
|
ID - Код контрагента |
FIRM_GROUP_ID INTEGER - Код группы контрагентов; NAME VARCHAR - Наименование; OKPO VARCHAR - Код ОКПО; INN VARCHAR - Индивидуальный налоговый номер; SVID VARCHAR - № налогового свидетельства; PHONE VARCHAR - Телефон; ADDR VARCHAR - Адрес; BANC VARCHAR - Наименование банка; BANC_ADDR VARCHAR - Адрес банка; MFO VARCHAR - Код МФО; ACCN VARCHAR - Расчетный счет; REGION VARCHAR - Область (или страна). |
Продажи «NAKL_OUT»
|
ID - Код продажи |
PART_ID - Код подразделения; FIRM_ID INTEGER - Код покупателя; OPER_ID INTEGER - Код типа операции; D - Дата продажи; NUM VARCHAR - Номер расходного документа; SKID_P - Процент скидки (не используется в программе); NDS_P - Процент НДС (не используется в программе); TRANS - Транспортные расходы (не используется в программе); ZPL_PERC - Процент из суммы продажи на зарплату продавцам (не используется в программе). |
Типы операций «OPER»
|
ID - Код типа операции |
NAME VARCHAR - Наименование типа |
Спецификация продажи (Товары в продажах) «NALK_OUT_POS»
|
ID - Код позиции расхода |
NAKL_OUT_ID INTEGER - Код продажи; GOODS_ID INTEGER - Код товара; CNT - Количество товара; PRICE - Цена продажи; DISCOUNT - Скидка; IN_ID INTEGER - Код позиции прихода; IN_WHAT INTEGER - Тип прихода (Закупка или внутр. перемещение); TRANS - Транспортные расходы (не используется в программе). |
Товары «GOODS»
|
ID - Код товара |
GOODS_GROUP_ID INTEGER - Код группы товаров; NAME VARCHAR - Наименование; ONE VARCHAR - Единица измерения; USE CHAR - Использовать?; PRICE - Цена последней закупки; CODE VARCHAR - Артикул. |
Спецификация продажи (Товары в продажах) «NALK_OUT_POS»
|
ID - Код позиции расхода |
NAKL_OUT_ID INTEGER - Код продажи; GOODS_ID INTEGER - Код товара; CNT - Количество товара; PRICE - Цена продажи; DISCOUNT - Скидка; IN_ID INTEGER - Код позиции прихода; IN_WHAT INTEGER - Тип прихода (Закупка или внутр. перемещение); TRANS - Транспортные расходы (не используется в программе). |
Продажи «NAKL_OUT»
|
ID - Код продажи |
PART_ID - Код подразделения; FIRM_ID INTEGER - Код покупателя; OPER_ID INTEGER - Код типа операции; D - Дата продажи; NUM VARCHAR - Номер расходного документа; SKID_P - Процент скидки (не используется в программе); NDS_P - Процент НДС (не используется в программе); TRANS - Транспортные расходы (не используется в программе); ZPL_PERC - Процент из суммы продажи на зарплату продавцам (не используется в программе). |
Входящие платежи «PLAT_IN»
|
ID - Код платежа |
D - Дата; NUM VARCHAR - Номер платежного документа; FIRM INTEGER - Код плательщика; SUMMA - Сумма платежа. |
Контрагенты «FIRM»
|
ID - Код контрагента |
FIRM_GROUP_ID INTEGER - Код группы контрагентов; NAME VARCHAR - Наименование; OKPO VARCHAR - Код ОКПО; INN VARCHAR - Индивидуальный налоговый номер; SVID VARCHAR - № налогового свидетельства; PHONE VARCHAR - Телефон; ADDR VARCHAR - Адрес; BANC VARCHAR - Наименование банка; BANC_ADDR VARCHAR - Адрес банка; MFO VARCHAR - Код МФО; ACCN VARCHAR - Расчетный счет; REGION VARCHAR - Область (или страна). |
Исходящие платежи «PLAT_OUT»
|
ID - Код платежа |
D - Дата; NUM VARCHAR - Номер платежного документа; FIRM INTEGER - Код получателя платежа; SUMMA - Сумма платежа. |
Контрагенты «FIRM»
|
ID - Код контрагента |
FIRM_GROUP_ID INTEGER - Код группы контрагентов; NAME VARCHAR - Наименование; OKPO VARCHAR - Код ОКПО; INN VARCHAR - Индивидуальный налоговый номер; SVID VARCHAR - № налогового свидетельства; PHONE VARCHAR - Телефон; ADDR VARCHAR - Адрес; BANC VARCHAR - Наименование банка; BANC_ADDR VARCHAR - Адрес банка; MFO VARCHAR - Код МФО; ACCN VARCHAR - Расчетный счет; REGION VARCHAR - Область (или страна). |
Для построения логической модели баз данных использовалось Case - средство ER-Win, которое позволяет проектировать реляционные модели баз данных как на логическом уровне, так и на физическом (проектирование таблиц БД) [6, 27].
На рисунке 2.5. представлена логическая модель базы данных. На рисунке 2.6. представлена физическая модель базы данных.
Логическая и физическая модели баз данных
Выполнив анализ сущностей и связей между ними, построим логическую модель, а затем - физическую.
Рисунок 2.5 - Логическая модель БД
Рисунок 2.6 - Физическая модель БД
Выводы по разделу 2
В ходе выполнения данного раздела к дипломному проекту выявлены основные технологические и информационные потоки предприятия АОЗТ «Новый Стиль Украина» по производству офисной мебели.
Разработана модель бизнес - процессов учета товаров и средств в нотациях IDEF0(CASE-средства BP-Win).
Выделены сущности предметной области и связи между ними. С использованием современных технологий проектирования(CASE-средства ER-Win) разработаны логическая и физическая модели данных, построены диаграммы этих моделей.
3. АЛГОРИТМИЗАЦИЯ ФУНКЦИЙ СИСТЕМЫ АВТОМАТИЗАЦИИ УЧЕТА ДВИЖЕНИЯ ТОВАРОВ И ФОРМИРОВАНИЯ ОТЧЕТНОСТИ
3.1 Методы разработки алгоритмов системы автоматизации учёта движения товаров и формирование отчетности
Под алгоритмом понимается точно определенное правило действий, для которого задано указание: как и в какой последовательности - это правило необходимо применять к исходным данным задачи, чтобы получить ее решение [6].
Главной особенностью любого алгоритма является формальное исполнение, позволяющее выполнять заданные действия или команды не только человеку, но и различным исполняющим техническим устройствам. Множество команд, которые в состоянии выполнить данное устройство, называется системой команд исполнителя (СКИ). Алгоритм может быть понят и выполнен в том случае, если его команды входят в СКИ [15].
Каждый алгоритм должен быть:
понятным для данного исполнителя, т.е. содержать предписания о выполнении только таких действий и о проверке только таких свойств объекта, которые входят в систему команд исполнителя;
дискретным, т.е. выполняться команды алгоритма должны последовательно, с точной фиксацией моментов окончания выполнения одной команды и начала выполнения следующей;
определенным, т.е. должны быть точные сведения о том, что после выполнения каждой очередной команды будет завершено выполнение алгоритма, или о том, какая следующая команда должна будет выполниться после текущей;
результативным, т.е. алгоритм должен обеспечивать возможность получения результата за конечное число шагов.
Процесс составления алгоритмов называется алгоритмизацией.
Алгоритмы могут быть заданы несколькими способами:
с помощью словесного описания,
с помощью графического описания,
с помощью псевдокода.
Словесное задание описывает алгоритм с помощью неформализованных предложений естественного языка, с использованием профессиональных понятий, терминов, зависимостей и знаков.
Графическое задание, или блок-схема, это способ представления алгоритма с помощью геометрических фигур, называемых блоками. Последовательность блоков и соединительных линий образуют блок-схему [3]. Команды алгоритма помещаются внутрь блоков, соединенных стрелками, показывающими очередность выполнения команд алгоритма. Для записи внутри блоков используется естественный язык с элементами математической символики. Схемы алгоритмов обладают большей наглядностью, чем словесная запись алгоритма. Однако эта наглядность быстро теряется при изображении большого алгоритма, в этом случае схема получается плохо обозримой.
Единой системой программной документации стандартизовано два метода описания алгоритмов программ: при помощи блок-схем и при помощи схем [3]. Общим достоинством этого метода является его независимость от языка реализации, что позволяет добиться переносимости алгоритмического обеспечения. В этом методе также реализованы все базовые структуры управления.
Блок-схемы являются самым доступным и наглядным способом алгоритмизации даного ПО.
3.2 Описание алгоритмов ПО системы обработки движения товаров и формирование отчетности
Для простоты понимания работы системы приведём логическую структуру программы - алгоритм функционирования системы, который будет представлен [16] на рисунке 3.1.
Рисунок 3.1 - Блок-схема алгоритма функционирования системы
На рисунке 3.2 расположена схема алгоритма работы программы. Входными данными представленного алгоритма является пароль, вводимый пользователем. После вода пароля данные проверяются на правильность и если все верно, то идет вызов основной формы и идет моментальная соединение с БД. Пользователю дается возможность для работы с БД. После завершение работы происходит отсоединение от БД и закрытие основной формы. В случи неправильного ввода пароля программа автоматически закрывается.
Рисунок 3.2 - Блок-схема алгоритма работы программы
На рисунке 3.3 представленная схема алгоритма работы с данными о приходе товаров. На входе подаются данные, которые вносятся в таблицу в случи неправильного ввода данных отображается сообщение, и пользователю предоставляется возможность ввести данные еще раз по желанию.
Рисунок 3.3 - Блок-схема алгоритма работы с данными о приходе товара
На рисунке 3.4 расположена схема алгоритма работы с данными. На входе идет проверка на наличие данных если данные имеются, то идет сортировка данных по списку, после того как сортировка сделана пользователю предоставляется возможность выбора данных, и перевода выбранных данных в другое окно программы, а если в наличии данных не имеется то работа с данными не возможна.
Рисунок 3.4 - Блок-схема алгоритма работы с данными (товары, предприятия, фирмы)
На рисунке 3.5 представлен алгоритм формирования отчета. На входе идет анализ необходимой информации о проделанной пользователем работы, после чего вся информация выводится на форму, после чего идет формирование ее в отдельные модули программы, в результате чего создается отчет.
Рисунок 3.5 - Блок-схема алгоритма формирования отчета
Выводы по разделу 3
В рамках данного раздела были разработаны основные алгоритмы программного обеспечения для автоматизации учета движения товаров и формирования отчетности:
алгоритм формирования отчета;
алгоритм работы с данными (товары, предприятия, фирмы);
алгоритм работы с данными о приходе товара;
алгоритм работы программы;
алгоритма функционирования системы.
4. ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ СИСТЕМЫ АВТОМАТИЗАЦИИ УЧЕТА ДВИЖЕНИЯ ТОВАРОВ И ФОРМИРОВАНИЕ ОТЧЕТНОСТИ
4.1 Системная архитектура "клиент-сервер"
Понятно, что в общем случае, чтобы прикладная программа, выполняющаяся на рабочей станции, могла запросить услугу у некоторого сервера, как минимум требуется некоторый интерфейсный программный слой, поддерживающий такого рода взаимодействие (было бы по меньшей мере неестественно требовать, чтобы прикладная программа напрямую пользовалась примитивами транспортного уровня локальной сети). Из этого, собственно, и вытекают основные принципы системной архитектуры "клиент-сервер"[16].
Система разбивается на две части, которые могут выполняться в разных узлах сети, - клиентскую и серверную части. Прикладная программа или конечный пользователь взаимодействуют с клиентской частью системы, которая в простейшем случае обеспечивает просто надсетевой интерфейс. Клиентская часть системы при потребности обращается по сети к серверной части. Заметим, что в развитых системах сетевое обращение к серверной части может и не понадобиться, если система может предугадывать потребности пользователя, и в клиентской части содержатся данные, способные удовлетворить его следующий запрос [1].
Интерфейс серверной части определен и фиксирован. Поэтому возможно создание новых клиентских частей существующей системы (пример интероперабельности на системном уровне).
Основной проблемой систем, основанных на архитектуре "клиент-сервер", является то, что в соответствии с концепцией открытых систем от них требуется мобильность в как можно более широком классе аппаратно-программных решений открытых систем. Даже если ограничиться UNIX-ориентированными локальными сетями, в разных сетях применяется разная аппаратура и протоколы связи. Попытки создания систем, поддерживающих все возможные протоколы, приводит к их перегрузке сетевыми деталями в ущерб функциональности.
Еще более сложный аспект этой проблемы связан с возможностью использования разных представлений данных в разных узлах неоднородной локальной сети. В разных компьютерах может существовать различная адресация, представление чисел, кодировка символов и т.д. Это особенно существенно для серверов высокого уровня: телекоммуникационных, вычислительных, баз данных.
Общим решением проблемы мобильности систем, основанных на архитектуре "клиент-сервер" является опора на программные пакеты, реализующие протоколы удаленного вызова процедур (RPC - Remote Procedure Call). При использовании таких средств обращение к сервису в удаленном узле выглядит как обычный вызов процедуры. Средства RPC, в которых, естественно, содержится вся информация о специфике аппаратуры локальной сети и сетевых протоколов, переводит вызов в последовательность сетевых взаимодействий. Тем самым, специфика сетевой среды и протоколов скрыта от прикладного программиста.
При вызове удаленной процедуры программы RPC производят преобразование форматов данных клиента в промежуточные машинно-независимые форматы и затем преобразование в форматы данных сервера. При передаче ответных параметров производятся аналогичные преобразования.
Если система реализована на основе стандартного пакета RPC, она может быть легко перенесена в любую открытую среду. На рисунке 4.1 представлена схема классической архитектуры клиент/сервер. На рисунке 4.2 представлена схема архитектуры клиент/сервер с “тонким” клиентом
Рисунок 4.1 - Схема классической архитектуры клиент/сервер
Размещено на http://www.allbest.ru/
Размещено на http://www.allbest.ru/
Рисунок 4.2 - Схема архитектуры клиент/сервер с “тонким” клиентом
4.2 Выбор и обоснование используемых программных средств
Выбор среды разработки обусловлен требованиями заказчика и необходимостью унификации языка разработки для последующей модификации разрабатываемого программного продукта.
Разрабатываемый программный продукт должен быть реализован в среде разработки Delphi версии 7.0 [7].
Инструментальные средства разработки, которые будут использоваться при разработке рассматриваемого программного обеспечения должны обладать следующими характеристиками [10]:
поддержка объектно-ориентированного программирования;
предоставление средств разработки приложений для операционных систем Windows 7/8/10.
Среди доступных инструментальных средств разработки программного обеспечения, которые предоставляют эти возможности, можно выделить три наиболее часто используемых:
Microsoft Visual C++ 6.0;
Borland C++ Builder 6.0;
Borland Delphi 7.0.
Для выбора наилучшей инструментальной среды из предложенного списка используем методику вариативных сетей.
Выбираем следующие критерии, по которым будем осуществлять выбор:
доступность необходимых бесплатных дополнительных библиотек;
время, затрачиваемое на разработку;
требования к вычислительным ресурсам ПК;
скорость работы разработанного программного обеспечения;
удобство эксплуатации.
Результат оценивания по выбранным критериям будет представлен в таблице 4.1.
Таблица 4.1 - Результат оценивания по выбранным критериям
|
№ критерия |
Весовой коэффициент |
Инструментальная среда разработки |
|||
|
Visual C++ 6.0 |
C++ Builder 6.0 |
Delphi 7.0 |
|||
|
1 |
5 |
3 |
3 |
5 |
|
|
2 |
5 |
4 |
5 |
5 |
|
|
3 |
3 |
3 |
4 |
4 |
|
|
4 |
4 |
5 |
4 |
4 |
|
|
5 |
3 |
4 |
4 |
4 |
|
|
Итого |
76 |
84 |
90 |
В результате проведенного исследования получено, что в данном случае наилучшей средой для разработки программного обеспечения является Borland Delphi 7.0 [4, 5, 7, 30].
БД должны отвечать следующим требованиям:
предоставлять средства разработки приложений для работы с БД;
поддерживать модель БД клиент - сервер;
поддерживать реляционную модель.
Для создания БД для нашего программного обеспечения сравним Firebird c Interbase. Для сравнения этих программных продуктов воспользуемся методом вариантных сетей. Характеристики программных продуктов будем оценивать по 5-ти бальной шкале:
скорость выполнения действий (6);
быстрый доступ к данным (5);
предоставляемые возможности (6);
защищённость данных (5).
Решение поставленной задачи выбора БД методом вариантных сетей показано в таблице 4.2.
Таблица 4.2 - Решение поставленной задачи выбора БД
|
средство разработки |
Характеристика |
Сумма |
||||
|
1(5) |
2(3) |
3(5) |
4(4) |
|||
|
Firebird |
5 |
4 |
5 |
5 |
82 |
|
|
Interbase |
3 |
4 |
3 |
4 |
58 |
В результате исследования мы получили, что лучшим инструментальным средством для разработки БД в данном случае является Firebird 2.5.
4.3 Анализ и выбор метода проектирования программных систем
Метод - это последовательный процесс создания моделей, которые описывают вполне определёнными средствами различные стороны разрабатываемой программной системы. Методы важны по нескольким причинам [2]. Во-первых, они упорядочивают процесс создания сложных программных систем. Во-вторых, они позволяют менеджерам в процессе разработки оценить степень продвижения и риск.
Обычно методы проектирования делятся на три основные группы:
метод структурного проектирования сверху вниз;
метод потоков данных;
объектно-ориентированное проектирование.
Для структурного проектирования характерна алгоритмическая декомпозиция. Следует отметить, что большинство программ написано в соответствии с этим методом. Тем не менее, структурный подход не предоставляет достаточных средств, для организации параллелизма. Структурный метод не может обеспечить создание предельно сложных систем, и он, как правило, неэффективен в объектных и объектно-ориентированных языках программирования [2].
В методе потоков данных программная система рассматривается как преобразователь входных потоков в выходные. Метод потоков данных с успехом применялся при решении ряда сложных задач, в частности, в системах информационного обеспечения, где существуют прямые связи между входными и выходными потоками системы и где не требуется уделять особого внимания быстродействию.
Объектно-ориентированное проектирование (object-oriented design, OOD) - это подход, в основе которого лежит представление о том, что программную систему нужно проектировать как совокупность взаимодействующих друг с другом объектов, рассматривая каждый объект как экземпляр определённого класса, причём классы образуют иерархию. Объектно-ориентированный подход отражает топологию новейших языков высокого уровня, таких как Object Pascal, C++ и т.д.
Для объектно-ориентированного программирования концептуальная база - это объектная модель [2]. Она имеет четыре главных элемента:
абстрагирование;
инкапсуляция;
модульность;
иерархия.
Эти элементы являются главными в том смысле, что без любого из них модель не будет объектно-ориентированной. Кроме главных , имеются ещё три дополнительных элемента:
типизация;
параллелизм;
сохраняемость.
Называя их дополнительными, имеется в виду, что они полезны в объектной модели, но не обязательны. Рассмотрим элементы объектной модели:
Абстрагирование.
Абстракция выделяет существенные характеристики некоторого объекта, отличающие его от всех других видов объектов и, таким образом, чётко определяет его концептуальные границы с точки зрения наблюдателя.
Инкапсуляция.
Инкапсуляция - это процесс отделения друг от друга элементов объекта, определяющих его устройство и поведение; инкапсуляция служит для того, чтобы изолировать контрактные обязательства абстракции от их реализации.
Абстракция и инкапсуляция дополняют друг друга: абстрагирование направлено на наблюдаемое поведение объекта, а инкапсуляция занимается внутренним устройством. Инкапсуляция, таким образом, определяет чёткие границы между различными абстракциями.
Модульность.
Модульность - это свойство системы, которая была разложена на внутренне связные, но слабо связанные между собой модули.
Иерархия.
Абстракция - вещь полезная, но всегда число абстракций в системе превышает наши умственные возможности. Значительное упрощение в понимании сложных задач достигается за счёт образования из абстракций иерархической структуры. Определим иерархию:
Иерархия - это упорядочение абстракций, расположение их по уровням.
Основными видами иерархических структур применительно к сложным системам являются структура классов (иерархия “is-a”) и структура объектов (иерархия ”part of”).
Типизация.
Типизация - это способ защититься от использования объектов одного класса вместо другого или, по крайней мере, управлять таким использованием.
Параллелизм.
Параллелизм позволяет различным объектам действовать одновременно. Параллелизм - это свойство, отличающее активные объекты от пассивных.
Сохраняемость.
Сохраняемость - это способность объекта существовать во времени, переживая породивший его процесс, и (или) в пространстве, перемещаясь из своего первоначального адресного пространства.
В ходе разработки алгоритмов АС учета движения товаров и формирование отчетности, были использованы принципы объектно-ориентированного подхода, что положительно сказалось на надежности, стабильности, отказоустойчивости вcей системы в целом.
4.4 Архитектурное проектирование
Перед кодировкой программы необходимо продумать ее архитектуру, чтобы знать в каких модулях будут в дальнейшем находиться отдельные части программы. Естественно, что необходимо учесть особенности задач, выполняемых программой. Поэтому этот вопрос очень важен, т.к. логически правильная организация архитектуры, позволит избежать накладных расходов, связанных с дополнительными сложностями в кодировке, а также повысит производительность программы [33, 21].
При дроблении программы на модули необходимо помнить следующие правила:
недостаточное дробление на процедуры может затруднить читабельность программы. Значительно замедлить процесс написания программы и при необходимости доработок, которые могут понадобиться через некоторое время, сделать их очень трудоемкими;
излишнее дробление вызовет хоть и незначительное, но все же неприятное падение скорости работы программы. Поэтому при написании программ, к которым выдвигаются повышенные требование по производительности, нельзя увлекаться разбиением программы на отдельные блоки.
При выполнении дробления необходимо придерживаться «золотой середины» и исходить из удобства кодировки и не забывать о производительности создаваемого программного продукта.
4.5 Декомпозиция проекта
Проектирование производится методом функциональной декомпозиции.
Сущность структурного подхода к проектированию и разработке ПО - это декомпозиция (разбиение) на автоматизируемые функции, функциональные системы, которые также разбиваются на подфункции, подзадачи, конкретные процедуры. Но обязательно все составляющие компоненты должны быть взаимосвязаны по управлению, должна быть выполнена информационная стыковка компонентов.
Существенными для структурного подхода являются перечисленные ниже принципы:
абстрагирования - заключается в выделении существенных аспектов системы и отвлечения от несущественных;
формализации - необходимости строгого методического подхода к решению проблемы;
непротиворечивости - обоснованности и согласованности элементов;
структурирования данных - данные должны быть структурированы и иерархически организованы.
Контекстные диаграммы - это диаграммы верхних уровней, определяют основные процессы или системы ПО с внешними входами и выходами. Они детализируются с помощью диаграмм нижнего уровня до тех пор, пока не будет достигнут такой уровень декомпозиции, на котором процессы становятся элементарными и детализировать их далее невозможно.
Декомпозиция проекта в виде логической структуры представлена на рисунке 4.3.
Краткое описание структуры программы.
Модуль «каталог» включает в себя такие подмодули как подразделения выбираемые нами в начале, чтобы при дальнейшей нашей работе в программе мы могли пользоваться выбранным нами подразделение. Второй подмодуль - это товары в свою очередь этот подмодуль имеет такие свойства, как удалять и вносить информацию. Третий подмодуль - это контрагенты имеет такое же свойство, как и у подмодуля товары. Четвертый подмодуль - это пользователи имеет такие свойства, как вносить нового пользователя, удаление, и выбор назначения.
Модуль, который описывает приход товаров, имеет такие свойства как вносить данных, так и их удаление.
Размещено на http://www.allbest.ru/
Размещено на http://www.allbest.ru/
Рисунок 4.3 - Структура программы
Модуль перемещения имеет свойства вносить внутренние перемещения, удаление их, заполнение всех необходимых полей и обновление их;
Модуль расходов имеет систему поиска определенных данных, выводимость расходов и удаление;
Модуль платежей имеет свойства вносить входные платежи, удаление, вносить исходные платежи и удаление;
Модуль отчетности включает в себя полную отчетность о проделанной работе;
Метод отображения товаров и цен показывает какое количество товаров продается и по какой цене, и в каком количестве;
Модуль отображающий информацию за определенное время работы обладает свойствами показать за какой период сколько было сделано операций и на какую сумму;
Методы отображения информации о товаре его маркировки помогает правильно и четко выбрать товар нужный для заказчика;
Модуль Формирования отчета показывает полную, четкую информацию о проделанной работе;
Получение полной информации о клиенте, то есть идет полная запись данных о том или ином клиенте;
Оформление отчета он разбивается на подпункты которые четко показывают все информацию о движении товаров и средств.
Входные данные ПО
Входные данные вводятся с клавиатуры: имя пользователя и его пароль, в случае неправильного ввода имени пользователя или пароля программа автоматически закрывается.
Все входные данные в программе вводятся с клавиатуры: название предприятия (фирмы), название группы товара, подразделения, стоимость товара и т. д.
Информация содержащаяся в БД [23, 24];
Дату (день, месяц, год) пользователь может задать при нажатии клавиши мыши на поле дата.
Выходные данные ПО
формированный отчет о проделанной работе
Результат выполнения запросов на экране.
На рисунке 4.4 представлена общая функциональная схема ПО.
Рисунок 4.4 - Общая функциональная схема ПО автоматизированной системы движения товаров и формирования отчетности
4.6 Проектирование интерфейса
В ходе выдачи задания на АОЗТ «Новый Стиль Украина» Заказчиком были выдвинуты требования на разработку интерфейса специально для начальника отдела продаж. Интерфейс должен быть удобным и соответствующий требованиям пользователям. Более или мене выяснить простату и быстро действие интерфейса, например какого вида должны быть окна в программе, как должны вводится данные, как должны быть расположены все кнопки на панели и как должен выдаваться отчет о проделанной работе [28].
На рабочей форме ПО должны располагаться закладки, которые обязаны включать в себя полную информацию по выбранной закладке.
Выводы по разделу 4
В рамках данного раздела методом вариантных сетей Фуксмана был проведен выбор и обоснование программно-инструментальных средств разработки ПО. В качестве средства для разработки серверной части системы была выбрана СУБД Firebird 2.5. В качестве средства разработки клиентской части системы была выбрана среда Delphi 7.0.
В ходе выполнения проектирования ПО была проведена декомпозиция задач ПО и разработана его структура. Автоматизированная система «Market» состоит из основного модуля, модуля ввода пароля, модуля соединения с БД, модуля учета расходов, модуля формирования отчета.
5. ВЕРИФИКАЦИЯ И ВАЛИДАЦИЯ ПО СИСТЕМЫ АВТОМАТИЗАЦИИ УЧЁТА ДВИЖЕНИЯ ТОВАРОВ И ФОРМИРОВАНИЕ ОТЧЕТНОСТИ
Для проверки правильности результатов работы программного продукта после завершения работы над ним проводят тестирование, верификацию, испытания [31, 13], Приложение Б.
5.1 Проектирование процессов тестирования и отладки программных средств
Верификация ПО - это действия по проверке, инспекции, тестированию, контролю, ревизии или иному установлению и документированию соответствия элементов, процессов, устройств либо документов определенным требованиям.
Система «Учет движения товаров и формирование отчетности» состоит из двух частей: клиентской и серверной части.
Цель верификации серверной части:
проверка на хранение информации в базе данных;
проверка процедуры для изменения состояния базы данных;
проверка на обеспечение целостности данных;
проверка учета товаров и средств.
Цель верификации клиентской части приложения:
проверка управления работы системы;
проверка контроль входных данных;
проверка составление отчета.
Верификация необходима для гарантии качества продукта.
Процесс верификации включает в себя:
процедуры проверок ПО;
проверка, что требования к ПО являются трассируемыми к требованиям пользователя;
проверка, что компоненты проекта являются трассируемыми к требованиям ПО;
формальные доказательства и алгоритмы проверки;
тестирование.
Где это осуществимо, должна быть сделана попытка формального дедуктивного доказательства корректности ПО.
Формальные методы обладают согласованной системой обозначений с четко определенной семантикой и исчислением, делающим возможным доказательство. Первое из указанных свойств присуще и другим методам спецификации ПО, но второе ставит их особняком. Если формальный метод может с уверенностью продемонстрировать, что нечто является корректным, то отдельная верификация не нужна.
Валидация ПО - это оценка ПО в конце процесса разработки ПО для подтверждения соответствия требованиям пользователя. Следовательно, валидация - это сквозная верификация.
Целью верификации программного продукта является:
проверка его на соответствие поставленным целям и задачам;
выявление ошибок при работе с базами данных.
Объект верификации и валидации - программное обеспечение автоматизированной системы «Учета движения товаров и формирование отчетности».
5.2 Цель разработки
сократить время доставки и отправки товара;
автоматизировать процесс обработки продукции;
повысить эффективность работы отдела и предприятия.
5.3 Название разработки
Программное обеспечение системы автоматизированного учета движения товаров и формирование отчетности на АОЗТ «Новый Стиль Украина».
Ожидаемые результаты:
занесение, удаление информации, просмотр продаж и движений товаров за предыдущие месяцы и года, формирование полного отчета о проделанной работе, генерирование документации в Word, Excel и вывод на печать;
формирование прайсов, истории товаров, движения товаров, прибыли, взаиморасчетов;
полное занесение данных о платежах, расходов и приходов товаров и денежных средств.
5.4 Функциональное назначение
Система «Market» состоит из двух частей: клиентской и серверной части.
Серверная часть содержит:
базу данных, которая предназначена для хранения информации о предприятии, а также непосредственно об отделе продаж;
процедуры для изменения состояния базы данных.
Клиентская часть приложения должна выполнять следующие функции:
обеспечивать занесение информации о предприятиях и фирмах все имеющеюся информацию вплоть до номера телефона с дальнейшей возможностью ее модификации и возможным удалением.
вывод информации о сумме, которую фирма затратила на данную сделку;
составление полного отчета о проделанной работе.
5.5 Эксплуатационное назначение
Для данной системы предусмотрено два защищенных режима.
Режим администратора предназначен для внесения, модификации, удаления информации о проделанной работе.
Режим пользователя предназначен для просмотра информации непосредственно не только за проделанную работу в этот срок, но и за сроки которые были сделаны ранее; предоставляется возможность удаления и внесение записей в программу; формирование отчетов включает в себя: Наличие товара, прайсы, движения товаров, история товаров, прибыль, взаиморасчет.
5.6 Требование к аппаратному обеспечению
Разработанный программный продукт должен функционировать на компьютере со следующей минимальной конфигурацией [10]:
процесор - Celeron 850 MHz и совместимые;
объем оперативной памяти - 64 Mb;
не менее 100 Mb свободного места на жестком диске.
5.7 Обоснование выбора метода тестирования
Существуют четыре метода тестирования: восходящий, нисходящий, модифицированный нисходящий, метод большого скачка. Оценить эти четыре стратегии и найти лучшую трудно, потому что «наилучший» подход зависит от конкретной программы и её реализации. С точки зрения надежности программного обеспечения эти стратегии можно оценить по семи критериям.
Так как при проектировании программного продукта в рамках данной работы предполагается использовать нисходящий метод, то в качестве метода тестирования выбираем метод восходящего тестирования.
Тестирование
Тестирование - процесс выполнения программного продукта или его модуля в специальных условиях с наблюдением и фиксированием результатов с целью оценки состояния этого продукта или модуля. Роль тестирования состоит в том, чтобы определить местонахождение ошибок в программе [31, 13].
Важным аспектом тестирования является последовательность слияния отдельных модулей в программу. Имеется несколько подходов, среди которых следует выделить восходящее тестирование, нисходящее тестирование, метод большого скачка, метод сандвича и их модифицированные версии. Модифицированный метод сандвича рекомендуется для тестирования больших систем, а восходящий подход - для тестирования средних и малых систем.
Следует придерживаться следующих принципов тестирования:
основная цель теста - выявить ошибки в работе программы;
тестирование должно выполняться внешней группой;
тесты должны быть задокументированы и сохранены для повторного использования;
ожидаемые результаты каждого теста должны быть заранее описаны, а полученные - детально изучены;
тесты должны охватывать как правильные, так и неправильные значения входных данных;
при разработке программы необходимо стремиться к упрощению её тестирования;
цикл тестирования должен быть выполнен полностью - от постановки целей до изучения результатов.
Тестирование ПО включает следующие процессы [31]:
планирование основного подхода и распределение ресурсов;
детализация основного подхода для различных видов тестов при проектировании тестов;
определение входов, ожидаемых результатов и условий выполнения при определении пакета тестов;
установление последовательности действий, проводимых персоналом в процессе тестирования;
регистрация выполнения тестовых процедур в тестовом отчете.
Система тестов должна разрабатываться по тем же стандартам, что и выпускаемое ПО. Поэтому система и данные тестов должны быть задокументированы и подчинены процедурам управления конфигурацией. Это позволяет отслеживать процесс тестирования и дает возможность позднее вновь использовать систему и данные тестов для проверки того, что работоспособность и характеристики ПО не были нарушены при модификациях. Это называется "возвратным" тестированием.
Рассмотрим такие виды тестирования:
автономное тестирование;
интеграционное тестирование;
системное тестирование.
На рисунке 5.1 представлена общая схема верификации программного продукта. При разработке данного программного продукта, были проведены автономные, интеграционные и системные тесты.
Рисунок 5.1 - Общая схема верификации ПО
План проведения системного тестирования
Объект испытания: программное обеспечение автоматизированной системы «Market» [31]: клиентская и серверная часть.
Цель тестирования сервера:
проверка совместимости системы;
тестирование пользовательского интерфейс.
Тестирование производительности
Цель - показать несоответствие программы требуемой производительности.
Тестирование требований к памяти
Цель - показать, что предельные объемы памяти недоступны программе.
Тестирование интерфейса пользователя
Цель - показать некорректность организации интерфейса.
Тестирование удобства эксплуатации.
Цель - показать несоответствие между целями ПО и удобством эксплуатации.
Критерии окончания системного тестирования:
количество екранних форм - одна главная форма
быстродействие формирования отчета - 40 мс.
На проведение системного тестирования предоставляется 80 часов машинного времени.
После исправления ошибок предполагается регрессионное тестирование с целью исключения новых ошибок.
План проведения интеграционного тестирования
Объект тестирования: модули системы и взаимосвязь между ними.
Цель: проверка информационных связей модулей, нахождение ошибок в интерфейсе между модулями, в интерфейсах между функциями и модулями.
Оценив преимущества и недостатки методов для тестирования данного программного продукта была выбрана инкрементная технология. Но четкой стратегии (восходящей или нисходящей) нет, так как обычно каждый модуль, по возможности, тестируется сразу после написания, в результате последовательность тестирования одних частей программы может оказаться восходящей, а других - нисходящей.
Критерий окончания - отсутствие ошибок в информационных связях при прохождении восходящего тестирования, внесение записи в базу данных, последовательная выдача информации.
Способ реализации тестирования - пошаговый, то есть в порядке подключения определенного модуля. Стратегия тестирования - восходящая, так как большая вероятность возникновения ошибки на модулях нижнего уровня.
Последовательность выполнения тестирования:
модуль входа в систему;
модуль каталоги;
модуль приходов товаров и средств;
модуль перемещения товаров и средств;
модуль расходов, которые проведены за период проведения сделок;
модуль платежей;
модуль формирования полного отчета о проделанной работе.
На проведение интеграционного тестирования предоставляется 20 часов машинного времени.
После исправления ошибок предполагается регрессионное тестирование с целью исключения новых ошибок.
План проведения автономного тестирования
Цели тестирования для серверной части:
проверка логики программы;
определение ошибок в запросах к базе данных;
определение ошибок в хранимых процедурах.
Цели тестирования для клиентской части:
определение ошибок в процедуре составления отчета;
определение ошибок в процедурах занесения информации в базу данных;
модификация информации в базе данных;
удаление информации из базы данных.
Объекты тестирования серверной части:
хранимые процедуры;
триггера базы данных;
база данных.
Объекты тестирования клиентской части:
управляющий модуль;
модуль входа в систему;
модуль занесения, модификация информации о фирме;
модуль занесения, модификация информации о предприятиях;
модуль занесения, модификация информации о проделанной работе;
модуль выдачи отчетности.
Для проведения тестирования выбран метод «белого ящика». Стратегия тестирования методом «белого ящика», или стратегия тестирования, управляемого логикой программы, позволяет исследовать внутреннюю структуру программы.
В таблице 5.2. содержится длительность проведения работ по тестированию.
Таблица 5.2 - График проведения работ по тестированию
|
№ |
Вид работы |
Продолжительность (дни) |
Сущность работы |
Цель работы |
|
|
1 |
Тестирование программного продукта |
2 |
Тестирование логики программы на правильность занесении данных |
Проверка на удобство интерфейса |
|
|
2 |
Тестирование режима смены пользователя |
1 |
Тестирование логики программы на правильность занесении данных |
Проверка на требование к ПО |
|
|
3 |
Тестирование модуля «Каталоги» |
1 |
Тестирование системы |
Проверка проектирования реализации ПО |
|
|
4 |
Тестирование интерфейса |
1 |
Тестирование режима ввода и вывода данных пользователю |
Проверка корректности ввода и вывода данных |
|
|
5 |
Интеграционное тестирование |
2 |
Тестирование логики программы на установление связей между интерфейсом и модулями |
Проверка связи интерфейса и модулей |
|
|
Всего |
7 |
5.8 Резюме по ресурсам
Для тестирования были использованы следующие аппаратные средства (конфигурация ПК) [28]:
процессор Intel Celeron 900 MHz;
ОЗУ 256;
жёсткий диск: 40 GB.
Программные средства использовавшиеся при тестировании:
Тестирование программы при работе c «Market»
Delphi 7
Тестирование интерфейса
Delphi 7
В таблице 5.3 содержится обязательное количество тестов для внесения информации о проделанной работе.
Таблица 5.3 - Модуль занесения информации о проделанной работе
|
№ п/п |
Параметры |
Диапазон значений |
Признак наличия |
Действие |
|
|
1 |
2 |
3 |
4 |
||
|
1 |
Фирма или предприятие. Вид товара. Сумма, на который был приобретен товар |
12 символов 1..30 символов 0..3,4е+38 |
+ + + |
Запись данных в базу данных |
|
|
2 |
Фирма или предприятие |
12 символов |
- |
Сообщение об ошибке |
|
|
3 |
Фирма или предприятие Вид товара. Сумма, на который был приобретен товар |
12 символов 1..30 символов 0.. 3,4е+38 |
+ - + |
Сообщение об ошибке |
Все данные должны быть проверены
на диапазон:
вид денежных затрат должен содержать больше одного и меньше тридцати символов;
на корректность:
фирма или предприятие не должен содержать цифр.
В таблице 5.4 содержаться обязательное количество тестов для внесения информации о заказанной продукции.
Таблица 5.4 - Модуль занесения информации о заказанной продукции
|
№ п/п |
Параметры |
Диапазон значений |
Признак наличия |
Действие |
|
|
1 |
2 |
3 |
4 |
||
|
1 |
Меблированный номер Название заказа Место хранения срок Сумма товара |
12 цифр 1..30 символов 1..40 символов 1..25 символов 0.. 3,4е+38 |
+ + + + + |
Запись в базу данных |
|
|
2 |
Меблированный номер |
12 цифр |
- |
Сообщение об ошибке |
|
|
3 |
Меблированный номер Название заказа |
12 цифр 1..30 символов |
+ - |
Сообщение об ошибке |
|
|
4 |
Меблированный номер Название заказа Место хранения |
12 цифр 1..30 символов 1..40 символов |
+ + - |
Сообщение об ошибке |
|
|
5 |
Меблированный номер Название заказа Место хранения срок Сумма товара |
12 цифр 1..30 символов 1..40 символов 1..25 символов 0.. 3,4е+38 |
+ + + + - |
Сообщение об ошибке |
Все данные должны быть проверены
на диапазон:
место хранения должно содержать больше одного и меньше сорока символов;
на корректность:
сумма товара не должна содержать символы.
Тестирование методом «черного ящика». Метод эквивалентных разбиений является одним из самых популярных способов тестирования по методу «черного ящика».
Таблица 5.5 - Информация о классах эквивалентности
|
Входные условия |
Правильный (допустимый) класс эквивалентности |
Неправильный (недопустимый) класс эквивалентности |
Особые условия |
|
|
Ввод данных |
1. Внесены все данные в таблиц |
1. Не внесены все данные |
1. Ввод всех пустых строк 2. Ввод какой либо пустой строки |
|
|
2. Корректно введены данные |
2. Некорректно введены данные |
1. Ввод цифр 2. Ввод символов, не являющихся буквами |
Критерием окончания тестирования является формирование записи.
На проведение автономного тестирования предоставляется 80 часов машинного времени.
5.9 Ответственность
Ответственность разработчика состоит в устранении ошибок и помощи тестировщику. На тестировщика возлагается обязанность составления планов тестирования, прогона тестов, воспроизведения ошибок, составление отчета по результатам.
Выводы по разделу 5
Проектирование тестирования было выполнено для серверной и клиентской части
Для автономного тестирования использовались методы «белого ящика» и «черного ящика».
Для реализации тестирования интеграционного тестирования предполагалось использовать восходящую стратегию.
Систематизированы параметры для тринадцати таблиц.
Обязательно выполнение тестирования для 13 наборов параметров.
Диапазоны и корректность данных должны быть протестированы дополнительными тестами.
Определены критерии завершения тестирования.
В процессе тестирования ПО были найдены ошибки, которые были непосредственно исправлены. В результате устранения этих ошибок был получен устойчиво работающий ПО с высоким уровнем надёжности.
В результате автономного тестирования программных модулей было определено, что все модули выполняют функции, которые были определены для них при проектировании и то, что они выполняют эти функции намеченным способом.
В результате интеграционного тестирования было проверено, что необходимые потоки управления были реализованы и все данные, которыми ПО обменивается через интерфейс соответствуют своим спецификациям.
Подобные документы
Характеристика предприятия ООО "КСК-Электро". Экономическая сущность задачи автоматизации отдела продаж. Бизнес-концепция проекта, системные и функциональные требования к информационной системе; архитектура прикладных программ; эффективность инвестиций.
дипломная работа [1,7 M], добавлен 20.03.2013Анализ архитектуры информационной системы, в структуру которой входят системы файл-сервер и клиент-сервер. Сравнение языков запросов SQL и QBE. Принципы разработки приложений архитектуры клиент-сервер при помощи структурированного языка запросов SQL.
курсовая работа [88,9 K], добавлен 11.04.2010Характеристика ООО "Евросеть", анализ места учета продаж товаров в его деятельности и использования вычислительной техники в учете. Особенности реализации задач автоматизации учета продажи товаров в ООО "Евросеть", оценка ее экономической эффективности.
дипломная работа [1,4 M], добавлен 30.08.2010Анализ решений по автоматизации аптечной деятельности. Разработка автоматизированной системы формирования заказов. Проектирование многопользовательского доступа к данным. Организация сетевой работы. Реализация протокола взаимодействия сервера и клиента.
дипломная работа [623,8 K], добавлен 19.01.2017Автоматизация работы кредитного отдела банка, решений бизнес-процесса выдачи кредитов и карт. Определения методологии и языка IDEF0, программа Dreamweaver. Правильно построенные и действительные документы XML. Создание отчётов с помощью JasperReports.
дипломная работа [1,9 M], добавлен 22.06.2013Сущность учета и его особенности в торговле. Проблемы создания эффективной системы управления предприятием. Две группы СУБД, используемые в системах автоматизации. Применение систем комплексной автоматизации. Методика разработки программы учета продаж.
курсовая работа [447,0 K], добавлен 08.03.2011Создание программного средства для автоматизации процесса управления учетом клиентов. Алгоритмы и модели базы данных; документооборот бизнес-процесса "работа отдела продаж", задачи и функции менеджера. Системные требования, экономическое обоснование.
курсовая работа [1,4 M], добавлен 18.03.2013Анализ существующих решений по автоматизации предметной области. Выбор методологии проектирования информационной системы. Сбор и спецификация, анализ, моделирование и аттестация требований. Возможные неисправности и сопровождение информационной системы.
курсовая работа [645,2 K], добавлен 26.05.2015Архитектура "клиент-сервер". Системный анализ базы данных "Газета объявлений", ее инфологическое и физическое проектирование. Программирование на стороне SQL-сервера. Разработка клиентской части в Borland C++ Builder 6.0 и с помощью Web-технологий.
курсовая работа [1,3 M], добавлен 07.07.2013Разработка модели системы тестирования пользователей с применением технологии "клиент-сервер". Требования к программному изделию и документации. SADT диаграмма системы тестирования до и после автоматизации. Настройка SQL-сервера и установка программы.
курсовая работа [1,5 M], добавлен 22.01.2013
