Проектирование АИС по учету продаж бытовой техники

">Методическое обеспечение АИС «Домовой» должно включать в себя следующую документацию:

-         техническую документацию на комплекс технических средств;

-         программную документацию на программные средства;

-         методическую документацию по системе внутреннего контроля;

-         должностные инструкции, которые должны содержать информацию для персонала, необходимую для работы.

2.4             Состав и содержание работ по созданию системы

Перечень документов, по ГОСТ 34.201, предъявляемых по окончании соответствующих стадий и этапов работ представлены в таблице 1.

 

 

 

 

Таблица 1

Название этапа	Содержание работ	Сроки выполнения	Форма отчетности
Формирование требований к Системе	Разработка основных технических решений и документаций.	С 24.10.2009 по 30.10.2009	Отчет по обследованию. Перечень выходных документов. Описание автоматизируемых функций; Описание постановки задач (комплекса задач).
Разработка Технического проекта и Разработка Технического задания	Разработка требований к Системе	С 31.10.2009 по 10.11.2009	Комплект проектной документации, выполненный по ГОСТ 34.201-89
Разработка Эскизного проекта	Разработка эскизно-технический проекта по внедрению автоматизированной системы	С 11.11.2009 по 25.11.2009	Ведомость эскизного проекта, пояснительная записка к эскизному проекту.
Работы по закупке и поставке оборудования Системы	Осуществление закупки и поставки оборудования.	С 26.11.2009 по 10.12 2009	Смета расходов на закупку необходимого дополнительного оборудования
Работы по настройке оборудования системы	Проведение работ по установке, подключению и первоначальной настройки технических средств Системы.	С 11.12.2009 по 09.01.2010	Акт об окончании работ
Работы по разработке, поставке и инсталляции ПО	Разработка заказного ПО, определенного в техническом проекте. Инсталляция и настройка ПО на технических средствах Системы.	С 10.01.2010 по 28.01.2010	Акт об окончании работ по инсталляции ПО.
Проведение предварительных испытаний опытного образца Системы, передача ее в опытную эксплуатацию	Обучение персонала Заказчика. Проведение предварительных испытаний в соответствии с согласованной методикой. Устранение неисправностей и внесение изменений в документацию, в т.ч. эксплуатационную, в соответствии с протоколом испытаний.	С 29.02.2010 по 11.03.2010	Акт о передаче Системы в опытную эксплуатацию Отчет об использовании финансовых средств
Проведение приемо-сдаточных испытаний доработанной Системы	Проведение испытаний, опытная эксплуатация доработанной Системы, анализ результатов, устранение выявленных недостатков. Передача Системы в опытную эксплуатацию	С 12.03.2010 по 21.03.2010	Протокол испытаний, Акт о передаче Системы в эксплуатацию, Отчет об использовании финансовых средств

2.5  Порядок контроля и приемки системы

Система должна пройти следующие основные виды испытаний:

-         предварительные испытания;

-         опытную эксплуатацию;

-         приемочные испытания.

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

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

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

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

Заключение о возможности ввода доработанной Системы в действие (промышленную эксплуатацию) принимается на основании результатов:

-         выполнения контрольного примера (сценария), алгоритм которого согласуется и утверждается предварительно;

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

При проведении предварительных или приемосдаточных испытаний должен составляться протокол, подписываемый Заказчиком и Исполнителем.

Перед проведением приемосдаточных испытаний Исполнитель обязан предъявить комиссии нижеперечисленные документы:

-         техническое задание на создание опытного образца системы;

-         проектную, рабочую и программную документацию (по согласованному перечню) на опытный образец системы;

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

-         акт о проведении обучения обслуживающего персонала и передаче эксплуатационной документации в эскизном исполнении;

-         акт приемки опытного образца Системы в опытную эксплуатацию;

-         протокол опытной эксплуатации.

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

 

2.6             Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие

-         Придать информации вид, пригодный для обработки на персональном компьютере.

-         Создание дополнительных служб и подразделений для функционирования ИС «Кадры» не требуется.

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

-         Установить системное программное обеспечение и протестировать его.

Подготовка персонала:

-           повышение квалификации персонала;

-           подготовка новых специалистов;

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

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

2.7  Требования к документированию

Перечень подлежащих к разработке документов указан в таблице 1.

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

 

 

3 РАЗРАБОТКА ТЕХНИЧЕСКОГО ПРОЕКТА

3.1  Основание для разработки системы

Основанием для разработки АИС «Домой» является контракт №1519-08-06 от 24.10.2009 года на выполнение работ по созданию автоматизированной информационной системы «Учет продаж бытовой техники» между ОАО «ТАА» и ООО «Домовой».

3.2  Краткая характеристика системы

Основными компонентами АИС «Домовой» являются:

      База данных.

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

Функциональные возможности MS Access позволяют:

-         создавать документы непосредственно в системе или загружать в нее уже готовые электронные представления;

-         добавлять в текст документа иллюстрации, таблицы, графики, отчеты и т.п.;

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

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

3.3  Проектирование

Для эффективного функционирования разрабатываемой системы «Домовой» будет разработана СУБД.

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

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

Основной недостаток реляционной модели данных связывается с низкой производительностью реляционной СУБД. Но разработка современных СУБД таких как, ORACLE, InterBase, Access и др. позволило преодолеть и этот недостаток.

Достоинства реляционной модели можно разделить на две группы:

1.      достоинства для пользователя:

-         реляционная БД представляет собой набор таблиц с которыми пользователь привык работать;

-         не нужно помнить пути доступа к данным и строить алгоритмы и процедуры обработки своего запроса;

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

2.      достоинства обработки данных реляционной БД:

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

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

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

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

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

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

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

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

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

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

Обязанности по созданию новых типов возложены на администратора базы данных. Механизм создания новых типов документов заключается в следующем:

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

2.      Администратор уточняет и согласовывает список реквизитов и их типы;

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

3.4             Процесс проектирования автоматизируемой системы

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

 

Правильная приемка и оформление документами поступивших товаров является надежной основой сохранности товарно-материальных ценностей.

Все сущности, их атрибуты и ключи представлены в таблице 2.

Таблица 2

Название сущности	Атрибут	Ключ
Категория	№Категории, наименование категории	№Категории
Производитель	№Производителя, имя производителя	№Производителя
Товар	№Товара, наименование товара, мощность, цена, производитель, категория	№Товара
Продажа	№Продажи, наименование товара, количество, цена, дата заказа.	№Продажи
Сотрудник	№Сотрудника, ФИО сотрудника, дата рождения, телефон.	№Сотрудника