Главная Обратная связь Поможем написать вашу работу!

Дисциплины:

Архитектура (936)
Биология (6393)
География (744)
История (25)
Компьютеры (1497)
Кулинария (2184)
Культура (3938)
Литература (5778)
Математика (5918)
Медицина (9278)
Механика (2776)
Образование (13883)
Политика (26404)
Правоведение (321)
Психология (56518)
Религия (1833)
Социология (23400)
Спорт (2350)
Строительство (17942)
Технология (5741)
Транспорт (14634)
Физика (1043)
Философия (440)
Финансы (17336)
Химия (4931)
Экология (6055)
Экономика (9200)
Электроника (7621)






Разработка математической модели



Структура пояснительной записки

 

Введение

1. Общесистемная часть

1.1 Общая характеристика объекта управления

1.2 Характеристика и анализ существующей системы управления

1.3 Формулировка задач усовершенствования системы управления

1.4 Обзор и анализ известных проектных решений

1.5 Выводы

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

2.1 Построение контуров управления

2.2 Разработка математической модели

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

2.4 Разработка информационной модели

2.5 Реализация информационной базы данных

2.6 Описание комплекса технических средств

2.7 Разработка программного обеспечения

2.7.1 Выбор системного программного обеспечения

2.7.2 Разработка прикладного программного обеспечения

2.7.2.1 Описание алгоритмов решения задач

2.7.2.2 Выбор программных технологий реализации

2.7.2.3 Описание прототипа системы

3. Организационно-экономическая часть

3.1 Расчет эффективности по сравнению с нормативами

3.2 Расчет эффективности по сравнению с существующими на предприятии решениями

4. Раздел по обеспечению безопасности жизнедеятельности

Заключение

Список литературы

Приложения


Обзор и анализ известных проектных решений

 

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

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

Важно отметить, что обзор проектных решений должен быть сделан в строгом соответствии с направленностью выпускной квалификационной работы. Поэтому все проектные решения по АСУ можно условно разделить на два класса – системы электронного документооборота (Евфрат, Directum, БОСС-Референт) и производственные системы (Baan, SAP R/3, Галактика). Все остальные решения можно рассматривать как их подклассы.



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

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

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



 

 


Выводы

 

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

 


Разработка математической модели

 

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

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

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



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

Если никакой задачи оптимизации не решается, то математическую модель лучше построить в классе имитационных моделей. В имитационной модели изменения процессов и данных ассоциируются с событиями. Процесс имитационного моделирования заключается в последовательном переходе от одного события к другому. К имитационным моделям относят: системы массового обслуживания (СМО), абстрактные автоматы, сети Петри.

 


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

 

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

Модель ТО-ВЕ («как будет») нужна для оценки последствий внедрения информационной системы и анализа альтернатив­ных/лучших путей выполнения работы и документирования того, как пред­приятие будет функционировать в будущем. Как правило, модель ТО-ВЕ соответствует разработанной автоматизированной системе.

Вид функциональной модели определятся используемым методом проектирования. Так, например, при использовании SADT(IDEF0)-методологии строится соответствующая функциональная модель с применением программных пакетов DESIGN/IDEF, BPWin, при использовании объектно-ориентированной методологии целесообразно применять соответствующие средства моделирования – Rational Rose, ARIS и т. д. Наиболее распространенной и строго формализованной является методология IDEF0. В качестве примера здесь рассматривается именно эта методология.

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

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

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

– каждая стрелка должна быть именована существительным, обозначающим объекты;

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

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

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

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

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

 

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

 

а

 

б

 

Рисунок 1 – Функциональная модель предлагаемого процесса оформления заказов

 

 

На контекстной диаграмме (рис. 1, а) представлена функция «Оформить заказ». Входной для нее является информация о товарах, входящих в заказ, клиенте, который заказывает товары, и сотруднике, который оформляет заказ; управляющей – устав предприятия; механизмами (исполнителями) выступают сотрудник и, собственно, АСУ заказами, выходной – оформленный заказ.

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

– подстановка номера и даты заказа (выполняется системой автоматически при создании нового заказа);

– выбор клиента из базы данных (выполняется сотрудником, который выполняет поиск клиента по списку, сгенерированному АСУ);

– выбор товаров из базы данных (выполняется сотрудником, который выполняет поиск клиента по списку, сгенерированному АСУ);

– указание данных сотрудника, оформляющего заказ (выполняется системой автоматически при создании нового заказа);

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

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

 


Просмотров 817

Эта страница нарушает авторские права




allrefrs.ru - 2021 год. Все права принадлежат их авторам!