Разработка автоматизированной справочно-информационной системы "Супермаркет"

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

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

Товарная политика формирует запасы товара на предприятии. Поэтому при формировании заказа уместно рассмотреть политику предприятия в области управления запасами. В связи с этим обратимся к перспективному методу управления запасами «точно в срок».

"Точно в срок" - это философия, применяется в торговле. Ядром этой философии является точка зрения, что все запасы нежелательные и они должны быть устранены или сведены к минимуму. Традиционная же политика представляет собой систему торговли, при которой товар является "на всякий случай" для того, чтобы можно было удовлетворить непредвиденный на нее спрос. Такая практика очень дорога через содержание большой площади складских помещений для хранения запасов.

Цель этого метода - заказывать и отгружать товар точно в срок для ее дальнейшей реализации.

Особое значение для реализации принципа «точно в срок» имеют такие аспекты, как закупки вместе с контролем качества.

Принцип «точно в срок» применяется к закупкам для сокращения или устранения запасов. Предполагается наличие нужного товара в соответствующем товарно-распределительном центре в необходимое время и доставка его на следующий день после заказа, причем в хорошем состоянии и без потерь.

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

3.2 Обобщенная модель управления запасами

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

- Какое количество товара заказывать?

- Когда заказывать?

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

Таким образом, решение обобщенной задачи управления запасами определяется следующим образом;

- В случае периодического контроля состояния запасов следует обеспечить поставку нового количества товарных ресурсов в объеме размера заказа через равные промежутки времени.

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

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

Рис. 1. Схема суммарных затрат системы управления запасами.

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

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

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

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

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

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

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

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

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

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

Хотя характер спроса является одним из основных факторов при построении модели управления запасами, есть и другие факторы, влияющие на выбор типа модели. К их числу относятся:

- Запаздывание поставок или сроки выполнения заказов. После размещения заказов он может быть поставлен немедленно или потребуется некоторое время на его выполнение. Интервал времени между моментом размещения заказа и его поставкой называется запаздыванием поставки, или сроком выполнения заказа. Эта величина может быть детерминированной или случайной.

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

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

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

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

- Число видов товара. В системе управления запасами может фигурировать более одного вида товара. Это фактор учитывается при условии наличия некоторой зависимости между различными видами товара. Так, для различного товара может использоваться то же самое складское помещение.

4. Разработка АСИС «Супермаркет»

4.1 Анализ и выбор программных средств разработки АСИС

Определения:

АСИС -- Автоматизированная справочно-информационная система

ПО -- Программное Обеспечение

ОС -- Операционная Система

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

Ё создавать интерфейс, используя стандартные компоненты;

Ё передавать управление различным процессам, в зависимости от состояния системы;

Ё создавать оболочки для баз данных, как и сами базы данных;

Ё разрабатывать более надежное ПО, путем обработки исключительных ситуаций возникающих при некорректной работе ПО.

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

Ё поддержка объектно-ориентированного стиля программирования;

Ё возможность использования CASE-технологий, как для проектирования разрабатываемой системы, так и для разработки моделей реляционных баз данных;

Ё использование визуальных компонентов для наглядного проектирования интерфейса;

Ё поддержка БД;

Ё возможность использования алгоритмов реляционной алгебры для управления реляционными базами данных;

Ё возможность синхронизации составных частей проекта (предоставляется при разработке больших программных комплексов).

Вышеперечисленными свойствами обладают языки программирования, например: Delphi, Visual C++, Borland С++ Biulder, Visual FoxPro и другие.

Каждое из этих средств содержит весь спектр современного инструментария, который был перечислен ранее. Главное отличие состоит в области использования рассматриваемых средств. Так Visual C++ обычно используется при разработке приложений предназначенных для работы с ОС Windows, и выполняющих большое количество вычислений. Одним из недостатков данного средства разработки приложений является высокое требование к аппаратным ресурсам при разработке программного обеспечения, недостаточно высокая скорость компиляции программного кода и при реализации конечного продукта (ПО), используя этот продукт необходимо большее дисковое пространство, чем при создании аналогичного ПО другими средствами разработки. Borland С++ Biulder по своим недостаткам аналогичен Visual C++, но обладает еще одним - разработка баз данных на базе языка SQL и их поддержка ограничена. Система разработки Visual FoxPro предъявляет наименьшие требования к системным ресурсам, но ее применение ограничено неудобством в визуальном создании интерфейса разрабатываемого приложения. Недостатком Delphi состоит в том, что при его использовании нет достаточного доступа к функциям ОС, но данный недостаток несущественен, поскольку разрабатываемое приложение ориентировано на поддержку БД, а не на работу с ОС. Немалое значение при выборе Delphi в качестве средства для разработки АСИС играет возможность использования большого количества встроенных визуальных компонентов, как для разработки интерфейса, так и для создания СУБД.

При создании программного продукта АСИС “Супермаркет” главным критерием выбора программных средств разработки являлись:

Ё скорость разработки приложений;

Ё возможность быстрого внесения изменений в программу;

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

Как дополнение к перечисленному, можно указать, что время разработки зависит от: поддержки выбранным инструментарием ОС, аппаратной поддержки, необходимой для их оптимального функционирования; наличия предварительного опыта у разработчиков в использования соответствующих программных средств. Обеспечить минимальное время разработки можно только при выполнении этих условий.

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

Ё Наличие опыта разработки с использованием данного программного продукта;

Ё Требования по ресурсам;

Ё Поддержка операционной системы;

Ё Наглядность разработки интерфейса;

Ё Предоставляемые возможности работы с базами данных;

Ё Доступность;

Ё Скорость работы разработанного программного обеспечения;

Ё Обработка исключительных ситуаций;

Ё Время создания разработанного программного обеспечения;

Ё Удобство эксплуатации;

Для вышеперечисленных средств для разработки АСИС воспользуемся методом вариантных обоснований. Этот метод предназначен для выбора наилучшего варианта из нескольких предложенных и состоит из следующих этапов:

Ё Определение критериев, по которым будет произведено сравнение и степени их важности.

Ё Каждый вариант оценивается по полученному перечню критериев. Получается численное значение - оценка.

Ё Нахождение общего количества баллов для каждого из вариантов ( можно учитывать важность критериев ).

Ё Лучшим считается вариант, который набрал максимальное количество баллов.

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

Результаты приведены в таблице 4.1

Таблица 4.1

Средство разработки Характеристика средств разработки	Delpi	Visual C++	Borland C++ Buielder	Visual FoxPro
Наличие опыта разработки с использованием данного программного продукта;	8	6	4	4
Требования по ресурсам;	7	6	6	5
Поддержка операционной системы;	8	8	8	7
Наглядность разработки интерфейса;	9	7	8	5
Предоставляемые возможности работы с базами данных;	8	6	4	7
Скорость работы разработанного программного обеспечения;	6	7	8	7
Обработка исключительных ситуаций;	8	8	8	6
Время создания разработанного программного обеспечения;	9	6	5	7
Удобство эксплуатации;	7	8	8	7
Всего:	70	62	60	56

Вывод: В результате выполненного анализа инструментальных средств выявили, что в качестве средства разработки АСИС будет использован Delphi, как наиболее оптимальное средство разработки с точки зрения разработчика.

Используя Delphi можно создавать приложения для MS Windows 95/98/NT/XP/7/8 с минимальными затратами времени т.к. в её основе лежит концепция быстрого создания приложений (RAD).

Основные сведения о Delphi:

Базируется на расширении языка Pascal - Object Pascal.

Интегрированная среда разработки приложений - позволяет создавать, компилировать, тестировать и редактировать проект или группу проектов в единой среде программирования;

Визуальная технология разработки программ - позволяет быстро создавать приложения путём размещения в форме стандартных компонентов. При этом соответствующий код программы автоматически генерируется Delphi. Такая технология освобождает разработчика от рутинной работы по созданию пользовательского интерфейса и позволяет уделить больше внимания внутренней организации данных и обработке данных.

Технология Two Ways Tools делает более эффективной работу с компонентами. При изменении программного кода в окне редактора Delphi соответствующим образом изменяет и сами компоненты. С другой стороны, при изменении свойств компонентов в инспекторе редактора объектов (Object Inspector) они немедленно отражаются в окне редактора кода.

Библиотека компонентов содержит множество стандартных компонентов, которые можно использовать при создании приложений. Сюда относятся элементы управления в стиле Windows 95 и IE 4.0, а также шаблоны для форм и экспертов.

Поддержка баз данных в среде Delphi осуществляется двояко. С одной стороны в ней широко используются компоненты, предназначенные для работы с базами данных. С их помощью можно создавать простые приложения, предназначенные для обработки данных, и приложения типа клиент/сервер. Особенностью этих компонентов является то, что во время создания приложения Delphi отображает результаты обработки данных, и позволяет проанализировать различные ситуации, которые могут сложиться в процессе работы программы. С другой стороны поддержка баз данных в Delphi осуществляется с помощью набора драйверов соединений с SQL-северами Borland SQL Links for Windows, которые позволяют интегрированному в Delphi ядру процессора баз данных Borland, (BDE) Borland Database Engine, получать доступ к локальным базам данных Paradox, dBASE, Access, FoxPro, а также SQL-северам InterBase, Informix, Oracle, Sybase, DB2, Microsoft SQL.

Компилятор Delphi генерирует исполняемые EXE-файлы. При этом существует возможность генерировать либо простые EXE-файлы, либо сложные приложения, требующие подключения DLL-библиотек.

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

Непосредственный доступ к интерфейсу приложений API;

Встроенный Ассемблер; обработка строк, написанных на Ассемблере вставленных в текст программ Delphi;

Возможность создания пользовательских объектов VCL и OCX;

Возможность создания DLL-библиотек и других "вторичных" объектов среды Windows;

Объектная ориентация - возможность создавать новые классы, наследующие свойства существующих классов, либо, начав с нуля, строить свои собственные.

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

- Поддержка как локальных таблиц, так и находящихся на удаленных серверах баз данных;

- Поддержка сложных запросов и доступ из одного приложения ко многим Системам Управления Базами Данных (СУБД), построенным на различных платформах;

- Свободное перемещение приложения из одной СУБД в другую, осуществляемое посредством ядра Borland Database Engine, которое организует доступ к базам данных, невзирая на различия в платформах;

- Наличие собственных быстрых драйверов для основных платформ типа клиент/сервер;

- Полная поддержка ODBC.

Delphi, как СУБД, полностью ориентирован на реляционную модель данных и имеет встроенный язык запросов к базам данных SQL (Structured Query Language).

4.2 Использование АСИС “Супермаркет”

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- Заявка;

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

- Все заявки.

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

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

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

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

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

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

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

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

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

- Заказ;

- Все заказы.

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

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

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

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

Печать.

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

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

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

Ё Тестирование (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.

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

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

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

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

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

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

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

Ё ревизии.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ё Третий шаг: нарисовать функциональную диаграмму. Ситуации изображаются в виде вершин на левом краю листа бумаги, а эффекты - на правом.

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

Тестирование модуля

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

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

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

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

Ё Был проверен текст программы на её чувствительность к отдельным особым значениям входных данных и были добавлены соответствующие тесты.

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

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

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

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

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

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

Комплексное тестирование

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

Ё Тестирование стрессов. Распространенный недостаток больших систем в том, что они функционируют как будто бы нормально при слабой или умеренной нагрузке, но выходят из строя при большой нагрузке и в стрессовых ситуациях реальной среды. Тестирование стрессов представляет попытки подвергнуть систему крайнему “давлению”.

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

Ё Тестирование объёма. В то время как при тестировании стрессов делается попытка подвергнуть систему серьёзным нагрузкам в короткий интервал времени, тестирование объема представляет собой попытку предъявить системе большие объёмы данных (максимальный объем базы данных, 2 Мб) в течение более длительного времени.

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

Ё Тестирование конфигурации. Многие системы обеспечивают работу различных конфигураций аппаратуры и ПО. Число таких конфигураций часто слишком велико, но необходимо проверить хотя бы максимальную и минимальную конфигурации. Система была проверена со всеми аппаратными устройствами, с которыми она может осуществлять работу (гибкие накопители данных, принтеры).

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

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

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

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

Выводы по тестированию ПО

На основание проведения вышеперечисленных тестов можно заключить, что:

Ё Созданная система выполняет все функции, указанные в ТЗ.

Ё При аварийном отключении сохраняет максимально возможное количество данных.

Ё Система способна работать на ПК различной конфигурации, в том числе и минимальной.

Ё Система отвечает поставленным требованиям по защите от несанкционированного доступа.

Ё Система корректно осуществляет свою работу при работе с большими объемами данных (при максимальном объеме БД - 2 Мб) и при большом количестве запросов(20 запросов).

6. Безопасность жизнедеятельности

6.1 Выявление вредных и опасных факторов

Работа ПЭВМ связана с присутствием на рабочем месте человека - оператора, поэтому вопросы охраны труда будут рассматриваться с точки зрения обеспечения безопасных условий труда и условий труда сохраняющих здоровье оператора, пользователя.

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

Ё Метеорологические условия среды (микроклимат лаборатории);

Ё Аномальное освещение;

Ё Высокий уровень шума;

Ё Повышенный уровень ионизирующего излучения;

Ё Опасность поражения электрическим током;

Ё Повышенные психофизиологические нагрузки;

Ё Пожароопасность.

Требования по влажности, предъявляемые к радиоэлектронной технике и нормы микроклимата, необходимые для нормальной жизнедеятельности человека различны. Это объясняется тем, что при эксплуатации ПЭВМ влажность воздуха в помещении согласно ГОСТам 12.1.005-86 должна быть одной (не более 40-60%), а влажность для оператора другой (не менее 70%). Поэтому, оптимальная влажность в лаборатории для оператора и ПЭВМ принята 50%. Пониженная влажность вызывает у человека ощущение сухости слизистых оболочек верхних дыхательных путей, ухудшает самочувствие и снижает работоспособность.

Высокая температура способствует быстрому утомлению оператора, может привести к перегреву организму, что вызывает тепловой удар. Низкая температура может вызвать местное или общее охлаждение организма, стать причиной простудного заболевания. Поэтому в качестве оптимального микроклимата для персонала, с учетом требований предъявляемых к оборудованию лаборатории, согласно ГОСТ 12.1.005-88 установлен микроклимат, отвечающий характеристикам: температура - 22-240 С, относительная влажность - 40-60%, подвижность воздуха не более 0.1 м/с. Освещенность измеряется в люминах лк., и для искусственного освещения приняты норма освещенности на рабочей поверхности составляет 250-350 лк.

Работы производимые в помещении лаборатории соответствуют категории работ I (легкий физический труд); разряд зрительных работ - III.

Шум [8], создаваемый одной ПЭВМ невелик, он находится в диапазоне 30-68 дб. Согласно ГОСТу 12.1.003-83 он должен не превышать уровня 40 дб. Но поскольку в лаборатории находится не одна ЭВМ, то шум производимый ими является достаточно высоким. Кроме того данный тип шума оказывает отрицательное воздействие на человека еще и тем, что он является монотонным. Также необходимо отметить, что в помещении лаборатории используются принтеры, как правило, матричного типа, что также увеличивает уровень шума. Шум нарушает нервную систему; шумовые явления обладают свойством куммуляции: накапливаясь в организме, он все больше и больше угнетает нервную систему. Шум - причина преждевременного утомления, ослабления внимания, памяти.

Ионизирующими называются излучения, взаимодействие которых со средой приводит к образованию электрических зарядов разных знаков. К ионизирующим излучениям относятся: гамма-излучение, рентгеновское, корпускулярное, инфракрасное, микроволновое и другие виды излучений. Рентгеновское излучение на расстоянии 10 см. от монитора составляет не более 100 мкР/ч, а уровень ионизации обоих зарядов в диапазоне 1500-5000 на 1 см3 воздуха. Источником излучения в лаборатории по производству ПО являются мониторы. При повышенном электромагнитном излучении у человека появляется головная боль, повышенная утомляемость, что снижает сосредоточенность работающего к работе, его внимание.

Излучение и поля радиочастотного диапазона регламентируются ГОСТ 12.1.006 - 84 (“Электромагнитные поля радиочастот. Допустимые уровни на рабочих местах и требования к проведению контроля”).

Электрооборудование в лаборатории является одним из первых источников опасных факторов, поскольку основная масса оборудования в ней электрическое. Оборудование, находящееся в лаборатории ПО запитывается от сети переменного тока напряжением 220 В и частотой 50 Гц. Поэтому персонал лаборатории подвержен повышенному риску поражения электрическим током. Поражение током может произойти от неизолированной электропроводки, от корпуса системного блока, если на него произошел пробой электричества, при неосторожным обращении с оборудованием, его разборкой и т.п. Действие электрического тока на живую ткань носит своеобразный характер. Проходя через организм человека ток производит термическое (ожоги отдельных участков тела, нагрев внутренних органов до высокой температуры), электрическое (разложение органической жидкости, в том числе и крови), механическое (расслоение и другие подобные повреждения различных тканей организма) и биологическое (нарушение внутренних биоэлектрических процессов, протекающих в нормально действующем организме) действия.

Психофизиологические опасные и вредные факторы по характеру действия подразделяются на: физические (статические и динамические) и нервно-психические (умственное перенапряжение, перенапряжение анализаторов, монотонность труда и эмоциональные перегрузки). Персонал лаборатории наиболее подвержен воздействию статических вредных факторов (неизменное положение тела), перенапряжению анализаторов (долгое времяпровождение перед экраном). Чтобы не перенапрягать зрительные анализаторы оператор должен проводить у монитора не более 4 ч. в сутки, производить набор не более 30.000 символов.

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

Лаборатория по разработке ПО на предприятии по своей конструкции представляет собой невзрывоопасное помещение и по пожарной опасности относится к категории В, согласно ОНТП-24-86. Степень огнестойкости здания - II согласно СНиП 2.01.02-35.Класс помещения по пожарной опасности П-IIа, согласно ПУЭ-87.

6.2 Мероприятия по защите от вредных и опасных факторов

1) Для нормализации воздуха в лаборатории следует использовать вентиляцию, как естественную так и искусственную. К видам естественной вентиляции используемой в лаборатории по производству ПО можно отнести неорганизованную естественную вентиляцию. Но использование такого вида вентиляции имеет ряд недостатков: воздух, поступающий в помещение не подогревается и не увлажняется, поэтому в лаборатории целесообразно применять механическую общую приточную вентиляцию, которая устраняет недостатки естественной. Для обеспечения соответствующей температуры в лаборатории по разработке ПО в зимнее время следует использовать централизованное отопление, а в летнее - различные виды вентиляции.

2) Нормальное освещение обеспечивается путем рационального комбинирования и применения естественного и искусственного освещения. Правильного размещения монитора на рабочем месте относительно оконных проемов.

3) Для защиты от шума, создаваемого в лаборатории оборудованием, целесообразно использовать следующие методы:

Ё Снижение шума в источнике его возникновения;

Ё Снижение шума на пути его распространения.

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