Курсовая работа содержит __ страниц, __ диаграмм, __ литературных источников. Основные слова и термины: Программная инженерия Диаграмма вариантов использования UML Временная диаграмма UML BPMN диаграмма Методология функционального моделирования IDEF0 ER-диаграмма Диаграмма состояний (Statechart Diagram) Содержание TOC \o "1-3" \h \z \u Введение5Глава 171.1. Стойка регистрации на рейс71.2. Стандартные стойки регистрации в аэропорту71.3 Стойки регистрации у входа…………………………………………………8Глава...

3566 Слова | 15 Стр.

Схема idef0

информационных систем» Тема: Метод функционального моделирования SADT. Методология IDEF0 . Цель работы: Изучить теоретические основы структурного подхода к проектированию информационных систем. Освоить принципы построения IDEF0 -диаграммы классов в программной среде Ramus Educational. Задачи: 1. Ознакомиться с теоретическими вопросами структурного подхода к проектированию информационных систем. 2. Изучить диаграмму IDEF0 (Integration Definition for Function Modeling) для предметной области «Гостиница»...

1859 Слова | 8 Стр.

Idef0 модель

Министерство образования Российской Федерации «IDEF0 модель» Выполнила: Проверил: Рязань 2010 Цель работы: изучить особенности работы с пакетом Design/IDEF, создать IDEF0 -модель. Задание: 1. Составить текстовое описание предметной области. 2. Разработать контекстную диаграмму. Определить точки зрения и границы модели. 3. Разработать диаграмму декомпозиции. 4. Составить отчёт по дугам. Редактировать отчёт. 1.Описание предметной области В качестве предметной области выберем...

1905 Слова | 8 Стр.

Диплом

РАЗРАБОТКА АИС ДЛЯ УЧЕТА СРЕДСТВ ВЫЧИСЛИТЕЛЬНОЙ ТЕХНИКИ АЭРОПОРТА , ПЛАНИРОВАНИЯ И ПРОГНОЗИРОВАНИЯ ПРОФИЛАКТИЧЕСКОГО ОБСЛУЖИВАНИЯ АННОТАЦИЯ В данной дипломной работе рассмотрена идея новой системы учета средств вычислительной техники в аэропорту , которая позволила бы сократить время прогнозирования и профилактического обслуживания и возможность быстрого, оперативного управления соответствующим документооборотом. Программное обеспечение реализовано с использованием среды разработки...

4472 Слова | 18 Стр.

Aris

определенных правил и требований к выпуску, эксплуатации и обслуживания изготовленной продукции. Требования и правила описания функционирования производства и систем, производственных процессов, распределения ресурсов строятся на использовании нотаций IDEF0 , IDEF1x, IDEF3, DPD, IDEF5 на основе методологии структурного анализа SADT. Использование структурного анализа к разработке функциональных моделей различных процессов и объектов позволяет более качественно не только оформить, но и воспринять...

3012 Слова | 13 Стр.

Раз ва

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

4639 Слова | 19 Стр.

Информационная система управления торгово-закупочной фирмы

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

4186 Слова | 17 Стр.

мпогпамего

Отчет по практике: Применение современных средств вычислительной техники на примере ОАО "Сахалинский аэропорт Оха" НЧОУ ВПО Южно-Сахалинский институт экономики, права и информатики ОТЧЕТ о прохождении производственной практики студентки III курса факультета информатики и вычислительной техники Моисеева Анастасия Александровна Открытое Акционерное Общество «Сахалинский аэропорт Оха» место прохождения практики с 21 июня 2010 года по 11 июля 2010 года период производственной практики...

2629 Слова | 11 Стр.

Реферат

разработки программного продукта 10 3.4 Оценка экономической эффективности разработки и использования ИС 15 4. Разработка проекта информационной системы с помощью структурного подхода 21 4.1. Моделирование данных с использованием стандарта IDEF0 21 4.2 Иерархия диаграмм 22 5. Разработка проекта информационной системы с помощью объектно-ориентированного подхода (UML-диаграммы) 23 5.1 Диаграмма вариантов использования 23 5.2 Диаграмма классов 28 5.3 Диаграмма состояний 31 5.4...

7189 Слова | 29 Стр.

себестоимости разработки программного продукта 10 3.4 Оценка экономической эффективности разработки и использования ИС 15 4. Разработка проекта информационной системы с помощью структурного подхода 21 4.1. Моделирование данных с использованием стандарта IDEF0 21 4.2 Иерархия диаграмм 22 5. Разработка проекта информационной системы с помощью объектно-ориентированного подхода (UML-диаграммы) 23 5.1 Диаграмма вариантов использования 23 5.2 Диаграмма классов 28 5.3 Диаграмма состояний 31 5.4 Диаграмма последовательности...

6968 Слова | 28 Стр.

Idfd 0

ФЕДЕРАЛЬНОЕ АГЕНСТВО ПО ОБРАЗОВАНИЮ ВОРОНЕЖСКАЯ ГОСУДАРСТВЕННАЯ ТЕХНОЛОГИЧЕСКАЯ АКАДЕМИЯ Задание и методические рекомендации к выполнению контрольной работы №2 по дисциплине «Проектирование информационных систем» на тему«Методологии IDEF0 , DFD» для студентов специальностей 230201, 080801 всех форм обучения Оглавление Методология IDEFO ......................................................................................................................3 Дополнение моделей процессов диаграммами...

930 Слова | 4 Стр.

Hgyggg

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

3654 Слова | 15 Стр.

Методические указания IDEFO

ОГЛАВЛЕНИЕ Введение 4 1 Теоретическая часть 5 1.1 Описание нотации IDEF0 5 1.2 Построение функциональных диаграмм в нотации IDEF0 7 1.3 Построение функциональных диаграмм в нотации IDEF3 20 2 Содержание практических работ 26 2.1 Контрольная работа 26 2.1.1 Задание № 1 26 2.1.2 Задание № 2 28 2.1.3 Задание № 3 30 2.1.4 Задание № 4 31 2.1.5 Задание № 5 35 2.1.6 Задание...

11066 Слова | 45 Стр.

Южно Сахалинск

Открытом акционерное общество «Сахалинский аэропорт Оха» в городе Оха Сахалинской области Местонахождение учреждения: 694490, Аэропорт Оха расположен в 9 км юго-западнее города Оха 1.Бизнес - направления организации Местом прохождения производственной практики являлась Федеральное агентство авиации Российской Федерации Открытом акционерное общество «Сахалинский аэропорт Оха» в городе Оха Сахалинской области. Основным видом деятельности в ОАО «Сахалинский аэропорт Оха» является деятельности по оказанию...

2469 Слова | 10 Стр.

Современные технологии объектно-ориентированного анализа и проектирования информационных систем

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

3757 Слова | 16 Стр.

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

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

3949 Слова | 16 Стр.

ПО для дистанционного обучения, тестирования и контроля

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

5501 Слова | 23 Стр.

Технологии реинжиниринга бизнес-процессов корпорации и внедрение корпоративных ИС

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

1625 Слова | 7 Стр.

. Основные методологии для проектирования ИС

управление, обратная связь и исполнители. IDEF0 - методология функционального моделирования (INTEGRATION DEFINITION FOR FUNCTION MODELING). Применяется для описания рабочих процессов (Work Flow). Разработана на основе SADT. По сути одно и тоже. DFD - методология моделирования потоков данных. Применяется для описания обмена данными между рабочими процессами. IDEF3 - методология моделирования потоков работ. Является более детальной по отношению к IDEF0 и DFD. Позволяет рассмотреть конкретный процесс...

4783 Слова | 20 Стр.

Построение АИС учета продаж в магазине книг

информационной системы будет произведено в методологиях IDEF0 с использованием системы бизнес-моделирования «Business studio». IDEF0 - методология функционального моделирования и графическая нотация, предназначенная для формализации и описания бизнес-процессов. Отличительной особенностью IDEF0 IDEF0 рассматриваются логические отношения между работами, а не их временна́я последовательность. Стандарт IDEF0 представляет организацию как набор модулей, здесь...

4017 Слова | 17 Стр.

Лабораторная работа по ИСРПО

Лабораторная работа №1 «Методология функционального моделирования» 1. Цель работы: Изучить методологии функционального моделирования IDEF0 и IDEF3. 2. Методические указания Лабораторная работа направлена на ознакомление с методологиями функционального моделирования IDEF0 и IDEF3, получение навыков по применению данных методологий для построения функциональных моделей на основании требований к информационной системе. Требования к результатам выполнения лабораторного практикума:  модель должна отражать...

8549 Слова | 35 Стр.

Реинжиниринг

Место прохождения практики: Федеральное агентство авиации Российской Федерации Открытом акционерное общество «аэропорт Оха» 1.Бизнес - направления организации Местом прохождения производственной практики являлась Федеральное агентство авиации Российской Федерации Открытом акционерное общество «аэропорт Оха». Основным видом деятельности в ОАО «аэропорт Оха» является деятельности по оказанию полного комплекса аэропортовых и наземных услуг по обслуживанию воздушных судов...

10689 Слова | 43 Стр.

Имитационное моделирование

экономике " Кафедра «Прикладная информатика в экономике» Курсовой проект по дисциплине: «Имитационное моделирование экономических процессов» на тему: «Анализ функционирования и оценка экономической эффективности взлетно-посадочных полос аэропорта на основе имитационного моделирования» Вариант 24-1 Работу выполнил студ. __________ Руководитель работы ___________ Допущен к защите _____ _______________ 2011. Защищен с оценкой ____________ _____ _______________...

2647 Слова | 11 Стр.

kursach

Yellow Cab (владелец Джон Херц). Впоследствии прокат автомобилей был выделен в отдельное направление и сегодня Hertz - одна из крупнейших автопрокатных компаний мира, имеющая более 5100 пунктов аренды. Ключевой составляющей успеха Hertz была аренда в аэропортах , в расчёте на деловых людей. После Второй мировой войны начинается подъём экономики, что положительно сказалось и на индустрии проката автомобилей. В 1945-1950 годах создаются такие известные компании, как Avis (основана Уоренном Эйвисом (Warren...

3162 Слова | 13 Стр.

Технология разработки программного обеспечения

функционального моделирования IDEF0 ........................ 149 5.2.1. Общие сведения о методологии SADT ............................................. 149 5.2.2. Основные понятия IDEF0 -модели..................................................... 150 5.2.3. Синтаксис IDEF0 -диаграмм............................................................... 152 5.2.4. Синтаксис IDEF0 -моделей................................................................. 159 5.2.5. Декомпозиция и её стратегии при IDEF0 -моделировании.....

57216 Слова | 229 Стр.

MPA_Kursovaya копия

оборот составил 290 тыс.тонн в год, а объемы закладки и хранения овощей и фруктов составили 90 тысяч тонн. В конце 1980-х в составе базы работали 36 специализированных магазинов «Овощи-фрукты». Имелся собственный грузовой терминал на территории аэропорта Шереметьево-2. Одновременно со строительством базы происходило развитие поселка Шереметьевский, который до 1973 года имел статус дачного. Уже в 1970-71гг. были сданы в эксплуатацию две пятиэтажки по адресу Южная 1а и Южная 2а. В одной из них...

4575 Слова | 19 Стр.

Стандарт idef0

Содержание Введение…………………………………………………………………………...3 1. История возникновения стандарта IDEF0 …………………………..........4 2. Концепции IDEF0 …………………………………………………………..6 3. Ключевые понятия IDEF0 -методологии………………………………...10 4. Преимущества методологии …………………………………………..…13 5. Перспективы развития методологии функционального моделирования…………………………………………………………….15 Заключение…………………………………………………………………….…16 Список литературы………………………………………………………………17 Введение Большинство...

3158 Слова | 13 Стр.

IDEF0

 1. Создание модели в стандарте IDEF0 IDEF0 - Function Modeling - методология функционального моделирования и графическая нотация, предназначенная для формализации и описания бизнес-процессов. Отличительной особенностью IDEF0 является её акцент на соподчинённость объектов. В IDEF0 рассматриваются логические отношения между работами, а не их временна́я последовательность (WorkFlow). Стандарт IDEF0 представляет организацию как набор модулей, здесь существует правило - наиболее важная функция...

1253 Слова | 6 Стр.

Idef0

5. Концепция IDEF0 Методология IDEF0 основана на следующих концептуальных положениях. 5.1 Модель Модель – искусственный объект, который представляет собой образ системы с ее компонентов. Модель разрабатывается для анализа и принятия решений о переработке системы, замене существующей, или создании абсолютно новой системы. Система – это есть совокупность взаимосвязанных частей, которые взаимодействуют друг с другом, а также выполняют определённую работу. Модель описывает то, что должно происходить...

1465 Слова | 6 Стр.

Методология структурного анализа и проектирования IDEF0

 Оглавление ВВЕДЕНИЕ 5 Глава 1. Понятие модели IDEF0 8 1.1 Основные определения (понятия) методологии и языка IDEF0 . 8 1.2 Концепция IDEF0 13 1.3 Синтаксис графического языка IDEF0 . 20 Глава 2. Разработка функциональных моделей 23 2.1 Методика разработки функциональных моделей среде IDEF0 . 23 2.2 Организация процесса функционального моделирования и управление проектом 25 2.3. Перспективы развития методологии функционального моделирования. 35 Заключение 38 СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ...

6110 Слова | 25 Стр.

Idef0 - методика работы с BPWin

Министерство науки и образования РФ ГОУ ВПО Тольяттинский государственный университет IDEF0 -технологии. Моделирование с помощью программного продукта BPWin Сборник методических рекомендаций Тольятти, 2008 За основу составления методических рекомендаций использован учебник Черемных СВ. и др. Моделирование и анализ систем. IDEF-технологии: практикум/ С.В.Черемных, И.О.Семенов, В.С.Ручкин. - М.: Финансы и статистика, 2002.- 192 с, ил. - (Прикладные информационные технологии)...

10059 Слова | 41 Стр.

Билеты ТРПО 2015 2016 1

преимущества и недостатки восходящего и нисходящего проектирования. Опишите принципы структурного подхода. Перечислите модели структурного подхода. 15) Дайте определение методу функционального моделирования SADT. Опишите принципы (правила) построения модели IDEF0 . Перечислите состав функциональной модели. 16) Диаграмма кооперации: назначение, элементы, пример программы. 17) Дайте определение методу функционального моделирования SADT. Приведите описание типов связей между функциями. Укажите правила именования...

3220 Слова | 13 Стр.

Методология idef0 и программный продукт BPWin

ФЕДЕРАЛЬНОЕ АГЕНСТВО ПО ОБРАЗОВАНИЮ Государственное образовательное учреждение высшего профессионального образования «Нижегородский государственный университет им. Н.И.Лобачевского» Факультет ВМК Кафедра ИАНИ Методология IDEF0 и программный продукт BPwin Учебно-методическое пособие г. Нижний Новгород, 2007 Введение Создание современных информационных систем представляет собой сложнейшую задачу, решение которой требует применения специальных методик и инструментов...

4909 Слова | 20 Стр.

idef0 создание моделирование

 Анализ Моделирование Проектирование Немного о курсе Методология IDEF0 Принципы построения модели IDEF0 На начальных этапах создания ИС необходимо понять, как работает организация, которую собираются автоматизировать. Никто в организации не знает, как она работает в той мере подробности, которая необходима для создания ИС. Руководитель хорошо знает работу в целом, но не в состоянии вникнуть в детали работы каждого рядового сотрудника. Рядовой сотрудник хорошо...

4102 Слова | 17 Стр.

Работа

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

5626 Слова | 23 Стр.

IDEF0

информационной безопасности» Тема: «Анализ процесса “Установка на служебном ПК офисного ПО” с использованием методологии структурного моделирования IDEF0 .» Выполнила: Студентка группы ИЭС-143-15 Наумова А. Ю. 2015 Содержание Введение «Точка зрения» 3 Основная часть 4 Глоссарий 8 Заключение 9 Список используемой литературы 10 Введение «Точка зрения» IDEF0 позволяет создать описание системы и ее внешнего окружения до определения окончательных требований к ней. Иными словами, с помощью данной методологии...

816 Слова | 4 Стр.

Технологии проектирвоания ИС

| |Case-средства для моделирования деловых процессов. Инструментальная среда BPwin. Принципы построения модели IDEF0 : контекстная диаграмма, | |субъект моделирования, цель и точка зрения. Диаграммы IDEF0 : контекстная диаграмма; диаграммы декомпозиции; диаграммы дерева узлов; диаграммы | |только для экспозиции (FEO). Работы (Activity). Стрелки (Arrow). Туннелирование стрелок. Нумерация работ и диаграмм...

16610 Слова | 67 Стр.

Анализ и проектирование информационной системы для предметной области «Аэропорт» с помощью CASE-технологий

17 1.4.2 Методика функционального моделирования в среде Ramus Educational 18 2. Реализация объектно-ориентированного приложения «Учет сетевого и компьютерного оборудования» 20 2.1 Разработка диаграмм методом функционального моделирования (SADT/IDEF0 ) 20 2.2 Разработка диаграмм потоков данных(DFD) 25 2.3 Разработка динамической модели объектно-ориентированных программных систем (Use Case-диаграмм) 32 2.4 Реализация объектно-ориентированного приложения в среде Visual Studio 2010 36 Заключение...

5556 Слова | 23 Стр.

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

«Моделирование систем» на тему: «Разработка модели предприятия тепличного хозяйства, используя методологии проектирования IDEF0 , DFD и IDEF3» 2009 Содержание 1. Цель работы 2. Теоретическое введение 3. Описание предметной области 4. Описание BPwin 4.1 Принцип построения модели IDEF0 4.2 Принцип построения модели DFD 4.3 Принцип построения модели IDEF3 5. Моделирование 5.1 Модель тепличного хозяйства 5.2 Математическая...

2405 Слова | 10 Стр.

Иформационное моделирование в ИС

Структурный и объектно-ориентированный подходы к моделированию информационных систем и процессов. При выполнении контрольной работы проверяются знания студента, полученные при изучении тем: – Структурный подход к моделированию ИС. Диаграммы SADT/IDEF0 , DFD, ERD. – Объектно-ориентированный подход к моделированию ИС. Диаграммы вариантов использования, диаграммы классов, диаграммы последовательности языка UML. Задание выполняется каждым студентом индивидуально в соответствии со своим вариантом...

10792 Слова | 44 Стр.

Моделирование IDEF0

Введение IDEF0 - Function Modeling - методология функционального моделирования и графическая нотация, предназначенная для формализации и описания бизнес-процессов. Отличительной особенностью IDEF0 является её акцент на соподчинённость объектов. В IDEF0 рассматривается логические отношения между работами, а не их временная последовательность (WorkFlow). Целью выполнения моей курсовой работы является разработка модели вымышленного агентства недвижимости в соответствии со стандартом IDEF0 . Агентство...

4043 Слова | 17 Стр.

Фячфяфя

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

9375 Слова | 38 Стр.

IDEF0 модель деятельности ВУЗа (модель+описание)

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

1190 Слова | 5 Стр.

Лекции по информационным системам

Функционально-ориентированные и объектно-ориентированные методологии описания предметной области 64 Синтетическая методика 72 7. Лекция: Моделирование бизнес-процессов средствами BPwin 73 Инструментальная среда BPwin 73 Построение модели IDEF0 74 Слияние и расщепление моделей 86 Создание отчетов в BPwin 87 8. Лекция: Моделирование бизнес-процессов средствами BPwin (часть 2) 88 Стоимостный анализ 88 Диаграммы потоков данных 91 Метод описания процессов IDEF3 93 ...

46107 Слова | 185 Стр.

Государственная Экономическая Политика

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

7320 Слова | 30 Стр.

моеапрш

ОБЛАСТИ ДЛЯ АВТОМАТИЗИРОВАННОЙ ИНФОРМАЦИОННОЙ СИСТЕМЫ. ПРОГРАММНАЯ РЕАЛИЗАЦИЯ АВТОМАТИЗИРОВАННОЙ ИНФОРМАЦИОННОЙ СИСТЕМЫ" Цели семестровой работы: - изучить принципы разработки и формализации предметной области в виде функциональной модели в нотации IDEF0 ; освоить приемы построения функциональной модели предметной области. - изучить принципы разработки и формализации предметной области в виде информационной модели IDEF1X для построения АИС; освоить приемы построения информационной модели предметной...

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

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

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

прокат автомобиль информационный база

Введение

Глоссарий проекта

1. Техническое задание на разработку

3. Функциональные модели информационной системы

4.1 Модели вариантов использования системы

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

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

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

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

4.6 Диаграмма состояния

5.1 Разработка интерфейса программного продукта

6. Тестирование программного продукта

7. Техническая документация

Заключение

Библиографический список

Приложения

Введение

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

· единый учет автомобилей в разрезе их характеристик (марка, пробег, свободен или арендован);

· поддержка учета поступления заявок;

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

· детализированный расчет стоимости конкретного заказа.

Глоссарий проекта

Таблица 1

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

1 . Техническое задание на разработку

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

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

В процессе проектирования было создано и утверждено техническое задание на разработку ИС "Проката автомобилей", которое приведено в приложении А.

2. Технико-экономические показатели

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

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

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

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

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

3. Функциональная модель информационной системы

Контекстная диаграмма ИС "Проката автомобилей" показана на рисунке 1. Функциональная диаграмма первого уровня приведена на рисунке 2. На рисунках 3 и 4 показаны функциональные диаграммы второго уровня для функций "Обслуживание клиентов и приём прочих поступлений" и "Оплата за аренду автомобилей".

Рисунок 1. Контекстная функциональная диаграмма информационной системы.

Рисунок 2. Функциональная диаграмма первого уровня информационной системы".

Рисунок 3. Функциональная диаграмма второго уровня в нотации DFD "Обслуживание клиентов и приём прочих поступлений".

Рисунок 4 . Функциональная диаграмма второго уровня в нотации DFD "Оплата за аренду автомобилей".

4. Объектно-ориентированное проектирование системы

4.1 Модели вариантов использования системы

В диаграмме вариантов использования используется сценарий взаимодействия между "Менеджером по прокату" и "Клиентом".

В ходе анализа для данного сценария было выделено 2 действующих лица: "Клиент" и "Менеджер по прокату". Для каждого из них были выделены прецеденты.

Полученная диаграмма вариантов использования ИС "Проката автомобилей" показана на рисунке 5.

Рисунок 5. Диаграмма вариантов использования информационной системы.

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

В ходе анализа для проектируемой информационной системы было выделено 5 классов: Менеджер по прокату, Центр проката, Клиенты, ИС Авто-Прокат, Автомобили проката. Для каждого из них были описаны атрибуты и операции.

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

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

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

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

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

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

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

Рисунок 8. Диаграмма последовательности.

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

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

Рисунок 9. Диаграмма кооперации.

5.6 Диаграмма состояния

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

Рисунок 10. Диаграмма состояния.

5. Создание информационной системы

5.1 Разработка интерфейса программного продукта

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

Рисунок 11. Стартовое состояние.

Если пользователь введёт неверный пароль, для него появится предупреждение (рисунок 12).

Рисунок 12. Ошибка при авторизации.

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

Рисунок 13. Рабочая форма пользователя.

Рисунок 14. Предупреждение при незаполненных полях.

Рисунок 15. Уведомление об успешном добавлении заказа.

Рисунок 16. Внешний вид заполненной базы данных.

5.2 Разработка программного кода системы

C# разрабатывался как язык программирования прикладного уровня для CLR и, как таковой, зависит, прежде всего, от возможностей самой CLR. Это касается, прежде всего, системы типов C#, которая отражает BCL.

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

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

6. Тестирование программного продукта

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

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

Пример тестирования программы.

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

7. Техническая документация

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

Заключение

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

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

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

На данный момент приложение ИС прокат автомобилей предоставляет ограниченный функционал и в дальнейшем может совершенствоваться, в качестве совершенствования можно добавить базы данных "Автомобили" и "Клиенты", а также добавить возможности подсчёта финансовых показателей "прокат автомобилей.

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

Библиографический список

1. Большаков А.А., Вешнева И.В., Мельников Л.А., Перова Л.Г. Новые методы математического моделирования динамики и управления формированием компетенций в процессе обучения в вузе. М.: Горячая линия-Телеком, 2014. 250 с. (ЭБС "Лань")

2. Губарев А.В. Информационное обеспечение системы менеджмента качества. М.: Горячая линия-Телеком, 2013. 132 с. (ЭБС "Лань")

3. Денисенко В.В. Компьютерное управление технологическими процессами, экспериментом, оборудованием. М.: Горячая линия-Телеком. 2013. 606 с. (ЭБС "Лань")

4. Дьяконов В.П. Новые информационные технологии. М.: СОЛОН_Пресс, 2008. 640 с. (ЭБС "Лань")

5. Кораблин М.А. Информатика поиска управленческих решений. М.: СОЛОН_Пресс, 2009. 192 с. (ЭБС "Лань")

6. Таганов А.И., Гильман Д.В. Методологические основы анализа и аттестации уровней зрелости процессов программных проектов в условиях нечеткости. М.: Горячая линия-Телеком. 2014. 168 с. (ЭБС "Лань")

7. Фельдман Я.А. Создаем информационные системы. М.: СОЛОН_Пресс, 2009. 120 с. (ЭБС "Лань")

8. Гагарина Л.Г., Виснадул Б.Д., Игошин А.В. "Основы технологии разработки программных продуктов" - М.: Форум: Инфра-М, 2006. 192 с.

9. Лаврищева Е.М. , Петрухин В.А. "Методы и средства инженерии программного обеспечения" - М.:МФТИ (ГУ), 2006. 305 с.

Приложения

Приложение А

Техническое задание на разработку ИС "Проката автомобилей"

Введение

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

1. Назначение программы

1.1. Наименование программы: "Разработка информационной системы прокат автомобилей"

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

2. Требования к программе

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

3. Технические требования

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

3.1.1. Состав выполняемых функций.

Единый учет автомобилей в разрезе их характеристик (марка, пробег, свободен или арендован);

Поддержка учета поступления заявок;

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

Детализированный расчет стоимости конкретного заказа.

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

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

4.1.1. Техническое задание

4.1.2. Программу и методики испытаний

4.1.3. Руководство оператора

5. Стадии и этапы разработки.

5.1, Стадии разработки. Разработка должна быть проведена в три стадии:

· 1, Разработка технического задания;

· 2, Рабочее проектирование;

· 3, Внедрение

5.2. Этапы разработки.

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

1. Разработка программы

2. Разработка программной документации

3. Испытания программы

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

6. Технико-экономические показатели

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

Разработка ИС прокат автомобилей требует деятельности коллектива из менеджеров по продажам, администратора автопарка и клиентов автопарка. Длительность полного цикла создания программного продукта - 2 месяца.

7. Порядок контроля и приемки

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

Приложение Б

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

using System.ComponentModel;

using System.Data;

using System.Drawing;

using System.Linq;

using System.Text;

using System.Threading.Tasks;

using System.Windows.Forms;

public partial class Form1: Form

form2 form = new form2();

string nameP = "";

InitializeComponent();

if (dostup == false)

string imenov1 = textBox3.Text;

string imenov2 = textBox6.Text;

string category1 = comboBox2.Text;

string imenov3 = textBox7.Text;

string imenov4 = textBox8.Text;

string category2 = comboBox1.Text;

string imenov5 = textBox5.Text;

string imenov6 = textBox4.Text;

if (imenov1 != "" & imenov2 != "" & category1 != "" & imenov3 != "" & imenov4 != "" & category2 != "" & imenov5 != "" & imenov6 != "")

form.dataGridView1.Rows.Add(imenov1, imenov2, category1, imenov3, imenov4, category2, imenov5, imenov6);

MessageBox.Show("Заказ успешно добавлен!", "Уведомление");

MessageBox.Show("Все поля должны быть заполнены!", "Предупреждение!");

if(textBox1.Text == "Admin")

nameP = textBox1.Text;

groupBox1.Visible = true; //Открываем рабочую область

button5.Visible = true;

groupBox2.Visible = false; //Скрываем объекты

label1.Visible = false;

textBox1.Visible = false;

label6.Location = new Point(506, 12); //Меняем координаты объектов

label7.Text = nameP;

label7.Location = new Point(506, 29);

MessageBox.Show("Такого менеджера не существует, возможно вы ошиблись при вводе данных!", "Предупреждение!");

Close(); //Выход из программы

private void button5_Click(object sender, EventArgs e)

if (nameP != "")

private void textBox1_TextChanged(object sender, EventArgs e)

private void Form1_Load(object sender, EventArgs e)

groupBox1.Visible = false;

button5.Visible = false;

private void groupBox1_Enter(object sender, EventArgs e)

private void textBox3_TextChanged(object sender, EventArgs e)

using System.Collections.Generic;

using System.ComponentModel;

using System.Data;

using System.Drawing;

using System.Linq;

using System.Text;

using System.Threading.Tasks;

using System.Windows.Forms;

public partial class form2: Form

InitializeComponent();

private void button2_Click(object sender, EventArgs e)

dataGridView1.Rows.Add("01", "02", "03", "04", "05", "06", "07", "08");

private void button1_Click(object sender, EventArgs e)

private void dataGridView1_CellContentClick(object sender, DataGridViewCellEventArgs e)

private void button2_Click_1(object sender, EventArgs e)

dataGridView1.Rows.Clear(); //Удаляем все данные из таблицы БД

private void button3_Click(object sender, EventArgs e)

//Удаляем одну строчку из таблицы БД

int ind = dataGridView1.SelectedCells.RowIndex;

dataGridView1.Rows.RemoveAt(ind);

Приложение В

Руководство пользователя

1. НАЗНАЧЕНИЕ ПРОГРАММЫ.

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

2.УСЛОВИЯ ВЫПОЛНЕНИЯ ПРОГРАММЫ.

Для работы с данным программным обеспечением необходимо наличие ПК с требуемыми техническими характеристиками, а именно:

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

2.1.1. Состав выполняемых функций.

Разрабатываемое ПО должно обеспечивать:

поступление новых заявок на аренду;

списание и перевод заявок в другие точки аренды;

учет поступивших заказов клиентов, их выполнения или информации об отказе;

введение данных о менеджере (ФИО, стаж работы в этой области);

перечень автомобилей в разрезе их характеристик (цвет, класс, мощность и т.д.).

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

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

2.1.2. Организация входных и выходных данных.

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

2.2. Требования к надежности.

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

3. ВЫПОЛНЕНИЕ ПРОГРАММЫ.

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

4. СООБЩЕНИЯ ОПЕРАТОРУ.

- "Заказ успешно добавлен!" - добавлена информация о заказе

Руководство администратора

1. ОБЩИЕ СВЕДЕНИЯ О ПРОГРАММЕ.

ИС прокат автомобилей - является информационной системой для регулярной аренды автомобилей в фирме по прокат автомобилей.

2. СТРУКТУРА ПРОГРАММЫ.

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

3. ДОПОЛНИТЕЛЬНЫЕ ВОЗМОЖНОСТИ.

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

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

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

4. СООБЩЕНИЕ СИСТЕМНОМУ ПРОГРАММИСТУ.

Вывод ошибок при некорректном запуске программы.

Вывод ошибок при некорректном сохранение данных программы.

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

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

Подобные документы

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

курсовая работа , добавлен 10.06.2014


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

курсовая работа , добавлен 21.03.2015


Разработка информационной системы на платформе "1С:Предприятие 8.0" для автоматизации документооборота и учета по приему аварийных автомобилей и составлению заказ-нарядов. Проектирование интерфейса. Построение логической и физической моделей данных.

дипломная работа , добавлен 14.02.2015


Разработка базы данных фирмы, представляющей в прокат автомобили; спецификация требований. Создание инфологической модели предметной области. Определение сущности, ее атрибутов и связей между ними; структура таблиц. Реализация базы данных в MS SQL Server.

курсовая работа , добавлен 10.04.2015


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

курсовая работа , добавлен 31.10.2014


Проектирование процесса автоматизации оформления продаж автомобилей в автосалоне. Описание бизнес-процессов учета автомобилей. Исследование информационных потоков. Анализ входной и выходной информации. Алгоритмы решения задачи и их машинная реализация.

курсовая работа , добавлен 11.03.2014


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

дипломная работа , добавлен 02.11.2015


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

дипломная работа , добавлен 08.02.2015


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

дипломная работа , добавлен 02.08.2015


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

Лабораторная работа № 2. Разработка моделей IDEF0

Порядок выполнения лабораторной работы:

1. Изучите теоретические сведения.

2. Выполните следующие задания:

· Создание контекстной диаграммы.

· Создание диаграммы узлов.

· Создание FEO диаграммы.

· Расщепление и слияние моделей.

3. Выполните структурный анализ задачи, определенной в ТЗ (первая лабораторная работа).

4. Выполненный анализ задачи оформите в виде диаграмм IDEF0 (программные продукты MS Visio, BPwin).

Теоретическая часть

Методология функционального моделирования IDEF 0

Лекционный материал

Общая постановка задачи

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

Список индивидуальных данных

Продолжается работа над задачей, выбранной в первой лабораторной работе.

Пример выполнения работы

Как было определено в ТЗ, входной информацией системы является:

· бухгалтерская информация;

· информация о нажатой кнопке RTE;

· регистрационная информация;

· информация о считанном идентификаторе.

Выходной информацией системы является:

· управляющие воздействия на исполнительный механизм;

· отчеты.

Контекстная диаграмм (диаграмма А-0) разрабатываемой системы управления платной автостоянкой приведена на рис. 1.

Рис. 1. IDEF0-диаграмма А-0 - контекстная диаграмма системы управления платной автостоянкой

Детализация контекстной диаграммы А-0 представлена на рис. 2 (диаграмма А0). На данной диаграмме выделены три функциональных блока «Регистрация клиентов и корректировка информации о клиентах», «Пропуск клиента» и «Формирование отчетов».

Рис. 2. IDEF0-диаграмма А0 – детализация контекстной диаграммы

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

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

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

Детализация блока «Регистрация клиентов и корректировка информации о клиентах» представлена на рис. 3. Как видно из диаграммы, перед регистрацией клиента и изменением информации о клиенте осуществляется проверка соответствующих прав сотрудника автостоянки (права администратора). Права определяются на основании введенного пароля.

Владелец" href="/text/category/vladeletc/" rel="bookmark">владельце идентификатора не осуществляется. Информация о нажатии данной кнопки сразу поступает на блок формирования управляющих воздействий.

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

Рис. 4. IDEF0-диаграмма А2 – детализация блока «Пропуск клиента» диаграммы А0

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

Детализация блока «Формирование отчетов» диаграммы А0 представлена на рис. 5. (диаграмма А3). Вначале необходимо выбрать тип отчета. Затем формируется соответствующий отчет. Все отчеты в системе можно разделить на два типа:

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

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

Рис. 5. IDEF0-диаграмма А3 – детализация блока «Формирование отчетов» диаграммы А0

К первому типу относятся следующие отчеты:

· список клиентов;

· задолжености клиентов.

Ко второму типу относятся следующие отчеты:

· активность использования машиномест;

· список занятых и свободных машиномест;

· список событий.

Детализация блока «Выполнить изменение информации о клиенте» диаграммы А1 представлена на рис. 6 (диаграмма А14). Требования внесения информации о клиенте могут быть вызваны следующими причинами:

· не произведена оплата аренды машиноместа;

· не произведена оплата пропуска;

· требуются изменения в договоре;

· требуется замена пропуска (идентификатора).

Рис. 6. IDEF0-диаграмма А14 – детализация блока «Выполнить изменение информации о клиенте» диаграммы А1

Детализация блока «Изменение договора» диаграммы 14 представлена на рис. 7 (диаграмма А142). Если требуется изменение договора, то выписывается новый договор, который отдается клиенту. После подписания договора клиентом и руководством автостоянки, информации о договоре вносится в бухгалтерскую программу и в разрабатываемую систему.

Рис. 7. IDEF0-диаграмма А142 – детализация блока «Изменение договора» диаграммы А14

Детализация блока «Оплата» диаграммы А14 представлена на рис. 8 (диаграмма А143). Если требуется произвести оплату аренды машиномест или изготовления нового пропуска, то выписываются документы, на основании которых будет производиться оплата. С этими документами клиент отправляется в бухгалтерию и производит оплату. Информация об оплате фиксируется в бухгалтерской программе и передается в разрабатываемую систему.

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

Рис. 8. IDEF0-диаграмма А143 – детализация блока «Оплата» диаграммы А14

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

Контрольные вопросы:

1. В чем суть методологии IDEF0 ?

2. Синтаксис и семантика функциональных блоков диаграммах IDEF0 ?

3. Синтаксис и семантика стрелок в диаграммах IDEF0:

· стрелки входа;

· стрелки управления;

· стрелки выхода;

· стрелки механизма исполнения;

· комбинированные стрелки;

· разбиение и соединение стрелок;

· туннели.

4. Основы методики построения моделей IDEF0.

5. Основные возможности программного продукта MS Visio.

6. Построение диаграмм IDEF0 с помощью программного продукта MS Visio.

7. Основные возможности программного продукта BPwin.

8. Построение диаграмм IDEF0 с помощью программного продукта BPwin.

Введение

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

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

О методологии IDEF0

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

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

Элементы, используемые для IDEF0

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

Возможности использования IDEF0

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

Типы связей между процессами IDEF0

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

1. Иерархическая («часть» - «целое») связь.

2. Управляющая (регламентирующая, подчинённая):

2) обратная связь управления.

3. Функциональная или технологическая:

2) обратная входная.

3) потребительская;

4) логическая;

5) методическая или коллегиальная;

6) ресурсная;

7) информационная;

8) временная;

9) случайная.

Построение блоков и связей в диаграммах

Методология IDEF0 предоставляет целый ряд правил и рекомендаций по своему использованию и улучшению качества использования. Так, в диаграмме отображается один блок, на котором можно задать название системы, её назначение. К блоку или от блока ведёт 2-5 стрелок. Можно больше или меньше, но как минимум две стрелки необходимы для входа/выхода, а остальные для дополнительных работ и их указания на диаграмме. Если стрелок больше 5, следует задуматься об оптимальности построения модели, и нельзя ли сделать её ещё более детализированной.

Построение блоков в диаграммах декомпозиции

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

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

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

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

Именование

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

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

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

Информация о стрелках

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

Пример реализации методологии IDEF0 на конкретной модели

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

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

Исходной информацией выступают:

1. данные про линию путей;
2. паспорт всей дистанции;
3. план пути.

Управляющие данные:

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

Результатом модели является:

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

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

Заключение

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