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

Автор работы: Пользователь скрыл имя, 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

Прикрепленные файлы: 1 файл

Курс.docx

— 1.38 Мб (Скачать документ)

 

 

8 Порядок контроля и приемки системы

 

8.1 Виды, состав, объем и методы испытаний системы и ее составных частей

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

8.2 Общие требования к приемке работ по стадиям

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

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

8.3 Статус приемочной комиссии (государственная, межведомственная, ведомственная)

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

 

 

 

 

 

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

 

1 Функциональная структура

1.1 Описание предметной области

 

Предметной  областью является фирма, торгующая  мебелью.

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

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

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

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

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

 

1.2 Функции и организационная структура

 

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

Фирма «Мебель» состоит из следующих отделов:

  • директор;
  • административный отдел;
  • отдел производства;
  • отдел доставки.

Организационная структура предприятия  отражена на рисунке 4.

 

Рисунок 4 - Организационная модель

 

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

Отдел производства осуществляет разработку проекта изделие, его  последующее изготовление и сборку.

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

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

 

1.3 Описание потоков данных и бизнес процессов

1.3.1 Моделирование бизнес-процессов 

 

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

Проанализировав деятельность мебельного цеха, и проведя пред-проектное  исследование, можно выделить три  основных бизнес-процесса АИС «Мебель»:

  1. Принятие заказа.
  2. Изготовление частей изделия.
  3. Расчет с заказчиком.

Функциональное  моделирование бизнес-процессов  представлено методологией IDEF0. Она описывает те деловые процессы, которые протекают в объекте автоматизации. Основу методологии IDEF0 составляет графический язык описания бизнес-процессов. Модель в IDEF0 представлена совокупностью иерархически упорядоченных и логически связанных диаграмм. Каждая диаграмма располагается на отдельном листе. Можно выделить четыре типа диаграмм:

  • контекстную диаграмму А-0 (в каждой модели может быть только одна контекстная диаграмма);
  • диаграммы декомпозиции (в том числе диаграмма первого уровня декомпозиции А0, раскрывающая контекстную);
  • диаграммы дерева узлов;
  • диаграммы только для экспозиции (FEO).

Контекстная диаграмма является вершиной древовидной  структуры диаграмм и представляет собой самое общее описание системы  и ее взаимодействия с внешней  средой (как правило, здесь описывается  основное назначение моделируемого  объекта). После описания системы  в целом проводится разбиение  ее на крупные фрагменты. Этот процесс  называется функциональной декомпозицией, а диаграммы, которые описывают  каждый фрагмент и взаимодействие фрагментов, называются диаграммами декомпозиции. После декомпозиции контекстной диаграммы (т.е., получения диаграммы А0) проводится декомпозиция каждого блока диаграммы А0 на более мелкие фрагменты и так далее, до достижения нужного уровня подробности описания. После каждого сеанса декомпозиции проводятся сеансы экспертизы - эксперты предметной области (обычно это интервьюируемые аналитиками сотрудники предприятий) указывают на соответствие реальных бизнес-процессов созданным диаграммам. Найденные несоответствия исправляются, и только после прохождения экспертизы без замечаний можно приступать к следующему сеансу декомпозиции. Так достигается соответствие модели реальным бизнес-процессам на любом и каждом уровне модели. Синтаксис описания системы в целом и каждого ее фрагмента одинаков во всей модели.

Главная бизнес-функция  «АИС Мебель» - изготовление мебели. Входными данными является заявка на выполнение работ. Выходными – акт о выполненных работах. В качестве управления выступают порядок обслуживания клиента, ГОСТы и ТУ по изготовлению мебели, проекты готовых решений, характеристики материалов, методики изготовления. Инструментами выполнения главной бизнес-функции служат сотрудники ОАО «Заказчик» (бухгалтер, менеджер, курьер, рабочие, мастер-технолог), а также оборудование, необходимое для изготовления мебели. Диаграмма IDEF0 для главной бизнес-функции представлена на рисунке 5.

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

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

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

Рисунок 5 – Контекстная диаграмма

 

Рисунок 6 - Диаграмма декомпозиции контекстной диаграммы

Рисунок 7 - Диаграмма декомпозиции блока «Принятие заказа»

 

Блок «Изготовление  частей изделия» имеет в своем  составе следующие блоки: заказ  и получение материалов, раскрой  плиты на детали, сверление соединительных отверстий облицовывание кромочным  материалом. Диаграмма декомпозиции блока «Изготовление частей изделия» представлена на рисунке 8. Для автоматизации процесса раскроя потребовалось уточнить, какие процессы входят в блок «Раскрой плиты на детали». Поэтому была составлена и его диаграмма декомпозиции, которая представлена на рисунке 9.

Функциональный  блок «Расчет с заказчиком» включает доставку, сборку, оплату и закрытие заявки. На вход поступают части  изделия, готовые к сборке, в качестве выходных данных выступает акт о  выполненных работах. Управляют  данным блоком согласованный проект, договор, порядок обслуживания клиентов. Исполнителями являются рабочие, курьер, бухгалтер-кассир и менеджер. Диаграмма  декомпозиции функционального блока  «Расчет с заказчиком» представлена на рисунке 10.

 

 

Рисунок 8 - Диаграмма декомпозиции блока «Изготовление частей изделия»

Рисунок 9 - Диаграмма декомпозиции блока «Раскрой плиты на детали»

Рисунок 10 – Диаграмма декомпозиции блока «Расчет с заказчиком»

 

1.3.2 Диаграмма потоков данных

 

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

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

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

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

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

В отличие от стрелок, описывающих  объекты в движении, хранилища данных изображают объекты в покое.

Диаграмма потоков данных для бизнес-процессов ОАО «Заказчик» представлена на рисунке 11.

 

Рисунок 11 - Диаграмма потоков данных 

2 Системное проектирование ИС

2.1 Разработка концепции, архитектуры  построения и платформы реализации  ИС

 

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

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

    • файл-сервер;
    • клиент-сервер;
    • многоуровневая архитектура.

Файл-серверная архитектура подразумевает под собой то, что сервер возлагает на себя лишь функцию хранения данных, а обработка производится  на клиентских машинах. Это означает, что данные необходимо передавать по сети, что приведет к сильной загрузке сетевого трафика. А это в свою очередь приведет к снижению производительности при увеличении числа пользователей. Также при реализации архитектуры файл-сервер, проблема целостности, согласованности и одновременного доступа к данным решается децентрализовано: данные хранятся на сервере, а обрабатываются на клиенте. Вследствие этого снижается надежность приложения. Еще одним недостатком являются высокие затраты на модернизацию и сопровождение сервисов бизнес - логики на каждой клиентской рабочей станции. Однако данная архитектура обладает и рядом преимуществ, таких как низкая стоимость разработки, высокая скорость разработки и  невысокая стоимость обновления и изменения программного обеспечения.

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