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

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

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

1. Общие положения

Назначение и область применения.

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

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

Для того чтобы качественно вести учет ремонтных работ, необходимо разработать информационную систему (ИС) по учёту товара на складе. Данная ИС реализована в программе «1С: Предприятие (ред. 8.2)»

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

2. Описание процесса деятельности предприятия

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

Разработка состоит из следующих этапов:

I этап. На этом этапе достигают соглашение по поставленной проблеме (табл. 1).

Табл. 1

Проблема	Описание
1. Поставленная цель	Разработать программу по автоматизации учёта ремонта автомобилей.
2. На кого воздействует и результатом чего является?	Непосредственно на сотрудников предприятия
3. В чем заключается выигрыш?	Оперативный учет ремонта автомобилей

II этап. Заключается в выявлении причин лежащих в основе проблемы:

· Неавтоматизированный учет может привести к ошибкам учета информации по реализуемым товарам;

· не ординарное распределение ресурсов - может привести к недостаче.

III этап. Выявляются пользовательское программное обеспечение (ПО) и лица заинтересованные во внедрении этого ПО. Выявление осуществляется с помощью анкетирования, путем ответа на вопросы (табл. 2).

Табл. 2

Номер	Вопрос	Ответ
1	Кто является пользователем системы?	Пользователями системы являются: Диспетчер
2	Кто является заказчиком этой системы?	Заказчиком этой системы является: КГОУ СПО «Камчатский политехнический техникум»
3	На кого оказывает влияние результат решения ПО?	Влияние оказывает на автомастерскую, т.к. она производит ремонт автомобилей.
4	Кто будет принимать, и оценивать ПО?	Принимать и оценивать ПО будет заказчик.
5	Существуют ли другие пользователи возможно внешние, чье мнение следует учитывать?	Да, существуют другие внешние пользователи, как клиент, механик, т.к. все действия с поступлением денег проходит через бухгалтерию.
6	Кто будет сопровождать систему?	Сопровождать систему будет программист, т.к. он знает, что делать в случае неполадок в системе.

IV этап.

Определение границы системы путем подготовки ответов на следующие вопросы:

Табл. 3

Номер	Вопрос	Ответ
1	Кто будет управлять системой?	Системой будет управлять администратор и пользователь.
2	Кто будет сопровождать систему?	Сопровождать систему будет группа программистов, т.к. они смогут найти ошибки и исправить систему, в случае проблем.
3	Откуда система получает информацию?	Система получает информацию из архивов со списками ИП и поступлений товаров из документации бухгалтеров.
4	С какими внешними системами эта система будет взаимодействовать?	Взаимодействие с другими системами не предусматривает.

Функциональная диаграмма (IDEF0).

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

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

Особенностью IDEF 0 диаграмм является то, что на них не указаны явно ни последовательность, ни время.

Одной из наиболее частых проблем, возникающих в процессе построения IDEF 0 моделей, является определение момента завершения процесса построения модели.

Рекомендации, которыми пользуются опытные аналитики, выражаются в следующем:

· для понимания работы системы достаточно разработать 3-4 уровня;

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

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

· рекомендуется прекращать моделирование, когда уровень детализации модели удовлетворяет ее цели.

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

· случайная (конкретная связь между функциями незначительна или полностью отсутствует);

· логическая (данные и функции собираются вместе благодаря тому, что они попадают в общий класс, но необходимых функциональных отношений между ними нет);

· временная (функции, связанные во времени, когда данные используются параллельно или функции включаются параллельно, а не последовательно);

· процедурная (функции сгруппированы потому что они выполняются в одной и той же части цикла или процесса);

· коммуникационная (функции группируются если они используют одни и те же входные данные или производят одни и те же выходные данные);

· последовательная (выход одной функции является входом для другой);

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

Схемы информационных связей работы зав складом и сотрудников определенны на рисунках 1 - 4.



Рис. 1. Диаграмма IDEF 0 (нулевой уровень)

На рисунке 2 показан первый уровень модели IDEF 0. Здесь поэтапно показаны все процессы связанные «Менеджментом Торговых Сетей» и задействованные в этом сотрудники.

Рис. 2. Диаграмма IDEF 0 (первого уровня)

Второй уровень диаграммы IDEF 0, на котором показан процесс заказа товара (Рис. 3).



Рис. 3. Диаграмма IDEF 0 (Второго уровня)

Рис. 4. Диаграмма IDEF 0 (второго уровня)

Второй уровень диаграммы IDEF 0, на котором показан процесс поступления товара на склад (Рис. 4).



Рис. 5. Диаграмма IDEF 0 (третьего уровня)

Диаграмма дерева узлов показана на рисунке 6.

Рис. 6. Диаграмма дерева узлов

Диаграмма бизнес-процессов (IDEF3).

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

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

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

Рис. 7. Виды связей

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

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

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

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

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

· разворачивающие соединения используются для разбиения потока;

· сворачивающие соединения объединяют потоки.

При построении диаграмм IDEF3 используются три вида соединений, представлены на рис. 8.

Рис. 8. Виды соединений

Диаграмма IDEF 3 представлена на рисунке 9.

Рис. 9. IDEF 3 Диаграмма

Элементы диаграмм J1, J2 предназначены для отражения логической связи между видами работ в процессе проведения соревнований. Символ О говорит о связке «Или», символ & - о связке «И».

Аналитическая модель.

Диаграмма вариантов использования.

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

Рис. 10. Диаграмма вариантов использования

Полученная диаграмма подлежит описанию в виде ответов на определенные виды вариантов. Краткая форма описания варианта использования показана в таблице 4.

Табл. 4

Название варианта	Автоматизированный учет выпуска продукции
Цель	Создание базы данных, в которую будет вноситься информация об автомобилях, которые требуют ремонта, регистрация их владельцев, детали требующиеся для ремонта и марка автомобиля.
Действующие лица	Программист, диспетчер, механик и клиент.
Краткое описание	Программист разрабатывает базу данных, куда диспетчер заносит заказ клиента, который впоследствии обрабатывает механик и выполняет данный заказ
Тип варианта	Основной.

Краткая форма описания варианта использования дополняется полной формой описания, она показана в таблице 5.

Табл. 5

Действие человека	Отклик системы
1) руководствуясь требованиями заказчика и под его контролем создает и правильно оформляет базу данных и ставиться на пользовательский компьютер	2) Программа устанавливается на каждый пользовательский ПК и запускается отладка.
3) Диспетчер, ознакомившись с требованиями и заказами клиентов, оформляет заявку и отправляет её в базу данных.	4) База данных сохраняет заявку в журнале документов
5) Механик, заходит в базу данных, находит заявку. Ознакомившись с ней, приступает к её выполнению.	6) База данных выдаёт механику информацию из журнала документов о заказе
7) Механик поставляет товар, в точку назначения и заносит информацию о поставке в базу данных.	8) База данных сохраняет в себе информацию о выполненной работе с комментариями механика

Диаграмма взаимодействий.

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

Диаграмма взаимодействий представлена на рисунке 11.

Рис. 11. Диаграмма взаимодействий

3. Основные технические решения

Инфологическая модель.

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

Сущность:

· Клиент (ФИО, Адрес, Телефон, Магазин, Размер вклада в магазин, номер регистрации, дата регистрации);

· Мастерская (Адрес, ФИО, возраст, стаж работы);

· Автомобиль(ФИО, Адрес, Телефон, Стоимость поставки);

· Механик (Название, Адрес, Телефон, Уставной капитал, Профиль ).

Связи:

· Контроль;

· Оформление заказа;

· Выполнение заказа.

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

Рис. 12. Инфологическая модель

информационный интерфейс даталогический

Даталогическая модель.

На этом этапе проектирования в ER-модель добавляются дополнительные реквизиты, но с таким условием, чтобы они не противоречили требованиям усиленной третьей нормальной формы. Схема даталогической модели показана на рисунке 13.



Рис. 13. Даталогическая модель

Диаграмма потоков данных (DFD).

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

· функции обработки информации (работы);

· документы, объекты, сотрудников или отделы, которые участвуют в обработке информации;

· внешние ссылки, обеспечивающие интерфейс с внешними объектами, находящимися за границами моделирования системы;

· таблицы для хранения документов (хранилища данных).

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

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

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

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

Хранилище данных. Хранилище данных изображает объекты в покое. В материальных объектах хранилища данных изображаются там, где объекты ожидают обработки. Например, хранилище «Технологические карты».

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

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

Построение DFD диаграмм ассоциируется с разработкой программного обеспечения.

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

· Размещать на каждой диаграмме от 3 до 6-7 процессов;

· Не загромождать диаграммы не существенными на данном уровне деталями;

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

· Выбирать ясные имена процессов и потоков, не использовать аббревиатуры.

Диаграмма информационных потоков представлена на рисунке 14.

Рис. 14. Схема даталогической модели

Структура диалоговых окон.

Проектирование диалоговых окон.

На рисунке 15 показана форма справочника «Номенклатура», в нём сохраняются все запчасти, которые хранятся в автомастерских.



Рис. 15. Форма справочника «Номенклатура»

На рисунке 16 показана форма справочника «Мастерские», в нём сохраняются все мастерские, а так же их телефоны и адреса.

Рис. 16. Форма справочника «Мастерские»

На рисунке 17 показана форма справочника «Единицы измерения», в нём сохраняются все единицы измерения необходимые автомастерским.

Рис. 17. Форма справочника «Единицы измерения»

Схема интерфейса.

На рисунке 18 показан набор справочников, отчетов, регистров и документов использованных в БД «Автоматизированный учет выпуска продукции».

Рис. 18. Схема интерфейса

4. Выходные формы

Структура запросов

Запрос используется для создания отчетов, структура запроса приведена в таблице 6.

Табл. 6. Документ о выполняемых ремонтных работах.

Объект	Реквизит	Функция	Сортировка, Упорядочить	Группировка
Документ "Ремонтная работа"	Материал Цена Количество Сумма	Всего	Да да	Да Да

Макеты выходных форм.

Макетами выходных форм считаются отчеты, которые формируются во время процесса занесения документов в регистры . Сами отчеты формируются на основании информации, выбранной из БД по запросу.(рис. 19).

Рис. 19. Форма отчёта "Материалы"

5. Мероприятия по подготовке объекта к эксплуатации

Для подготовки объекта к эксплуатации , должны быть выполнены условия:

1) Установить на компьютере заказчика разработанный программный продукт;

2) Демонстрация заказчику работоспособность программного продукта на тестовом задании;

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

4) Выполнить работу по заполнению БД начальной информации;

5) Проверить работоспособность программного продукта на реальной информации;

6) Оформить акт о сдаче ПП в программной эксплуатации.

Литература

1. Единая система программной документации (сборник ГОСТов):

2. 1С: Предприятие «Описание встроенного языка часть 1, часть 2».

3. 1С: Предприятие «Конфигурирование и администрирование».

4. 1С: Предприятие «Описание типовой конфигурации».

5. Усиков Т.Н. 1С: Предприятие «Эффективное программирование».

6. Бобцов А. «Банки и базы данных. Основы работы» / А. Бобцов, В. Шиегин. - СПб., 2005. - 93с.

Размещено на Allbest.ru

...