Автор работы: Пользователь скрыл имя, 17 Сентября 2013 в 00:06, курсовая работа
Целью работы является изучение основных принципов и получение базовых навыков подготовки технических заданий на разработку информационных систем, их программного обеспечения.
Введение 3
Техническое задание 4
1 Общие сведения 4
2 Основания для разработки 4
3 Назначение и цели создания системы 4
4 Требования к системе 5
5 Характеристика объектов автоматизации 9
6 Требования к документированию 9
7 Стадии и этапы разработки 9
8 Порядок контроля и приемки системы 15
Технический проект 16
1 Функциональная структура 16
1.1 Описание предметной области 16
1.2 Функции и организационная структура 17
1.3 Описание потоков данных и бизнес процессов 18
1.3.1 Моделирование бизнес-процессов 18
1.3.2 Диаграмма потоков данных 27
2 Системное проектирование ИС 29
2.1 Разработка концепции, архитектуры построения и
платформы реализации ИС 29
2.2 Структура информационной системы, состав
функциональных и обеспечивающих подсистем 31
3 Информационное обеспечение ИС 35
3.1 Описание концептуальной модели информационной базы 35
3.2 Описание логической структуры информационной базы 37
3.3 Описание физической реализации БД 40
Заключение 43
Список литературы 44
8 Порядок контроля и приемки системы
8.1 Виды, состав, объем и методы испытаний системы и ее составных частей
Испытание системы производится путем введения большого количества данных, введения одинаковых сведений, сведений другого типа данных, данных большего диапазона. Производится проверка соответствия экранных форм описанию в руководстве для пользователя (тестирование интерфейса).
8.2 Общие требования к приемке работ по стадиям
Сдача-приемка осуществляется комиссией,
в состав которой входят представители
Заказчика и Исполнителя. По результатам
приемки подписывается акт
Все создаваемые в рамках настоящей работы программные изделия передаются Заказчику, как в виде готовых модулей, так и в виде исходных кодов, представляемых в электронной форме на стандартном машинном носителе (на компакт-диске).
8.3 Статус приемочной комиссии (государственная, межведомственная, ведомственная)
Статус приемочной комиссии определяется Заказчиком до проведения испытаний.
Технический проект
1 Функциональная структура
1.1 Описание предметной области
Предметной областью является фирма, торгующая мебелью.
Предприятие
имеет в своем составе
Мастер-технолог занимается работой с эскизами и проектами и осуществляет руководство тремя рабочими, выполняющими непосредственное изготовление мебели. Также мастер-технолог на основании разработанного проекта подготавливает бухгалтеру список материалов, которые необходимо закупить.
Административный отдел, состоящий из бухгалтера и менеджера, занимается принятием и регистрацией заказа, а так же последующим расчетом с клиентом. Кроме того, в обязанности бухгалтера входит закупка материалов у сторонних фирм в количестве, указанном мастером-технологом.
Когда
заказ готов, курьер получает
у бухгалтера счет, совместно
с одним из рабочих прибывает
к заказчику в предварительно
обговоренное время, затем
После доставки заказа курьер сдает документы и деньги бухгалтеру, который контролирует правильность расчетов и оформления документа. Затем менеджер закрывает заявку в списке текущих заказов.
1.2 Функции и организационная структура
Построение структуры предприятия можно разбить на три шага: построение организационной модели, построение функциональной модели и построение информационной модели.
Фирма «Мебель» состоит из следующих отделов:
Организационная структура предприятия отражена на рисунке 4.
Рисунок 4 - Организационная модель
Директор осуществляет общее
руководство производственно-
Отдел производства осуществляет разработку проекта изделие, его последующее изготовление и сборку.
Административный отдел, состоящий из бухгалтера и менеджера, занимается принятием и регистрацией заказа, а так же последующим расчетом с клиентом.
Отдел доставки осуществляет транспортировку частей изделия, подготовленных к сборке, по адресу, указанному заказчиком.
1.3 Описание потоков данных и бизнес процессов
1.3.1 Моделирование бизнес-процессов
Бизнес-процесс — это совокупность взаимосвязанных мероприятий или задач, направленных на создание определенного продукта или услуги для потребителей. Для наглядности бизнес-процессы визуализируют при помощи блок-схемы бизнес-процессов. Моделирование бизнес-процессов - деятельность по формированию моделей организаций, включающая описание деловых объектов (подразделений, должностей, ресурсов, ролей, процессов, операций, информационных систем, носителей информации и т. д.) и указание связей между ними. Требования к формируемым моделям и их соответствующее содержание определяются целями моделирования. Бизнес-моделированием также называют дисциплину и отдельный подпроцесс в процессе разработки программного обеспечения, в котором описывается деятельность компании и определяются требования к системе — те подпроцессы и операции, которые подлежат автоматизации в разрабатываемой информационной системе.
Проанализировав деятельность мебельного цеха, и проведя пред-проектное исследование, можно выделить три основных бизнес-процесса АИС «Мебель»:
Функциональное
моделирование бизнес-
Контекстная диаграмма является вершиной древовидной структуры диаграмм и представляет собой самое общее описание системы и ее взаимодействия с внешней средой (как правило, здесь описывается основное назначение моделируемого объекта). После описания системы в целом проводится разбиение ее на крупные фрагменты. Этот процесс называется функциональной декомпозицией, а диаграммы, которые описывают каждый фрагмент и взаимодействие фрагментов, называются диаграммами декомпозиции. После декомпозиции контекстной диаграммы (т.е., получения диаграммы А0) проводится декомпозиция каждого блока диаграммы А0 на более мелкие фрагменты и так далее, до достижения нужного уровня подробности описания. После каждого сеанса декомпозиции проводятся сеансы экспертизы - эксперты предметной области (обычно это интервьюируемые аналитиками сотрудники предприятий) указывают на соответствие реальных бизнес-процессов созданным диаграммам. Найденные несоответствия исправляются, и только после прохождения экспертизы без замечаний можно приступать к следующему сеансу декомпозиции. Так достигается соответствие модели реальным бизнес-процессам на любом и каждом уровне модели. Синтаксис описания системы в целом и каждого ее фрагмента одинаков во всей модели.
Главная бизнес-функция «АИС Мебель» - изготовление мебели. Входными данными является заявка на выполнение работ. Выходными – акт о выполненных работах. В качестве управления выступают порядок обслуживания клиента, ГОСТы и ТУ по изготовлению мебели, проекты готовых решений, характеристики материалов, методики изготовления. Инструментами выполнения главной бизнес-функции служат сотрудники ОАО «Заказчик» (бухгалтер, менеджер, курьер, рабочие, мастер-технолог), а также оборудование, необходимое для изготовления мебели. Диаграмма IDEF0 для главной бизнес-функции представлена на рисунке 5.
В соответствии
с указанными ранее тремя основными
бизнес-процессами при декомпозиции
главной бизнес-функции
Функциональный блок «Принятие заказа» включает регистрацию заказа, разработку эскиза, а затем и проекта изделия, а также его согласование с заказчиком. В случае внесения заказчиком каких-либо изменений, эскиз и проект разрабатываются заново. В управлении блоком «Принятие заказа» участвуют характеристики материалов, порядок обслуживания клиентов, проекты готовых решений, ГОСТы по изготовлению мебели. На вход поступает заявка на выполнение работ, на выходе получен согласованный проект и договор. В качестве исполнителей выступают менеджер и мастер-технолог. Диаграмма декомпозиции блока «Принятие заказа» представлена на рисунке 7.
Функциональный
блок «Изготовление частей изделия»
получает в качестве входных данных
согласованный проект, в управлении
участвуют характеристики материалов,
методики изготовления, ГОСТы по изготовлению
мебели, а также согласованный
проект. В качестве исполнителей выступают
мастер-технолог, рабочие, станки и
оборудование. В качестве выходных
данных выступают части изделия,
готовые к сборке
Рисунок 5 – Контекстная диаграмма
Рисунок 6 - Диаграмма декомпозиции контекстной диаграммы
Рисунок 7 - Диаграмма декомпозиции блока «Принятие заказа»
Блок «Изготовление
частей изделия» имеет в своем
составе следующие блоки: заказ
и получение материалов, раскрой
плиты на детали, сверление соединительных
отверстий облицовывание
Функциональный
блок «Расчет с заказчиком» включает
доставку, сборку, оплату и закрытие
заявки. На вход поступают части
изделия, готовые к сборке, в качестве
выходных данных выступает акт о
выполненных работах. Управляют
данным блоком согласованный проект,
договор, порядок обслуживания клиентов.
Исполнителями являются рабочие, курьер,
бухгалтер-кассир и менеджер. Диаграмма
декомпозиции функционального блока
«Расчет с заказчиком»
Рисунок 8 - Диаграмма декомпозиции блока «Изготовление частей изделия»
Рисунок 9 - Диаграмма декомпозиции блока «Раскрой плиты на детали»
Рисунок 10 – Диаграмма декомпозиции блока «Расчет с заказчиком»
1.3.2 Диаграмма потоков данных
Требования представляются в виде иерархии процессов, связанных потоками данных. Диаграммы потоков данных показывают, как каждый процесс преобразует свои входные данные в выходные, и выявляют отношения между этими процессами. DFD-диаграммы успешно используются как дополнение к модели IDEF0 для описания документооборота и обработки информации. Подобно IDEF0, DFD представляет моделируемую систему как сеть связанных работ. Основные компоненты DFD (как было сказано выше) – процессы или работы, внешние сущности, потоки данных, накопители данных (хранилища). В отличие от стрелок IDEF0, которые представляют собой жесткие взаимосвязи, стрелки DFD показывают, как объекты (включая данные) двигаются от одной работы к другой.
В отличие от IDEF0, где система рассматривается как взаимосвязанные работы, DFD рассматривает систему как совокупность предметов. Контекстная диаграмма часто включает работы и внешние ссылки. Работы обычно именуются по названию системы, например "Система обработки информации". Включение внешних ссылок в контекстную диаграмму не отменяет требования методологии четко определить цель, область и единую точку зрения на моделируемую систему.
В DFD работы ( процессы ) представляют собой функции системы, преобразующие входы в выходы. Хотя работы изображаются прямоугольниками со скругленными углами, смысл их совпадает со смыслом работ IDEF0 и IDEF3. Так же, как процессы IDEF3, они имеют входы и выходы, но не поддерживают управления и механизмы, как IDEF0.
Внешние сущности изображают входы в систему и/или выходы из системы. Внешние сущности изображаются в виде прямоугольника с тенью и обычно располагаются по краям диаграммы. Одна внешняя сущность может быть использована многократно на одной или нескольких диаграммах. Обычно такой прием используют, чтобы не рисовать слишком длинных и запутанных стрелок.
Потоки работ изображаются стрелками и описывают движение объектов из одной части системы в другую. Поскольку в DFD каждая сторона работы не имеет четкого назначения, как в IDEF0, стрелки могут подходить и выходить из любой грани прямоугольника работы. В DFD также применяются двунаправленные стрелки для описания диалогов типа "команда-ответ" между работами, между работой и внешней сущностью и между внешними сущностями.
В отличие от стрелок, описывающих объекты в движении, хранилища данных изображают объекты в покое.
Диаграмма потоков данных
для бизнес-процессов ОАО «
Рисунок 11 - Диаграмма
потоков данных
2 Системное проектирование ИС
2.1 Разработка концепции,
Основными аспектами при выборе архитектуры построения ИС являются быстродействие, надежность, масштабируемость и безопасность.
В настоящее время наиболее
распространенными
Файл-серверная архитектура подразумевает под собой то, что сервер возлагает на себя лишь функцию хранения данных, а обработка производится на клиентских машинах. Это означает, что данные необходимо передавать по сети, что приведет к сильной загрузке сетевого трафика. А это в свою очередь приведет к снижению производительности при увеличении числа пользователей. Также при реализации архитектуры файл-сервер, проблема целостности, согласованности и одновременного доступа к данным решается децентрализовано: данные хранятся на сервере, а обрабатываются на клиенте. Вследствие этого снижается надежность приложения. Еще одним недостатком являются высокие затраты на модернизацию и сопровождение сервисов бизнес - логики на каждой клиентской рабочей станции. Однако данная архитектура обладает и рядом преимуществ, таких как низкая стоимость разработки, высокая скорость разработки и невысокая стоимость обновления и изменения программного обеспечения.