Проектирование CRM-системы ОАО ‘Орбита-Сервис’

метки: Система, Разработка, Клиент, Данные, Требование, Модель, Диаграмма, Server

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

1.1 Задачи систем управления взаимодействием с клиентами

1.2 Проблемы и перспективы CRM-систем

1.3 Необходимость использования CRM-систем

1.4 Эффективность внедрения CRM-систем

1.5 Этапы разработки информационных систем

1.6 СУБД как способ реализации ИС

1.6.1 Общие принципы проектирования баз данных

1.6.2 Иерархические структуры данных

1.6.3 Сетевые структуры данных

1.6.4 Реляционная модель

1.6.5 Технология клиент-сервер

1.7 Цель, назначение и задачи информационной подсистемы

1.8 Организационная структура ОАО «Орбита-Сервис»

2 Проектирование информационной подсистемы

2.1 Основы технологий создания ПО

2.1.1 Визуальное моделирование

2.1.2 Методы структурного анализа и проектирования ПО

2.2 Методы анализа и проектирования ПО

2.3 Функциональное моделирование информационной подсистемы

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

2.5 Инфологическая модель предметной области

2.6 Даталогическое проектирование базы данных

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

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

2.9 Описание алгоритма работы программного модуля

3 Реализация

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

3.1.1 Borland Delphi

3.1.2 MS SQL Server

3.2 Описание прикладной программы

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

3.2.2 Системные и программные требования

3.2.3 Описание интерфейса и возможностей программы

3.2.4 Резервное копирование

3.3.5 Пути усовершенствования программной разработки

4 Организационно — экономическая часть

4.1 Экономическое и социальное обоснование разработки программного продукта

4.1.1 Выявление спроса

4.1.2 Выбор базового варианта

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

... -Комп». Задачи дипломной работы. Основные задачи дипломной работы заключаются в следующем: анализ предметной области по построению информационных систем анализ и изучение моделей управления запасами; создание информационной системы по учету производства и реализации ортопедических ...

4.1.3 Расчет затрат на разработку ПС и договорной цены

4.2 Расчет экономических показателей целесообразности и оценка эффективности предлагаемой разработки

4.2.1 Расчет капитальных вложений по сравниваемым вариантам

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

4.2.3 Расчет эксплуатационных издержек у пользователя

4.2.4 Расчет годовой экономии стоимости машинного времени у потребителя программы

4.2.5 Расчет относительной экономии капвложений

4.2.6 Расчет относительной экономии эксплуатационных издержек потребления

4.2.7 Расчет годового экономического эффекта использования ПП

4.2.8 Расчет годового экономического потенциала разработки

4.2.9 Расчет цены потребления

4.3 Оценка конкурентоспособности ПП

4.3.1 Расчётный коэффициент экономической эффективности

4.4 Организация сервисного обслуживания

4.4.1 Смета затрат на выполнение сервисного обслуживания

5 Безопасность и экологичность

5.1 Опасные и вредные производственные факторы на рабочем местеоператора ЭВМ

5.2 Вредные факторы и их воздействие на оператора ЭВМ

5.2.1 Воздействие шума на оператора ЭВМ

5.2.2 Микроклимат

5.2.3 Освещение организаций, разрабатывающих ПП

5.2.4 Расчет естественного освещения

5.2.5 Защита от электромагнитных полей

5.3 Пожарная безопасность

5.3.1 Средства первичного пожаротушения и план эвакуации из рабочего помещения

5.4 Электробезопасность

5.5 Экологическая оценка

Заключение

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

[Электронный ресурс]//URL: https://inzhpro.ru/diplomnaya/razrabotka-crm/

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

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

• ­ рациональное использование ресурсов;
• ­ улучшение обслуживания клиентов;
• ­ учет бизнес-процедур;
• ­ эффективная отчетность о результатах;
• ­ облегчение работы персонала.

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

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

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

Расчет показателей надежности простейшей системы электроснабжения ...

... частью их. Наработка, Показатель надежности Задание на расчёт Система электроснабжения, представленная на рис.1, включает ... важную роль при выборе моделей и методов анализа надежности. комплексным Составляющих (единичных) свойств, безотказность; долговечность; ... 0.96. Расчёт надёжности Безотказная работа рассматриваемой части системы электроснабжения будет тогда, когда в соответствии с принятыми ...

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

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

Система управления взаимодействием с клиентами (Customer Relationship Management System, CRM-система) — корпоративная информационная система, предназначенная для автоматизации CRM-стратегии компании, в частности, для повышения уровня продаж, оптимизации маркетинга и улучшения обслуживания клиентов путём сохранения информации о клиентах (контрагентах) и истории взаимоотношений с ними, установления и улучшения бизнес-процедур и последующего анализа результатов. Её основные принципы таковы:

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

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

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

Существуют несколько типов классификации CRM-систем.

Классификация по функциональным возможностям:

Управление продажами (SFA — Sales Force Automation)

Управление маркетингом

Управление сервисом и Call-центры (системы по обработке жалоб от абонентов, фиксация и дальнейшая работа с обращениями клиентов)

Классификация по уровням обработки информации.

Оперативный — регистрация и оперативный доступ к первичной информации по событиям, компаниям, проектам, контактам, документам и т.д.

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

Коллаборационный (англ. collaboration — сотрудничество; совместные, согласованные действия) — уровень организации тесного взаимодействия с конечными потребителями, клиентами, вплоть до влияния клиента на внутренние процессы компании (опросы, для изменения качеств продукта или порядка обслуживания, web-страницы для отслеживания клиентами состояния заказа, уведомление по SMS о проведённых транзакциях по банковскому счету, возможность для клиента самостоятельно скомплектовать и заказать в online, к примеру, автомобиль или компьютер из доступных блоков и опций и др.)

Методы эффективных продаж

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

Ранее (примерно до 2000 года) CRM-системы, как правило, были «однобоки» (так называемые «менеджеры контактов», или системы поддержки маркетинговых мероприятий, или системы для автоматизации сервисных служб).

Однако к 2006 году практически все современные CRM-системы получили в большей или меньшей степени все указанные возможности и уровни обработки информации [1].

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

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

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

Стоимость системы. Можно долго говорить о преимуществах той или иной системы, но основным критерием выбора остается цена. Конечная стоимость обычно складывается из расходов на консультирование, стоимости лицензии (зависит от количества пользователей), стоимости внедрения, технической поддержки и обучения. Цена отечественных и западных решений одного уровня отличается на порядок [2].

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

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

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

... - программный продукт 1С:Управление торговлей» Цель курсовой работы заключается в разработке проекта внедрения 1С:Управление торговлей в компанию «СТД -Петрович». Для достижения поставленной ... данными. Грекул В.И., Коровкина Н.Л., Куприянов Ю.В. Проектное управление в сфере информационных технологий - М.:Бином. Лаборатория знаний , 2013.- 336 с. Цель проекта внедрения 1С-системы в компанию ...

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

Одним из факторов, препятствующих широкому использованию CRM-программ в бизнесе, является несколько смещенное позиционирование продуктов производителями данного ПО. Аббревиатура CRM — управление взаимоотношениями с клиентами — воспринимается слишком буквально. Изначально, CRM, как программный продукт рассматривался как часть единой системы управления бизнесом! И также как изолированный складской учет не решит проблему бухучета предприятия, «голая» CRM-система не решит проблему управления продажами.

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

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

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

В-третьих, действия конкурентов. Мониторинг действий конкурентов, «защита» своих клиентов от их воздействия — это тоже часть CRM-технологии.

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

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

Подготовка технического задания на разработку информационной ...

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

Таким образом, для большинства предприятий МСБ вполне достаточно интегрировать три основных модуля: Учет, Аналитика, CRM.

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

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

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

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

Выгоды от внедрения CRM-системы.

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

Например:

• повышение точности и адекватности планирования;
• повышение оперативности подготовки отчетных данных (например, с 5 до 1 дня);
• улучшение взаимоотношений с клиентами, например, повышение лояльности клиентов;
• увеличение объема продаж, например, на 5-10 или более %;
• сокращение времени исполнения заказов, например, срока формирования предложений и подбора услуги/продукта клиенту;
• снижение производственных и операционных затрат, на 5-10 или более %;
• уменьшение складских запасов, на 5-10 или более %;
• сокращение времени на разработку и вывод новой продукции на рынок и т.д.

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

Системы подземной разработки с обрушением руды и вмещающих пород

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

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

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

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

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

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

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

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

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

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

Автоматизация системы бюджетирования финансовой службы

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

Ввод в эксплуатацию. Этот этап предусматривает перенос новой ИС из тестовой в рабочую среду.

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

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

На этом этапе определяются:

• ­ архитектура системы, ее функции, внешние условия функционирования, распределение функций между аппаратурой и программным обеспечением;

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

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

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

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

По принципам организации данных СУБД можно разделить на следующие: модель, основанная на инвертированных списках, иерархическая модель, сетевая модель и реляционная модель [3].

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

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

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

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

Рисунок 1 — Процесс разработки базы данных

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

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

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

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

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

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

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

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

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

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

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

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

• ­ переносимость;
• ­ масштабируемость;
• ­ простота администрирования;
• ­ минимальные требования к аппаратной части;
• ­ низкая стоимость ПО или возможность получить его бесплатно.

Кроме перечисленных условий, сервер центра сервисной поддержки должен:

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

При этом ключевым фактором остается вид базы данных.

На сегодняшний день существуют 2 принципиально разных вида баз данных: реляционный и постреляционный (объектно-ориентированный).

К первому относится подавляющее большинство промышленных БД: MS SQL Server, Oracle, InterBase и т.д. Ко второй группе можно отнести Lotus Notes/Domino и СУБД Cache.

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

Модель данных — это абстрактное представление о содержимом базы данных.

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

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

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

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

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

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

Основными из этих принципов являются:

• ­ принцип абстрагирования — выделение существенных аспектов системы и отвлечение от несущественных;
• ­ принцип формализации — необходимость строгого методического подхода к решению проблемы;
• ­ принцип непротиворечивости — обоснованность и согласованность элементов;
• ­ принцип структурирования данных — данные должны быть структурированы и иерархически организованы.

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

• ­ DFD (Data Flow Diagrams) — диаграммы потоков данных;
• ­ SADT (Structured Analysis and Design Technique) — модели и соответствующие функциональные диаграммы;
• ­ ERD (Entity-Relationship Diagrams) — диаграммы «сущность-связь».

Диаграммы потоков данных и диаграммы «сущность-связь» — наиболее часто используемые в CASE-средствах виды моделей.

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

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

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

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

• ­ внешние сущности;
• ­ системы/подсистемы;
• ­ процессы;
• ­ накопители данных;
• ­ потоки данных.

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

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

Каждый столбец таблицы соответствует одному атрибуту сущности.

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

Эти ограничения следующие:

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

Это ограничение называют правилом ссылочной целостности.

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

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

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

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

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

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

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

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

Основными из этих принципов являются:

• ­ принцип абстрагирования — выделение существенных аспектов системы и отвлечение от несущественных;
• ­ принцип формализации — необходимость строгого методического подхода к решению проблемы;
• ­ принцип непротиворечивости — обоснованность и согласованность элементов;
• ­ принцип структурирования данных — данные должны быть структурированы и иерархически организованы.

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

• ­ DFD (Data Flow Diagrams) — диаграммы потоков данных;
• ­ SADT (Structured Analysis and Design Technique) — модели и соответствующие функциональные диаграммы;
• ­ ERD (Entity-Relationship Diagrams) — диаграммы «сущность-связь».

Диаграммы потоков данных и диаграммы «сущность-связь» — наиболее часто используемые в CASE-средствах виды моделей.

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

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

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

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

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

К недостаткам этих же систем относится заметная сложность в использовании; необходимость знаний о физической структуре организации данных; зависимость прикладных систем от этой организации; логика прикладных систем перегружена деталями доступа к данным СУБД.

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

Реляционные БД в 70-х годах практически вытеснили БД других видов. В качестве основных причин этого называют сложность представления данных в иерархической и сетевой моделях и необходимость определения связей между данными на этапе проектирования БД, в то время как в реляционных БД связи между таблицами могут устанавливаться непосредственно в момент выполнения запросов. Кроме того, разработчикам и пользователям значительно проще отображать сущности предметной области в табличных структурах данных [5].

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

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

Тем не менее реляционные БД остаются наиболее используемыми.

Создание модели вычислений «клиент-сервер», знаменует собой следующий этап в развитии СУБД. Характерной особенностью архитектуры «клиент-сервер» является перенос вычислительной нагрузки на сервер БД и максимальная разгрузка от нее приложения клиента. Вычисления «клиент-сервер» имеют преимущества модели сетевых вычислений, с доступом к совместно используемым данным, и высокие характеристики производительности, присущие модели вычислений с хостмашиной. Система вычислений «клиент-сервер» состоит из трех различных компонентов, каждый из которых выполняет конкретную работу: сервер базы данных, клиентское приложение и сеть.

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

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

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

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

Клиентское приложение («внешний интерфейс») — это часть системы, которую пользователь использует для взаимодействия с данными.

Клиентские приложения в СУБД «клиент-сервер» выполняют следующие задачи:

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

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

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

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

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

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

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

Рисунок 2 — Организационная структура предприятия

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

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

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

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

Инженерный цех осуществляет ремонт и обслуживание.

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

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

Графические (визуальные) модели представляют собой средства для визуализации, описания, проектирования и документирования архитектуры системы. Разработка модели системы ПО промышленного характера в такой же мере необходима, как и наличие проекта при строительстве большого здания. Хорошие модели являются основой взаимодействия участников проекта и гарантируют корректность архитектуры [6].

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

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

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

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

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

• Функциональную структуру системы;
• Последовательность выполняемых действий;
• Передачу информации между функциональными процессами;
• Отношения между данными.

Наиболее распространенными моделями первых трех групп являются:

• функциональная модель SADT (Structured Analysis and Design Technique);
• модель IDEF3;(Data Flow Diagrams) — диаграммы потоков данных.

Метод SADT представляет собой совокупность правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области. Функциональная модель SADT отображает функциональную структуру объекта, т.е. производимые им действия и связи между этими действиями. Метод SADT разработан Дугласом Россом (SoftTech, Inc.) в 1969 г. для моделирования искусственных систем средней сложности. Данный метод успешно использовался в военных, промышленных и коммерческих организациях США для решения широкого круга задач, таких, как долгосрочное и стратегическое планирование, автоматизированное производство и проектирование, разработка ПО для оборонных систем, управление финансами и материально-техническим снабжением и др. Метод SADT поддерживается Министерством обороны США, которое было инициатором разработки семейства стандартов IDEF (Icam DEFinition), являющегося основной частью программы ICAM (интегрированная компьютеризация производства), проводимой по инициативе ВВС США. Метод SADT реализован в одном стандартов этого семейства — IDEF0, который был утвержден в качестве федерального стандарта США в 1993 г. Модели SADT (IDEF0) традиционно используются для моделирования организационных систем (бизнес-процессов).

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

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

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

Метод моделирования IDEF3, являющийся частью семейства стандартов IDEF, был разработан в конце 1980-х годов для закрытого проекта ВВС США. Этот метод предназначен для таких моделей процессов, в которых важно понять последовательность выполнения действий и взаимозависимости между ними. Хотя IDEF3 и не достиг статуса федерального стандарта США, он приобрел широкое распространение среди системных аналитиков как дополнение к методу функционального моделирования IDEF0 (модели IDEF3 могут использоваться для детализации функциональных блоков IDEF0, не имеющих диаграмм декомпозиции).

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

Диаграммы потоков данных (Data Flow Diagrams — DFD) представляют собой иерархию функциональных процессов, связанных потоками данных. Цель такого представления — продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами.

Для построения DFD традиционно используются две различные нотации, соответствующие методам Йордона-ДеМарко и Гейна-Сэрсона. Эти нотации незначительно отличаются друг от друга графическим изображением символов. В соответствии с данными методами модель системы определяется как иерархия диаграмм потоков данных, описывающих асинхронный процесс преобразования информации от ее ввода в систему до выдачи потребителю. Практически любой класс систем успешно моделируется при помощи DFD-ориентированных методов. Они с самого начала создавались как средство проектирования информационных систем (тогда как SADT — как средство моделирования систем вообще) и имеют более богатый набор элементов, адекватно отражающих специфику таких систем (например, хранилища данных являются прообразами файлов или баз данных, внешние сущности отражают взаимодействие моделируемой системы с внешним миром).

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

Наиболее распространенным средством моделирования данных (предметной области) является модель «сущность-связь» (Entity-Relationship Model — ERМ).

Она была впервые введена Питером Ченом в 1976 г. Эта модель традиционно используется в структурном анализе и проектировании, однако, по существу, представляет собой подмножество объектной модели предметной области. Одна из разновидностей модели «сущность-связь» используется в методе IDEF1Х, входящем в семейство стандартов IDEF и реализованном в ряде распространенных CASE-средств (в частности, AllFusion ERwin Data Modeler).

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

Все современные ТС ПО реализуют ту или иную методику анализа и проектирования ПО. Одна из типичных методик ООАП реализована в технологии RUP. Согласно этой методике, объектно-ориентированный анализ включает два вида деятельности: архитектурный анализ и анализ вариантов использования. Архитектурный анализ выполняется архитектором системы и включает в себя:

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

Анализ вариантов использования выполняется проектировщиками и включает в себя:

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

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

Граничные классы (Boundary) — служат посредниками при взаимодействии внешних объектов с системой. Типы граничных классов: пользовательский интерфейс (обмен информацией с пользователем, без деталей интерфейса — кнопок, списков, окон), системный интерфейс и аппаратный интерфейс (используемые протоколы, без деталей их реализации).

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

Управляющие классы (Control) — обеспечивают координацию поведения объектов в системе. Примеры управляющих классов: менеджер транзакций, координатор ресурсов, обработчик ошибок.

Классы анализа отражают функциональные требования к системе и моделируют объекты предметной области [7].

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

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

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

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

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

Объектно-ориентированное проектирование включает два вида деятельности:

• ­ проектирование архитектуры системы;
• ­ проектирование элементов системы.

Проектирование архитектуры системы выполняется архитектором системы и включает в себя:

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

Проектирование элементов системы включает в себя:

• ­ проектирование классов (детализация классов, уточнение операций и атрибутов, моделирование состояний, уточнение связей между классами);

• ­ проектирование баз данных (в зависимости от типа используемой для хранения данных СУБД — объектной или реляционной).

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

Затем каждая подсистема разбивается на более мелкие и так далее до достижения нужной степени подробности.

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

Рисунок 3 — Контекстная диаграмма

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

Разработаем диаграмму потоков данных, на которой представим: один обобщающий процесс путем объединения всех функциональных требований предварительной диаграммы; выявленные внешние объекты, взаимодействующие с АРМом, — внешние сущности; основную информацию, циркулирующую между внешними сущностями и процессом — потоки данных. Построенная контекстная диаграмма приведена ниже на рисунке 5.

Рисунок 5 — Диаграмма потоков данных

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

Рисунок 6 — Результат декомпозиции первого уровня

Диаграмма «сущность-связь» (ER) предназначена для разработки моделей данных и обеспечивает стандартный способ определения данных и отношения между ними. Фактически с помощью ER-диаграмм осуществляется детализация хранилищ данных проектируемой системы, а также документируются сущности системы и способы взаимодействия, включая идентификацию объекта важной для предметной области (сущности), свойства этих объектов (атрибуты) и отношения с другими объектами (связи).диаграмма, построенная с помощью пакета MS SQL Enterparise Manager 7.2 представлена на рисунке 7.

Рисунок 7 — Инфологическая модель базы данных

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

Рисунок 8 — Даталогическая модель базы данных

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

Теория систем массового обслуживания начала развиваться в начале 20 века. Основателем СМО считается математик Иохансен, сформулировавший в 1907 году предпосылки новой теории.

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

СМО представляют собой системы специфического вида. Вообще СИСТЕМА — целостное множество взаимосвязанных элементов, неделимое на независимое подмножество.

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

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

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

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

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

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

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

На рисунке 9 изображена структура СМО.

Рисунок 9 — Структура СМО

Классификация СМО и их основные элементы

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

По числу каналов n СМО бывают одноканальные (с одним обслуживающим устройством) и многоканальными (с большим числом обслуживающих устройств).

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

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

• ­ с неограниченным временем ожидания (очередь).

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

• ­ с отказами (нулевое ожидание или явные потери).

  «Отказанная» заявка вновь поступает в систему, чтобы её обслужили (вызов абонента через АТС);

• ­ смешанного типа (ограниченное ожидание).

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

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

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

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

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

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

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

(1)

где Т — среднее значение интервала между поступлением очередных требований.

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

Простейший поток обладает такими важными свойствами:

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

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

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

При простейшем потоке требований распределение требований, поступающих в систему подчиняются закону распределения Пуассона: вероятность того, что в обслуживающую систему за время t поступит именно k требований:

(2)

где . — среднее число требований, поступивших на обслуживание в единицу времени.

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

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

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

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

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

(3)

где v — интенсивность обслуживания одного требования одним обслуживающим устройством, которая определяется из соотношения:

, (4)

где — среднее время обслуживания одного требования одним обслуживающим устройством.

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

(5)

где a — коэффициент загрузки;

— интенсивность поступления требований в систему;

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

Из (1) и (2) получаем, что

(6)

Учитывая, что — интенсивность поступления требований в систему

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

Для СМО с ожиданием количество обслуживаемых устройств n должно быть строго больше коэффициента загрузки (требование установившегося или стационарного режима работы СМО): .

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

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

Эффективность работы СМО характеризуется:

Группой показателей эффективности использования СМО:

• ­ абсолютная пропускная способность — среднее число заявок, обслуживаемых в единицу времени (А);
• ­ относительная пропускная способность — отношение АПС к среднему числу заявок, поступивших за единицу времени (Q);
• ­ средняя продолжительность периода занятости СМО (Те);
• ­ коэффициент использования СМО — средняя доля времени, в течении которого система занята обслуживанием заявок.

2) Показателями качества обслуживания заявок:

• ­ среднее время ожидания заявки в очереди (T line);
• ­ среднее время пребывания заявки в СМО (T sys);
• ­ вероятность отказа заявки в обслуживании без ожидания;
• ­ вероятность немедленного приёма заявки;
• ­ среднее число заявок в очереди (N line);
• ­ среднее число заявок, находящихся в СМО (N sys).

3) Показателями эффективности функционирования пары «СМО — потребитель», (например, когда доход от СМО и затраты на её обслуживание измеряются в одних и тех же единицах, и отражает специфику работы СМО).

Обслуживание с ожиданием

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

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

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

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

Мы рассмотрим здесь классическую задачу теории массового обслуживания в тех условиях, в каких она была рассмотрена и решена К. Эрлангом на n одинаковых приборов поступает простейший поток требований интенсивности . Если в момент поступления имеется хотя бы один свободный прибор, оно немедленно начинает обслуживаться. Если же все приборы заняты, то вновь прибывшее требование становится в очередь за всеми теми требованиями, которые поступили раньше и ещё не начали обслуживаться. Освободившийся прибор немедленно приступает к обслуживанию очередного требования, если только имеется очередь. Каждое требование обслуживается только одним прибором, и каждый прибор обслуживает в каждый момент времени не более одного требования. Длительность обслуживания представляет собой случайную величину с одним и тем же распределением вероятностей F (x).

Предполагается, что при x0.

(7)

где — постоянная.

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

Например, вызов абонента, имеющего только один телефонный номер, через АТС. Здесь поток заявок является случайным, если абонент занят, очередная поступающая заявка получает отказ в обслуживании; АТС — это одноканальная СМО (канал обслуживания — линия связи с телефонным номером абонента) с отказами. Работа пейджинговой компании. Многоканальная СМО, число каналов — количество дежурных операторов, СМО с ограниченной очередью (ограничение на длину очереди — память накопителя вызовов).

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

Рисунок 10 — Модульная структура программы

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

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

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

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

Продолжение рисунка 11 — Алгоритм работы программы

Продолжение рисунка 11 — Алгоритм работы программы

Рисунок 11 — Алгоритм работы программы

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

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

Для реализации поставленных перед подсистемой задач выбрано средство разработки приложение Borland Delphi 7, а также СУБД, поддерживающая архитектуру «клиент-сервер» Microsoft SQL Server 2000. Рассмотрим данные средства более подробнее:Delphi 7:7 — является наиболее полным решением для разработки корпоративных приложений от проектирования до развертывания по архитектуре, управляемой моделью (MDA), которое позволяет интегрировать моделирование, разработку и развертывание приложений и систем электронного бизнеса для платформы Windows. Delphi 7 содержит развитые библиотеки и инструменты для создания приложений электронного бизнеса и веб-сервисов, полностью интегрирует соответствующие технологии и качественно повышает производительность разработчиков, предоставляя все необходимое для исследования вопросов перехода на Microsoft.net. При помощи включенного в комплект поставки Kylix 3 для Delphi разработчики могут переносить свои приложения на Linux, повышая отдачу своих инвестиций и расширяя спектр платформ, на которых доступны их приложения. Интегрируя ведущие приложения разработки в единый и легкий в использовании пакет [8].

Delphi 7 сокращает жизненный цикл разработки приложений и ускоряет вывод создаваемых с его помощью продуктов на рынок ПО.7 обладает возможностями проектирования и развертывания корпоративных приложений. Это позволяет разработчикам быстрее воспользоваться преимуществами разработки корпоративных приложений от концепции до коммерческой версии при помощи новой системы проектирования UML и технологии Model Driven Architecture (MDA).

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

Включённая в состав Delphi 7 технология проектирования и моделирования приложений UML позволяет эффективно проектировать свои приложения при помощи средств визуального моделирования и реорганизации кода (refactoring) [9].

Возможности Delphi 7 по интеграции, реинжинирингу и мгновенной визуализации позволяют создавать высококачественные проекты и тексты программ, применяя готовые шаблоны проектирования и создавая более крупные модели.3 в составе Delphi 7 является первой высокопроизводительной визуальной интегрированной средой разработки (IDE), предназначенной для быстрого создания приложений баз данных, программ с графическим пользовательским интерфейсом (GUI), Internet-приложений и WEB-сервисов для операционной системы Linux.

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

Microsoft SQL Server в качестве языка запросов использует версию SQL, получившую название Transact-SQL (сокращённо T-SQL), являющуюся реализацией SQL-92 (стандарт ISO для SQL) с множественными расширениями. T-SQL позволяет использовать дополнительный синтаксис для хранимых процедур и обеспечивает поддержку транзакций (взаимодействие базы данных с управляющим приложением).

Microsoft SQL Server для взаимодействия с сетью используют протокол уровня приложения под названием Tabular Data Stream (TDS, протокол передачи табличных данных).

Протокол TDS также был реализован в проекте FreeTDS с целью обеспечить различным приложениям возможность взаимодействия с базами данных Microsoft SQL Server.SQL Server также поддерживает Open Database Connectivity (ODBC) — интерфейс взаимодействия приложений с СУБД. Версия SQL Server 2005 обеспечивает возможность подключения пользователей через веб-сервисы, использующие протокол SOAP. Это позволяет клиентским программам, не предназначенным для Windows, кроссплатформенно соединяться с SQL Server [15].

Microsoft также выпустила сертифицированный драйвер JDBC, позволяющий приложениям под управлением Java (таким как BEA и IBM WebSphere) соединяться с Microsoft SQL Server 2000.Server поддерживает зеркалирование и кластеризацию баз данных. Кластер сервера SQL — это совокупность одинаково конфигурированных серверов; такая схема помогает распределить рабочую нагрузку между несколькими серверами. Все сервера имеют одно виртуальное имя, и данные распределяются по IP адресам машин кластера в течение рабочего цикла. Также в случае отказа или сбоя на одном из серверов кластера доступен автоматический перенос нагрузки на другой сервер.Server поддерживает избыточное дублирование данных по трем сценариям:

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

История изменений — все изменения базы данных непрерывно передаются пользователям.

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

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

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

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

Программа работает с СУБД MS SQL Server 2000, перед запуском программы необходимо убедиться, что запущен MS SQL Server, в противном случае программа выдаст предупреждение о том, что необходимо включить MS SQL Server. Выбранная СУБД позволяет работать нескольким приложениям одновременно. В ОАО Орбита Сервис к базе данных будет подключено одновременно до 18 клиентов с разными правами доступа.

Для корректной работы данной программы на стороне клиента необходимо наличие компьютера с архитектурой совместимой с I386 и операционной системой Windows XP, Windows 2000, Windows Vista. Из специального программного обеспечения на рабочую станцию необходимо установить СУБД MS SQL SERVER 2000.

Минимальные системные требования для аппаратного обеспечения:

• ­ оперативная память 128Мб;
• ­ процессор с тактовой частотой 800 MHz;
• ­ свободное место на жестком диске 20Мб;
• ­ видеосистема SVGA 800Ч600;
• ­ клавиатура;
• ­ мышь;
• ­ CD привод для чтения оптических дисков;
• ­ PC совместимый принтер.

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

• ­ оперативная память 256Мб;
• ­ процессор с тактовой частотой 1000 MHz;
• ­ свободное место на жестком диске 5Гб;
• ­ видеосистема SVGA 1024Ч768;
• ­ клавиатура;
• ­ мышь;
• ­ CD привод для чтения оптических дисков;
• ­ PC совместимый принтер.

Размер файлов отчетов со временем будет увеличиваться, поэтому рекомендуется свободного места на жестком диске не меньше 5ГБ.

Для корректной работы сервера СУБД необходимо наличие компьютера с архитектурой совместимой с I386 и операционной системой Windows XP, Windows 2000, Windows Vista, с установленным MS SQL SERVER 2000.

Минимальные системные требования для аппаратного обеспечения:

• ­ оперативная память 512Мб;
• ­ процессор с тактовой частотой 1000 MHz;
• ­ свободное место на жестком диске 5Гб;
• ­ видеосистема SVGA 800Ч600;
• ­ клавиатура;
• ­ мышь;
• ­ CD привод для чтения оптических дисков.

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

• ­ оперативная память 1024Мб;
• ­ процессор с тактовой частотой 2000 MHz;
• ­ свободное место на жестком диске 20Гб;
• ­ видеосистема SVGA 800Ч600;
• ­ клавиатура;
• ­ мышь;
• ­ CD привод для чтения оптических дисков.

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

Интерфейс программы строился по принципу «минимум кнопок, максимум удобства». Главное окно программы показано на рисунке 12.

Рисунок 12 — Главное окно программы

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

• ­ справочник инженеров;
• ­ поиск;
• ­ печать;
• ­ экспорт в excel;
• ­ добавление, изменение, удаление записи;
• ­ фильтр по значениям ячеек;
• ­ функция быстрый поиск по номеру заказа;
• ­ фильтр по дате;
• ­ настройка интерфейса.

Окно «Поиск» показано на рисунке 13. В нем мы можем производить поиск, как по какому-то отдельному критерию, так и сразу по нескольким.

Рисунок 13 — Окно «Поиск»

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

Окно редактирования данных показано на рисунке 14.

Рисунок 14 — Редактирование данных

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

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

­ принято в ремонт

­ тестовый прогон

­ ожидание детали

­ отремонтирован

­ выдан клиенту

По умолчание при добавлении новой записи статус телефона установлен в значение «принято в ремонт».

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

Рисунок 15 — «Справочник инженеры»

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