Автор Анна Евкова
Преподаватель который помогает студентам и школьникам в учёбе.

Автоматизация бизнес процессов

Содержание:

Введение

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

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

Кроме того, определены следующие цели разрабатываемого проекта:

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

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

Задачи, которые нужно выполнить для достижения поставленной цели:

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

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

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

Методы исследования: анализ, обобщение, моделирование, CASE-средства, сравнение.

1. Аналитическая часть

1.1 Выбор комплекса задач автоматизации

Optimum Media OMD Group – группа специализированных агентств, начало деятельности, которой на российском рынке приходится на 1992 г. Группа входит в число безусловных лидеров рынка услуг в области медиасервиса в России и СНГ. Optimum Media OMD Group является частью мировой сети OMD Worldwide – медийного подразделения транснационального коммуникационного холдинга Omnicom Group Inc. (omnicomgroup.com, NYSE: OMC).

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

Агентства Optimum Media OMD Group предлагают широкий спектр услуг в сфере коммуникационного и медиа планирования, медиасервиса:

- исследования рынка, анализ данных, 

- стратегическое и медиа- планирование,

- оптимизация и закупки,

- создание и реализация нестандартных медиа решений и новых каналов коммуникации (product placement, спонсорство, ambient media, Digital-проекты и т.д.),

- маркетинговые исследования, эконометрическое моделирование.

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

Компания работает со всеми медиа каналами и только с надежными поставщиками. Но не ограничивается традиционными медиа проектами. Компания создает новые оригинальные идеи для продвижения бизнеса клиентов. Доказательством успехов компании служит рекордное количество наград, которые компания Optimum Media OMD Group (рис. 1) завоевала на самых престижных фестивалях, в частности: Cannes Lions, Golden Hammer, Eurobest, Международные Фестивали Рекламы в Москве и Киеве и других.

StructureRussia-750x

Рис. 1 Компании Optimum Media OMD Group

Компания Optimum Media OMD Group является членом АКАР (Ассоциации Коммуникационных Агентств России) с 2000 г.

OPERA начала работать на российском рынке в июне 2006 г. в качестве объединенной медиа инвестиционной компании агентств, входящих в Omnicom Media Group (OMG). На сегодняшний день в альянс OPERA входят все агентства OMG, плюс ряд независимых российских агентств: АПР Евразия, МУВИ, EasyMedia, MediaClub, Sorec Media.

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

По данным RECMA, OPERA занимает третье место в России, с биллингами $1095 млн за 2009 г.

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

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

1.2 Характеристика существующих бизнес процессов

Рассмотрим, как организуется работа с документами в компании Optimum Media OMD Group. В отдел документооборота и делопроизводства поступают входящие документы. Любой документ, доставленный в организацию, должен быть зарегистрирован и обработан. Обработка входящих документов должна включать регистрацию в журнале. После рассмотрения руководителем и регистрации документы передаются исполнителям. Документ находится у исполнителя до окончательного решения вопроса. После исполнения документ должен подшиваться к делу. Дело - это совокупность документов, относящихся к определенному вопросу (папка или картотека, внутри которой документы расположены в определенном порядке).

По истечении установленного срока дела передаются на хранение в архив.

Документооборот – это движение документов от момента их создания до момента окончания работы с ними.

Различают внешний и внутренний контуры документооборота.[11,c.35]

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

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

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

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

Схему движения документов по внутреннему и внешнему контуру мы можем увидеть на рисунке 2.

Схема документооборота

Рис.2. Движение документов

Для более четкого представления о документообороте компании, рассмотрим распределение работ, для этого необходимо построить модель «Как есть» . Модель «Как есть» показана на рисунке 3.

Рис.3. Модель «Как есть»

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

  1. Нет единого информационного про­странства, отсутствуют автоматизирован­ные корпоративные справочники, за ис­ключением одинаковых адресных книг, содержащих адреса электронной почты сотрудников;
  2. Структурные подразделения организа­ции вынуждены локально формировать собственные системы классификаторов, а также словарей и нормативов;
  3. Регистрация документов проводит­ся вручную и часто дублируется в каж­дом структурном подразделении. При этом используются какие-либо таблицы или списки;
  4. Маршрутизация документов не автома­тизирована. Документ направляется толь­ко по маршруту, выбираемому очередным исполнителем, что затрудняет соблюде­ние регламентов, принятых в организации (особенно при согласовании документов);
  5. Затруднено проведение контроля за своевременным исполнением документа. Напомнить о документе при этом можно только дополнительным письмом, отправленным вручную, или позвонив по телефону;
  6. Невозможно осуществить автоматизированный поиск документов;
  7. Электронная почта не предполагает проведения подобной операции.

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

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

1.3 Характеристика документооборота, возникающего при решении задачи

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

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

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

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

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

Необходимо задействовать в данном агентстве программу, в которую будут вноситься все заключенные договоры с клиентами. В агентстве есть программа, которая называется egency. Это программа, в которую при подтверждении клиентом размещения рекламной кампании менеджер вносит сумму подтвержденного плана, СМИ по которому сделан план, название клиента и размер агентской комиссии. И этому клиенту присваивается номер, который называют проектом. Далее этот проект автоматически выгружается в excel. Этот документ называется job – это название ему присвоило агентств. Но работать в этой программе не очень удобно. На это есть ряд причин. Например, если в плане по размещению в прессе фигурируют 20 изданий, в которых решил разместиться клиент, то программа выгрузит в excel только часть этих изданий, а именно 15. Это лимит этой программы. Она выгружает только 15 изданий или каналов. Остальные 5 приходится вносить в excel самостоятельно. А если этих изданий в плане 50 или 100. Тогда можно только себе представить, сколько менеджеру потребуется времени на то чтобы это внести в еxcel. Если вспомнить клиента «Синергию», то этих изданий по нему было 75. И мы можем только сочувствовать менеджеру, который каждый раз вбивал руками остальные не выгруженные издания. Почему каждый раз? Потому что клиент очень много раз менял план.

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

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

Отдел трафиков, получив этот job приступают к подготовке приложения. Приложение – это документ, который составляется по определенному СМИ, в котором размещается клиент. В нем прописываются суммы, период и обязанности которые клиент должен по этому проекту выполнить. Это приложение от трафиков направляется в отдел баийнга и в клиентский сервис (менеджеру который ведет клиента) для утверждения. Это неверно. Менеджер должен получать уже готовый документ, чтобы он его просто направил клиенту. А отдел баийнга его должен проверить. Т.е. должно быть так: трафики должны выслать приложение в отдел баийнга на проверку, а как только они все проверят, они должны отослать приложение менеджеру, чтобы тот его отправил клиенту. Это было бы гораздо быстрее, нежели сначала бы трафики ждали ответа от баийнга и от клиентского сервиса, а потом менеджер высылал документ клиенту. Это связанно с тем что отдел баийнга зачастую не считает нужным проверять этот документ и тянет с его проверкой откладывая все время на потом. В этом случае необходимо сделать следующим образом: приложение должно отправляться отделом трафиков непосредственно в баийнг отдел на проверку, т.к. именно баийнг отдел предоставляет стоимость и сам план по размещению. Баийнг отдел должен проверять этот документ. А менеджеру уже должен отправляться документ поверенный отелом баийнга и он просто его отправляет клиенту.

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

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

1.4 Обоснование проектных решений по информационному обеспечению

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

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

1) Входные и выходные документы. Входными документами системы являются сведения о клиентах.

Выходными документами являются договора с клиентами.

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

2) Экранные формы

Для построения диалога с пользователем возможны следующие способы: диалог типа «Вопрос-ответ»; диалог типа «Меню», диалог на основе экранных форм, диалог на основе командного языка.

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

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

Условно-постоянная информация будет храниться в справочниках. В системе потребуются следующие справочники:

  • Справочник «Список продукции»;
  • Справочник «Типы продуктов»;
  • Справочник «Фирмы»;
  • Справочник «Контент».

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

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

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

Необходимо разработать локальную систему классификации и кодирования для следующих объектов учета:

- фирм;

- продуктов;

- типов продуктов.

4) Информационная база. Центральным компонентом информационного обеспечения является информационная база (ИБА), представляющая собой организованную определенным способом совокупность данных, хранимых в памяти вычислительной системы в виде файлов, с помощью которых удовлетворяются информационные потребности управленческих процессов и решаемых задач. [1]

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

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

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

Основными способами организации БД являются создание централизованных и распределенных БД. [4] В рассматриваемой задаче не предполагается распределенная структура ИС, т.к. задача небольшая по объему данных и по количеству пользователей.

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

1.5 Обоснование проектных решений по программному обеспечению

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

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

Для получения информации о характеристиках СУБД воспользуемся информационными порталами:

  1. www.tpc.org – зарубежная некоммерческая корпорация, сосредоточенная на разработке и проведении тестирования производительности программных и аппаратных комплексов;
  2. www.msdn.ru – крупнейший портал русскоязычный сайт, посвященный программному обеспечению.

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

Основными компонентами MS Access являются построитель таблиц, экранных форм, SQL-запросов (язык SQL в MS Access не соответствует стандарту ANSI), отчётов, выводимых на печать.

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

MS Access обладает худшим функционалом по сравнению с MS SQL Server. Но возможности MS Access по написанию приложений существенно расширяются благодаря механизму связи с различными внешними СУБД: «связанным таблицам» (связь с таблицей СУБД) и «запросам к серверу» (запрос на диалекте SQL, который «понимает» СУБД). Также благодаря MS Access можно строить полноценные клиент-серверные приложения на СУБД MS SQL Server. При этом есть возможность совмещения с присущей MS Access простотой инструментов для управления БД и средств разработки [6].

На рисунке 4 представлен скриншот главного рабочего окна СУБД MS Access.

Рисунок 4 – Рабочее окно СУБД MS Access

Microsoft Visual FoxPro (VFP)  представляет собой среду разработок системы баз данных, в которую включены объектно-ориентированная реляционная СУБД, объектно-ориентированный язык программирования, чтобы разрабатывать приложения баз данных, а также входит система построения отчётов [1].

В основе Microsoft Visual FoxPro лежит система FoxPro, у которой язык принадлежит к языкам xBase, которые разрабатывались на основе синтаксиса такого языка программирования, как dBase. Другие члены - представители этого семейства языки Clipper и Recital.

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

У Visual FoxPro высокая скорость при обслуживании базы данных. Благодаря использованию стандарта ODBC и SQL-запросов для выборки данных, Visual FoxPro дает возможность осуществлять работу с базой данной СУБД Access, Paradox, dBase и т.д., с серверами базы данных - Microsoft SQL Server, Oracle и др. Благодаря Visual FoxPro создаются сетевые приложения (т.е. приложения, которые функционируют в сетях).

Когда создаются проекты, базы данных, таблицы, запросы, формы, отчеты, при­ложения и другие элементы в среде Visual FoxPro, то каждый из вышеперечисленных элементов помещается в отдельный файл, пользователь называет файл любого элемента любым именем, а расширение формируется в автоматическом режиме и помогает идентифицировать эти элементы (объекты). Элементы проектов Visual FoxPro и соответствующие им расширения имена файлов приведены в таблице 1. У файлов элементов, которые созданы на базе других (родительских) элементов, общие с родительскими имена.

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

Отладку приложений осуществляли в двух окнах - Trace и Debug, в этой же версии для полнофункционального отладчика, запускаемого в собственном окне и имеющего 5 панелей: Trace, Watch, Locals, Call Stack и Output отладку сделать проще. Конфигурация панелей настраивается и сохраняется, можно перетаскивать с панели на панель.

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

На рисунке 5 представлен скриншот Visual FoxPro.

http://2.bp.blogspot.com/-PEjGiy7HTfE/Tub7I_fqL3I/AAAAAAAAAHQ/dhESAh3psS0/s1600/latiha14.gif

Рисунок 2 –Visual FoxPro

В качестве создания базы данных была выбрана СУБД Microsoft Access.

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

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

В настоящее время лидерами на рынке сред разработки являются Microsoft Visual Studio, Delphi, C++ Builder, JBuilder. Любая из перечисленных сред позволит разработать современное клиент-серверное приложение с современным пользовательским интерфейсом.

Microsoft Visual Studio – линейка продуктов компании Майкрософт, включающих интегрированную среду разработки программного обеспечения и ряд других инструментальных средств. Данные продукты позволяют разрабатывать как консольные приложения, так и приложения с графическим интерфейсом, в том числе с поддержкой технологии Windows Forms, а также веб-сайты, веб-приложения, веб-службы как в родном, так и в управляемом кодах для всех платформ, поддерживаемых Microsoft Windows, Windows Mobile, Windows CE, .NET Framework, .NET Compact Framework и Microsoft Silverlight.

Язык программирования Delphi

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

Delphi – это комбинация нескольких важнейших технологий:

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

Язык программирования Си++

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

Достоинством языка является:

  1. Поддержание различных стилей и технологий программирования, включая традиционное директивное программирование, объектно-ориентированное программирование.
  2. Возможность работы на низком уровне с памятью, адресами, портами.
  3. возможность создания обобщённых алгоритмов для разных типов данных, их специализация и вычисления на этапе компиляции, используя шаблоны.
  4. Кроссплатформенность. Доступны компиляторы для большого количества платформ.
  5. Эффективность. Язык спроектирован так, чтобы дать программисту максимальный контроль над всеми аспектами структуры и порядком исполнения программы.

Недостатки:

  1. Сложность и избыточность, из-за которых C++ трудно изучать, а построение компилятора сопряжено с большим количеством проблем. В частности:
    • В языке практически полностью сохранён набор конструкций Си, к которому добавлены новые средства. Во многих случаях новые средства и механизмы позволяют делать то же самое, что и старые, но в языке сохраняются оба варианта;
    • Поддержка множественного наследования реализации в ООП-подсистеме языка вызывает логические проблемы, а также создаёт дополнительные трудности в реализации компилятора;
    • Шаблоны в своём исходном виде приводят к порождению кода очень большого объёма, а введённая позже в язык возможность частичной спецификации шаблонов трудно реализуема и не поддерживается многими существующими компиляторами.
  2. Недостаток информации о типах данных во время компиляции (CTTI).
  3. Метапрограммирование на основе шаблонов C++ сложно и имеет ограничения в возможностях. Оно состоит в реализации средствами шаблонов C++ интерпретатора примитивного функционального языка программирования выполняющегося во время компиляции. Такой код трудно воспринимать и отлаживать.
  4. Отсутствие поддержки функционального программирования. Отчасти, данный пробел устраняется различными библиотеками (Boost) использующими средства метапрограммирования для расширения языка функциональными конструкциями (например, поддержкой лямбд/анонимных методов), но качество подобных решений значительно уступает качеству встроенных в функциональные языки решений.

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

Таблица 1

Сравнение характеристик языков программирования

С

С++

С#

Perl

Delphi

PureBasic

Функциональный

-

+/-

+/-

+

+/-

+/-

Обобщенное программирование

-

+

+

+

+

+/-

Возможность компиляции

+

+

+

+

+

+

Многопоточная компиляция

+

+

-

?

?

+

Интерпретатор командной строки

-/+

+/-

-

+

-

-

Ручное управления памятью

+

+

+

-

+

+

Поддержка try/catch

-

+

+

+

+

+

Алгебраические типы данных

-

-

-

-

-/+

-

Многомерные массивы

+

+

+

+/-

+

+

Целые числа с контролем границ

-

-

-

-

+

-

Интерфейсы

-

+

+

+/-

+

-

Макросы

-/+

-/+

-

+

-

+

Локальные функции

-/+

+

+/-

+/-

+

?

В качестве средства разработки была выбрана среда разработки Borland Delphi, которая способна предоставить значительные возможности разработчику и имеет ряд преимуществ перед другими средами разработки, таких как:

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

2. Проектная часть

2.1 Информационная модель и её описание

Информационная модель задачи показана на рис.6.

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

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

Рис.6. Информационная модель задачи

2.2 Характеристика результатной информации

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

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

Общие положения (дерево функций и сценарий диалога)

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

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

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

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

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

Рис.7. Дерево функций ИС

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

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

В процессе диалога возможно:

  • двустороннее управление на базе языка типа «запрос-ответ»,
  • одностороннее управление со стороны ИС с языком общения типа «меню», «заполнения шаблона», ответа по «подсказке»,
  • одностороннее управление со стороны пользователя с использованием языка директив (команд).

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

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

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

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

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

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

Сценарий диалога состоит из двух логически связанных частей:

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

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

2.3 Характеристика базы данных

База данных должна позволять хранение следующей информации:

  1. Список имеющихся в наличии фирмы рекламных щитов (адрес, по которому расположен щит, размеры щита, название конструкции).
  2. Список фирм, являющихся клиентами и заказывающих рекламу (название, телефон, ИНН, контактное лицо).
  3. Перечень договоров, заключенных с каждой фирмой. В договоре определено, в каком интервале времени на щите должно находиться определенное рекламное объявление, указана стоимость договора. Договор может быть заключен заранее (пока на щите размещена реклама другой фирмы), и в этом случае полная оплата может осуществляться позднее.
  4. Перечень рекламных объявлений (название, габариты, фотография, фирма-заказчик). Одно объявление может быть размещено на нескольких щитах в разные моменты времени.
  5. Список фирм, устанавливающих рекламные щиты (название, телефон, ИНН, контактное лицо). Некоторые из этих фирм сами могут заказывать у нас рекламу.
  6. Информация о договорах с фирмами-установщиками щитов (когда фирма должна установить новый щит, какими параметрами он должен обладать, стоимость договора).

Структурная схема пакета (дерево вызова программных модулей)

Схема программных модулей содержит программные модули различных классов:

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

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

Рис. 9. Схема взаимосвязи программных модулей ИС

Контрольный пример реализации проекта и его описание

Главное окно программы представлено на рисунке 10.

Рис. 10. Схема взаимосвязи программных модулей ИС

Окна программы представлены на рисунке 11.

Курсовая работа Delphi

Рисунок 11 – Окна программы

Курсовая работа Delphi

Рисунок 12 – Применение фильтра

Заключение

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

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

В отличие от дорогих и сложных программ автоматизации, разработанная программа действительно хорошо подходит для представителей малого и среднего бизнеса, так как включает все, что им необходимо, но не перегружена избыточными возможностями. Использование технологии создания программы в визуальных средах программирования делает ее интерфейс универсальным и совместимым с операционными системами Windows XP/7/Vista. Также одним из преимуществ программы является то, что она не требует достаточно большого свободного дискового пространства, так как комплект поставки занимает всего лишь 1,9 Mb памяти.

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

  1. РД 50-34.698-90. Автоматизированные системы. Требования к содержанию документов.
  2. ГОСТ 34.601-90. Автоматизированные системы. Стадии создания.
  3. ГОСТ 34.602-89. Информационная технология.
  4. ГОСТ 19.701-90. Единая система программной документации. Схемы алгоритмов, программ, данных и систем. Условные обозначения и правила выполнения.
  5. РД IDEF0 2000. Методология функционального моделирования.
  6. Автоматизированные информационные технологии в экономике /Под ред. проф. ГА, Титоренко. - М.: ЮНИТИ, 2008.
  7. Введение в системы баз данных – СПб: Издательский дом "Вильямс", 2000. - 848 с.;
  8. Вендров А.М. Проектирование программного обеспечения экономических информационных систем. - М: «Финансы и статистика», 2000
  9. Грекул В.И., Денищенко Г.Н., Коровкина Н.Л. Проектирование информационных систем – М.: ИНТУИТ.ру, 2005
  10. Данелян Т.Я. Организация и функционирование больших информационных систем. -М.: МЭСИ, 2007
  11. Ивлиев М.К., Порошина Л.А. Автоматизация оперативного и бухгалтерского учета товаров, 1997.
  12. Информационные системы в экономике /Под ред. В.В. Дика. - М.: Финансы и статистика, 2006.
  13. Информационные системы: Учебник для вузов. 2-е изд. СПб: "Питер", 2005 г - 656 стр.
  14. Крис Дейт. Введение в базы данных, 6-е изд. Киев, Диалектика, 1998.
  15. Разработка программного обеспечения - СПб : "Питер", 2004 г - 592 стр.