Главная Коллекция "Otherreferats" Программирование, компьютеры и кибернетика Проектирование системы приема заказов для завода "Автоприбор"

Проектирование системы приема заказов для завода "Автоприбор"

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

Рубрика Программирование, компьютеры и кибернетика
Вид курсовая работа
Язык русский
Дата добавления 11.12.2012
Размер файла 2,4 M

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Страница:

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

Содержание

Введение

1. Обследование объекта автоматизации

1.1 Данные о предприятии

1.2 Обзор аналогов системы

1.3 Организационная структура

1.4 Реестр внутренней информации

1.5 Реестр исходящей информации

2. Бизнес-процессы до автоматизации организации

2.1 Описание бизнес-процессов по методологии IDEF0

2.2 Описание информационных потоков по методологии DFD

3. Техническое задание. Состав и содержание

3.1 Общие сведения

3.2 Назначение и цели создания системы

3.3 Характеристика объекта автоматизации

3.4 Требования к системе

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

4. Объектно-ориентированные проектирование ИС

4.1 Диаграмма прецедентов

4.2 Диаграмма классов с концептуальной точки зрения

4.3 Диаграмма состояний объектов класса

4.4 Диаграмма видов деятельности

4.5 Диаграмма последовательности

5. Сетевой план выполнения проектных работ

5.1 Определение состава работ по стадиям и этапам

5.2 Содержание работ на каждом этапе

5.3 Первоначальный сетевой план

5.4 Квалификационный план

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

6. Оценка достоверности выдаваемой информации

Заключение

Литература

Введение

dfd автоматизация диаграмма прецедент

В рамках данного проекта будет спроектирована система приема заказов завода «Автоприбор».

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

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

Оценка специалистами технологичности и экономичности поступающих заказов.

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

Бухгалтерский учёт заказов, закупленных материалов и стоимости производства.

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

Передача конструкторской документации внутри производственных отделов.

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

1. Обследование объекта автоматизации

1.1 Данные о предприятии

Объектом автоматизации является завод «Автоприбор».

- полное наименование эмитента

открытое акционерное общество «Завод Автоприбор»

- сокращенное наименование

ОАО «Завод Автоприбор»

местонахождение

центральная Россия, 180 км от Москвы в сторону Н.Новгорода

почтовый адрес

600016, Россия, г. Владимир, ул. Большая Нижегородская, д.79

дата государственной регистрации

17 марта 2003г

- орган осуществивший регистрацию

Межрайонная инспекция Министерства Российской Федерации по налогам и сборам № 10 по Владимирской области

ОГРН

1033303408995

аудитор

ООО “Центр аудита и оценки “Владстандарт” г. Владимир

держатель реестра акционеров

Владимирский филиал ООО “Региональная Регистрационная Компания” (лицензия ФСФР России № 10 -000-1-00308 от 19.03.04 года без ограничения срока действия)

1.2 Обзор аналогов системы

Система организации приёма заказов DOCUMETR for SharePoint.

аковы преимущества при организации работы подразделения по приему заказов при помощи системы электронного документооборота DOCUMETR?

Сохраняется история всех заказов с возможностью просмотра и поиска данных, указанных в заказе (дата создания, параметры заказа, ФИО ответственного и др.).

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

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

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

Работа с инструментами корпоративных порталов, созданных на базе Windows SharePoint Services (WSS) или Microsoft Office SharePoint Services (MOSS), как правило, происходит только в рамках локальной сети, следовательно, система независима от сбоев сторонних поставщиков услуг связи и достаточно хорошо защищена от возможных внешних воздействий.

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

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

2. 1С: Автоматизация приема заказов, формирования дневного производственного задания, учета готовой продукции и взаиморасчетов с покупателями.

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

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

В конфигурации реализованы следующие функциональные возможности:

* учет готовой продукции на складе готовой продукции с автоматизацией внутрискладских процессов (инвентаризация, оприходование, отгрузка) с помощью «1С:Расширения для КПК»;

* учет заказов покупателей;

* групповое формирование отгрузочных и налоговых документов операторами отдела сбыта;

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

* импорт банковских документов из системы «Клиент-Банк»;

* контроль взаиморасчетов с покупателями;

* взаимодействие с бухгалтерской учетной системой на базе «1С:Предприятие 7.7 Комплексный учет»;

* формирование аналитической отчетности по разделам учета (готовая продукция, взаимоотношения с покупателями).

3. Прием заказов компании “Вайллант группа Украина”

Прием заказов на запчасти и доставка запчастей

Для осуществления качественного сервисного обслуживания продукции Saunier Duval ДП «Вайллант группа Украина» реализует запасные части на все официально ввезенное оборудование Saunier Duval. Официальный Сервисный партнер может приобрести запасные части непосредственно со склада ДП «ВГУ». По вопросам наличия запчастей на складе ДП «ВГУ» обращайтесь по телефону (###) ###-##-##. Для приобретения запасных частей Сервисному партнеру необходимо заполнить «Бланк заказа запасных частей» с указанием артикульного номера, наименования, необходимого количества запчастей. Бланк заказа необходимо отправить по факсу (###) ###-##-##/## или электронной почте ***@vaillant.ua. Счет на Ваш заказ Вы получите в кратчайшие сроки по факсу или электронной почте, указанным Вами в бланке заказа. Время доставки: 2 - 4 дня, при условии наличия товара на складе и своевременной оплаты счета.

DOCUMETR for SharePoint.

1С: Конфигурация для автоматизации приема заказов

Прием заказов компании “Вайллант группа Украина”

Удобный интерфейс для работников предприятия

?

?

X

Не обязательно наличие дополнительного ПО

X

X

?

Интеграция с оффисными приложениями

?

X

X

Интеграция с “1С: Предприятие”

X

?

X

Предусматривает создание онлайн-форм для заполнения клиентом

?

?

X

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

1.3 Организационная структура

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

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

2. Бизнес-процессы до автоматизации организации

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

2.1 Описание бизнес-процессов по методологии IDEF0

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

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

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

Стрелка входа «Требования к изделиям» представляет собой предоставляемые заказчиком особые требования к изделиям или процессу их производства.

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

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

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

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

Основной блок процесса выполнения заказа.

Декомпозиция основного блока.

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

Функциональный блок «Получить согласие заказчика» описывает процесс отправки условий заказчику и получения от него согласия с условиями.

Функциональный блок «Разработать конструкторскую документацию» описывает процесс создания документации на производство изделия.

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

Функциональный блок «Закупить материалы» описывает процесс закупки требуемых для выполнения заказа материалов, которых на момент оценки заказа нет на складе.

Функциональный блок «Изготовить заказанные изделия» описывает процесс производства заказанных изделий в цехах завода.

Декомпозиция блока «Оценить возможность выполнения заказа»

Декомпозиция блока «Получить согласие заказчика»

Декомпозиция блока «Разработать конструкторскую документацию»

Декомпозиция блока «Оценить трудоемкость, распределить задания»

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

Основным объектом автоматизации будет являться блок «Оценить возможность выполнения заказа».

2.2 Описание информационных потоков по методологии DFD

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

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

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

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

Миниспецификация:

А-0. Выполнить заказ

ПРОЦЕСС: Выполнить заказ

ВХОД: Документация на изделия; Требования к изделиям; Чертежи; Сведения о материалах; Нормативные документы; Согласие на выполнение заказа

ВЫХОД: Заказ на закупку недостающих материалов; Условия выполнения заказа; Выполненный заказ

ПОДПРОЦЕССЫ:

А1. Оценить возможность выполнения заказа

А2. Разработать конструкторскую документацию

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

А4. Изготовить заказанные изделия

А0. Выполнить заказ

ПРОЦЕСС: Оценить возможность выполнения заказа

ВХОД: Документация заказчика; Данные о свободных финансах предприятия; Сведения о материалах; Нормативные документы

ВЫХОД: Условия выполнения заказа; Заключение о выполнимости заказа

ПОДПРОЦЕССЫ:

- Оценить технологичность заказа

- Систематизировать данные от заказчика по типовой форме

- Определить нормы расхода материала

- Определить стоимость и сроки выполнения

ПРОЦЕСС: Разработать конструкторскую документацию

ВХОД: Документация заказчика; Согласие на выполнение заказа; Нормативные документы; Заключение о выполнимости заказа; Сведения о материалах

ВЫХОД: Заказ на закупку недостающих материалов; Конструкторская документация

ПРОЦЕСС: Оценить трудоемкость и распределить задания

ВХОД: Конструкторская документация; Нормативные документы

ВЫХОД: Данные о зарплате рабочим; Задания рабочим

ПРОЦЕСС: Изготовить заказанные изделия

ВХОД: Конструкторская документация; Нормативные документы; Задания рабочим

ВЫХОД: Выполненный заказ

А1. Оценить возможность выполнения заказа

ПРОЦЕСС: Оценить технологичность заказа

ВХОД: Документация заказчика; Нормативные документы

ВЫХОД: Заключение о технологичности заказа

ПРОЦЕСС: Систематизировать данные от заказчика по типовой форме

ВХОД: Документация заказчика; Нормативные документы; Заключение о технологичности заказа; Бланк формы техпроцесса

ВЫХОД: Заключение о выполнимости заказа; Заполненная форма техпроцесса

ПРОЦЕСС: Определить нормы расхода материала

ВХОД: Заполненная форма техпроцесса; Нормативные документы

ВЫХОД: Нормы расхода материала

ПРОЦЕСС: Определить стоимость и сроки выполнения

ВХОД: Заполненная форма техпроцесса; Нормативные документы; Нормы расхода материала; Сведения о материалах; Данные о свободных финансах предприятия

ВЫХОД: Условия выполнения заказа

Реестр входной и выходной информации:

Входные данные:

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

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

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

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

Выходные данные:

Выполненный заказ - готовые изделия, поставленные заказчику.

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

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

3. Техническое задание. Состав и содержание

3.1 Общие сведения

1.1. Полное наименование системы и ее условное обозначение: Система приема заказов завода «Автоприбор».

1.2. Наименование предприятий (объединений) разработчика и заказчика (пользователя) системы и их реквизиты: разработчик системы - студент гр. ИСГ-108 Сычёв Роман Владимирович; заказчик системы - завод «Автоприбор».

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

1.4. Плановые сроки начала разработки и сдачи проекта: 17.09.2012 - 7.12.2012 без учета выходных.

1.5. Сведения об источниках и порядке финансирования работ: не оплачиваются.

1.6. Порядок оформления и предъявления заказчику результатов работ по созданию системы (ее частей), по изготовлению и наладке отдельных средств (технических, программных, информационных) и программно-технических (программно-методических) комплексов системы: передается в виде спроектированной системы в сроки окончания работы. Приемка системы осуществляется комиссией в составе представителей кафедры ИСИМ. Порядок предъявления системы, ее испытаний и окончательной приемки определяется календарным графиком выполнения курсового проекта.

Определения, обозначения и сокращения указаны в таблице:

1

ИСИМ

Информационные системы и информационный менеджмент

2

ТЗ

Техническое задание

3

ИС

Информационная система

3.2 Назначение и цели создания системы

2.1. Назначение системы: вид автоматизированной деятельности -- автоматизация системы приема и обработки заказов завода «Автоприбор»;

объект автоматизации: завод «Автоприбор»;

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

Основные задачи, решаемые при автоматизации:

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

разработка интернет-портала для доступа к системе управления заказами;

формирование отчетов и потоков данных на стадии оценки заказа;

отслеживание состояния заказа до его окончательного выполнения.

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

регистрация заказчика;

размещение заказа;

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

формирование условий выполнения заказа;

3.3 Характеристика объекта автоматизации

3.1. Предметной областью является система приема и обработки заказов завода «Автоприбор».

3.2. Основной задачей автоматизации является упрощение процесса приема и оценки заказов.

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

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

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

3.4 Требования к системе

4.1. Требования к системе в целом

4.1.1. Требования к структуре и функционированию системы

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

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

Web-интерфейс - подсистема формирования и визуализации информации.

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

Для организации информационного обмена между компонентами системы должны использоваться специальные протоколы прикладного уровня, такие как: NFS, HTTP и его расширение HTTPS, NetBios/SMB, Oracle TNS.

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

- Основной режим, в котором подсистемы СУЗ выполняют все свои основные функции.

- Профилактический режим, в котором одна или все подсистемы СУЗ не выполняют своих функций.

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

- работу пользователей в режиме - 24 часа в день, 7 дней в неделю

- выполнение своих функций - хранение, обработку и предоставление данных.

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

- техническое обслуживание;

- модернизацию аппаратно-программного комплекса;

- устранение аварийных ситуаций.

Общее время проведения профилактических работ не должно превышать 5% от общего времени работы системы в основном режиме (500 часов).

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

- СУБД

- Web-браузер

Обязательно ведение журналов инцидентов в электронной форме.

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

Требования к численности и квалификации персонала системы и режиму его работы

Требования к численности персонала

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

- Системный администратор - 1 человек.

Выполняет следующие обязанности:

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

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

- на всем протяжении функционирования КХД обеспечивает поддержку пользователей.

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

- Главный конструктор -- 1 человек

Выполняет следующие обязанности:

- руководит конструкторским отделом.

- обеспечивает оценку технологичности поступающих заказов.

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

- Начальник отдела экономики -- 1 человек

Выполняет следующие обязанности:

- руководит отделом экономики.

- обеспечивает оценку экономичности поступающих заказов.

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

- Начальник отдела приема заказов -- 1 человек

Выполняет следующие обязанности:

- руководит отделом приема заказов.

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

Требования к квалификации персонала

К квалификации персонала, эксплуатирующего СУЗ, предъявляются следующие требования:

- Администратор системы - знание методологии проектирования хранилищ данных; знание СУБД; знание языка запросов SQL; опыт администрирования СУБД; знание и навыки операций архивирования и восстановления данных; знание и навыки оптимизации работы СУБД; знание языков программирования PHP5 и HTML.

- Главный конструктор, Начальник отдела экономики, Начальник отдела приема заказов -- базовые навыки работы с компьютером; принцип обращения с файлами заказов и СУБД. Требования к квалификации установлены предприятием.

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

Требования к режимам работы персонала

Персонал, работающий с Системой КХД и выполняющий функции её сопровождения и обслуживания, должен работать в следующих режимах:

- Начальник отдела приема заказов - в соответствии с основным рабочим графиком подразделений Заказчика.

- Начальник отдела экономики - в соответствии с основным рабочим графиком предприятия.

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

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

Требования к надежности

Состав показателей надежности для системы в целом

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

Надежность должна обеспечиваться за счет:

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

- своевременного выполнения процессов администрирования Системы;

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

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

Вероятность безотказной работы системы за 500 часов должна быть не менее 0,95

Достоверность выдаваемой информации 0.98

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

В ходе функционирования системы могут возникнуть следующие аварийные ситуации:

- сбой в электроснабжении сервера

- ошибки СУЗ, не выявленные при отладке и испытании системы

- сбои программного обеспечения сервера

Требования к надежности технических средств и программного обеспечения

К надежности оборудования предъявляются следующие требования:

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

- применение технических средств соответствующих классу решаемых задач

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

К надежности электроснабжения предъявляются следующие требования:

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

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

- своевременного выполнения процессов администрирования;

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

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

Надежность программного обеспечения подсистем должна обеспечиваться за счет:

- надежности ПО

- проведением комплекса мероприятий отладки, поиска и исключения ошибок.

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

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

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

Требования к эргономике и технической эстетике

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

В части внешнего оформления:

- должно быть обеспечено наличие локализованного (русскоязычного) интерфейса пользователя;

- должен использоваться шрифт: GOST type A

- размер шрифта должен быть: 24

- цветовая палитра должна быть: Черно - белой

В части диалога с пользователем:

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

Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы

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

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

Требования к защите информации от несанкционированного доступа

Требования к информационной безопасности

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

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

- Разграничение прав доступа заказчика, работников предприятия и администратора

Требования к антивирусной защите

Средства антивирусной защиты должны быть установлены на всех рабочих местах пользователей и администраторов системы. Средства антивирусной защиты рабочих местах пользователей и администраторов должны обеспечивать:

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

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

- ведение журналов вирусной активности;

Требования по сохранности информации при авариях

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

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

Требования к защите от влияния внешних воздействий

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

- Система должна иметь возможность функционирования при колебаниях напряжения электропитания в пределах от 155 до 265 В

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

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

Требования по стандартизации и унификации

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

Моделирование должно выполняться в рамках стандартов, поддерживаемых программными средствами моделирования BPWin и Sparx Enterprise Architect.

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

Требования безопасности

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

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

Аппаратная часть системы должна быть заземлена.

4.2 Требования к видам обеспечения

4.2.1 Требования к информационному обеспечению

4.2.2.1 Требования к составу, структуре и способам организации данных в системе

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

- область временного хранения данных;

- область постоянного хранения данных;

Многомерная модель данных физически должна быть реализована в СУБД по иерархической топологии.

4.3.2.2 Требования к защите данных от разрушений при авариях и сбоях в электропитании системы

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

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

4.3.2.3 Требования к контролю, хранению, обновлению и восстановлению данных

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

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

К хранению данных предъявляются следующие требования:

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

К обновлению и восстановлению данных предъявляются следующие требования:

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

4.3.2 Требования к лингвистическому обеспечению

При реализации системы должны применяться следующие языки высокого уровня: SQL, PHP5, HTML.

Должны выполняться следующие требования к кодированию данных : UTF-8 для подсистемы хранения данных.

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

4.3.3 Требования к программному обеспечению

СУБД должна иметь возможность установки на ОС ХP, Windows 7

ETL-средство должно иметь возможность установки на ОС ХP, Windows 7

BI-приложение должно иметь возможность установки на ОС ХP, Windows 7

4.3.4 Требования к техническому обеспечению

Система должна быть реализована с использованием специально выделенных серверов Заказчика.

Сервер базы данных должен быть развернут на компьютере с минимальной конфигурацией: CPU: 800Mhz; RAM: 128 Mb; HDD: 512 Gb; Network Card: 2 (2 Gbit).

Минимальный объем свободного пространства для хранения данных на дисковом массиве должен составлять 100 Тб.

4.3.5 Требования к организационному обеспечению

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

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

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

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

Директивное время на создание и введение в действие системы -- 120 дней.

Работы по созданию системы выполняются в 5 этапов:

Постановка задачи. Результаты обследования объекта автоматизации. Техническое задание. Дата сдачи 5.10.2012

Объектно-ориентированное проектирование ИС. Дата сдачи 9.11.2012

Оценка надежности проектируемой системы. Оценка достоверности выдаваемой информации. Дата сдачи 16.11.2012

Сетевой план выполнения проектных работ. Дата сдачи 23.11.2012

Контроль оформления графического материала. Дата сдачи 30.11.2012

4. Объектно-ориентированные проектирование ИС

4.1 Диаграмма прецедентов

Документ описания прецедентов:

1.

Название: Регистрироваться как Заказчик

Краткое описание: Регистрация нового пользователя в системе приема заказов. Учетная запись может представлять как физическое, так и юридическое лицо

Участвующие актеры: Незарегистрированный пользователь

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

Альтернативный поток событий: Вывести сообщение об ошибке, отметить ошибочно заполненные поля формы

Предусловие: Пользователь успешно открыл сайт системы

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

Точки расширения: _

2.

Название: Создать учетную запись для работника предприятия

Краткое описание: Администратор создает учетную запись для работника предприятия, который через систему должен иметь доступ к заказам

Участвующие актеры: Администратор системы

Основной поток событий: Создать новую учетную запись работника предприятия с заданными правами доступа

Альтернативный поток событий: Вывести сообщение об ошибке, отметить ошибочно заполненные поля формы

Предусловие: Сайт системы открыт с учетной записи администратора

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

Точки расширения: _

3.

Название: Редактировать учетную запись

Краткое описание: Администратор редактирует данные любой учетной записи в системе, или пользователь редактирует данные своей учетной записи

Участвующие актеры: Администратор системы, Заказчик

Основной поток событий: Изменить данные об учетной записи

Альтернативный поток событий: Вывести сообщение об ошибке, отметить ошибочно заполненные поля формы

Предусловие: Пользователь или администратор вошел в систему приема заказов под своей учетной записью

Постусловие: Данные об учетной записи изменены

Точки расширения: _

4.

Название: Управлять заказом

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

Участвующие актеры: Заказчик

Основной поток событий: Произвести заданное действие над объектом класса «Заказ» - создать новый заказ для учетной записи, редактировать заказ, отменить заказ, или пометить заказ как отправленный на рассмотрение, после чего он будет оценен работниками предприятия

Альтернативный поток событий: Вывести сообщение об ошибке, отметить ошибочно заполненные поля формы

Предусловие: Заказчик вошел в систему приема заказов под своей учетной записью

Постусловие: Данные объекта класса «заказ» изменены

Точки расширения: Создать новый заказ, Редактировать заказ, Разместить заказ, Отменить заказ

5.

Название: Подтвердить условия выполнения

Краткое описание: Заказчик подтверждает или отклоняет выдвинутые предприятием условия выполнения заказа

Участвующие актеры: Заказчик

Основной поток событий: Заказ помечается как подтвержденный и направляется на производство, или помечается как отмененный

Альтернативный поток событий: Заказ остается помечен, как ожидающий подтверждения

Предусловие: Заказчик вошел в систему приема заказов под своей учетной записью, с предприятия поступили условия выполнения заказа

Постусловие: Заказ помечен как подтвержденный

Точки расширения: Согласиться, Отказаться

6.

Название: Оценить технологичность заказа

Краткое описание: Главный конструктор по предоставленным в заказе чертежам определяет выполнимость данного изделия с технологической точки зрения

Участвующие актеры: Главный конструктор

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

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

Предусловие: Имеется нерассмотренный заказ

Постусловие: Получена оценка технологичности заказа

Точки расширения: _

7.

Название: Составить форму процесса производства

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

Участвующие актеры: Главный конструктор

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

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

Предусловие: Имеется нерассмотренный заказ

Постусловие: Составлена форма процесса производства

Точки расширения: _

8.

Название: Оценить экономичность

Краткое описание: На основе составленной главным конструктором формы процесса производства и данных о финансовом положении предприятия начальник отдела экономики оценивает экономичность заказа

Участвующие актеры: Начальник отдела экономики

Основной поток событий: Рассчитывается экономичность заказа на основе требований и составленной формы процесса производства

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

Предусловие: Имеется нерассмотренный заказ, для которого составлена форма процесса производства

Постусловие: Получена оценка экономичности заказа

Точки расширения: Рассчитать стоимость материалов, Рассчитать дополнительные затраты

9.

Название: Дать оценку заказа

Краткое описание: Составляется финальная оценка выполнимости заказа, стоимости и сроков его выполнения на основе оценок технологичности и экономичности

Участвующие актеры: Инженер

Основной поток событий: Объединить оценку технологичности и экономичности в общую оценку заказа

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

Предусловие: Имеется оценка экономичности и технологичности заказа

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

Точки расширения: _

10.

Название: Отправить клиенту согласие/отказ, сроки и стоимость выполнения в случае согласия

Краткое описание: Составленные ранее условия выполнения заказа направляются заказчику для подтверждения

Участвующие актеры: Начальник отдела приема заказов

Основной поток событий: Сроки и стоимость выполнения или отказ в выполнении заказа отправляются заказчику

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

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

Постусловие: Заказчик получил условия выполнения заказа

Точки расширения: _

11.

Название: Дать разрешение на производство

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

Участвующие актеры: Начальник отдела приема заказов

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

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

Предусловие: Получено согласие заказчика с условиями выполнения заказа

Постусловие: Заказ направлен на производство

Точки расширения: _

4.2 Диаграмма классов с концептуальной точки зрения

Выделены следующие классы: Заказчик (физическое или юридическое лицо), Заказ, Условия выполнения, Изделие, Сборное изделие, Строка формы процесса производства, Оснастка:

Класс «Заказчик» содержит в себе учетные записи заказчиков, зарегистрированных в системе. С каждым заказчиком может быть ассоциировано множество размещенных им заказов.

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

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

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

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

4.3 Диаграмма состояний объектов класса

Диаграмма состояний, представленная на рисунке, отображает возможные состояния класса «Заказ».

4.4 Диаграмма видов деятельности

Отображает состояние системы с точки зрения различных работников .

Диаграмма видов деятельности заказчика:

Диаграмма видов главного конструктора:

Диаграмма видов начальника отдела экономики:

Диаграмма видов начальника отдела приема заказов:

4.5 Диаграмма последовательности

Диаграммы последовательности системы состоят из актеров, интерфейса системы, выполненного на языке PHP, системы управления базами данных MySQL Server и сервера, на котором установлена система.

Диаграмма последовательности для прецедента «Создать заказ»:

Диаграмма последовательности для прецедента «Оценить экономичность»:

Диаграмма последовательности для прецедента «Отправить клиенту согласие/отказ, сроки и стоимость выполнения в случае согласия»:

5. Сетевой план выполнения проектных работ

5.1 Определение состава работ по стадиям и этапам

В соответствии с ГОСТ 34.601-90 проектирование автоматизированных систем предполагает выполнение ряда стадий:

Формирование требований к АС;

Разработка концепции АС;

Техническое задание;

Эскизный проект;

Технический проект;

Рабочая документация;

Ввод в действие;

Сопровождение АС.

Каждая стадия подразделяется на этапы, приведенные в таблице:

Стадии

Этапы работ

1.Формирование требований к АС

1.1. Обследование объекта и обоснование необходимости создания АС.

1.2. Формирование требований пользователя к АС.

1.3. Оформление отчёта о выполненной работе и заявки на разработку АС (тактико-технического задания)

2.Разработка концепции АС

2.1. Изучение объекта.

2.2. Проведение необходимых научно-исследовательских работ.

2.3. Разработка вариантов концепции АС, удовлетворяющего требованиям пользователя.

2.4. Оформление отчёта о выполненной работе.

3.Техническое задание

Разработка и утверждение технического задания на создание АС.

4.Эскизный проект

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

4.2. Разработка документации на АС и её части.

5.Технический проект

5.1. Разработка проектных решений по системе и её частям.

5.2. Разработка документации на АС и её части.

5.3. Разработка и оформление документации на поставку изделий для комплектования АС и (или) технических требований (технических заданий) на их разработку.

5.4. Разработка заданий на проектирование в смежных частях проекта объекта автоматизации.

6.Рабочая документация

6.1. Разработка рабочей документации на систему и её части.

6.2. Разработка или адаптация программ.

7. Ввод в действие

7.1. Подготовка объекта автоматизации к вводу АС в действие.

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

7.3. Комплектация АС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями).

7.4. Строительно-монтажные работы.

7.5. Пусконаладочные работы.

7.6. Проведение предварительных испытаний.

7.7. Проведение опытной эксплуатации.

7.8. Проведение приёмочных испытаний.

8.Сопровождение АС

8.1. Выполнение работ в соответствии с гарантийными обязательствами.

8.2. Послегарантийное обслуживание.

5.2 Содержание работ на каждом этапе

На этапе 1.1 “Обследование объекта и обоснование необходимости создания АС” будут проведены:

сбор данных об объекте автоматизации и осуществляемых видах деятельности (обследование объекта и анализ предметной области);

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

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

2. На этапе 1.2 “Формирование требований пользователя к АС” будет проведено:

подготовка исходных данных для формирования требований к АС (характеристика объекта автоматизации, описание требований к системе, ограничения допустимых затрат на разработку, ввод в действие и эксплуатацию, эффект, ожидаемый от системы, условия создания и функционирования системы);

формулировка и оформление требований пользователя к АС.

3. На этапе 1.3 "Оформление отчета о выношенной работе и заявки на разработку АС (тактико-технического задания)” будет проведено оформление отчета о выполненных работах на данной стадии и оформление заявки на разработку АС.

4. На этапе 2.1 “Изучение объекта” будет проведено детальное изучение объекта автоматизации.

Проведение научно-исследовательских работ (НИР), связанных с поиском путей и оценкой возможности реализации требований пользователя, согласно этапу 2.2 “Проведение необходимых научно-исследовательских работ” при разработке системы приема заказов завода «Автоприбор» не предполагаются вследствие невысокого уровня сложности системы.

5. На этапе 2.3 “Разработка вариантов концепции АС и выбор варианта концепции АС, удовлетворяющего требованиям пользователя” будет проведена:

разработка альтернативных вариантов концепции создаваемой ИС;

оценка необходимых ресурсов на реализацию концепций и обеспечение функционирования;

оценка преимуществ и недостатков каждого варианта концепции;

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

определение порядка оценки качества и условий приемки системы;

оценку эффектов, получаемых от системы.

6. На этапе 2.4 “Оформление отчета о выполненной работе” будет подготовлен и оформлен отчет, содержащий описание выполненных работ на стадии, описание и обоснование предлагаемого варианта концепции системы.

7. На этапе 3.1 “Разработка и утверждение технического задания на создание АС” будет проведена разработка, оформление, согласование и утверждение технического задания на систему приема заказов завода «Автоприбор».

8. На этапе 4.1 “Разработка предварительных проектных решений по системе и ее частям” для системы приема заказов завода «Автоприбор» будут описаны функции и задачи системы, определена цель разработки системы, разработана информационная и физическая модель данных, состав комплекса технических средств.

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

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

10. На этапах 4.2 и 5.2 “Разработка документации на АС и ее части” будет проведена разработка, оформление, согласование и утверждение документации в объеме, необходимом для описания полной совокупности принятых проектных решений и достаточном для дальнейшего выполнения работ по созданию АС. Виды документов - по ГОСТ 34.201.

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

11. На этапе 5.3 “Разработка и оформление документации на поставку изделий для комплектования АС и (или) технических требований (технических заданий) на их разработку” будет проводиться подготовка и оформление документации на поставку системы приема заказов завода «Автоприбор».

На данном этапе требуется составить документацию на покупку сервера.

12. На этапе 5.4 “Разработка заданий на проектирование в смежных частях проекта объекта автоматизации” будет осуществлена разработка, оформление, согласование и утверждение заданий на проектирование в смежных частях проекта объекта автоматизации для проведения строительных, электротехнических, санитарно-технических и других подготовительных работ, связанных с созданием АС.

13. На этапе 6.1 “Разработка рабочей документации на систему и ее части” будет осуществлена разработка рабочей документации, содержащей все необходимые и достаточные сведения для обеспечения выполнения работ по вводу АС в действие и ее эксплуатации, а также для поддерживания уровня эксплуатационных характеристик (качества) системы в соответствии с принятыми проектными решениями, ее оформление, согласование и утверждение, Виды документов - по ГОСТ 34.201.

На данном этапе при разработке ИС будут уточнены диаграмма классов, диаграммы деятельности, диаграмма компонентов, диаграмма пакетов; реализована диаграмма размещения компонентов.

14. На этапе 6.2 “Разработка или адаптация программ” будет доработана конфигурация базы данных системы, создана онлайн-форма для создания и редактирования заказа, страницы для доступа к информации сотрудников, ответственных за оценку заказов. Будет настроена система обмена информации между частями ИС; будет разработана программная документация.

Страница:


Подобные документы

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.

© 2000 — 2023, ООО «Олбест» Все права защищены