Лабораторная работа по дисциплине «Проектирование информационных систем» Тема: Метод функционального моделирования SADT. Методология IDEF0

Введение

1.Постановка задач автоматизированной системы управления «Автосервис»

1.1. Основания для разработки

1.2. Назначение

1.3. Цель проекта

1.4. Точка зрения

1.5. Границы моделирования

1.6. Требования к функциональным характеристикам

1.7.Требования к информационной и программной совместимости

1.8. Требования к программной документации

2. Проектирование автоматизированной системы «Автосервис»

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

2.1.1 Описание BPwin, стандарты моделирования

2.1.2 Описание, преимущества Rational Rose Enterprise Edition

2.1.3. Назначение языка UML

2.1.4.Общая структура языка UML

2.2. Диаграмма функций IDEF0

2.3.Перечень функций в соответствии с функциональными блоками в диаграмме IDEFO

2.4. Перечень функций в соответствии с блоками

3.Реализация автоматизированной системы «Автосервис»

3.1. Решение задач автоматизированной системы

3.1.1.Регистрация клиента в системе

3.1.2.Регистрация автомобиля клиента в системе

3.1.3. Ведение базы данных автозапчастей

3.1.4. Ведение базы данных зарегистрированных клиентов

3.1.5. Ведение базы данных производимых ремонтных работ

3.1.5. Выдача клиенту на руки форм отчетности документов и формирование электронной форм экономической отчетности по выполненным заказам

3.2. Описание информационной модели

3.3. Проектирование структуры базы данных

3.3.1.Исходные данные

3.3.2 Итоги Нормализации БД

3.4.Схема связей АСУ «Автосервис»

3.5.Проектирование форм электронных документов

3.5.1. Документ «Заказ-наряд на работы»

3.5.2.Документ «Счет-Фактура»

3.5.3. Документ «Приходный кассовый ордер»

3.5.4. Документ «Расходный кассовый ордер»

3.6. Руководство пользователя АСУ «АВТОСЕРВИС»

3.6.1.Регистрация клиентов

3.6.2.Регистрация автомобиля

3.6.3.Заказ запчастей и работ

3.6.4. Оформление заказа

3.6.5. Ведение склада

4. Оценка экономической эффективности разработки

Заключение

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

Введение

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

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

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

Актуальность состоит в том, что в современных условиях ремонта автомобилей возникает потребность быстро и качественно подобрать требуемые запчасти в зависимости от неисправности автомобиля. В основном данный процесс занимает достаточно емкий промежуток времени, приблизительно от нескольких часов до нескольких суток, особенно при работе с On-Line Электронными Базами Данными автомобильных, запчастей.

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

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

1. Постановка задач автоматизированной системы управления «Автосервис»

1.1 Основание для разработки

Проект «Автоматизированная система АВТОСЕРВИС» разрабатывается в виде дипломной работы, на основе учебного плана кафедры Информационных Технологий.

1.2 Назначение

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

1.3 Цель проекта

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

1.4 Точка зрения

Руководитель предприятия.

1.5 Границы моделирования

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

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

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

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

1.6 Требования к функциональным характеристикам

Регистрация клиента в системе

Регистрация автомобиля клиента в системе

Ведение базы данных автозапчастей

Ведение базы данных производимых ремонтных работ

Ведение базы данных зарегистрированных клиентов

Выдача клиенту на руки форм отчетности документов

Формирование электронной форм экономической отчетности по выполненным заказам

1.7 Требования к информационной и программной совместимости

Система должна работать под управлением семейства операционных систем Win 32 (Windows 95, Windows 98, Windows Me, Windows 2000, Windows NT, Windows XP).

1.8 Требования к программной документации

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

2. Проектирование автоматизированной системы «Автосервис»

2.1 Выбор и описание технологий проектирования и инструментальных средствах

В своем проекте я останавливаюсь на таких инструментальных средствах проектирования как BPWin и Rational Rose Enterprise Edition, Delphi 7

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

анализ - определение того, что система будет делать,

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

реализация - разработка подсистем по отдельности, объединение - соединение подсистем в единое целое,

тестирование - проверка работы системы,

установка - введение системы в действие,

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

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

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

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

Описание документооборота предприятия.

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

Создание сущностей и атрибутов и построение на этой основе модели данных.

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

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

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

2.1.1 Описание BPwin , стандарты моделирования

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

Создавать модели процессов и поддерживает три стандарта (нотации) моделирования - IDEF0, DFD и IDEF3. Каждая из трех нотаций, поддерживаемых в BPwin, позволяет рассмотреть различные стороны деятельности предприятия.

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

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

Диаграммы потоков данных (Data flow diagramming, DFD) используются для описания документооборота и обработки информации. DFD описывают функции обработки информации, документы, объекты, а также сотрудников или отделы, которые участвуют в обработке информации. Наличие в диаграммах DFD элементов для описания источников, приемников и хранилищ данных позволяет более эффективно и наглядно описать процесс документооборота.

Для описания логики взаимодействия информационных потоков более подходит IDEF3, называемая также workflow diagramming, - нотация моделирования, использующая графическое описание информационных потоков, взаимоотношений между процессами обработки информации и объектов, являющихся частью этих процессов. Диаграммы IDEF3 позволяют описать как отдельные сценарии реализации бизнес-процессов, так и полное описание последовательности действий. Диаграммы нового типа - Swim Lane, использующие методологию Process Flow Network и могут быть добавлены в модель, содержащую диаграммы IDEF3.

В моей дипломной работе я использовал диаграмму IDEF0

2.1.2 Описание , преимущества Rational Rose Enterprise Edition

Rational Rose Enterprise Edition - является по моему мнению наиболее удобным визуальным CASE средством проектирования информационных системна языке UML.

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

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

Среди всех фирм-производителей CASE-средств именно компания Rational Software Coip. одна из первых осознала стратегическую перспективность развития объектно-ориентированных технологий анализа и проектирования программных систем. Эта компания выступила инициатором унификации языка визуального моделирования в рамках консорциума OMG, что, в конечном итоге, привело к появлению первых версий языка UML. И эта же компания первой разработала инструментальное объектно-ориентированное CASE-средство, в котором был реализован язык UML как базовая нотация визуального моделирования.

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

Rational Rose Enterprise Edition

Rational Rose Professional Edition

Rational Rose Modeler Edition

Rational Rose для UNIX

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

Интеграция с MS Visual Studio 6, что включает в себя поддержку на уровне прямой и обратной генерации кодов и диаграмм VB 6, Visual C++ 6, Visual J++ 6 (ATL-Microsoft Active Template Library, Web-Classes, DHTML, Data Connections).

Непосредственная работа (инжиниринг и реинжиниринг) с исполняемыми модулями и библиотеками форматов EXE, DLL, TLB, OCX.

Поддержка технологий MTS (Microsoft Transaction Server) и ADO (ActiveX Data Objects) на уровне шаблонов и исходного кода, а также элементов стратегической технологии Microsoft - СОМ+ (DCOM).

Полная поддержка CORBA 2.2, включая реализацию технологии компонентной разработки приложений CBD (Component-Based Development), языка определения интерфейса IDL (Interface Definition Language) и языка определения данных DDL (Data Definition Language).

Полная поддержка среды разработки Java-приложений JDK 1.2, включая прямую и обратную генерацию классов Java формата JAR, а также работу с файлами форматов CAB и ZIP.

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

2.1.3 Назначение языка UML

Язык UML предназначен для решения следующих задач:

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

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

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

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

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

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

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

С другой стороны, язык UML должен обладать потенциальной возможностью реализации своих конструкций на том или ином языке программирования. Конечно, в первую очередь имеются в виду языки, поддерживающие концепцию ООП, такие как C++, Java, Object Pascal. Именно это свойство языка UML делает его современным средством решения задач моделирования сложных систем. В то же время, предполагается, что для программной поддержки конструкций языка UML могут быть разработаны специальные инструментальные CASE-средства. Наличие последних имеет принципиальное значение для широкого распространения и использования языка UML.

Описание языка UML должно включать в себя семантический базис для понимания общих особенностей ООАП.

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

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

Поощрять развитие рынка объектных инструментальных средств.

Способствовать распространению объектных технологий и соответствующих понятий ООАП.

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

Интегрировать в себя новейшие и наилучшие достижения практики ООАП.

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

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

2.1.4 Общая структура языка UML

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

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

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

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

Мета-метамодель

Метамодель

Объекты пользователя

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

Диаграмма вариантов использования (use case diagram)

Диаграмма классов (class diagram)

Диаграммы поведения (behavior diagrams)

Диаграмма состояний (statechart diagram)

Диаграмма деятельности (activity diagram)

Диаграммы взаимодействия (interaction diagrams)

Диаграмма последовательности (sequence diagram)

Диаграмма кооперации (collaboration diagram)

Диаграммы реализации (implementation diagrams)

Диаграмма компонентов (component diagram)

Диаграмма развертывания (deployment diagram)

2.2 Диаграмма функций IDEF 0

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

Стрелки входа (входят в левую грань работы) - изображают данные или объекты, изменяемые в ходе выполнения работы.

1.Детальный заказ клиента

2.Запчасти от поставщика

3.Платежи клиента

4.Регистрационные данные клиента

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

1.Законодательство

2.Список зарегистрированных клиентов

3.Сопроводительная документация

4.Список запчастей на складе

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

1.Отчетность

2.Документы подлежащие к оплате клиентом

3.Список для доставки необходимых запчастей

4.Бракованые детали

5.Дкументы подтверждающие выполнения заказа

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

1.Оборудование

2.Персонал

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

Контекстная диаграмма IDEF0

Диаграмма декомпозиции

2.3 Перечень функций в соответствии с функциональными блоками в диаграмме IDEFO

1) Работа Автоматизированной системы АВТОСЕРВИС.

Дает представление о деятельности системы в целом, показывая входящие и исходящие данные и объекты.

2) Принятие заказа.

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

3) Обработка заказа.

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

4) Исполнение заказа.

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

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

5) Проверка качества выполненных работ.

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

6) Дефектование запчастей.

Производится проверка исправности запчастей на основе сопроводительной документации

7) Исполнение заказа.

Проведение ремонта автомобиля на основании выявленных неисправностей.

8) Итоговое заключение по заказу.

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

9) Обработка заказа.

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

10)Определение з\ч которых нет в наличии.

На основании дополнительных выявленных неисправностях, а также анализа наличия запчастей на складе.

11)Определение неисправностей автомобиля.

12) Определение требуемых запчастей. На основе определения неисправностей автомобиля.

14)Проведение ремонта автомобиля.

15)Проверка качества выполненных работ.

16)Проверка качества запчастей

17)Проверка качества используемых деталей.

18)Подведение итогового заключения по заказу клиентов.

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

2.4 Перечень функций в соответствии с блоками

1) Законодательство Документация, по установленным правилам и нормам поведение с клиентом.

2)Выполненный заказ

Предоставленные результаты работ по заказу клиента

3)Данные по заказу.

Списки требуемых запчастей и неисправностей, а также стоимость ремонта.

4)Данные по клиенту.

Контактные денные и данные по автомобилю.

Детальный заказ клиента.

Конкретный список требований клиента.

Документация по сформированному заказу.

Заказ-Наряд и иная документация установленного образца.

Документация подтверждающая выполнение заказа.

Счет-Фактура, Накладные и иная документация установленного образца.

Документы подлежащие к оплате клиентом.

Ордера и иная документация установленного образца.

Заказ на проверку.

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

10)Заказ-Наряд Финансовая отчетность перед клиентом и для бухгалтерского учета.

11)Отчетность Финансовая отчетность перед клиентом и для бухгалтерского учета.

12)Прием платежа от клиента. Оплата клиентом заказа в установленном законодательством порядке.

13)Сопроводительная документация. Данные по поступающим запчастям (их характеристики).

14)Список автозапчастей на складе

15)Список бракованых деталей подлежащих возврату поставщику

16)Список для доставки необходимых запчастей

17)Список дополнений к заказу

18)Список з\ч и работ для проверки

19)Список зарегистрированных клиентов

20)Список неисправностей автомобиля

21)Список необходимых работ и требуемых запчастей

22) Список полученных запчастей.

23)Список принятых данных о заказе.

24) Сформированный заказ

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

3. Реализация автоматизированной системы управления

3.1 Перечень задач автоматизированной системы

3.1.1 Регистрация клиента в системе

ФИО клиента

Город клиента

Адрес клиента

Телефон клиента

3.1.2 Регистрация автомобиля клиента в системе

При реализации этой задачи клиент предоставляет следующие данные менеджеру по работе с клиентами:

VTN код автомобиля клиента

Марка автомобиля клиента

Модель автомобиля клиента

Тип двигателя автомобиля клиента

Год выпуска автомобиля клиента

Пробег автомобиля клиента

Государственный регистрационный номер автомобиля клиента

Цвет автомобиля клиента

Дата регистрации автомобиля клиента

3.1.3 Ведение базы данных автозапчастей

Производитель запасной части

Наименование запасной части

Количество заказанных запасных частей

Стоимость единицы запасной части

Стоимость работ по замене запчастей

3.1.4 Ведение базы данных зарегистрированных клиентов

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

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

3.1.5 Ведение базы данных производимых ремонтных работ

Аналогично и по этой задаче:

Наименование выполненной работы

Стоимость выполненной работы

Дата заказа

3.1.5 Выдача клиенту на руки форм отчетности документов и формирование электронной форм экономической отчетности по выполненным заказам

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

Заказ-наряд на работы

Расходный кассовый ордер

Приходный кассовый ордер

Накладная

3.2 Описание информационной модели

Для описания информационной модели я разработал с помощью CASE средств два вида диаграмм:

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

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

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

На диаграммах класс изображается в виде прямоугольника со сплошной границей, разделенного горизонтальными линиями на 3 секции:

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

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

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

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

3.3 Проектирование структуры базы данных

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

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

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

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

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

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

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

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

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

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

3.3.1 Исходный набор данных

Наименование клиента

Город клиента

Адрес клиента

Телефон клиента

Электронный адрес

Принадлежность клиента к юридическому или физическому лицу

VIN код автомобиля

Марка автомобиля

Модель автомобиля

Тип двигателя автомобиля

Год выпуска автомобиля

Пробег автомобиля

Государственный регистрационный номер автомобиля

Цвет автомобиля

Дата регистрации автомобиля

Производитель запасных частей автомобиля

Наименование запасной части автомобиля

Количество запасных частей автомобиля

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

Стоимость работы по замене запасной части автомобиля

Наименование выполненной ремонтной работы по автомобилю

Стоимость выполненной ремонтной работы по автомобилю

3.3.2 Итоги Нормализации БД

Таким образом, вследствие нормализации БД в я получил восемь таблиц:

«Клиенты»,

«Заказ работ»,

«Заказ запчастей»,

«Работы»,

«Запчасти».

«Регистрационные данные автомобиля», которые впоследствии при работе системы «АВТОСЕРВИС» служат в качестве справочных таблиц.

3.4 Схема связей АСУ «Автосервис»

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

Для этих целей я систему в общем виде условно разделил на три составляющие:

Регистрация клиентов и их автомобилей

Навигация по запасным частям

Собственно заказы автозапчастей и работ

В раздел «Регистрация клиентов и их автомобилей» я включил две таблицы:

«Клиенты»,

«Зарегистрированные автомобили клиентов»

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

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

Структура БД

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

В данной БД основными используются таблицы:

«Клиенты»:

Поле код клиента является ключевым..

«Заказы»:

VIN код – ключевое поле.

«Работы»:.

Код работы – ключевое поле.

«Запчасти»:

Код запчасти – ключевое поле.

«Заказы работ»:

Номер заказа – ключевое поле; код клиента, код работы – для связи с данными о клиенте и работах.

«Заказ запчастей»:

Номер заказа – ключевое поле; код клиента, код запчасти – для связи с данными о клиенте и запчастях.

3.5 Проектирование форм электронных документов

Система «Автосервис» должна выдавать следующие формы электронных документов для отчетности и заключения договоров с клиентами:

Заказ-наряд на работы.

Расходный кассовый ордер

Приходный кассовый ордер

Счет-фактура

3.5.1 Документ «Заказ-наряд на работы»

Документ «Заказ-наряд на работы», который сформировывает система «Автосервис» выглядит следующим образом:

3.5.2 Документ «Счет-Фактура»

«Счет-Фактура», который сформировывает АСУ «Автосервис» выглядит следующим образом:

3.5.3 Документ «Приходный кассовый ордер»

Документ «Приходный кассовый ордер», который сформировывает система «Автосервис» выглядит следующим образом:

3.5.4 Документ «Расходный кассовый ордер»

Документ «Расходный кассовый ордер», который сформировывает система «Автосервис» выглядит следующим образом:

3.6 Руководство пользователя АСУ «АВТОСЕРВИС»

Система «АВТОСЕРВИС» предназначена для автоматизации работы с клиентами на Станциях Технического Обслуживания.

Для того чтобы начать работу с системой «.АВТОСЕРВИС» требуется запустить файл приложения «ProjectAuto».

3.6.1 Регистрация клиентов

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

Если клиент - новый, тогда ПС должен его зарегистрировать в системе.

После заполнения всех полей на одной из этих вкладок пользователь системы должен нажать на кнопку «Добавить» для проверки правильности заполнения всех полей (Рис. 6).

3.6.2 Регистрация автомобиля

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

После заполнения всех полей на этой вкладке пользователь системы должен нажать на кнопку «Добавить» для проверки правильности заполнения всех полей (Рис. 7).

Рис.7 «Регистрация автомобиля»

3.6.3 Заказ запчастей и работ

Программа предложит пользователю перейти на Форму оформления заказа, где клиенту предоставляется возможность подобрать работы и запасные части к его автомобилю:

Пользователь на вкладке «Заказ на выполнение работ» выбирает из таблицы «Выполненные работы» требуемую работу для клиента и нажимает на кнопку «Выбрать» и так до тех пор пока не выберет перечень необходимых работ

Программа предложит пользователю сделать предварительный заказ автозапчастей для клиента

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

Рис.8 Форма предварительного заказа автозапчастей и работ.

3.6.4 Оформление заказа

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

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

Формы предлагаемых документов:

Заказ - Наряд на работы

Счет - фактура

Приходный кассовый ордер

Расходный кассовый ордер

Пользователь указать документы, необходимые к выдаче клиенту и нажать на кнопку «Сформировать отчет».

После чего будут сформированы требуемые формы документов и предложены для печати.

Рис.9 «Оформление заказа»

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

3.6.5 Ведение склада

В программе также предусмотрено ведение склада автозапчастей работ, которые вызываются из главной формы командой «Склад -- > Добавление запчасти\работы». Где пользователь системы имеет возможность оприходовать в базу данных поступившие запчасти или добавить новый набор работ.

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

расчет единовременных затрат разработчика;

тиражирование и реализация программного обеспечения;

план прибыли от продаж;

финансовый план проекта;

определение экономической эффективности проекта.

Расчет единовременных затрат разработчика

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

Фактическая трудоемкость работ по стадиям научно-исследовательских работ представлена в таблице 5.

Таблица 5

	Трудоемкость, дн.	Трудоемкость, %
Техническое задание
Эскизный проект
Технический проект
Рабочий проект
Внедрение

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

материальные затраты;

основная и дополнительная заработная плата;

отчисления на социальные нужды;

стоимость машинного времени на подготовку и отладку программы;

стоимость инструментальных средств;

накладные расходы.

Материальные затраты

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

В процессе работы использовались материалы и принадлежности, представленные в таблице 6.

Таблица 6

Использованные материалы и принадлежности

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

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

Таким образом, основная заработная плата (З осн) при выполнении научно-исследовательских работ рассчитывается по формуле:

,

Где З срдн j – зарплата j-го сотрудника, руб.;

n – количество сотрудников, принимающих непосредственное участие в разработке программного продукта.

Среднедневная зарплата разработчика (З раз/д) определена из расчета 8000 руб. в месяц и равна:

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

Заработная плата исполнителя в целом составляет:

З раз =205 дн.*350 руб./день=71750 руб.

На консультации запланировано:

23 часов – дипломный руководитель

3 часа – консультант по экономике.

Заработная плата дипломного руководителя составляет 40 руб./час. Следовательно, среднедневная зарплата дипломного руководителя равна:

З рук =23*40=920 руб.

Заработная плата консультанта по экономике составляет 40 руб./час. Следовательно, среднедневная зарплата равна:

З конс =3*40=120 руб.

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

З осн =З раз +З рук +З конс =71750+920+120=72790 руб.

Дополнительная заработная плата составляет 10 % от основной, следовательно:

З доп =0,1*З осн =0,1*72790=7279 руб.

Итого основная и дополнительная заработная плата составляют:

З общ =З осн +З доп =72790+7279=80069 руб.

Отчисления на социальные нужды

Отчисления на социальные нужды на сегодняшний день составляют 26% от общего фонда заработной платы, следовательно:

О соц =З общ *0,26=80069*0,26=20817,94 руб.

Стоимость машинного времени на подготовку и отладку программы

Затраты на оплату машинного времени (З омв) зависят от себестоимости машино-часа работы ЭВМ (С мч), времени работы на ЭВМ (Т эвм) и включают в себя амортизацию ЭВМ и оборудования, затраты на электроэнергию. Таким образом, себестоимость машино-часа работы ЭВМ составила:

С мч =0,24 кВт/час*1,16 руб./кВт=0,28 руб./час

Время работы на ЭВМ вычисляется по формуле:

Т эвм = Т эвм =0,35*Т эск +0,6*Т тех пр +0,8*Т раб пр +

0,6*Т вн =0,35*25+0,6*30+0,8*39+0,6*10=131 день

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

Т эвм =131 дн*8ч=1048 ч

Себестоимость электроэнергии рассчитывается следующим образом:

С эл = Т эвм *С мч =1048*0,28=293,44 руб.

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

А м =(О ф *Н ам *Т эвм)/(365*100),

Где О ф – первоначальная стоимость оборудования, руб.;

Н ам – норма амортизации, % (принято 20%);

Первоначальная стоимость оборудования представлена в таблице

Таблица 7

Себестоимость оборудования и амортизационные отчисления

Согласно таблице 7 первоначальная стоимость оборудования составила 29840 руб.

Произведем расчет затрат на амортизацию:

А м =(29840*20*131)/(365*100)= 2135,40 руб.

Стоимость машинного времени

Затраты на оплату машинного времени (З овм) включают:

Затраты на оборудование - 2135,40 руб.

Затраты на электроэнергию – 290,87 руб.

Таким образом, стоимость машинного времени составляет:

З овм =2135,40+290,87=2426,27 руб.

Стоимость инструментальных средств

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

Таблица 8

Стоимость системного программного обеспечения

Норма амортизации для системного программного обеспечения – 30%, время использования - 139 день.

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

А ис =(О ф *Н ам *Т эвм)/(365*100),

Где О ф – первоначальная стоимость инструментальных средств, руб.;

Н ам – норма амортизации, % (принято 30%);

Т эвм – время использования оборудования, дней.

А ис =(33925*30*131)/(365*100)= 3652,75 руб.

Накладные расходы

Накладные расходы составляют 30 % от суммы основной заработной платы, а значит:

Р н =З осн *0,3=72790*0,3=21837 руб.

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

Таблица 9

Смета затрат на программное обеспечение

Получаем, что затраты на научно-исследовательские работы равны:

К нир =130284,96руб.

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

Таблица 10

План инвестиций

Тиражирование и реализация программного обеспечения

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

Таблица 11

План по реализации программного обеспечения

Показатели
Объем тиражирования
Цена, руб.
Выручка от реализации, руб.
Доходы от сопровождения, руб.

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

Таблица 12

Смета затрат

Показатели
	2 полугодие 2005	1 полугодие 2006	2 полугодие 2006	1 полугодие 2007	2 полугодие 2007	1 полугодие 2008	2 полугодие 2008	1 полугодие 2009
Затраты на тиражирование:
Стоимость документации
Затраты на копирование
Стоимость машинных носителей и упаковочных материалов
Амортизация ЭВМ и оборудования
Затраты на сопровождение ПО
Итого затраты:

План прибыли от продаж

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

Таблица 13

План прибыли

Показатели
	2 полугодие 2005	1 полугодие 2006	2 полугодие 2006	1 полугодие 2007	2 полугодие 2007	1 полугодие 2008	2 полугодие 2008	1 полугодие 2009
Выручка от реализации и сопровождения
Затраты на тиражирование и cопровождение
Процентные платежи за кредит
Прибыль валовая
Налог (24%)
Прибыль чистая

Финансовый план проекта

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

Таблица 14

Оценка финансовой состоятельности проекта

Показатели
	2 полугодие 2005	1 полугодие 2006	2 полугодие 2006	1 полугодие 2007	2 полугодие 2007	1 полугодие 2008	2 полугодие 2008	1 полугодие 2009
1. Инвестиционная деятельность
техническое задание
эскизный проект
технический проект
рабочий проект
Внедрение
Итого: эффект от инвестиционной деятельности
2. Операционная деятельность
Выручка, всего
Затраты, всего
Прибыль валовая
Налог на прибыль
Прибыль чистая
Итого: эффект от операционной деятельности
3. Финансовая деятельность
Собственные средства
Возврат кредита
Итого: эффект от финансовой деятельности
4. Сальдо денежной наличности (1+2+3)
5. Сальдо денежной наличности нарастающим итогом

Из таблицы 14 видно, что данный проект потребует 95826,56 и 34458,56 рубля инвестиций соответственно в первое и второе полугодие. Так как в первое полугодие продажа программного продукта не осуществляется, то для покрытия данного вида затрат потребуется 95826,56 рубля. Эти средства можно получить либо вложив собственные средства, как в представленном случае, либо взяв банковский кредит. За второе полугодие планируется осуществить продажу семи копий программы и прибыль от продажи так же не покроет появившиеся на данном периоде затраты, т.е. потребуется дополнительное вложение 3321,56 рубля. Доход ожидается начиная со второго полугодия 2006 года. Так как сальдо денежной наличности является положительной величиной нарастающим итогом по всем периодам, можно перейти к определению чистой текущей стоимости проекта, которая характеризует эффективность проекта.

Определение экономической эффективности проекта

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

чистая текущая стоимость;

индекс доходности;

внутренний коэффициент эффективности;

максимальный денежный поток;

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

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

Таблица 15

Денежные потоки, руб.

Показатели
	2 полугодие 2005	1 полугодие 2006	2 полугодие 2006	1 полугодие 2007	2 полугодие 2007	1 полугодие 2008	2 полугодие 2008	1 полугодие 2009
Эффект от инвестиционной деятельности
Эффект от операционной, деятельности
Чистый денежный поток (ЧДП)
Коэффициент дисконтирования (α)
Дисконтированный денежный поток (ДДП=ЧДП*α)
Дисконтированный денежный поток нарастающим итогом (NPV)

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

Коэффициент дисконтирования (α) рассчитывается по формуле:

Где r – ставка дисконтирования,

t – период времени.

Ставка дисконтирования (r) рассчитывается по формуле:

При этом ставка рефинансирования равна 13%, инфляция – 11%, а риск – 13%. Таким образом, получаем:

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

Индекс доходности (SRR) определяется как отношение суммарного дисконтированного дохода к суммарным дисконтированным капитальным вложениям:

Где П чt – прибыль чистая,

A t – амортизационные отчисления,

K t – капитальные вложения в основные и оборотные фонды,

α t – коэффициент дисконтирования.

Таким образом, индекс доходности равен:

SRR=(31137*0,87+140898,95*0,81+143657,7*0,75+96029,4*0,7+93861,2*0,65+42572*0,61+38215*0,56)/ (95826,56*0,93+34458,56*0,87)=3,57

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

Внутренний коэффициент эффективности проекта (IRR) или пороговое значение рентабельности рассчитывается по формуле:

Где r пор – внутренний коэффициент эффективности проекта,

r 1 – исходная ставка дисконтирования,

r 2 – ставка дисконтирования, при которой NPV меньше нуля,

NPV r1 и NPV r2 – NPV соответственно при r 1 и r 2.

Для этого возьмем такую ставку дисконтирования (r 2 =1,14), при которой NPV станет меньше нуля. Полученные результаты сводятся в таблицу 16.

Таблица 16

Нахождение отрицательной чистой текущей стоимости проекта

Рассчитаем пороговое значение рентабельности:

r(пор.)= 0,15+(285817,34/(285817,34-(-745,75)))*(1,14-0,15)=1,137

Значение внутреннего коэффициента эффективности проекта, равное 113,7 % в полугодие или 129,6% годовых, показывает с одной стороны рентабельность проекта, а с другой стороны – предельную ставку процента по банковскому кредиту, полученному для финансирования проекта.

Срок окупаемости проекта (T ок ) можно найти по формуле:

Где t x – количество периодов, при которых NPV меньше нуля,

NPV t – последнее отрицательное значение NPV,

ДДП t+1 – величина ДДП в t+1 периоде.

Срок окупаемости проекта равен:

Т(ок)= 2+|-111653,73/114128,15|=2,98

Значение: срока окупаемости проекта равное 2,98 полугодия или 1,49 года говорит о том, что только через данный промежуток времени проект окупит денежные средства, вложенные в его реализацию, и только затем начнет приносить доход.

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

В результате проведенного расчета показателей, характеризующих экономическую эффективность проекта можно сделать выводы о его выгодности, т.к. сальдо реальных накопленных денег во всех временных интервалах положительно, значение интегрального экономического эффекта больше нуля (NPV=285817,34>0), значение индекса доходности более единицы (SRR=3,57>1), а так же внутренний коэффициент эффективности значительно больше заданной ставки дисконтирования (IRR=1,28>0,15).

Заключение

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

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

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

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

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

В цело можно сделать вывод о том что цель моей курсовой работы достигнута.

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

1. Автоматизированные информационные технологии в экономике: Учебник/ Под ред. Проф. Г.А. Титоренко. - М.: Компьютер, ЮНИЩ 1998.

2. Вендров А.М. CASE - технологии. Современные методы и средства проектирования информационных систем. - М.: Финансы и статистика, 1998.

3. Маклаков С.В. BFWin и ERWin. CASE-средства разработки информационных систем. М.: ДИАЛОГ-МИФИ, 2000.

4. Delphi 7 в подлиннике. А. Хомоненко. СПб: BHV, 2003 – 1216 стр.

5. Delphi. Советы программистов (2-е издание): В.Озеров. – СПб: Символ-Плюс, 2002. – 976 стр.

6. Borland Delphi 6. Руководство разработчика: С.Тейксейра, К.Пачеко. – М: Вильямс, 2002. – 1120 стр.

7. Принципы проектирования и разработки программного обеспечения. Учебный курс MCSD: Скотт Ф. Уилсон, Брюс Мэйплс, Тим Лэндгрейв. – М: Русская редакция, 2002. – 736стр.

8. Проектирование экономических информационных систем: Учебник/Г.Н.Смирнова, А.А.Сорокин, Ю.Ф.Тельнов. – М: Финансы и статистика, 2003. – 512стр.

9. Вендров А.М. Проектирование программного обеспечения экономических информационных систем. М.: «Финансы и статистика»,2002.

10. Самоучитель UML. Эффективный инструмент моделирования информационных систем: А. Леоненков. – СПб: BHV, 2001. – 304стр.

11. Delphi 7 на примерах/Под ред. Ю. С. Ковтанюка - К.: Издательство Юниор, 2003. - 384 с., ил.

12. Нестандартные приемы программирования на Delphi. - СПб.: БХВ-Петербург, 2005. - 560 с: ил.

13. UML диаграммы в Rational Rose – http://www. с ase с lub .га. article s/rose2 .html:

14. Объектно-ориентированный подход и диаграммы классов в UML http://www.iti.bpbu.ru/publicationb."i-u/Real UML.htm:

15. Основы проектирования реляционных баз данных http://books.kulichki.net/data/sql/sqll/:

16. Понимание SQL (Understanding SQL). http://www.sql.ni/docs/sql/u sqI/index.shtml:

17. Borland AML Portal. WWW: http://www.almportal.ru

18. Компания Borland. WWW: http://www.borland.com

19. Русскоязычный сайт компании Borland. WWW: http://www.borland.ru

20. Сайт компании Statsoft. WWW: http://statsoft.ru

21. Сайт компании Base Group Labs. WWW: http://basegroup.ru

Жизненный цикл разработки информационной системы

В процессе создания информационная система проходит несколько стадий, начиная от ее задумки и заканчивая внедрением. В рамках курса «Базы данных и информационные технологии» наибольший интерес представляет первые два - проектирование и разработка. Давайте разберемся, что стоит за каждым из пунктов, перечисленных на слайде.

1. Исследование и анализ. Главной задачей информационной системы является удовлетворение информационных потребностей бизнеса. Поэтому на первом этапе важно разобраться как протекают бизнес-процессы внутри организации, на какие потоки информации они опираются. Чаще всего это происходит в виде интервью с представителями разных отделов предприятия. На этом этапе важно получить исчерпывающую картину работы предприятия в формате который будет с одной стороны понятен разработчикам, а с другой - представителям бизнеса. На этом этапе нам на помощь могут прийти методологии IDEF0 и DFD, которые будут рассмотрены в этой лекции.
2. Прототипирование . На этом этапе моделируется структура информационной системы, структура хранилищ данных, пользовательские интерфейсы.
3. Построение и документирование. На этом этапе происходит согласование прототипа системы с требованиями заказчика. Поведение информационной системы детально документируется, для того чтобы в дальнейшем можно было сравнить ожидаемое и полученное поведение системы.
4. Внедрение. На этом этапе выполняется верификация соответствия реального и ожидаемого поведения системы. Зачастую это происходит в виде пиремо-сдаточных испытаний.
5. Использование. Этот этап разработки информационной системы рассматривается дисциплиной Техническая поддержка программных решений (Technical Solution Support). Он характеризуется гарантийным и послегарантийным обслуживанием информационной системы. Примером такого обслуживания может быть исправление ошибок, внесение новых функций, повышение производительности, обучение персонала и прочее.

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

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

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

При этом «концептуальная модель» это:

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

Методология IDEF0

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

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

IDEF0 - это подмножество SADT (Structured Analisys and Design Technique). Методология SADT разрабатывалась Дугласом Т. Россом в 1969-1973 годах и изначально применялась для проектирования систем общего назначения. В данной методологии ключевым является в какую из сторон процесса направлен поток управления.

Поясним суть методологии IDEF0 на примере производства товара. Процесс производства условно изображен на слайде.

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

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

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

Правила интерпретации модели:

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

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

Анализ объекта на основе построения его IDEF0-модели является этапом, который должен предварять разработку информационной системы по целому ряду причин. Во-первых, при ознакомлении с объектом строят модель "КАК ЕСТЬ". Такая модель фиксирует бизнес процессы и используемые ими информационные потоки. Во-вторых, функциональная модель "КАК ЕСТЬ" позволяет увидеть информационно перегруженные бизнес процессы - "узкие" места обследуемого объекта. В-третьих, на основании модель "КАК ЕСТЬ" можно построить модель "КАК БУДЕТ". То есть предложить более совершенную структуру организации объекта. Но это уже вопросы реинжиниринга и мы их не будем касаться. Можно только отметить, что реинжиниринг подчеркивает важную роль информационных технологий в жизни общества. В-четвертых, в процессе построения модели "КАК ЕСТЬ" выявляются бизнес-правила - положения, которые регламентируют процесс функционирования моделируемого объекта. Например, представленный на слайде фрагмент функциональной модели должен быть зафиксирован бизнес-правилом: "служба снабжения обязана определять потребности в материалах для производства готовой продукции только на основании плана выпуска".

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

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

Методология Data Flow Diagram

Тот факт, что IDEF0-модель не разделяет потоки данных на материальные, информационные и управляющие приводит разработчиков к необходимости использовать диаграммы потоков данных (Data Flow Diagrams - DFD ). Это можно делать после составления IDEF0-модели, либо вместо этого в зависимости от сложности моделируемого объекта или предпочтений исполнителя.

Основы методологии построения диаграмм потоков данных DFD были описаны в 1979 году C. Gane и T. Sarson в книге "Structured Systems Analysis".

Ее назначение - ограничить рамки системы, определить, где заканчивается разрабатываемая система и начинается среда.

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

• External Entity ( Внешняя сущность ) представляет собой материальный предмет или физическое лицо, представляющее собой источник или приемник информации, например, заказчики, персонал, поставщики, клиенты, склад. Определение некоторого объекта или системы в качестве внешней сущности указывает на то, что она находится за пределами границ анализируемой ИС. В процессе анализа некоторые внешние сущности могут быть перенесены внутрь диаграммы анализируемой ИС, если это необходимо, или, наоборот, часть процессов ИС может быть вынесена за пределы диаграммы и представлена как внешняя сущность. Внешняя сущность обозначается квадратом, расположенным как бы "над" диаграммой и бросающим на нее тень, для того, чтобы можно было выделить этот символ среди других обозначений.
• Process ( Процессы , Системы и подсистемы) - при построении модели сложной ИС она может быть представлена в самом общем виде на так называемой контекстной диаграмме в виде одной системы как единого целого, либо может быть декомпозирована на ряд подсистем. Процесс представляет собой преобразование входных потоков данных в выходные в соответствии с определенным алгоритмом. Физически процесс может быть реализован различными способами: это может быть подразделение организации (отдел), выполняющее обработку входных документов и выпуск отчетов, программа, аппаратно реализованное логическое устройство и т.д.
• Datastore ( Хранилище данных ) представляет собой абстрактное устройство для хранения информации, которую можно в любой момент поместить в накопитель и через некоторое время извлечь, причем способы помещения и извлечения могут быть любыми.
• Dataflow ( Поток данны х) определяет информацию, передаваемую через некоторое соединение от источника к приемнику. Реальный поток данных может быть информацией, передаваемой по кабелю между двумя устройствами, пересылаемыми по почте письмами, магнитными лентами или дискетами, переносимыми с одного компьютера на другой и т.д. и т.п.

Аналогично IDEF0, для удобства DF-диаграммы разделяют на уровни.

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

На 1 уровне выделяются основные компоненты системы. С 0-го уровня сюда переносятся все потоки данных. Диаграмма дополняется потоками данных внутри системы и хранилищами данных.

Внешние сущности:

• объекты взаимодействующий с системой, но не относящийся к ней (поставщики и потребители информации, те для кого информационная система строится и кто задействован при работе с ней);
• должны быть отображены на уровнях 0 и 1 DF-диаграммы;
• не должны присутствовать на уровнях 2(3, …) диаграммы;
• должны иметь содержательное имя;
• могут иметь дубликаты на диаграмме.

Процессы:

• описывают действия с информацией;
• должны быть представлены на всех уровнях диаграммы:
• Уровень 0 - один процесс, описывающий систему;
• Уровень 1+ -рекомендуется размещать не более 7 процессов;
• дубликаты (процессы с одинаковым именем или содержанием) не допускаются.

Хранилища данных:

• указывает вид информации которые хранятся в системе (товары, накладные, персонал);
• не отображаются на уровне 0;
• все хранилища данных, которые есть в ИС должны быть указаны на уровне 1.

Потоки данных:

• отображают направление передачи данных;
• отображаются на всех уровнях диаграммы;
• должны иметь содержательное имя.

Алгоритм построения диаграммы

1. Определите входящие запросы или события, на которые должна реагировать система. Определите что система отвечает на них.
2. Определите кто формирует эти запросы и получает ответ (это внешние сущности).
3. Постройте диаграмму уровня 0 - на ней отображены только внешние сущности и главный процесс системы.
4. Постройте диаграмму уровня 1 - на ней должны быть отображены все внешние сущности, все хранилища данных, главные процессы и потоки информации между ними.
5. Проанализируйте и оптимизируйте диаграмму уровня 1. Рекомендуется на одном уровне диаграммы размещать 7±2 процесса.
6. Если требуется, детализируйте отдельные процессы на уровне 2(3,4 …).

Типичные ошибки построения DF-диаграмм

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

На DFD диаграмме не отображаются точки начала и окончания, решения(if) и циклы.

Внешние сущности не могут быть связаны потоками информации (это выходит за рамки моделируемой системы)

Внешние сущности не могут напрямую обращаться к хранилищам данных

Хранилище данных не может напрямую обращаться к другому хранилищу. Между ними должен быть процесс.

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

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

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

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

Давайте построим DF-диаграмму для информационной системы риэлтерской конторы.

Фирма функционирует следующим образом:

• Заказчики могут оставлять заявки на аренду.
• Менеджер подыскивает надвижимость и готовит проект договора.
• Клиент подписывает договор.

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

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

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

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

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

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

Наличие на диаграмме процесса "Подготовить договор аренды" - это следствие того, что "черновик" договора аренды готовит клерк, а менеджер принимает решение о заключении договора. Это повышает эффективность работы фирмы в целом.

Роль методологий в анализе моделируемого объекта (Выводы)

В результате анализа моделируемого информационной системой объекта на основе построения IDEF0 и DFD-диаграмм:

Определяют главную функцию проектируемой системы. Например, "сопровождать аренду недвижи­мости".

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

Например, так:

1. заключать договора аренды;
2. сопровождать хранение информации об объектах недвижимости.

Определяют обрабатываемые бизнес процессами информационными потоки . Например, так: "отправка договора менеджеру".

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

Как видим назначение концептуальной модели объекта:

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

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

Использование UML для проектирования систем

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

Каждая такая диаграмма или, как ее обычно называют, каждый Use case - это описание сценария поведения, которому следуют действующие лица (Actors).

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

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

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

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

State Maсhine diagram (диаграммы состояний)

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

Statechart diagram (диаграмма состояний)

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

Activity diagram (диаграммы активности)

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

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

Interaction diagram (диаграммы взаимодействия)

Этот тип диаграмм включает в себя диаграммы Sequence diagram (диаграммы последовательностей действий) и Collaboration diagram (диаграммы сотрудничества). Эти диаграммы позволяют с разных точек зрения рассмотреть взаимодействие объектов в создаваемой системе.

Sequence diagram (диаграммы последовательностей действий)

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

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

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

Collaboration diagram (диаграммы сотрудничества)

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

Class diagram (диаграммы классов)

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

Значки диаграммы позволяют отображать сложную иерархию систем, взаимосвязи классов (Classes) и интерфейсов (Interfaces). Данный тип диаграмм противоположен по содержанию диаграмме Collaboration, на котором отображаются объекты системы. Классы имеют различные нотации. В нотации, предложенной Г. Бучем классы изображаются в виде чего-то нечеткого, похожего на облако. Таким образом Г.Буч пытается показать, что класс - это лишь шаблон, по которому в дальнейшем будет создан конкретный объект.

Component diagram (диаграммы компонентов)

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

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

Федеральное агентство по образованию
Государственное образовательное учреждение высшего профессионального образования
«ПОВОЛЖСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ СЕРВИСА»

Кафедра «Прикладная информатика в экономике»

КУРСОВОЙ ПРОЕКТ

по дисциплине «Бизнесреинжиниринг»

на тему: «Проектирование бизнес-процессов предприятия сферы обслуживания (предприятие по оказанию услуг в сфере проката автомобилей)»

Выполнил студент

Группы И-402

Юзманов Р.М.

Проверила

Филиппова О.А.

Тольятти, 2010
СОДЕРЖАНИЕ

ВВЕДЕНИЕ...………………………………………………… ……………………………...…..3
1. АНАЛИТИЧЕСКИЙ РАЗДЕЛ……………………………………………….…………… ….4
1.1. Основные направления деятельности предприятия………………………………………4
1.2 Структурно-функциональное моделирование бизнес-процессов предприятия…………5
1.3 Недостатки существующей структурно-функциональной модели бизнес-процессов предприятия………………………………………………… …………………………………..14
2. ПРОЕКТНЫЙ РАЗДЕЛ……………………………………………………………… ...……16
2.1 Автоматизация структурно-функциональных моделей бизнес-процессов предприятия…… ……………………………………………………………………………… ..16
3. ПРОЕКТ ИНФОРМАЦИОННОЙ СИСТЕМЫ…………………………………………….31
3.1 Модель данных ИС………………………………………………………………………… 31
3.2 Интерфейс пользователя……………………………………………… …………………...33
4. ЭКОНОМИЧЕСКИЙ РАЗДЕЛ……………………………………………………………. ..38
4.1 Анализ затрат по проекту…………………………………………………………… ……..38
4.2 Расчет основных экономических показателей…………… ……………………………... 41
ЗАКЛЮЧЕНИЕ.………………………………………………… ………..…………………….44
БИБЛИОГРАФИЧЕСКИЙ СПИСОК…...………………………………….……………… …45

ВВЕДЕНИЕ

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

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

1. АНАЛИТИЧЕСКИЙ РАЗДЕЛ

1.1 Основные направления деятельности предприятия

Предприятие ООО «VolgaRent», деятельность которого планируется автоматизировать, занимается прокатом авто. Важнейшим звеном в данной деятельности является спецоборудование. В зависимости от того, насколько работа персонала автоматизирована, можно судить об эффективности его работы. Каждый день организация осуществляет прием и выдачу автомобилей разных марок, окрасов, и съёмной стоимости.
Персонал заполняет БД клиентов (ФИО, адрес, тел), если его еще там нет. После этого персонал осуществляет поиск интересующего автомобиля в БД. После того как клиент получает интересующий его авто, редактируется информация о выданных автомобилях. После возвращения клиентом взятого авто, вновь редактируется БД выданных авто и данные о взятых клиентом автомобиле.
Ниже (см. рис. 1.1) представлена схема организационной структуры нашей предметной области.

Рис. 1.1 Организационная структура

Рис. 1.2 Организационная структура автоматизируемого подразделения

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

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

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

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

Для проведения анализа и реорганизации бизнес-процессов воспользуемся CASE-средством. Bpwin поддерживает методологии IDEF0 (функциональная модель), IDEF3 (WorkFlow Diagram) и DFD (DataFlow Diagram).
Функциональная модель предназначена для описания существующих бизнес-процессов на предприятии (так называемая модель AS-IS) и идеального положения вещей - того, к чему нужно стремиться (модель ТО-ВЕ). Для начала построим функциональные диаграммы бизнес-процессов, которые предстоит улучшить, т.е. модели AS-IS:
На рисунках 1.3 и 1.4 представлены контекстная диаграмма и диаграмма декомпозиции процесса «Выбор авто». На вход поступает информация о финансовых возможностях клиента, и текущий модельный ряд автомобилей. С помощью любезного персонала клиенту предоставляется возможность выбрать понравившийся автомобиль, и тем самым на выходе вы получаем выбранный авто. За управление процессами отвечают государственные стандарты. Механизмами служат клиент, который выбирает авто, и персонал, который обслуживает клиента.

Рис. 1.3 Контекстная диаграмма функциональной модели процесса «Выбор авто»

Рис. 1.4 Диаграмма декомпозиции процесса «Выбор авто»

Рис. 1.5 Контекстная диаграмма функциональной модели процесса «Выдача авто»

Рис. 1.6 Диаграмма декомпозиции процесса «Выдача авто»

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

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

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

Рис. 1.10 Диаграмма декомпозиции процесса «Оплата за ренту»

Рисунки 1.5 и 1.6 отображают процесс «Выдача авто». Входом является модельный ряд и сведения о клиенте. На выходе клиенту выдаётся автомобиль. Ресурсной стрелкой является обслуживающий персонал, который и выдаёт клиенту авто. Управляют процессами внутренние правила предприятия «VolgaRent».
На рисунках 1.7 и 1.8 представлены диаграммы процесса «Оформление квитанции». Входным материалом является заявка клиента, которая передаётся обслуживающему персоналу, который в свою очередь обрабатывает заявку при помощи ИС, и на выходе клиент получает чек, который обязан оплатить и квитанцию об оплате.
Завершающим процессом является «Оплата за ренту». Контекстная диаграмма и диаграмма декомпозиции этого процесса отображены на рисунках 1.9 и 1.10. Входная стрелка – это заявка и непосредственно деньги от клиента, которые передаются обслуживающему персоналу. Персонал, обрабатывает полученную информацию, производит пересчёт средств, и на выходе клиент получает чек об оплате за авто. За управление в данном процессе отвечает законодательство РФ.

1.3 Недостатки существующей структурно-функциональной модели бизнес-процессов предприятия

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

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

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

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

Как видно из описания структуры, все документы-списки необходимы для подсчета выручки. Таким образом, уже на данном этапе видно, насколько рационально использовать базу данных и приложение по работе с ней. Во-первых, сокращается объем информации, а данные для подсчета прибыли можно получить путем запросов, во-вторых, заметно сократится время на формирование отчета.
До создания этой информационной системы учёт арендуемых автомобилей в компании «VolgaRent» велся в письменном виде в регистре заявок. А также данные заполнялись в электронные таблицы Excel. Все данные о клиентах, услугах, мастерах хранились в табличном виде.
Таким образом, учет арендуемых авто в фирме «VolgaRent» не был автоматизирован. Как таковой БД не имелось и это существенный недостаток. Данные необходимо было связать и систематизировать. Разработанное программное приложение призвано решить эту проблему. Так же появилась возможность печати отчетов. Созданная ИС существенно сокращает бумажную работу нашей организации и минимизирует физический труд людей занимающихся ведением данной документации
Далее же запишем всю информацию в систематизированной форме. При создании базы данных, эту информацию можно будет разделить на конкретные таблицы.

ФИО.
Адрес.
Телефон.
Марка автомобиля
Цена аренды.
Дата аренды.
Срок аренды.

2. ПРОЕКТНЫЙ РАЗДЕЛ

2.1 Автоматизация структурно- функциональных моделей бизнес-процессов предприятия

Найденные в модели AS-IS недостатки можно исправить при создании модели ТО-ВЕ (как будет) - модели новой организации бизнес-процессов. Технология проектирования ИС подразумевает сначала создание модели AS-IS, ее анализ и улучшение бизнес-процессов, то есть создание модели ТО-ВЕ, и только на основе модели ТО-ВЕ строится модель данных, прототип и затем окончательный вариант ИС.
Как правило, данная модель создается на основе AS-IS, с устранением недостатков в существующей организации бизнес-процессов, а так же с их совершенствованием и оптимизацией. Это достигается за счет устранения выявленных на базе анализа AS-IS узких мест.
В традиционном реинжиниринге именно на основе модели TO-BE рекомендуется производить автоматизацию бизнес-процессов и проектировать КИС. Подразумевается, что это позволяет существенно снизить риск проявления автоматизации как исключительно источника затрат из-за автоматизации несовершенных процессов.
Построим функциональные диаграммы ТО-ВЕ бизнес-процессов, которые мы изменили.
На рисунках 2.1 и 2.2 представлены контекстная диаграмма и диаграмма декомпозиции процесса «Выбор авто». На вход поступает информация о финансовых возможностях клиента, и текущий модельный ряд автомобилей. С помощью любезного персонала клиенту предоставляется возможность выбрать понравившийся автомобиль, и тем самым на выходе вы получаем выбранный авто. За управление процессами отвечают государственные стандарты. Механизмами служат клиент, который выбирает авто, и персонал, который обслуживает клиента. В результате автоматизации предприятия произошло внедрение ИС в данный процесс. ИС позволила выбрать авто из каталога БД.
Рисунки 2.3 и 2.4 отображают процесс «Выдача авто». Входом является модельный ряд и сведения о клиенте. На выходе клиенту выдаётся автомобиль. Ресурсной стрелкой является обслуживающий персонал, который и выдаёт клиенту авто. Управляют процессами внутренние правила предприятия «VolgaRent». В результате процесса «Выдача авто» выдаётся доверенность клиенту на управление выбранным транспортным средством.

Рис. 2.1 Контекстная диаграмма функциональной модели процесса «Выбор авто» после автоматизации

Рис 2.2 Диаграмма декомпозиции процесса «Выбор авто» после автоматизации

Рис. 2.3 Контекстная диаграмма функциональной модели процесса «Выдача авто» после автоматизации

Рис 2.4 Диаграмма декомпозиции процесса «Выдача авто» после автоматизации

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

Рис 2.6 Диаграмма декомпозиции процесса «Оформление квитанции» после автоматизации

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

Рис 2.8 Диаграмма декомпозиции процесса «Оплата за ренту» после автоматизации

На рисунках 2.5 и 2.6 представлены диаграммы процесса «Оформление квитанции». Входным материалом является заявка клиента, которая передаётся обслуживающему персоналу, который в свою очередь обрабатывает заявку при помощи ИС, и на выходе клиент получает чек, который обязан оплатить и квитанцию об оплате. В результате поправок в законодательстве РФ в процессе «Оформление квитанции», формируется квитанция и выдаётся чек клиенту, благодаря ИС.
Завершающим процессом является «Оплата за ренту». Контекстная диаграмма и диаграмма декомпозиции этого процесса отображены на рисунках 2.7 и 2.8
Входная стрелка – это заявка и непосредственно деньги от клиента, которые передаются обслуживающему персоналу. Персонал, обрабатывает полученную информацию, производит пересчёт средств, и на выходе клиент получает чек об оплате за авто. За управление в данном процессе отвечает законодательство РФ. Вследствие автоматизации данного процесса появилась возможность выдачи гарантии на арендуемое авто.

3. ПРОЕКТ ИНФОРМАЦИОННОЙ СИСТЕМЫ

3.1 Модель данных ИС

Процесс моделирования в Erwin базируется на методологии проектирования реляционных баз данных IDEF1X.
Для проектирования базы данных проектов использовалась модель «сущность – связь» (Entity – Relationship model, или ER – модель). ER – модель представляет собой высокоуровневую концептуальную модель данных, цель которой - упрощение задачи проектирования баз данных. Данная модель данных включает в себя набор концепций, которые описывают структуру базы данных и связанные с ней транзакции обновления и выборки данных. Следует подчеркнуть, что концептуальная модель данных не зависит от конкретной СУБД или аппаратной платформы, которая используется для физической реализации базы данных.
Основными элементами IDEF1X являются сущности, атрибуты и связи.
Каждая сущность является множеством подобных индивидуальных объектов, называемых экземплярами. Каждый экземпляр индивидуален и должен отличаться от всех остальных экземпляров. Атрибут выражает определенное свойство объекта. Атрибут или группа атрибутов, которые идентифицируют сущность, называется первичным ключом. С точки зрения БД (физическая модель) сущности соответствует таблица, экземпляру сущности - строка в таблице, а атрибуту - колонка таблицы.
Сущности изображаются в виде прямоугольников. Имя сущности показывается над прямоугольником, изображающим сущность, список атрибутов сущности - внутри прямоугольника. Список разделен горизонтальной чертой, выше которой расположены атрибуты первичного ключа, ниже – не ключевые атрибуты.
В IDEF1X также различают зависимые и независимые сущности. Тип сущности определяется ее связью с другими сущностями. Зависимая сущность изображается прямоугольником со скругленными углами.
Результатом нормализации является модель данных, которую легко поддерживать, не содержащая неопределенностей в данных и повторений данных.
После выделения информационных объектов необходимо объединить их в одну систему, то есть установить связи между ними.
Объект «Марки» связан с полем «Автомобили» связью «один ко многим». Этот тип связи применяется, когда одному значению вспомогательного объекта соответствует много значений главного. По аналогии с этим устанавливаются связи «один ко многим» у остальных информационных объектов «Персонал», «Клиенты», «Выдача авто», с соответствующими полями связанных между собой таблиц. Схема логической модели данных представлена на рисунке 3.1.

Рис. 3.1 Логическая модель базы данных.

3.2 Интерфейс пользователя

Рис. 3.2 Форма «Прокат автомобилей»

Форма «Прокат автомобилей» - это начальная форма приложения, с помощью неё осуществляется возможность доступа к формам: «Автомобили», «Комплектация», «Клиенты», «Персонал», «Выдача автомобилей».

Рис. 3.3 Форма «Автомобили»

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

Рис. 3.4 Форма «Комплектация»
Через форму «Комплектация» осуществляется редактирование данных об имеющихся данных. Редактирование данных осуществляется при помощи кнопок: «Добавить», «Удалить», «Переместить», «Откат действия». На данной форме предусмотрена возможность сортировки, поиска и фильтрации данных по выбранным параметрам.

Рис. 3.5 Форма «Клиенты»

Через форму «Клиенты» осуществляется редактирование данных о клиентах. Редактирование данных осуществляется при помощи кнопок: «Добавить», «Удалить», «Переместить», «Откат действия». На данной форме предусмотрена возможность сортировки, поиска и фильтрации данных по выбранным параметрам.

Рис. 3.7 Форма «Персонал»
Через форму «Персонал» осуществляется редактирование данных о обслуживающем персонале. Редактирование данных осуществляется при помощи кнопок: «Добавить», «Удалить», «Переместить», «Откат действия». На данной форме предусмотрена возможность сортировки, поиска и фильтрации данных по выбранным параметрам.

Рис. 3.8 Форма «Выдача»

Форма «Выдача автомобилей» - это главная форма приложения, в которую заносятся данные о менеджере, отдавшем автомобиль в ренту, клиенте, который этот автомобиль взял в прокат, об арендуемом автомобиле, и о дате аренды.
Редактирование данных осуществляется при помощи кнопок: «Добавить», «Удалить», «Переместить», «Откат действия», «Отчёт». На данной форме предусмотрена возможность сортировки, поиска и фильтрации данных по выбранным параметрам.
При нажатии кнопки «запрос по дате», отбираются сведения о клиенте, менеджере и рентуемом автомобиле, который был взят в прокат в этот день.
При нажатии на кнопку «Отчет» формируется отчет по данным о клиентах, представленный на рис. 3.9
.

Рис. 3.9 Отчет по выдачам автомобилей

4. ЭКОНОМИЧЕСКИЙ РАЗДЕЛ

4.1 Анализ затрат по проекту

Затраты на ресурсы процесса «Выбор авто»:
Затраты на рекламу – 5000 р.
Оплата персоналу – 26000 р.
Создание каталога – 2000 р

Рис. 4.1 Диаграмма дерево узлов процесса «Выбор авто»

Затраты на ресурсы процесса «Выдача авто»:
Зар.плата персоналу – 17500 р
Электроэнергия – 700 р

Рис. 4.2 Диаграмма дерево узлов процесса «Выдача авто»

Затраты на ресурсы процесса «Оформление квитанции»:
Зар.плата персоналу – 14700 р
Канцтовары – 500 р
Электроэнергия – 300 р

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

Дата

08 Авг 2013

Тема: Знакомство с CASE-средством разработки информационных систем BPwin

Цель работы : познакомиться с CASE-средством BPwin фирмы Computer Associates, научиться строить модель в методологии IDEF0 .

Порядок работы:
1. Ознакомиться с принципами построения модели в BPwin.
2. Ознакомиться с основной панелью инструментов.
3. Ознакомиться с палитрой инструментов IDEF0.
4. Научиться строить контекстную диаграмму, определять цель, точку зрения, границы модели. Освоить работу с закладками General, Purpose, Definition, Status, Numbering, Display.
5. Научиться строить декомпозирующие диаграммы.
6. Выполнить практическое задание.
7. Ответить на контрольные вопросы.

1. Краткая информация об CASE-средстве BPwin

BPwin - CASE-средство верхнего уровня, помогающее проводить анализ и реорганизацию бизнес-процессов. Поддерживается методология IDEF0 (функциональная модель), IDEF3 (Work Flow Diagram), DFD (Data Flow Diagram). Функциональная модель предназначена для описания существующих бизнес-процессов на предприятии (так называемая модель AS-IS) и идеального положения вещей – того, к чему надо стремиться (модель TO-BE).
Процесс построения информационной модели в BPwin состоит из следующих шагов:
построение контекстной диаграммы;
проводится функциональная декомпозиция;
после каждого сеанса декомпозиции проводится сеанс экспертизы.
На основе модели BPwin можно построить модель данных. В программе поддерживается связь с ERwin.

2. Инструментальная среда BPwin

При запуске BPwin по умолчанию появляется основная панель инструментов (рис.1), палитра инструментов и навигатор модели Model Explorer (рис.2).

Рис.1 Внешний вид панели управления BPwin4.0

Панель инструментов представлена следующими кнопками (слева направо):
создать модель (пункт меню File/New);
открыть модель (пункт меню File/Open);
сохранить модель (пункт меню File/Save);
напечатать модель (пункт меню File/Print);
выбор масштаба (View/Zoom);
уменьшить модель (View/Zoom);
увеличить модель (View/Zoom);
проверить правописание (Tools/Spelling);
включение и выключение навигатора модели (View/Model Explorer);
включение и выключение дополнительной панели инструментов работы с Model Mart (Model Mart).

Рис.2 Внешний вид окна навигатора модели Model Explorer

При создании новой модели возникает диалог, в котором следует указать, будет ли модель создаваться заново, или она будет открыта из файла либо из репозитария Model Mart. Также необходимо внести имя модели и выбрать методологию, в которой будет построена модель (рис.3).

Рис.3 Диалог создания модели.

BPwin поддерживает три методологии моделирования:
функциональное моделирование (IDEFO);
описание бизнес-процес¬сов (IDEF3);
диаграммы потоков дан¬ных (DFD).
В зависимости от выбранной методологии программой автомати¬чески подбирается нужная панель инструментов BPwin Toolbox. В BPwin существует три разных панели инструментов - по числу поддерживаемых програм¬мой методологий. На рис.4 представлена палитра для IDEF0.

Рис.4 Палитра инструментов IDEF0.

Вы можете показывать или скрывать панель инструментов, используя функцию «View» на панели меню.

3. Построение модели IDEF0. Контекстная диаграмма
Функциональное моделирование является технологией анализа системы в целом как набора связанных между собой действий или функций. Действия системы анализируются независимо от объектов, которые обеспечивают их исполнение. Моделировать деловой про¬цесс можно исходя из различных перспектив и временных рамок. На¬пример, вы можете моделировать процесс заказа услуг клиентом так, как вы видите его в идеале, а не так, как это происходит в настоящее время. Также можно абстрагироваться от проблем физической реализации модели.
Процесс моделирования какой-либо системы в IDEF0 начинается с определения КОНТЕКСТА, т.е. наиболее абстрактного уровня описания системы в целом. В контекст входит определение субъекта моделирования, цели и точки зрения на модель.
Под субъектом понимается сама система, при этом необходимо точно установить ГРАНИЦЫ СИСТЕМЫ, определить, что входит в систему, а что лежит за ее пределами. То есть необходимо решить, что будет рассматриваться как компоненты системы, а что как внешнее воздействие. Другими словами, первоначально необходимо определить область (Scope) моделирования.
Наименование функции самого высокого уровня опи¬сывает систему непосредственно и, как правило, состоит из одного активного глагола в сочетании с обобщающим существительным, ко¬торое разъясняет цель деятельности с точки зрения самого общего взгляда на систему. Например «Изготовить изделие».
Формулировка цели моделирования (Purpose) позволяет команде аналитиков сфокусировать усилия в нужном направлении. Модель не может быть построена без четко сформулированной цели.
Точку зрения можно представить как взгляд человека, который видит систему в нужном для моделирования аспекте. Точка зрения должна соответствовать цели моделирования. Очевидно, что описание работы предприятия с точки зрения финансиста и технолога будет выглядеть совершенно по-разному, поэтому в течение моделирования важно оставаться на выбранной точке зрения.
Для определения контекста модели в BPwin следует выбрать пункт меню Model/Model Properties. В закладке General указывается наименование и сведения об авторе модели, в закладку Purpose следует внести цель и точку зрения, а в закладку Definition – определение модели и описание области (рис.5).
Для создания контекстной диаграммы необходимо сначала соз¬дать новую модель, выбрав пункт «New» в меню «File». В появившем¬ся диалоге необходимо набрать имя модели и выбрать ее тип. Этот диалог также отображается при запуске BPwin.
После создания модели можно задать ее параметры. Кроме вышеперечисленных свойств модели (Model Properties) можно задать состоя¬ние, в котором находится модель, например «в работе» или «для публикации» (закладка Status).

Рис.5 Диалог задания свойств модели.

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

Рис.6 Пример контекстной диаграммы.

4. Декомпозиция
Декомпозиционное разложение модели используется в моделиро¬вании бизнес-процессов, для того чтобы дать более подробное описа¬ние блоков. Каждый из них может в свою очередь быть де¬композированным. При каждой декомпозиции блока создается новая диаграмма. Число декомпозиций не ограничено и полностью зависит от уровня сложности, который необходимо показать в модели.
Чтобы выполнить декомпозицию функции, необходимо щелкнуть по кнопке . Возникает диалог Activity Box Count (рис.7), в котором следует указать нотацию новой диаграммы и количество блоков на ней. Для IDEF0 рекомендуется 3-6 блоков.

Рис.7 Диалог Activity Box Count.

BPwin создает новую диаграмму, которая является диаграммой разложения родительской диаграммы. Заметьте, что новые действия не связаны между собой и не поименованы - это следующая задача. Необходимо задать взаимодействие между блоками и «привязать» к но¬вым блокам стрелки, которые автоматически унаследованы от роди¬тельской диаграммы (рис.8).

Рис.8 Пример несвязанных стрелок.

Имя блока и другие его свойства вводятся в закладке «Name» спи¬ска свойств блока. Для вывода свойств блока на экран достаточно два¬жды щелкнуть мышью на блоке.
Следующим шагом при создании диаграммы должно быть соеди¬нение всех использованных на диаграмме блоков с помощью стрелок, представляющих входы, результаты работы, средства управления и механизмы. Для этого достаточно соединить исходящую точку стрел¬ки с точкой ее окончания. Окончанием стрелки может быть как одна из сторон функциональных блоков, так и граница диаграммы. BPwin автоматически выделяет допустимые окончания для создаваемых стрелок. Для рисования стрелки пользуются инструментом из комплекта инструментов. Задание имени стрелки производится в закладке «Name» диалога свойств стрелок. Для вызова этого диалога достаточно дважды щелк¬нуть мышью на нужной стрелке.
Если количества блоков на диаграмме окажется недостаточным, существует возможность добавления на нее новых блоков с использованием кнопки панели инструментов. Для добавления блока сле¬дует щелкнуть на этом инструменте, а затем - на диаграмме в том месте, где необходимо расположить новый блок. После того как до¬полнительный блок создан, вы можете связать его стрелками с други¬ми блоками и задать его название и другие свойства.
Обра¬тите внимание на рис.9. Если действие не было декомпозирова¬но, в верхнем левом углу блока будет по¬являться символ «листа». После деком-позиции данного блока символ «листа» исчезнет.

Рис.9 Пример недекомпозированного блока.

Нумерация блоков производится автоматически при их создании. Номера могут быть относительными или постоянными, они отражают иерархическое положение блока в пределах модели. Вы можете управлять нумерацией блоков на диаграмме, используя закладку «Numbering» диалога ввода свойств модели (рис.5).
Перемещение любых объектов на диаграмме осуществляется с по¬мощью их «захвата» мышью и перемещения в новое место. При пере¬мещении блоков одновременно перемещаются и связанные с ними стрелки. Функциональные блоки могут также быть перемещены меж¬ду диаграммами с использованием команд «Cut/Paste» из меню «Edit». При изменении взаимного расположения блоков могут меняться и их но¬мера.
Для идентификации граничных стрелок предназначены ICOM-коды. Код содержит префикс, соответствующий типу стрелки (Input, Control, Output, Mechanism) и порядковый номер. BPwin вносит ICOM-коды автоматически. Для отображения ICOM-кодов следует включить опцию ICOM codes на закладке Display диалога свойств.
Практическое задание:
1. Согласно варианту, создайте контекстную диаграмму. Определите цель, точку зрения модели. Опишите свойства в соответствующих закладках диалога Model Properties.
2. Задайте входы, выходы, механизмы и управление.
3. Создайте декомпозицию контекстной диаграммы, состоящую из 2-3 блоков. Задайте автоматическую нумерацию блоков и ICOM-кодов.
4. Установите связи между блоками. Задайте имена дуг.
5. Сохраните проект в отдельный файл.

Контрольные вопросы:
1. Для чего используется методология IDEF0.
2. Объясните необходимость задания цели и точки зрения модели?
3. Перечислите и расскажите назначения кнопок на панели инструментов.
4. Перечислите этапы декомпозиции блока.
5. Расскажите, каким образом на диаграмму добавить блок, дугу.
6. Дайте определение ICOM-кодов.
7. Для чего используются закладки General, Purpose, Definition, Status, Numbering, Display в диалоге Model Properties.
Варианты к практическим работам
Вариант 1
Система должна описывать порядок подготовки к экзамену, предполагающий получение отличной оценки.
Вариант 2
Система должна описывать порядок выполнения практической работы по дисциплине «Проектирование ИС».
Вариант 3
Система должна описывать порядок получения водительских прав.
Вариант 4
Система должна описывать порядок организации городского спортивного соревнования.
Вариант 5
Система должна описывать порядок организации общеинститутского студенческого мероприятия.
Вариант 6
Система составления учебного графика дисциплин, изучаемых на факультете
Вариант 7
Система должна описывать порядок поставок товара в систему розничных киосков.
Вариант 8
Система должна описывать порядок обработки заказов в службе быта.
Вариант 9
Система должна описывать работу одного из участков автосалона.
Вариант 10
Система должна описывать работу приемного покоя в больнице.
Вариант 11
Система должна описывать порядок приема заявки на поставку продукции на хлебокомбинате.
Вариант 12
Система должна описывать процесс поставки сезонных товаров в оптовой фирме.
Вариант 13
Система должна описывать процесс работы торгового отдела.
Вариант 15
Система учета в видеопрокате.
Вариант 16
Система учета проката на лыжной базе

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

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

Описание бизнес-процессов учета реализации автомобилей

Организация учета реализации автомобилей в автосалоне предполагает следующие бизнес-процессы:

1. Заказ автомобиля - после выбора автомобиля оформляется заказ на выбранную модель, подготавливается и отправляется запрос на завод - изготовитель, принимается предоплата и выдается квитанция о предоплате;

2. Прием автомобиля - принятие автомобиля на внутренний учет, проведение предпродажной подготовки и диагностики автомобиля, оповещение покупателя;

3. Реализация автомобиля - осмотр автомобиля покупателем, оформление договора купли-продажи;

4. Регистрация оплаты;

5. Формирование отчетных документов:

Формирование отчета «Прайс-лист»;

Формирование отчета «Анализ продаж»;

Формирование отчета «Заказы автомобилей»;

Формирование отчета «Состояние заказов».

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

1) Вход - материал или информация, которые используются или преобразуются блоком для получения результата (выхода);

2) Выход - результат выполнения функции (материал или информация);

3) Управление - условия, правила, стандарты, которые влияют на выполнение функции;

4) Механизм - ресурсы, с помощью которых выполняется работа;

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

На рисунках 1.3 (а, б, в) представлена IDEF0-модель «Информационная система автосалона», декомпозированная на 3 подуровня. На первом уровне блок А0 отвечает за реализацию автомобилей на основе следующих данных: заказ клиента и поставщик автомобилей. В результате на выходе получаем выполненный заказ. В качестве управления выступают: законодательство РФ, лицензия на продажу, каталог автомобилей. Механизм - Автосалон «AlongTheRoad».

Рисунок 1.3 (а)

При декомпозиции (рис. 1.3(б)) блок А0 разбивается на 4 блока: А1, А2, А3, А4. В блоке А1 формируется план закупок, руководствуясь входными данными заказ клиента, поставщик автомобилей. Блок А2 - Договор с поставщиками соединяется с блоком А3 - Формирование каталога автомобилей. Блок А4 отвечает за сбыт автомобилей, на выходе - выполненный заказ. Механизмами выступают: отдел по закупке автомобилей, юридический отдел, отдел рекламы и PR, отдел бухгалтерии, отдел сбыта автомобилей. Таким образом, выделили 4 подзадачи, произведя детализацию первого уровня.

Рисунок 1.3 (б) - Диаграмма декомпозиции

Перейдем на 3 уровень декомпозиции блока А4 - Сбыт автомобилей (рис. 1.3(в)). Диаграмма представлена тремя блоками: А41 - Принятие заявки, А42 - Оформление договора, А43 - Продажа автомобиля. В качестве управления остаются те же стандарты и правила, что и на первом уровне, на выходе получаем выполненный заказ.

Рисунок 1.3 (в) - Диаграмма декомпозиции

Исследование информационных потоков

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

Входные данные:

Сведения о клиентах;

Заказы клиентов;

Сведения об автомобилях;

Данные для формирования отчетов;

Сведения о поставщиках.

Выходные документы:

Отчет «Прайс-лист»;

План закупок;

Договор с поставщиками;

Каталог автомобилей;

Отчет «Анализ продаж»;

Отчет «Заказы автомобилей»;

Отчет «Состояние заказов».

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

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

– Потоки данных;

– Процессы (работы) преобразования входных потоков данных в выходные;

– Внешние сущности;

– Накопители данных (хранилища).

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

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