Разработка типовой конфигурации для автоматизации учебно-производственного отдела ОАО «ЖБК» в среде программирования 1С Конфигуратор

Создано admin . Опубликовано в Для диплома

po

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

 

Если Вам нужна для ознакомления полная версия проекта с исходниками, презентациями, выступлениями и т.д., то пишитеigwt@mail.ru. Проект (диплом) предоставляется только по взаимовыгодным условиям, которые обсуждаются индивидуально. Это может быть например: совместная работа над этим сайтом, участие в написании контента для сайта, разработка для этого проекта модулей, плагинов и.д. (всего, что приведет к продвижению или улучшению проекта). А также готовы выслушать ваши предложения.

 

Преддипломная практика проходила на ОАО «Железобетон». Свою историю фирма ОАО «Железобетон» ведёт с 1990 года. За эти годы ОАО «Железобетон» успел зарекомендовать себя на рынке Ставропольского края как серьёзный и надёжный партнёр, а также завоевать доверие у наших покупателей.

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

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

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

 

 

Анализ и моделирование требований

 

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

Безымянный

Рисунок 1.6 – Алгоритм этапа «Анализ и моделирование требований»

 

Модель требований включает актеров и варианты использования (use cases). Эта модель является основой всего жизненного цикла ПО, она используется при дизайне, реализации и тестировании.

На рисунке 1.7 показана модель прецедентов для данной предметной области сделанную с использованием Rational Rose.

1231658486

Рисунок 1.7 – Модель прецедентов функций учебного центра

 

Созданная в итоге бизнес-модель является основой для последующего моделирования ПО.

 

Спецификация требований

 

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

Спецификация должна описывать:

– функциональность. Что должно выполнять ПО? Все требования, перечисляемые в этом разделе, должны быть точно сформулированы и одинаково пониматься заказчиком и исполнителем.

– внешние интерфейсы. Как ПО взаимодействует с пользователями, оборудованием и другими системами?

– атрибуты ввода и вывода. Определяют вводимые и выводимые данные.

– ограничения на функциональность.

– прочие нефункциональные требования.

56464

Рисунок 1.8 – Обследование организации (бизнес-анализ)

 

Цель этой стадии — разработка требований к ПО. Она является основой для разработки и проведения приемо-сдаточных испытаний. Главным моментом при составлении Спецификации является достижение взаимопонимания между разработчиком и заказчиком. Все требования к ПО должны одинаково пониматься как Разработчиком, так и Заказчиком.

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

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

Цели бизнес-анализа заключались в следующем:

—      понять структуру и динамику работы организации;

—      определить проблемы, возникающие в работе организации, и возможности их решения, направленного на повышение эффективности работы организации;

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

—      вывести требования к программным системам, автоматизирующим работу организации.

В Приложении 1 показана разработанная спецификация для обозначенных требований.

ОАО «Железобетон» – это крупный производственный комплекс. Полноценная материально-техническая база и современное оснащение позволяют предприятию быть практически автономным и работать в усиленном режиме.

В состав ОАО «Железобетон» входят:

— бетонно-растворный цех — выпускает бетон любой марки и раствор строительный;

— арматурный цех — занимается изготовлением каркасов и сеток, в том числе для организаций и частных лиц;

— три цеха по производству сборного железобетона;

— асфальтный цех;

— цех стеновых материалов – производит облицовочный кирпич, стеновые блоки и тротуарные бордюры;

— деревообрабатывающий цех – изготавливает оснастку для выпуска ЖБИ, прокладки, изделия из древесины (окна, двери и т.п.);

— ремонтно-механический цех – занимается производством и обслуживанием станков, механизмов, опалубки из металла;

-транспортный цех – осуществляет доставку ЖБИ, а также перевозки внутри предприятия;

— конструкторское бюро;

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

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

ООО Торговый дом «Железобетон» делает все возможное для того чтобы клиентам было удобно работать с заводом, для этого была создана товаропроводящая сеть завода, которая представлена торговым домом в г.Невинномысске и тремя представительствами в Ставрополе, Черкесске и Минеральных водах. Все они работают в рамках единой ценовой политики с центром распределения продукции в г.Невинномысске. Близость к потребителям позволяет доставлять продукцию в любой район ЮФО по ценам ниже сложившихся в данном районе. География наших поставок это Ставрополь, города Кавмингруппы, Краснодар, Ростов, Карачаево-Черкессия, Дагестан, Осетия, Чеченская республика, Кабардино-Балкария. Бесперебойность доставки продукции потребителям обеспечивает собственный парк техники, позволяющий перевозить не только блоки и плиты, но и такие сложные изделия, как плиты ПНС, стеновые панели, колонны. Все машины имеют разрешение на перевозку негабаритных грузов.

Основным результатом бизнес-анализа стала бизнес-модель, которая представляется на языке UML. Она включает:

1. Структуру организации — статическое описание подразделений организации и отношений подчиненности в виде диаграмм пакетов и/или классов.

авиывпор

Рисунок 1.9 – Структура организации

 

2. Модель видов деятельности, описывающую бизнес-актеров и виды деятельности организации. К числу бизнес-актеров относятся: партнеры, поставщики, внешние информационные системы и т. д. Виды деятельности представляют собой бизнес-процессы. Модель видов деятельности представляется с помощью use case диаграмм UML и уточняющих их технологических сценариев в виде диаграмм последовательностей и/или деятельностей.

ыарырп

Рисунок 1.10 – Модель видов деятельности менеджера учебного центра

 

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

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

1

Рисунок 1.11 —  Диаграмма последовательности оформление договора на обучение

2

Рисунок 1.12 —  Кооперативная диаграмма оформление

договора на обучение

 

Объектная модель также включает диаграммы классов. Рассмотрим создание диаграмм классов (добавление связей между классами).

3

Рисунок 1.13 — Диаграмма классов «Оформления нового договора на обучение»

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

Добавим связи к классам, принимающим участие в варианте использования «Оформление нового договора на обучение» показано на рисунке 1.13.

 

Аттестация требований

 

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

Число прототипов определяется на основе учета разных параметров – размера проекта, анализа рисков, пожеланий Заказчика и т. д. Традиционно разрабатываются 3 прототипа.

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

4

Рисунок 1.14 – Стартовая форма

 

Результаты первого этапа прототипирования показаны в Приложении 2.

Второй прототип содержит реализацию основной функциональности ПО.

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

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

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

5

Рисунок 1.15 – Алгоритм реализации прототипирования

 

По завершении каждого прототипа выполняется коррекция и уточнение модели на основе реинжиниринга. Тем самым обеспечивается соответствие модели и программного кода как для каждого реализованного прототипа, так и для ПО в целом.

 

Проектная часть

Проектирование пользовательского интерфейса

 

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

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

6

Рисунок 2.2 – Главная форма надстройки в 1С 8.0.

123456789

Рисунок 2.3  — Диаграмма пользовательского интерфейса

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

 

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

 

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

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

987

Рисунок 2.4 – Концептуальная модель данных подсистемы

Разработанная логическая модель данных для работы отдела ЖКХ представлена на рисунке 2.5

321

Рисунок 2.5 – Логическая модель данных подсистемы отдела ЖКХ

456

Рисунок 2.6 – Физическая модель данных

 Основные формы прототипа ИС

369

258

147

Безымянный

132

159

357

456

789

123456789

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

Если Вам нужна для ознакомления полная версия проекта с исходниками, презентациями, выступлениями и т.д., то пишитеigwt@mail.ru. Проект (диплом) предоставляется только по взаимовыгодным условиям, которые обсуждаются индивидуально. Это может быть например: совместная работа над этим сайтом, участие в написании контента для сайта, разработка для этого проекта модулей, плагинов и.д. (всего, что приведет к продвижению или улучшению проекта). А также готовы выслушать ваши предложения.

С ув. Эдуард Тихонов

Похожие материалы:

Понравилась статья? - поделитесь ею со своими друзьями!

Хотите Быть В Курсе Всех Новинок Сайта?!

Подпишитесь прямо сейчас, и получайте обновления на свой E-Mail:

Ваш E-Mail в безопасности

Есть что сказать? - Комментируй!

Комментарии Facebook

А Вы что думаете?