Реферат: Автоматизированная справочно-информационная система учета и контроля поставок на предприятии

Пароль доступа Khai.

В случае, если соединение прошло успешно, то пользователь допускается к работе с АСИС.

4.4.2 Работа с режимами АСИС

Рабочее окно АСИС выглядит следующим образом (рис 4.3):

Рис 4.3 Рабочая область АСИС

Ниже описана работа с АСИС.

Работа с договорами

Работа с договорами включает в себя:

-  Работа с поставщиками;

-  Работа с договорами;

-  Работа с товарами;

-  Работа с заключенными договорами;

-  Работа с ассортиментом договоров;

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

-  Работа с заявками;

-  Работа со счетами;

-  Работа с заказами.

     Для автоматизации использования АСИС “Учет поставок” реализована возможность печати бланков документов договора, заявки, заказа.

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

    Редактирование происходит при нажатии клавиши Enter на выбранной записи. Происходит автоматическое изменение всех полей других таблиц связанных с номером редактируемого договора. Это изменение необходимо для поддержания ссылочной целостности в БД.

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

Работа с поставщиками

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

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

    Для редактирования таблицы “поставщики” нужно выбрать запись для редактирования , нажать клавишу Enter и изменить необходимую информацию. Измененные атрибуты поставщика автоматически изменяются в других таблицах.

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

Работа с товарами

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

      Добавление новой записи в таблицу осуществляется путем ввода информации о товаре в строки таблицы товары. Редактирование – нажатием клавиши Enter на редактируемой строке и изменении информации.

Удаление – двойным щелчком мыши на удаляемой строке.

Работа с заключенными договорами

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

Работа с ассортиментом договоров

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

Работа с заявками

     Работа с заявками представляет собой работу с тремя закладками:

-  Заявка;

-  Ассортимент заявки;

-  Все заявки.

      Закладка “заявка” содержит таблицу с данными о заявках, которые сделал заказчик поставщику по одному из заключенных договоров. Таблица заявка содержит атрибуты: номер заявки, номер договора, дата заявки. Заполнение всех атрибутов является обязательным. Номер договора один из заключенных, в противном случае возникает ошибка.

     Пользователь имеет возможность добавлять, редактировать и удалять записи.

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

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

     Удаление, добавление и редактирование записей происходит аналогично закладке заявка.

Работа со счетами

     Для работа со счетами предлагается закладка “счет-фактура”, которая содержит таблицу счета и поле для определения оптимального счета. Таблица “счета” включает атрибуты: номер счета, номер заявки, номер договора, сумма счета. Все атрибуты обязательны для заполнения. Ассортимент счета соответствует ассортименту заявки. На закладку выводится информация (либо предоставляется для ввода) только по одному из заключенных договоров, номер которого выбран в таблице ассортимент договоров.   

Работа с заказами

     Для работы с заказами предлагается две закладки:

-  Заказ;

-  Все заказы.

В закладку “заказ” включены таблица “заказ” с атрибутами: номер

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

     В случае если долг по оплате поставок отсутствует, то поле “долг” принимает значение “нет”.

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

Печать.

     Закладка “печать”  используется для печати бланков договоров, заявок, заказов. Для выбора документа, который необходимо напечатать следует выбрать соответствующий флажок.

5. Испытания программного продукта.

          Надежность программного обеспечения (ПО) есть вероятность его работы без отказов в течении определенного периода времени, рассчитанная с учетом стоимости для пользователя каждого отказа [9] . Надежность программного обеспечения как определяющий элемент его качества закладывается на этапе разработки и проектирования, реализуется на этапе реализации ПО [11]. Выбор критериев, которыми должна определятся надежность ПО, отыскание оптимальной по отношению к этим критериям его структуры, выбор режима работы ПО – вот далеко не полный перечень  тех проблем,  которые должны быть решены на этапе создания и реализации ПО до его эксплуатации. Поэтому для обеспечения надежности ПО зачастую используют такие термины, как доказательство, тестирование, отладка, контроль и испытание, которые часто используются как синонимы, поэтому приведём эти определения:

¨   Тестирование (testing) - процесс выполнения программы или части программы, с намерением или целью найти ошибки;

¨   Доказательство (proof) - попытка найти ошибки в программе безотносительно к внешней для программы среде. Большинство методов доказательства предполагает формулировку утверждений о поведении программы и затем вывод и доказательство математических теорем о правильности программы.

¨   Контроль (verification) -  попытка найти ошибки в тестовой, или моделируемой среде;

¨   Испытание (validation) - попытка найти ошибки, выполняя программу в заданной реальной среде;

¨   Аттестация (certification) - авторитетное подтверждение правильности программы. При тестировании с целью аттестации выполняется сравнение с некоторыми заранее определённым стандартом;

¨   Отладка (debugging) не является разновидностью тестирования. Хотя “отладка” и “тестирование” часто используются как синонимы, под ними подразумеваются разные виды деятельности. Тестирование – деятельность, направленная на обнаружение ошибок; отладка направлена на установление точной природы известной ошибки.

5.1. Справочные документы.

Испытания программного продукта производятся  с использованием следующей справочной литературы:

1.   ГОСТ Р28195-89  Оценка качества программных средств.

2.   ISO/IEC 9126 : 1991 Information Technology Software Product Quality Characteristics.

3.   Стандарты разработки ПО ESA PSS-05-0-1991.

5.2. Краткий обзор верификации .

Верификация обозначает:

¨   действие по проверке, инспекции, тестированию, контролю процессов, определённых требованиями ANSI –78

¨   процесс определения: удовлетворяет ли продукт данной фазе ЖЦ ПО требованиям, сформулированным на протяжение предыдущих фаз;

¨   формальное доказательство корректности программы.

¨   верификация необходима для обеспечения качественных характеристик продукта.

        Ряд определений, приведённый ниже, охватывает вторую сторону тестирования: типы ошибок, которые предполагается обнаружить, и стандарты, с которыми сопоставляются тестируемые программы.

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

¨   Тестирование сопряжений – контроль сопряжений между частями системы (модулями, компонентами подсистемами).

¨   Комплексное тестирование  – контроль и/или испытание системы по отношению к исходным целям. Комплексное тестирование является процессом контроля, если оно выполняется в моделируемой среде, и процессом испытания, если выполняется в среде реальной, жизненной.

¨   Тестирование приемлемости – проверка соответствия программы требованиям пользователя.

5.3. Процессы верификации.

Верификацию, тестирование и испытания разрабатываемой системы  будем производить в соответствии со стандартами ES-PSS-05.

Процесс верификации включает в себя:

¨   технические проверки, сквозные контроли и инспекции ПО;

¨   проверки того, что требования к ПО соответствуют требованиям заказчика;

¨   проверки того, что требования к проекту являются соответствующими требованиям ПО;

¨   автономное тестирование;

¨   системное тестирование;

¨   приёмочное тестирование;

¨   ревизии.

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

5.3.1.  Сквозной контроль.

Эффективный  прием оценки детальных внешних спецификаций – подготовить тесты и затем воспользоваться детальными внешними спецификациями для имитации поведения системы. Этот процесс часто называют сквозным контролем [10]  или прослеживанием.

Для проверки отдельных внешних функций должны быть выполнены следующие действия. Кто-то (не автор спецификаций) должен сначала построить “тесты на бумаге” для этой функции, т.е. список конкретных входных данных (допустимых и недопустимых). Вместе с автором спецификаций затем имитируют ввод этих данных в cистему, используя спецификации как описание поведения системы. Если оказывается, что спецификации описывают выходные данные или преобразование для какого-то набора входных данных недостаточно полно и правильно, это означает, что обнаружена ошибка.

          Важно отметить, что цель всякого такого сеанса сквозного контроля – обнаружить ошибки, но не исправлять их сразу.

Используя данный прием тестирования, были протестированы запросы осуществляемые к базе данных (БД) созданной системы. Для этого на вход подавались различные запросы к БД (См. приложение B).

В результате проведения теста было зафиксировано, что корректные запросы обрабатываются БД согласно  предполагаемому результату, время обработки запроса отвечает указанному в ТЗ (не более 3 секунд при минимальной конфигурации, процессор Intel 586). При попытке осуществить некорректный запрос к БД не всегда выдаются сообщения об ошибках, либо не указано какие действия необходимо предпринять для правильной работы системы.

5.3.2. Трассировка требований к ПО и требований пользователя.

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

          Соответствие требований проверялось на ранних стадиях ЖЦ программного продукта. Используя матрицу трассировки было установлено полное соответствие между требованиями пользователя и требованиями к ПО, неоднозначности в требованиях обнаружены не были.  (см. ТЗ “Матрица трассировки”).

5.3.3. Тестирование внешних функций.

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

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

Тестирование функций – процесс контроля, поскольку оно обычно выполняется в моделируемой среде (в противоположность обстановке реальной). Другими словами, тестирование функций обычно выполняется для компонент системы прежде, чем она будет собрана воедино. Например, могут быть недоступны определённые устройства ввода-вывода, вследствие чего потребуется написать специальные программы для имитации их работы, могут отсутствовать или быть неполными отдельные компоненты программного обеспечения, что также потребует имитации или применения вспомогательных программ.

Метод функциональных диаграм [11], предлагает способ перевода спецификаций, написанных на естественном языке, на язык формальный. Это способствует проектированию высокорезультативных тестов, не страдающих избыточностью, и обнаруживающих случаи неполноты и неоднозначности во входных спецификациях. Метод предполагает анализ семантического содержания внешних спецификаций и перевод их на язык логических отношений между входными данными (ситуациями) и выходными данными и преобразованиями (эффектами), представленных в виде логической диаграммы (“и- или”-графа), называемой функциональной диаграммой.

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

Последовательность применения метода:

¨   Первый шаг: разбить внешние спецификации на отдельные функции, комбинаторные свойства которых и должны тестироваться;

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

Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10