Внедрение информационной подсистемы "Заказ обедов"

Размещено на http://www.allbest.ru/

СОДЕРЖАНИЕ

ВВЕДЕНИЕ

1. АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ

1.1 Структура фирмы по доставке готовых обедов

1.2 Анализ внешнего и внутреннего документооборота

1.3 Анализ бизнес процессов

3. ПРОЕКТНАЯ ЧАСТЬ

3.1 Цели создания автоматизированной подсистемы

3.2 Характеристика функциональных подсистем

3.3 Характеристика обеспечивающих подсистем проектируемой автоматизируемой системы

3.4 Проектирование базы данных

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

4. ПРОЕКТИРОВАНИЕ ВЫЧИСЛИТЕЛЬНОЙ СЕТИ

5. НАДЕЖНОСТЬ АВТОМАТИЗИРОВАННОЙ СИСТЕМЫ

5.1 Обзор модели надежности

5.2 Основание выбора модели надежности

5.3 Методика расчета надежности по выбранной модели

5.4 Расчет надежности автоматизированной системы

6. ЭКОНОМИЧЕСКАЯ ЦЕЛЕСООБРАЗНОСТЬ ПРОЕКТА

6.1 Понятие экономической эффективности

6.2 Определение затрат на разработку и внедрение программного продукта

6.3 Расчет показателей экономической эффективности

ЗАКЛЮЧЕНИЕ

БИБЛИОГРАФИЧЕСКИЙ СПИСОК

ОПРЕДЕЛЕНИЯ, ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ

ПРИЛОЖЕНИЕ



ВВЕДЕНИЕ

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

Основные задачи, которые должна решать информационная система управления фирмой:

1. Поддержание достаточной полноты и стабильности ассортимента;

2. Повышение скорости обслуживания;

3. Автоматизация управления и контроля деятельности предприятия, в частности, автоматизация процесса заказа:

4. Повышение оборачиваемости финансов;

5. Защита от злоупотреблений и воровства персонала;

В данной работе представлена информационная подсистема «Заказ обедов». Внедрение информационной подсистемы «Заказ обедов» позволит повысить эффективность работы фирмы, за счет повышения качества информации, циркулирующей в фирме, снижения трудовых и временных затрат на заказ и доставку обедов. В результате разработки информационной подсистемы «систему «Учет товарооборота» будут автоматизированы следующие виды деятельности:

1. Заполнение бланка заказа;

2. Загрузку и распределение поваров;

3. Формирование партии обедов для предприятия;

4. Расчет с клиентами;

5. Определение потребностей в продуктах;

6. Закуп продуктов.

Основные документы, которые будут формироваться при автоматизации магазина: «Бланк заказов», «Общий заказ», «Закуп продуктов» и др.

1. АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ

1.1 Структура фирмы по доставке готовых обедов

Наименование организации: фирма по доставке обедов.

Сфера деятельности организации: общественное питание.

Общая численность персонала - 9 человек.

Организационная структура предприятия представлена на рисунке А.1 (Приложение А).

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

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

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

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

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

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

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

2.Учет источников формирования имущества организации (обязательств организации);

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

4.Учет количества и качества затраченного в торговой и управленческой деятельности труда. Количество труда измеряется в часах, днях, месяцах. Качество труда оценивается в денежном выражении;

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

1.2 Анализ внешнего и внутреннего документооборота

Для анализа документооборота предприятия используется методология DFD case-системы BPWin [2]. Схема внешнего документооборота представлена на рисунке Б.1 (Приложение Б).

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

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

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

В Фонд социального страхования руководитель предоставляет отчеты и сведения о сотрудниках.

Внутренний документооборот предприятия строится в соответствии с бизнес процессами [6], которые имеются на предприятии. Известно, что успех деятельности организации в значительной степени зависит от того, насколько быстро и качественно происходит обработка всей необходимой документации. Перемещение документов осуществляется по определенным маршрутам от места составления или поступления до отправки заинтересованным лицам. Внутренний документооборот фирмы по доставке готовых обедов представлен в Приложении Б на рисунке Б.2.

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

Обеды в производственном цеху после приготовления упаковываются в одноразовую посуду в производственном цеху и передаются в отдел доставки. Подготавливаются документы для транспортировки и упакованные обеды развозятся предприятиям-клиентам. Клиенты расплачиваются при получении обеда с водителем. Деньги передаются в бухгалтерию. Бухгалтер проверяет полученную сумму и выполненный заказ.

Приемщик и шеф-повар после обеда анализируют остатки продуктов и меню на следующий день и составляют список продуктов, которые необходимо приобрести. Шеф-повар и водитель выполняют закуп продуктов.

1.3 Анализ бизнес процессов

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

Взаимодействие структурных подразделений фирмы по приготовлению обедов представлено на диаграммах в приложении Б. Диаграммы построены с использованием объектно-ориентированного языка моделирования UML.



3. ПРОЕКТНАЯ ЧАСТЬ

3.1 Цели создания автоматизированной подсистемы

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

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

Вид автоматизированной деятельности: 0аказ и доставка обедов. Создаваемая автоматизированная подсистема необходима для работы фирмы по доставке готовых обедов.

Целями разработки информационной системы являются:

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

– сокращение трудоемкости работы и более эффективное выполнение основных операций сотрудниками;

– более надежное и эффективное хранение данных и защита от несанкционированного доступа.

3.2 Характеристика функциональных подсистем

В работе представлена информационная подсистема «Заказ и доставка обедов». Контекстная диаграмма ее функционирования представлена на рисунке Г.1, а на рисунке Г.2 отображены входящие в состав ИС подсистемы.

Подсистему «Работа с БД» необходима для ввода данных о заказах от сотрудников предприятий-клиентов, информация о закупленных продуктах. Данная подсистема выделена как отдельная подсистема, но при реализации информационной системы для каждой, описанной далее подсистемы разрабатывается свой модуль ввода и редактирования данных.

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

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

Подсистема «Платеж» обеспечивает выполнение электронных платежей пользователей интернет магазина.

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

Подсистема формирования отчетов - выполняет формирование и вывод регламентных отчетов о работе фирмы и отчетов по реализации.

Подсистема обработки запросов - выполняет формирование и вывод отчетов по запросам.

Подсистема администрирования должна выполнять функции:

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

– архивирование, резервное копирование базы данных, настройка автоматического резервирования;

– восстановление базы данных.



3.3 Характеристика обеспечивающих подсистем проектируемой автоматизируемой системы

Подсистема организационного обеспечения

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

Рассмотрим обеспечивающие подсистемы проектируемой информационной подсистемы.

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

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

- средство разработки структуры базы данных ERWin;

- СУБД MySQL;

-- серверное программное обеспечение Apache HTTP Server 2.2;

- построение модели информационных потоков предприятия и его отделов производим в пакете BPWin.

б) техническая документация, получаемая в процессе обследования, проектирования и внедрения системы: экономическая целесообразность разработки, техническое задание на разработку системы и первичные формы входных документов;

в) «Персонал», где представлена организационно-штатная структура проекта. Все пользователи, которые будут иметь доступ к базе данных, будут разделяться на две категории:

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

В задачи администратора также входит:

1) создание учетных записей пользователей и управление ими;

2) защита данных;

3) обучение и поддержка пользователей;

4) модернизация существующего ПО и установка нового;

5) архивирование и резервное копирование данных;

6) предупреждение потери данных;

7) диагностика и контроль над свободным пространством для хранения данных на сервере;

8) настройка сети под максимальную производительность;

9) защита сети от вирусов.

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

Подсистема правового обеспечения

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

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

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

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

3.4 Проектирование базы данных

Инфологическое проектирование

Назначение сущностям описательных атрибутов

На основании проведенного исследования предметной области и целей создания информационной системы были выделены следующие сущности:

- «Товар»;

- «Поступление»;

- «Продажа»;

- «Поставщик»;

- «Покупатель»;

- «Заказ».

Выбор именно этих сущностей обусловлен спецификой работы проектируемой автоматизированной системы.

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

Сущность «Поступление» содержит данные обо всех документах, которые фиксируют поступление товара в интернет магазин (счет-фактура, ТТН, накладные, железнодорожные и авиа накладные)

Сущность «Продажа» содержит данные обо всех документах, которые фиксируют продажу товара в интернет магазине (накладные).

Сущность «Поставщик» содержит данные обо всех поставщиках товаров.

Сущность «Покупатель» содержит данные обо всех покупателях интернет магазина.

Сущность «Заказ» содержит данные о заказах, находящихся в производстве.

Таблица 2 - Спецификация атрибутов сущности «Товар»

Название атрибута	Описание атрибута	Диапазон значений	Единицы измерения	Пример атрибута
Код товара	Число, однозначно определяющее каждый товар	> 0	-	64
Наименование	Наименование товара	Текст	-	ноутбук
Характеристика	Характеристика товара	Текст	-	Sony VAIO SVE1512L1R

Таблица 3 - Спецификация атрибутов сущности «Поступление»

Название атрибута	Описание атрибута	Диапазон значений	Единицы измерения	Пример атрибута
Код поступления	Число, однозначно определяющее каждое поступление товара	> 0	-	47
Дата поступления	Число, месяц и год поступления товара	<= текущая дата	дд.мм.гггг	16.01.2013
Количество	Число определяющее количество поступившего товара	>0	-	450
Единицы измерения	Единицы измерения для товара	Текст	-	кг
Цена	Цена единицы поступившего товара	>0	Руб.	120.0

Таблица 4 - Спецификация атрибутов сущности «Продажа»

Название атрибута	Описание атрибута	Диапазон значений	Единицы измерения	Пример атрибута
Код продажи	Число, однозначно определяющее каждую продажу товара	> 0	-	47
Дата продажи	Число, месяц и год поступления товара	<= текущая дата	дд.мм.гггг	16.01.2013
Количество	Число, определяющее количество проданного товара	>0	-	450
Единицы измерения	Единицы измерения для товара	Текст	-	кг
Цена	Цена единицы проданного товара	>0	Руб.	150.0

Таблица 5 - Спецификация атрибутов сущности «Поставщик»

Название атрибута	Описание атрибута	Диапазон значений	Единицы измерения	Пример атрибута
Код поставщика	Число, однозначно определяющее каждого льготника	> 0	-	17
Наименование	Наименование поставщика	Текст	-	ООО «Формоза»
Страна	Страна поставщика	Текст	-	Россия
Населенный пункт	Населенный пункт нахождения поставщика	Текст	-	Новосибирск
Улица	Название улицы нахождения поставщика	Текст	-	Ленина
Дом	Номер дома нахождения поставщика	>0	-	49
Обращатьсяк	Имя, с кем проводить переговоры	Текст	-	Ольга
Телефон	Телефон поставщика для связи	Текст	-	84568339127
Факс	Факс поставщика для связи	Текст	-	84568339127
Электронный адрес	Электронный адрес поставщика для связи	Текст	-	Formosa@mail.ru
ИНН	ИНН поставщика	>0	-	7729589570
КПП	КПП поставщика	>0	-	774301001
ОГРН	ОГРН поставщика	>0	-	1077763377834
Банк	Банк для расчетов с поставщиком	Текст	-	ОАО "Альфа-Банк" г. Москва
Расчетный счет	Расчетный счет для осуществления расчетов с поставщиком	Текст	-	40702810002750000191
БИК	БИК для осуществления расчетов с поставщиком	Текст	-	044525593
К/счет	К/счет для осуществления расчетов с поставщиком	Текст	-	30101810200000000593

Таблица 6 - Спецификация атрибутов сущности «Покупатель»

Название атрибута	Описание атрибута	Диапазон значений	Единицы измерения	Пример атрибута
Код покупателя	Число, однозначно определяющее каждого покупателя	> 0	-	164
Фамилия	Фамилия покупателя	Текст	-	Авдеев
Имя	Имя покупателя	Текст	-	Алексей
Страна	Страна проживания	Текст	-	Сергеевич
Индекс	Индекс населенного пункта	>0	цццццц	657000
Населенный пункт	Населенный пункт льготника	Текст	-	Серышево-1
Улица	Название улицы, на которой проживает льготник	Текст	-	Централь ная
Дом	Номер дома льготника	>0	-	1
Квартира	Номер квартиры льготника	>0	-	16
Телефон	Телефон для связи с покупателем	Текст	-	84161338128
Электронный адрес	Электронный адрес для связи с покупателем	Текст	-	adres@mail.ru
Скидка	Торговая скидка на товар	>=0	%	5

Таблица 7 - Спецификация атрибутов сущности «Заказ»

Название атрибута	Описание атрибута	Диапазон значений	Единицы измерения	Пример атрибута
Код заказа	Число, однозначно определяющее каждый заказ товара	> 0	-	47
Дата заказа	Число, месяц и год заказа	<= текущая дата	дд.мм.гггг	16.01.2013
Количество	Число, определяющее количество заказанного товара	>0	-	450
Единицы измерения	Единицы измерения для товара	Текст	-	кг
Цена	Цена единицы заказанного товара	>0	Руб.	150.0
Статус	Состояние заказа в текущий момент времени	Текст	-	Выполнен

Таблица 8 - Спецификация атрибутов сущности «Документ»

Название атрибута	Описание атрибута	Диапазон значений	Единицы измерения	Пример атрибута
Номер документа	Число, однозначно определяющее номер расходного или приходного документа	> 0	-	4758700
Наименование	Наименование документа	Текст	-	накладная
Дата документа	Число, месяц и год создания документа	<= текущая дата	дд.мм.гггг	16.01.2013

Таблица 9 - Спецификация атрибутов сущности «Оплата»

Название атрибута	Описание атрибута	Диапазон значений	Единицы измерения	Пример атрибута
Код оплаты	Число, однозначно определяющее каждую оплату товара покупателем	> 0	-	47
Дата	Число, месяц и год оплаты товара	<= текущая дата	дд.мм.гггг	16.01.2013
Сумма	Число, определяющее сумму произведенной оплаты	>0	Руб.	450.70
Способ	Способ оплаты товара	Текст	-	Карта Visa

Определение связей между сущностями

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

Модель «сущность-связь» предполагает несколько типов связи: «один-к-одному», «один-ко-многим», «многие-ко-многим». Связь «один-к-одному» означает, что в каждый момент времени каждому экземпляру сущности А соответствует 1 и только 1 экземпляр сущности В и наоборот. Связь «один-ко-многим» обозначает, что одному представителю сущности А соответствуют 0, 1 или несколько представителей сущности В, но каждому экземпляру сущности В соответствует только 1 экземпляр сущности А. Связь «многие-ко-многим» показывает, что одному представителю сущности А соответствуют 0, 1 или несколько представителей сущности В и наоборот.

Исходя из этого, обозначим связи между сущностями.

1) Связь «Товар - Поступление» показана на рисунке 1.

Рисунок 1 -Товар - Поступление

В этом случае имеется связь один-ко-многим. Одному товару может соответствовать несколько поступлений. В тоже время одному поступлению соответствует только один товар.

2) Связь «Товар - Продажа» представлена на рисунке 2.

Рисунок 2 -Товар - Продажа

Для сущностей «Товар» и «Продажа» также установлена связь один-ко-многим. Одному товару может соответствовать несколько продаж. Одной продаже соответствует один товар.

3) На рисунке 3 показана связь «Поступление - Поставщик». Для сущностей «Поступление» и «Поставщик» установлена связь один-ко-многим. Одному поступлению соответствует один поставщик, при этом одному поставщику может соответствовать много поступлений.

Рисунок 3 -Поставщик - Поступление

4) Связь Покупатель - Продажа представлена на рисунке 4

Рисунок 4 -Покупатель - Продажа

Между сущностями установлена связь один-ко-многим, так как одному покупателю соответствует много продаж, а одной продаже соответствует один покупатель.

5) Рисунок 5 отображает связь Продажа - Документ. В этом случае имеет место связь один-ко-многим. Одной продаже соответствует один документ (накладная), но одному расходному документу может соответствовать несколько продаж. Действительно в интернет магазине может быть в одной накладной представлено несколько продаж, все товары будут доставлены одному покупателю.

Рисунок 5 -Документ - Продажа

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

Рисунок 6 -Документ - Поступление

7) Рисунок 7 отображает связь Товар - Заказ. Для сущностей «Товар» и «Заказ» организована связь один-ко-многим. Одному заказу соответствует один товар, но одному товару может соответствовать несколько заказов.

Рисунок 7 -Товар - Заказ

8) На рисунке 8 представлена связь Покупатель - Оплата. В этом случае имеет место связь один-ко-многим. Одному покупателю соответствует много оплат, но одной оплате может соответствовать один покупатель.

Рисунок 8 -Покупатель - Оплата

Логическое проектирование

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

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

- Анализ полученных отношений на соответствие трем нормальным формам.

При проведении первого этапа логического проектирования рассматривается каждая связь между сущностями. В тех случаях, когда сущности имеют связь «один-ко-многим», сущности, от которых исходит простая связь, являются исходными, а другие сущности соответственно являются порожденными, а в тех случаях, когда сущности имеют связь «один-к-одному», выбор исходной сущности производится произвольным образом. При построении отношений, ключи порожденной сущности необходимо добавить в атрибуты исходной сущности. Связь «многие ко многим» рекомендуется разрешать с помощью создания промежуточного отношения, который будет содержать все ключевые атрибуты обеих сущностей [10, с. 549].

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

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

Рассмотрим связь «Товар - Поступление», показанную на рисунке 9.

Рисунок 9- Связь «Товар - Поступление»

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

Рисунок 10 - Результат анализа связи «Товар - Поступление»

Аналогичным способом выполним анализ всех остальных связей.

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

Физическое проектирование

Целью физического проектирования является представление логического проектирования в форме, пригодной для реализации в конкретной СУБД. При физическом проектировании происходит трансформация сущностей в таблицы, а атрибутов в поля [3, с. 5].

Все поля физических таблиц БД, описаны в таблицах 10 - 15.

Таблица 10 - Физическое представление отношения «Товар»

Название поля	Тип данных	Условия	Индексация
Код товара	Числовой	> 0	Да
Наименование	Текстовый	-	Да
Характеристика	Текстовый	-	Нет

Таблица 11 - Физическое представление отношения «Поступление/продажа»

Название поля	Тип данных	Условия	Индексация
Код поступления	Числовой	> 0	Да
Дата поступления	Дата/время	? Date()	Да
Количество	числовой	>0	Да
Единицы измерения	Текстовый	-	Нет
Цена	Числовой	>0	Да
Код товара	Числовой	>0	Да
Код поставщика	Числовой	>0	Да
Код покупателя	Числовой	>0	Да
Номер документа	Числовой	>0	Да
Тип операции	Текстовый	-	Да

Таблица 11 - Физическое представление отношения «Поставщик»

Название поля	Тип данных	Условия	Индексация
Код поставщика	Числовой	> 0	Да
Наименование	Текстовый	-	Да
Страна	Текстовый	-	Нет
Населенный пункт	Текстовый	-	Нет
Улица	Текстовый	-	Нет
Дом	Числовой	>0	Нет
Обращатьсяк	Текстовый	-	Да
Телефон	Числовой	>0	Да
Факс	Числовой	>0	Да
Электронный адрес	Текстовый	-	Да
ИНН	Числовой	>0	Нет
КПП	Числовой	>0	Нет
ОГРН	Числовой	>0	Нет
Банк	Текстовый	-	Да
Расчетный счет	Числовой	>0	Да
БИК	Числовой	>0	Да
К/счет	Числовой	>0	Да

Таблица 12 - Физическое представление отношения «Покупатель»

Название поля	Тип данных	Условия	Индексация
Код покупателя	Числовой	> 0	Да
Фамилия	Текстовый	-	Да
Имя	Текстовый	-	Нет
Страна	Текстовый	-	Нет
Индекс	Числовой	>0	Нет
Населенный пункт	Текстовый	-	Нет
Улица	Текстовый	-	Да
Дом	Числовой	>0	Да
Квартира	Числовой	>0	Да
Телефон	Числовой	-	Да
Электронный адрес	Текстовый	-	Нет
Скидка	Числовой	>0	Нет
Код оплаты	Числовой	>0	Нет

Таблица 13- Физическое представление отношения «Документ»

Название поля	Тип данных	Условия	Индексация
Номер документа	Числовой	> 0	Да
Наименование	Текстовый	-	Да
Дата документа	Дата/время	? Date()	Нет



Таблица 14 - Физическое представление отношения «Заказ»

Название поля	Тип данных	Условия	Индексация
Код заказа	Числовой	> 0	Да
Дата заказа	Дата/время	? Date()	Да
Количество	Числовой	>0	Нет
Единицы измерения	Текстовый	-	Нет
Цена	Числовой	>0	Нет
Статус	Текстовый	-	Нет
Код товара	Числовой	>0	Да

Таблица 15 - Физическое представление отношения «Оплата»

Название поля	Тип данных	Условия	Индексация
Код оплаты	Числовой	> 0	Да
Дата	Дата/время	? Date()	Да
Сумма	числовой	>0	Да
Способ	Текстовый	-	Нет

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

Для реализации функций АИС разработан программный продукт на языке PHP. Работа начинается с открытия главной страницы интернет магазина, на этой странице имеются гиперссылки на каталог товаров, включающий стоимость товара, на страницу, предназначенную для оформления покупки и доставки товара, на информационные разделы сайта, содержащие информацию о новинках, местоположении бэк-офиса и другой контактной информации, разработчике интернет магазина, карту сайта (рисунок Е.1).

Кроме этого сайт имеет раздел необходимый для работы сотрудников отдела продаж, доставки, финансового отдела, Каждому сотруднику для входа в административный раздел назначен логин и пароль. Экранная форма входа в административный раздел представлена на рисунке Е.2. При правильном вводе логина и пароля сотрудник имеет доступ к странице, вид которой отображен на рисунке E.3. На этой странице имеются вкладки «Товары, учет товарооборота, заказы, покупатели и др.».

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

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

При активизации гиперссылки «Учет товарооборота» сотрудники финансового отдела имеют возможность получить регламентные отчеты и отчеты по запросам: «Журнал поступления», «Книга продаж», «Товарный отчет», «Учетная карточка товара», документация по проведению инвентаризации, отчеты по заказам и др. Вид страниц и форма отчетов представлена на рисунке Е.6, Е.7.



4. ПРОЕКТИРОВАНИЕ ВЫЧИСЛИТЕЛЬНОЙ СЕТИ

Для размещения интернет магазина есть несколько способов:

– виртуальный хостинг;

– виртуальный сервер;

– физический сервер.

Виртуальный хостинг

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

Достоинства виртуального хостинга:

– низкая стоимость;

– прост в управление. Все операции с виртуальным хостингом выполняются через web-интерфейс специальной панели провайдера;

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

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

Недостатки виртуального хостинга

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

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

– Несогласованное обновление программного обеспечения на хостинге. Естественно, из лучших побуждений хостинг компания периодически может менять программное обеспечения хостинг сервера, а приводит к тому, что интернет-магазину приходиться также вносить изменение в ПО своего сайта. Это приходиться делать обязательно и своевременно, так как без соответствующих обновлений сайт интернет магазина просто перестанет работать.

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

Бэк-офис интернет магазина представляет собой небольшой офис, в котором работает не менее 8 сотрудников - руководитель, менеджеры по продажам и доставке, складской работник, бухгалтер, системный администратор, программист, маркетолог. На каждом рабочем месте установлен компьютер, также в офисе есть один выделенный канал в интернет с постоянным реальным ip адресом и доменным именем.

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

– объединить все компьютеры в локальную сеть (LAN);

– организовать печать со всех рабочих мест на сетевой принтер;

– подключить и настроить Интернет - канал;

– организовать доступ в Интернет со всех компьютеров локальной сети.;

– защитить локальную сеть от внешних вторжений;

– установить и настроить сетевые сервисы: WEB-сервер, почтовый сервер, файловый, FTP, прокси и т.д..

Схема вычислительной сети представлена на рисунке Ж.1 приложения Ж.

Поставленную задачу построения простой локальной сети мы будем решать на базе стека (набора) протоколов TCP/IP. Выбор оборудования для сети представлено в таблице 16, программного обеспечения - в таблице 17.

Таблица 16 - Технические средства вычислительной сети

Наименование ТС	к-во
Сервер Hewlett Packard NetServer E800 PIII-800/HDD 9,1Gb SCSI/128Mb ECC SDRAM/32x CD-ROM/Fast Ethernet NIC	3шт
HP QK703A QK703A, для сервера, 3.5", SAS, 3000 Гб,	2шт
Сетевой адаптер 3COM 3C905C PCI 10/100	8шт
3Com 3C16470B-ME Baseline 10/100 Switch 16 Port	2шт
Кабель оптоволокно 9A/125/900	100м
APC Smart-UPS, 390 Watts / 620 VA,Входной 230V / Выход 230V, Interface Port DB-9 RS-232	2шт.
Сетевой принтер HP LaserJet 2100TN (C4172A) 10 стр/ мин сетев.10BaseT 8Mb	1 шт.
Рабочая станция Intel Core i7 3770 (3400Mhzx8)/ОЗУ 8Gb(4Gb)/2Gb Video Hd 4000	8

Таблица 17 - Сетевое программное обеспечение.

Тип программного обеспечения	Наименование оборудования
Сетевая операционная система	MS Windows Server 2003 Standard Edition RUS
Сервер баз данных	SQL Server 2000 Standard Edition
Антивирусная программа	ESET NOD32 Smart Security Business
Файрвол	Outpost Firewall Pro 4.0
Почтовый сервер	Microsoft Exchange



5. НАДЕЖНОСТЬ АВТОМАТИЗИРОВАННОЙ СИСТЕМЫ

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

5.1 Обзор модели надежности

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

На рисунке 1 представлена одна из многих классификаций моделей надежности.

Рисунок 11 - Классификация моделей надежности

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

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

5.2 Основание выбора модели надежности

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

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

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

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

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

5.3 Методика расчета надежности по выбранной модели

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

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

N= (1)

где S - количество внесенных ошибок;

n - число найденных собственных ошибок;

V - число обнаруженных к моменту оценки искусственных ошибок.

Вторая часть модели связана с проверкой гипотезы от N. Предположим, что в программе имеется K собственных ошибок и внесем в нее еще S ошибок. В процессе тестирования были обнаружены все S внесенных ошибок и n собственных ошибок. Тогда по формуле Миллса мы предполагаем, что первоначально в программе было N равно n ошибок. Вероятность, с которой можно высказать такое предположение, можно рассчитать по следующему соотношению:

,

,

где C - мера доверия к модели, показывающая вероятность того, насколько правильно найдено значение N.

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

,

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

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

5.4 Расчет надежности автоматизированной системы

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

Перед началом тестирования в программу было внесено 5 искусственных ошибок, формализованных согласно приведенному выше методу. В результате тестирования было обнаружено 4 искусственно сгенерированных ошибок и 1 собственная. Используя формулу (1) из первой части модели Миллса, произведем расчет первоначального комплекса ошибок N, полученное равным 1.

,

Для проверки корректности полученного значения N, необходимо применить формулу (3) из второй части модели Миллса, результат которой отражает значение степени доверия к данному значению N.



C =

C==

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

Для достижения требуемого уровня доверия (90%) к предполагаемому количеству оставшихся ошибок N=1, выявленному по результатом применения первой части модели Миллса, необходимо сгенерировать не менее 20 искусственных ошибок, обнаружив их все при тестировании и не раскрыв более 1 собственной ошибки. Такой подход является не рациональным, ввиду большой трудоемкости процесса формализации большого количества искусственных ошибок, а так же из-за возникающего риска получить полностью неработоспособное программное обеспечение, неспособное выполнять даже базовый функционал. Поэтому будем вносить за один раз не более 10 искусственных ошибок, 5-7 из которых можно создать полностью самостоятельно, а в качестве остальных использовать найденные в процессе тестирования, выполняя перерасчет значений N, С для каждого выполненного теста.

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

,

,

,

,

,

При проведении второго теста были использованы составленные на предшествующем этапе 5 искусственных ошибок и одна найденная собственная, помеченная как искусственно созданная. Таким образом, перед началом второго теста в программу было внесено 6 ошибок, в ходе которого было выявлено 4 искусственных и не одной собственной. Выполнения расчета количества оставшихся ошибок в программе N и соответствующего уровня доверия С производится аналогично соответствующем расчетам на первом этапе тестирования, согласно формулам (1) и (3). (Далее при выполнении аналогичных вычислений на последующих этапах тестирования, для краткости, не будем приводить формулы).

,

,

,

,

Полученный уровень доверия, равный 57% к значению N, предписывает продолжить тестирование.

На текущей, третьей итерации процесса тестирования внесем еще одну искусственную ошибку. Результаты теста следующие - обнаружено 6 из 7 искусственных и 2 собственных ошибки. Проведем расчет N, C:

,

,

,

,

Не смотря на большее, по сравнению со вторым повтором количество внесенных и найденных ошибок, ввиду обнаружения 2-х собственных, значение С, уменьшилось до 47%, при N равном 2.

На четвертом повторе был использован комплекс из 9 искусственных ошибок, в состав которого включены 2 собственные, найденные на предыдущем этапе тестирования и помеченные как искусственные. В ходе проведения теста было обнаружено 8 из 9 внесенных ошибок и 1 собственная. Выполним расчет N, C:

,

,



,

,

Полученное значение уровня доверия С равна 65%, позволяет утверждать, что оставшееся количество ошибок в тестируемом программном обеспечении близко к 1. Так же, в нашем распоряжении есть еще одна формализованная ошибка, которую в дальнейших тестах будем считать искусственной. Таким образом, мы приблизились к целевым условиям, дающим возможность провести тест, с участием 10 искусственных ошибок и достаточно весовым основаниям не встретить ни одной собственной ошибки на момент обнаружения всех искусственных, что позволит привести утверждение об отсутствии ошибок в исходном программном обеспечении с 90% доверия к этому утверждению.