Проектирование информационной системы автотранспортного предприятия ООО «Автодорстрой»

 

Содержание

Введение

1. Исследование предметной области
1. Структура управления предприятия
2. Краткая характеристика строительной компании «ООО Автодорстрой»
2. Построение модели деятельности «как есть» (AS IS)
1. Построение структурной функциональной модели деятельнсоти строительной компании «ООО Автодорстрой» со стандартом IDEF08
2. Функциональная модель в виде потоков данных (DFD)
3. Построение модели деятельности как должно быть (TO-BE)
1. Построение структурной функциональной модели строительной компании «ООО Автодорстрой»
2. Функциональная модель в виде потоков данных (DFD)
4. Формирование технического задания на создание автоматизированной системы
1. Общие сведения
2. Характеристики объекта автоматизации
3. Назначение и цели создания АИС
4. Основные требования к системе
5. Состав, содержание и организация работ по созданию АИС

Заключение

Список используемой литературы

 

 

Введение

 

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

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

Производительность является главным фактором, определяющим эффективность системы. Хорошее проектное решение служит основой высокопроизводительной системы.

Проектирование информационных систем охватывает три основные области:

• проектирование объектов данных, которые будут реализованы в базе данных;
• проектирование программ, экранных форм, отчетов, которые будут обеспечивать выполнение запросов к данным;
• учет конкретной среды или технологии, а именно: топологии сети, конфигурации аппаратных средств, используемой архитектуры (файл-сервер или клиент-сервер), параллельной обработки, распределенной обработки данных и т.п.

 

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

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

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

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

1. Исследование предметной области
2. Структурный анализ предметной области
3. Построение структурно-функциональной модели IDEF08
4. Построение структурно-функциональной модели потоков данных (DFD)
5. Составление технического задания на основе анализа полученных моделей
 

1. Исследование предметной области

 

1. Структура управления предприятия

 

Структура управления в ООО «АвтодорСтрой» имеет схему, представленную на рис. 1:

1. Руководство – непосредственное руководство предприятием, сметным отделом и бухгалтерией;
2. Бухгалтерия – составление сметы проектов, распределение производственных ресурсов, Расчет заработной платы;
3. Маркетинг – анализ спроса, деятельности других предприятий, разработка рекламы;
4. Управление персоналом – прием на работу, поиск новых сотрудников, составление управляющих документов;
5. Проектирование – создание плана проекта в соответствии с тех. заданием клиента;
6. Реализация проекта – непосредственно строительство объектов;
7. Контроль качества – прием готовых проектов, анализ соотвестствия тех. заданию и плану, анализ обращений заказчиков.

 

 

 

 

 

Рис. 1. Структура управления ООО «АвтодорСтрой»

 

2. Краткая характеристика строительной компании «ООО Автодорстрой»

 

Компания оказывает следующие услуги:

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

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

 

2. Построение модели деятельности «как есть» (AS IS)

 

Функциональная модель деятельности компании включает в себя структурную функциональную модель в соответствии со стандартом  IDEF08 (иерархия SATD-диаграмм) и функциональную модель в виде иерархии потоков данных (DFD).

 

1. Построение структурной функциональной модели деятельности строительной компании «ООО Автодорстрой» со стандартом IDEF08

 

Методологию IDEF08 можно считать следующим этапом развития хорошо известного графического языка описания функциональных систем SATD (Structured Analysis and Design Technique).

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

Первым из них является понятие функционального блока (Activity Box). Функциональный блок графически изображается в виде прямоугольника и олицетворяет собой некоторую конкретную функцию в рамках рассматриваемой системы.

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

• верхняя сторона имеет значение “Управление” (Control);
• левая сторона имеет значение “Вход” (Input);
• правая сторона имеет значение “Выход” (Output);
• нижняя сторона имеет значение “Механизм” (Mechanism).

Каждый функциональный блок в рамках единой рассматриваемой  системы должен иметь свой уникальный идентификационный номер.

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

Графическим отображением интерфейсной дуги является однонаправленная стрелка. Каждая интерфейсная дуга должна иметь  свое уникальное наименование (Arrow Label).

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

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

Обязательное наличие управляющих  интерфейсных дуг является одним  из главных отличий стандарта IDEF0 от других методологий классов DFD (Data Flow Diagram) и WFD (Work Flow Diagram).

Третьим основным понятием стандарта IDEF0 является декомпозиция (Decomposition). Принцип декомпозиции применяется при разбиении сложного процесса на составляющие его функции. При этом уровень детализации процесса определяется непосредственно разработчиком модели.

Модель IDEF0 всегда начинается с представления системы как единого целого – одного функционального блока с интерфейсными дугами, простирающимися за пределы рассматриваемой области. Такая диаграмма с одним функциональным блоком называется контекстной диаграммой, и обозначается идентификатором «А-0».

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

Последним из понятий IDEF0 является глоссарий (Glossary). Для каждого  из элементов IDEF0: диаграмм, функциональных блоков, интерфейсных дуг существующий стандарт подразумевает создание и поддержание набора соответствующих определений, ключевых слов, повествовательных изложений и т.д., которые характеризуют объект, отображенный данным элементом. Этот набор называется глоссарием и является описанием сущности данного элемента. Например, для управляющей интерфейсной дуги “распоряжение об оплате” глоссарий может содержать перечень полей соответствующего дуге документа, необходимый набор виз и т.д. Глоссарий гармонично дополняет наглядный графический язык, снабжая диаграммы необходимой дополнительной информацией.

 

 

Рис. 2. Общий вид диаграммы IDEF0

 

Рис. 3. деятельность ООО  «Автодорстрой»

 

Рис. 4. Детализация отдела «Маркетинг»

 

Рис. 5. Детализация отдела «Проектирование»

 

Рис. 6. Детализация отдела «Бухгалтерия»

 

Рис. 7. Детализация отдела «Контроль качества»

 

 

3. Функциональная модель в виде потоков данных (DFD)

 

Диаграмма потоков данных (data flow diagram, DFD) — один из основных инструментов структурного анализа и проектирования информационных систем. Несмотря на имеющее место в современных условиях смещение акцентов от структурного к объектно-ориентированному подходу к анализу и проектированию систем, «старинные» структурные нотации по-прежнему широко и эффективно используются как в бизнес-анализе, так и в анализе информационных систем.

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

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