Методология SADT (Structured Analysis and Design Technique – методология структурного анализа и проектирования) представляет собой совокупность методов, правил и процедур, предназначенных для построения функциональной модели системы.

Начало разработки данной методологии было положено Дугласом Россом (США) в середине 60-х гг. ХХ в. С тех пор системные аналитики компании SofTech, Inc. улучшили SADT и использовали ее в решении широкого круга проблем. Программное обеспечение телефонных сетей, диагностика, долгосрочное и стратегическое планирование, автоматизированное производство и проектирование, конфигурация компьютерных систем, обучение персонала, управление финансами и материально-техническим снабжением – вот некоторые из областей эффективного применения SADT. Широкий спектр областей указывает на универсальность и мощь методологии SADT. В программе «Интеграции компьютерных и промышленных технологий» (Integrated Computer Aided Manufacturing, ICAM) Министерства обороны США была признана полезность SADT. Это привело к публикации ее части в 1981 г., называемой IDEF0 (Icam DEFinition), в качестве федерального стандарта на разработку программного обеспечения. Под этим названием SADT стала применяться тысячами специалистов в военных и промышленных организациях . Последняя редакция стандарта IDEF0 была выпущена в декабре 1993г. Национальным институтом по стандартам и технологиям США (National Institute Standards and Technology, NIST).

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

Описывать любые системы, а не только информационные (DFD предназначена для описания программного обеспечения);

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

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

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

Модель (AS-IS, TO-BE или SHOULD-BE) может содержать 4 типа диаграмм [ , ]:

Контекстную диаграмму;

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

Диаграммы дерева узлов;

Диаграммы только для экспозиции (for exposition only, FEO).

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

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

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

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

6.3. Элементы графической нотации IDEF0

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

На следующем рисунке показаны основные элементы графической нотации IDEF0 .

Рис. 6.1. Элементы графической нотации IDEF0

Прямоугольник представляет собой работу (процесс, деятельность, функцию или задачу) , которая имеет фиксированную цель и приводит к некоторому конечному результату. Имя работы должно выражать действие (например, «Изготовление детали», «Расчет допускаемых скоростей», «Формирование ведомости ЦДЛ № 3»).

Взаимодействие работ между собой и внешним миром описывается в виде стрелок. В IDEF0 различают 5 видов стрелок :

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

- управление (англ. control) – управляющие, регламентирующие и нормативные данные, которыми руководствуется работа. Управление отвечает на вопрос «В соответствии с чем выполняется работа?». Управление влияет на работу, но не преобразуется ей, т.е. выступает в качестве ограничения. В качестве управления могут быть правила, стандарты, нормативы, расценки, устные указания. Стрелки управления рисуются входящими в верхнюю грань работы. Если при построении диаграммы возникает вопрос, как правильно нарисовать стрелку сверху или слева, то рекомендуется ее рисовать как вход (стрелка слева);

- выход (англ. output) – материал или информация, которые представляют результат выполнения работы. Выход отвечает на вопрос «Что является результатом работы?». В качестве выхода может быть как материальный объект (деталь, автомобиль, платежные документы, ведомость), так и нематериальный (выборка данных из БД, ответ на вопрос, устное указание). Стрелки выхода рисуются исходящими из правой грани работы;

- механизм (англ. mechanism) – ресурсы, которые выполняют работу. Механизм отвечает на вопрос «Кто выполняет работу или посредством чего?». В качестве механизма могут быть персонал предприятия, студент, станок, оборудование, программа. Стрелки механизма рисуются входящими в нижнюю грань работы;

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

6.4. Типы связей между работами

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

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

1. Иерархическая связь (связь «часть» – «целое») имеет место между функцией и подфункциями, из которых она состоит.

Рис. 6.2. Иерархическая связь

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

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

Рис. 6.5. Прямая связь по входу	Рис. 6.6. Обратная связь по входу

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

Рис. 6.7. Потребительская связь

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

Рис. 6.8. Логическая связь

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

Рис. 6.9. Методическая связь

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

Рис. 6.10. Ресурсная связь

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

Рис. 6.11. Информационная связь

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

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

Рис. 6.12. Временная связь

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

Рис. 6.13. Случайная связь

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

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

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

1. Перед построением модели необходимо определиться, какая модель (модели) системы будет построена. Это подразумевает определение ее типа AS-IS, TO-BE или SHOULD-BE, а также определения позиции, с точки зрения которой строится модель. «Точку зрения» лучше всего представлять себе как место (позицию) человека или объекта, в которое надо встать, чтобы увидеть систему в действии. Например, при построении модели работы продуктового магазина можно среди возможных претендентов, с точки зрения которых рассматривается система, выбрать продавца, кассира, бухгалтера или директора. Обычно выбирается одна точка зрения, наиболее полно охватывающая все нюансы работы системы, и при необходимости для некоторых диаграмм декомпозиции строятся диаграммы FEO, отображающие альтернативную точку зрения.

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

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

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

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

Рис. 6.14. Функция без управления и входа

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

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

6. У каждого блока должен быть как минимум один выход.

Рис. 6.15. Функция без выхода

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

7. При построении диаграмм следует минимизировать число пересечений, петель и поворотов стрелок.

8. Обратные связи и итерации (циклические действия) могут быть изображены с помощью обратных дуг. Обратные связи по входу рисуются «нижней» петлей, обратная связь по управлению – «верхней» (см. рис. 6.4 и 6.6).

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

Рис. 6.16. Ветвление стрелок

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

Так, на рис. 6.16 управления, входящие в блоки «Изготовление деталей» и «Сборка изделия», имеют уточняющие значения и являются составной частью более общего управления «Чертежи». Для работы блока «Контроль качества» используются все чертежи.

На диаграмме не допускается рисовать стрелки, когда до и после ветвления они не именованы. На рис. 6.17 стрелка, входящая в блок «Формирование типовых ведомостей», не имеет имени до и после ветвления, что является ошибкой.

Рис. 6.17. Неправильное именование стрелок

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

Рис. 6.18. Туннелирование стрелок

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

Аналогичным образом можно выполнять туннелирование с обратной целью – недопущения отображения стрелки на диаграммах низших уровней. В этом случае круглые скобки ставятся на конце стрелки. На контекстной диаграмме (см. рис. 6.21) затуннелирован механизм «Инженер службы пути», входящий в блок «Определение допускаемых скоростей». Такое решение принято, так как инженер непосредственно участвует во всех работах, отображенных на диаграмме декомпозиции этого блока (см. рис. 6.22). Чтобы не показывать эту связь и не загромождать диаграмму декомпозиции, стрелка была затуннелирована.

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

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

Рис. 6.19. Объединение связей

13. Каждый блок на диаграммах должен иметь свой номер. Для того чтобы указать положение любой диаграммы или блока в иерархии, используются номера диаграмм. Блок на диаграмме верхнего уровня обозначается 0, блоки на диаграммах второго уровня – цифрами от 1 до 9 (1, 2, …, 9), блоки на третьем уровне – двумя цифрами, первая из которых указывает на номер детализируемого блока с родительской диаграммы, а вторая номер блока по порядку на текущей диаграмме (11, 12, 25, 63) и т. д. Контекстная диаграмма имеет обозначение «А – 0», диаграмма декомпозиции первого уровня – «А0», диаграммы декомпозиции следующих уровней – состоят из буквы «А», за которой следует номер декомпозируемого блока (например, «А11», «А12», «А25», «А63»). На рисунке показано типичное дерево диаграмм (диаграмма дерева узлов) с нумерацией.

Рис. 6.20. Иерархия диаграмм

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

6.6. Пример построения модели IDEF0 для системы определения допускаемых скоростей

Расчет допускаемых скоростей движения поездов является трудоемкой инженерной задачей. При проходе поездом какого-либо участка фактическая скорость движения поезда не должна превышать предельно допускаемую. Эта предельно допускаемая скорость устанавливается исходя из опыта эксплуатации и специально проводимых испытаний по динамике движения и воздействию на путь подвижного состава. Непревышение этой скорости гарантирует безопасность движения поездов, комфортабельные условия езды пассажиров и т. п. Они определяются в зависимости от типа подвижного состава (марки локомотива и типа вагонов), параметров верхнего строения пути (типа рельсов, балласта, эпюры шпал) и плана (радиуса кривых, переходных кривых, возвышения наружного рельса и т. д.). Как правило, для установления допускаемых скоростей необходимо определить не менее двух (на прямых) и пяти (в кривых) скоростей, из которых и выбирается окончательная допускаемая скорость, как наименьшая из всех рассчитанных. Расчет этих скоростей регламентируются Приказом МПС России № 41 от 12 ноября 2001 г. «Нормы допускаемых скоростей движения подвижного состава по железнодорожным путям колеи 1520 (1524) мм Федерального железнодорожного транспорта».

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

Контекстная диаграмма для задачи определения допускаемых скоростей показана на рис.6.21. Для построения модели использовался продукт BPwin 4.0 фирмы Computer Associates.

Рис. 6.21. Контекстная диаграмма системы определения допускаемых скоростей (методология IDEF0)

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

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

Подробный продольный профиль (содержит информацию, аналогичную рассмотренной выше);

Паспорт дистанции пути (содержит информацию, аналогичную рассмотренной выше, а также сведения о верхнем строении пути (ВСП));

Данные о результатах съемки плана пути вагоном-путеизмерителем;

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

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

Управляющими данными являются:

Указание начальника службы пути дороги или Департамента пути и сооружений ОАО «РЖД» на расчет;

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

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

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

Результатом работы системы должны быть:

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

Ведомости Приказа начальника дороги об установлении допускаемых скоростей на перегонах и раздельных пунктах (Приказ «Н») согласно принятой на дороге форме. Утвержденный Приказ «Н» официально закрепляет допускаемые скорости движения поездов;

Типовые формы № 1, 1а и 2, содержащие планируемые допускаемые скорости для разработки графика движения поездов.

Скорости, содержащиеся в Приказе «Н» и типовых формах, могут отличаться от рассчитанных и показываемых в ведомостях допускаемых скоростей. Это связано с тем, что в них отражают ограничения скорости не только по конструкции подвижного состава, параметров ВСП и кривых, но и по состоянию устройств и сооружений (деформация земляного полотна, перекос опор контактной сети и т. д.). Кроме того, они корректируются с учетом планируемых ремонтов пути, реконструкции и переустройства сооружений и устройств и т.д.

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

Диаграмма декомпозиции первого уровня для рассматриваемой задачи приведена на рис.6.22. Как правило, при построении диаграммы декомпозиции исходная функция (декомпозируемая) разбивается на 3–8 подфункций (блоков). При этом блоки на диаграмме декомпозиции рекомендуется располагать слева направо сверху вниз, чтобы лучше была видна последовательность и логика взаимодействия подфункций.

Рис. 6.22. Диаграмма декомпозиции первого уровня (методология IDEF0)

Очередность выполнения функций для решения рассматриваемой задачи следующая:

Ввод и корректировка нормативно-справочной информации и данных по участкам дороги (блоки 1 и 2);

Подготовка задания на расчет (блок 3). В нем указывается, для какого участка и пути, а также марки локомотива и типа вагонов следует выполнить расчет;

Расчет допускаемых скоростей в соответствии с порядком и формулами, указанными в Приказе № 41 (блок 4). В качестве исходной информации выступают данные по пути участка (план, верхнее строение пути и т. д.) и нормативы, выбираемые на основании задания на расчет;

Формирование ведомостей допускаемых скоростей (блок 5). На базе результатов расчета создаются несколько видов выходных документов, которые, с одной стороны, позволяют выявить причину ограничений скорости, с другой стороны, выступают в качестве основы для подготовки регламентированных документов;

Формирование и подготовка проекта Приказа «Н» и типовых ведомостей (блоки 6 и 7).

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

6.7. ICOM-коды

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

ICOM-коды (аббревиатура от Input, Control, Output и Mechanism) предназначены для идентификации граничных стрелок. ICOM-код содержит префикс, соответствующий типу стрелки (I, С, О или М), и порядковый номер (см. рис.).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рисунок 1.3 (а)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Договор с поставщиками;

Каталог автомобилей;

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

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

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

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

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

– Потоки данных;

– Процессы (работы) преобразования входных потоков данных в выходные;

– Внешние сущности;

– Накопители данных (хранилища).

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

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

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

   Отчет

   ЭЛЕКТРОННЫЙ АДМИНИСТРАТИВНЫЙ РЕГЛАМЕНТ, АДМИНИСТРАТИВНЫЙ РЕГЛАМЕНТ, ДОЛЖНОСТНОЙ РЕГЛАМЕНТ, АДМИНИСТРАТИВНО-УПРАВЛЕНЧЕСКИЙ ПРОЦЕСС, ОПИСАНИЕ АДМИНИСТРАТИВНО-УПРАВЛЕНЧЕСКИХ ПРОЦЕССОВ,

2. управление процессами

   Документ

   Позняковский Валерий Михайлович – директор НИИ биотехнологии и сертификации, зав. кафедры биотехнологии, товароведения и управления качеством Кемеровского технологического института пищевой промышленности,

3. Технологии защиты информации в сети Курс лекций Введение В данном курсе изложены теоретические основы криптографии и вопросы сетевой безопасности Предназначено для чтения курса «Технологии защиты информации в сети» Содержание

   Обзор

4. Информационные технологии в профессиональной деятельности

   Учебно-методический комплекс

   Учебно-методический комплекс по учебной дисциплине «Информационные технологии в профессиональной деятельности» для специальности 030503.52 – «Правоведение» среднего профессионального образования.

5. Учебно-методический комплекс по дисциплине «информационные технологии в бизнес-планировании»

   Учебно-методический комплекс

6. 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 диаграммы, по которому вы можете ориентироваться уже сейчас.

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

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

   Размещено на 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.