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

Содержание

Введение

1. Анализ предметной области проектирования

1.1 Профили стандартов

1.2 Диаграмма вариантов использования

1.3 Диаграмма кооперации

2. Выбор и обоснование средств и методов разработки

3. Проектирование логической структуры программного средства

3.1 Диаграмма последовательности

3.2 Диаграмма классов

3.3 Диаграмма состояний

3.4 Диаграмма деятельности

4. Разработка физической структуры программного средства

4.1 Диаграмма компонентов

4.2 Диаграмма развертывания

5. Разработка интерфейсных компонентов программного средства

6. План выполнения работ по созданию программного продукта

Заключение

Список использованных источников

Приложение

Введение

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

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

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

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

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

Таким образом, применение средств автоматизации и информационной системы является целесообразным и необходимым современных в условиях.

Автоматизированная информационная система "Расчет стоимости проката автомобилей" создается с целью:

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

Выполнение курсового проекта подразумевает выполнение следующих задач:

- анализ предметной области и выбор подходящих профилей стандартов

- выбор средств и методов разработки

- проектировку логической структуры программного средства

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

1. Анализ предметной области проектирования

ООО «Авто в долг» Осуществляет сдачу в аренду люксовых легковых транспортных средств зарубежного производства.

Система управления предприятием построена в соответствии с линейно-иерархическим принципом. На каждом уровне четко определены зоны ответственности и зоны подчинения.

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

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

Служба материально-технического снабжения ведет учет оборудования и технических средств, необходимых для ремонта.

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

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

Стаж вождения - количество времени, с момента получения клиентом водительских прав до его обращения в компанию ООО «Авто в долг».

Количество аварийных случаев - число ДТП, в которых участвовал клиент, как в роли виновника, так и потерпевшей стороны.

Тип страхования - под типом страхования подразумевается вид страхового соглашения, которое намерен заключить клиент со страховой организацией.

1.1 Профили стандартов

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

Создание системы основывается на перечне следующих документов:

ГОСТ 34.601-90 - «Стадии создания автоматизированной системы».

ГОСТ 34.603-92 - «Виды испытаний автоматизированной системы».

ГОСТ 34.602-89 - «Техническое задание на создание автоматизированной системы». Требования к содержанию и оформлению ко всему техническому заданию на создание автоматизированной системы “Учета деталей на складе”.

Стандарт ISO/IEC 12207:2008 «System and software engineering -- Software life cycle processes» -- стандарт ISO, который описывает процессы жизненного цикла программного обеспечения.

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

Стандарт ISO 15504:1-5:2003-2006 определяет оценку и аттестацию зрелости процессов создания и совершенствования программных средств и систем, выполняемых предприятиями.

Стандарт ISO 9001:2000 - «Система менеджмента качества». Используется для описания требований заказчика, разработчика, утверждение проекта.

Стандарт ISO 90003:2004 - «Рекомендации по применению стандарта ISO 9001:2000 для программных средств» - предназначены для регулирования менеджмента при приобретении, разработке, поставке, применении, сопровождении сложных программных средств.

Стандарт ISO/IEC 12207 Standard for Information Technology -- Software Life Cycle Processes, определяет общую структуру жизненного цикла по приобретению, передаче, разработке и эксплуатации ПО.

1.2 Диаграмма варианта использования

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

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

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

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

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

-«Ввод данных» -«Расчет стоимости аренды ТС»

-«Расчет стоимости страховки ТС»

-«Реализация запросов»

На рисунке 1 представлена схема функциональных возможностей.



Рисунок 1 Диаграмма вариантов использования

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

1.3 Диаграмма кооперации

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

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

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

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

На рисунке 2 представлена диаграмма кооперации для процесса ввода данных.



Рисунок 2 Диаграмма кооперации (ввод данных)

Рисунок 3 показывает структурные отношения между объектами при расчете стоимости проката автомобиля.

Рисунок 3 Диаграмма кооперации (аренда)

Рисунок 4 отображает последовательность операций при расчете стоимости страхования.



Рисунок 4 Диаграмма кооперации (страхование)

Рисунок 5 Диаграмма кооперации (реализация запросов)

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

2. Выбор и обоснование средств и методов разработки

программный стоимость прокат автомобиль

Для проектирования информационной системы была выбрана методология объектно-ориентированного анализа и проектирования на языке UML.

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

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

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

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

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

Также в UML используются следующие диаграммы:

- диаграмма вариантов использования;

- диаграмма последовательности;

- диаграмма кооперации;

- диаграмма классов;

- диаграмма состояний;

- диаграмма деятельности;

- диаграмма развертывания.

3. Проектирование логической структуры программного средства

3.1 Диаграмма классов

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

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

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

Диаграмма классов проекта отображает классы объектов ПО «Авто в долг» с их характерным поведением и свойствами. Структурными единицами, т.е представителями, выделены конкретные объекты, обладающие сходными свойствами и событиями. В диаграмме выделены такие классы:

- «Карточка клиента»

- «Аренда»

- «Страховка»

- «Расчетный лист»

Рисунок 6 Диаграмма классов

Таблица 1 Ключевые реквизиты класса «Карточка клиента»

Название реквизита	Обозначение	Тип	Размерность
Стаж	Stage	Integer	2
Срок	Term	Integer	3
Пол	Gender	String	7
Автомобиль	Vehicle	String	30
Аварийные случаи	Incidents	Integer	2
ФИО	FIO	String	50

Таблица 2 Ключевые реквизиты класса «Страховка»

Название реквизита	Обозначение	Тип	Размерность
Сумма	Summ	Real	8

Таблица 3 Ключевые реквизиты класса «Аренда»

Название реквизита	Обозначение	Тип	Размерность
Сумма	Summ	Real	8

Таблица 4 Ключевые реквизиты класса «Расчетный лист»

Название реквизита	Обозначение	Тип	Размерность
Цена	Cost	Real	8

3.2 Диаграмма последовательности

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

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

В UML диаграмма последовательности содержит два измерения. Слева направо в виде вертикальных линий, каждая из которых отображает линию жизни отдельного объекта, участвующего во взаимодействии. Первый слева на диаграмме изображается объект, который является инициатором взаимодействия. Правее изображается другой объект, который будет взаимодействовать с первым. Таким образом, все объекты на диаграмме образуют некоторый порядок, который определяется поочередностью объектов при взаимодействии друг с другом. На рисунке 7 показано, каким образом, от оператора поступают данные о клиенте в базу данных организации ООО «Авто в долг». Для этого оператор ЭВМ должен внести данные в карту клиента, находящуюся на форме, затем, эта карта автоматически передается в базу данных, где она сохраняется.



Рисунок 7 Диаграмма вариантов использования (ввод данных)

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

Рисунок 8 Диаграмма вариантов использования (Аренда)

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

Рисунок 9 Диаграмма вариантов использования (страхование)

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



Рисунок 10 Диаграмма вариантов использования (реализация запроса)

3.3 Диаграмма состояний

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

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

У диаграммы состояний основными элементами являются «Переход» и «Состояние». Диаграмма состояний имеет некую схожесть с диаграммой деятельности, в данном случае деятельность здесь как бы заменена состоянием, а переходы символизируют действия. Таким образом, диаграмма состояний символизирует состояние, в котором объект находится продолжительное количество времени, когда на самом деле действие моментально.

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

- entry - действие, которое выполняется в момент входа в данное состояние (входное действие);

- exit - действие, которое выполняется в момент выхода из данного состояния (выходное действие);

- do - выполняющаяся деятельность ("do activity") в течение всего времени, пока объект находится в данном состоянии.

На данной диаграмме отображается изменение состояния базы данных в зависимости от выбранного оператором действия (рисунок 11).

Рисунок 11 Диаграмма состояний базы данных

Диаграмма на рисунке 12 показывает состояния экранной формы, в зависимости от выбранной оператором процедуры.

Рисунок 12 Диаграмма состояний экранной формы

3.4 Диаграмма деятельности

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

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

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

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

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

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



Рисунок 13 Диаграмма деятельности

4. Разработка физической структуры программного средства

4.1 Диаграмма компонентов

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

Диаграммы компонентов важны не только для визуализации, специфицирования и документирования системы, основанной на компонентах, но и для создания исполняемых систем путем прямого и обратного проектирования. Каждый класс модели (или подсистема) преобразуется в компонент исходного кода. После создания они сразу добавляются к диаграмме компонентов. Между отдельными компонентами изображают зависимости, соответствующие зависимостям на этапе компиляции или выполнения. Диаграммы компонентов применяются теми участниками проекта, кто отвечает за компиляцию системы. Из этой диаграммы видно, в каком порядке надо компилировать компоненты, а также какие исполняемые компоненты будут созданы системой. На диаграмме компонентов показано соответствие классов реализованным компонентам. Она необходима там, где начинается генерация кода. Рисунок 14 показывает связь между подсистемами «Компьютер оператора», «База данных», «Сетевой принтер».



Рисунок 14 Диаграмма компонентов и размещения

4.2 Диаграмма развертывания

Этот вид диаграмм предназначен для анализа аппаратной части системы, то есть "железа", а не программ. В прямом переводе с английского Deployment означает "развертывание", но термин "топология" точнее отражает сущность этого типа диаграмм.

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

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

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

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

На диаграмме (рисунок 15) представлены функциональные органы, узлы и линии связи между ними. Данная структура во многом отображает не только схему компонентов, но и их интерфейсные характеристики.

Внутри организации сетевое соединение имеет инкапсулированные пакет защиты типа TCP\IP. Межорганизованное взаимодействие реализуется типом связи Ethernet.

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



Рисунок 15 Диаграмма развертывания

5. Разработка интерфейсных компонентов программного средства

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

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

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

На рисунках 16,17,18 показана экранная форма приложения, которая позволяет вводить данные в систему. Помимо ввода экранная форма позволяет выполнять расчеты стоимостей страхования и аренды.

Рисунок 16 Экранная форма



Рисунок 17 Экранная форма

Рисунок 18 Экранная форма

6. План выполнения работ по созданию программного продукта

Microsoft Project (или MSP) -- программа управления проектами, разработанная и продаваемая корпорацией Microsoft.

Microsoft Project создан, чтобы помочь менеджеру проекта в разработке планов, распределении ресурсов по задачам, отслеживании прогресса и анализе объёмов работ. Microsoft Project создаёт расписания критического пути. Расписания могут быть составлены с учётом используемых ресурсов. Цепочка визуализируется в диаграмме Ганта.

Рисунок 19 План работ micrisoft project

Таблица 5 Табличное представление плана работ

№	Название задачи	Длительность	Начало	Окончание	Предшественники
1	Начало реализации проекта	1д	Ср 01.10.14	Ср 01.10.14
2	Постановка задачи	10д	Пт 03.10.14	Чт 16.10.14	1
3	Разработка интерфейса	5д	Пт 17.10.14	Чт 23.10.14	2
4	Разработка модулей обработки данных	7д	Пт 24.10.14	Пн 03.11.14	3
5	Разработка структуры базы данных	5д	Вт 04.11.14	Пн 10.11.14	2
6	Отладка	2д	Ср 05.11.14	Чт 06.11.14
7	Отладка программного комплекса	1д	Пт 07.11.14	Пт 07.11.14	6
8	Тестирование и исправление ошибок	2д	Пт 07.11.14	Пн 10.11.14
9	Составление программной документации	1д	Пн 10.11.14	Пн 10.11.14
10	Отладка завершена	1д	Чт 11.12.14	Чт 11.12.14	8
11	Конец проекта	2д	Ср 12.11.14	Чт 13.11.14

Заключение

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

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

Использование информационной системы, разработанной в рамках курсового проекта:

- надежное и долговременное хранение данных;

- сократит трудоемкость и облегчит труд сотрудников;

- снизит время обработки информации;

- сведет возможность оформления неверного документа к нулю;

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

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

Список использованных источников

1 Диаграмма вариантов использования [Электронный ресурс]: - http://www.info-system.ru/ designing/methodology/uml/theory/use_case_diagram_theory.html.

2 Профиль стандартов [Электронный ресурс]: - http://www.znaytovar.ru/gost/ 2/GOST_2120378_SPDS_Pravila_uche.html

3 Крэг Ларман. Применение UML и шаблонов проектирования

4 Диаграмма классов [Электронный ресурс]: - http://www.info-system.ru/designing/methodology/uml/theory/class_diagram_ theory.html.

5 Теория и практика UML. Диаграмма состояний [Электронный ресурс]: - http://it-gost.ru/articles/view_articles/97.

6 Теория и практика UML. Диаграмма деятельности [Электронный ресурс]: - http://it-gost.ru/articles/view_articles/96.

7 Диаграмма последовательности [Электронный ресурс]: - http://www.info-system.ru/ designing/methodology/uml/theory/sequence_ diagram_theory.html.

8 Диаграмма развертывания [Электронный ресурс]: - https://ru.wikipedia.org /wiki/Диаграмма_развертывания.

9 Microsoft Project [Электронный ресурс]: - https://ru.wikipedia.org/wiki/ Microsoft_Project.

10 Техническое задание [Электронный ресурс]: - http://www.rugost.com/index.php? option=com _content&view=article&id =96:gost-34602-89&catid=22&Itemid=53.

Приложение А

1.1 Наименование системы

Автоматизированная информационная система «Расчет стоимости проката автомобилей».

1.2 Основания для проведения работ

Курсовая работа по дисциплине «Программная инженерия».

1.3 Наименование организаций - Заказчика и Разработчика

1.3.1 Заказчик

Заказчик: Оренбургский Государственный Университет

Адрес фактический: г. Оренбург, ул пр. Победы, д 13

Телефон / Факс: 8 (353) 277-67-70

1.3.2 Разработчик

Разработчик: Русаков Владимир Олегович

Адрес фактический: г. Оренбург, ул Чкалова

Телефон / Факс: +7 (903) 395-92-01

1.4 Плановые сроки начала и окончания работы

Начало: 1 сентября 2014. Окончание: 1 декабря 2014.

1.5 Порядок оформления и предъявления заказчику результатов работ

Работы по созданию АИС сдаются Разработчиком поэтапно в соответствии с календарным планом курсового проекта. По окончании каждого из этапов работ Разработчик сдает Заказчику соответствующие отчетные документы этапа, состав которых определены планом курсового проекта.

2 Назначение и цели создания системы

2.1 Назначение системы

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

- накопление данных о сделках по прокату автомобилей;

- подсчет притока прибыли от проката автомобилей;

- расчет амортизации автомобиля;

2.2 Цели создания системы

Автоматизированная информационная система «Расчет стоимости проката автомобилей» создается с целью:

- обеспечения сбора и первичной обработки исходной информации, необходимой для подготовки отчетности по показателям деятельности;

- создания единой системы отчетности по показателям деятельности;

- повышения качества (полноты, точности, достоверности, своевременности, согласованности) информации;

3 Характеристика объектов автоматизации

Структурное подразделение	Наименование процесса	Возможность автоматизации	Решение об автоматизации в ходе проекта
Производственное отделение	Расчет стоимости проката авто в зависимость от срока и сведений о клиенте	Возможна	Будет автоматизирована
Производственное отделение	Расчет стоимости страхования на установленный период времени	Возможна	Будет автоматизирована
Производственное отделение	Ввод, обработка и хранение данных о клиентах	Возможна	Будет автоматизирована

4 Требования к системе

4.1 Требования к системе в целом

4.1.1 Требования к структуре и функционированию системы

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

В Системе предлагается выделить следующие функциональные подсистемы:

- подсистема сбора, обработки и загрузки данных

- подсистема хранения данных

- подсистема формирования и визуализации результата.

В качестве протокола взаимодействия между компонентами Системы на транспортно-сетевом уровне необходимо использовать протокол TCP/IP.

Для организации информационного обмена между компонентами Системы должны использоваться специальные протоколы прикладного уровня, такие как: NFS, HTTP и его расширение HTTPS, NetBios/SMB, Oracle TNS.

Для организации доступа пользователей к отчетности должен использоваться протокол презентационного уровня HTTP и его расширение HTTPS.

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

- Основной режим, в котором подсистемы выполняют все свои основные функции.

- Профилактический режим, в котором одна или все подсистемы не выполняют своих функций.

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

- работу пользователей режиме - 24 часов в день, 7 дней в неделю (24х7);

- выполнение своих функций - сбор, обработка и загрузка данных; хранение данных, предоставление отчетности.

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

- техническое обслуживание;

- модернизацию аппаратно-программного комплекса;

- устранение аварийных ситуаций.

4.1.2 Требования к численности и квалификации персонала системы и режиму его работы

4.1.2.1 Требования к численности персонала

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

- Руководитель эксплуатирующего подразделения - 1 человек.

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

- Администратор подсистемы формирования и визуализации отчетности - 1 человек.

Данные лица должны выполнять следующие функциональные обязанности.

- Руководитель эксплуатирующего подразделения - на всем протяжении функционирования ИС обеспечивает общее руководство группой сопровождения.

- Администратор подсистемы сбора, хранения данных, обработки и загрузки данных - на всем протяжении функционирования ИС обеспечивает контроль процессов ETL, подготовку и загрузка данных из внешних источников в хранилище данных, распределение дискового пространства, модификацию структур БД, оптимизацию производительности.

- Администратор подсистемы формирования и визуализации отчетности - на всем протяжении функционирования ИС обеспечивает поддержку пользователей, формирование отчетности

5 Состав и содержание работ по созданию системы

Работы по созданию системы выполняются в три этапа:

- Проектирование. Разработка эскизного проекта. Разработка технического проекта.

- Разработка рабочей документации. Адаптация программ.

- Ввод в действие.

Конкретные сроки выполнения стадий и этапов разработки и создания системы определяются планом курсового проекта.

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

...