Автоматизированная система учета расчетов с покупателями и поставщиками на предприятии на основе данных ООО "Дагестан-Парус"

Достоинствами реляционной модели являются:

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

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

Недостатки данной модели:

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

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

Ш наибольшая полнота понимания и использования пользователями;

Ш возможность реализации непроцедурных языков запросов;

Ш более высокий уровень независимости данных.

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

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

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

Ш ясная взаимосвязь атрибутов из различных отношений и файлов;

Ш независимость данных от прикладной программы;

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

Обоснование выбора формы хранения данных в памяти ЭВМ.

Разработанная система с использованием базы данных, позволяет:

Ш централизовать информационный фонд системы;

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

Ш рассчитывать показатели.

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

Определение целесообразности использования интегрированной БД.

Отметим некоторые достоинства интеграции данных.

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

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

Ш благодаря сокращению или устранению дублирования данных повышается уровень их достоверности, существенно проще и эффективнее становятся процедуры обновления.

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

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

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

1.7 Обоснование проектных решений по программному обеспечению (внутри машинной технологии) комплекса задач

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

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

Ш удобный пользовательский интерфейс;

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

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

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

Ш анализ информации.

Обоснование выбора режима обработки данных.

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

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

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

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

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

Ш предложение для выбора (меню функций, меню параметров, вопросы требующие ответа “да/нет”).

Среда выполнения программы

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

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

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

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

Ш наличие средств проектирования пользовательского интерфейса;

Ш скорость выполнения программы;

Ш надежность работы программы и защищенность от программных сбоев[1].

В качестве среды выполнения программы выбрана операционная система Windows XP.

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

Обоснование выбора СУБД и языка программирования для реализации проекта.

Для разработки автоматизированной системы учета расчетов с покупателями и поставщиками использовалась шестая версия системы объектно-ориентированного программирования системы Borland C++ Builder 6 .

C++Builder 6 включает обширный набор средств, которые повышают производительность труда программистов и сокращают продолжительность цикла разработки. Многофункциональная интегрированная среда разработки C++Builder 6 включает компилятор, удовлетворяющий стандарта ANSI/ISO, встроенный дизайнер форм, богатый набор средств для работы с компонентами, инструмент Object Inspector, менеджер проектов и отладчик.

C++Builder 6 - это единственный компилятор C++, органично объединяющий среду разработки и приложения COM и CORBA для создания сложных систем на базе распределенных объектов. C++Builder 6 предоставляет удобные средства разработки и отладки серверных COM- и CORBA-компонентов на языке C++, которые могут взаимодействовать с различными объектами и клиентскими приложениями Windows, UNIX и Java.

Продукт C++Builder 6 объединяет высокоэффективную среду разработки на C++ и Borland InterBase, мощную кросс-платформенную реляционную базу данных класса предприятия, удовлетворяющую стандарту SQL, которая отличается простотой использования и низкой стоимостью обслуживания.

C++Builder 6 поддерживает основные принципы объектно-ориентированного программирования - инкапсуляцию, полиморфизм и множественное наследование, а также нововведенные спецификации и ключевые слова в стандарте языка C++.

C++Builder 6 обеспечивает высокое быстродействие при компиляции и сборке 32-разрядных приложений для современных операционных систем Windows, включая OLE взаимодействие клиент-сервер[4].

Основные возможности:

Ш поддержка языков программирования Delphi для Win32, Delphi для .NET, C++ и C в единой среде;

Ш ECO III обеспечит создание надежных корпоративных приложений (object relational mapping, transparent object persistence, поддержка исполняемых диаграмм состояний),

Ш обновленная библиотека визуальных компонент (VCL) позволит ускорить и упростить разработку графического пользовательского интерфейса (GUI), автоматически располагая компоненты в соответствии с настраиваемыми правилами,

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

Ш благодаря тесной интеграции с решениями Borland управления жизненным циклом ПО реализуется возможность:

Ш управления требованиями (Borland CaliberRM);

Ш управления конфигурациями и изменениями (Borland StarTeam);

Ш визуального моделирования с использованием технологии LiveSource (Borland Together)[9].

Для установки системы необходим ПК в следующей конфигурации:

Ш Операционная система: Windows XP Professional (5.1, Build 2600) Service Pack 3 (2600.xpsp.080413-2111);

Ш Процессор: Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz (2 CPUs);

Ш ОЗУ: DDR3 DIMM 2046MB RAM;

Ш Монитор: LCD 20 PHILIPS (1600x1200);

Ш Видео карта: NVIDIA GeForce 9800 GT 512MB,256 bit,DDR3;

Ш Жесткий диск: HDD IDE 1 TBIT: LaCie Big Disk Extreme 1 TB и Maxtor OneTouch III Turbo 1 TB;

Ш DVD RW AD-7200S;

Ш Клавиатура: Genius;

Ш Мышь: Genius.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.1 Информационное обеспечение комплекса задач

2.1.1 Инфологическая или информационная модель и ее описание

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

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

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

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

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

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

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

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

Рис. 2.1. Взаимосвязь этапов проектирования БД

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

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

Требования к инфологической модели:

Ш адекватное отображение предметной области;

Ш непротиворечивость;

Ш должна отражать взгляды и потребности всех пользователей системы;

Ш однозначная трактовка моделей;

Ш модель должна быть конечной;

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

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

Ш должна быть легко реализуемой на ЭВМ;

Ш должна быть независимой от оборудования и языков организации базы данных на ЭВМ.

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

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

Объекты могут быть двух типов:

Ш реальные объекты;

Ш абстрактные объекты.

Каждому объекту в классе объектов присваивается свое уникальное имя (идентификатор). Каждому классу объектов в модели присваивается уникальное имя.

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

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

Свойства могут быть:

Ш статистическими (постоянные, не изменяющиеся с течением времени);

Ш динамическими (изменяющиеся с течением времени).

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

Такие свойства называются условными.

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

Различают следующие виды связей:

Ш один к одному;

Ш один ко многим;

Ш многие к одному;

Ш многие ко многим.

Инфологическая модель отображает классы объектов и связи между ними.

Для указания этой ситуации существует понятие класс принадлежности.

Инфологическая модель комплекса задач, рассматриваемого в данном дипломном проекте, представлена на рис. 2.2.



Рис. 2.2. Инфологическая модель данных

2.1.2 Характеристика входной информации

Описание входящих документов

Для выполнения автоматизации расчетов с поставщиками и покупателями на предприятиях ООО «Дагестан - Парус» используются данные следующих форм:

А) Счет-фактура при покупке и реализации товаров со следующими характеристиками:

- № счет - фактуры;

- дата составления счета;

- продавец;

- адрес продавца;

- ИНН/КПП продавца;

- грузоотправитель и его адрес;

- грузополучатель и его адрес;

- платежно-расчетный документ;

- покупатель;

- адрес покупателя;

- ИНН/КПП покупателя;

- наименования товара;

- единица измерения;

- количество товаров;

- цена за единицу измерения;

-стоимость товара без учета налога;

- налоговая ставка;

- сумма налога по товару;

-стоимость товара с учетом налога;

- всего к оплате;

- сумма налога;

- ФИО руководителя;

- ФИО главного бухгалтера.

Б) Накладная по поступлению товаров от поставщиков:

- номер накладной;

- дата оформления документа;

- склад;

- поставщик;

- № договора;

- зачет аванса;

- налоги;

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

- количество товара;

- цена за единицу измерения;

- стоимость товара без учета налога;

- сумма налога товара;

- стоимость товара с учетом налога;

- итого с учетом НДС;

-сумма НДС.

В) Накладная по отгрузке товара:

- плательщик;

- договор;

- склад;

- вид отгрузки;

- зачет аванса;

- налоги;

- тип цен;

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

- цена за единицу измерения;

- стоимость товара без учета налога;

- сумма налога товара;

- стоимость товара с учетом налога;

- итого с учетом НДС;

-сумма НДС.

Описание файлов базы данных для хранения входной информации

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

Таблица 2.1

Структура базы данных Scfac.db

Наименование поля	тип	длина	Назначение
Nom	A	10	№ счет-фактуры
Dt1	D		дата составления счета
Prod	A	100	продавец
Adr	A	100	адрес продавца
Inn	A	20	ИНН/КПП продавца
Grusotp	A	100	грузоотправитель и его адрес
Grusop	A	100	грузополучатель и его адрес
Prsd	A	100	платежно-расчетный документ
Pok	A	100	покупатель
Adr1	A	100	адрес покупателя
Inn1	A	20	ИНН/КПП покупателя
Sum1	$		стоимость товара с учетом налога
Snds	$		сумма налога
Ruk	A	35	ФИО руководителя
Glbuch	A	35	ФИО главного бухгалтера

Таблица баз данных scfac1.db используется для хранения табличной части счета. Структура приведена в табл. 2.2.

Таблица 2.2

Структура базы данных scfac1.db

Наименование поля	тип	длина	Назначение
Nom	A	10	Номер счета
Name	A	50	наименования товара
Ed_izm	A	10	единица измерения
Kol	S		количество товаров
Cena	$		цена за единицу измерения
Sum	$		стоимость товара без учета налога
Nalog	S		налоговая ставка
Snds	$		сумма налога по товару
Sum1	$		стоимость товара с учетом налога

Таблица баз данных nakl_post.db используется для хранения заголовочной части накладной поступления товара. Структура приведена в табл. 2.3.

Таблица 2.3

Структура базы данных nakl_post.db.DBF

Наименование поля	тип	длина	Назначение
1	2	3	4
Nom	A	10	номер накладной
Dt	D		дата оформления документа
Sklad	A	25	склад
Post	A	50	поставщик
Dogov	A	50	№ договора
Zac_av	A	50	зачет аванса
Nalog	A	50	налоги
Snds	$		итого с учетом НДС
Sum1	$		-сумма НДС.

Таблица баз данных nakl_post1.db используется для хранения табличной части накладной по поставке товара. Структура приведена в табл. 2.4.

Таблица 2.4

Структура базы данных nakl_post1.db

Наименование поля	тип	длина	Назначение
Nom	A	10	Номер счета
Name	A	50	наименования товара
Ed_izm	A	10	единица измерения
Kol	S		количество товаров
Cena	$		цена за единицу измерения
Sum	$		стоимость товара без учета налога
Nalog	S		налоговая ставка
Snds	$		сумма налога по товару
Sum1	$		стоимость товара с учетом налога

Таблица баз данных nakl_otg.db используется для хранения заголовочной части накладной отгрузки товара. Структура приведена в табл.2.5.

Таблица 2.5

Структура базы данных nakl_otg.db.DBF

Наименование поля	тип	длина	Назначение
Nom	A	10	номер накладной
Dt	D		дата оформления документа
Sklad	A	25	склад
Наименование поля	тип	длина	Назначение
Post	A	50	Плательщик
Dogov	A	50	№ договора
Vid_ogr	A	50	Вид отгрузки
Zac_av	A	50	зачет аванса
Nalog	A	50	налоги
Typ	A	50	Тип цены
Snds	$		итого с учетом НДС
Sum1	$		-сумма НДС.

Таблица баз данных nakl_otg1.db используется для хранения табличной части накладной по поставке отгрузке товара. Структура приведена в табл.2.6.

Таблица 2.6

Структура базы данных nakl_otg1.db

Наименование поля	тип	длина	Назначение
Nom	A	10	Номер счета
Name	A	50	наименования товара
Ed_izm	A	10	единица измерения
Kol	S		количество товаров
Cena	$		цена за единицу измерения
Sum	$		стоимость товара без учета налога
Nalog	S		налоговая ставка
Snds	$		сумма налога по товару
Sum1	$		стоимость товара с учетом налога

Характеристика постоянной входной информации

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

Для хранения этой информации необходимо разработать соответствующие таблицы баз данных. Структуры и имена файлов, в которых они будут храниться представлены в табл. 2.7-2.10.

Таблица 2.7

Структура базы данных sklad.db

Наименование поля	тип	длина	Назначение
Kod	A	10	Номер склада
Name	A	50	наименования склада
Prim	A	100	примечание

Таблица 2.8

Структура базы данных tovar.db

Наименование поля	тип	длина	Назначение
Kod	A	10	Код товара
Name	A	50	наименования
Typ	A	20	Тип товара
Proiz	A	35	Страна производитель

Таблица 2.9

Структура базы данных postavsh.db

Наименование поля	тип	длина	Назначение
Kod	A	10	Код поставщика
Name	A	50	наименования
Adr	A	60	Адрес поставщика
Inn/kpp	A	20	ИНН/КПП
phone	A	12	телефон

Таблица 2.10

Структура базы данных dogovor.db

Наименование поля	тип	длина	Назначение
Kod	A	10	Номер договора
Tex	M		Текст договора

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

Результатную информацию, формируемую в данном программном приложении можно подразделить на два вида: 1) информацию, формируемые на экране; 2) документы, формируемые в виде файлов и выводимые на печать.

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

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

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

Ш макет счета фактуры (рис.2.3.);

Ш макет накладной по отгрузке товара (рис.2.4.);

Ш макет накладной по поступлению товара (рис.2.5.);

Ш макет документа отображающей данные книги продаж (рис.2.6.);

Ш макет, отображающий отчет по продажам (рис.2.7.).

Рис.2.3. Макет счета фактуры

Рис.2.4. Макет накладной по отгрузке товара



Рис.2.5. Макет накладной по поступлению товара

Рис2.6. Макет «Книги продаж»

Рис.2.7. Отчет по продажам

2.2 Машинная реализация комплекса задач

При разработке программного приложения с использованием языка С++ Builder необходимо создать таблицы базы данных проекта. Для этих целей в системе программирования существует инструмент Database DeskTop. С помощью команды New->Table создадим таблицы баз данных и сохраним их в папке BD, которая и будет базой данных проекта. После чего можно приступить непосредственно к программному приложению. Основой приложения являются формы, на которые размещаются компоненты. Особенностью приложений работающих с базами данных является обязательно наличие компонент доступа к данным. В данном приложении использованы компоненты Table, DataSource.

Для представления данных на форме используются компоненты Edit, Label, DBGrid, DBNavigator, DateTimePicker и др.

Проект состоит из множества форм, каждая из которых выполняет одну функцию. После разработки всех форм необходимо определить опции проекта. Для этого используется команда C++ Builder - Project->Option (рис.2.8)

Рис.2.8. Окно опции проекта

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

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

Состав и функции системы:

Таблицы базы данных системы:

1. Таблица баз данных scfac.db используется для хранения данных заголовочной части счета.

2. Таблица баз данных scfac1.db используется для хранения табличной части счета.

3. Таблица баз данных nakl_post.db используется для хранения заголовочной части накладной поступления товара.

4. Таблица баз данных nakl_post1.db используется для хранения табличной части накладной по поставке товара.

5. Таблица баз данных nakl_otg.db используется для хранения заголовочной части накладной отгрузки товара.

6. Таблица баз данных nakl_otg1.db используется для хранения табличной части накладной по поставке отгрузке товара.

7. Таблица баз данных sklad.db - для хранения данных о складах.

8. Таблица баз данных Tovar.db - для хранения данных о товарах.

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

10. Таблица баз данных postavsh.db - для хранения данных о поставщиках товаров.

Формы (Units)

1. Form1 - модуль - форма главного окна программного приложения.

2. Form2- модуль - форма ввода новых данных «Поступление товаров и услуг: Новый товар».

3. Form3 - модуль - форма просмотра данных «Справочник Контрагенты

4. Form4 - модуль - форма просмотра данных «Справочник: Склады организации».

5. Form5 - модуль-форма просмотра данных «Справочник: Договора».

6. Form6 - модуль-форма просмотра данных «Справочник Номенклатура».

7. Form7 - форма ввода данных документа «Отгрузка товаров. Продажа».

8. Form8 - форма просмотра книги продаж.

9. Form9 - форма просмотра данных накладных по поступлениям товаров.

10. Form10 - форма ввода нового входного документа «Счета фактура».

11. Form11 модуль - форма просмотр данных введенных в базу данных о накладных - «Отгрузка товаров».

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

13. Form13- формирование документа «Формирование отчета по продажам»

14. Form14- форма о программе

15. Form15-- формирование документа «Счет фактура»

16. Form16- форма анализа документа «Книга продаж».

17. Form17- формирование документа «Поступление товаров»

18. Form18- формирование отчета «Отгрузка товаров»

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

Структура меню программного приложения

Как уже было сказано ранее в данном программном приложении, реализованном на объектно-ориентированном визуальном языке программирования С++ Builder 6, имеется возможность создавать удобные конструкции с использованием различных видов меню. К основным видам меню можно отнести световое, клавишное и кнопочное меню. Все эти виды реализованы в программном приложении. Главное двухуровневое меню реализовано в виде светового (см. рис. 2.9).

Рис.2.9. Настройка меню программного приложения

После настройки компоненты главное меню MainМenu1 оно отражается на форме на верхней строке.

Рис.2.10. Вид главного меню приложения

2.2.2 Детальная блок-схема основных расчетных модулей

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



Рис.2.11. Блок-схема программного комплекса

2.2.3 Организация технологического процесса сбора, передачи, обработки и выдачи информации

Для запуска программы необходимо запустить одним из способов из операционной системы windows программный файл проекта Firmaas.exe., который располагается в папке d:\gkas\firmaas.exe. После загрузки программа откроет окно с главным меню программы (рис.2.12).



Рис.2.12. Окно с главным меню системы

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

Рис.2.13. Форма ввода технико-экономических показателей

При вводе товара программа автоматически считает значения стоимости товаров, НДС и сумм с НДС. Заполнив все поля ввода кнопкой «Сохранить» запишем данные в БД, причем автоматически будет подсчитана сумма счета. После ввода данных можно выполнить печать полученного документа на принтере (рис.2.14).

Рис.2.14. Документ «Счет фактура»

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

Рис.2.15.Окно ввода данных «Накладная по поступление товара»



Рис.2.16. Документ «Накладная по поступление товара»

Рис.2.17. Окно ввода данных «Накладная по отгрузке товара»

Рис.2.18. Документ «Накладная по отгрузке товара»

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

Рис.2.19.Отчет «Отчет по продажам»

Рис.2.20. Отчет «Книга продаж»

Завершение программы выполняется командой меню «Выход».

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

3.1 Выбор и обоснование методики расчета экономической эффективности проекта

В соответствии с ГОСТ 24.702-85 целесообразные варианты построения ИС выбираются путем балансирования показателей приращения эффекта Э, получаемого за счет создания или совершенствования ИС и затрат Q. Математически эту задачу формулируют в виде:

MAX Э при Q=const

или в виде обратной задачи:

MIN Q при Э=const

При оценке эффективности ИС используют обобщающие и частные показатели. К основным показателям экономической эффективности относятся:

Ш расчетный коэффициент эффективности капитальных вложений:

Е_p=П/К,

где П -- годовая экономия (годовой прирост прибыли), руб;

К -- единовременные затраты, руб;

Ш годовой экономический эффект:

Э=П-К*Е_н,

где Е_н -- нормативный коэффициент эффективности капитальных вложений (Е_н=0,15).

Произведение К*Е_н в данном случае следует рассматривать как нормативную прибыль, которая должна быть получена от внедрения системы.

Ш срок окупаемости:

Т=К/П=1/Е_р.

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

Ш годовая экономия (годовой прирост прибыли);

Ш единовременные затраты на разработку и внедрение системы;

Ш длительность обработки информации;

Ш надежность технических средств;

Ш увеличение затрат вследствие ненадежности КТС (комплекса технических средств), руб.;

Ш достоверность и др.

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

Пу=З_б-З_п,

где З_б,З_п - приведенные к одному году затраты на обработку информации соответственно при существующем и предполагаемом вариантах организации ИС.

Среднегодовые затраты на обработку информации (ЗП,ЗБ), приведенные выше в формуле, должны определятся с учетом всех стадий жизненного цикла ИС:

З_п=(Р+С)/Т_экс+Ф,

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

С - единовременные затраты на создание и внедрение системы, не учитываемые в себестоимости машино-часа, руб.,

Т_экс - предполагаемый срок эксплуатации ИС лет,

Ф - среднегодовые затраты на функционирование ИС (текущие затраты), руб..

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

Единовременные затраты на создание ИС (С) в общем виде равны сумме затрат на проектирование (R) и удельных затрат на приобретение, монтаж, наладку используемых средств (КВТ), однако, вследствие того, что КВТ учитывается при расчете себестоимости машино-часа, во избежание двойного счета значение С в большинстве случаев следует принимать равным R.

Единовременные затраты на проектирование R определяются следующим образом:

R=S_тз*T_тз+S_тп*T_тп,

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

Срок предполагаемой эксплуатации определяется в соответствии с периодами морального старения соответствующей техники (8 лет).

3.2 Расчет показателей экономической эффективности проекта

3.2.1 Разработка плана выполнения работ

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

При разработке данного дипломного проекта были проведены работы:

1. Постановка технического задания;

2. Согласование технического задания;

3. Анализ технического задания;

4. Выбор методики проектирования программного продукта ;

5. Сбор необходимых данных для создания программного продукта;

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

7. Разработка аналитической части;

8. Анализ проделанной работы;

9. Инфологическое проектирование программного продукта;

10. Даталогическое проектирование программного продукта;

11. Разработка алгоритма комплекса решения задач;

12. Анализ проделанной работы;

13. Формирование и заполнение БД;

14. Разработка собственных программных средств;

15. Тестирование разработанного пакета программ;

16. Отладка разработанного программного обеспечения;

17. Выбор методики расчета экономической разработанного пакета программ;

18. Расчет показателей экономической эффективности;

19. Разработка инструкций для пользователей;

20. Оформление пояснительной записки к дипломному проекту.

На основании плана выполнения работ составлена табл.3.1.

Таблица 3.1

№	i-j	Наименование работы	Z	Tож
1	2	3	4	5
1	0-1	Постановка технического задания	1	1
2	1-2	Согласование технического задания	1	0,5
3	1-3	Анализ технического задания	2	1
4	2-3	Выбор методики проектирования	1	1
5	3-4	Сбор необходимых данных	1	6
6	4-5	Изучение требований к системе с точки зрения возможных пользователей	1	1
7	5-6	Разработка аналитической части	1	17
8	6-7	Анализ проделанной работы	2	0,5
9	7-8	Инфологическое проектирование	1	5
10	8-9	Даталогическое проектирование	1	2
11	9-10	Разработка алгоритма решения задач	1	8
12	9-11	Анализ проделанной работы	2	1,5
13	10-11	Формирование и заполнение БД	1	2
14	11-12	Разработка собственных программных средств	1	20
15	12-13	Опытная эксплуатация	1	1
16	13-14	Отладка разработанного программного обеспечения	1	2
17	14-15	Консультация по экономической эффективности	2	0,5
18	14-16	Расчет экономической эффективности	1	4
19	15-16	Подготовка инструкций для пользователей	1	1
20	16-17	Оформление пояснительной записки к дипломному проекту	1	1

На основе таблицы построим сетевой график(рис 3.5).



Рис. 3.5. Сетевой график

Данный сетевой график имеет параметры: Ткр = 72 дня.

После построения сетевого графика определяются основные временные параметры сетевого графика: ранний и поздний сроки наступления событий Т_i^(р), T_i^(п); ранние и поздние сроки начала и окончания работ t_ij ^(рн), t_ij^(пн), t_ij^(ро), t_ij^(по); резервы времени работ и событий r_ij^(п),r_ij^(св),R_i. Параметры рассчитаны и приведены в таблице 3.2.

Таблица 3.2

№ работы	Код работ	Параметры работ и событий в днях
	i	j	tij	Ti(p)	Ti(п)	Tj(p)	Tj(п)	tijрн	tijпн	tijро	tijпо	rijп	rijсв	Ri
1	0	1	1	0	0	1	1	0	0	1	1	0	0	0
2	1	2	0,5	1	1	1,5	1,5	1	1	1,5	1,5	0	1	0
3	1	3	1	1	1	2,5	2,5	1	1,5	2	2,5	0	1,5	0
4	2	3	1	1,5	1,5	2,5	2,5	1,5	1,5	2,5	2,5	0	1,5	0
5	3	4	6	2,5	2,5	8,5	8,5	2,5	2,5	8,5	8,5	0	2,5	0
6	4	5	1	8,5	8,5	9,5	9,5	8,5	8,5	9,5	9,5	0	8,5	0
7	5	6	17	9,5	9,5	26,5	26,5	9,5	9,5	26,5	26,5	0	9,5	0
8	6	7	0,5	26,5	26,5	27	27	26,5	26,5	27	27	0	26,5	0
9	7	8	5	27	27	32	32	27	27	32	32	0	27	0
10	8	9	2	32	32	34	34	32	32	34	34	0	32	0
11	9	10	8	34	34	42	42	34	34	42	42	0	34	0
12	9	11	1,5	34	34	44	44	34	42,5	35,5	44	0	42,5	0
13	10	11	2	42	42	44	44	42	42	44	44	0	42	0
14	11	12	20	44	44	64	64	44	44	64	64	0	44	0
15	12	13	1	64	64	65	65	64	64	65	65	0	64	0
16	13	14	2	65	65	67	67	65	65	67	67	0	65	0
17	14	15	0,5	67	67	67,5	68,5	67	68	67,5	68,5	0	67	0
18	14	16	4	67	67	71	71	67	67	71	71	0	67	0
19	15	16	1	67,5	67,5	71	71	67,5	70	68,5	71	0	70	0
20	16	17	1	71	71	72	72	71	71	72	72	0	71	0

Далее определяется продолжительность пути сетевого графика как сумма продолжительностей составляющих его работ. Полный путь, имеющий наибольшую продолжительность, называется критическим Т_кр. Для событий критического пути R_i=0, так как T_i^(р)=T_i^(п). продолжительность критического пути больше продолжительности любого другого пути сетевого графика. Критический путь на сетевом графике выделяется жирной линией. Разность между продолжительностью критического пути и продолжительностью любого полного пути является резервом времени этого пути R:

R(Ls)=T_кр-t(Ls).

Расчёт продолжительности и резервов времени путей сетевого графика производится в табл. 3.3.

Таблица 3.3

Расчет продолжительности путей сетевого графика

Обозначение пути	Продолжительность событий пути	T(Ls)	R(Ls)	Примечание
L1	0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,16,17	72	0	Критический путь
L2	0,1,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17	69	3
L3	0,1,2,3,4,5,6,7,8,9,11,12,13,14,15,16,17	61	11
L4	0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17	69,5	2,5
L5	0,1,3,4,5,6,7,8,9,11,12,13,14,15,16,17	60,5	11,5
L6	0,1,3,4,5,6,7,8,9,10,11,12,13,14,16,17	71,5	0,5
L7	0,1,2,3,4,5,6,7,8,9,11,12,13,14,16,17	63,5	8,5
L8	0,1,3,4,5,6,7,8,9,11,12,13,14,16,17	64	8

3.2.2 Трудоемкость разработки программного обеспечения

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

t = t_о + t_и + t_а + t_п+ t_отл +t_д

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

Q = qc(1 + p);

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

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

Коэффициенты, используемые при оценке затрат труда на подготовку задачи к решению ее на ЭВМ в автоматизированной системе, характеризуют различные факторы: коэффициент сложности программы с - относительную сложность программ задачи по отношению к так называемой типовой задаче, сложность которой принята равной единице (типовые задачи для разных классов АС могут быть разными, поэтому в процессе создания базовой АС необходимо определять типовую задачу, с трудоемкостью разработки, которой можно будет сравнивать другие задачи в АС данного класса: величина с (лежит в пределах от 1,25 до 2); коэффициент коррекции программы p - увеличение объема работ за счет внесения изменений в алгоритм или программу решения задачи по результатам уточнения постановок и описаний ее, изменения состава и структуры информации, а также уточнений, вносимых разработчиками для улучшения качества самой программы без изменения постановки задачи (на практике при разработке программы в среднем вносится 3-5 коррекций, каждая из которых ведет к переработке от 5 до 10% готовой программы, т.е. величина p находится в пределах 0,05...0,1); коэффициент квалификации разработчика k - степень подготовленности исполнителя к порученной ему работе (он определяется в зависимости от стажа работы и составляет: для работающих до двух лет - 0,8; от двух до трех лет - 1,0; от трех до пяти лет - 1,1-1,2; от пяти до семи лет - 1,3-1,4; свыше семи лет - 1,5-1,6); коэффициент увеличения затрат труда вследствие недостаточного описания задачи В - качество постановки задачи, выданной для разработки программы, в связи с тем, что задачи, как правило, требуют уточнения и некоторой доработки (практика показывает, что в большинстве случаев этот коэффициент в зависимости от сложности задачи принимается от 1,2 до 1,5)[1].

Затраты труда на изучение описания задачи t_и с учетом уточнения описания и квалификации программиста могут быть определены по формуле, чел-ч:

t_и = QB/ (75-85)k

Затраты труда на разработку алгоритма решения задачи tа рассчитываются по формуле, чел-ч:

t_а = Q/(20-25)k

Затраты труда на составление программы по готовой блок-схеме tп определяются по формуле, чел-ч:

t_п = Q/ (20-25)k

Затраты труда на отладку программы на ЭВМ tотл рассчитывается по следующим формулам, чел-ч:

t_отл = Q/(45)k

Затраты труда на подготовку документации по задаче tд определяются по формуле, чел-ч:

t_д = t_др +t_до,

где t_др -затраты труда на подготовку материалов в рукописи, равные Q/(15-20)k;

t_до - затраты труда на редактирование, печать и оформление документации, равные 0,75t_др.

Полная средняя трудоемкость разработки программы:

T_pп=0.83*Q/k

Рассчитаем трудоемкость разработки программного обеспечения.

q=600; c=1,35; p=0,07; k=1,18; B=1,3

Q= qc(1 + p)=600*1,35*(1+0,07)=866.7

t_и = QB/ (75ч85)k = 866.7*1,35/(81*1,18)=11,79 (чел-ч.);

t_а = Q/(20ч25)k = 866.7/(22*1,18)=33,39 (чел-ч.);

t_п = Q/ (20ч25)k = 866.7/(22*1,18)=33,39(чел-ч.);

t_отл = Q/(45)k = 866.7/(45*1,18)=16,32 (чел-ч.);

t_др = Q/(15ч20)k = 866.7/(20*1,18)=36,73 (чел-ч.);

t_до = 0,75tдр = 0,75*36,73=27,54 (чел-ч.);

t_д = t_др + t_до = 36,73+27,54=64,27 (чел-ч.);

t = t_о + t_и + t_а + t_п + t_отл + t_д =195,12(чел-ч.) /8 =24 чел. дней.

Итак, трудоемкость разработки программы - 24 (чел. дней).

3.2.3 Расчет единовременных затрат на проектирование и отпускной цены программного продукта

Затраты на разработку программы состоят из:

Ш прямой производственной заработной платы (Фзарп);

Ш дополнительной заработной платы (Фдоп.зарп) - 15 - 20 % от основной производственной заработной платы;

Ш начислений на заработную плату (Н) - 13 % от общей заработной платы;

Ш услуги сторонних организаций (Смаш);

Ш накладных расходов (Нр=(Фзарп+Фдоп.зарп+Н+Смаш)*b/(1-b), b=0,2);

Ш отчислений в пенсионный фонд (Фпенс) - 22 % от общей заработной платы;

Ш отчислений на социальное страхование (Фсоц.стр.) - 2,9% от общей заработной платы;

Ш отчислений на медицину (Фмед) - в ФФОМС 5.1 % от общей заработной платы, в ТФОМС 0 % от общей заработной платы.

Вычислим себестоимость одного чел.-дня на стадии Т1 (Ткр-Т2=72-24 =48) когда не пользовались средствами проектирования (S1):