Диплом Разработка АРМ менеджера по продажам

Содержание
Введение 3

  1. Аналитическая часть 6
    1.1. Постановка задачи 6
    1.2. Характеристика предприятия МК «Стрела» 6
    1.3. Организационно-экономическая сущность задачи 9
    1.4. Обоснование использования вычислительной техники для решения данного комплекса задач 10
    1.5. Требования к разрабатываемой информационной системе 12
    1.5.1. Требования к системе в целом 12
    1.5.2. Требования к функциям (задачам) 13
    1.5.3. Системотехнические требования к разрабатываемой системе 13
    1.5.4. Требования к видам обеспечения 14
    1.6. Анализ существующих разработок 15
    1.6.1. Скайнет: АРМ (автоматизация работы менеджера) 15
    1.6.2. АССистент: Менеджера по продажам 16
    1.6.3. «Эврика» от РУСЛАН Коммуникейшнз 16
    1.7. Выбор СУБД, технических средств разработки, определение среды функционирования программы 17
  2. ПРОЕКТНАЯ ЧАСТЬ 20
    2.1. Функционально-ориентированное и объектно-ориентированное проектирование информационной системы 20
    2.1.1. Проектирование модели IDEF0 20
    2.1.2. Модель объектно-ориентированной программной системы 24
    2.2. Используемые классификаторы и системы кодирования 27
    2.3. Проектирование информационного обеспечения 30
    2.3.1. Информационный анализ предметной области и выделение информационных объектов 30
    2.3.2. Построение логической модели данных 32
    2.3.3. Описание таблиц базы данных 34
    2.4. Характеристика входной информации 36
    2.5. Характеристика результатной информации 37
    2.5.1. Характеристика результатных документов. 37
    2.5.2. Характеристика таблиц с результатной информацией 37
    2.6 Машинная реализация комплекса задач 38
    2.6.1 Описание структуры диалога 38
    2.6.2. Описание программных модулей 39
    2.6.3 Схема взаимосвязи программных модулей и информационных файлов 40
    2.7. Разработка программного обеспечения системы 43
    2.7.1. Проектирование экранных форм для ввода данных 43
    2.7.2. Тестирование и оценка программного продукта 44
    2.8. Описание контрольного примера реализации проекта. 46
  3. Обоснование экономической эффективности проекта 56
    3.1. Смета затрат на разработку 56
    3.1.1. Определение трудоемкости 56
    3.1.2. Структура затрат на разработку программного изделия (относительная трудоемкость стадий) 56
    3.1.3. Расчет количества условных команд разрабатываемого программного изделия 57
    3.2. Расчет трудоемкости разработки программного изделия по стадиям 58
    3.3. Расходы на разработку 63
    Заключение 70
    Список использованных источников 71
    Приложения 72

Введение

За последние двадцать лет значительно возрос объём и оборот информации во всех сферах жизнедеятельности человека: экономической, финансовой, политической, духовной. И процесс накопления, обработки и использования знаний постоянно ускоряется. Учёные утверждают, что каждые десять лет количество информации увеличивается вдвое. В связи с этим возникает необходимость использования автоматических средств, позволяющих эффективно хранить, обрабатывать и распределять накопленные данные.
Исходя из современных требований, предъявляемых к качеству работы финансового звена крупного предприятия, нельзя не отметить, что эффективная работа его всецело зависит от уровня оснащения компании информационными средствами на базе компьютерных систем автоматизированного складского учета.
Компьютерный учет имеет свои особенности и радикально отличается от обычного. Компьютер не только облегчает учет, сокращая время, требующееся на оформление документов и обобщение накопленных данных для анализа хода торговой деятельности, необходимого для управления ею. Отчеты о положении в торговле, получаемые с помощью компьютера, можно получить и без него – никакой особой математики в компьютере не содержится – но на расчеты уйдет столько времени, что они уже ни на что не будут нужны; или ими придется занять такое количество расчетчиков, что на их зарплату уйдет значительно больше, чем будет получено прибыли в результате их расчетов. Таким образом при применении компьютера “количество переходит в качество”: увеличение скорости расчетов делает возможным качественное улучшение самой схемы построения торговли.
Программное обеспечение для работы с базами данных используется на персональных компьютерах уже довольно давно. К сожалению, эти программы либо были элементарными диспетчерами хранения данных и не имели средств разработки приложений, либо были настолько сложны и трудны, что даже хорошо разбирающиеся в компьютерах люди избегали работать с ними до тех пор, пока не получали полных, ориентированных на пользователя приложений.
Предлагаемый проект реализует автоматизированное рабочее место менеджера отдела продаж. Данная система должна обеспечивать возможность учета заявок, распределения товаров на предприятии и обеспечивать ввод, удаление, хранение, редактирование и выдачу информации, которая содержится в таблицах базы данных.
Целью данной дипломной работы является разработка АРМ Менеджера по продажам МК «Стрела». Для достижения данной цели необходимо решить следующие задачи:
• провести анализ работы менеджера;
• выявить экономическую сущность задачи;
• обосновать необходимость и цели использования вычислительной техники для решения задач;
• определить цель и назначение автоматизированного варианта решения задачи;
• провести анализ существующих разработок;
• обосновать проектные решения по видам обеспечения;
• построить информационную модель;
• описать характеристики БД и программные модули;
• обосновать экономическую эффективность проекта.
В первой части проекта рассмотрена структура и характеристика предприятия, экономическая сущность задачи. Определены недостатки существующей системы обработки информации и дано обоснование необходимости совершенствования информационной системы.
Во второй части данной работы представлена функциональная модель системы с использованием методологии IDEF0, функциональная структура данных в виде диаграммы вариантов использования, представлен информационный анализ предметной области. Здесь рассмотрены функциональные зависимости между реквизитами, а также процессы выделения информационных объектов и построение логической структуры баз данных. Также в разделе рассмотрены алгоритмы реализации основных проектных решений и их декомпозиция на составляющие процессы, представлены разработанные экранные формы, а также результаты тестирования и оценки надёжности работы программного обеспечения.
В третьей части проекта изложено обоснование экономической эффективности проекта.

  1. Аналитическая часть
    1.1. Постановка задачи

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

  • ведение базы данных товаров и клиентов;
  • учет заявок от торговых представителей и отгрузку товара по каждой заявке;
  • формирование статистической и аналитической информации.
    Область применения программы – это отдел продаж МК «Стрела». Менеджер может легко извлекать, заносить и изменять информацию в базе данных. Создание программы обусловлено тем, что отдел продаж не нуждается в универсальном пакете прикладных программ, а достаточно небольшой узкоспециализированной программы, которая бы смогла выполнять необходимые действия.
    1.2. Характеристика предприятия МК «Стрела»
    Мясоперерабатывающая компания «Стрела» основана в городе Котласе, на юге Архангельской области, в 1998 году.
    В течение последующих шести лет предприятие постепенно набирало обороты, но настоящий бум деятельности произошел в 2004 году, когда «Стрелу» возглавил новый генеральный директор – Оксана Тюкавина. Она пригласила в компанию высокопрофессиональных специалистов, имеющих большой опыт работы на знаменитом «Котласском мясокомбинате». Под руководством талантливого руководителя они модернизировали производство.
    Компанию «Стрела» отличают и творческие методы работы в сфере продаж. Они направлены на индивидуальный подход к каждому клиенту и увлекательные рекламные кампании, которые вызывают широкий интерес.
    На территории фирмы выделена площадь под склады, где хранятся основные виды товаров, продаваемых клиентам, поэтому менеджеры могут контролировать наличие товаров на складе, отгрузку, погрузку и проводить инвентаризацию в непосредственной близости от офиса. Благодаря этому упрощена схема документооборота.
    Продукция поступает непосредственно с мясокомбината, перерабатывается и реализуется клиентам, нуждающимся в данном виде товаров. Организация осуществляет производство и транспортировку продукции с производства на базу, ее складирование, хранение и отгрузку клиентам.
    Номенклатура реализуемых товаров составляет несколько сотен наименований и постоянно увеличивается. В основном это продукты мясопереработки и мясные полуфабрикаты
    Внутренняя организационная структура фирмы представляет собой схему изображенную на рисунке 1.1

Рис. 1.1 Внутренняя структура организации
Во главе фирмы стоит генеральный директор, который решает в основном управленческие вопросы, а также вопросы стратегического характера. Он контролирует деятельность всех отделов. Также в его компетенции вопросы движения финансовых потоков.
Закупкой товаров занимается отдел снабжения. В его функции также входит поиск новых поставщиков с более выгодными условиями поставки. Этот отдел решает вопросы закупки по всему ассортименту. Закупка производится на основании заявок, оформленных менеджерами.
Отдел бухгалтерии включает в себя три подотдела: это главный бухгалтер, платежи и касса.
Главный бухгалтер ведет бухгалтерский учет, делает баланс, различные встречные сверки, считает все налоги и решает вопросы, возникающие в отделах, находящихся в его подчинении.
Отдел «Платежи» предполагает отправку и получение платежей из банка через специальную банковскую программу. Это оплата по счетам поставщикам, уплата налогов, каждодневные получения денежных средств на расчетный счет фирмы от клиентов и др. платежи.
Кассир занимается распределением наличных средств фирмы (выдача заработной платы, выделение средств на хозяйственные нужды, выдача командировочных и т.д.)
В производственный отдел входят: отдел переработки и отдел контроля качества.
Отдел переработки занимается непосредственно переработкой поступившего сырья в готовые изделия или полуфабрикаты.
Отдел контроля качества контролирует выпуск готовой продукции ГОСТам и санитарным нормам.
В отдел сбыта входят менеджеры, которые занимаются непосредственно клиентами. Каждый менеджер имеет совою базу клиентов, с которыми он работает. Он заключает договора, обговаривает сроки, условия поставки и оплаты товара; осуществляет прием заказов от покупателей. Увеличивает свою базу клиентов за счет поиска новых.
Автоматизированное рабочее место предназначено для решения задач отдела «Выписка». Основные задачи данного отдела – это работа с менеджерами отдела сбыта, прием заявок на товар, занесение их в базу данных, распределение имеющегося на складе товара, выписка нарядов на отгрузку.
Рассмотрим подробнее экономическую сущность задач, решаемых по фирме в целом и отдельно по отделу выписка.

1.3. Организационно-экономическая сущность задачи
Внедрение разработанной автоматизированной системы имеет следующие цели:

  • повышение уровня автоматизации и качества обработки информации;
  • упрощение поиска и доступа к информации, необходимой для составления отчетной документации;
  • сокращение времени обработки и получения информации;
  • возникновение принципиально новых возможностей для работы пользова¬телей системы, например, работа с общей информационной базой;
  • исключение необходимости хранения информации на бумажных носителях.
    Следствием достижения приведенных выше целей является снижение трудоемкости выполняемых менеджером операций, снижение количества «бумажной» работы, повышение качества и оперативности управления процессом выписки товара.
    Хозяйственный учет представляет собой совокупность бухгалтерского, оперативного и статистического учета. Учет – одна из наиболее трудоемких функций управления. Отличительной чертой учета является большая массовость и однородность исходных и итоговых показателей. Как правило, итоговые показатели формируются путем многократной группировки по различным признакам исходных первичных данных без применения сложных расчетов.
    Управление торговыми процессами в МК «Стрела» основывается на информации, отражающей объем, структуру и динамику поступления, продажи и запасов товаров. Движение информации между МК «Стрела» и внешней средой (поставщиками, покупателями) осуществляется в форме потоков информации. По отношению к оптовому предприятию различают входные, внутренние и выходные потоки информации (входную, внутреннюю и выходную информацию). От рациональной организации потоков информации оптового предприятия, способов сбора, регистрации, передачи, хранения и обработки информации, ее состава и своевременного получения зависят оперативность и эффективность управления торговыми процессами.
    В соответствии с данными целями необходимо разработать информационную систему, использующую современные компьютерные технологии и автоматизирующую большинство функций, выполняемых менеджером по продажам.
    1.4. Обоснование использования вычислительной техники для решения данного комплекса задач

За последние двадцать лет значительно возрос объём и оборот информации во всех сферах жизнедеятельности человека: экономической, финансовой, политической, духовной. И процесс накопления, обработки и использования знаний постоянно ускоряется. Учёные утверждают, что каждые десять лет количество информации увеличивается вдвое. В связи с этим возникает необходимость использования автоматических средств, позволяющих эффективно хранить, обрабатывать и распределять накопленные данные.
В настоящее время все предприятия испытывают настоятельную потребность в расширении аналитических работ, связанных с разработкой перспектив развития, комплексной оценкой эффективности применения различных форм хозяйствования, своевременной выработкой оперативных управленческих решений.
При помощи ЭВМ на предприятии МК «Стрела» автоматизирован учет поступления и продажи товаров, учет расчетов с поставщиками и покупателями, операций по расчетному счету, количественно-суммовой учет. В общем объеме учетных работ эти задачи имеют значительный удельный вес.
Их автоматизация позволяет сократить ручные операции, ускорить обработку информации, повысить точность учета. В памяти ЭВМ хранится и может быть выдана на печать детальная информация о количестве поступления и продажи конкретного товара по каждому документу в случае несовпадения величины запаса с данными машинного учета.
Исходной информацией для учета являются первичные документы. При ручном учете, а также частичной автоматизации обработки информации каждое подразделение предприятия (бухгалтерия, отдел закупок и продаж и др.) для выполнения возложенных на них функций вводит в ЭВМ по существу одни и те же данные из первичных документов, на основе которых составляются отчетные и другие выходные документы бухгалтерского, оперативного и статистического учета. Создание в каждом подразделении своей собственной информационной базы приводит к многократному дублированию информации, увеличению времени и стоимости ее обработки.
Главное назначение автоматизированного рабочего места в данном случае – повысить эффективность выполнения основных функций менеджера, поскольку, как можно увидеть, функционирование блока выписки связано с большим документным и информационным потоком. Кроме того, АРМ Менеджера призвано улучшить оперативность принятия решений, повысить производительность труда, снизить количество вычислительных ошибок при помощи автоматизации процесса обработки информации, содействовать эффективному и безопасному хранению и доступу к информации.
Сотрудники торговых предприятий более половины рабочего времени затрачивают на выполнение многочисленных трудоемких учетно-технических операций обработки информации, связанных с оперативным учетом поступления, продажи и запасов товаров. Выполнение элементарных процедур обработки данных не требует специальных знаний. По мере роста объема информации доля таких работ возрастает. Это ведет к уменьшению времени на выполнение таких важных творческих работ, как изучение конъюнктуры торговли, определение потребности в товарах, контроль, анализ и регулирование поставок и запасов товаров и т.п.
Массовые, повторяющиеся операции по оформлению продажи товаров, ведению оперативного учета относятся к числу задач, поддающихся формализации и, следовательно, автоматизации.
Автоматизация оперативного управления торговыми процессами требует тщательной проработки состава переменной и постоянной информации. Данные, характеризующие, например, товары и покупателей (постоянная информация), должны обеспечить автоматизацию обработки заказов, оперативного учета поступления и продажи товаров.
Автоматизированное рабочее место менеджера по продажам МК «Стрела» повышает его оперативность и эффективность, улучшает товароснабжение розничной торговой сети.
1.5. Требования к разрабатываемой информационной системе
1.5.1. Требования к системе в целом
К системе предъявляется ряд требований:

  • Система должна быть легко переносимой с одного компьютера на другой;
  • Работа системы не должна зависеть от версии Windows;
  • Система должна работать на компьютерах различных конфигураций.
    1.5.2. Требования к функциям (задачам)
    АРМ менеджера должно реализовывать следующие функции:
  • добавление, изменение и удаление видов продукции МК «Стрела» в базу данных;
  • ввод, редактирование и удаление данных клиентов из базы;
  • ввод, редактирование и удаление заявок;
  • создание нарядов на склад и редактирование предыдущих;
  • формирование отчетов по результатам работы менеджера.
    1.5.3. Системотехнические требования к разрабатываемой системе
    1) Открытость, то есть совместимость со всеми современными стандартами, возможность наращивания функциональности за счет взаимодействия с другим программным обеспечением;
    2) масштабируемость, как ключевое требование с точки зрения экономии вложений, гарантирующее, что не придется перестраивать систему по мере роста объема обрабатываемой информации и количества одновременно работающих пользователей;
    3) переносимость, или способность работать на различных аппаратных платформах, операционных системах, серверах баз данных;
    4) расширяемость и возможность наращивания функциональных возможностей системы, не выходя за рамки принятой изначально концепции развития и технологической базы, в соответствии со специфическими потребностями пользователей.
    Аппаратно-программные средства системы должны создаваться на передовых мировых технологиях в сфере телекоммуникаций и автоматизации управления и удовлетворять следующим основным требованиям:
    1) поддерживать возможность хранения в единой базе данных больших объемов информации (комплексность, единство базы данных), обеспечивать возможности функционального расширения и наращивания мощности (расширяемость и масштабируемость);
    2) поддерживать распределенную обработку информации, доступ к ресурсам системы по локальной сети;
    3) использовать единую систему классификации и кодирования (унифицированность);
    4) иметь встроенные средства оперативной аналитической обработки данных;
    5) обеспечивать высокую надёжность и устойчивость к сбоям;
    6) обеспечивать непротиворечивость и полноту хранимой информации (целостность);
    7) обеспечивать надлежащий уровень защиты и конфиденциальности передаваемых данных (безопасность).
    1.5.4. Требования к видам обеспечения
    Данные вводятся в таблицы через экранные формы, разработанные в среде Delphi 7, вывод результатов также производится с помощью экранных форм Delphi.
    Параметры информационных потоков:
  • объем информации – в целом, планируемый объем поступающей информации не должен превысить объема жесткого диска, так как, не смотря на приток информации за счет пополнения числа клиентов и заявок, записи с истекшим сроком надобности удалены;
  • тип носителя информации – жесткий диск;
  • информация будет представляться в виде отчетов (в электронном варианте), с возможностью отправки на печать.
    Перечень аппаратных и программных средств, необходимых для работы информационной системы:
    1) при минимальной конфигурации: процессор с тактовой частотой не меньше 333 MHz; ОЗУ – 64 МВ; Video – 8 МВ; ОС – Windows 95/98; ПО – MS Office 97 и выше, клавиатура/мышь, монитор.
    2) при оптимальной конфигурации: процессор с тактовой частотой не меньше 1 GHz; ОЗУ – 256 Mb; Video – 64 МВ; ОС – Windows 98/2000/NT/ХР; ПО – MS Office 97 и выше, клавиатура/мышь, монитор.
    3) при максимальной конфигурации: процессор с тактовой частотой 2.6 GHz; ОЗУ – 1024МВ; Video – 256МВ; ОС – Windows 98/2000/NT/XP; ПО – MS Office 97 и выше, клавиатура/мышь, монитор.
    1.6. Анализ существующих разработок
    1.6.1. Скайнет: АРМ (автоматизация работы менеджера)
    Скайнет: АРМ — это набор приложений, связанных единой бизнес логикой, с интегрированной в них базой данных предприятий и организаций Скайнет.
    Скайнет: АРМ — это и оперативный CRM, который может работать как планировщик задач или органайзер, и аналитический CRM — можно получить статистику и отчеты по различным срезам. Эта информация важна, т.к. позволяет в дальнейшем пользователю корректировать свои действия.
    Преимущества:
  • Создает основу стандартизации бизнес-процесса продаж;
  • Накопленная информация о клиентах становится достоянием Вашей компании, а не отдельных менеджеров;
  • Уменьшается риск потери накопленной информации при уходе из компании сотрудников; делает невозможным появления в компании «незаменимых» людей;
  • Значительно затруднит несанкционированный доступ к информации по сравнению с другими формами хранения: бумажные носители, электронные таблицы и пр.
    Недостатки:
  • Отсутствие возможности занесения в базу заявок от клиентов;
  • Высокая стоимость (более 1000$ за локальную версию).
    1.6.2. АССистент: Менеджера по продажам
    Данная программа призвана облегчить труд менеджеров по продажам. Это мощный инструмент сохранения и систематизации опыта продаж и анализа рынка.
    Преимущества:
  • Широкие возможности для сбора статистической и аналитической информации;
  • Высокая степень защиты от несанкционированного доступа к информации.
    Недостатки:
  • Отсутствие возможности занесения в базу заявок от клиентов;
  • Сложность. Для работы с программой необходимо первоначальное обучение.
    1.6.3. «Эврика» от РУСЛАН Коммуникейшнз
    CRM-решение, предлагаемое «РУСЛАН Коммуникейшнз», подходит для небольшого предприятия, так как стоит в несколько раз меньше аналогичных продуктов западного производства, менее приближенных к российской действительности и не имеющих поддержки на местах.
    В процессе работы системы постоянно обновляется полная информация о существующих и перспективных партнерах компании, в том числе и информация о телефонных звонках и других контактах данного человека или организации, о посещениях Web-сервера, о завершенных и текущих контрактах и т.д. Система ведет своего рода архив общения с клиентами, напоминая об истечении срока действия контракта, о времени со дня последнего звонка клиенту и т.п. В момент телефонного звонка на компьютер отвечающего сотрудника поступает полная информация о звонящем, так что сотрудник к началу разговора уже готов к общению.
    Основополагающим элементом новой структуры является осуществление взаимодействия между Web-порталом предприятия и его телефонной структурой. Одновременная работа в Интернете и по телефону, совместные обсуждения и совместная работа с одними и теми же документами могут производиться не только среди сотрудников предприятия, но и с внешними клиентами. Одновременное взаимодейcтвие с внешним миром через браузер и общение по телефону позволяет осуществлять оперативное взаимодействие с клиентом и со всеми заинтересованными лицами в компании в целях оперативного решения текущих вопросов. В результате увеличивается эффективность работы не только каждого конкретного сотрудника, но и предприятия в целом.
    Недостатки:
  • Высокие системотехнические требования для работы программы, наличие доступа в Интернет обязательно;
  • Необходимость ввода большого количества данных о клиентах, товарах и услугах.
    1.7. Выбор СУБД, технических средств разработки, определение среды функционирования программы
    Выбор СУБД определяется запросами конечного пользователя АРМ, а так же затратами на ее создание. В данной конкретной ситуации выбор определяется надежностью, дешевизной, удобностью и эффективностью СУБД. В современных СУБД в подавляющем большинстве случаев используется реляционная модель представления данных. Причем развитые версий таких СУБД работают под управлением MS Windows (FoxPro , Paradox , Clipper).
    Для увеличения эффективности операций с реляционными базами данных часто работают с отдельными записями и полями, а не с отношениями. Такой подход давно используется в сетевых и иерархических базах данных. Таким образом, отчетливо наблюдается движение от классической реляционной модели к некой смешанной модели данных, которая призвана объединить все лучшие свойства других моделей, и явится, видимо, их симбиозом.
    Для наших целей хорошо подходит СУБД Access, созданная компанией Microsoft. Данная СУБД поддерживает проверку данных на уровне полей и записей. Целостность данных обеспечивается при помощи первичных ключей и проверки ссылок между таблицами [6].
    Для манипулирования данными Jet-машина поддерживает язык SQL. SQL позволяет при помощи одного оператора считывать, добавлять, удалять или обновлять группы записей на основе определенных пользователем критериев. SQL запросы в СУБД Jet предоставляет очень широкие возможности благодаря увеличенному количеству функций это выгодно отличает ее от других СУБД. Также Jet разрешает довольно гибко модифицировать данные, выбранные в SQL запросах (например, можно редактировать упорядоченные записи) [7].
    Также Jet-машина обеспечивает широкие средства для обеспечения безопасности базы данных. В совокупности с развитым средством работы с базой данных MS Access это делает выбор СУБД практически предопределенным.
    После выбора СУБД перейдем к выбору среды разработки. С точки зрения совместимости с ядром СУБД наилучшим будет являться среда Delphi.
    Среда Delphi относится к классу инструментов ускоренной разработки программ. Это ускорение достигается за счет двух характерных свойств Delphi: визуального конструирования форм и широкого использования библиотеки визуальных компонентов (Visual Component Library, VCL).
    Среди разработчиков программных продуктов под Windows в России особой популярностью пользуется среда быстрой разработки приложений Delphi. Эта популярность завоевана, прежде всего, ее простотой, легкостью в изучении и использовании.
    Среда Delphi позволяет разрабатывать как обычные приложения, так и приложе¬ния для работы с базами данных. Delphi предоставляет программисту широкие возможности создания интерфейса пользователя, а также большой набор стандартных компонентов, с помощью которых можно создавать приложения достаточно высокого уровня сложности.
    Среда Delphi обладает практически всеми возможностями современных систем управления базами данных. Она имеет встроенную поддержку языка структурированных запросов (SQL). С помощью Delphi можно разрабатывать как локальные, так и удаленные базы данных [8].
    Для разработки программы используется версия Delphi 7.
  1. ПРОЕКТНАЯ ЧАСТЬ
    2.1. Функционально-ориентированное и объектно-ориентированное проектирование информационной системы
    2.1.1. Проектирование модели IDEF0
    Для проектирования АРМ используют CASE-средства. Большинство CASE-технологий ориентировано на автоматизацию проектирования ПО и основано на методологии структурного или объектно-ориентированного проектирования [9].
    Здесь использованы CASE-средства:
  • Erwin – средство концептуального моделирования базы данных, использующее методологию IDEF;
  • BPWin – средство функционального моделирования, реализующее методологию IDEF.
    IDEF0 применяется как технология исследования и проектирования систем на логическом уровне. Она имеет графическую нотацию, состоящую из блоков и стрелок, IDEF0 представлена на рис.2.1.

Рис.2.1 – Диаграмма IDEF0
На вход информационной системы поступают данные о заявке, о клиентах, о товаре в заявке и информация о пользователе. Выходная информация – формирование общего отчета по всем заявкам и наряда на склад. Управляющей информацией являются средства ввода и обработки. Механизмом, который осуществляет работу информационной системы, является менеджер. Диаграмма декомпозиции 1-го уровня (рис.2.2) «АРМ Менеджера по продажам МК «Стрела»» представляется в 4 этапа: «Ввод заявок» (А1), «Ввод клиентов» (А2), «Ввод товаров» (А3), «Обработка результатов» (А4).
Результатом работы декомпозиции первого уровня является оптимальный вид системы.

Рис.2.2 – Диаграмма декомпозиции 1-го уровня
В связи с размером информационной системы 2-ом уровне декомпозиции представлено 4 диаграммы:
1) Ввод заявок (А1);
2) Ввод клиентов (А2) состоит из 3-х функциональных блоков:

  • Анализ клиента,
  • Ввод нового клиента или выбор существующего,
  • Добавление клиента к заявке.

Рис.2.3 – Диаграмма декомпозиции 2-го уровня

3) Ввод товаров (А3) состоит из 3-х функциональных блоков:

  • Анализ товара,
  • Ввод нового товара или выбор существующего,
  • Добавление товара к клиенту в заявке.

Рис.2.4 – Диаграмма декомпозиции 2-го уровня

4) Обработка результатов (А4).

В табл. 2.1 показаны основные элементы модели.
Таблица 2.1
Основные элементы модели
Список данных Перечень функций
Информация о пользователе;
Данные о заявке;
Данные о клиентах;
Данные о товаре;
Средства ввода заявок;
Средства обработки заявок;
Менеджер;
Общий отчет по заявкам;
Наряд на склад. А0.«АРМ Менеджера по продажам МК «Стрела»»
Информация о пользователе;
Данные о заявке;
Данные о клиентах;
Данные о товаре;
Средства ввода заявок;
Средства обработки заявок;
Менеджер;
Общий отчет по заявкам;
Наряд на склад;
Заявка;
Заявка с клиентом;
Заявка с клиентом и товаром. А1. Ввод заявок
А2. Ввод клиентов
А3. Ввод товара
А4. Обработка результатов
Данные о клиентах;
Заявка;
Средства ввода заявок;
Менеджер;
Заявка с клиентом;
Данный анализа;
Клиент. А21. Анализ клиента
А22. Ввод нового клиента или выбор существующего
А23. Добавление клиента в заявке
Заявка с клиентом;
Данные о товаре;
Средства ввода заявок;
Менеджер;
Заявка с клиентом и товаром;
Данный анализа;
Товар. А31. Анализ товара
А32. Ввод нового товара или выбор существующего
А33. Добавление товара к клиенту в заявке

В табл. 2.2 представлено описание основных функциональных блоков.
Таблица 2.2
Описание функциональных блоков
Наименование блока Описание решаемых задач
А1. Ввод заявок На этом этапе происходит ввод данных о торговом представителе, номер и дата заявки.
А2. Ввод клиентов Ввод данных о наименовании клиента, его адрес.
А3. Ввод товара Ввод наименования товара и его количества в заявке.
А4. Обработка результатов Создание необходимых общих или детальных отчетов по заявкам, создание наряда на склад.
А21. Анализ клиента Анализ клиента менеджером
А22. Ввод нового клиента или выбор существующего Данные анализа используются для выбора клиента
А23. Добавление клиента в заявке Прикрепление клиента к заявке и ввод в базу данных
А31. Анализ товара Анализ заказанного клиентом товара менеджером.
А32. Ввод нового товара или выбор существующего Данные анализа используются для выбора товара
А33. Добавление товара к клиенту в заявке Добавление товара к клиенту в заявке и ввод в базу данных
2.1.2. Модель объектно-ориентированной программной системы
Для описания функционального назначения системы построена диаграмма вариантов использования (use case diagram). Диаграмма вариантов использования является исходным концептуальным представлением или концептуальной моделью системы в процессе ее проектирования и разработки.
Разработка диаграммы вариантов использования преследует следующие цели:

  • определить общие границы и контекст моделируемой предметной области на начальных этапах проектирования системы;
  • сформулировать общие требования к функциональному поведению проектируемой системы;
  • разработать исходную концептуальную модель системы для ее последующей детализации в форме логических и физических моделей.
    Суть данной диаграммы состоит в следующем: проектируемая система представляется в форме так называемых вариантов использования, с которыми взаимодействуют некоторые внешние сущности или актеры. При этом актером или действующим лицом называется любой объект, субъект или система, взаимодействующая с моделируемой системой извне. В свою очередь вариант использования служит для описания сервисов, которые система предоставляет актеру.
    Построение диаграммы использования является первым этапом процесса объектно-ориентированного анализа и проектирования, цель которого – представить совокупность функциональных требований к поведению проектируемой системы. Разработанная диаграмма вариантов использования представлена на рис.2.5.
    Система имеет одного актера — Менеджера. Базовыми вариантами использования являются: «Ввод заявки», «Ввод клиента», «Выбор клиента из списка», «Добавление нового клиента», «Ввод товара в заявку», «Выбор товара из списка», «Добавление нового товара», «Формирование отчета», «Формирование наряда на склад».

Рис.2.5 – Диаграмма вариантов использования
Для уточнения и детализации последовательности действий, совершаемых системой при выполнении ее вариантов использования, рекомендуется дополнять этот тип диаграмм текстовыми сценариями (табл. 2.3).
Таблица 2.3
Главный раздел
Варианты использования Формирование базы заявок и выписка нарядов на склад
Актеры Менеджер
Цель Ведение учета заявок на товар от торговых представителей и своевременная отгрузка товара клиентам.
Краткое описание Менеджер принимает заявки от торговый представителей, в которых содержится наименование клиента, наименование и количество заказанного товара, формирует наряд на склад, по которому клиент получает продукцию.
Тип Базовый

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

  1. Менеджер запускает АРМ 2. Система предлагает ввести имя пользователя и пароль для авторизации
  2. Менеджер выбирает режим добавления заявки и вводит данные. 4. Система добавляет заявку в базу данных с указанием номера и текущей даты
  3. Менеджер выбирает режим добавления клиента и вводит данные.
    Исключение №1: отсутствие клиента в базе данных 6. Система добавляет клиента в базу данных с указанием адреса.
  4. Менеджер выбирает режим добавления товара и вводит данные
    1. Система добавляет наименование товара и его количество в базу данных.
  5. Менеджер создает отчет по заявкам.
    Исключение №2: отсутствие заявок в базе данных 10. Система выводит форму выбранного отчета
  6. Менеджер формирует наряд на склад 12. Система выводит форму наряда.

В третьем разделе сценария (табл. 2.5) описываются последовательности действий, которые должны выполняться при возникновении исключительных ситуаций (исключений).
Таблица 2.5
Раздел «Исключения»
Действия актеров Отклик системы
Исключение №1: отсутствие клиента в базе данных

  1. Менеджер водит данные о новом клиенте 14. Система добавляет данные о новом клиенте в базу данных
    Исключение №2: отсутствие заявок в базе данных
  2. Менеджер заносит все данные о заявке 16. Система добавляет данные о заявке в базу данных
    2.2. Используемые классификаторы и системы кодирования
    Системы классификации бывают двух видов:
  • иерархическая – последовательное деление множества объектов на подчиненные классификационные группировки. Такая классификация характеризуется количеством степеней классификации, глубиной, емкостью, гибкостью.
    Преимуществами такой классификации являются: логичность построения, четкость выделения признаков, большой информационный объем, традиционность и привычность использования.
    К недостаткам можно отнести жесткую структуру, необходимость иметь большие резервные емкости.
  • фасетная – параллельное разделение множества на независимые классификационные группировки.
    Преимущества: гибкость структуры, возможность включать новые и удалять старые фасеты. Благодаря этому плюсу, в данном проекте применена именно эта система классификации.
    Недостатки: недостаточно полное использование вследствие отсутствия множества возможных комбинаций фасет, непривычность и нетрадиционность использования при ручной обработке. Так как на программном уровне системе проще оперировать структурой фасетов, этот недостаток не является существенным.
    Система кодирования – совокупность методов и правил кодирования классификационных группировок и объектов заданной длины.
    Они бывают:
  • порядковые. Создание кода из чисел натурального ряда и его присвоение;
  • серийно-порядковые. Создание кода из чисел натурального ряда с закреплением отдельных серий и диапазонов за объектами классификации с одинаковыми признаками и его присвоение;
  • последовательные. Создание кода классификационной группировки с использованием кодов последовательного размещения группировок;
  • параллельные. Создание кода классификационной группировки или объекта классификации с использованием кодов независимых группировок, которые получены при фасетном методе. Именно такая система и подходит для данного проекта.
    Способы кодирования информации:
  • ручной;
  • печатный;
  • автоматизированный, на специальном оборудовании.
    Для решения данного комплекса задач применяются несколько кодовых обозначений объектов. Их структура может быть оформлена в виде таблицы (табл.2.6).
    Таблица 2.6
    Описание классификаторов
    Наименование кодируемого множества объектов Значность кода Система кодирования Система классификации Вид классификатора
    Код клиента 4 Порядковая Отсутствует Локальный
    Код продажи 4 Порядковая Отсутствует Локальный
    Код товара 4 Порядковая Отсутствует Локальный
    Код заявки 4 Порядковая Отсутствует Локальный
    Код пользователя 2 Порядковая Отсутствует Локальный
    Код клиента предназначен для однозначного определения клиента среди множества ему подобных. Для подобных целей служат и все остальные коды, определяя уникальность объектов в своей области применения.
    Так как данные классификаторы применяются исключительно для работы разрабатываемой системы и обеспечения удобной организации информации в базе данных для дальнейшей ее обработки и не представляют ценности для предприятия. Правила их кодирования полностью задаются программным комплексом (в том числе и СУБД) и не регулируются какими-либо нормативными актами.
    Так, к примеру, в таблице «Товары», полю «Код товара» первой записи присваивается значение 1, коду следующего товара — 2 и так далее по нарастающей. Последняя запись всегда имеет наибольшее значение. Так как код является первичным ключом в данной таблице, значение его не может повторяться и оно всегда уникально. Теоретически на предприятии могут быть 2 товара с абсолютно одинаковыми названиями. Однако они будут иметь различные порядковые номера, вследствие чего они будут числиться как 2 абсолютно разных товара, и целостность базы данных и ее непротиворечивость останутся в полном порядке. Аналогичным образом присваивается код и в остальных таблицах.
    2.3. Проектирование информационного обеспечения
    2.3.1. Информационный анализ предметной области и выделение информационных объектов
    На основе анализа предметной области и требований к разрабатываемой системе было принято решение об организации набора баз данных. Были выявлены входные документы или документы-источники для загрузки в базу данных (БД). Состав информационного обеспечения представлен в табл. 2.7.
    Таблица 2.7
    Состав информационного обеспечения
    Информационный объект (ИО) Обозначение ИО Семантика ИО
    Клиенты CLIENTS Содержит названия и адреса клиентов
    Продажи PROD Содержит список проданных товаров по каждой заявке
    Товар TOVAR Содержит список наименований товаров
    Пользователи USERS Содержит информацию о пользователях системы
    Заявки ZAYAV Содержит информацию о торговых представителях и датах заявок.
    Функциональные зависимости реквизитов представлены в табл. 2.8.
    Таблица 2.8
    Функциональные зависимости реквизитов
    Информационный объект Название реквизитов Имя реквизитов Функциональные зависимости
    Товар Код товара ID Название товара TYPE
    Клиенты Код клиента ID Код заявки ZAYAV_ID
    Клиент NAME
    Адрес клиента ADRES
    Продажи Код продажи ID Код вопроса CLIENT_ID
    Код товара TOVAR_ID
    Товар NAME
    Количество товара KOL
    Пользователи Код пользователя ID Логин LOGIN
    Пароль PASSWORD
    Права RIGHT
    Заявки Код заявки ID Имя торгового представителя NAME
    Дата DATA

Соответствие описательных и ключевых реквизитов представлено в табл. 2.9

Таблица 2.9
Соответствие описательных и ключевых реквизитов
Описательные (зависимые) реквизиты Ключевые реквизиты Признак ключа Имя ИО, включающего реквизит
TYPE ID Простой, универсальный (П., У) Товар (TOVAR)
ZAYAV_ID ID (П., У) Клиенты (CLIENTS)
NAME
ADRES
TOVAR_ID ID (П., У) Продажи (PROD)
CLIENT_ID
NAME
KOL
LOGIN ID П., У Пользователи (USERS)
PASSWORD
RIGHT
NAME ID П., У Заявки (ZAYAV)
DATA

Были проанализированы реальные отношения и функциональные связи между информационными объектами. Связи между информационными объектами приведены в табл. 2.10.
Таблица 2.10
Связи ИО
Главный ИО Подчиненный ИО Ключ связи Тип реального отношения
Заявки Клиенты ZAYAV_ID
Код заявки 1:М
Клиенты Продажи CLIENT_ID
Код клиента 1:М
Товар Продажи TOVAR_ID
Код товара 1:М
2.3.2. Построение логической модели данных
Различают следующие уровни логической модели, каждая из которых отличается глубиной представления информации о данных:
1) диаграмма сущность-связь (рис. 2.6) представляет собой модель данных верхнего уровня. Она включает сущности и взаимосвязи, отражающие основные бизнес-правила предметной области. Такая диаграмма не слишком детализирована и может включать связи много–ко-многим;
2) модель данных, основанная на ключах (рис. 2.7). Данная модель предполагает уже более подробное представление данных и включает описание всех сущностей и первичных ключей. Здесь уже не допускается наличие связи много-ко-многим, так как данная модель предназначена для представления структуры данных и ключей, которые соответствуют предметной области;
3) Полная атрибутивная модель. Это наиболее детальное представление данных. Данная модель представляет данные в третьей нормальной форме и включает все сущности, атрибуты и связи.

Рис. 2.6 – Диаграмма сущность-связь

Рис. 2.7 – Модель данных, основанная на ключах
2.3.3. Описание таблиц базы данных

Описание структуры реляционных таблиц представлено в табл. 2.11.
Таблица 2.11
Описание таблиц реляционной базы данных
Атрибут
Признак ключа
Формат поля

Обозначение Наименование Тип
Длина

Пользователи (USERS)
ID Код пользователя П.,У. счетчик Длинное целое
RIGHT Права числовой
LOGIN Логин символьный 15
PASSWORD Пароль символьный 15
Заявки(ZAYAV)
ID Код заявки П.,У. счетчик Длинное целое
NAME Торговый представитель символьный 255
DATA Дата Дата/время
Клиенты(CLIENTS)
ID Код клиента П.,У. счетчик Длинное целое
ZAYAV_ID Код заявки Числовой 255
NAME Название символьный 255
ADRES Адрес символьный 255
Товар (TOVAR)
ID Код товара П.,У. счетчик Длинное целое
TYPE Название символьный 255
Продажи (PROD)
TOVAR_ID Код товара П.,У. Числовой
CLIENT_ID Код клиента Числовой
NAME Товар Текстовый
KOL Количество Числовой
ID Код продажи счетчик Длинное целое
Исходя из функциональных зависимостей реквизитов, построим логическую модель БД (рис.2.8).

Рис.2.8 – Логическая модель базы данных

Построим физическую модель БД (рис.2.9).

Рис.2.9 – Физическая модель базы данных

2.4. Характеристика входной информации
Под входной информацией понимается вся информация, необходимая для решения задачи и расположенная на различных носителях: первичных документах, машинных носителях, в памяти персонального компьютера.
От рациональной организации входной информации торгового предприятия, способов сбора, регистрации, передачи, хранения и обработки информации, ее состава и своевременного получения зависят оперативность и эффективность управления торговыми процессами.
Входной информацией для разрабатываемой в дипломном проекте автоматизированной системы является:
1) Информация о товарах, производимых МК «Стрела» Сюда входит:

  • Наименование товара;
  • Тип продукции;
  • Отпускная цена продукции со склада;
  • Дополнительная информация о продукте.
    2) Информация о клиентах и торговых точках, с которыми работают торговые представители МК «Стрела». В нее входит:
  • Полное наименование клиента;
  • Адрес расположения торговой точки;
  • Информация о директоре предприятия;
  • Информация и телефон контактного лица, с которым ведутся переговоры по поставкам продукции.
    3) Заявки, принимаемые менеджером от торговых представителей МК «Стрела». Сюда входит:
  • ФИО торгового представителя;
  • Дата заявки;
  • Информация о клиенте, от которого получена заявка;
  • Наименование и количество заказанной продукции.
    2.5. Характеристика результатной информации
    2.5.1. Характеристика результатных документов.
    Результатной информацией в разработанной ИС являются:
    • Отчет по продажам по выбранным параметрам;
    • Наряд на склад на определенную дату..
    Отчет по продажам включает следующую информацию:
    ФИО торгового представителя, наименование клиента, список товаров с указанием количества и дата заявки. Информация сгруппирована по дате.
    Экранная форма отчета по продажам приведена на рисунке 2.10.

Рисунок 2.10. Экранная форма «Отчет по продажам»
2.5.2. Характеристика таблиц с результатной информацией
Для отчетов по заявкам и наряда на склад разработан следующий запрос:
SELECT zayav.ID, zayav.DATA, zayav.NAME, clients.name, prod.name, prod.kol
FROM (ZAYAV INNER JOIN clients on zayav.id = clients.ZAYAV_ID) INNER JOIN prod on clients.id = prod.CLIENT_ID
При печати к нему дополнительно может применяться фильтр по дате, торговому представителю или клиенту на выбор.
Для вывода на экран наряда на склад разработан следующий запрос:
SELECT tovar.type, prod.kol, tovar.id
FROM tovar INNER JOIN prod on tovar.id = prod.tovar_id
К запросу дополнительно применяется фильтр для выборки информации по дате.
2.6 Машинная реализация комплекса задач
2.6.1 Описание структуры диалога

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

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

  1. Файл проекта (ARM.dpr) Этот текстовый файл используется для хранения информации о формах и модулях. В нем содержатся операторы инициализации и запуска программы на выполнение.
  2. Файлы форм (Client, Main, Tovar, TP, User, Uzas1.dfm) Это двоичный или текстовый файл, который создается Delphi для хранения информации о формах
  3. Файлы модулей (Client, Main, Tovar, TP, User, Uzas1.pas) Каждой форме проекте, соответствует текстовый файл модуля, используемый для хранения кода. Т.к. форм в проекте 6, модулей соответственно тоже 6.
  4. Файл параметров проекта (ARM.dof) В этом файле хранятся установки параметров проекта.
  5. Файл ресурсов (ARM.res) Этот бинарный файл содержит используемую проектом пиктограмму и прочие ресурсы.
  6. Объектные файлы модулей (Client, Main, Tovar, TP, User, Uzas1.dcu) Это откомпилированный файл модулей (Client, Main, Tovar, TP, User, Uzas1.pas), которsq компонуется в окончательный исполняемый файл.
  7. Исполняемый файл (ARM.ехе) Это исполняемый файл приложения. Он является автономным исполняемым файлом, для которого больше ничего не требуется.
  8. Файл базы данных tests.mdb.
    Листинг программного кода приведен в приложении 1.

Взаимодействие пользователя с системой осуществляется в диалоговом режиме. Основным связующим элементом разрабатываемого АРМ является система меню (рис. 2.12). Разработанная система является меню — ориентированной.

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

Рис 2.13 Блок-схема основных модулей программы

Работа с программой начинается с запроса имени пользователя и пароля а затем активизации системы меню. Работа программы осуществляется по диалоговому и событийному режиму, при этом по диалогом понимается предоставление пользователю нескольких альтернатив и обработка его выбора. В диалоговую систему входят главное меню с соответствующими всплывающими подменю а также диалоговые окна. Под событиями понимаются процессы активизируемые пользователем (например — нажатие функциональных клавиш).
Модуль Главное меню предназначен для запуска основных процедур программы и завершения работы с программой.
Модуль работы со справочниками включает в себя пять справочников:
 Справочник Товары;
 Справочник Клиенты;
 Справочник Заявки.
Назначение данного модуля является поиск и просмотр информации по товарам, клиентам и заявкам.
Модуль Формирование входной информации предназначен для ввода первичных данных и просмотра ранее занесенных. Данный модуль реализует задачи ввода заявок с указанием клиентов и заказанной продукции с помощью специальных форм.
В компьютерных системах баз данных пользователи для ввода, просмотра и распечатки отчетов с информацией базы данных могут применять формы. Основные преимущества использования форм следующие:
 При вводе данных в поля формы, приложение может считывать словарь данных сервера и автоматически проверить допустимость данных в соответствии с правилами целостности.
 Поле ввода в форме может представлять список допустимых значений, из которых пользователи могут легко выбрать нужное.
 Область формы может выводить шаблон, соответствующий текущей выводимой в форме записи.
 Командные кнопки в форме могут выполнять действия, связанные с выводимой в форме текущей записью.
Модуль формирование отчетов и нарядов выполняет функции по формированию печатных форм. В модуле хранятся шаблоны для печати выходных документов, таких как отчет по продажам и наряд на склад.
Отчеты формируются, используя запросы, которые обрабатывают исходную информацию в соответствии с заданными параметрами пользователя.
Система построения запросов в Access не имеет себе равных среди СУБД массового использования. Практически все виды запросов, которые можно построить программно, в Access можно построить визуально. В Access предоставляется возможность создавать самые разнообразные запросы выборки, причем они могут модифицировать исходные данные. Также представлена развитая система фильтров. Фильтры – одна из наиболее сильных сторон Access. Фильтры строятся с помощью запросов или установкой критериев.
Компьютерные системы используют отчеты и запросы для считывания и представления данных таким образом, чтобы обеспечить полезность информации, содействовать принятию решений или поддерживать коммерческие приложения.

2.7. Разработка программного обеспечения системы
2.7.1. Проектирование экранных форм для ввода данных
Как уже упоминалось выше, разработка программного продукта будет производиться в визуальной среде разработки Delphi 7. Программирование в Delphi 7 состоит из проектирования пользовательского интерфейса с использованием визуальных средств, а также написание самого кода для обработки данных, формирования исходящей документации и увеличения возможностей интерфейса для работы пользователя [10].
В основе пользовательского интерфейса лежит традиционный оконный подход. Все клиентские компоненты содержат набор форм для взаимодействия с пользователем.
При проектировании интерфейса использовались следующие принципы:

  • создание интуитивно понятного интерфейса;
  • объединение элементов управления по их назначению в группы;
  • максимальное упрощение всех элементов управления;
  • удобное для работы расположение всех элементов;
  • предотвращение возможности совершения пользователем ошибки – элементы управления доступны для пользователя только при определенных условиях;
  • использование подсказок.
    2.7.2. Тестирование и оценка программного продукта
    Перед внедрением программного продукта в эксплуатацию необходимо провести его тестирование. Тестирование является одним из этапов жизненного цикла программного средства (ПС), направленным на повышение качественных характеристик. Применительно к ПС тестирование — процесс многократного выполнения программ.
    Целью тестирования является выявление как можно большего количества ошибок. Тестовый прогон считается удачным, если он позволяет выявить ошибки, и эффективным, если имеет высокую вероятность обнаружения большого количества ошибок [11].
    Существуют следующие методы тестирования ПС:
  • статический;
  • стохастический;
  • детерминированный.
    Статический метод наиболее формализованный и базируется на правилах структурного построения программ и обработки данных. Проверка степени выполнения этих правил проводится без изменения объектного кода программы путем формального анализа текста программы на языке программирования. В ходе тестирования данным методом были выявлены и устранены следующие ошибки:
  • неправильное написание операторов языка программирования;
  • отсутствие в отдельных командах знака «;»;
  • излишние, неиспользующиеся операторы.
    Стохастический метод предполагает в качестве исходных данных использование множества случайных величин с различными распределениями, так как невозможно перебрать все комбинации исходных данных. В результате тестирования данным методом были выявлены следующие ошибки:
  • несоответствие типов входных данных;
  • несоответствие данных диапазону допустимых значений;
  • отсутствие директории для записи или поиска файлов;
  • нарушение целостности базы данных.
    Для устранения этих ошибок использовался класс Exception, предназначенный для обработки исключительных ситуаций. Пользователю при возникновении исключительной ситуации выдается сообщение и предлагается выбрать один из вариантов дальнейшей работы с ПС.
    Детерминированный метод тестирования предполагает многократное вы¬полнение программы с использованием определенных, специальным образом подобранных тестовых наборов данных. При детерминированном тестировании контролируются каждая комбинация исходных наборов данных, соответствующие результаты, а также каждое утверждение в спецификации тестируемой программы.
    Для реализации данного метода использовался подход функционального тестирования или тестирование программы как «черного ящика». В данном случае предполагается, что логика программы неизвестна, а тестовые наборы подбираются на основании анализа функциональных входных спецификаций. К стратегии «черного ящика» относятся методы:
  • эквивалентного разбиения;
  • анализ граничных условий.
    В данном случае использовался метод эквивалентного разбиения. Данный метод основывается на выделении классов эквивалентности, которые представляют собой множество входных значений, каждое из которых имеет одинаковую вероятность обнаружения конкретного типа ошибки. Он состоит из следующих этапов:
  • выделение классов эквивалентности;
  • построение тестовых наборов.
    На первом этапе были выделены классы эквивалентности, представленные в табл. 2.11.

Таблица 2.11
Выделенные классы эквивалентности
Правильный класс
эквивалентности Неправильный класс
эквивалентности
Фамилия торгового представителя не содержит цифр. Фамилия торгового представителя содержит цифры
Графа «название клиента» заполнена Графа «название клиента» не заполнена

На втором этапе на основе выделенных классов эквивалентности были построены тестовые наборы, представленные в табл. 2.12.
Таблица 2.12
Тестовые наборы
Показатель Входные данные для тестирования Предполагаемый результат Результат
Тестирования
Фамилия торгового представителя Иванов
Иванов
+

+
+
+

Попов123
Ошибка ввода    -
123
Ошибка ввода    -

Графа «название клиента» Не заполнена Сообщение «Не введено название клиента» —
Заполнена Тест заносится в БД +

В результате тестового прогона выявленные ошибки были устранены.

2.8. Описание контрольного примера реализации проекта.

При поступлении заявки от торгового представителя менеджер визуально проверяет правильность заполнения заявки, а затем вносит данные в АРМ.
При запуске АРМ появляется окно авторизации (рисунок 2.14). Менеджер имеет свой логин и пароль.

Рис 2.14. — Окно авторизации
В случае успешной авторизации открывается главное окно программы АРМ менеджера (рис 2.15.). Если логин и пароль неверные, то пользователь видит на своем экране сообщение о неверном логине или пароле (рис. 2.16.)

Рис. 2.15. – Главное окно АРМ Менеджера

Рис. 2.16. – Сообщение о неверном вводе

В главном меню программы менеджер может выполнять все операции, предусмотренные в АРМ менеджера по продажам. В начале работы менеджер должен занести новую заявку в базу данных. Для этого необходимо выбрать меню «Заявки» — «Добавить» или на главной панели нажать кнопку «Заявки», а затем внизу кнопку «Добавить» (рис. 2.17).

Рис. 2.17. – Меню «Заявки»
При нажатии на кнопку «Добавить» появляется форма добавления новой заявки (рис. 2.18).

Рис. 2.18. – Форма добавления заявки
При добавлении заявки менеджер вводит имя торгового представителя, от которого поступила заявка и нажимает кнопку ОК. В результате данной операции заявке автоматически присваивается порядковый номер и дата, которая равна дате занесения заявки в базу данных.
При необходимости менеджер может изменить заявку, нажав на кнопку «Изменить» (рис 2.19) или удалить заявку полностью, нажав «Удалить» (рис. 2.20). Необходимо обратить внимание на то, что при изменении заявки менеджер может изменить только имя торгового представителя, номер и дату заявки он изменить не может.

Рис. 2.19. – Изменение заявки

Рис. 2.20. – Удаление заявки
Далее менеджер переходит к работе с клиентами. Для перехода к экранной форме необходимо нажать кнопку «Клиенты» Менеджер также может управлять работой экранной формы с помощью кнопок главного меню (рис. 2.21).

Рис. 2.21. – Экранная форма «Клиенты»
К каждой заявке менеджер должен добавить клиентов. Для этого ему необходимо нажать кнопку «Добавить» или выбрать пункт меню «Клиенты» — «Добавить». После этого на экран выводится форма добавления клиента (рис .2.22).

Рис. 2.22. – Форма добавления клиента
При добавлении клиента менеджеру предоставляется на выбор два варианта действия: выбрать клиента из списка или создать нового. Для выбора уже имеющегося клиента менеджер должен выбрать название из выпадающего списка и выбрать соответствующий адрес клиента из другого списка. После нажатия кнопки «ОК» клиент будет добавлен к заявке. Для создания нового клиента менеджер должен вручную заполнить поля «Новый клиент» и «Адрес» после чего нажать кнопку «Добавить». После этого новый клиент будет добавлен к заявке.
Менеджер также может изменить информацию о клиенте в заявке или удалить клиента из заявки, нажав кнопки «Изменить» и «Удалить» соответственно. При этом на экран будут выведены формы изменения (рис. 2.23) и удаления (рис. 2.24) клиента.

Рис. 2.23. – Форма изменения клиента

Рис. 2.24. -Форма удаления клиента
После добавления клиента к заявке менеджер переходит к добавлению товара в заявку. Для перехода к экранной форме необходимо нажать кнопку «Товар» Менеджер также может управлять работой экранной формы с помощью кнопок главного меню (рис. 2.25).

Рис. 2.25. – Экранная форма «Товары»
Далее менеджер добавляет товар к выбранному клиенту. Для этого необходимо нажать кнопку «Добавить» или выбрать пункт меню «Товар» — «Добавить». После этого на экран выводится форма добавления товара (рис. 2.26).

Рис. 2.26. – Форма добавления товара
С помощью данной формы менеджер выбирает название товара из выпадающего списка, указывает его количество и нажимает кнопку «Сформировать». Также с помощью данной формы менеджер может добавить новое наименование продукции. Для этого он должен ввести наименование в поле «Новый вид продукции» и нажать кнопку «Добавить». После нажатия кнопки «Добавить» в выпадающем списке «Товар» появляется новое наименование товара.
Также с помощью кнопки «Изменить» менеджер может при необходимости изменить наименование товара и его количество в заявке (рис. 2.27).

Рис. 2.27. – Форма изменения товара
Менеджер имеет возможность удалить выбранный товар из заявки. Для этого ему необходимо нажать на кнопку «Удалить» или выбрать соответствующий пункт главного меню. При этом на экран будет выведена форма удаления товара (рис. 2.28).

Рис. 2.28. –Форма удаления товара
На этом работа с формированием заявки заканчивается. При необходимости менеджер может просмотреть все заявки в базе, внести необходимые изменения и дополнения.
После внесения всех заявок в базу данный менеджер приступает к работе с отчетами и нарядами на склад. Для перехода к экранной форме «Отчеты» (рис. 2.29) менеджеру необходимо нажать кнопу «Отчеты» или выбрать соответствующий пункт главного меню.

Рис. 2.29. – Экранная форма «Отчеты»
При переходе на форму «Отчеты» на экране показаны все заявки, имеющиеся в базе. Для того чтобы просмотреть отчеты по выбранной дате, клиенту или торговому представителю необходимо выбрать в левой части формы из выпадающего списка нужный фильтр (рис. 2.30). После выбора фильтра на форме появится поле, в которое нужно ввести данные, по которым осуществляется отбор и нажать кнопку «Показать»

Рис. 2.30. – Выбор фильтра
Кроме просмотра отчета на экране менеджер имеет возможность распечатать отчет. Для этого ему необходимо нажать на экранную кнопку «Печать» или выбрать соответствующий пункт главного меню «Отчеты» — «Печать». После нажатия кнопки на экран будет выведено окно с выбором параметров печати (рис. 2.31).

Рис. 2.31. – Параметры печати
Для выписки наряда на склад менеджер переходит на экранную форму «Наряды» путем нажатия кнопки на экране или выбора соответствующего пункта главного меню (рис. 2.32).

Рис. 2.32. – Экранная форма «Наряды»
При переходе на форму «Наряды» на экране показаны наряды по всем датам, имеющимся в базе. Для выписки наряда на текущую дату необходимо выбрать её из выпадающего списка внизу формы и нажать кнопку «Печать» или выбрать соответствующий пункт главного меню.
Последний пункт главного меню «Справка» содержит подменю «О программе», осуществляющее вывод на экран формы содержащей информацию о разработчике данного программного продукта (рис. 2.33).

Рис. 2.33. – Экранная форма «О программе»

  1. Обоснование экономической эффективности проекта

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

3.1.1. Определение трудоемкости

Затраты на разработку распределяются между двумя видами работ: научно-исследовательскими и опытно-конструкторскими. В рамках данного проекта предусматривается расчет затрат на выполнение только научно-исследовательских работ (НИР). При определении трудоемкости НИР применяется метод укрупненного членения НИР на стадии и этапы.
Программное изделие планируется разрабатывать с помощью системы управления базами данных Access 2000, ориентированной на графический интерфейс разработки программ.
3.1.2. Структура затрат на разработку программного изделия (относительная трудоемкость стадий)

Затраты труда на разработку типичного программного изделия (ПИ) принимаются в соответствии с исходными данными таблицы 3.1.

Таблица 3.1
Структура затрат на разработку
№ п/п Наименование
стадии Содержание стадии Трудоемкость, %

  1. Подготовительная стадия Изучение научно-технической литературы.
    Согласование и утверждение тех. задания и календарного плана проведения работ. 13
  2. Теоретическая разработка Технико-экономическое обоснование и описание задач для алгоритмизации. 10
  3. Алгоритмизация и программирование Разработка алгоритмов, блок-схем, разработка форм, запросов, макросов и модулей на алгоритмическом языке, их отладка на ЭВМ. 65
  4. Обобщение и выводы Обобщение результатов работы, выводы 5
  5. Техническая отчетность Подготовка отчетной документации по выполненной работе 5
  6. Заключительная стадия Оформление и утверждение результатов 2

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

При применении процедурных языков расчет количества условных команд выполняется по формуле
Q = q * (1 + P1 + P2 + …. + Pn),
где q – предполагаемое число команд программы, определяемое в ориентации на ассемблерную обработку.
q = q0 число команд ассемблера (от 2 до 10 команд)
q = 100 * 20 = 2000 (усл. ком. )
Kсл — коэффициент сложности программы (1.0 – 1.5)
P – коэффициент коррекции программы
n — количество коррекций программы в ходе разработки.
Каждый модуль программы потребует следующих доработок:
15% серьезной доработки изменений текста программ;
2% уточняющей отладочной доработки исходного текста.
Коэффициент типизации (повторение одинаковых или очень близких фрагментов в различных программных модулях) – 25%.
Соответственно разработка программы составляет 75%.
Таки образом количество условных команд Q разрабатываемого ПИ составляет:
Q = 2000 * 1.2 * 0.75 * (1 + 0.15 + 0.02) = 2106 (усл. команд)

3.2. Расчет трудоемкости разработки программного изделия по стадиям
Расчет трудоемкости стадии алгоритмизации и программирования
Работы, выполняемые на третьей стадии разработки – алгоритмизации и программирования, являются наиболее сложными и наиболее длительными.
Трудоемкость работ на данной (третьей) стадии вычисляются по формуле:
TЗ = tИ+ tА + tБС + tП + tОТ + tЭВМ + tД ,
где: tИ — затраты труда на изучение (и описание) задачи;
tА — затраты труда на изучение задачи в целом и на разработку алгоритмов;
tБС — затраты труда на разработку блок-схем;
tП — затраты труда на программирование;
tОТ — затраты труда на отладку программы;
tЭВМ – время машинного счета на ПЭВМ;
tД- затраты на оформление документации.

Затраты труда на изучение задачи — tИ определяются по формуле:
tИ = Q/(В 31* ККВ) * ККАЧ ,
где: Q — общее количество команд в программном комплексе (2106 усл. команд);
В 31 – производительность исполнителя на первом этапе третьей стадии (55 ком/час);
ККВ — коэффициент, отражающий квалификацию специалиста (для стажа менее 2 лет, коэффициент равен 0.8);
ККАЧ — коэффициент, учитывающий требуемое качество описания задачи (ККАЧ = 1.1).
tИ = 2106/(550.8)1.1 = 53 (ком/час)
Остальные величины трудоемкости на различных этапах работы определяются по той же формуле с учетом исходных данных, получаемых в ходе анализа системы.
Затраты труда на изучение задачи в целом и разработку алгоритмов составят:
tИ = Q/(В 32* ККВ)= 2106/(200.8) = 132 (ком/час) где В32 — производительность исполнителя на втором этапе третьей стадии (20 ком/час); Затраты на разработку блок-схем ПИ определяются: tБС = Q/(В 33 ККВ)= 2106/(220.8) = 120 (ком/час) где В33 — производительность исполнителя на третьем этапе третьей стадии (22 ком/час); Затраты труда на этапе программирования составляют: tП = Q/(В 34 ККВ) = 2106/(250.8) = 105 (ком/час) где В34 — производительность на четвертом этапе третьей стадии (25 ком/час); Затраты труда на отладку программы определяются: tОТ = Q/(В 35 ККВ) = 2106/(100.8) = 263 (ком/час) где В35 — производительность на пятом этапе третьей стадии (10 ком/час); Затраты на оформление документов составляют: tП = Q/(В 36 ККВ) = 2106/(24*0.8) = 110 (ком/час)
где В36 — производительность на шестом этапе третьей стадии (24 ком/час);
Время машинного счета на ЭВМ определяется:
tЭВМ = В37 = 10 (чел/час)
где В37 — время машинного счета на ЭВМ – 10 чел/час.
Таким образом трудоемкость работ на третьей стадии составит:
TЗ = 53 + 132 + +120 +105 +263 + 10 + 110 = 793 (чел/час)
Или, в человеко-днях, на алгоритмизацию и программирование буде затрачено:
TЗД = 793/ 8 = 99 (чел. дн
Расчет трудоемкости остальных стадий
В соответствии с исходными данными таблицы 3.1. можно определить трудоемкость 1, 2, 4, 5, 6 стадий разработки программного изделия:
Ti = TЗ * (Ti%/ TЗ %) , где:
Ti – трудоемкость каждой стадии.
T1 = 793(13/65) = 159 (чел.час) = 159 : 8 = 20 (чел. дн) T2 = 793(10/65) = 122 (чел.час) = 122 : 8 = 15 (чел. дн)
T4 = 793(5/65) = 61 (чел.час) = 61 : 8 = 8 (чел. дн) T5 = 793(5/65) = 61 (чел.час) = 61 : 8 = 8 (чел. дн)
T6 = 793*(2/65) = 24 (чел.час) = 24 : 8 = 3 (чел. дн)

Расчет трудоемкости разработки в целом
T = T1 + T2 + T3 + T4 + T5 + T6 = 159 + 122 + 793 + 61 + 61 + 24 = 1220 (чел. час) = 153 (чел.дн)
Выполненная проверка свидетельствует о правильности полученных значений:
T = 793*(100/65) = 1220 (чел.час) = 1220 : 8 = 153 (чел. дн)
Построение календарного плана графика
С учетом функциональных обязанностей и знаний специалистов – исполнителей на конкретной стадии и характера работ, предусматриваемых этой стадией (табл. 3.1), распределение нагрузки на специалистов приведено в таблице 3.2.
На 1, 2, 4 и 6 стадиях применяется труд ведущего инженера и инженера программиста, на 3 и 5 стадиях – только инженера – программиста.

Таблица 3.1
Распределение трудоемкости работ между исполнителями на различных стадиях

п/п Наименование стадий Трудоемкость, чел.час Занятые
исполнители Доля выполненных работ, % Трудоемкость по исполнителям, чел.час
1 Подготовительная стадия 183 Ведущий инженер
Инженер-программист 67
33 123
60
2 Теоретическая разработка 146 Ведущий инженер
Инженер-программист 33
67 48
98
3 Алгоритмизация и программирован. 793 Инженер-программист 100 793
4 Обобщение и выводы 37 Ведущий инженер
Инженер-программист 33
67 12
25
5 Техническая отчетность 49 Инженер-программист 100 49
6 Заключительная стадия 12 Ведущий инженер
Инженер-программист 60
40 7
5

При определении продолжительности каждой из стадий учитывается следующее, чтобы данная стадия не оказалась меньшей, чем трудоемкость, приходящаяся на какого-либо исполнителя. Расчет календарной продолжительности стадии определяется по формуле, предполагающей равную степень загруженности Rj исполнителей на j –й стадии.
TiК = Ti(1 + р) / (Rj * f *tg) , где:
Ti – общая трудоемкость j стадии;
p — доля дополнительных работ (в нашем случае равна 0.2);
tg – количество часов в рабочем дне (8);
f – переводной коэффициент, обеспечивающий переход от человеко-дней с календарным интервалом
f = (12 * 22) / 365 = 0.73 раб.дн/кал.дн
Эта формула модифицируется в формулу:

TiК = maxi Ti * Gij *(1 + р) / (f * tg) , где:

Gij – относительная доля работ, выполняемых j-м исполнителем на i-й стадии. В результате получим следующие значения:
T1К = 123 * 1.2 / (0.73 * 8) = 25 (кал. дн)
T2К= 98 * 1.2 / (0.73 * 8) = 20 (кал. дн)
T3К= 793 * 1.2 / (0.73 * 8) = 163 (кал. дн)
T4К= 25 * 1.2 / (0.73 * 8) = 6 (кал. дн)
T5К= 49 * 1.2 / (0.73 * 8) = 10 (кал. дн)
T6К= 7 * 1.2 / (0.73 * 8) = 1 (кал. дн)
Таким образом, общая продолжительность разработки составит 224 календарных дня.

3.3. Расходы на разработку
Основными статьями затрат, которые должны быть предусмотрены сметой являются: заработная плата, накладные расходы, затраты на материалы.
1) Основная заработная плата
В разработке ПИ принимают участие ведущий инженер и инженер-программист. Ведущий инженер несет ответственность за автоматизацию предприятия, а инженер-программист осуществляет работу по алгоритмизации и программированию автоматизированной системы.
Средняя заработная плата ведущего инженера – 10000 руб.
Средняя заработная плата инженера- программиста – 8000 руб.
Среднедневной заработок определяется по формуле:
ЗСД = ЗО / Ф, где
ЗО – оклад в руб.
Ф – месячный фонд рабочего времени в днях (21.8 – среднее значение)
ЗСД вед. инженера = 10000 / 21.8 = 459 руб.
ЗСД инж.-прогр. = 8000 / 21.8 = 367 руб.
Общая затрата на зарплату отдельного работника определяется по формуле:
З = ЗСД * Т, где
Т – время, затрачиваемое на разработку конкретным специалистом –участником (раб.дн).
Как следует из таблицы 3.2:
Твед.инжен.= (123+48+12+7)/8 = 190/8 = 24 (раб. дн)
Тинж.прогр.= (60+98+793+25+49+5)/8 = 1030/8 = 129 (раб. дн)
Итого, затраты, связанные с зарплатой составят:
Звед.инжен.= 459 * 24 = 11016 руб
Зинж.прогр.= 367 * 129 = 47343 руб
Зосн..= 11016 + 47343 = 58359руб
2) Определение величины накладных расходов
Величина накладных расходов при разработке ПИ составляет 120 % от основной заработной платы – ФОТ. Следовательно Lнакл. определятся:
Lнакл. = Зосн * 1.2 = 58359 * 1,2 = 70031 руб.
Для проектирования и отладки программ используется IBM совместимый компьютер. Заработная плата обслуживающего персонала (одного наладчика) составляет 2000 руб. в месяц. Один наладчик обслуживает 5 ЭВМ с периферией. Следовательно, затраты, связанные с зарплатой при обслуживании на одну ПЭВМ, в месяц составляют — 2000/5 = 400 руб. В год соответственно эта величина составит 4800 руб.
В накладные расходы необходимо также включить амортизацию основных средств. Приняв амортизационные отчисления равным 20% от 20000 руб. (стоимость ПЭВМ с периферией), получаем, что расходы связанные с амортизацией в течении года составят:
А = 0.2 * 20 000 = 4000 (руб.)
Затраты на электроэнергию в среднем в год составляют  400 руб. По отношению к амортизации это в десять раз меньше, а оплата занимаемых площадей, их освещение, отопление и обслуживание учтены как общехозяйственные расходы, входящие в смету как накладные расходы. Стоимость расходов на материалы при эксплуатации ПЭВМ учитываются в соответствующей статье сметы.
Таким образом, себестоимость часа машинного времени составляет:
С ПЭВМ = (ЗОП + А)/ ФД , где
ФД – годовой фонд машинного времени (час)
ФД = количество месяцев в году * количество рабочих дней в месяце* количество рабочих часов в день.
ФД = 12 * 21.8 * 8 = 2093 (час)
С ПЭВМ = (4800 + 4000) / 2093 = 4,2 (руб./час)
Для разработки программного изделия необходимо заказать 349 часов машинного времени (табл. 3.3). Затраты на него составляют:
Lпэвм. = 4,2 * 349 = 1466 (руб)

Таблица 3.2
Продолжительность работ на ПЭВМ на различных стадиях разработки
Стадия, этап Трудоемкость, чел.час Доля работ, выполн. на компьют., % Необходимое машинное время, час
Подготовительная стадия 183 20 37
Теоретическая разработка 146 10 15
Алгоритмизация и программирование
изучение и описание задачи
разработка алгоритмов
разработка блок-схем
программирование
отладка
машинный счет
оформление документов
53
132
120
105
263
12
110

10

10
50
67
100
20

5

12
52
176
10
22
Обобщение и выводы 37 10 4
Техническая отчетность 49 20 10
Заключительная стадия 12 50 6
Всего: х х 349

3) Определение расходов на материалы
При разработке программного изделия предполагается использовать:
750 листов бумаги для принтера формата А4 (1,5 пачки) стоимостью 100 руб. за пачку, 100 * 2 = 200 руб.;
один картридж для принтера марки HP1100 (черно-белый) стоимостью 1500 руб.;
10 CD-дисков стоимостью 10 руб. штука, 10 * 10 = 100 руб.
Общая сумма расходов на материалы составит:
Lмат. = 200 + 1500 + 100 = 1800 руб.

4) Общая сметная сумма затрат
Общие затраты на разработку программного комплекса составляют:
Lсм. = Lзп + Lнак. + Lмат. + Lпэвм
С учетом выполненных ранее расчетов, общая сметная сумма затрат составит — Lсм. = 58539 +70031 + 1800 + 1466 = 131836 руб.
3.4. Экономический эффект
Расчет годового экономического эффекта от использования ПИ как элемента новой технологии проектирования и внедрения вычислительного определяется по формуле:
Э = (З1 – З2) * А2где
Э – годовой экономический эффект от использования ПИ в вычислительных процессах, руб.;
З1 , З2 – приведенные затраты на единицу работ, выполненных с помощью нового ПИ и без него, руб.;
А2 – годовой объем работ выполняемых с помощью нового ПИ в расчетном году, натур. ед.
Приведенные затраты (З2) на единицу работы рассчитываются по формулам:
З1 = С1 + Ен * К1
З2 = С2 + Ен * К2

где С1, С2 – себестоимость единицы работ производимых без использования ПИ и с помощью него, руб.;
К1, К2 капитальные вложения, связанные с использованием ПИ (К2) и без его использования (К1), руб.;
Ен– нормативный коэффициент экономической эффективности капитальных вложений, равный 0,15.
Себестоимость единицы работ (С1, С2) определяется по формуле:
С1 = Зар. плата инспектора / (N0* 21.8)
С2 = Зар. плата инспектора / (N1 * 21.8)
где Зар. плата инспектора — 8000 руб. в месяц
N0 – количество документов, обрабатываемых без компьютера в день (до 10);
N1 – количество документов, обрабатываемых с применением ПИ в день (до 50);
Следовательно себестоимость составит
С1 = 8000 / (10 * 21.8) = 8000 / 218 = 37 (руб)
С2 = 8000/ (50 * 21.8) = 8000 /1090 = 7,3 (руб)
Удельные капитальные вложения не связанные с использованием ПИ рассчитывается по формуле:
К1 = капитальные затраты / (N0* 21.8 * 12)
В свою очередь в капитальные затраты отнесены: электроэнергия 400 руб. в месяц 12 = 4 800, что составляет в общей сумме 4800 руб. Подставив значения в формулу получим: К1 = 4800 / (721.812) = 4800 / 1831 = 3 руб. Удельные капиталовложения, связанные с использованием ПИ равны: = LСМ / (N1 21.8 * 12)= 30322/(50 * 21.8 * 12)= 59994/13080 = 5 руб.
Следовательно, приведенные затраты на единицу работ равны:
З1 = 37 + 0.15 * 3 = 38 руб
З2 = 7,3 + 0.15 * 5 = 8 руб
Для расчета годового объема выполненных работ с помощью ПИ необходимо использовать формулу:
А2 = N1 * 21.8 * 12 = 13080 (документов)
Зная все необходимые данные можно рассчитать годовой экономический эффект от использования ПИ:
Э = (38 – 8) * 13080 = 392400 руб.
Полученная величина свидетельствует об эффективности внедрения ПЭВМ на предприятии, так как за счет увеличения количества документов, обрабатываемых с помощью ЭВМ уменьшаются затраты выполненные на единицу работ, следовательно экономический эффект увеличивается. А значит внедрение вычислительной техники на предприятии становится выгодным.
Срок окупаемости капитальных затрат:
Тр = LСМ / Э = 131836 /392400 = 0,33 года
Следователь в течении 4 месяцев с момента начала эксплуатации АРМ окупится затраты на его разработку. Это значительно небольшой срок по сравнению с эффектом, который мы получим при внедрении вычислительной техники.

Заключение

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

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

1) Некрасов, Е. Ждут перемен / Е. Некрасов // Аргументы и факты Вологда.- 2007.- 15 марта. — С. 21.
2) Понамарев, В. Базы данных Delphi7. Самоучитель/ В.Понамарев. – СПб.: Питер, 2003. – 224с.
3) Хомоненко, А.Д. Базы данных: учебник для высших учебных заведений / А.Д. Хомоненко, В.М. Цыганков, М.Г. Мальцев. – СПб.: КОРОНА принт, 2000.- 416с.
4) Бобровский, С.И. Delphi 7: Учебный курс/ С.И. Бобровский – СПб.: Питер, 2003. – 736 с.
5) Хоменко, А. Delphi 7/ А. Хоменко. – СПб.: БХВ-Петербург, 2004. – 1200 с
6) Вендров, А.М. CASE-технологии. Современные методы и средства проектирования информационных систем /А.М. Вендров. – М.: Финансы и статистика.1998.–176с.
7) Архангельский, А.Я. Приемы программирования в Delphi. Издание второе / А.Я.Архангельский – М.: ООО Бином- Пресс, 2004. – 846 с., ил.
8) Канер, С. Тестирование программного обеспечения /С. Канер. – М.:2000г.–254с.

Приложения

Оцените статью
Поделиться с друзьями
BazaDiplomov