Автоматизация работы финансово-экономического отдела ООО "Кружева"

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

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

Введение

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

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

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

составление окончательных смет по заказам,

составление договоров по заказам,

составление отчетности с целью принятия управленческих решений

В рамках курсового проекта ставится цель -- автоматизировать работу финансово-экономического отдела ООО «Кружева».

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

1. Изучить методы и средства проектирования ИС.

2. Изучить методы и средства создания баз данных.

3. Изучить особенности ИС для данной предметной области.

4. Спроектировать ИС.

5. Описать эксплуатацию проектируемой ИС.

6. Рассчитать себестоимость проектирования и эксплуатации ИС.

7. Описать ключевые особенности охраны труда при эксплуатации проектируемой ИС.



1. Теоретическое обоснование

1.1 Методы и средства проектирования ИС

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

Все методы проектирования делятся на функционально-ориентированные и объектно-ориентированные.

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

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

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

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

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

Для преодоления сложностей начальных этапов разработки предназначен структурный анализ --метод исследования, которое начинается с общего обзора системы и затем детализуется, приобретая иерархическую структуру с большим числом уровней. На каждом уровне рассматривается ограниченное число элементов (обычно от 3 до 6-8), каждый из которых в свою очередь может быть декомпозирован на составляющие детали на следующем уровне. Такая технология получила название CASE (ComputerAidedSoftwareEngeneering-- создание программного обеспечения с помощью компьютера).

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

мощные графические средства для описания и документирования ИС, обеспечивающие удобный интерфейс с разработчиком и развивающие его творческие возможности;

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

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

На сегодняшний день рынок программного обеспечения СНГ располагает следующими наиболее развитыми CASE-средствами:

Vantage Team Builder (Westmount I-CASE);

Designer/2000;

Silverrun;

ERwin+BPwin;

S-Designor;

CASE.Аналитик.



1.2 Методы и средства создания базы данных

База данных(БД)--это организованная структура данных, предназначенная для хранения информации.

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

1. Модель «сущность-связь»предназначена для концептуального моделирования предметной области. Подход анализа предметной области, реализованный в модели «сущность-связь», послужил одним из источников для методов объектно-ориентированного анализа

2. Метод Баркера является одной из вариаций модели «сущность-связь».Сущность (Entity)--реальный либо воображаемый объект, имеющий значение для рассматриваемой предметной области, информация о котором подлежит хранению.

Каждая сущность должна обладать некоторыми свойствами:

иметь уникальное имя;

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

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

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

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

В зависимости от степени выделяют связи «один к одному», «один ко многим» (или «многие к одному») и «многие ко многим». 

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

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

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

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

Создание БД проходит в три этапа:

Физическое проектирование, заключающееся в создании схемы БД для конкретной СУБД.

Концептуальное проектирование, которое представляет собой построение семантической модели предметной области без привязки к конкретной СУБД.

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

Современными средствами проектирования БД являются так называемые CASE-средства.

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

Средствами проектирования БД, обеспечивающими моделирование данных и генерацию схем баз данных для наиболее распространенных СУБД являются Silverrun, VantageTeamBuilder, Designer/2000, ERwin, S-Designor.

1.3 Современные ИС для данной предметной области

При анализе рынка автоматизированных информационных систем (АИС), было установлено, что типовых решений для данной предметной области в общем доступе нет.

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



2. Проектирование ИС

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

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

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

В каждом заказе клиентом выбираются виды услуг, а так же элементы оформления. Постоянным клиентам по усмотрению менеджера предоставляется скидка.

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

Бизнес-процессы организации представлены на рисунках №1-4

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



Рисунок 2. Диаграмма декомпозиции процесса «Обновление БД»,«как есть», с точки зрения менеджера

Рисунок 3.Диаграмма потоков данных для процесса «Оформление заказов на проведение мероприятий»

Рисунок 4. Диаграмма декомпозиции для процесса «Оформление заказов на проведение мероприятий»

2.2 Жизненный цикл ИС

Одним из базовых понятий методологии проектирования ИС является понятие жизненного цикла ее программного обеспечения (ЖЦ ПО). Жизненный цикл ПО - это непрерывный процесс, который начинается с момента принятия решения о необходимости его создания и заканчивается в момент его полного изъятия из эксплуатации.

В соответствии с базовым международным стандартом ISO/IEC 12207 все процессы ЖЦ ПО делятся на три группы:

1. Основные процессы:

приобретение;

поставка;

разработка;

эксплуатация;

сопровождение.

2. Вспомогательные процессы:

документирование;

управление конфигурацией;

обеспечение качества;

разрешение проблем;

аудит;

аттестация;

совместная оценка;

верификация.

3. Организационные процессы:

создание инфраструктуры;

управление;

обучение;

усовершенствование.

Стандарт ISO/IEC 12207 не предлагает конкретную модель ЖЦ и методы разработкиПО. Его регламенты являются общими для любых моделей ЖЦ, методологий и технологий разработки. Стандарт ISO/IEC 12207 описывает структуру процессов ЖЦ ПО, но не конкретизирует в деталях, как реализовать или выполнить действия и задачи, включенные в эти процессы.

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

Рисунок 5. Каскадная модель разработки ПО.

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



Рисунок 6. Реальный процесс разработки ПО по каскадной модели

Затем была предложена спиральная модель ЖЦ, делающая упор на начальные этапы ЖЦ: анализ и проектирование. На этих этапах реализуемость технических решений проверяется путем создания прототипов. Каждый виток спирали соответствует созданию фрагмента или версии ПО, на нем уточняются цели и характеристики проекта, определяется его качество и планируются работы следующего витка спирали. Таким образом углубляются и последовательно конкретизируются детали проекта и в результате выбирается обоснованный вариант, который доводится до реализации. Разработка итерациями отражает объективно существующий спиральный цикл создания системы. Неполное завершение работ на каждом этапе позволяет переходить на следующий этап, не дожидаясь полного завершения работы на текущем. При итеративном способе разработки недостающую работу можно будет выполнить на следующей итерации. Главная же задача - как можно быстрее показать пользователям системы работоспособный продукт, тем самым активизируя процесс уточнения и дополнения требований. Спиральная модель ЖЦ ИС представлена на рисунке 7.

Рисунок 7. Спиральная модель разработки ПО

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

Во время эксплуатации проектируемая ИС оказывается под влиянием управляющих воздействий, которые влияют за собой на нахождение системы в разных состояниях. Диаграмма перехода состояний проектируемой системы представлена на рисунке 8.

Рисунок 8. Диаграмма переходов проектируемой системы

Для функционирования ИС необходима БД. В рамках курсового проекта разработана БД, состоящая из 10-ти таблиц и имеет структуру, представленную в таблицах №1-10.

Таблица 1. Структура таблицы «Клиенты»

Атрибут	Тип данных
Код клиента	Счетчик
ФИО клиента	Текст
№ паспорта	Числовой
Телефон	Текст

Таблица 2. Структура таблицы «Услуги»

Атрибут	Тип данных
Код услуги	Счетчик
Наименование услуги	Текст
Цена	Числовой

Таблица 3. Структура таблицы «Элементы оформления»

Атрибут	Тип данных
Код элемента оформления	Счетчик
Наименование элемента оформления	Текст
Цена	Числовой

Таблица 4. Структура таблицы «Скидки»

Атрибут	Тип данных
Код скидки	Счетчик
Размер скидки в процентах	Числовой

Таблица 5. Структура таблицы «Менеджеры»

Атрибут	Тип данных
Код менеджера	Счетчик
ФИО менеджера	Текст
Телефон	Текст

Таблица 6. Структура таблицы «Мероприятия»

Атрибут	Тип данных
Кд мероприятия	Счетчик
Наименование мероприятия	Текст

Таблица 7. Структура таблицы «Работники»

Атрибут	Тип данных
Код работника	Счетчик
ФИО работника	Текст
Код услуги	Числовой

Таблица 8. Структура таблицы «Заказ»

Атрибут	Тип данных
№ заказа	Счетчик
Код клиента	Числовой
Код мероприятия	Числовой
Код менеджера	Числовой
Код скидки	Числовой
Дата приема	Дата
Дата завершения	Дата

Таблица 9. Структура таблицы «Элементы оформления по заказу»

Атрибут	Тип данных
№ заказа	Числовой
Код элемента оформления	Числовой
Количество	Числовой

Таблица 10. Структура таблицы «Услуги по заказу»

Атрибут	Тип данных
№ заказа	Числовой
Код услуги	Числовой
Количество	Числовой

Заполненные данными таблицы представлены на рисунках №….

Рисунок №.Данные таблицы «Клиент»

Рисунок № Данные таблицы «Услуги»

Рисунок № Данные таблицы «Элементы оформления»

Рисунок № Данные таблицы «Скидки»

Рисунок № Данные таблицы «Менеджер»



Рисунок № Данные таблицы «Мероприятия»

Рисунок № Данные таблицы «Работник»

Рисунок № Данные таблицы «Заказ»

Рисунок № Данные таблицы «Элементы оформления по заказу»

Рисунок № Данные таблицы «Услуги по заказу»

2.3 Схема данных

Схема БД -- это визуальное представление таблиц в базе данных.

Схема данных для проектируемой БД представлена на рисунке.



Рисунок

Размещено на Allbest.ru

...