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

 

Содержание

Введение

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 Экологическая оценка

Заключение

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

Приложения

Введение

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

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

рациональное использование ресурсов;

улучшение обслуживания клиентов;

учет бизнес-процедур;

эффективная отчетность о результатах;

облегчение работы персонала.

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

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

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

значительно сократить денежные и трудозатраты;

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

повысить качество обслуживания клиентов;

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

сократить время, потраченное на распределение объема работ;

оптимизировать внутренние процессы, связанные с ремонтом телефонов;

отслеживать статистику выполненной и текущей работы;

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

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

информационная система база менеджер

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В последние годы в мире получили широкое распространение CRM-системы On-demand (или SaaS), снимающие ограничения для использования территориально-распределенными компаниями.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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-решений.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

интерфейсы и распределение функций между человеком и системой;

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

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

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

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

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

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

1.6.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-средствах виды моделей.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

управление доступом к БД;

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

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

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

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

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

управление логикой приложения;

выполнение логики приложения;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рекламный отдел занимается рекламой.

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

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

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

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

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

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

сложности проектируемой системы;

необходимой полноты ее описания;

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

времени, отведенного на проектирование.

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

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

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

Функциональную структуру системы;

Последовательность выполняемых действий;

Передачу информации между функциональными процессами;

Отношения между данными.

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

функциональная модель 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).

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

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

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

утверждение общих стандартов (соглашений) моделирования и документирования системы;

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

формирование набора основных абстракций предметной области (классов анализа);

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

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

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

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

определение атрибутов и ассоциаций классов.

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

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

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

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

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

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

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

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

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

проектирование архитектуры системы;

проектирование элементов системы.

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

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

анализ взаимодействий между классами анализа, выявление подсистем и интерфейсов;

формирование архитектурных уровней;

проектирование конфигурации системы.

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

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

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

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

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

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

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

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

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

Рисунок 4 - Декомпозиция первого уровня

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

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

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

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

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

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

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

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

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

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

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

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

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

Теория систем массового обслуживания начала развиваться в начале 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)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3 Реализация

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

3.1.1 Borland Delphi

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

Для реализации поставленных перед подсистемой задач выбрано средство разработки приложение 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 корпоративных кроссплатформенных отчетов обеспечивает высокую эффективность работы приложения.

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

3.1.2 MS SQL Server

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]. Данный тип дублирования предусматривает возможность разрешения противоречий между БД.

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

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

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

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

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

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

Для корректной работы данной программы на стороне клиента необходимо наличие компьютера с архитектурой совместимой с 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.

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

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

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

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

справочник инженеров;

поиск;

печать;

экспорт в excel;

добавление, изменение, удаление записи;

фильтр по значениям ячеек;

функция быстрый поиск по номеру заказа;

фильтр по дате;

настройка интерфейса.

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

Рисунок 13 - Окно "Поиск"

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

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

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

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

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

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

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

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

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

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

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

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

Рисунок 15 - "Справочник инженеры"

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

На Рисунке 16 показано добавление нового инженера.

Рисунок 16 - Добавление нового инженера в справочник

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

Рисунок 17 - Настройка интерфейса системы

Разработанная система позволяет распечатать квитанции для клиента. Например, печать наряда-заказа и квитанции показана на рисунках 18 и 19. Квитанцию клиент забирает себе, и предъявляет её при получении отремонтированного телефона, в случае утери квитанции мы всегда сможет идентифицировать клиента по ФИО или другим данным.

В квитанции распечатываются основные данные, такие как:

модель;

серийный номер;

IMEI;

серийный номер батареи;

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

неисправность со слов клиента;

стоимость ремонта;

замечания, внешний вид;

дата приёма;

инженер.

В квитанции "наряд-заказ" печатается следующая информация:

ФИО клиента;

адрес;

контактный телефон;

модель телефона сданного в ремонт;

серийный номер;

IMEI;

серийный номер батареи;

комплектность;

неисправность со слов клиента;

стоимость ремонта;

замечания, внешний вид;

дата приёма;

дата выдачи;

инженер.

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

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

Рисунок 18 - Предпросмотр наряд-заказа перед печатью

Рисунок 19 - Предпросмотр квитанции перед печатью

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

Рисунок 20 - Экспорт данных в xls формат

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

Рисунок 21 - Система оповещения

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

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

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

основными причинами использования резервного копирования являются выход из строя компонентов сервера (например, жесткого диска) или программные ошибки, которые могут привести к разрушению базы данных [19]. При выборе решения о резервном копировании эти причины необходимо учитывать;

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

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

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

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

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

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

Рассмотрим некоторые из них:

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

протоколы (или порты в случае использования TCP/IP), по которым осуществляется доступ к БД, должны быть настраиваемыми. Если доступ к БД возможен при помощи специализированного клиента или через протокол http, то сервер должен предоставлять администратору системы возможность выбирать или запрещать доступ через определенный порт;

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

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

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

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

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

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

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

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

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

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

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

В качестве товара-конкурента разрабатываемому программному продукту была выбрана "ASoft CRM 2009".CRM 2009 - мощное профессиональное решение по управлению обслуживанием пользователей (сотрудников и/или клиентов) вашего предприятия, основанное на рекомендациях ITIL и реализующее важнейшие процессы ITSM - управление инцидентами, уровнем обслуживания и конфигурацией.CRM 2009 - инструмент повышения эффективности службы поддержки в соответствии с рекомендациями ITIL. Использование ASoft CRM 2009 помогает организовать и поддерживать следующие процессы:

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

Управление уровнем обслуживания (Service Level Management) - формирование каталога услуг, предоставляемых сервисным подразделением и выполнение работ в соответствии с договорными обязательствами.

Управление конфигурацией (Configuration Management) - ведение учета обслуживаемых объектов и работа с аналитической информацией для определения причин возникновения инцидентов.

Решение ASoft CRM 2009 обеспечивает:

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

стандартный способ регистрации и выдачи заданий специалистам;

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

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

информирование пользователя об этапах выполнения заявки;

эскалацию запросов и инцидентов;

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

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

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

ведение каталога услуг;

формирование и ведение единого списка обслуживаемых объектов;

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

Характеристики товара-конкурента:

Год издания - 2009

Договорная цена - 96600 р.,

Продажная цена - 107000 р.,

Машинное время для решения задач - 8 ч/день,

Срок службы программы - 5 лет.

Источник - <#"center">4.1.3 Расчет затрат на разработку ПС и договорной цены

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

Цены на материалы и специальное оборудование взяты из прайс-листа фирмы "РЕТ" от 03.04.2009 года.

Таблица 1 - Расчет стоимости основных материалов

Наименование материалов и покупных изделийКол-воЦена за ед., р. Сумма, р. Флеш-накопитель, шт. 1580580Бумага в упаковке, шт. 2150300Письменные принадлежности: Набор шариковых ручек 1 50 50Всего 930Транспортно-заготовительные расходы (15%) 139,50 Итого 1069,5

Рассчитаем затраты на использование компьютерной техники в период создания ПП. В Таблице 2 приведена стоимость специального оборудования (согласно прайс-листу фирмы "РЕТ" от 03.04.2009).

Таблица 2 - Стоимость специального оборудования

Наименование оборудованияКоличествоСтоимость, рублей1. ПК РЕТ1150002. Принтер Lexmark E15013500,00Всего 18500,00Транспортно-заготовительные расходы (15%) 2775,00 Итого 21275,00

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

В соответствии с производственным календарем имеем:

Календарные дни - 365;

Рабочие дни - 249;

Выходные и праздничные дни - 116;

Номинальный фонд времени - 1987 час;

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

Расчеты стоимости одного машино-ч приведены в таблице 3.

Затраты на электроэнергию определим по формуле (8).

, (8)

где - стоимость одного кВт·ч (текущий тариф составляет 1.99 р.);

- мощности ЭВМ и принтера (соответственно 0.25 и 0.06 кВт);

- полезный фонд времени работы спецоборудования (1713 ч).

Таблица 3 - Расчет стоимости одного машинного часа

Наименование статьи затратМетодика расчетаСумма, р. 1) Затраты на электроэнергию, Z11056,72) Затраты на техобслуживание оборудования, Z225 % от стоимости спецоборудования 46253) Амортизация оборудования за год, Z337004) Текущие расходы, РТ

9381,7Стоимость одного машино-часа6

Амортизацию оборудования за год определим по формуле (9).

, (9)

где - стоимость оборудования, р.;

- срок эксплуатации оборудования (5 лет, исходя из годовой нормы амортизации 15 %);

Количество отработанных часов ЭВМ рассчитывается исходя из количества дней потраченных на разработку продукта (50 дней) и количества рабочих часов ЭВМ в день (8 ч): 50*8=400 ч. Для разработки данного продукта принтер использовался в течение 8 часов.

Данные и результаты расчета затрат на использование специального оборудования приведены в таблице 4.

Таблица 4 - Расчет затрат на использование специального оборудования для автоматизации разработки нового продукта

Наименование оборудованияСтоимость часа, р. Количество отработанных часов, чСумма, р. 1. ПК РЕТ6 400 24002. Принтер Lexmark E1206848Итого2448

Рассчитаем затраты на основную и дополнительную зарплату исполнителей и занесем в таблицы 5 и 6.

Таблица 5 - Основная заработная плата

Наименование должностиКоличествоКвалификационный уровеньОклад, руб. Научный руководитель1155000Научный консультант1155000Исполнитель1104800

Таблица 6 - Расчет заработной платы исполнителей

ДолжностьОклад + дополнительная з/п., р/мес. Время разработки, ч. Стоимость одного часа, р/часЗаработная плата, р. Научный руководитель5000*1,4+2800+3000= 12800211182478Научный консультант5000*1,4+2800+3000 =128003118354Исполнитель48003184413992Итого: 16824

Единый социальный налог вычисляется как процент (26%) от общей заработной платы и составляет:

РЕСН=16824*0,26=4374,24 р.

Таблица 7 - Расчет себестоимости и договорной цены разработки

Наименование статей затратСумма, руб. 1. Материалы и покупные изделия1069,52. Стоимость специального оборудования21275,003. Общая заработная плата 168244. Единый социальный налог = 26% от общей з/п. 4374,245. Накладные расходы =15% от общей з/п. 2523,66. Сметная стоимость46066,347. Прибыль =20% от сметной стоимости9213,38. Договорная цена = сметная стоимость + прибыль55279,6

Договорная цена разработки:

,34+9213,3=55279,6 р.

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

,6+55279,6*0,18=65230 р.

Расчет продажной цены ПП:

(10)

где - договорная цена программного продукта;

- транспортные расходы (15% от договорной цены);

- наценка торговых организаций (3% от договорной цены).

То есть, продажная цена разработанного программного продукта составит:

Цпр = 55279,6+ 8291,85 + 1658,37 = 65230 руб.

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

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

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

К=К1-К2. (11)

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

К1 = (ТМВ1*КЭВМ/ТПОЛН) + Ц1, (12)

К2 = (ТМВ2*КЭВМ/ТПОЛН) + Ц2, (13)

где ТМВ1 - машинное время, необходимое потребителю для решения задач в базовой модели за год, машино-часов;

ТМВ1 = 249*2= 498 машино-часов;

ТМВ2 - машинное время, необходимое потребителю для решения задач в новом варианте за год, машино-часов;

ТМВ2 = 249*1 = 249 машино-часа;

- капитальные вложения в ЭВМ, р.;

- полезный годовой фонд работы ЭВМ, ч.;

- продажная цена базовой программы, р.,

- продажная цена нового (разработанного) ПП.

К=112332-57945=54387руб

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

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

(14)

где

Тмв1 и Тмв2 машинное время ЭВМ за год соответственно для базового и нового вариантов, ч;

КЭВМ - капитальные вложения в ЭВМ и принтер, руб.,

Тпол - полезный годовой фонд работы ЭВМ, ч.

Кэ2/1 = (498 - 249) × 21275/ 1987 = 2666 руб

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

Издержки, связанные с эксплуатацией программного продукта определяются по формуле:

И = Тмв × Ич + Ц / Тс (15)

где Тмв - машинное время ЭВМ, затрачиваемое на решение одной задачи, ч.;

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

Ц - цена программного продукта;

Тс - срок использования программного продукта.

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

Ин = 249 × 25,4 + 55279,6/ 1 = 61603 руб

Иб = 249 × 25,4 + 107000 /1 = 113324 руб

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

Годовая экономия стоимости машинного времени у потребителя программы определяется по формуле:

Эмз = (Тмв1 - Тмв2) ×Ич (16)

где Ич - эксплуатационные издержки приходящиеся на 1 час машинного времени, р;

Тмв1 и Тмв2 - машинное время, затрачиваемое на решение одной задачи соответственно в базовом и новом вариантах, ч.

Эмз = 25,4 × (498-249) = 6325 руб

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

Экономическую эффективность внедрения нового программного продукта характеризуют относительной экономией капитальных вложений:

DК = (К1 - К2) ×100 %/ К1 (17)

где К1 и К2 - капитальные вложения, связанные с использованием программ соответственно в базовом и новом варианте, р.

DК = (112332 - 57945) ×100/112332 = 48%

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

Относительная экономия эксплуатационных издержек потребления определяется по формуле:

DЭ = (И1 - И2) ×100 %/ И1 (18)

где И1 и И2 - эксплуатационные издержки потребления соответственно в базовом и новом варианте, р.

В соответствии с формулой получим:

DЭ = (113324 - 61603) ×100 /113324 = 45%

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

Годовой экономический эффект пользователя программного продукта рассчитывается по формуле:

Эг2/1 = (И1 - И2) - Ен × (К1 - К2), (19)

где Ен - нормативный коэффициент (Ен = 0,15)

Эг2/1 = (113324 - 61603) - 0,15 × (112332 - 57945) = 43562 руб

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

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

Рп = n× Эг2/1 (20)

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

Эг2/1 - годовой экономический эффект, р.;

В нашем случае как минимум n = 1, следовательно, годовой экономический потенциал разработки составляет:

Рп = 1×43562 = 43562 руб

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

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

Цп = Цпр + И×Тс (21)

где Цпр - продажная цена программного продукта, р;

И - эксплуатационные издержки, р.

Тс - срок использования программного продукта, лет.

Цпб = 107000 + 113324 ×5 = 673620 руб

Цпн = 55279 + 61603 ×5 = 363294 руб

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

Таблица 8 - Экономические показатели эффективности разработанного программного продукта

Наименование параметраБазовый ППНовый ПП1. Договорная цена, р. 9660055279,62. Продажная цена, р. 107000652303. Цена потребления, р. 6736203632944. Капитальные вложения в использование разработанного ПП, р. 112332579455. Экономия капиталовложений, р. 26666. Эксплуатационные издержки, р. 113324616037. Годовая экономия стоимости машинного времени, р. 63258. Относительная экономия капитальных вложений, %489. Относительная экономия эксплуатационных расходов, %4510. Годовой экономический эффект, р. 4356211. Годовой экономический потенциал, р. 43562

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

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

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

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

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

, (22)

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

Коэффициент технического уровня рассчитывается по формуле:

, (23)

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

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

Таблица 9 - Технические параметры для расчёта коэффициента эквивалентности

ПараметрыВПэПбПнКтбКтн Удобство интерфейса0,310,70,80,210,24Время обработки введенных данных, с 0,210,80,90,160,18Надежность, %0,410,70,80,320,32Объем программного продукта на диске, Мб 0,1 1 0,6 0,7 0,06 0,07Итого0,750,81

По данным таблицы 9 рассчитаем коэффициент эквивалентности:

Таким образом, по техническому уровню новый ПП превышает базовый.

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

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

, (24)

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

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

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

Перечень показателейХарактеристические параметры базового ППХарактеристические параметры нового ППБальная оценка базового ППБальная оценка нового ПП1. Технические показатели: 1.1 Скорость работысредняяХорошая221.2 Функциональные возможностихорошиеВысокие332. Эстетические показатели: 2.1 Простота использованияхорошая Высокая232.2 Дружественный интерфейс++233. Эргономические показатели3.1 Степень утомляемостиработает до 10 часовработает до 10 часов223.2 Производительность трудасредняяВысокая34Итого1417

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

. (25)

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

Рассчитаем коэффициент цены потребления:

Кц = Цпн/Цпб, Кц=363294/673620=0,54

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

(26)

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

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

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

. (27)

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

= (55279,6-46066,34) / 21275=0,43

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

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

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

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

ростом конкуренции на все более насыщаемых товарных рынках;

возрастанием желаний покупателей иметь возможности решения проблем, возникающих в процессе использования приобретенного товара;

усложнением процесса эксплуатации товара.

Основными функциями сервиса как инструмента маркетинга являются:

привлечение покупателей;

поддержка и развитие продаж товара;

информирование покупателя.

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

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

Существует ряд общепринятых норм, соблюдение которых предостерегает от ошибок:

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

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

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

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

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

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

В основные задачи сервиса входит:

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

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

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

предпродажная подготовка программного изделия во избежание малейшей возможности отказа в его работе во время демонстрации потенциальному покупателю;

доставка, установка и приведение в рабочее состояние программного изделия на место эксплуатации;

демонстрация программного изделия покупателю в действии;

обеспечение полной готовности изделия к эксплуатации в течение всего срока нахождения его у потребителя;

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

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

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

формирование постоянной клиентуры.

Этапы организации сервисного обслуживания приведены на рисунке 22.

Рисунок 22 - Этапы организации сервисного обслуживания

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

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

1 доставка и установка разработки на компьютер покупателя (заказчика) - 3 часа;

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

1 обновление программного продукта на более новую версию с вызовом специалиста на 1 час.

Калькуляция затрат на сервисное обслуживание приведена в таблице 11.

Таблица 11 - Калькуляция затрат на сервисное обслуживание

Наименование статей затрат1. Основная заработная плата исполнителей 2. Дополнительная заработная плата3. ЕСН 4. Накладные расходы 5. Прочие прямые расходы 9. Сметная стоимость сервисного обслуживания

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

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

Рисунок 23 - Анализ экономических показателей эффективности разработанного ПП.

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

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

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

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

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

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

Допустимые уровни звукового давления, уровни звука и эквивалентные уровни звука на рабочих местах, должны соответствовать требованиям ГОСТ 12.1.003-83 "Шум. Общие требование безопасности". При выполнении основной работы на ЭВМ, т.е. помещения программистов вычислительных машин, лабораторий для теоретических работ и обработки экспериментальных данных, где производятся творческие работы, уровень шума на рабочем месте не должен превышать 50 дБА. В помещениях управления (рабочих комнатах), где работают инженерно-технические работники, уровень шума не должен превышать 60 дБА.

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

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

В соответствии с ГОСТ 12.1.003-83 защита от шума, создаваемого на рабочих местах внутренними источниками, а также шума, проникающего извне, осуществляется следующими методами:

уменьшением шума в источнике;

рациональной планировкой и акустической обработкой рабочих помещений.

Как правило, снижение уровня шума достигается рациональной планировкой помещений, а также применением качественного монтажа оборудования [22].

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

изолировать источник шума или вибрации от окружающей среды средствами звуко- и виброизоляции;

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

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

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

С целью обеспечения комфортных условий для обслуживающего персонала и надежности технологического процесса в организации устанавливают дополнительные требования к воздушной среде помещений. Так, в зале операторов ЭВМ температура воздуха должна быть 20<t<25 С. Относительная влажность воздуха в зале рекомендуется 55+5%.

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

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

рациональная планировка помещений при строительстве;

применение систем вентиляции и кондиционирования.

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

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

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

Требования по организации вентиляции регламентируются СНиП 11-33-86 (раздел "Вентиляция, отопление и кондиционирование воздуха").

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

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

Согласно действующим строительным нормам и правилам СНиП 23-05-95 для искусственного освещения регламентирована наименьшая допустимая освещенность рабочих мест, а для естественного и совмещенного - коэффициент естественной освещенности КЕО.

Нормы освещенности зависят от принятой системы освещения. Так, при комбинированном искусственном, освещении как более экономичном, нормы выше, чем при общем. Освещенность, создаваемая светильниками общего освещения, должно составлять 10% от нормируемой для комбинационного освещения. При этом наибольшее и наименьшее значения освещенности для люминесцентных ламп должны составлять 500 и 150 лк, а для ламп накаливания - 100 и 50 лк.

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

Исходя из того, что в вычислительных центрах проводится зрительная работа высокой точности, рекомендуемая освещенность для работы с экраном дисплея составляет 200 лк, а при работе с экраном в сочетании с работой над документами - 400 лк. Рекомендуемые яркости в поле зрения операторов должны лежать в пределах 1: 5-1: 10.

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

Для правильной расстановки оборудования и распределения рабочих мест с различной степенью зрительного напряжения необходимо определять коэффициент естественной освещенности в помещении. Световой поток, падающий в расчетную точку кабинета, складывается из прямого диффузного света небосвода, отраженного от внутренних поверхностей помещения и противостоящих зданий. Рассчитаем КЕО при боковом освещении кабинета. Кабинет размером 8х5м и высотой помещения над рабочей поверхностью НР=4 м, имеется 3 окна размером 1,5х2 м. Планировка зала изображена на рисунке 24.

Рисунок 24 - Планировка кабинета с ПЭВМ

КЕО при боковом освещении рассчитывается по формуле:

, (28)

где ? бq + ? здR - выражение, определяющее часть КЕО, создаваемого светом, проникающим извне;

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

- общий коэффициент светопропускания, который характеризует потерю света в материале остекления, в переплетах светопроема в слое загрязнения и в солнцезащитных устройствах;- коэффициент, учитывающий повышение КЕО за счет отраженного света от потолка и стен помещения;

КЗ - Коэффициент запаса.

Геометрическое значение КЕО в расчетной точке (%) помещения определяется по формуле:

, (29)

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

При n1=25 и n2 =12 находим геометрический коэффициент естественной освещенности:

Геометрический коэффициент естественной освещенности, рассчитывается по формуле:

, (30)

где n11, n21 - количество лучей, проходящих от противостоящего здания через световой проем в расчетную точку на поперечном разрезе помещения.

При n11 = 6, n21 = 3 находим геометрический коэффициент

Общий коэффициент светопропускания определим по формуле:

, (31)

где - коэффициент светопропускания материала (=0,8);

- коэффициент, учитывающий потери света в переплетениях светопроема (= 0,6);

- коэффициент, учитывающий потери света в несущих конструкциях (= 1, при боковом освещении);

- коэффициент, учитывающий потери света в защитной сетке, устанавливаемой под фонарями (=0,9);

- коэффициент, учитывающий потери света в солнцезащитных устройствах (= 1).

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

Учитывая, что q = 0,52, R = 0,18, КЗ = 1,2; r =3,6 и результаты, которые получились в результате расчетов по формулам (29) - (31) по формуле (28) определим КЕО

Как видно полученная величина, в результате расчетов, (Еб = 2,06) соответствует нормативным уровням по СниП II-4-79.

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

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

Электромагнитные поля радиочастот имеют большой диапазон длин волн - от 3 км до 1 мм. Степень вредного воздействия электромагнитных полей (ЭМП) радиочастот на человека зависит от интенсивности, времени действия и длины волны источника.

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

Биологическая активность ЭМП возрастает с уменьшением длины волны, самая высокая активность ЭМП - в области СВЧ.

В целях обеспечения здоровья работающих и предупреждения профессиональных заболеваний предельно допустимые значения напряженности и плотности потока энергии электромагнитных полей регламентируются ГОСТ ССБТ 12.1.006 - 84 "Электромагнитные поля радиочастот. Общие требования безопасности".

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

При проектировании новых зданий и кабинетов необходимо соблюдать мероприятия пожарной профилактики ("Инструкции по проектированию зданий и помещений для ЭВМ " и СНиП 11-2-80 "Противопожарные нормы проектирования зданий и сооружений "), где изложены основные требования к огнестойкости зданий, противопожарным преградам, эвакуации людей из зданий и помещений.

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

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

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

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

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

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

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

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

Кратковременность процесса вынужденной эвакуации достигается устройством эвакуационных путей и выходов, число, размеры и конструктивно-планировочные решения которых регламентированы строительными нормами СНиП 2.01.02-85.

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

Рисунок 25 - Схематическое изображение помещения и план эвакуации

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

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

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

Таблица 12 - Предельно допустимые уровни напряжений прикосновения и токов (время нахождения под напряжением 10 мин.)

Частота, ГцНапряжение, ВТок, мА5030.4

Основное питание ПК осуществляется от трехфазной сети частотой 50 Гц, напряжением 380/220 В. Для питания же отдельных устройств используются однофазные сети как переменного, так и постоянного тока с напряжением от 5 до 380 В.

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

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

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

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

Заключение

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

Был произведен анализ и расчет показателей в области безопасности жизненной деятельности при создании и использовании разработанной продукции. Было установлено, что все ГОСТы и санитарные нормы, действующие на территории Российской Федерации, полностью соблюдены. Выполнение организационно-экономических расчетов, показало, что разработанный программный продукт является конкурентоспособным по всем рассчитанным параметрам. И внедрение этого продукта является выгодным для ОАО "Орбита сервис".

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

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

1.Ю.С. Избачков, В.Н. Петров. CRM системы. Издательство: Питер, 2008 г. - 656 с.

2.Гайдамакин Н.А. Автоматизированные информационные системы, базы и банки данных. / Н.А. Гайдамакин. - М.: "Гелиос АРВ" 2002. - 97 с.

.Чопоров О. Н, Бухонова О.В. Базы и Банки Данных / Воронеж: Воронеж. гос. техн. ун-т, 2000.146 с.

.Джен Л. Харрингтон. Проектирование реляционных баз данных. Издательство: Лори, 2006 г. - 230 с.

.Рэймонд Фрост, Джон Дей, Крейг Ван Слайк. Базы данных. Проектирование и разработка. Издательство: НТ Пресс, 2007 г. - 592 с.

.Рындин А.А., Хаустович А.В., Долгих Д.В. Проектирование корпоративных информационных систем. / под ред.А. А. Рындина. Воронеж: Издательство "Кварта", 2003. - 448 с.

.Советов Б. Я, Яковлев С.А. Моделирование систем. Издательство: Вильямс, 2006 г. - 340 с.

.Тихоненко О.М. Модели массового обслуживания в информационных системах. Издательство: Бином, 2006 2003 г. - 327 с.

.Программирование Deplhi 29-2001. Архангельский C. F.: Москва 2003.757с.

.Бобровкий А.С., Delphi 7. Учебный курс. Издательство: Питер, 2006 г.736 с.

.Фаронов В.А., Программирование на языке высокого уровня. Издательство: Питер, 2006 год.640 с.

.Анатолий Хомоненко, Владимир Гофман, Евгений Мещеряков, Владимир Никифоров. Delphi 7. Наиболее полное руководство. Издательство: BHV - Санкт - Петербург, 2006 г. - 1216 с.

.С.В. Глушаков, А.Л. Клевцов. Delphi 7. Издательства: АСТ, АСТ Москва, Хранитель, 2007 г. - 640 с.

.Виктор Пестриков, Артур Маслобоев. Delphi на примерах. Издательство: БХВ-Петербург, 2005 г. - 496 с.

.Луис Дэвидсон. Проектирование баз данных на SQL Server 2000. Издательство: Бином. Лаборатория знаний, 2003 г. - 662 с.

.Энтони Молинаро. SQL. Сборник рецептов. Издательство: Символ-Плюс, 2009 г. - 672 с.

.Мартин Грабер. SQL. Справочное руководство Издательство: Лори, 2006 г. - 368 с.

.Роберт Вьейра. SQL Server 2000. Программирование. Издательство: Бином. Лаборатория знаний, 2004 г. - 808 с.

.Эйри Джоунс, Райан К. Стивенз, Рональд Р. Плю, Роберт Ф. Гарретт, Алекс Кригель. Функции SQL. Справочник программиста. Издательство: Вильямс, 2006 г. - 768 с.

.Лабораторный практикум по экономике производства. / Самогородская М. И.: Воронеж, 2001.88 с.

.Практикум по экономике производственной деятельности. / Самогородская М. И.: Воронеж, 2003.118 с.

.Безопасность жизнедеятельности: Учебное пособие. Ч.2 /Е.А. Резчиков, В.Б. Носов, Э.П. Пышкина, Е.Г. Щербак, Н.С. Чверткин /Под редакцией Е.А. Резчикова. М.: МГИУ, - 1998.

Приложения

Приложение А (Листинг программы)

Unit1;, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,, ComCtrls, ToolWin, Grids, DBGrids, ExtCtrls, Menus, DB, ADODB,, ActnList,xpman, StdCtrls, Buttons, RpCon, RpConDS, RpDefine,, UComboBox, DBTables, RpBase, RpSystem, RpRender, RpRenderCanvas,, IniFiles, JanHDBGrid;= class (TForm): TADOConnection;: TADOQuery;: TDataSource;: TMainMenu;: TMenuItem;: TPanel;: TPanel;: TToolBar;: TToolButton;: TToolButton;: TToolButton;: TToolButton;: TActionList;: TAction;: TAction;: TAction;: TAction;: TMenuItem;: TMenuItem;: TMenuItem;: TMenuItem;: TMenuItem;: TAction;: TToolButton;: TAction;: TImageList;: TToolButton;: TAction;: TImageList;: TMenuItem;: TMenuItem;: TMenuItem;: TBitBtn;: TRvDataSetConnection;: TRvProject;: TToolButton;: TAction;: TMenuItem;: TMenuItem;: TToolButton;: TAction;: TMenuItem;: TPopupMenu;: TMenuItem;: TMenuItem;: TAction;: TAction;: TMenuItem;: TMenuItem;: TAction;: TMenuItem;: TMenuItem;: TAction;: TAction;: TAction;: TMenuItem;: TMenuItem;: TMenuItem;: TMenuItem;: TMenuItem;: TMenuItem;: TMenuItem;: TToolButton;: TAction;: TDateTimePicker;: TDateTimePicker;: TRvSystem;: TLabel;: TPopupMenu;: TMenuItem;: TMenuItem;: TAction;: TAction;: TMenuItem;: TToolButton;: TToolButton;: TAction;: TAction;: TMenuItem;: TMenuItem;: TMenuItem;: TMenuItem;: TMenuItem;: TCheckBox;: TMenuItem;: TMenuItem;: TEdit;: TSpeedButton;: TLabel;: TJanHDBGrid;ADDExecute (Sender: TObject);DELETEExecute (Sender: TObject);EDITExecute (Sender: TObject);FINDExecute (Sender: TObject);actEXITExecute (Sender: TObject);INGENIRESExecute (Sender: TObject);PrintExecute (Sender: TObject);FormShow (Sender: TObject);ActUpdateExecute (Sender: TObject);SortExecute (Sender: TObject);SortDatePriemaExecute (Sender: TObject);SortStatusExecute (Sender: TObject);SortByIDExecute (Sender: TObject);SortByFIOExecute (Sender: TObject);SortByENGFIOExecute (Sender: TObject);SortByModelExecute (Sender: TObject);ChooseExecute (Sender: TObject);DBGrid1DblClick (Sender: TObject);BeginDateChange (Sender: TObject);EndDateChange (Sender: TObject);ActPrintExecute (Sender: TObject);ActPreviewExecute (Sender: TObject);FormClose (Sender: TObject; var Action: TCloseAction);ActEndExecute (Sender: TObject);ActHomeExecute (Sender: TObject);CheckBox1Click (Sender: TObject);N27Click (Sender: TObject);FormCreate (Sender: TObject);N29Click (Sender: TObject);FSBClick (Sender: TObject);FEditKeyDown (Sender: TObject; var Key: Word;: TShiftState);FEditKeyPress (Sender: TObject; var Key: Char);DBGrid1MouseDown (Sender: TObject; Button: TMouseButton;: TShiftState; X, Y: Integer);JanHDBGrid1DblClick (Sender: TObject);

{ Private declarations }

{ Public declarations }GridWidth;InitFormFAdd;InitFormFFind;SaveSettings;LoadSettings;LoadDate;

{ procedure IsReg;WriteEndUse; };: TFMain;: integer;: TIniFile;Unit2, Unit3, Unit4, Unit5, Unit6, Unit7, Unit8;

{$R *. dfm}

{procedure TFMain. WriteEndUse;: TIniFile;: =TIniFile. Create ('Rconf. ini');. WriteString ('SK','NSK','NR');. Free;; }

{procedure TFMain. IsReg;: string;: TIniFile;: =TIniFile. Create ('Rconf. ini');: =RInf. ReadString ('SK','p',p);p='ljkkfh' then('Время использования пробной версии программы истекло'

+#13+'для получения полной версии обратитесь к разработчикам');. Terminate;;. Free;; }TFMain. LoadDate;: =TIniFile. Create (ExtractFilePath (Application. ExeName) +'DBconfig. ini');. Date: =ConfFile. ReadDate ('Date','BeginDate',BeginDate. Date);. Date: =ConfFile. ReadDate ('Date','EndDate',EndDate. Date);. Free;;TFMain. LoadSettings;: =TIniFile. Create (ExtractFilePath (Application. ExeName) +'DBconfig. ini');. Columns [0]. Width: =ConfFile. ReadInteger ('GridColumns','Column0',DBGrid1. Columns [0]. Width);. Columns [1]. Width: =ConfFile. ReadInteger ('GridColumns','Column1',DBGrid1. Columns [1]. Width);. Columns [2]. Width: =ConfFile. ReadInteger ('GridColumns','Column2',DBGrid1. Columns [2]. Width);. Columns [3]. Width: =ConfFile. ReadInteger ('GridColumns','Column3',DBGrid1. Columns [3]. Width);. Columns [4]. Width: =ConfFile. ReadInteger ('GridColumns','Column4',DBGrid1. Columns [4]. Width);. Columns [5]. Width: =ConfFile. ReadInteger ('GridColumns','Column5',DBGrid1. Columns [5]. Width);. Columns [6]. Width: =ConfFile. ReadInteger ('GridColumns','Column6',DBGrid1. Columns [6]. Width);. Columns [7]. Width: =ConfFile. ReadInteger ('GridColumns','Column7',DBGrid1. Columns [7]. Width);. Columns [8]. Width: =ConfFile. ReadInteger ('GridColumns','Column8',DBGrid1. Columns [8]. Width);. Columns [9]. Width: =ConfFile. ReadInteger ('GridColumns','Column9',DBGrid1. Columns [9]. Width);. Columns [10]. Width: =ConfFile. ReadInteger ('GridColumns','Column10',DBGrid1. Columns [10]. Width);. Columns [11]. Width: =ConfFile. ReadInteger ('GridColumns','Column11',DBGrid1. Columns [11]. Width);. Columns [12]. Width: =ConfFile. ReadInteger ('GridColumns','Column12',DBGrid1. Columns [12]. Width);. Columns [13]. Width: =ConfFile. ReadInteger ('GridColumns','Column13',DBGrid1. Columns [13]. Width);. Columns [14]. Width: =ConfFile. ReadInteger ('GridColumns','Column14',DBGrid1. Columns [14]. Width);. Columns [15]. Width: =ConfFile. ReadInteger ('GridColumns','Column15',DBGrid1. Columns [15]. Width);. Columns [16]. Width: =ConfFile. ReadInteger ('GridColumns','Column19',DBGrid1. Columns [19]. Width);. Columns [20]. Width: =ConfFile. ReadInteger ('GridColumns','Column20',DBGrid1. Columns [20]. Width);. Free;;

// ширина полей в DBGridTFMain. GridWidth;. Columns [20]. Index: =2;. Columns [20]. Index: =10;. Columns [20]. Index: =3;. Columns [7]. Index: =4;. Columns [9]. Index: =5;. Columns [14]. Index: =6;

{DBGrid1. Columns [0]. Width: =50;. Columns [1]. Width: =60;. Columns [2]. Width: =150;. Columns [3]. Width: =180;. Columns [4]. Width: =180;. Columns [5]. Width: =70;. Columns [6]. Width: =90;. Columns [7]. Width: =100;. Columns [8]. Width: =100;. Columns [9]. Width: =100;. Columns [10]. Width: =160;. Columns [11]. Width: =50;. Columns [12]. Width: =160;. Columns [13]. Width: =150;. Columns [14]. Width: =60;. Columns [15]. Width: =60; }. Columns [17]. Visible: =False;. Columns [18]. Visible: =False;. Columns [19]. Visible: =False;

// DBGrid1. Columns [19]. Width: =150;;. Columns [0]. Title. Caption: ='№ заказа';. Columns [1]. Title. Caption: ='Дата приёма';. Columns [2]. Title. Caption: ='Статус';. Columns [7]. Title. Caption: ='Ф. И.О. ';. Columns [8]. Title. Caption: ='Адрес';. Columns [9]. Title. Caption: ='Телефон';. Columns [4]. Title. Caption: ='Модель';. Columns [10]. Title. Caption: ='S/N';. Columns [5]. Title. Caption: ='IMEI';. Columns [11]. Title. Caption: ='S/N Батареи';. Columns [12]. Title. Caption: ='Комплектность';. Columns [13]. Title. Caption: ='Стоимость';. Columns [14]. Title. Caption: ='Замечания, внешний вид';. Columns [6]. Title. Caption: ='Неисправность со слов клиента';. Columns [15]. Title. Caption: ='Дата выдачи';. Columns [16]. Title. Caption: ='Дата покупки';. Columns [3]. Title. Caption: ='Инженер';. Columns [20]. Title. Caption: ='Примечания';;TFMain. SaveSettings;: =TIniFile. Create (ExtractFilePath (Application. ExeName) +'DBconfig. ini');. WriteInteger ('GridColumns','Column0',DBGrid1. Columns [0]. Width);. WriteInteger ('GridColumns','Column1',DBGrid1. Columns [1]. Width);. WriteInteger ('GridColumns','Column2',DBGrid1. Columns [2]. Width);. WriteInteger ('GridColumns','Column3',DBGrid1. Columns [3]. Width);. WriteInteger ('GridColumns','Column4',DBGrid1. Columns [4]. Width);. WriteInteger ('GridColumns','Column5',DBGrid1. Columns [5]. Width);. WriteInteger ('GridColumns','Column6',DBGrid1. Columns [6]. Width);. WriteInteger ('GridColumns','Column7',DBGrid1. Columns [7]. Width);. WriteInteger ('GridColumns','Column8',DBGrid1. Columns [8]. Width);. WriteInteger ('GridColumns','Column9',DBGrid1. Columns [9]. Width);. WriteInteger ('GridColumns','Column10',DBGrid1. Columns [10]. Width);. WriteInteger ('GridColumns','Column11',DBGrid1. Columns [11]. Width);. WriteInteger ('GridColumns','Column12',DBGrid1. Columns [12]. Width);. WriteInteger ('GridColumns','Column13',DBGrid1. Columns [13]. Width);. WriteInteger ('GridColumns','Column14',DBGrid1. Columns [14]. Width);. WriteInteger ('GridColumns','Column15',DBGrid1. Columns [15]. Width);. WriteInteger ('GridColumns','Column19',DBGrid1. Columns [16]. Width);. WriteInteger ('GridColumns','Column20',DBGrid1. Columns [20]. Width);. WriteDate ('Date','BeginDate',BeginDate. Date);. WriteDate ('Date','EndDate',EndDate. Date);. Free;;TFMain. InitFormFAdd;: TADOQuery;. EFIO. Text: ='';. Etel. Text: ='';. EAdres. Text: ='';. Emodel. Text: ='';. ESN. Text: ='';. EIMEI. Text: ='';. ESNBat. Text: ='';

// FAdd. CKompl. Text: ='Телефон';. CEngeneer. Text: ='';. ENeisp. Text: ='';. ECost. Text: ='';. EZam. Text: ='';. ENumberOrder. Text: ='';. EPrim. Text: ='';

// FAdd. CStatus. Text: ='Принято в ремонт';

// Добавляем инженеров в список ComboBox из таблицы: = TADOQuery. Create (Self);. Connection: = Password;. Close;. SQL. Add ('select * from Engineer');. Open;(FAdd. CEngeneer, quSelect, 'ID', 'FIO');

{quSelect. Close;. Free;

// Добавляем статусы телефонов в список ComboBox из таблицы: = TADOQuery. Create (Self);. Connection: = Password; }. SQL. Clear;. Close;. SQL. Add ('select * from STATUS');. Open;(FAdd. CStatus, quSelect, 'ID', 'Status');

{quSelect. Close;. Free;

// Добавляем комплектность телефонов в список ComboBox из таблицы: = TADOQuery. Create (Self);. Connection: = Password; }. SQL. Clear;. Close;. SQL. Add ('select * from KOMPLEKTNOST');. Open;(FAdd. CKompl, quSelect, 'ID', 'Komplektnost');. SQL. Clear;. Close;. Free;;TFMain. ADDExecute (Sender: TObject);: TADOQuery;,s: string;: =ADOQuery1. Fields [0]. Text; // запоминание текущей записи

// Добавление записи;; // // // /****************. CStatus. ItemIndex: =0;. DateReception. Enabled: =True;. DateReception. Date: =Date ();. DatePokupki. Checked: =False;. DateDelivery. Checked: = False;. Caption: ='Добавление записи';: = TADOQuery. Create (Self);. Connection: = Password;. Close;

// добавление автономера заказа. SQL. Add ('SELECT (IDENT_CURRENT (''ORBITAS'') + 1) as Number');. Open;. ENumberOrder. Text: = quInsert. FieldByName ('Number'). AsString;FAdd. ShowModal = mrOk then: ='ok';. Close;. SQL. Clear;FAdd. DatePokupki. Checked then begin // [datavidachi]. SQL. Add ('insert into ORBITAS ([datapriema], [FIO], [Adres], [Tel], [Model], [SN], [IMEI], [SNbat], [Stoimost], [Zamechaniya], [Neispravnost], [datapokypki], [Primechaniya], R_Komplektnost, R_STATUS, R_ENGINEER) values ('''+(FAdd. DateReception. Date) +''','''+(FAdd. EFIO. Text) + ''','''+(FAdd. EAdres. Text) + ''','''+(FAdd. Etel. Text) + ''','''+(FAdd. Emodel. Text) + ''','''+(FAdd. ESN. Text) + ''','''+(FAdd. EIMEI. Text) + ''','''+(FAdd. ESNbat. Text) + ''','''+(FAdd. ECost. Text) + ''','''+(FAdd. EZam. Text) + ''','''+(FAdd. ENeisp. Text) + ''','''+(FAdd. DatePokupki. Date) +''','''+(FAdd. EPrim. Text) + ''','''+(GetIDComboBox (FAdd. CKompl)) + ''','''+(GetIDComboBox (FAdd. CStatus)) + ''','+(GetIDComboBox (FAdd. CEngeneer)) +') ');else begin. SQL. Add ('insert into ORBITAS ([datapriema], [FIO], [Adres], [Tel], [Model], [SN], [IMEI], [SNbat], [Stoimost], [Zamechaniya], [Neispravnost], [Primechaniya], R_Komplektnost, R_STATUS, R_ENGINEER) values ('''+(FAdd. DateReception. Date) +''','''+(FAdd. EFIO. Text) + ''','''+(FAdd. EAdres. Text) + ''','''+(FAdd. Etel. Text) + ''','''+(FAdd. Emodel. Text) + ''','''+(FAdd. ESN. Text) + ''','''+(FAdd. EIMEI. Text) + ''','''+(FAdd. ESNbat. Text) + ''','''+(FAdd. ECost. Text) + ''','''+(FAdd. EZam. Text) + ''','''+(FAdd. ENeisp. Text) + ''','''+(FAdd. EPrim. Text) + ''','''+(GetIDComboBox (FAdd. CKompl)) + ''','''+(GetIDComboBox (FAdd. CStatus)) + ''','+(GetIDComboBox (FAdd. CEngeneer)) +') ');;. ExecSQL;;. Close;. Free;. Close;. Open;;;Unit3. PrintAct then. DefaultDest: =rdPrinter;. Last;. Execute;: =False;;click='ok' then ADOQuery1. Last else ADOQuery1. Locate ('ID',s, [loCaseInsensitive]);;TFMain. DELETEExecute (Sender: TObject);: TADOQuery;: string;

// Удаление записи

// MessageDLG ();

{ if ADOQuery1. Last then exit;. Next;: =ADOQuery1. Fields [0]. Text; // запоминание текущей записи. Prior; }; // *******************Application. MessageBox ('Удалить выделенную запись? ','Удаление записи',MB_YESNO + MB_ICONQUESTION) <> mrYes then exit;

// If MessageDLG ('Удалить выделенную запись? ', mtConfirmation, [mbYes, mbNo], 1) <> mrYes then exit;: = TADOQuery. Create (Self);. Connection: = Password;. Close;. SQL. Add ('delete from ORBITAS where ID = ' + ADOQuery1. FieldByName ('ID'). AsString);. ExecSQL;. Close;. Free;. Close;. Open;;

// ADOQuery1. Locate ('ID',s, [loCaseInsensitive]);. Last;;TFMain. EDITExecute (Sender: TObject);: TADOQuery;: string;

// Изменение записи: =ADOQuery1. Fields [0]. Text; // запоминание текущей записи;; // *****************************. DateReception. Enabled: =False;. DateDelivery. Enabled: =True;. Caption: = 'Изменение записи';. ENumberOrder. Text: = ADOQuery1. FieldByName ('ID'). AsString;. EFIO. Text: = ADOQuery1. FieldByName ('FIO'). AsString;. Etel. Text: = ADOQuery1. FieldByName ('TEL'). AsString;. EAdres. Text: = ADOQuery1. FieldByName ('ADRES'). AsString;. Emodel. Text: = ADOQuery1. FieldByName ('Model'). AsString;. ESN. Text: = ADOQuery1. FieldByName ('SN'). AsString;. EIMEI. Text: = ADOQuery1. FieldByName ('IMEI'). AsString;. ESNBat. Text: = ADOQuery1. FieldByName ('SNBat'). AsString;. ECost. Text: = ADOQuery1. FieldByName ('Stoimost'). AsString;. EZam. Text: = ADOQuery1. FieldByName ('Zamechaniya'). AsString;. ENeisp. Text: = ADOQuery1. FieldByName ('Neispravnost'). AsString;. EPrim. Text: = ADOQuery1. FieldByName ('Primechaniya'). AsString;

{ FAdd. DatePokupki. Checked: = False;. DateDelivery. Checked: = False; }. DateReception. Date: = StrToDateDef (ADOQuery1. FieldByName ('datapriema'). AsString,Date ());. DateDelivery. Date: = StrToDateDef (ADOQuery1. FieldByName ('datavidachi'). AsString,Date ());. DatePokupki. Date: = StrToDateDef (ADOQuery1. FieldByName ('datapokypki'). AsString,Date ());StrToDateDef (ADOQuery1. FieldByName ('datavidachi'). AsString,0) =0 then FAdd. DateDelivery. Checked: =False;StrToDateDef (ADOQuery1. FieldByName ('datapokypki'). AsString,0) =0 then FAdd. DatePokupki. Checked: =False;. CStatus. ItemIndex: = FAdd. CStatus. Items. IndexOf (ADOQuery1. FieldByName ('STATUS'). AsString);. CKompl. ItemIndex: = FAdd. CKompl. Items. IndexOf (ADOQuery1. FieldByName ('Komplektnost'). AsString);. CEngeneer. ItemIndex: = FAdd. CEngeneer. Items. IndexOf (ADOQuery1. FieldByName ('ENG_FIO'). AsString);FAdd. ShowModal <> mrOk then exit;: = TADOQuery. Create (Self);. Connection: = Password;. Close;(FAdd. DateDelivery. Checked) and (FAdd. DatePokupki. Checked) then. SQL. Add ('update ORBITAS set '+

'datapriema = ''' + DateToStr (FAdd. DateReception. Date) +

''', FIO = ''' + Trim (FAdd. EFIO. Text) +

''', ADRES = ''' + Trim (FAdd. EAdres. Text) +

''', TEL = ''' + Trim (FAdd. ETel. Text) +

''', Model = ''' + Trim (FAdd. Emodel. Text) +

''', SN = ''' + Trim (FAdd. ESN. Text) +

''', IMEI = ''' + Trim (FAdd. EIMEI. Text) +

''', SNbat = ''' + Trim (FAdd. ESNbat. Text) +

''', Stoimost = ''' + Trim (FAdd. ECost. Text) +

''', Zamechaniya = ''' + Trim (FAdd. EZam. Text) +

''', Neispravnost = ''' + Trim (FAdd. ENeisp. Text) +

''', datavidachi = ''' + DateToStr (FAdd. DateDelivery. Date) +

''', datapokypki = ''' + DateToStr (FAdd. DatePokupki. Date) +

''', Primechaniya = ''' + Trim (FAdd. EPrim. Text) +

''', R_STATUS = ''' + IntToStr (GetIDComboBox (FAdd. CStatus)) +

''', R_Komplektnost = ''' + IntToStr (GetIDComboBox (FAdd. CKompl)) +

''', R_ENGINEER = ' + IntToStr (GetIDComboBox (FAdd. CEngeneer)) + ' where ID = ' + ADOQuery1. FieldByName ('ID'). AsString);;(FAdd. DateDelivery. Checked=False) and (FAdd. DatePokupki. Checked=False) then. SQL. Add ('update ORBITAS set '+

'datapriema = ''' + DateToStr (FAdd. DateReception. Date) +

''', FIO = ''' + Trim (FAdd. EFIO. Text) +

''', ADRES = ''' + Trim (FAdd. EAdres. Text) +

''', TEL = ''' + Trim (FAdd. ETel. Text) +

''', Model = ''' + Trim (FAdd. Emodel. Text) +

''', SN = ''' + Trim (FAdd. ESN. Text) +

''', IMEI = ''' + Trim (FAdd. EIMEI. Text) +

''', SNbat = ''' + Trim (FAdd. ESNbat. Text) +

''', Stoimost = ''' + Trim (FAdd. ECost. Text) +

''', Zamechaniya = ''' + Trim (FAdd. EZam. Text) +

''', Neispravnost = ''' + Trim (FAdd. ENeisp. Text) +

''', datavidachi = ''' + ''+

''', datapokypki = ''' + ''+

''', Primechaniya = ''' + Trim (FAdd. EPrim. Text) +

''', R_STATUS = ''' + IntToStr (GetIDComboBox (FAdd. CStatus)) +

''', R_Komplektnost = ''' + IntToStr (GetIDComboBox (FAdd. CKompl)) +

''', R_ENGINEER = ' + IntToStr (GetIDComboBox (FAdd. CEngeneer)) + ' where ID = ' + ADOQuery1. FieldByName ('ID'). AsString);;(FAdd. DateDelivery. Checked) and (FAdd. DatePokupki. Checked=False) then. SQL. Add ('update ORBITAS set '+

'datapriema = ''' + DateToStr (FAdd. DateReception. Date) +

''', FIO = ''' + Trim (FAdd. EFIO. Text) +

''', ADRES = ''' + Trim (FAdd. EAdres. Text) +

''', TEL = ''' + Trim (FAdd. ETel. Text) +

''', Model = ''' + Trim (FAdd. Emodel. Text) +

''', SN = ''' + Trim (FAdd. ESN. Text) +

''', IMEI = ''' + Trim (FAdd. EIMEI. Text) +

''', SNbat = ''' + Trim (FAdd. ESNbat. Text) +

''', Stoimost = ''' + Trim (FAdd. ECost. Text) +

''', Zamechaniya = ''' + Trim (FAdd. EZam. Text) +

''', Neispravnost = ''' + Trim (FAdd. ENeisp. Text) +

''', datavidachi = ''' + DateToStr (FAdd. DateDelivery. Date) +

''', datapokypki = ''' + ''+

''', Primechaniya = ''' + Trim (FAdd. EPrim. Text) +

''', R_STATUS = ''' + IntToStr (GetIDComboBox (FAdd. CStatus)) +

''', R_Komplektnost = ''' + IntToStr (GetIDComboBox (FAdd. CKompl)) +

''', R_ENGINEER = ' + IntToStr (GetIDComboBox (FAdd. CEngeneer)) + ' where ID = ' + ADOQuery1. FieldByName ('ID'). AsString);;(FAdd. DateDelivery. Checked=False) and (FAdd. DatePokupki. Checked) then. SQL. Add ('update ORBITAS set '+

'datapriema = ''' + DateToStr (FAdd. DateReception. Date) +

''', FIO = ''' + Trim (FAdd. EFIO. Text) +

''', ADRES = ''' + Trim (FAdd. EAdres. Text) +

''', TEL = ''' + Trim (FAdd. ETel. Text) +

''', Model = ''' + Trim (FAdd. Emodel. Text) +

''', SN = ''' + Trim (FAdd. ESN. Text) +

''', IMEI = ''' + Trim (FAdd. EIMEI. Text) +

''', SNbat = ''' + Trim (FAdd. ESNbat. Text) +

''', Stoimost = ''' + Trim (FAdd. ECost. Text) +

''', Zamechaniya = ''' + Trim (FAdd. EZam. Text) +

''', Neispravnost = ''' + Trim (FAdd. ENeisp. Text) +

''', datavidachi = ''' + ''+

''', datapokypki = ''' + DateToStr (FAdd. DatePokupki. Date) +

''', Primechaniya = ''' + Trim (FAdd. EPrim. Text) +

''', R_STATUS = ''' + IntToStr (GetIDComboBox (FAdd. CStatus)) +

''', R_Komplektnost = ''' + IntToStr (GetIDComboBox (FAdd. CKompl)) +

''', R_ENGINEER = ' + IntToStr (GetIDComboBox (FAdd. CEngeneer)) + ' where ID = ' + ADOQuery1. FieldByName ('ID'). AsString);;. ExecSQL;. Close;. Free;. Close;. Open;;Unit3. PrintAct then. DefaultDest: =rdPrinter;. Last;. Execute;;. Locate ('ID',s, [loCaseInsensitive]);;TFMain. FINDExecute (Sender: TObject);

// Поиск;; // *****************FFind. ShowModal <> mrOk then exit;. ADOQuery1. Close;. ADOQuery1. SQL. Clear;

// Поиск по 4 полям. SQL. Add ('SELECT orb. *, ENG. FIO as ENG_FIO, KOM. Komplektnost as Komplektnost, STA. STATUS as STATUS FROM ( (ORBITAS orb left join ENGINEER ENG on orb. R_ENGINEER = ENG. id) '+

' left join KOMPLEKTNOST KOM on orb. R_Komplektnost = KOM. id left join STATUS STA on orb. R_STATUS = STA. id) WHERE (STATUS LIKE '''+FFind. CStatus. Text+'%'') and (Model LIKE '''+FFind. EMod. Text+'%'') and (IMEI LIKE '''+FFind. EIMEI. Text+'%'') and (orb. FIO LIKE '''+FFind. EFIO. Text+'%'') ');. Open;;;;TFMain. actEXITExecute (Sender: TObject);. Close;;TFMain. INGENIRESExecute (Sender: TObject);

// Редактор инженеров. ShowModal;;TFMain. PrintExecute (Sender: TObject);

// предпросмотр и печатьN13. Checked then RvSystem1. DefaultDest: =rdPrinter;N14. Checked then RvSystem1. DefaultDest: =rdPreview;. Execute;;TFMain. FormShow (Sender: TObject);

{if FMain. Tag=0 then: =TFPassword. Create (self);. ShowModal;; }

{EndDate. Date: =Date ();. Date: =Date (); }: =1;;. WindowState: =wsMaximized;;. Enabled: =False;. Enabled: =False;;TFMain. InitFormFFind;. EFIO. Text: ='';. EMod. Text: ='';. EIMEI. Text: ='';. CStatus. Text: ='';;TFMain. ActUpdateExecute (Sender: TObject);: string;: =ADOQuery1. Fields [0]. Text; // запоминание текущей записи; // // // // // // // // *************************. Close;

// ADOQuery1. Open;. SQL. Clear;CheckBox1. Checked then. SQL. Add (Format ('SELECT orb. *, ENG. FIO as ENG_FIO, KOM. Komplektnost as Komplektnost, STA. STATUS as STATUS FROM ( (ORBITAS orb left join ENGINEER ENG on orb. R_ENGINEER = ENG. id) '+

' left join KOMPLEKTNOST KOM on orb. R_Komplektnost = KOM. id left join STATUS STA on orb. R_STATUS = STA. id) WHERE %s BETWEEN ''%s'' AND ''%s''', ['orb. datapriema',DateToStr (BeginDate. Date),DateToStr (EndDate. Date)])). SQL. Add ('SELECT orb. *, ENG. FIO as ENG_FIO, KOM. Komplektnost as Komplektnost, STA. STATUS as STATUS FROM ( (ORBITAS orb left join ENGINEER ENG on orb. R_ENGINEER = ENG. id) '+

' left join KOMPLEKTNOST KOM on orb. R_Komplektnost = KOM. id left join STATUS STA on orb. R_STATUS = STA. id) ');

// ADOQuery1. ExecSQL;. Open;;

// ADOQuery1. Locate ('S/N',Edit1. Text, [loCaseInsensitive, loPartialKey]);. Locate ('ID',s, [loCaseInsensitive]);;TFMain. SortExecute (Sender: TObject);

// Сортировка; // // // **********************SortAct of

: ActionList1. Actions [11]. Execute;

: ActionList1. Actions [9]. Execute;

: ActionList1. Actions [10]. Execute;

: ActionList1. Actions [12]. Execute;

: ActionList1. Actions [14]. Execute;

: ActionList1. Actions [13]. Execute;;;TFMain. SortDatePriemaExecute (Sender: TObject);: string;: =ADOQuery1. Fields [0]. Text; // запоминание текущей записи

// Сортировка по дате приёма. Close;. SQL. Clear;CheckBox1. Checked then. SQL. Add (Format ('SELECT orb. *, ENG. FIO as ENG_FIO, KOM. Komplektnost as Komplektnost, STA. STATUS as STATUS FROM ( (ORBITAS orb left join ENGINEER ENG on orb. R_ENGINEER = ENG. id) '+

' left join KOMPLEKTNOST KOM on orb. R_Komplektnost = KOM. id left join STATUS STA on orb. R_STATUS = STA. id) '+'WHERE %s BETWEEN ''%s'' AND ''%s''', ['orb. datapriema',DateToStr (BeginDate. Date),DateToStr (EndDate. Date)]) +'ORDER BY datapriema'). SQL. Add ('SELECT orb. *, ENG. FIO as ENG_FIO, KOM. Komplektnost as Komplektnost, STA. STATUS as STATUS FROM ( (ORBITAS orb left join ENGINEER ENG on orb. R_ENGINEER = ENG. id) '+

' left join KOMPLEKTNOST KOM on orb. R_Komplektnost = KOM. id left join STATUS STA on orb. R_STATUS = STA. id) ORDER BY datapriema ');. Open;;: =2;. Checked: =False;. Checked: =False;. Checked: =False;. Checked: =False;. Checked: =False;. Checked: =True;. Locate ('ID',s, [loCaseInsensitive]);;TFMain. SortStatusExecute (Sender: TObject);: string;: =ADOQuery1. Fields [0]. Text; // запоминание текущей записи

// Сортировка по статусу. Close;. SQL. Clear;CheckBox1. Checked then. SQL. Add (Format ('SELECT orb. *, ENG. FIO as ENG_FIO, KOM. Komplektnost as Komplektnost, STA. STATUS as STATUS FROM ( (ORBITAS orb left join ENGINEER ENG on orb. R_ENGINEER = ENG. id) '+

' left join KOMPLEKTNOST KOM on orb. R_Komplektnost = KOM. id left join STATUS STA on orb. R_STATUS = STA. id) '+'WHERE %s BETWEEN ''%s'' AND ''%s''', ['orb. datapriema',DateToStr (BeginDate. Date),DateToStr (EndDate. Date)]) +'ORDER BY STATUS'). SQL. Add ('SELECT orb. *, ENG. FIO as ENG_FIO, KOM. Komplektnost as Komplektnost, STA. STATUS as STATUS FROM ( (ORBITAS orb left join ENGINEER ENG on orb. R_ENGINEER = ENG. id) '+

' left join KOMPLEKTNOST KOM on orb. R_Komplektnost = KOM. id left join STATUS STA on orb. R_STATUS = STA. id) ORDER BY STATUS ');. Open;;: =3;. Checked: =False;. Checked: =False;. Checked: =False;. Checked: =False;. Checked: =False;. Checked: =True;. Locate ('ID',s, [loCaseInsensitive]);;TFMain. SortByIDExecute (Sender: TObject);: string;: =ADOQuery1. Fields [0]. Text; // запоминание текущей записи

// Сортировать по номеру заказа. Close;. SQL. Clear;CheckBox1. Checked then. SQL. Add (Format ('SELECT orb. *, ENG. FIO as ENG_FIO, KOM. Komplektnost as Komplektnost, STA. STATUS as STATUS FROM ( (ORBITAS orb left join ENGINEER ENG on orb. R_ENGINEER = ENG. id) '+

' left join KOMPLEKTNOST KOM on orb. R_Komplektnost = KOM. id left join STATUS STA on orb. R_STATUS = STA. id) '+'WHERE %s BETWEEN ''%s'' AND ''%s''', ['orb. datapriema',DateToStr (BeginDate. Date),DateToStr (EndDate. Date)]) +'ORDER BY 1'). SQL. Add ('SELECT orb. *, ENG. FIO as ENG_FIO, KOM. Komplektnost as Komplektnost, STA. STATUS as STATUS FROM ( (ORBITAS orb left join ENGINEER ENG on orb. R_ENGINEER = ENG. id) '+

' left join KOMPLEKTNOST KOM on orb. R_Komplektnost = KOM. id left join STATUS STA on orb. R_STATUS = STA. id) ORDER BY 1 ');. Open;;. Checked: =False;. Checked: =False;. Checked: =False;. Checked: =False;. Checked: =False;. Checked: =True;: =1;. Locate ('ID',s, [loCaseInsensitive]);;TFMain. SortByFIOExecute (Sender: TObject);: string;: =ADOQuery1. Fields [0]. Text; // запоминание текущей записи

// Сортировать по фамилии клиента. Close;. SQL. Clear;CheckBox1. Checked then. SQL. Add (Format ('SELECT orb. *, ENG. FIO as ENG_FIO, KOM. Komplektnost as Komplektnost, STA. STATUS as STATUS FROM ( (ORBITAS orb left join ENGINEER ENG on orb. R_ENGINEER = ENG. id) '+

' left join KOMPLEKTNOST KOM on orb. R_Komplektnost = KOM. id left join STATUS STA on orb. R_STATUS = STA. id) '+'WHERE %s BETWEEN ''%s'' AND ''%s''', ['orb. datapriema',DateToStr (BeginDate. Date),DateToStr (EndDate. Date)]) +'ORDER BY 3'). SQL. Add ('SELECT orb. *, ENG. FIO as ENG_FIO, KOM. Komplektnost as Komplektnost, STA. STATUS as STATUS FROM ( (ORBITAS orb left join ENGINEER ENG on orb. R_ENGINEER = ENG. id) '+

' left join KOMPLEKTNOST KOM on orb. R_Komplektnost = KOM. id left join STATUS STA on orb. R_STATUS = STA. id) ORDER BY 3 ');. Open;;: =4;. Checked: =False;. Checked: =False;. Checked: =False;. Checked: =False;. Checked: =False;. Checked: =True;. Locate ('ID',s, [loCaseInsensitive]);;TFMain. SortByENGFIOExecute (Sender: TObject);: string;: =ADOQuery1. Fields [0]. Text; // запоминание текущей записи

// Сортировать по фамилии инженера. Close;. SQL. Clear;CheckBox1. Checked then. SQL. Add (Format ('SELECT orb. *, ENG. FIO as ENG_FIO, KOM. Komplektnost as Komplektnost, STA. STATUS as STATUS FROM ( (ORBITAS orb left join ENGINEER ENG on orb. R_ENGINEER = ENG. id) '+

' left join KOMPLEKTNOST KOM on orb. R_Komplektnost = KOM. id left join STATUS STA on orb. R_STATUS = STA. id) '+'WHERE %s BETWEEN ''%s'' AND ''%s''', ['orb. datapriema',DateToStr (BeginDate. Date),DateToStr (EndDate. Date)]) +'ORDER BY ENG_FIO'). SQL. Add ('SELECT orb. *, ENG. FIO as ENG_FIO, KOM. Komplektnost as Komplektnost, STA. STATUS as STATUS FROM ( (ORBITAS orb left join ENGINEER ENG on orb. R_ENGINEER = ENG. id) '+

' left join KOMPLEKTNOST KOM on orb. R_Komplektnost = KOM. id left join STATUS STA on orb. R_STATUS = STA. id) ORDER BY ENG_FIO ');. Open;;: =6;. Checked: =False;. Checked: =False;. Checked: =False;. Checked: =False;. Checked: =False;. Checked: =True;. Locate ('ID',s, [loCaseInsensitive]);;TFMain. SortByModelExecute (Sender: TObject);: string;: =ADOQuery1. Fields [0]. Text; // запоминание текущей записи

// Сортировать по модели телефона. Close;. SQL. Clear;CheckBox1. Checked then. SQL. Add (Format ('SELECT orb. *, ENG. FIO as ENG_FIO, KOM. Komplektnost as Komplektnost, STA. STATUS as STATUS FROM ( (ORBITAS orb left join ENGINEER ENG on orb. R_ENGINEER = ENG. id) '+

' left join KOMPLEKTNOST KOM on orb. R_Komplektnost = KOM. id left join STATUS STA on orb. R_STATUS = STA. id) '+'WHERE %s BETWEEN ''%s'' AND ''%s''', ['orb. datapriema',DateToStr (BeginDate. Date),DateToStr (EndDate. Date)]) +'ORDER BY Model'). SQL. Add ('SELECT orb. *, ENG. FIO as ENG_FIO, KOM. Komplektnost as Komplektnost, STA. STATUS as STATUS FROM ( (ORBITAS orb left join ENGINEER ENG on orb. R_ENGINEER = ENG. id) '+

' left join KOMPLEKTNOST KOM on orb. R_Komplektnost = KOM. id left join STATUS STA on orb. R_STATUS = STA. id) ORDER BY Model ');. Open;;: =5;. Checked: =False;. Checked: =False;. Checked: =False;. Checked: =False;. Checked: =False;. Checked: =True;. Locate ('ID',s, [loCaseInsensitive]);;TFMain. ChooseExecute (Sender: TObject);,FieldText: String;

// Выбор; // *****************: =DBGrid1. SelectedField. FieldName;: =DBGrid1. SelectedField. Text;. Close;. SQL. Clear;(FieldName='ID') or (FieldName='FIO') then. SQL. Add (Format ('SELECT orb. *, ENG. FIO as ENG_FIO, KOM. Komplektnost as Komplektnost, STA. STATUS as STATUS FROM ( (ORBITAS orb left join ENGINEER ENG on orb. R_ENGINEER = ENG. id) '+

' left join KOMPLEKTNOST KOM on orb. R_Komplektnost = KOM. id left join STATUS STA on orb. R_STATUS = STA. id) WHERE %s=''%s''', ['orb. '+FieldName,FieldText]));FieldName= ('ENG_FIO') then. SQL. Add (Format ('SELECT orb. *, ENG. FIO as ENG_FIO, KOM. Komplektnost as Komplektnost, STA. STATUS as STATUS FROM ( (ORBITAS orb left join ENGINEER ENG on orb. R_ENGINEER = ENG. id) '+

' left join KOMPLEKTNOST KOM on orb. R_Komplektnost = KOM. id left join STATUS STA on orb. R_STATUS = STA. id) WHERE %s=''%s''', ['ENG. FIO',FieldText]));(FieldName <>'ID') and (FieldName<>'ENG_FIO') and (FieldName<>'FIO') then. SQL. Add (Format ('SELECT orb. *, ENG. FIO as ENG_FIO, KOM. Komplektnost as Komplektnost, STA. STATUS as STATUS FROM ( (ORBITAS orb left join ENGINEER ENG on orb. R_ENGINEER = ENG. id) '+

' left join KOMPLEKTNOST KOM on orb. R_Komplektnost = KOM. id left join STATUS STA on orb. R_STATUS = STA. id) WHERE %s=''%s''', [FieldName,FieldText]));. Open;;;TFMain. DBGrid1DblClick (Sender: TObject);. Actions [15]. Execute;;TFMain. BeginDateChange (Sender: TObject);,FieldText: String;

// Выбор: =DBGrid1. SelectedField. FieldName;: =DBGrid1. SelectedField. Text;

// ADOQuery1. Close;. SQL. Clear;. SQL. Add (Format ('SELECT orb. *, ENG. FIO as ENG_FIO, KOM. Komplektnost as Komplektnost, STA. STATUS as STATUS FROM ( (ORBITAS orb left join ENGINEER ENG on orb. R_ENGINEER = ENG. id) '+

' left join KOMPLEKTNOST KOM on orb. R_Komplektnost = KOM. id left join STATUS STA on orb. R_STATUS = STA. id) WHERE %s BETWEEN ''%s'' AND ''%s''', ['orb. datapriema',DateToStr (BeginDate. Date),DateToStr (EndDate. Date)]));. Open;;. Last;;TFMain. EndDateChange (Sender: TObject);,FieldText: String;

// Выбор: =DBGrid1. SelectedField. FieldName;: =DBGrid1. SelectedField. Text;

// ADOQuery1. Close;. SQL. Clear;. SQL. Add (Format ('SELECT orb. *, ENG. FIO as ENG_FIO, KOM. Komplektnost as Komplektnost, STA. STATUS as STATUS FROM ( (ORBITAS orb left join ENGINEER ENG on orb. R_ENGINEER = ENG. id) '+

' left join KOMPLEKTNOST KOM on orb. R_Komplektnost = KOM. id left join STATUS STA on orb. R_STATUS = STA. id) WHERE %s BETWEEN ''%s'' AND ''%s''', ['orb. datapriema',DateToStr (BeginDate. Date),DateToStr (EndDate. Date)]));. Open;;. Last;;

{var: TForm;: = Dialogs. CreateMessageDialog ('Удалить выделенную запись? ', dialogs. mtConfirmation, [mbYes, mbNo]);. Caption: ='Удаление записи'; }TFMain. ActPrintExecute (Sender: TObject);. ImageIndex: =4;. DefaultDest: =rdPrinter;. Execute;. Checked: =True;. Checked: =False;. Hint: ='Печать';;TFMain. ActPreviewExecute (Sender: TObject);. ImageIndex: =10;. DefaultDest: =rdPreview;. Execute;. Checked: =True;. Checked: =False;. Hint: ='Предпросмотр';;TFMain. FormClose (Sender: TObject; var Action: TCloseAction);;;TFMain. ActEndExecute (Sender: TObject);. Last;;TFMain. ActHomeExecute (Sender: TObject);. First;;TFMain. CheckBox1Click (Sender: TObject);CheckBox1. Checked then. Enabled: =True;. Enabled: =True;else. Enabled: =False;. Enabled: =False;;;TFMain. N27Click (Sender: TObject);. ShowModal;;TFMain. FormCreate (Sender: TObject);

{var: TIniFile;,p: string;: TDate;: integer; }

{ RInf: =TIniFile. Create ('Rconf. ini');: =RInf. ReadString ('SK','NSK',NSK);: =RInf. ReadString ('SK','p',p);: =RInf. ReadDate ('SK','dt',dt);: =RInf. ReadInteger ('SK','day',day);Date>=StrToDate ('10.09.06') thenp='ljkkfh' then exit else;;;;NSK<>'Trial'then('Время использования пробной версии программы истекло'

+#13+'для получения полной версии обратитесь к разработчикам');. Terminate;;dt<>Date then: =day+1;. WriteInteger ('SK','day',day);. WriteDate ('SK','dt',Date);. Free;;day>=23 then('Время использования пробной версии программы истекло'

+#13+'для получения полной версии обратитесь к разработчикам');. Terminate;; }. ButtonsVisibleLoad;;TFMain. N29Click (Sender: TObject);. ShowModal;;TFMain. FSBClick (Sender: TObject);ADOQuery1. Locate ('ID',FEdit. Text, [loCaseInsensitive])TBEdit. ClickShowMessage ('Запись не найдена');;TFMain. FEditKeyDown (Sender: TObject; var Key: Word;: TShiftState);key=13 then FSB. Click;;TFMain. FEditKeyPress (Sender: TObject; var Key: Char);(Key<>'0') and (Key<>'1') and (Key<>'2') and (Key<>'3')(Key<>'4') and (Key<>'5') and (Key<>'6') and (Key<>'7')(Key<>'8') and (Key<>'9') and (key<>#08) and (key<>'2E')key: =#0;;TFMain. DBGrid1MouseDown (Sender: TObject; Button: TMouseButton;: TShiftState; X, Y: Integer);

// if (Button = mbRight) then Showmessage ('! '); TBEdit. Click;;TFMain. JanHDBGrid1DblClick (Sender: TObject);. Actions [15]. Execute;;.Unit2;, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,, StdCtrls, Buttons, ExtCtrls;= class (TForm): TPanel;: TLabeledEdit;: TBitBtn;: TBitBtn;BitBtn1Click (Sender: TObject);BitBtn2Click (Sender: TObject);

{ Private declarations }

{ Public declarations };: TFAddEngineer;Unit5, Unit1;

{$R *. dfm}TFAddEngineer. BitBtn1Click (Sender: TObject);

// FAddEngineer. Close;;TFAddEngineer. BitBtn2Click (Sender: TObject);

// INSERT INTO Engineer VALUE ('1','Привет');

// Fmain. ADOQuery1. SQL. Add ('INSERT INTO Engineer VALUE (1, Привет') ');

// Insert (Engineer);;.Unit3;, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,, StdCtrls, ComCtrls, ExtCtrls, Buttons;= class (TForm): TPanel;: TGroupBox;: TLabel;: TLabeledEdit;: TComboBox;: TGroupBox;: TLabel;: TLabel;: TLabel;: TLabel;: TLabel;: TLabeledEdit;: TLabeledEdit;: TLabeledEdit;: TLabeledEdit;: TComboBox;: TDateTimePicker;: TComboBox;: TLabeledEdit;: TLabeledEdit;: TLabeledEdit;: TDateTimePicker;: TDateTimePicker;: TGroupBox;: TLabeledEdit;: TLabeledEdit;: TLabeledEdit;: TBitBtn;: TBitBtn;: TBitBtn;: TLabeledEdit;EIMEIKeyPress (Sender: TObject; var Key: Char);BitBtn3Click (Sender: TObject);FormShow (Sender: TObject);

{ Private declarations }

{ Public declarations };: TFAdd;: Boolean; // для печатиUnit1;

{$R *. dfm}TFAdd. EIMEIKeyPress (Sender: TObject; var Key: Char);(Key<>'0') and (Key<>'1') and (Key<>'2') and (Key<>'3')(Key<>'4') and (Key<>'5') and (Key<>'6') and (Key<>'7')(Key<>'8') and (Key<>'9') and (key<>#08) and (key<>'2E')key: =#0;( (Length (EIMEI. Text)) =15) and (key<>#08) and (key<>'2E') then Key: = #0;;TFAdd. BitBtn3Click (Sender: TObject);: =True;. Click;;TFAdd. FormShow (Sender: TObject);: =False;;.Unit4;, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,, ExtCtrls, Buttons, StdCtrls, ADODB, UComboBox;= class (TForm): TPanel;: TCheckBox;: TEdit;: TCheckBox;: TEdit;: TCheckBox;: TEdit;: TCheckBox;: TLabel;: TComboBox;: TBitBtn;: TBitBtn;BtCancelClick (Sender: TObject);BtFindClick (Sender: TObject);FormCreate (Sender: TObject);CheckBox1Click (Sender: TObject);CheckBox2Click (Sender: TObject);CheckBox3Click (Sender: TObject);CheckBox4Click (Sender: TObject);

{ Private declarations }

{ Public declarations };: TFFind;Unit1;

{$R *. dfm}TFFind. BtCancelClick (Sender: TObject);. Close;;TFFind. BtFindClick (Sender: TObject);

// Поиск;TFFind. FormCreate (Sender: TObject);: TADOQuery;

// загружаем статусы телефонов в комбо бокс для поиска: = TADOQuery. Create (Self);. Connection: = FMain. Password;. SQL. Clear;. Close;. SQL. Add ('select * from STATUS');. Open;(CStatus, quSelect, 'ID', 'Status');. Close;. Free;;TFFind. CheckBox1Click (Sender: TObject);not CheckBox1. Checked then. Text: ='';. Enabled: =False;else EFIO. Enabled: =True;;TFFind. CheckBox2Click (Sender: TObject);not CheckBox2. Checked then. Text: ='';. Enabled: =False;else EMod. Enabled: =True;;TFFind. CheckBox3Click (Sender: TObject);not CheckBox3. Checked then. Text: ='';. Enabled: =False;else EIMEI. Enabled: =True;;TFFind. CheckBox4Click (Sender: TObject);not CheckBox4. Checked then. Text: ='';. Enabled: =False;else CStatus. Enabled: =True;;.Unit5;, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,, Grids, DBGrids, Menus, ComCtrls, ToolWin, ExtCtrls, DB, ADODB,, StdCtrls, Buttons, IniFiles, JanHDBGrid;= class (TForm): TPanel;: TMainMenu;: TMenuItem;: TMenuItem;: TMenuItem;: TMenuItem;: TMenuItem;: TADOQuery;: TDataSource;: TActionList;: TAction;: TAction;: TAction;: TAction;: TBitBtn;: TPanel;: TPanel;: TToolBar;: TToolButton;: TToolButton;: TToolButton;: TDataSource;: TADOQuery;: TLabel;: TLabel;: TLabel;: TLabel;: TLabel;: TJanHDBGrid;: TJanHDBGrid;FormShow (Sender: TObject);ADDExecute (Sender: TObject);EDITExecute (Sender: TObject);DELExecute (Sender: TObject);ActEXITExecute (Sender: TObject);DBGrid1DblClick (Sender: TObject);JanHDBGrid1DblClick (Sender: TObject);

{ Private declarations }

{ Public declarations }GridWidth;GridInfoWidth;SaveSettings;LoadSettings;LoadInfoSettings;SaveInfoSettings;;: TFEngineer;: TIniFile;Unit1, Unit2;

{$R *. dfm}TFEngineer. SaveInfoSettings;: =TIniFile. Create (ExtractFilePath (Application. ExeName) +'DBconfig. ini');. WriteInteger ('INFO_GridColumns','Column0',DBGrid2. Columns [0]. Width);. WriteInteger ('INFO_GridColumns','Column1',DBGrid2. Columns [1]. Width);. WriteInteger ('INFO_GridColumns','Column2',DBGrid2. Columns [2]. Width);. Free;;TFEngineer. LoadInfoSettings;: =TIniFile. Create (ExtractFilePath (Application. ExeName) +'DBconfig. ini');. Columns [0]. Width: =ConfFile. ReadInteger ('INFO_GridColumns','Column0',DBGrid2. Columns [0]. Width);. Columns [1]. Width: =ConfFile. ReadInteger ('INFO_GridColumns','Column1',DBGrid2. Columns [1]. Width);. Columns [2]. Width: =ConfFile. ReadInteger ('INFO_GridColumns','Column2',DBGrid2. Columns [2]. Width);. Columns [0]. Title. Caption: ='Статус';. Columns [1]. Title. Caption: ='Модель';. Columns [2]. Title. Caption: ='IMEI';. Free;;TFEngineer. SaveSettings;: =TIniFile. Create (ExtractFilePath (Application. ExeName) +'DBconfig. ini');. WriteInteger ('ENG_GridColumns','Column1',DBGrid1. Columns [1]. Width);. Free;;TFEngineer. LoadSettings;: =TIniFile. Create (ExtractFilePath (Application. ExeName) +'DBconfig. ini');. Columns [1]. Width: =ConfFile. ReadInteger ('ENG_GridColumns','Column1',DBGrid1. Columns [1]. Width);. Free;;TFEngineer. GridWidth;. Columns [0]. Visible: =False;

// DBGrid1. Columns [1]. Width: =280;. Columns [1]. Title. Caption: ='Ф. И.О. ';;;TFEngineer. FormShow (Sender: TObject);: TADOQuery;

// Подсчет количества телефонов всёго: = TADOQuery. Create (Self);. Connection: = FMain. Password;. Close;. SQL. Text: = ('SELECT COUNT (R_STATUS) FROM ORBITAS WHERE ORBITAS. R_STATUS=4');. Open;. Caption: ='Всёго телефонов отремонтировано: '+quCount. Fields [0]. AsString;. ExecSQL;. Close;. Free;;

{DBGrid1. Columns [0]. Visible: =False;. Columns [1]. Width: =280; };TFEngineer. ADDExecute (Sender: TObject);: TADOQuery;

// Добавление инженера; // // // ****************. Caption: ='Добавление инженера';. EAddEngineer. Text: ='';: = TADOQuery. Create (Self);. Connection: = FMain. Password;. Close;FAddEngineer. ShowModal = mrOk then. Close;. SQL. Clear; // [datavidachi]. SQL. Add ('insert into ENGINEER ([FIO]) values ('''+(FAddEngineer. EAddEngineer. Text) +''') ');. ExecSQL;;. Close;. Free;. Close;. Open;;;

{DBGrid1. Columns [0]. Visible: =False;. Columns [1]. Width: =280; };TFEngineer. EDITExecute (Sender: TObject);: TADOQuery;

// Изменение инженера; // // // **********************. Caption: ='Изменение инженера';. EAddEngineer. Text: = ADOQuery1. FieldByName ('FIO'). AsString;FAddEngineer. ShowModal <> mrOk then exit;: = TADOQuery. Create (Self);. Connection: = FMain. Password;. Close;. SQL. Add ('update ENGINEER set FIO = ''' +Trim (FAddEngineer. EAddEngineer. Text) + ''' where ID = ' + ADOQuery1. FieldByName ('ID'). AsString);. ExecSQL;. Close;. Free;. Close;. Open;;;TFEngineer. DELExecute (Sender: TObject);: TADOQuery;

// Удаление иженера; // // // ****************Application. MessageBox ('Удалить выделенную запись? ','Удаление записи',MB_YESNO + MB_ICONQUESTION) <> mrYes then exit;: = TADOQuery. Create (Self);. Connection: = FMain. Password;. Close;. SQL. Add ('delete from ENGINEER where ID = ' + ADOQuery1. FieldByName ('ID'). AsString);. ExecSQL;. Close;. Free;. Close;. Open;

{DBGrid1. Columns [0]. Visible: =False;. Columns [1]. Width: =280; };;TFEngineer. ActEXITExecute (Sender: TObject);. Close;;TFEngineer. DBGrid1DblClick (Sender: TObject);: string;: TADOQuery;

// SaveInfoSettings; // /*******************

// * ВЫВОД ТЕЛЕФОНОВ И СТАТУСОВ ДЛЯ КАЖДОГО ИНЖЕНЕРА: =ADOQuery1. FieldByName ('ID'). AsString;. SQL. Clear;. Close;. SQL. Add ('SELECT STATUS. STATUS, ORBITAS. MODEL, ORBITAS. IMEI FROM ORBITAS, STATUS WHERE (ORBITAS. R_STATUS IN (1,2,3)) AND (STATUS. ID=ORBITAS. R_STATUS) ' +'AND'+' (ORBITAS. R_ENGINEER='+ID+') ');

// ADOQuery2. Active: =True;

// ADOQuery2. ExecSQL;

// ADOQuery2. Close;. Open;

// GridInfoWidth;

// Подсчет количества телефонов для каждого инженера и вывод в Label

// Подсчет количества телефонов всёго: = TADOQuery. Create (Self);. Connection: = FMain. Password;. Close;. SQL. Text: = ('SELECT COUNT (R_STATUS) FROM ORBITAS, STATUS WHERE ( (ORBITAS. R_STATUS=1) OR (ORBITAS. R_STATUS=2) OR (ORBITAS. R_STATUS=3)) AND (STATUS. ID=ORBITAS. R_STATUS) ' +'AND'+' (ORBITAS. R_ENGINEER='+ID+') ');. Open;. Caption: ='Всёго телефонов в ремонте: '+quCount. Fields [0]. AsString;. Close;

// Подсчет количества телефонов принятых в ремонт. SQL. Text: = ('SELECT COUNT (R_STATUS) FROM ORBITAS, STATUS WHERE (ORBITAS. R_STATUS=1) AND (STATUS. ID=ORBITAS. R_STATUS) ' +'AND'+' (ORBITAS. R_ENGINEER='+ID+') ');. Open;. Caption: ='Принято в ремонт: '+quCount. Fields [0]. AsString;. Close;

// Подсчет количества телефонов тестовый прогон. SQL. Text: = ('SELECT COUNT (R_STATUS) FROM ORBITAS, STATUS WHERE (ORBITAS. R_STATUS=2) AND (STATUS. ID=ORBITAS. R_STATUS) ' +'AND'+' (ORBITAS. R_ENGINEER='+ID+') ');. Open;. Caption: ='Тестовый прогон: '+quCount. Fields [0]. AsString;. Close;

// Подсчет количества телефонов ожидание деталеё. SQL. Text: = ('SELECT COUNT (R_STATUS) FROM ORBITAS, STATUS WHERE (ORBITAS. R_STATUS=3) AND (STATUS. ID=ORBITAS. R_STATUS) ' +'AND'+' (ORBITAS. R_ENGINEER='+ID+') ');. Open;. Caption: ='Ожидание деталей: '+quCount. Fields [0]. AsString;

// // // // // quCount. ExecSQL;. Close;. Free;;

// GridInfoWidth;;TFEngineer. GridInfoWidth;

{DBGrid2. Columns [0]. Title. Caption: ='Статус';. Columns [1]. Title. Caption: ='Модель';. Columns [2]. Title. Caption: ='IMEI'; };TFEngineer. JanHDBGrid1DblClick (Sender: TObject);: string;: TADOQuery;

// SaveInfoSettings; // /*******************

// * ВЫВОД ТЕЛЕФОНОВ И СТАТУСОВ ДЛЯ КАЖДОГО ИНЖЕНЕРА: =ADOQuery1. FieldByName ('ID'). AsString;. SQL. Clear;. Close;. SQL. Add ('SELECT STATUS. STATUS, ORBITAS. MODEL, ORBITAS. IMEI FROM ORBITAS, STATUS WHERE (ORBITAS. R_STATUS IN (1,2,3)) AND (STATUS. ID=ORBITAS. R_STATUS) ' +'AND'+' (ORBITAS. R_ENGINEER='+ID+') ');

// ADOQuery2. Active: =True;

// ADOQuery2. ExecSQL;

// ADOQuery2. Close;. Open;

// GridInfoWidth;

// Подсчет количества телефонов для каждого инженера и вывод в Label

// Подсчет количества телефонов всёго: = TADOQuery. Create (Self);. Connection: = FMain. Password;. Close;. SQL. Text: = ('SELECT COUNT (R_STATUS) FROM ORBITAS, STATUS WHERE ( (ORBITAS. R_STATUS=1) OR (ORBITAS. R_STATUS=2) OR (ORBITAS. R_STATUS=3)) AND (STATUS. ID=ORBITAS. R_STATUS) ' +'AND'+' (ORBITAS. R_ENGINEER='+ID+') ');. Open;. Caption: ='Всёго телефонов в ремонте: '+quCount. Fields [0]. AsString;. Close;

// Подсчет количества телефонов принятых в ремонт. SQL. Text: = ('SELECT COUNT (R_STATUS) FROM ORBITAS, STATUS WHERE (ORBITAS. R_STATUS=1) AND (STATUS. ID=ORBITAS. R_STATUS) ' +'AND'+' (ORBITAS. R_ENGINEER='+ID+') ');. Open;. Caption: ='Принято в ремонт: '+quCount. Fields [0]. AsString;. Close;

// Подсчет количества телефонов тестовый прогон. SQL. Text: = ('SELECT COUNT (R_STATUS) FROM ORBITAS, STATUS WHERE (ORBITAS. R_STATUS=2) AND (STATUS. ID=ORBITAS. R_STATUS) ' +'AND'+' (ORBITAS. R_ENGINEER='+ID+') ');. Open;. Caption: ='Тестовый прогон: '+quCount. Fields [0]. AsString;. Close;

// Подсчет количества телефонов ожидание деталеё. SQL. Text: = ('SELECT COUNT (R_STATUS) FROM ORBITAS, STATUS WHERE (ORBITAS. R_STATUS=3) AND (STATUS. ID=ORBITAS. R_STATUS) ' +'AND'+' (ORBITAS. R_ENGINEER='+ID+') ');. Open;. Caption: ='Ожидание деталей: '+quCount. Fields [0]. AsString;

// // // // // quCount. ExecSQL;. Close;. Free;;

// GridInfoWidth;;.Unit6;, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,, StdCtrls, Buttons, ExtCtrls;= class (TForm): TPanel;: TLabeledEdit;: TLabeledEdit;: TBitBtn;: TBitBtn;BitBtn1Click (Sender: TObject);BitBtn2Click (Sender: TObject);FormCloseQuery (Sender: TObject; var CanClose: Boolean);FormClose (Sender: TObject; var Action: TCloseAction);

{ Private declarations }

{ Public declarations }WMGetSysCommand (var Message: TMessage); message WM_SYSCOMMAND;;: TFPassword;: Boolean=False;Unit1;

{$R *. dfm}TFPassword. WMGetSysCommand (var Message: TMessage);(Message. wParam = SC_Close)Application. TerminateInherited;;TFPassword. BitBtn1Click (Sender: TObject);(ELogin. Text='gsm') and ( (EPass. Text='genetika') or (EPass. Text='4321')) then: =True;. MessageBox ('Неверно введены имя пользователя или пароль','Ошибка',MB_OK + MB_ICONERROR);;;TFPassword. BitBtn2Click (Sender: TObject);: =True;. Close;;TFPassword. FormCloseQuery (Sender: TObject;CanClose: Boolean);Login then CanClose: =True else: =False;;TFPassword. FormClose (Sender: TObject; var Action: TCloseAction);

{Login: =True;. Close; };.Unit7;Windows, SysUtils, Classes, Graphics, Forms, Controls, StdCtrls,, ExtCtrls,ShellApi;= class (TForm): TPanel;: TImage;: TLabel;: TLabel;: TLabel;: TLabel;: TButton;: TLabel;CommentsClick (Sender: TObject);

{ Private declarations }

{ Public declarations };: TAboutBox;Unit1;

{$R *. dfm}TAboutBox.commentsClick (Sender: TObject);(AboutBox. Handle, 'open', 'mailto: [email protected]', nil, nil, SW_SHOWNORMAL);;.Unit8;, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,, StdCtrls, Buttons, ExtCtrls, IniFiles;= class (TForm): TPanel;: TGroupBox;: TCheckBox;: TCheckBox;: TCheckBox;: TCheckBox;: TCheckBox;: TCheckBox;: TCheckBox;: TCheckBox;: TCheckBox;: TCheckBox;: TBitBtn;CheckBox1Click (Sender: TObject);CheckBox2Click (Sender: TObject);CheckBox7Click (Sender: TObject);CheckBox8Click (Sender: TObject);CheckBox10Click (Sender: TObject);CheckBox11Click (Sender: TObject);CheckBox9Click (Sender: TObject);CheckBox5Click (Sender: TObject);CheckBox3Click (Sender: TObject);CheckBox6Click (Sender: TObject);ButtonsVisibleSave;ButtonsVisibleLoad;CheckBoxLoad;FormClose (Sender: TObject; var Action: TCloseAction);FormCreate (Sender: TObject);BitBtn1Click (Sender: TObject);

{ Private declarations }

{ Public declarations };: TFSettings;Unit1;

{$R *. dfm}TFSettings. ButtonsVisibleSave;

// Запоминание показываемых кнопок: TIniFile;: =TIniFile. Create (ExtractFilePath (Application. ExeName) +'DBconfig. ini');. WriteBool ('ToolBatSet','TBADD',FMain. TBAdd. Visible);. WriteBool ('ToolBatSet','TBEdit',FMain. TBEdit. Visible);. WriteBool ('ToolBatSet','TBDelete',FMain. TBDelete. Visible);. WriteBool ('ToolBatSet','TBRefresh',FMain. TBRefresh. Visible);. WriteBool ('ToolBatSet','TBSeach',FMain. TBSeach. Visible);. WriteBool ('ToolBatSet','TBPrint',FMain. TBPrint. Visible);. WriteBool ('ToolBatSet','TBIngeneer',FMain. TBIngeneer. Visible);. WriteBool ('ToolBatSet','TBChoose',FMain. TBChoose. Visible);. WriteBool ('ToolBatSet','TBSort',FMain. TBSort. Visible);. WriteBool ('ToolBatSet','ToolButton1',FMain. ToolButton1. Visible);. WriteBool ('ToolBatSet','ToolButton2',FMain. ToolButton2. Visible);. Free;;TFSettings. ButtonsVisibleLoad;

// Загрузка показываемых кнопок: TIniFile;: =TIniFile. Create (ExtractFilePath (Application. ExeName) +'DBconfig. ini');. TBAdd. Visible: =ConfFile. ReadBool ('ToolBatSet','TBADD',FMain. TBAdd. Visible);. TBEdit. Visible: =ConfFile. ReadBool ('ToolBatSet','TBEdit',FMain. TBEdit. Visible);. TBDelete. Visible: =ConfFile. ReadBool ('ToolBatSet','TBDelete',FMain. TBDelete. Visible);. TBRefresh. Visible: =ConfFile. ReadBool ('ToolBatSet','TBRefresh',FMain. TBRefresh. Visible);. TBSeach. Visible: =ConfFile. ReadBool ('ToolBatSet','TBSeach',FMain. TBSeach. Visible);. TBPrint. Visible: =ConfFile. ReadBool ('ToolBatSet','TBPrint',FMain. TBPrint. Visible);. TBIngeneer. Visible: =ConfFile. ReadBool ('ToolBatSet','TBIngeneer',FMain. TBIngeneer. Visible);. TBChoose. Visible: =ConfFile. ReadBool ('ToolBatSet','TBChoose',FMain. TBChoose. Visible);. TBSort. Visible: =ConfFile. ReadBool ('ToolBatSet','TBSort',FMain. TBSort. Visible);. ToolButton1. Visible: =ConfFile. ReadBool ('ToolBatSet','ToolButton1',FMain. ToolButton1. Visible);. ToolButton2. Visible: =ConfFile. ReadBool ('ToolBatSet','ToolButton2',FMain. ToolButton2. Visible);. Free;;TFSettings. CheckBoxLoad;

// Загрузка галочек для кнопок: TIniFile;: =TIniFile. Create (ExtractFilePath (Application. ExeName) +'DBconfig. ini');. CheckBox1. Checked: =ConfFile. ReadBool ('ToolBatSet','TBADD',FSettings. CheckBox1. Checked);. CheckBox10. Checked: =ConfFile. ReadBool ('ToolBatSet','TBSeach',FSettings. CheckBox10. Checked);. CheckBox11. Checked: =ConfFile. ReadBool ('ToolBatSet','TBPrint',FSettings. CheckBox11. Checked);. CheckBox2. Checked: =ConfFile. ReadBool ('ToolBatSet','TBEdit',FSettings. CheckBox2. Checked);. CheckBox3. Checked: =ConfFile. ReadBool ('ToolBatSet','TBSort',FSettings. CheckBox3. Checked);. CheckBox5. Checked: =ConfFile. ReadBool ('ToolBatSet','TBChoose',FSettings. CheckBox5. Checked);. CheckBox6. Checked: =ConfFile. ReadBool ('ToolBatSet','ToolButton1',FSettings. CheckBox6. Checked);. CheckBox7. Checked: =ConfFile. ReadBool ('ToolBatSet','TBDelete',FSettings. CheckBox7. Checked);. CheckBox8. Checked: =ConfFile. ReadBool ('ToolBatSet','TBRefresh',FSettings. CheckBox8. Checked);. CheckBox9. Checked: =ConfFile. ReadBool ('ToolBatSet','TBIngeneer',FSettings. CheckBox9. Checked);. Free;;TFSettings. CheckBox1Click (Sender: TObject);CheckBox1. Checked then FMain. TBAdd. Visible: =TrueFMain. TBAdd. Visible: =False;;TFSettings. CheckBox2Click (Sender: TObject);CheckBox2. Checked then FMain. TBEdit. Visible: =TrueFMain. TBEdit. Visible: =False;;TFSettings. CheckBox7Click (Sender: TObject);CheckBox7. Checked then FMain. TBDelete. Visible: =TrueFMain. TBDelete. Visible: =False;;TFSettings. CheckBox8Click (Sender: TObject);CheckBox8. Checked then FMain. TBRefresh. Visible: =TrueFMain. TBRefresh. Visible: =False;;TFSettings. CheckBox10Click (Sender: TObject);CheckBox10. Checked then FMain. TBSeach. Visible: =TrueFMain. TBSeach. Visible: =False;;TFSettings. CheckBox11Click (Sender: TObject);CheckBox11. Checked then FMain. TBPrint. Visible: =TrueFMain. TBPrint. Visible: =False;;TFSettings. CheckBox9Click (Sender: TObject);CheckBox9. Checked then FMain. TBIngeneer. Visible: =TrueFMain. TBIngeneer. Visible: =False;;TFSettings. CheckBox5Click (Sender: TObject);CheckBox5. Checked then FMain. TBChoose. Visible: =TrueFMain. TBChoose. Visible: =False;;TFSettings. CheckBox3Click (Sender: TObject);CheckBox3. Checked then FMain. TBSort. Visible: =TrueFMain. TBSort. Visible: =False;;TFSettings. CheckBox6Click (Sender: TObject);CheckBox6. Checked then. ToolButton1. Visible: =True;. ToolButton2. Visible: =True;. ToolButton1. Visible: =False;. ToolButton2. Visible: =False;;;TFSettings. FormClose (Sender: TObject; var Action: TCloseAction);;;TFSettings. FormCreate (Sender: TObject);;;TFSettings. BitBtn1Click (Sender: TObject);;;.UComboBox;, DB;= object {блок данных для любого ComboBox}: integer; {id в таблице};

// Загружает данные в ComboBox с привязанными к ним IDLoadIDComboBox (CB: TComboBox; DS: TDataSet; IDField, TextField: shortstring): boolean; overload;

// Загружает данные в ComboBox с привязанными к ним ID,

// устанавливает текущее значение по указанному уникальному номеруLoadIDComboBox (CB: TComboBox; DS: TDataSet; IDField, TextField: shortstring; SelectID: integer): boolean; overload;

// Возвращает ID соответствующий выбранным данным в ComboBoxGetIDComboBox (CB: TComboBox): integer;

// Устанавливает фокус на сроку с соответствующим IDSelectFromID (CB: TComboBox; SelectID: integer): boolean;LoadIDComboBox (CB: TComboBox; DS: TDataSet; IDField, TextField: shortstring): boolean;: PIDComboBox;

// Заполнение полей ComboBox-ов. Items. Clear;. First;not DS. EOF do begin. id: = DS [IDField];

// Добавляем строку с привязанным объектом. Items. AddObject (DS [TextField], TObject (IDCB));. Next;;: = True;: = False;;;LoadIDComboBox (CB: TComboBox; DS: TDataSet; IDField, TextField: shortstring; SelectID: integer): boolean;: PIDComboBox;: integer;

// Заполнение полей ComboBox-ов. Items. Clear;. First;not DS. EOF do begin. id: = DS [IDField];

// Добавляем строку с привязанным объектом: = CB. Items. AddObject (DS [TextField], TObject (IDCB));

// Выделяем указанный элементSelectID = IDCB. id then CB. ItemIndex: = Index;. Next;;: = True;: = False;;;GetIDComboBox (CB: TComboBox): integer;

// Возвращает ID соответствующий выбранным данным в ComboBoxCB. Items. Objects [CB. ItemIndex] = nil then: = - 1: = PIDComboBox (CB. Items. Objects [CB. ItemIndex]). id;: = - 1;;;SelectFromID (CB: TComboBox; SelectID: integer): boolean;: Integer;

// Выделяем указанный элементi: = 0 to CB. Items. Count - 1 doPIDComboBox (CB. Items. Objects [i]). id = SelectID then. ItemIndex: = i;: = True;;;: = False;: = False;;;.

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

Больше работ по теме: