Автоматизированная справочно-информационная система учета и контроля поставок на предприятие

СОДЕРЖАНИЕ 1. Состояние проблемы учета поставок на предприятие. Введение 1.1 Общая характеристика проблемы 1.2 Формулировка задач
1.3 Мотивация задач. 1.3. Техническое задание. Введение. 1.3.1. Основания для разработки. 1.3.2. Назначение разработки. 1.3.3. Исходные данные и источники. 1.3.4. Исходные требования к конечному результату. 1.3.5. Этапы проведения работ. 1.3.6. Планируемые показатели эффективности. 1.3.7. Порядок приемки результатов работы. 1.3.8. Документация, предъявляемая по окончанию работы. 2. Моделирование. 2.1 Анализ представления моделей данных. 2.2 Выбор логической модели данных. 2.2.1 Иерархическая модель данных. 2.2.2 Сетевая модель данных. 2.2.3 Реляционная модель данных. 2.3 Выбор концептуальной модели. 2.4 Процесс моделирования. 2.4.1 Выделение сущностей. 2.4.2. Выделение связей между сущностями 2.5 Построение логической модели. 3. Проектирование алгоритмов справочно-информационной системы учета и контроля поставок на предприятие. 3.1 Выбор метода проектирования АСИС. 3.2. Анализ алгоритмов работы с базой данных 3.3. Проектирование алгоритмов расчёта задолженности по оплате поставок и определения оптимальной заявки. 4. Выбор средств для разработки АСИС, описание структуры АСИС.- 4.1 Выбор аппаратных средств. 4.2. Анализ и выбор программных средств разработки АСИС. 4.3. Описание общей структуры АСИС. 4.4. Описание программы. 4.4.1. Описание интерфейса. 4.4.2 Работа с режимами АСИС 5. Испытания программного продукта. 5.1. Справочные документы. 5.2. Краткий обзор верификации. 5.3. Процессы верификации. 5.3.1. Сквозной контроль. 5.3.2. Трассировка требований к ПО и требований пользователя. 5.3.3. Тестирование внешних функций. 5.3.4. Тестирование модуля. 5.4.5. Комплексное тестирование. 5.5. Выводы по тестированию ПО. 6. Разработка бизнес-плана автоматизированной справочно-информационной системы “Учет поставок”. Резюме. 6.1. Описание автоматизированной справочно-информационной системы. 6.2 Маркетинговые исследования рынков сбыта. 6.3 Оценка качества и конкурентоспособности продукта. 6.4 Определение затрат на разработку АСИС “Учет поставок”. 6.5 Стратегия маркетинга. 6.6 Оценка риска и страхования. 6.7 Финансовый план. 7. Безопасность жизнедеятельности 7.1. Выявление вредных и опасных факторов. 7.2. Мероприятия по защите от вредных и опасных факторов. Заключение. Список используемой литературы. Приложения Список используемых обозначений. АСИС – автоматизированная справочно-информационная система; БД – база данных; ОЗУ – оперативное запоминающее устройство; ПК – персональный компьютер; ПО – программное обеспечение; ОП – оперативная память; ВП – видеопамять; ПП – программный продукт; ПЭВМ – персональная электронно-вычислительная машина; СУБД – система управления базами данных; 1. Состояние проблемы учета поставок на предприятие. Введение Хозяйство Украины представляет собой совокупность предприятий и организаций отдельных отраслей народного хозяйства различных форм собственности. Предприятия государственной формы собственности находятся в ведении различных министерств и ведомств, а также в ведении местных исполкомов. Производственная деятельность как и хозяйственная, направлены на выпуск предметов культурно-бытового назначения, хозяйственного обихода и др. Таким образом, в состав хозяйства Украины входят предприятия и организации, как сферы материального производства, так и сферы обслуживания, как хозрасчетные, так и состоящие на государственном бюджете. Наибольшее число госбюджетных организаций находится в ведении Министерства образования и науки Украины: школы, детские сады, педагогические институты, техникумы, училища и т.п. (около 30% общего количества организаций); министерства здравоохранения Украины – больницы, санатории, госпитали и др. лечебные учреждения (около 20%); министерства культуры и просвещения Украины – театры, библиотеки, музеи и др. (более 25% общего количества организаций) [3]. Руководство местным хозяйством страны организовано как по отраслевому принципу (через соответствующие министерства и ведомства), так и по территориальному (через местные органы управления). Предприятия хозяйства Украины производят разнообразную продукцию. В ее числе можно найти средства производства: станки, машины, металлопродукцию, товары народного потребления, предметы бытовой химии и т.п. Для производства всей вышеперечисленной продукции предприятия, независимо от форм собственности, для своего нормального и стабильного функционирования нуждаются в сырье, комплектующих, запчастях и т.п. Иными словами для организации своей деятельности предприятия сталкиваются с проблемой своевременной поставки продукции. Для этих целей предприятия государственной формы собственности используют снабженческие организации (в настоящее время данными организациями пользуются специализированные государственные предприятия), предприятия же частных форм собственности проводят соответствующие мероприятия, направленные на своевременное и непрерывное обеспечение необходимым сырьем или материалами. Но в настоящее время практически все предприятия любой формы собственности самостоятельно занимаются поиском предприятий-поставщиков, а также по мере необходимости организацией поставок. Одним из показателей характеризующих работу предприятия является товарооборот, который представляет собой планово организационный процесс обращения средств производства [2], от которого во многом зависят и другие экономические показатели. В общий объем товарооборота включают все товары, реализованные предприятием, т.е. полученные от предприятий поставщиков продукции. Также товарооборот показывает насколько быстро предприятие использует полученную продукцию, т.е. какими темпами оно осуществляет свою деятельность, чем больше на предприятие осуществляется поставок, тем более стабильно работает данное предприятие. При осуществлении поставок на предприятие производится обработка и хранение большого количества информации, связанной с поставками, которая в себя включает: своевременное и правильное оформление документов и контроль за каждой операцией поступления товаров от поставщиков, из переработки и других источников, выявление расхождения фактического наличия и количества, указанного в сопроводительных документах; контроль за своевременным, полным и правильным оприходованием поступивших товаров; своевременное и правильное оформление документации и контроль за каждой операцией отпуска, отгрузки или реализации товара; контроль за соблюдением нормативов запаса товаров. В связи с этим для надежного функционирования системы поставок необходимо вести их систематический и непрерывный учет, что и будет выполнять разрабатываемое ПО.
Разрабатываемый программный продукт будет отличаться от аналогичного программного обеспечения возможностью применения на современной электронно-вычислительной технике [1], удобным интерфейсом, низкой стоимостью, возможностью его использования на любом предприятии. 1.1 Общая характеристика проблемы
При осуществлении поставок предприятия изготовители продукции производственно-технического назначения вступают в договорные отношения с предприятиями потребителями (покупателями) как поставщики заключают прямые договора с предприятиями потребителями для сбыта продукции и комплексного снабжения предприятий-заказчиков. Договоры о поставках необходимо заключать своевременно. В них указываются условия поставки товаров, их количество, ассортимент, качество, комплектность и сроки поставки. Кроме того, в договорах предусмотрены цены на товары, общая сумма, порядок расчетов, платежные и отгрузочные реквизиты поставщика и получателя продукции. Договора подлежат обязательному выполнению по всем указанным в них пунктам. Нарушение сроков договоров и обязательств влечет ответственность, предусмотренную “Положением о поставке продукции производственно-технического назначения” и “Особыми условиями поставки.” Контроль за выполнением договоров осуществляют товарные отделы. Рациональная организация приемки продукции от поставщиков имеет важное значение для своевременного, полного, комплексного снабжения предприятий сырьем, материалами, топливом, инструментами, оборудованием и другими средствами производства. Правильная приемка и оформление документами поступивших товаров Является надежной основой сохранности товарно-материальных ценностей. Общий порядок приемки товарно-материальных ценностей установлен “Положением о поставке продукции производственно-технического назначения”. Порядок и сроки приемки товарно-материальных ценностей в определенном количестве и качестве, оформление актов приемки и предъявление претензий определены инструкцией о порядке приемки продукции производственно-технического назначения и товаров народного потребления по количеству и инструкцией о порядке приемки продукции производственно-технического назначения по качеству. Особенности приемки отдельных видов продукции определяются в ГОСТах [12.01.005-89], технических условиях, Особых условиях поставки и договорах поставки, предусматривающих особые порядки приемки продукции при поставках. На предприятиях государственной формы собственности осуществлением всех действий связанных с поставками и оформлением необходимых документов , при наличии соответствующего программного обеспечения, занимается определенное количество персонала предприятия, но , как правило, разработка такого программного обеспечения велась на языках низкого уровня программирования, а за последние 6-8 лет развитие машинных средств (ПЭВМ), программных средств резко увеличилась, поэтому ранее разработанное ПО не отвечает более высоким требованиям, предъявляемым к современным программным продуктам. Что же касается предприятий, фирм различный форм частной собственности, то они зачастую не имеют вовсе соответствующего программного обеспечения, что значительно увеличивает трудоемкость процесса контроля и учета проведения поставок. Разрабатываемый программный продукт и призван решать данные проблемы. 1.2 Формулировка задач Любое предприятие, осуществляя свою деятельность, для получения продукции от поставщиков должно заключить с последними договор на поставку продукции. Обычно на одноименную продукцию предприятие-заказчик заключает несколько договоров с предприятиями-поставщиками. Затем заказчик по мере потребности в определенной продукции высылает поставщику заявку на поставку продукции и получает от последнего счет-фактуру, в котором указано наименование продукции и ее отпускная цена. На основании этих счетов предприятие-заказчик определяет оптимальную заявку и высылает поставщику заказ на поставку продукции. После получения заказанной продукции заказчик отправляет счет в бухгалтерию, которая оплачивает его в банке в течении срока, предусмотренного договором. Поэтому для документального обеспечения процесса поставок на предприятие программа должна создавать (распечатывать) следующие необходимые документы: - бланк договора предприятия-заказчика с фирмой-поставщиком (с указанием наименования и юридических адресов сторон, ассортимента продукции для поставок, ее количества и предположительной стоимости, а так же условия и сроки действия договора); - заказ на поставку необходимой продукции (указывается количество, наименование, номенклатура, сроки поставки). Также создаваемая автоматизированная система по имеющимся данным о поставщиках и вновь полученным данным должна определять оптимальный счет-фактуру с точки зрения количество-цена. Любую поставку предприятие-заказчик обязано оплатить в установленные договором сроки, поэтому АС должна осуществлять подсчет суммы долга (денег к выплате) на текущую дату. На рис 1.1 представлена функциональная схема осуществления поставок на предприятие. Таким образом для разработки АСИС необходимо выполнить следующие задачи: ¨ реализация управления доступом к АСИС; ¨ создать СУБД для работы АСИС; ¨ разработать справочную информацию по АСИС; ¨ выполнить анализ и учета поставок. 1.3 Мотивация задач. Предприятие или фирма, производя свою продукцию, нуждается в поставках сырья от других предприятий. Но на одно и тоже сырье у разных производителей-поставщиков различная отпускная цена, поэтому в целях снижения себестоимости выпускаемой продукции предприятие заказчик заключает договора с большим количеством поставщиков и затем высылает поставщикам заявку на поставку продукции с указанием типа и ее количества. Поскольку предприятие-заказчик при получении грузов так или иначе связано с документами, с документальным оформлением поставок, то проектируемая АСИС должна создавать все бланки документов, связанных с поставками. Поскольку все поставщики высылают заказчику счета-фактуры (прейскурант цен на заказанную продукцию), то среди их множества необходимо определить наиболее выгодное для предприятия-заказчика, как по цене, так и по качеству, что и должна выполнять создаваемая АС. Так как договора с поставщиками заключаются на определенный срок, предполагаемое количество поставляемой продукции и на определенную сумму, то при осуществлении заказа на поставку продукции, в договоре оговаривается срок, в течении которого заказ должен быть оплачен, поэтому необходимо знать сумму к оплате на указанное число, как общую так и по различным поставщикам в отдельности.
Так как все вышеперечисленные действия осуществляются на протяжении длительного времени, то при приятии решения о продлении срока действия договора целесообразно принимать во внимание следующие факторы: качество поставок конкретными поставщиками (имеется ввиду выполнение сроков осуществления поставок, соответствие номенклатуры поставленной продукции заказанной, отсутствие или процент брака), его терпимость по отношению к оплате по поставкам. Поэтому необходимо сохранять всю информацию о поставках на предприятие, что бы в дальнейшем ее можно было бы использовать.
1.3. Техническое задание. Введение. Автоматизированная справочно-информационная система (АСИС) “Учет поставок” будет использоваться на предприятиях различных форм собственности и обеспечивать контроль и учет поставок производимых на предприятие. Также при использовании данного ПО будет иметься возможность составления отчетности о поставках на предприятие, выявление задолженности по оплате поставок. Разрабатываемое ПО может быть использовано как руководителем предприятия, для осуществления контроля производимых поставок на предприятие, так и начальниками цехов, для ведения учета поставок. 1.3.1. Основания для разработки. Основанием для выполнения работы является приказ о базе преддипломной практики от 10 июня 1999 г. № 270 по Государственному аэрокосмическому университету и приказ о дипломном проектировании от 26 июня 2000 г. № 271. 1.3.2. Назначение разработки. Целью дипломного проектирования является разработка и создание программного продукта “Учет поставок”. Данный программное обеспечение предназначено для контроля, учета, автоматизации и систематизации информации о поставках различного вида продукции на предприятие любой формы собственности, занимающимся любым видом производства или деятельности. Разрабатываемый программный продукт должен обеспечивать создание информационной базы об осуществленных поставках на предприятие, а также осуществлять создание следующих документов : ¨ бланк договора предприятия заказчика с фирмой-поставщиком (с указанием наименования и юридических адресов сторон, участвующих в договоре, ассортимента продукции для поставок, ее количества, предположительной стоимости, условия и сроки действия договора); ¨ заявку на поставку необходимой продукции (указывается количество, наименование, номенклатура, сроки поставки, сумма поставки); ¨ заказ на поставку. Коммерческая версия программного продукта позволит производить: ¨ более полный контроль и организацию учета о поставках на предприятие; ¨ автоматизировать процесс оформления поставок на предприятие; ¨ уменьшит временные затраты на оформление документов, связанных с поставками; ¨ вычислять задолженность по оплате осуществленных поставок на указанный период; ¨ обеспечить пользователя системой помощи как по понятиям предметной области, так и по пользованию программным продуктом. Разрабатываемый автоматизированная система должна будет реализовать следующие функции: 1. Обеспечение ввода данных о поставках на предприятие; 2. Анализ введенной информации; 3. Подсчет задолженности предприятия за осуществленные поставки; 4. Определять оптимальный счет-фактуру с точки зрения “количество-цена”; 5. Производит печать документации, связанной с организацией поставок (бланк договора, заказа, заявки). 1.3.3. Исходные данные и источники. Данная работа базируется на теме преддипломной практики и является ее продолжением с учетом рекомендаций по улучшению ранее разработанного ПО, предложенных руководителем практики от предприятия и группой сотрудников этого предприятия и рассмотренных руководителем практики от института. 1.3.4. Исходные требования к конечному результату. Требования по функциональности. Разрабатываемая АСИС должен обеспечивать автоматизированный контроль, а так же учет поставок на предприятие (цех этого предприятия), для этого создаваемая система должна: ¨ Обеспечивать ввод, связанных с поставками на предприятие и обработку этих данных; ¨ Создавать отчетные документы и документы для организации грузопоставок; ( Приложение А) ¨ Иметь систему помощи по программе; ¨ При вводе данных об наименовании товаров должен использоваться справочник “Номенклатура товаров”; ¨ Создаваемые документы должны отвечать отраслевым стандартам, принятым на предприятии. Условия эксплуатации Создаваемый программный продукт должен будет использоваться директором предприятия, начальником цеха, начальником склада, в зависимости от места эксплуатации продукта. Заданные характеристики функционирования должны обеспечиваться при условиях, которые определяются конкретным носителем данных, на котором хранятся данные. Наиболее распространенными носителями данных в настоящее время являются жесткие диски, для которых оптимальным является функционирование при температурах от 5 до +35оС и относительной влажности от 10 до 60 процентов. Требования к составу и параметрам технических средств Программа должна функционировать на персональных компьютерах со следующей конфигурацией: - IBM PC/AT совместимых ПЭВМ не ниже Pentium 100; - с объемом ОЗУ не менее 16 мегабайт; - Объем необходимого дискового пространства - не менее 10 мегабайт. Требования к информационной и программной совместимости Создаваемая программа должна функционировать, легко инсталлироваться, настраиваться и корректно работать при выполнении следующих требований: - наличие операционной системы типа Windows 95, Windows 98, Windows NT 4.x, Windows 2000 и совместимых с ними; - наличие базы данных LocalInterBase или совместимых с ней; - ввод даты обязателен в форме маски; - ввод цифр обязателен. Требования по защите. Для обеспечения защиты от несанкционированного доступа к информации, связанной с поставками на предприятие будет предусмотрена система паролей при загрузке программы в оперативную память. Для обеспечения защиты данных про сбое в сети питания ПК либо аварийном завершении работы программы будет предусмотрен режим автосохранения. 1.3.5. Этапы проведения работ. Этапы проведения работы представлены в таблице 1.2. Таблица 1.2. Этапы проведения работы. № Этапы Сроки выполнения Отчетность 1 Изучение принципов системы грузопоставок на предприятие 07.07.1999 – 14.07.1999 2 Ознакомление с ранее проделанной работой 01.09.1999– 08.09.1999 3 Определение требований к разработке 9.09.2000– 19.09.1999 Техническое задание 4 Разработка информационной модели предметной области (построение концептуальной модели) 20.09.200– 09.10.1999 5 Выбор алгоритмических средств 10.10.1999– 28.10.1999 6 Определение программных средств 29.10.99– 07.11.1999 7 Выбор методики испытания и тестирования 08.11.1999– 15.11.1999 Техническое предложение 8 Разработка алгоритмов, связанных с реализацией учета поставок 16.11.1999– 9.12.1999 9 Проектирование алгоритмов, связанных с формированием тестовых заданий 10.12.1999 – 20.12.1999 10 Определение средств проведения тестирования и анализа его результатов 11.12.1999– 30.12.1999 11 Разработка программного обеспечения связанного с реализацией учета поставок на предприятие 31.12.1999– 15.02.2000 12 Разработка программного обеспечения связанного с формированием тестовых заданий 16.02.2000– 3.03.2000 13 Реализация программного обеспечения проведения тестирования и анализа его результатов 4.03. 2000– 4.04.2000 14 Проведение тестирования и испытаний разработанного программного обеспечения 5.04.2000– 19.04.2000 16 Написание расчетно-пояснительной записки 20.04.2000– 21.05.2000 Расчетно-пояснительная записка 17 Подготовка плакатов 22. 05.2000– 29.05.2000 Плакаты 18 Подготовка доклада 29.05.2000– 11.06.2000 Доклад 19 Предзащита дипломного проекта 12.06.2000 20 Защита дипломного проекта 20.06.2000 1.3.6. Планируемые показатели эффективности. В результате выполненной работы предполагается достигнуть следующих эффектов: ¨ уменьшение времени необходимого для учета поставок произведенных на предприятие; ¨ автоматизация контроля поставок; ¨ возможность длительного хранения информации о поставках на предприятие большого срока давности, для возможности более полного расчета эффективности деятельности предприятия;
¨ постоянная известность о сроках оплаты осуществленных поставок. 1.3.7. Порядок приемки результатов работы. Приемка результатов работы осуществляется в соответствии с планом приемки, утвержденным на кафедре и согласованным с руководителем практики. Этот план включает следующие пункты: ¨ Сдача технического задания, технического предложения, журнала по преддипломной практике и содержания расчетно-пояснительной записки после прохождения преддипломной практики. ¨ Сдача программы. ¨ Предзащита дипломного проекта. Предоставляются :расчетно-пояснительная записка, плакаты, доклад, рецензия, отзыв руководителя. ¨ Защита дипломного проекта. Предоставляются: дипломный проект с документами, замечания, допуск на защиту, карточка учета деканата, демонстрационный образец. 1.3.8. Документация, предъявляемая по окончанию работы. После окончания работы предоставляется следующая документация: ¨ Техническое задание; ¨ Расчетно-пояснительная записка; ¨ Описание применения; ¨ Руководство системного программиста; ¨ Руководство оператора; Также предоставляются: ¨ Плакаты; ¨ Доклад; ¨ Рецензия; ¨ Текст программы; Дискета с программным продуктом и сопроводительной документацией. 2. Моделирование. 2.1 Анализ представления моделей данных. Для эффективного функционирования разрабатываемой АСИС “Учет поставок” будет разработана СУБД [24]. Поэтому ниже рассмотрены логические и концептуальные модели данных. 2.2 Выбор логической модели данных. 2.2.1 Иерархическая модель данных. Иерархическая модель [6] данных представляет собой иерархию в виде дерева. Данная модель данных базируется на сегменте, который представляет собой совокупность полей, характеризующих данный сегмент. Сегменты различаются по типу, а каждый тип характеризуется фиксированной длиной и конкретным разбиением на поля данных. Два связанных сегмента, расположенных на смежных уровнях называются исходным (более высокого уровня) и порожденным (более низкого). Иерархическая запись – система взаимосвязанных сегментов, в которой каждый порожденный сегмент представлен столько раз, сколько необходимо для полного раскрытия данного сегмента. В иерархической структуре есть сегмент, который не имеет исходного и называется головным или корневым. В этом сегменте обычно располагается идентификатор объекта, свойства которого раскрываются в сегментах второго и более низких уровней иерархии. Для реализации данной модели на физическом уровне используется ряд стандартных методов размещения данных на запоминающих устройствах, которые могут размещать сегменты следующими иерархическими способами доступа: последовательный, индексно-последовательный, прямой, индексно-прямой. В соответствии со способами размещения сегментов устанавливается порядок доступа к ним. Установленный порядок доступа к сегментам обуславливает процедурность языка запросов и требует от пользователя знания путей доступа к данным, проходящим по ветвям дерева иерархической записи. Что является одним из недостатков данной модели. В качестве других недостатков можно отметить следующие: ¨ Сложность реализации “многие ко многим”, требующая избыточности данных на физическом уровне, что приведет к нежелательному и не оправданному увеличению БД; ¨ требование повышенной корректности к операции удаления, поскольку удаление исходного сегмента влечет за собой удаление порожденных; ¨ доступ к любому порожденному сегменту возможен только через исходный, что увеличивает время ответа а запрос к БД. В связи с тем, что иерархическая модель обладает большим количеством недостатков она не будет применятся для моделирования разрабатываемой АСИС. 2.2.2 Сетевая модель данных. Сеть [5] – более общая структура в сравнении с иерархией. Узлами сети являются отдельные экземпляры записи. Узлы записи являются единицей доступа к БД. Поскольку отдельный узел может иметь несколько непосредственно старших узлов, так же, как и несколько непосредственно подчиненных, то данная структура обеспечивает прямое представление отношения “многие ко многим”. Для связи между записями-узлами существует связующая запись, все экземпляры которой помещаются в цепочку для связи двух экземпляров. Основной конструкцией сетевой модели данных является набор. Для каждого типа набора, определяемого в схеме, должен быть указан определенный тип записи владельца набора, а так же произвольное число типов записи членов набора. Каждый экземпляр набора состоит из одного экземпляра-владельца и одного или более экземпляров записей-членов. Каждый экземпляр записи-набора представляет иерархические связи между экземпляром записи-владельца и соответствующими экземплярами записей-членов. Это является следствием того ограничения, что ни один экземпляр записи-члена из набора на может принадлежать более, чем одному экземпляру набора. Способ, которым каждый экземпляр записи владельца связывается с соответствующими экземплярами записей-членов, определяется в схеме сети. Одним из способов организации таких связей является установление цепочки указателей, выходящих из экземпляра записи-владельца, проходящих через все экземпляры записей-членов и возвращающихся обратно к экземпляру записи-владельца, что обеспечивает высокую скорость обработки запросов. Главный недостаток сетевой модели заключается в сложности структур памяти. Пользователь должен знать, какие цепочки существуют и какие отсутствуют. В результате язык запросов процедурный и требует программистских навыков. 2.2.3 Реляционная модель данных. Реляционная модель – множественное отношение которое представляет собой подмножество декартова произведения списка доменов [27,20]. Домен – это множество значений, из которого извлекаются значения для данного атрибута. Другими словами в основе реляционной модели лежат простые таблицы, которые удовлетворяют определенным ограничениям, а потому могут рассматриваться как математические отношения. Строки таких таблиц называются кортежами, имена столбцов – атрибутами. Следует отметить, что все кортежи различны, а порядок столбцов произволен, чем упрощается процесс обработки кортежей. В отношении (таблице) выделяется несколько атрибутов, однозначно идентифицирующих кортежи и называемых ключами. Особенность реляционной модели заключается в том, что в отличии от сетевой и иерархической моделей реальные объекты и взаимосвязи между ними представляются в базе данных единообразно в виде нормализованных отношений [24]. Основной недостаток реляционной модели данных связывается с низкой производительностью реляционной СУБД. Но разработка современных СУБД таких как, ORACLE, InterBase, Acsses и др. позволило преодолеть и этот недостаток.
Достоинства реляционной модели можно разделить на две группы: 1) достоинства для пользователя: ¨ реляционная БД представляет собой набор таблиц с которыми пользователь привык работать; ¨ не нужно помнить пути доступа к данным и строить алгоритмы и процедуры обработки своего запроса;
¨ реляционные языки легки для изучения и освоения, в то время как языки общения с иерархической и сетевой моделями предназначены для программистов и мало пригодны для пользователей; 2) достоинства обработки данных реляционной БД: ¨ связность. Реляционное представление дает ясную картину взаимосвязей атрибутов из различных отношений; ¨ точность. Направленные связи в реляционной БД отсутствуют. Отношения по своей природе обладают более точным смыслом и поддаются манипулированию с использованием таких средств, как алгебра и исчисление отношений [5], обеспечивающих наглядность и гибкость модели данных; ¨ гибкость. Операции проекции и объединения [17] позволяют разрезать и склеивать отношения, так что программист может получать разнообразные файлы в нужной форме; ¨ секретность. Контроль секретности упрощается. Для каждого отношения имеется возможность задания правомерности доступа, засекреченные показатели можно выделить в отдельные отношения с проверкой прав доступа. ¨ Простота внедрения. Физическое размещение однородных (табличных) файлов намного проще, чем размещение иерархических и сетевых структур. ¨ Независимость данных. БД должна допускать возможность расширения, т.е. добавления новых атрибутов и отношений. Вывод: поскольку среди перечисленных логических моделей данных реляционная обладает значительными преимуществами и малыми недостатками, то она и будет взята в основу для построения СУБД. 2.3 Выбор концептуальной модели. Для выбора концептуальной модели данных рассмотрим три их разновидности: ¨ Семантическая модель; ¨ Фреймы; ¨ Модель “сущность-связь”. Семантическая модель основывается на построении семантической сети. Под семантической сетью понимают ориентированный граф, состоящий из помеченных вершин и дуг и задающий объекты и отношения предметной области. Семантические сети обладают рядом достоинств, а именно: ¨ Описание объектов предметной области происходит естественным языком; ¨ Все записи, поступающие в БД накапливаются в относительно однородной структуре. Но несмотря на эти преимущества, семантическая модель данных обладает рядом недостатков, один из которых и наиболее существенный, заключается в том, что построение реляционной модели данных на основе семантических сетей затруднено. Фреймы выражаются структурами данных с привязанными процедурами обработки этих данных. Фреймы могут быть следующих видов: событийные, характеристики, логические предикаты. Использование фреймовой модели так же нецелесообразно, поскольку данная модель не отражает типы связей [14] в реляционной модели данных. Модель “сущность-связь” описывается в терминах сущность, связь, значение. Сущность – понятие которое может быть идентифицировано. Связь – соединение сущностей. Для представления связей и сущностей введен специальный метод: ER-диаграма [27]. Различаются сущности трех основных классов: стержневые, ассоциативные и характеристические. Стержневая сущность – это независимая сущность (ей свойственно независимое существование). Ассоциативная сущность или ассоциация рассматривается как связь между двумя или более сущностями типа "многие -ко- многим" или подобные им. Характеристическая сущность (или характеристика) представляет собой сущность, единственная цель которой, в рамках рассматриваемой предметной области, состоит в описании или уточнении некоторой другой сущности. ER-диаграма – графическое представление взаимосвязей сущностей. Каждое множество сущностей представляется прямоугольником, а множество связей – ромбом. Связи могут быть трех типов: “один к одному”, “один ко многим”, “многие ко многим”. данные типы связи присущи реляционной модели, как и сущности, которым в реляционной модели соответствуют таблицы. Вывод: в связи с тем, что модель “сущность-связь” наиболее близка по принципам организации к реляционной модели и реализация последней на основе первой наиболее удобна, то в качестве концептуальной модели выбрана модель “сущность-связь”. 2.4 Процесс моделирования. 2.4.1 Выделение сущностей. Сущность “поставщик” является стержневой сущностью разрабатываемой модели. С поставщиком заключается договор, на основании которого ведется вся остальная деятельность предприятии по поставкам, отправление заявки поставщикам, получение от них счета-фактуры, отправление заказа на поставку, получение товара, оплата поставки. В качестве ключа для данной сущности вводится атрибут № Поставщика. Все сущности , их атрибуты и ключи представлены в табл. 2.1. Таблица 2.1 Название сущности Атрибут Ключ Договор №Договора, дата договора, сумма договора, срок действия. №Договора Поставщик №Поставщика, наименование поставщика, адрес, телефон. №Поставщика Ассортимент товаров №Товара, наименование товара. №Товара Заявка №Заявки, ассортимент заявки, номер договора, дата заявки. №Заявки Заказ №Заказа, №Договора, ассортимент заказа, дата заказа, номер счета. №Заказа Счет-фактура №Счета, ассортимент счета, цена за единицу товара, сумма счета. №Счета 2.4.2. Выделение связей между сущностями Выделение связей между сущностями осуществляется на основании анализа предметной области. Все выделенные связи представлены на рис.2.1

Рис 2.1. Связи между сущностями 2.5 Построение логической модели. Выполнив анализ сущностей и связей меду ними построим логическую модель, в виде отношений (таблица 2.2) Таблица 2.2 Название сущности Атрибут Ключ Договор №Договора, дата договора, сумма договора, срок действия. №Договора Поставщик №Поставщика, наименование поставщика, адрес, телефон. №Поставщика Ассортимент товаров №Товара, наименование товара. №Товара Заявка №Заявки, номер договора, дата заявки. №Заявки Заявка №Заявки, №товара, количество. №Заявки, №Товара Ассортимент заявки №Заказа, №Договора, дата заказа, номер счета. №Заказа Ассортимент заказа №Заказа, №Заявки, №товара. №Заказа, №Заявки, №товара. Счет-фактура №Счета, сумма счета. №Счета Цены поставщика №Счета, №Заявки, №Товара. №Счета, №Заявки, №Товара. Для построения логической модели данных использовалось case - средство [17] ER-Win, которое позволяет проектировать реляционные модели данных как на физическом уровне (ER-диаграмы), так и на физическом (проектирование таблиц БД). Логическая модель данных представлена в виде ER-диаграмы на рис. 2.2. Рис 2.2 ER-диаграмма модели данных АСИС “Учет поставок” 3. Проектирование алгоритмов справочно-информационной системы учета и контроля поставок на предприятие. Алгоритмизация в самом общем виде может быть определена как процесс направленного действия проектировщика (группы проектировщиков), необходимый для выработки алгоритмов, достаточных для реализации создаваемого объекта (системы), удовлетворяющего заданным требованиям [19]. Завершающим этапом алгоритмизации является выпуск набора алгоритмов, отображающий решения, принятые проектировщиком, в форме, необходимой для производства объекта (системы). При проектировании системы я использовал три класса алгоритмов: ¨ Алгоритмы, связанные с проектированием АСИС; ¨ Алгоритмы реляционной алгебры, необходимые для работы с БД; ¨ Алгоритмы расчета необходимых показателей (вычисление задолженности предприятия по оплате поставок, определение оптимального счета-фактуры). 3.1 Выбор метода проектирования АСИС. Метод — это последовательный процесс создания моделей, которые описывают вполне определёнными средствами различные стороны разрабатываемой программной системы [18]. Методы важны по нескольким причинам. Во-первых , они упорядочивают процесс создания сложных программных систем. Во-вторых , они позволяют менеджерам в процессе разработки оценить степень продвижения и риск. Обычно методы проектирования делятся на три основные группы; · Метод проектирования сверху вниз; · Метод потоков данных; · Объектно-ориентированное проектирование. Для структурного проектирования характерна алгоритмическая декомпозиция. Следует отметить , что большинство программ написано в соответствии с этим методом. Тем не менее структурный подход не позволяет выделить абстракции и обеспечить ограничение доступа к данным; он также не предоставляет достаточных средств для организации параллелизма. Структурный метод не может обеспечить создание предельно сложных систем , и он, как правило, неэффективен в объектных и объектно-ориентированных языках программирования. Поэтому данный метод не использовался для проектирования АСИС “Учет поставок”. В методе потоков данных программная система рассматривается как преобразователь входных потоков в выходные. Метод потоков данных с успехом применялся при решении ряда сложных задач, в частности , в системах информационного обеспечения, где существуют прямые связи между входными и выходными потоками системы и где не требуется уделять особого внимания быстродействию. Но поскольку одним из основных требований предъявляемых к проектируемой АСИС является увеличение скорости автоматизации учета поставок и уменьшение временных затрат на оформление поставок на предприятии, то применение данного метода также нецелесообразно для проектирования АСИС. Объектно-ориентированное проектирование (object-oriented design, OOD)—это подход в основе которого лежит представление о том , что программную систему нужно проектировать как совокупность взаимодействующих друг с другом объектов, рассматривая каждый объект как экземпляр определённого класса, причём классы образуют иерархию. Объектно-ориентированный подход отражает топологию новейших языков высокого уровня , таких как Object Pascal, C++, Smalltalk [23] и др. Модели, для проектирования которой используется вышеназванный подход проектирования присущи четыре главных элемента:
¨ Абстрагирование; ¨ Инкапсуляция; ¨ Модульность; ¨ Иерархия. Абстрагирование позволяет выделить существенные характеристики проектируемого объекта, отличающие его от других объектов;
Инкапсуляция – процесс отделения друг от друга элементов объекта, определяющих его устройство и поведение. Она позволяет изолировать контрактные обязательства абстракции от их реализации. Модульность – свойство системы, которая была разложена на внутренне связные, но слабо связанные между собой модули. Иерархия – упорядочивание абстракций, расположение их по уровням. Абстракция и инкапсуляция дополняют друг друга. Абстрагирование направлено на наблюдение поведения объекта извне, а инкапсуляция определяет четкие границы между различными абстракциями, т.е. наблюдение за поведением объекта изнутри. Использование этих элементов проектирования и позволяет значительно увеличить производительность любой проектируемой системы. Таким образом, для проектирования АСИС используется объектно-ориентированный подход. 3.2. Анализ алгоритмов работы с базой данных Система управления разработанной БД использует реляционный подход для построения базы данных [20]. Подобные системы основаны на реляционной модели данных, которые используются для моделирования взаимосвязей между объектами реального мира и для хранения данных об этих объектах. Применение реляционной модели данных [27] обусловлено использованием реляционной алгебры и соответствующих алгоритмов и операций для выполнения действий над данными. Использование алгоритмов реляционной алгебры [20] позволяет обеспечить высокую производительность работы с базой данных. Основные операции реляционной алгебры были впервые предложены Коддом [26]. Он доказал, что запросы, формулируемые с помощью языка исчисления могут быть сформулированы в языках реляционной алгебры и наоборот [18], т.е запросы представленные с помощью языка реляционной алгебры могут быть использованы для выполнения запросов к разработанной БД. Ниже приведен ряд запросов к БД: SELECT nomer_dogovora, postav.nomer_postav, dogovor.nomer_postav, naimen_post FROM postav, dogovor WHERE postav.nomer_postav=dogovor.nomer_postav SELECT select nomer_zajavki, zajavka.nomer_dogovora, dogovor.nomer_dogovora, naimen_post,postav.nomer_postav, dogovor.nomer_postav FROM from zajavka,dogovor,postav WHERE (zajavka.nomer_dogovora=dogovor.nomer_dogovora) AND (postav.nomer_postav=dogovor.nomer_postav) SELECT nomer_zakaza, zakaz.nomer_dogovora, dogovor.nomer_dogovora, naimen_post,postav.nomer_postav, dogovor.nomer_postav FROM zakaz, dogovor, postav WHERE (zakaz.nomer_dogovora=dogovor.nomer_dogovora) AND (postav.nomer_postav=dogovor.nomer_postav) Рассмотрим четыре операции над отношениями [20]: ¨ Селекция; ¨ Проекция; ¨ Теоретико-множественное объединение; ¨ Соединение. Селекция (selected_on – подвергнутые селекции по) уменьшает количество строк в таблице, и ее можно представить как результат разрезания таблицы по горизонтали и удаления ненужных кортежей. Формально селекция записывается так: R selected_on [] {синтаксис языка запросов (SQL)} Здесь - это логическое выражение, которое может содержать сравнения значений одних атрибутов со значениями других в том же кортеже или с константами. В результате сохраняются только строки, удовлетворяющие . Операция селекции соответствует программам, которые выбирают записи из файлов и печатают эти записи. Однако условия отбора могут относится только к отдельно взятым записям. Например, невозможно выбрать запись, исходя из того, что значение какого-либо ее поля равно или больше, чем значение этого поля в предидущей записи. В действительности почти невозможно смоделировать поведение автомата с конечным числом состояний, который изменяет свое состояние для каждой записи, изменяя тем самым критерии отбора для следующей записи. Проекция (projected_to – спроецированное на) уменьшает количество столбцов в таблице; данную операцию можно представить себе как разрезание по вертикали название операции имеет своим источником понятие проекции множества точек N-мерного пространства в пространство с меньшим количеством измерений. Например, в результате проекции множества точек плоскости (Х,У) на ось Х получается множество точек, расположенных на этой оси. К сожалению, значения проекций некоторых “точек” могут совпадать; это произойдет в том случае, когда проекция удалит столбец, входящий в ключ, так что оставшиеся части двух “укороченных” кортежей могут быть идентичными. Тогда придется удалить дубликаты и тем самым уменьшить количество строк, т.е. размер БД. Если хотя бы один из возможных ключей при выполнении проекции останется незатронутым, то дубликатов не будет. Формально проекция записывается следующим образом: R projected_to {, } Где список означает имена сохраняемых столбцов. Операция проекции соответствует программе отбора несколько иного рода, чем операция селекции, а именно, она печатает определенные поля из каждой записи. Удаление дубликатов обычно достигается в результате сортировки записей по требуемым полям, после чего записи пропускаются до тех пор, пока не изменится значение поля. На практике при одном просмотре файла операция проекции обычно происходит с операцией селекции. Теоретико-множественное объединение (union) имеет два операнда; она берет строки двух таблиц и размещает их друг за другом, формируя одну длинную таблицу. Это возможно лишь в том случае, когда обе таблицы имеют один и тот же тип, т.е. имеют совпадающие названия (имена) и типы столбцов. Такие таблицы называют “совместимыми по объединению”. Все дубликаты строк должны быть удалены из отношения-результата. Данная операция аналогична объединению множеств в алгебре, но она является дополнительной по отношению к ограничению, так как имеется возможность восстановить отношение путем объединения двух дополняющих друг друга результатов операции селекции. Операция теоретико-множественного отношения соответствует известной операции “слияния” файлов. Если известно, что файлы не пересекаются, и если порядок записей не играет роли, то достаточно скопировать один файл в конце другого. Однако, как правило, файлы поддерживаются в порядке первичных ключей, и тогда используются простые алгоритмы слияния., считывающие поочередно записи из каждого файла в зависимости от того, в каком из файлов запись имеет ключ с меньшим значением полей, так что в новый файл записи также будут помещаться в порядке первичных ключей. Соединение (joined_to – соединение с) имеет два операнда; она определена для любых двух таблиц. Если эти две таблицы не имеют столбцов с совпадающими именами, то соединение ведет себя, как декартово произведение, соединяя каждую строку первой таблицы поочередно с каждой строкой второй таблицы. Если имена всех столбцов этих двух таблиц совпадают, то соединение ведет себя как теоретико-множественное пересечение, и создает таблицу, состоящую из тех строк, которые встречаются в каждой из рассматриваемых двух таблиц (такая таблица может быть и пустой, аналогично пустому множеству). Если у двух таблиц-операндов совпадают лишь некоторые имена столбцов, то в результате соединения получается таблица, содержащая все имена столбцов первой таблицы, а также все те имена столбцов второй таблицы, которые не встретились в первой. Строки результата выбираются из первой таблицы, а дополнительные значения конкатенируются (присоединяются) из тех строк второй таблицы, у которых значения в общих столбцах совпадают. До некоторой степени соединения является дополнением проекции, если осуществить проекцию “исходного” отношения так, чтобы получился набор отношений, каждое из которых сохраняет первичный ключ исходного, то соединение этого отношения восстановит исходное при дополнительном условии, что каждый столбец исходного отношения встречается хотя бы в одной из проекций.
При формулировании запросов операция соединения является решающей, если в запросе используется более одного отношения. Как правило, для формирования запроса используется соединение нескольких таблиц, а затем селекция требуемых строк, и , наконец, проекция на требуемые столбцы при печати.
Операция соединения больше всего соответствует операции “селективной выборки”, при выполнении которой список ключей представлен в виде записей в файле транзакций [19], и требуется выбрать или записать в выходной файл соответствующие записи из основного файла. Ключи в файле транзакций могут совпадать, например, с посторонним ключом в основном файле или же с частью первичного ключа, и в этих случаях для каждой записи в файле транзакций может быть выбрано несколько записей из основного файла. Таким образом, используется соединение как обобщенное пересечение [20]. Алгоритмы, которые выполняют вышеперечисленные операции, реализуются на уровне системы управления базой данных. Их содержание формируется на основе определений этих операций. Для их реализации используются или стандартные функции языка программирования , или формируется SQL-запрос. Более подробно реализация будет рассмотрена в следующей главе. 3.3. Проектирование алгоритмов расчёта задолженности по оплате поставок и определения оптимальной заявки. Данные алгоритмы представлены в виде блок-схем на рис 3.1 и рис 3.2 соответственно: нет да нет да нет нет да да нет да нет да нет да нет да 4. Выбор средств для разработки АСИС, описание структуры АСИС. 4.1 Выбор аппаратных средств.
При выборе аппаратных средств для разработки АСИС наибольшую роль играет фактор быстродействия работы ПЭВМ. Поскольку именно от него зависит время разработки ПО, а соответственно затрат на разработку и его себестоимости. Скорость функционирования ПЭВМ в основном определяется следующими параметрами:
¨ Объемом оперативной памяти (ОП); ¨ Быстродействием процессора; ¨ Объемом видеопамяти (ВП). Исходя из требований предъявляемых к используемым программным средствам разработки (Delpi 3.0 InterBase 4.2) минимальное значение вышеперечисленных параметров составляет ОП – 12 Мб, процессор – на базе Intel 486, ВП – 1 Мб. При минимальных значениях параметров функцмонирование разработанной АСИС малоэффективно, поэтому рекомендуемым является компьютер со следующими значениями параметров: ¨ Процессор – intel 586-100 МГц; ¨ Оперативная памть – 16 Мб; ¨ Видеопамять – 1 Мб; 4.2. Анализ и выбор программных средств разработки АСИС. Современные средства разработки ПО характеризуются большим разнообразием критериев, используюя которые разработчик имеет возможность автоматизировать процесс разработки приложений. Так, в настоящее время инструментальные средства позволяют: ¨ создавать интерфейс испльзуя стандартные компоненты; ¨ передавать управление различным процессам, в зависимости от состояния системы; ¨ создавать оболочки для баз данных, как и сами базы данных; ¨ разрабатывать более надежное ПО, путем обработки исключительных ситуаций возникающих при некорректной работе ПО. Современные средства разработки характеризуются следующими параметрами: ¨ поддержка объектно-ориентированного стиля программирования; ¨ возможность использования CASE-технологий, как для проектирования разрабатываемой системы, так и для разработки моделей реляционных баз данных; ¨ использование визуальных компонент для наглядного проектирования интерфейса; ¨ поддержка БД; ¨ возможность использования алгоритмов реляционной алгебры для управления реляционными базами данных; ¨ возможность синхронизации составных частей проекта (предоставляется при разработке больших программных комплексов). Вышеперечисленными свойствами обладают языки программирования, например: Delphi, Visual C++, Borland С++ Biulder, Visual FoxPro и другие. Каждое из этих средств содержит весь спектр современного инструментария, который был перечислен ранее. Главное отличие состоит в области использования рассматриваемых средств. Так Visual C++ обычно используется при разработке приложений предназначенных для работы с ОС Windows, использующих основные свойства ОС [1], а так же выполняющих большое количество вычислений.[12] Одним из недостатков данного средства разработки приложений является высокое требование к аппаратным ресурсам при разработке программного обеспечения, недостаточно высокая скорость компиляции программного кода и при реализации конечного продукта (ПО), используя этот продукт необходимо большее дисковое пространство, чем при создании аналогичного ПО другими средствами разработки. Borland С++ Biulder по своим недостаткам аналогичен Visual C++, но обладает еще одним – разработка баз данных на базе языка SQL и их поддержка ограничена. Система разработки Visual FoxPro предъявляет наименьшие требования к системным ресурсам, но ее применение ограничено неудобством в визуальном создании интерфейса разрабатываемого приложения. Недостатком Delphi состоит в том, что при его использовании нет достаточного доступа к функциям ОС, но данный недостаток несущественен, поскольку разрабатываемое приложение ориентировано на поддержку БД, а не на работу с ОС. Немалое значение при выборе Delphi в качестве средства для разработки АСИС играет возможность использования большого количества встроенных визуальных компонент, как для разработки интерфейса, так и для создания СУБД. При создании программного продукта АСИС “Учет поставок” главным критерием выбора программных средств разработки являлись: ¨ скорость разработки приложений; ¨ возможность быстрого внесения изменений в программу; ¨ возможность редактирования и просмотра БД, используя средства разработки. Как дополнение к перечисленному, можно указать, что время разработки зависит от: поддержки выбранным инструментарием ОС, аппаратной поддержки, необходимой для их оптимального функционирования; наличия предварительного опыта у разработчиков в использования соответствующих программных средств. Обеспечить минимальное время разработки можно только при выполнении этих условий. Исходя из приведенных требований, выделим следующие характеристики средств разработки программного обеспечения: ¨ Наличие опыта разработки с использованием данного программного продукта; ¨ Требования по ресурсам; ¨ Поддержка операционной системы; ¨ Наглядность разработки интерфейса; ¨ Предоставляемые возможности работы с базами данных; ¨ Доступность; ¨ Скорость работы разработанного программного обеспечения; ¨ Обработка исключительных ситуаций; ¨ Время создания разработанного программного обеспечения; ¨ Удобство эксплуатации; Для вышеперечисленных средств для разработки АСИС воспользуемся методом вариантных обоснований. Этот метод предназначен для выбора наилучшего варианта из нескольких предложенных и состоит из следующих этапов: ¨ Определение критериев, по которым будет произведено сравнение и степени их важности. ¨ Каждый вариант оценивается по полученному перечню критериев. Получается численное значение – оценка. ¨ Нахождение общего количества баллов для каждого из вариантов ( можно учитывать важность критериев ). ¨ Лучшим считается вариант, который набрал максимальное количество баллов. Для решения поставленной задачи будем использовать перечень характеристик, приведенный выше. Результаты приведены в таблице 4.1 Таблица 4.1 Средство разработки Характеристика средств разработки Delpi Visual C++ Borland C++ Buielder Visual FoxPro Наличие опыта разработки с использованием данного программного продукта; 8 6 4 4 Требования по ресурсам; 7 6 6 5 Поддержка операционной системы; 8 8 8 7 Наглядность разработки интерфейса; 9 7 8 5 Предоставляемые возможности работы с базами данных; 8 6 4 7 Скорость работы разработанного программного обеспечения; 6 7 8 7 Обработка исключительных ситуаций; 8 8 8 6 Время создания разработанного программного обеспечения; 9 6 5 7 Удобство эксплуатации; 7 8 8 7 Всего: 70 62 60 56 Вывод: В результате выполненного анализа инструментальных средств выявили, что в качестве средства разработки АСИС будет использован Delphi, как наиболее оптимальное средство разработки с точки зрения разработчика. Используя Delphi можно создавать приложения для MS Windows95/98/NT с минимальными затратами времени т.к. в её основе лежит концепция быстрого создания приложений (RAD).
Основные сведения о Delphi [15,16,17]: Базируется на расширении языка Pascal – Object Pascal. Интегрированная среда разработки приложений – позволяет создавать, компилировать, тестировать и редактировать проект или группу проектов в единой среде программирования; Визуальная технология разработки программ – позволяет быстро создавать приложения путём размещения в форме стандартных компонентов. При этом соответствующий код программы автоматически генерируется Delphi. Такая технология освобождает разработчика от рутинной работы по созданию пользовательского интерфейса и позволяет уделить больше внимания внутренней организации данных и обработке данных. Технология Two Ways Tools делает более эффективной работу с компонентами. При изменении программного кода в окне редактора Delphi соответствующим образом изменяет и сами компоненты. С другой стороны, при изменении свойств компонентов в инспекторе редактора объектов (Object Inspector) они немедленно отражаются в окне редактора кода. Библиотека компонентов содержит множество стандартных компонентов, которые можно использовать при создании приложений. Сюда относятся элементы управления в стиле Windows95 и IE 4.0, а также шаблоны для форм и экспертов. Поддержка баз данных в среде Delphi осуществляется двояко. С одной стороны в ней широко используются компоненты, предназначенные для работы с базами данных. С их помощью можно создавать простые приложения, предназначенные для обработки данных, и приложения типа клиент/сервер. Особенностью этих компонентов является то, что во время создания приложения Delphi отображает результаты обработки данных, и позволяет проанализировать различные ситуации, которые могут сложиться в процессе работы программы. С другой стороны поддержка баз данных в Delphi осуществляется с помощью набора драйверов соединений с SQL-северами Borland SQL Links for Windows, которые позволяют интегрированному в Delphi ядру процессора баз данных Borland, (BDE) Borland Database Engine, получать доступ к локальным базам данных Paradox, dBASE, Access, FoxPro, а также SQL-северам InterBase, Informix, Oracle, Sybase, DB2, Microsoft SQL 32-битовый компилятор Delphi генерирует исполняемые EXE-файлы. При этом существует возможность генерировать либо простые EXE-файлы, либо сложные приложения, требующие подключения DLL-библиотек. Delphi - это первый инструмент в котором быстрое проектирование сочетается с использованием оптимизирующего компилятора [3]. Кроме того, в Delphi может быть использована технология масштабирования баз данных, являющаяся самой мощной и сложной технологией программирования, которая когда-либо использовалась для персональных компьютеров. В отличии от большинства других инструментов, предназначенных для быстрой разработки приложений, Delphi является расширяемым инструментом. Ниже приведен краткий список особенностей, обеспечивающих расширяемость Delphi: Непосредственный доступ к интерфейсу приложений API; Встроенный Ассемблер; обработка строк, написанных на Ассемблере вставленных в текст программ Delphi; Возможность создания пользовательских объектов VCL и OCX; Возможность создания DLL-библиотек и других "вторичных" объектов среды Windows; Объектная ориентация - возможность создавать новые классы, наследующие свойства существующих классов, либо, начав с нуля, строить свои собственные. Одним из основных критериев, при выборе инструмента разработки приложений баз данных является масштабируемость возможность работать с данными в различных платформах. Масштабируемость в Delphi достигается благодаря следующим свойствам [ ]: Поддержка как локальных таблиц, так и находящихся на удаленных серверах баз данных; Поддержка сложных запросов и доступ из одного приложения ко многим Системам Управления Базами Данных (СУБД), построенным на различных платформах; Свободное перемещение приложения из одной СУБД в другую, осуществляемое посредством ядра Borland Database Engine, которое организует доступ к базам данных, невзирая на различия в платформах; Наличие собственных быстрых драйверов для основных платформ типа клиент/сервер; Полная поддержка ODBC. Delphi, как СУБД, полностью ориентирован на реляционную модель данных и имеет встроенный язык запросов к базам данных SQL (Structured Query Language). 4.3. Описание общей структуры АСИС. Схема функционирования автоматизированной системы представлена на рис.4.1. 4.4. Описание программы. 4.4.1. Описание интерфейса. После запуска файла postavki.exe на исполнение на мониторе появляется главное меню (рис 4.1): Рис 4.1 Главное меню АСИС Для начала работы с программой необходимо соединиться с базой данных, для чего щелкнуть по команде меню соединится с БД. Если на компьютере пользователя установлен InterBase Local Server и создана база данных, то появится запрос на подтверждение права доступа к БД (рис 4.2): Рис 4.2 Окно ввода пароля Пароль доступа Khai. В случае, если соединение прошло успешно, то пользователь допускается к работе с АСИС. 4.4.2 Работа с режимами АСИС Рабочее окно АСИС выглядит следующим образом (рис 4.3): Рис 4.3 Рабочая область АСИС Ниже описана работа с АСИС. Работа с договорами Работа с договорами включает в себя: - Работа с поставщиками; - Работа с договорами; - Работа с товарами; - Работа с заключенными договорами; - Работа с ассортиментом договоров; Договор заключается предприятием-заказчиком с предприятием-поставщиком на поставку определенного вида и ассортимента продукции. С одним поставщиком может быть заключено несколько договоров. В качестве атрибутов договора являются следующие поля: номер договора, код поставщика, дата договора, сумма договора, срок действия договора. Все атрибуты, кроме срока действия договора являются обязательными для заполнения. На основании договора производится дальнейшая деятельность по поставкам на предприятии. Она заключается в:
- Работа с заявками; - Работа со счетами; - Работа с заказами. Для автоматизации использования АСИС “Учет поставок” реализована возможность печати бланков документов договора, заявки, заказа. Добавление нового договора осуществляется путем выбора соответствующей закладки и вводе текста в поля-атрибуты таблицы. Добавление при условии, что для добавляемого договора известен поставщик.
Редактирование происходит при нажатии клавиши Enter на выбранной записи. Происходит автоматическое изменение всех полей других таблиц связанных с номером редактируемого договора. Это изменение необходимо для поддержания ссылочной целостности в БД. Для удаления определенного договора необходимо два раза щелкнуть правой кнопкой мыши на удаляемом договоре. Автоматически удалятся все записи связанные с удаляемым договором (заявки, счета-фактуры, заказы). Работа с поставщиками Работа с поставщиками состоит в добавлении нового поставщика, его атрибутов, удалении поставщика, редактировании атрибутов поставщика: код поставщика (для каждого поставщика код уникален), наименование поставщика, адрес и телефон поставщика. Все атрибуты, кроме телефона являются обязательными для заполнения, в случае их незаполнения возникает ошибка. Добавление поставщика производится следующим образом: пользователь выбирает соответствующую таблицу и заполняет атрибуты поставщика. Для редактирования таблицы “поставщики” нужно выбрать запись для редактирования , нажать клавишу Enter и изменить необходимую информацию. Измененные атрибуты поставщика автоматически изменяются в других таблицах. Удаление записи “поставщик” происходит путем двойного щелчка мышью на удаляемой записи. При этом требуется запрос на подтверждение удаления записи. Работа с товарами Таблица “товары” представляет собой справочник товаров, которые поставляются на предприятие. Атрибуты этой таблицы содержат уникальный код для каждого товара и наименование товара. При заключении каждого нового договора необходимо заполнить таблицу ассортимент договора. Добавление новой записи в таблицу осуществляется путем ввода информации о товаре в строки таблицы товары. Редактирование – нажатием клавиши Enter на редактируемой строке и изменении информации. Удаление – двойным щелчком мыши на удаляемой строке. Работа с заключенными договорами Работа с данной таблицей для пользователя ограничена, поскольку данными для ее заполнения служат ранее заполненные таблицы (договор, поставщик). Работа с ассортиментом договоров Работа с ассортиментом договоров заключается в добавлении, редактировании и удалении наименования товара или товаров, которые поставщик обязуется поставить заказчику на основании перечня поставляемых товаров, указываемом в заключенном договоре. Вышеуказанные операции проводятся аналогично операциям в работе с договорами. Работа с заявками Работа с заявками представляет собой работу с тремя закладками: - Заявка; - Ассортимент заявки; - Все заявки. Закладка “заявка” содержит таблицу с данными о заявках, которые сделал заказчик поставщику по одному из заключенных договоров. Таблица заявка содержит атрибуты: номер заявки, номер договора, дата заявки. Заполнение всех атрибутов является обязательным. Номер договора один из заключенных, в противном случае возникает ошибка. Пользователь имеет возможность добавлять, редактировать и удалять записи. Добавить запись можно в случае когда таблица активна, т.е. пользователь осуществляет работу с ней. Таблица автоматически переводится в режим добавления записей при нажатии пользователем клавиши на пустой строке, либо нажатием клавиши Insert. Для редактирования необходимо выбрать запись для редактирования и, нажав клавишу Enter произвести редактирование необходимого поля записи. Удаление происходит путем двойного щелчка мышью на выбранной для удаления записи. Закладка “ассортимент товаров” содержит таблицу с данными о сделанной заявке, а именно: номер заявки, номер товара, количество заказанной продукции в принятых единицах измерения (шт., кг., л., и т.п.). все атрибуты являются обязательными к заполнению. Кроме того, номер товара (код товара) может быть выбран только из номеров товара, которые указаны в справочнике товаров. Удаление, добавление и редактирование записей происходит аналогично закладке заявка. Работа со счетами Для работа со счетами предлагается закладка “счет-фактура”, которая содержит таблицу счета и поле для определения оптимального счета. Таблица “счета” включает атрибуты: номер счета, номер заявки, номер договора, сумма счета. Все атрибуты обязательны для заполнения. Ассортимент счета соответствует ассортименту заявки. На закладку выводится информация (либо предоставляется для ввода) только по одному из заключенных договоров, номер которого выбран в таблице ассортимент договоров. Работа с заказами Для работы с заказами предлагается две закладки: - Заказ; - Все заказы. В закладку “заказ” включены таблица “заказ” с атрибутами: номер заказа, номер договора, номер счета, получено, оплачено, и поле для определения задолженности предприятия по оплате выполненных поставок. Пользователю предоставляется возможность добавления, редактирования и удаления записей. Все операции с записями осуществляются для определенного договора, указанного в закладке ассортимент договора. Все атрибуты таблицы обязательны к заполнению. Заполнение полей таблицы оплачено и получено можно осуществлять с выпадающего списка с двумя строками (да, нет). В случае если долг по оплате поставок отсутствует, то поле “долг” принимает значение “нет”. Закладка “все заказы” представляет собой таблицу с перечнем всех заказов сделанных по всем заключенным договорам. Что-либо в ней изменять пользователь не имеет возможности. Печать. Закладка “печать” используется для печати бланков договоров, заявок, заказов. Для выбора документа, который необходимо напечатать следует выбрать соответствующий флажок. 5. Испытания программного продукта. Надежность программного обеспечения (ПО) есть вероятность его работы без отказов в течении определенного периода времени, рассчитанная с учетом стоимости для пользователя каждого отказа [9] . Надежность программного обеспечения как определяющий элемент его качества закладывается на этапе разработки и проектирования, реализуется на этапе реализации ПО [11]. Выбор критериев, которыми должна определятся надежность ПО, отыскание оптимальной по отношению к этим критериям его структуры, выбор режима работы ПО – вот далеко не полный перечень тех проблем, которые должны быть решены на этапе создания и реализации ПО до его эксплуатации. Поэтому для обеспечения надежности ПО зачастую используют такие термины, как доказательство, тестирование, отладка, контроль и испытание, которые часто используются как синонимы, поэтому приведём эти определения: ¨ Тестирование (testing) - процесс выполнения программы или части программы, с намерением или целью найти ошибки;
¨ Доказательство (proof) - попытка найти ошибки в программе безотносительно к внешней для программы среде. Большинство методов доказательства предполагает формулировку утверждений о поведении программы и затем вывод и доказательство математических теорем о правильности программы.
¨ Контроль (verification) - попытка найти ошибки в тестовой, или моделируемой среде; ¨ Испытание (validation) - попытка найти ошибки, выполняя программу в заданной реальной среде; ¨ Аттестация (certification) - авторитетное подтверждение правильности программы. При тестировании с целью аттестации выполняется сравнение с некоторыми заранее определённым стандартом; ¨ Отладка (debugging) не является разновидностью тестирования. Хотя “отладка” и “тестирование” часто используются как синонимы, под ними подразумеваются разные виды деятельности. Тестирование – деятельность, направленная на обнаружение ошибок; отладка направлена на установление точной природы известной ошибки. 5.1. Справочные документы. Испытания программного продукта производятся с использованием следующей справочной литературы: 1. ГОСТ Р28195-89 Оценка качества программных средств. 2. ISO/IEC 9126 : 1991 Information Technology Software Product Quality Characteristics. 3. Стандарты разработки ПО ESA PSS-05-0-1991. 5.2. Краткий обзор верификации . Верификация обозначает: ¨ действие по проверке, инспекции, тестированию, контролю процессов, определённых требованиями ANSI –78 ¨ процесс определения: удовлетворяет ли продукт данной фазе ЖЦ ПО требованиям, сформулированным на протяжение предыдущих фаз; ¨ формальное доказательство корректности программы. ¨ верификация необходима для обеспечения качественных характеристик продукта. Ряд определений, приведённый ниже, охватывает вторую сторону тестирования: типы ошибок, которые предполагается обнаружить, и стандарты, с которыми сопоставляются тестируемые программы. ¨ Тестирование модуля или автономное тестирование – контроль отдельного программного модуля, обычно в изолированной среде (т.е. изолированно от всех остальных модулей). Тестирование модуля иногда также включает математическое доказательство. ¨ Тестирование сопряжений – контроль сопряжений между частями системы (модулями, компонентами подсистемами). ¨ Комплексное тестирование – контроль и/или испытание системы по отношению к исходным целям. Комплексное тестирование является процессом контроля, если оно выполняется в моделируемой среде, и процессом испытания, если выполняется в среде реальной, жизненной. ¨ Тестирование приемлемости – проверка соответствия программы требованиям пользователя. 5.3. Процессы верификации. Верификацию, тестирование и испытания разрабатываемой системы будем производить в соответствии со стандартами ES-PSS-05. Процесс верификации включает в себя: ¨ технические проверки, сквозные контроли и инспекции ПО; ¨ проверки того, что требования к ПО соответствуют требованиям заказчика; ¨ проверки того, что требования к проекту являются соответствующими требованиям ПО; ¨ автономное тестирование; ¨ системное тестирование; ¨ приёмочное тестирование; ¨ ревизии. Исходя из выше изложенного, были проведены тестовые испытания программного продукта. 5.3.1. Сквозной контроль. Эффективный прием оценки детальных внешних спецификаций – подготовить тесты и затем воспользоваться детальными внешними спецификациями для имитации поведения системы. Этот процесс часто называют сквозным контролем [10] или прослеживанием. Для проверки отдельных внешних функций должны быть выполнены следующие действия. Кто-то (не автор спецификаций) должен сначала построить “тесты на бумаге” для этой функции, т.е. список конкретных входных данных (допустимых и недопустимых). Вместе с автором спецификаций затем имитируют ввод этих данных в cистему, используя спецификации как описание поведения системы. Если оказывается, что спецификации описывают выходные данные или преобразование для какого-то набора входных данных недостаточно полно и правильно, это означает, что обнаружена ошибка. Важно отметить, что цель всякого такого сеанса сквозного контроля – обнаружить ошибки, но не исправлять их сразу. Используя данный прием тестирования, были протестированы запросы осуществляемые к базе данных (БД) созданной системы. Для этого на вход подавались различные запросы к БД (См. приложение B). В результате проведения теста было зафиксировано, что корректные запросы обрабатываются БД согласно предполагаемому результату, время обработки запроса отвечает указанному в ТЗ (не более 3 секунд при минимальной конфигурации, процессор Intel 586). При попытке осуществить некорректный запрос к БД не всегда выдаются сообщения об ошибках, либо не указано какие действия необходимо предпринять для правильной работы системы. 5.3.2. Трассировка требований к ПО и требований пользователя. Для осуществления проверки требований к ПО и требований пользователя на полноту (поиск всех пропущенных требований), т.е. удовлетворения всех требований пользователя в программном продукте, и отсутствия неоднозначности применяется матрица трассировки. Соответствие требований проверялось на ранних стадиях ЖЦ программного продукта. Используя матрицу трассировки было установлено полное соответствие между требованиями пользователя и требованиями к ПО, неоднозначности в требованиях обнаружены не были. (см. ТЗ “Матрица трассировки”). 5.3.3. Тестирование внешних функций. Цель теста внешней функции – найти расхождения между программой и её внешними спецификациями. Необходимым условием успешного тестирования функций является наличие чётких и точных внешних спецификаций. Если внешние спецификации неполны или неоднозначны, результаты тестирования не могут не быть такими же. Внешние спецификации обычно разбиваются на отдельные внешние функции (например, по типу входных сообщений или команд пользователя), и после тщательного изучения каждой функции строятся тесты. Тесты должны строиться для всех входных условий и вариантов, а также на границах всех областей допустимых значений на входе и области изменения на выходе. Тесты должны также проверять поведение программы у функциональных границ и в случаях и в случаях ввода недопустимых или непредусмотренных данных. Рассмотрим методологию проектирования тестов, основанную на функциональных диаграммах (cause-effect graphing). Тестирование функций – процесс контроля, поскольку оно обычно выполняется в моделируемой среде (в противоположность обстановке реальной). Другими словами, тестирование функций обычно выполняется для компонент системы прежде, чем она будет собрана воедино. Например, могут быть недоступны определённые устройства ввода-вывода, вследствие чего потребуется написать специальные программы для имитации их работы, могут отсутствовать или быть неполными отдельные компоненты программного обеспечения, что также потребует имитации или применения вспомогательных программ.
Метод функциональных диаграм [11], предлагает способ перевода спецификаций, написанных на естественном языке, на язык формальный. Это способствует проектированию высокорезультативных тестов, не страдающих избыточностью, и обнаруживающих случаи неполноты и неоднозначности во входных спецификациях. Метод предполагает анализ семантического содержания внешних спецификаций и перевод их на язык логических отношений между входными данными (ситуациями) и выходными данными и преобразованиями (эффектами), представленных в виде логической диаграммы (“и- или”-графа), называемой функциональной диаграммой.
Диаграмма снабжается примечаниями в виде синтаксических правил и ограничений внешней среды и затем преобразуется в таблицу решений с ограниченным входом. Каждый столбец таблицы соответствует будущему тесту. Последовательность применения метода: ¨ Первый шаг: разбить внешние спецификации на отдельные функции, комбинаторные свойства которых и должны тестироваться; ¨ Второй шаг: проанализировать спецификации в поисках всех явных и неявных ситуаций (условия на входе) и эффектов (действия на выходе). Лучше всего делать это, подчёркивая каждую ситуацию и каждый эффект, по мере того как они встречаются при чтении спецификаций. Все ситуации и эффекты нумеруются произвольным образом. ¨ Третий шаг: нарисовать функциональную диаграмму. Ситуации изображаются в виде вершин на левом краю листа бумаги, а эффекты – на правом. ¨ Четвёртый шаг: преобразовать диаграмму в таблицу решений с ограниченным выходом. Для этого нужно выбрать некоторый эффект и записать все комбинации ситуаций, которые его вызывают, затем выписать также состояния всех остальных эффектов при этих комбинациях ситуаций. 5.3.4. Тестирование модуля. Целью тестирования модуля является нахождение несоответствия между логикой и сопряжениями модуля, с одной стороны, и его внешними спецификациями (описанием функций, входных и выходных дынных, внешних эффектов), с другой стороны. Процесс проектирования тестов для модуля состоит из следующих четырех шагов: ¨ Руководствуясь внешними спецификациями модуля, были подготовлены тесты для каждой ситуации и каждой возможности, для каждой границы областей допустимых значений всех входных данных, областей изменения данных, для всех недопустимых условий. ¨ Был проверен текст программы, чтобы убедиться, что все условные переходы были выполнены в каждом направлении. (Текст программы определялся с использованием созданного логического анализатора). ¨ Для циклов модулей были проведены тесты, соответствующие пути без выполнения тела циклов, с его однократным выполнением и максимальным числом повторений. ¨ Был проверен текст программы на её чувствительность к отдельным особым значениям входных данных и были добавлены соответствующие тесты. Следует отметить, что компиляцию модуля также можно рассматривать как часть процесса тестирования, поскольку компилятор обнаруживает большинство синтаксических ошибок, а также некоторые семантические и логические ошибки. В результате реализации данного типа тестирования было зафиксировано, что все условные переходы выполняются в каждом направлении, не происходит “зацикливания” в модуле при граничных значениях индексов циклов, также как и не обнаружено сбоев в работе модуля при невыполнении тела какого-либо из циклов, система реагирует на граничные значения водимых данных корректно. 5.4.5. Комплексное тестирование. Комплексное тестирование – процесс поисков несоответствия системы ее исходным целям [11]. Это наиболее творческий из всех видов тестирования. Оно состоит из следующих шагов: ¨ Тестирование стрессов. Распространенный недостаток больших систем в том, что они функционируют как будто бы нормально при слабой или умеренной нагрузке, но выходят из строя при большой нагрузке и в стрессовых ситуациях реальной среды. Тестирование стрессов представляет попытки подвергнуть систему крайнему “давлению”. Для проведения тестов осуществлялось большое количество запросов к БД (20 запросов). В результате теста не было зафиксировано никаких отклонений в работе программы, но было отмечено определенное замедление работы БД с запросами. ¨ Тестирование объёма. В то время как при тестировании стрессов делается попытка подвергнуть систему серьёзным нагрузкам в короткий интервал времени, тестирование объема представляет собой попытку предъявить системе большие объёмы данных (максимальный объм базы данных, 2 Мб) в течение более длительного времени. Для проведения тестов создавалась БД как можно больших размеров, создавались очереди документов, выводимых на печать, использовались граничные значения числовых форматов. В результате теста также не было зафиксировано отклонений в работе программы, обработка запросов БД осуществлялась с незначительным замедлением. ¨ Тестирование конфигурации. Многие системы обеспечивают работу различных конфигураций аппаратуры и ПО. Число таких конфигураций часто слишком велико, но необходимо проверить хотя бы максимальную и минимальную конфигурации. Система была проверена со всеми аппаратными устройствами, с которыми она может осуществлять работу (гибкие накопители данных, принтеры). При работе с разными типами накопителей данных (НГМД, НЖМД) не было обнаружено ошибок, за исключением малой информативности ошибок возникающих при некорректной работе с НГМД. ¨ Тестирование защиты. Так как внимание к вопросам сохранения секретности в сегодняшнем автоматизированном обществе возрастает, к большинству систем предъявляются определенные требования по обеспечению защиты от несанкционированного доступа. Цель тестирования защиты – нарушить секретность в системе. В результате проведения теста было зафиксировано, что пользователь не имеющий доступа к системе проникнуть в нее не может. ¨ Тестирование производительности. Требования к производительности и эффективности (время ответа для различных нагрузок и различных конфигураций) – важная часть проектов систем. По сравнению с другими типами комплексного тестирования системы о тестировании производительности известно очень много, этой проблеме посвящена монография[22]. Для проведения данного теста были использованы персональные компьютеры различной конфигурации (ЭВМ на базе Intel 486, Pentium 100, Cyrix 350). В результате проведения теста была зафиксирована корректная работы системы, но необходимо отметить, что работа на ПК на базе Intel 486 не рекомендуется, хотя и возможна. 5.5. Выводы по тестированию ПО. На основание проведения вышеперечисленных тестов (см. приложение B, C) можно заключить, что: ¨ Созданная система выполняет все функции, указанные в ТЗ. ¨ При аварийном отключении сохраняет максимально возможное количество данных. ¨ Система способна работать на ПК различной конфигурации, в том числе и минимальной. ¨ Система отвечает поставленным требованиям по защите от несанкционированного доступа. ¨ Система корректно осуществляет свою работу при работе с большими объемами данных (при макимальном объеме БД – 2 Мб) и при большом количестве запросов(20 запросов).
6. Разработка бизнес-плана автоматизированной справочно-информационной системы “Учет поставок”. Резюме. Разработанная АСИС предназначена для контроля и учета поставок на предприятие любой формы собственности, занимающимся любым видом деятельности связанной с поставками на предприятие. Данная система позволит автоматизировать процесс учета поставок и обрабатывать данные с большой скоростью, поскольку она разработана под современную электронно-вычислительную технику. Данный аспект обеспечивает пользователю удобный интерфейс и простоту в использовании.
Для возможности работы с данным программным продуктом необходима ПЭВМ на базе процессора Intel Pentium 100 и выше, со свободным дисковым пространством не менее 10 Mb, оперативной памятью – 16 Mb. ПЭВМ на которой будет эксплуатироваться предоставляемая АСИС должна быть обеспечена операционной системой Windows 95 или системами совместимыми с ней, а также сервером базы данных InterBase. Стоимость разработанной АСИС 629,02 грн. Затраты на тиражирование и адаптацию 20,6 грн. Предположительное число продаж 470 копий, в том числе: 155 в первый год; 200 во второй год; 115 в третий год. Стоимость одной копии 64,73 грн. При данной стоимости одной копии затраты на разработку АСИС окупятся при реализации 10 копий, что обеспечивает рентабельность разработанной АСИС. 6.1. Описание автоматизированной справочно-информационной системы. Характеристики программного продукта. АСИС “Учет поставок” предназначена для осуществления контроля за поставками на предприятие и для их учета. Работать с АСИС рекомендуется директору предприятия или начальнику цеха (для осуществления контроля поставок), либо ответственному по поставкам (для учета поставок). Используя АСИС “Учет поставок” на предприятии достигается эффективность в их проведении, что обеспечивается: ¨ Возможностью создания печатных документов (договора с поставщиками, заказы и заявки на поставку продукции); ¨ Высокой скоростью обработки данных о процессе поставок; ¨ Определением задолженности по оплате за выполненный заказ; ¨ Определением оптимального счета-фактуры и выдачи рекомендации по возможному поставщику данной продукции; В таблице 6.1 приведены основные характеристики АСИС: Таблица 6.1 Характеристика АСИС Наименование Значение параметра Тип используемой ЭВМ Intel Pentium 100 Тип операционной системы Windows 95 и другая совместимая с ней Требуемая память на диске 1.4 Mb Требуемая оперативная память 16 Mb и выше Инструментальное ПО Delphi 3.0 Дополнительное ПО InterBase 4.2 Модель данных Реляционная Для более быстрого освоения работы с предоставляемой АСИС предусмотрена система помощи, так же сопроводительная документация предоставляемая к ПО. Патентная чистота. Поскольку предоставляемая АСИС “Учет поставок” разрабатывалась в Государственном аэрокосмическом университете, с использованием лицензионного ПО, которым обладает университет, то данный программный продукт можно реализовывать на легальном рынке ПО. Гарантия потребительских прав. Гарантируется получение АСИС “Учет поставок” в обусловленные договором сроки, замена старой версии АСИС на новую и удаление ошибок обнаруженных пользователем, предоставление скидок при приобретении новых версий АСИС. 6.2 Маркетинговые исследования рынков сбыта. Разработанная АСИС является специализированным программным продуктом, ориентированным на предприятия связанные с поставками различных видов продукции. Поэтому сигментацию рынка сбыта целесообразно проводить по географическому признаку, а именно по областям страны, смежных с Харьковской. Полная потребность в продукции рассчитывается по формуле: (6.1) где - полная потребность в продукте; - полная потребность в продукте i-го сегмента, которая определя- ется по следующей формуле: (6.2) где - количество предприятий (в нашем случае вузы) в i-ом сегменте; - коэффициент охвата, т.е. доля предприятий-покупателей, которые хотят (могут) приобрести товар в i-ом сегменте. mi – комплектность поставки (m=1). Сегментирование и расчеты емкости рынка представлены в таблице 6.2. Таблица 6.2. Сегментирование и расчеты емкости рынка Область промышленные предприятия Итого полная потребность Общее количество Предполагаемый коэффициент охвата Харьковская 257 0,3 77 Киевская 365 0,2 73 Днепропетровская 261 0,3 78 Донецкая 420 0,4 168 Полтавская 147 0,5 74 Итого 1450 470 Исходя из предполагаемых коэффициентов охвата по указанным областям Украины и расчета емкости по каждому сегменту определено, что полная емкость рынка составляет 89 копий. Предположительные объемы реализации по годам, на ближайшие 3 года: 1-ый год (помесячно):
месяц: 1 2 3 4 5 6 7 8 9 10 11 12 итого объем реализации: 4 6 6 9 10 14 14 15 17 17 20 23 155 2-ой год (поквартально): I квартал - 35 копий; II квартал - 50 копий; III квартал - 55 копий; IV квартал - 60 копий; Итого: 200 копий; 3-ий год: 115 копий. 6.3 Оценка качества и конкурентоспособности продукта. Поскольку на промышленных предприятиях, как правило, уже имеется подобие данного продукта, то собственные программные продукты и будут составлять конкуренцию разработанной АСИС. Но их основным недостатком является то, что большинство данных продуктов разработано для устаревшей электронно-вычислительной техники, и не отвечают современным требованиям по надежности, интерфейсу, простоте в эксплуатации предъявляемым к современному ПО. Для оценки уровня качества продукта используют обобщенный показатель качества. Для его расчета необходимо выделить два вида показателей, характеризующих данное изделие: ¨ Минимизирующие; ¨ Максимизирующие. Минимизируемые показатели рассчитываются по формуле: (6.3) Для расчета максимизирующих показателей используется формула: (6.4) где –относительный показатель i-го показателя для j-го варианта, - абсолютный показатель i-го показателя для j-го варианта, - пока затель i-го показателя для гипотетического варианта. Показателям качества присваивают коэффициенты весомости , при этом и . После чего рассчитывают обобщенные показатели качества по j-варианту: (6.5) Расчет обобщенного показателя качества АСИС “Учет поставок” приведен в таблице 6.3 Таблца 6.3 Определение обобщенного показателя качества № Наименование пока Коэф. Абсолютные значения Относительные значения показателя зат Весом. показателей показателей качества ель Bi Учет поставок существ. Гипот. Учет поставок Существ. ПО ПО Kij bi*Kij Kij bi*Kij 1 Уровень защищенности макс. 0,2 8 5 10 0,8 0,16 0,5 0,1 2 Интерфейс макс. 0,25 9 4 10 0,9 0,225 0,4 0,1 3 Надежность макс. 0,3 8 7 10 0,8 0,24 0,7 0,21 4 Скорость обработки запросов макс. 0,15 6 7 10 0,6 0,09 0,7 0,105 5 Требования к ПО мин. 0,05 8 3 3 0,375 0,019 1 0,05 6 Требования к аппаратным ср-вам мин. 0,05 9 3 3 0,333 0,017 1 0,05 Итого 1 обобщенный показатель качества: 0,75 0,615 Исходя из расчета обобщенного показателя качества для АСИС сделаем вывод, что показатель уровня качества предлагаемой автоматизированной системы на 13% больше, чем у конкурирующей продукции. Для определения конкурентоспособности продукции требуется рассчитать уровень качества рассматриваемой АСИС. Уровень качества рассчитывается по следующей формуле:
(6.6) где Кj – обобщенный показатель качества j конкурирующей продукции; Кб – обобщенный показатель качества базового изделия (предлагаемой АСИС); Уровень качества АСИС “Учет поставок” составляет: 1,22. Таким образом предлагаемый продукт по указанным в таблице 6.3 показателям качества обладает большим качеством, чем у конкурирующей продукции на на 22%. 6.4 Определение затрат на разработку АСИС “Учет поставок”. Для определения затрат на разработку АСИС необходимо учесть следующие данные: ¨ Основная зарплата разработчиков; ¨ Стоимость МБП; ¨ Стоимость аренды ПЭВМ; ¨ Отчисления в пенсионный фонд; ¨ Отчисления на социальное страхование (с разработчика). Затраты на разработку АСИС приведены в таблице 6.4 таблица 6.4 затраты на разработку №п/п Виды формула расчет,грн затрат 1 основная зарплата Ззр=Зср/дн.*(tоф+tа+tс+tп+tо+tд), Зср/дн=Зп/21 195,96 2 Стоимость МБП Змбп=Сд+Сб+Скт 23 3 стоимость Змв=Смв*Тмв, Тмв=(Q*m)/(60*Kкв) 5 аренды ПЭВМ 4 отчисления 32%*Ззр 62,71 в пенсионный фонд 5 отчисление 4%*Ззр 7,84 на соц. Страх ИТОГО 314,51 Ззр- зарплата разработчику; Зср/дн- среднедневная зарплата разработчика Ззс/дн=8,52 грн. tоф- трудозатраты на изучение, описание задачи (оцениваются по 5 бальной шкале); tоф=4 tа- трудозатраты на разработку алгоритма решения задачи; tа=4 tс- трудозатраты на составление схемы программы; tс=3 tп- трудозатраты на разработку АСИС; tп=3 tо- трудозатраты на отладку АСИС на тестовом примере; tо=5 tд- трудозатраты на оформление документации. tд=4 Сд- стоимость дискет; Сд=2 грн. Зб- стоимость бумаги; Зб=18 грн. Зк- стоимость канцелярских товаров; Зк=3 грн. Змв- затраты на машинное время; Смв- себестоимость машиночаса работы ПЭВМ; Смв=0,2 грн. Тмв- время отладки программы на ПЭВМ; Тмв=25 ч. Q – условное количество операторов в программе; Q=1500 Ккв- коэффициент квалификации; Ккв=1; Планируемая прибыль, которая будет получена в результате продажи одной копии АСИС составит 100% от стоимости разработки: 314,51 грн. Поэтому цена готового изделия составит: Ц=З + П где З – затраты на разработку АСИС; П – планируемая прибыль. Цена= 629,02 грн. Полученное значение цены отражает стоимость разработки АСИС с учетом прибыли, но поскольку АСИС предполагается тиражировать, то данную величину необходимо пересмотреть. Рассмотрим затраты на тиражирование 1 копии АСИС “Учет поставок”. Они определяются: - стоимостью дискет и бумаги для документации (100 листов), на 1 копию: 2+18/5=5,6 грн.; - расходами на печать документации: 3 грн; Таким образом затраты на тиражирование составляют 8,6 грн. (1) Себестоимость разработки одной копии (стоимость разработки к емкости рынка) равна: 314,51/470=0,67 грн. (2) Поскольку данное ПО является специализированным и ориентировано в большей степени на промышленные предприятия, то для его рекламы будет применятся “прямая почтовая реклама”. В виду небольшого количества предполагаемых продаж и малой стоимости данного вида рекламы, затраты на рекламу одной копии составят: 1 грн. (3) Стоимость обслуживания покупателя АСИС при покупке одной копии составляет 12 грн. и включает в себя: установку АСИС, предоставление руководства пользователя. (4) Отчисление в пенсионный фонд, на соц. страх и страхование на случай безработицы составляют 37,5% от пункта (4) и равны: 4,5 грн. (5) Себестоимость одной копии составляет сумму 1-5: 26,97 грн. Прибыль от одной копии составляет 100% себестоимости: 26,97 грн. (6) Цена одной копии будет составлять сумму прибыли и себестоимости одной копии: 53,94 грн. Цена одной копии с учетом НДС (20%) буде равна: 1,2*(26,97+26,97)=64,73 грн. Налог на прибыль составляет 30%, поэтому чистый доход, полученный от реализации одой копии равен разности между прибылью и налогом на нее и составляет: 26,97-0,3*26,97= 18,88 грн. 6.5 Стратегия маркетинга. При разработке АСИС “Учет поставок” перед разработчиком ставилась задача создать такую систему, которая автоматизировала бы деятельность предприятия, связанную с поставками. Поэтому пользователями разработанной АСИС будут: руководители предприятий (начальники цехов), для осуществления контроля за производимыми поставками на предприятие и ответственными по поставкам, для учета и систематизации поставок. В связи с этим АСИС является специализированным ПО и его тиражирование невелико, поэтому распространение будет производится силами разработчика, с возможным применением специальных салонов.
Для рекламирования ПО будет использована прямая почтовая реклама. Данная разновидность рекламы предполагает отправление потенциальным покупателям (предприятиям) писем с краткой информацией о назначении, функциях реализуемых АСИС, и сервисном обслуживании. При реализации АСИС потребителям возможны следующие скидки:
¨ 10% при замене старой версии на новую; ¨ 15% при приобретении 2-х и более копий АСИС. Сервисное обслуживание АСИС включает в себя: ¨ бесплатное обучение работы с АСИС при первой покупке; ¨ устранение выявленных недостатков за счет разработчика; ¨ информирование о появлении новой версии. 6.6 Оценка риска и страхования. Разработанная АСИС защищена патентом и авторскими правами. Защита от несанкционированного применения обеспечивается невозможностью использования АСИС при незнании пароля. Пароль устанавливается уникальный для каждой копии. 6.7 Финансовый план. Составленный финансовый план расходов и доходов охватывает период времени в три года. В таблице 6.5 приведен финансовый план на первый год (помесячно): Таблица 6.5 Карта расходов и доходов ( помесячно) Доходы и затраты Сумма, грн. Всего, 1 мес. 2 мес 3 мес 4 мес 5 мес 6 мес 7 мес 8 мес 9 мес 10 мес 11 мес 12 мес. грн. Объем продаж (шт) 4 6 6 9 10 14 14 15 17 17 20 23 155 доходы от реализа- ции (с НДС), грн. 286,4 429,5 429,5 644,31 715,9 1002,3 1002,3 1073,9 1217 1217 1431,8 1646,6 11096 I. Постоянные затраты, грн. 1. На разработку 314,51 2. На рекламу 4 6 6 9 10 14 14 15 17 17 20 23 155 Всего 4 6 6 9 10 14 14 15 17 17 20 23 469,51 II. Переменные затраты, грн. 1. На тиражирование 48 72 72 108 120 168 168 180 204 204 240 276 1860 2. НДС 57,27 85,91 85,91 128,86 143,18 200,45 200,45 214,77 243,41 243,41 286,36 329,31 2219,29 3. Отчисления - в пенс. Фонд 15,36 23,04 23,04 34,56 38,40 53,76 53,76 57,60 65,28 65,28 76,80 88,32 595,20 - на соц. страх 1,92 2,88 2,88 4,32 4,80 6,72 6,72 7,20 8,16 8,16 9,60 11,04 74,40 - на случай безработицы 0,72 1,08 1,08 1,62 1,80 2,52 2,52 2,70 3,06 3,06 3,60 4,14 27,90 - на прибыль 35,80 53,70 53,70 80,55 89,50 125,30 125,30 134,25 152,15 152,15 179,00 205,85 1387,25 Всего 6164,04 Наличные деньги 4462,9 В таблице 6.6 представлена карта доходов и затрат поквартально: Таблица 6.6 Карта расходов и доходов ( поквартально)
Доходы и затраты Сумма, грн. Всего, I квартал II квартал III квартал IV квартал грн. Объем продаж (шт) 35 50 55 60 200 доходы от реализа- ции (с НДС), грн. 2505,65 3579,5 3937,45 4295,4 14318 I. Постоянные затраты, грн. 1. На разработку ---- 2. На рекламу 35 50 55 60 200 Всего 35 50 55 60 200 II. Переменные затраты, грн. 1. На тиражирование 420 600 660 720 2400 2. НДС 501,13 715,90 787,49 859,08 2863,60 3. Отчисления - в пенс. Фонд 134,40 192,00 211,20 230,40 768,00 - на соц. страх 16,80 24,00 26,40 28,80 96,00 - на случай безработицы 6,30 9,00 9,90 10,80 36,00 - на прибыль 313,25 447,50 492,25 537,00 1790,00 Всего 7953,60 Наличные деньги 6164,40 В таблице 6.7 показаны доходы и затраты при реализации АСИС в течении 3-х лет: Таблица 6.7 Таблица доходов и затрат Наименование показателя Сумма ,грн Всего Начало реализации 1-й год 2-й год 3-й год Объём продаж, шт 0 155 200 115 470 Доходы от реализации, грн 0 11096,45 14318 8232,85 33647,3 постоянные затраты, грн. 1. Зарплата разработчиков 195,96 195,96 2. МБП 23 23 3. Отчисления в бюджет 70,55 70,55 4. Аренда ЭВМ 5 5 5. На рекламу 0 155 200 115 470 Всего: 294,51 155 200 115 764,51 переменные затраты, грн 1. На тиражирование 0 1860 2400 1380 5640 2. НДС 0 2219,29 2863,60 1646,57 6729,46 3. Отчисления 0 - в пенс. Фонд 0 595,20 768,00 441,60 1804,80 - на соц. страх 0 74,40 96,00 55,20 225,60 - на случай 0 безработицы 27,90 36,00 20,70 84,60 - на прибыль 0 1387,25 1790,00 1029,25 4206,50 Всего 0 6164,04 7953,60 4573,32 18690,96 Прибыль, грн. -294,51 4777,41 6164,40 3544,53 14191,83 На основании анализа финансового плана построим график безубыточности (рис. 6.1): Рис 6.1 график безубыточности. Выполнив анализ данного графика можно сделать вывод, что реализация 10 копий АСИС “Учет поставок” при отпускной цене каждой копии 71,59 покроет затраты на его разработку. При заполнении всей предполагаемой емкости рынка и реализации продукции продукт принесет прибыль значительно превышающую затраты не его разработку и сопровождение. Поскольку разработанная автоматизированная система является конкурентоспособной и ее цена достаточно низка, то данный проект заинтересует потенциального покупателя.
7. Безопасность жизнедеятельности 7.1. Выявление вредных и опасных факторов. Работа ПЭВМ связана с присутствием на рабочем месте человека – оператора, поэтому вопросы охраны труда будут рассматриваться с точки зрения обеспечения безопасных условий труда и условий труда сохраняющих здоровье оператора, пользователя. При работе в помещении лаборатории по производству ПО следует выделить следующие вредные и опасные факторы: ¨ Метеорологические условия среды (микроклимат лаборатории); ¨ Аномальное освещение; ¨ Высокий уровень шума; ¨ Повышенный уровень ионизирующего излучения; ¨ Опасность поражения электрическим током; ¨ Повышенные психофизиологические нагрузки; ¨ Пожароопасность. Требования по влажности, предъявляемые к радиоэлектронной технике и нормы микроклимата, необходимые для нормальной жизнедеятельности человека различны. Это объясняется тем, что при эксплуатации ПЭВМ влажность воздуха в помещении согласно ГОСТам 12.1.005-86 должна быть одной (не более 40-60%), а влажность для оператора другой (не менее 70%). Поэтому, оптимальная влажность в лаборатории для оператора и ПЭВМ принята 50%. Пониженная влажность вызывает у человека ощущение сухости слизистых оболочек верхних дыхательных путей, ухудшает самочувтсвие и снижает работоспособность. Высокая температура способствует быстрому утомлению оператора, может привести к перегреву организму, что вызывает тепловой удар. Низкая температура может вызвать местное или общее охлаждение организма, стать причиной простудного заболевания. Поэтому в качестве оптимального микроклимата для персонала, с учетом требований предъявляемых к оборудованию лаборатории, согласно ГОСТ 12.1.005-88 установлен микроклимат, отвечающий характеристикам: температура – 22-240 С, относительная влажность – 40-60%, подвижность воздуха не более 0.1 м/с. Освещенность измеряется в люминах лк., и для искусственного освещения приняты норма освещенности на рабочей поверхности составляет 250-350 лк. Работы производимые в помещении лаборатории соответствуют категории работ I (легкий физический труд); разряд зрительных работ – III. Шум [8], создаваемый одной ПЭВМ невелик, он находится в диапазоне 30-68 дб. Согласно ГОСТу 12.1.003-83 он должен не превышать уровня 40 дб. Но поскольку в лаборатории находится не одна ЭВМ, то шум производимый ими является достаточно высоким. Кроме того данный тип шума оказывает отрицательное воздействие на человека еще и тем, что он является монотонным. Также необходимо отметить, что в помещении лаборатории используются принтеры, как правило матричного типа, что также увеличивает уровень шума. Шум нарушает нервную систему; шумовые явления обладают свойством куммуляции: накапливаясь в организме, он все больше и больше угнетает нервную систему. Шум – причина преждевременного утомления, ослабления внимания, памяти. Ионизирующими [7] называются излучения, взаимодействие которых со средой приводит к образованию электрических зарядов разных знаков. К ионизирующим излучениям относятся: гамма-излучение, рентгеновское, корпускулярное, инфракрасное, микроволновое и другие виды излучений. Рентгеновское излучение на расстоянии 10 см. от монитора составляет не более 100 мкР/ч, а уровень ионизации обоих зарядов в диапазоне 1500-5000 на 1 см3 воздуха. Источником излучения в лаборатории по производству ПО являются мониторы. При повышенном электромагнитном излучении у человека появляется головная боль, повышенная утомляемость, что снижает сосредоточенность работающего к работе, его внимание. Излучение и поля радиочастотного диапазона регламентируются ГОСТ 12.1.006 – 84 (“Электромагнитные поля радиочастот. Допустимые уровни на рабочих местах и требования к проведению контроля”). Электрооборудование в лаборатории является одним из первых источников опасных факторов, поскольку основная масса оборудования в ней электрическое. Оборудование, находящееся в лаборатории ПО запитывается от сети переменного тока напряжением 220 В и частотой 50 Гц. Поэтому персонал лаборатории подвержен повышенному риску поражения электрическим током. Поражение током может произойти от неизолированной электропроводки, от корпуса системного блока, если на него произошел пробой электричества, при неосторожным обращении с оборудованием, его разборкой и т.п. Действие электрического тока на живую ткань носит своеобразный характер. Проходя через организм человека ток производит термическое (ожоги отдельных участков тела, нагрев внутренних органов до высокой температуры), электрическое (разложение органической жидкости, в том числе и крови), механическое (расслоение и другие подобные повреждения различных тканей организма) и биологическое (нарушение внутренних биоэлектрических процессов, протекающих в нормально действующем организме ) действия. Психофизиологические опасные и вредные факторы по характеру действия подразделяются на: физические (статические и динамические) и нервно-психические [7] (умственное перенапряжение, перенапряжение анализаторов, монотонность труда и эмоциональные перегрузки). Персонал лаборатории наиболее подвержен воздействию статических вредных факторов (неизменное положение тела), перенапряжению анализаторов (долгое времяпровождение перед экраном). Чтобы не перенапрягать зрительные анализаторы оператор должен проводить у монитора не более 4 ч. в сутки, производить набор не более 30.000 символов. Пожароопасность в лаборатории [28] главным образом представлена оголенными токоведущими частями электропроводки, коротким замыканием проводки, перегрузки электросети, статическим электричеством. Что касается причин возникновения пожара не связанных с электричеством, то сюда можно отнести: неправильное устройство и эксплуатация отопительных систем (использование обогревателей), неисправность вентиляционных систем, неосторожное обращение с огнем персонала лаборатории и др. Лаборатория по разработке ПО на предприятии по своей конструкции представляет собой невзрывоопасное помещение и по пожарной опасности относится к категории В, согласно ОНТП-24-86. Степень огнестойкости здания – II согласно СНиП 2.01.02-35 .Класс помещения по пожарной опасности П-IIа, согласно ПУЭ-87. 7.2. Мероприятия по защите от вредных и опасных факторов.
1) Для нормализации воздуха в лаборатории следует использовать вентиляцию, как естественную так и искусственную. К видам естественной вентиляции используемой в лаборатории по производству ПО можно отнести неорганизованную естественную вентиляцию. Но использование такого вида вентиляции имеет ряд недостатков: воздух поступающий в помещение не подогревается и не увлажняется, поэтому в лаборатории целесообразно применять механическую общую приточную вентиляцию, которая устраняет недостатки естественной. Для обеспечения соответствующей температуры в лаборатории по разработке ПО в зимнее время следует использовать централизованное отопление, а в летнее – различные виды вентиляции.
2) Нормальное освещение обеспечивается путем рационального комбинирования и применения естественного и искусственного освещения. Правильного размещения монитора на рабочем месте относительно оконных проемов. 3) Для защиты от шума, создаваемого в лаборатории оборудованием, целесообразно использовать следующие методы: ¨ Снижение шума в источнике его возникновения; ¨ Снижение шума на пути его распространения. Так, для уменьшения шума создаваемого оборудованием лаборатории, его необходимо располагать на специальных аммортизирующих прокладках, помещение, в котором данное оборудование облицовывать звукопоглощающей плиткой. Для защиты от внешнего шума подобные лаборатории следует располагать в нерабочей зоне (в отдельном здании, либо в здании управления предприятием). 4) для защиты от ионизирующего излучения следует использовать: во-первых, источники с минимальным выходом ионизирующего излучения (электронно-лучевая трубка), во-вторых, ограничивать время работы с источником ионизирующего излучения и, в-третьих – экранирование источников. 5) защита персонала лаборатории по разработке ПО от поражения электрическим током обеспечивается правильным размещением оборудования, правильным выполнением электропроводки, ее надежной изоляцией и выполнением требований по технике безопасности при работе в лаборатории. 6) уменьшение влияния психофизиологических нагрузок на организм человека достигается путем правильного оформления рабочего места (согласно ГОСТ 122.032-78 и ГОСТ 21829-76), рационального распределения рабочего времени (через каждые 2 часа проведенные за ПЭВМ необходимо обеспечивать 10-15 минут отдыха), правильным цветовым оформлением (коэффициенты отражения должны быть: 60-70% для потолка, 40-50% для стен, 30% для пола, 30-40% для других отражающих поверхностей), обеспечением соответствующей настройки параметров терминального оборудования (контрастность изображения знака не менее 0,8; яркость освещения экрана не менее 10 kq/m2; разрешение экрана 640х480 и более; частота регенерации изображения не менее 72 МГц) 7) пожарная безопасность в соответствии с ГОСТ 12.1.004-91 обеспечивается системами предотвращения пожара (использование заземления для защиты от статического напряжения, контроль состояния изоляции, молниезащита зданий, наличие плавких предохранителей в электрооборудовании), системами пожарной защиты (системы оповещения о пожаре, наличия первичных средств тушения пожара, аварийное отключение аппаратуры), организационно-техническими мероприятиями. Заключение. В рамках дипломного проекта была разработана автоматизированная справочно-информационная система “Учет поставок”. В результате выполненной разработки можно сделать следующие выводы: 1. При разработке АСИС был пройден полный цикл проектирования программы от постановки задачи заказчиком до сдачи АСИС в эксплуатацию. 2. Разработанная АСИС позволяет достигнуть следующих эффектов: ¨ уменьшение времени необходимого для учета поставок произведенных на предприятие; ¨ автоматизация контроля поставок; ¨ возможность длительного хранения информации о поставках на предприятие большого срока давности, для возможности более полного расчета эффективности деятельности предприятия; ¨ своевременное получение информации о сроках оплаты за осуществленные поставки. 3. Целесообразность разработки обуславливается наличием свободного сегмента рынка для реализации разработанной АСИС. Для этого были разработаны элементы бизнес-плана и проведены необходимые исследования. согласно разработанному бизнес-плану цена одной копии АСИС составит 64, 59 грн при предполагаемом количестве продаж 470 копий. Рассчитывается получение чистая прибыль от реализации в размере 2600 грн. 4. Так же при создании АСИС “Учет поставок” были исследованы условия труда инженера-программиста на его рабочем месте на предприятии (в лаборатории по разработке ПО) и сделаны конкретные предложения по их улучшению. 5. На основании вышесказанного можно сделать вывод о том, что разработка АСИС “Учет поставок” является целесообразной и будет приносить реальную пользу при использовании ее на предприятии. Список используемой литературы. 1. Рихтер Джеффри “Windows для профессионалов”, С-П. Русская редакция 1995. 2. Пеньков Е.Г. “Организация учета в материально-техническом снабжении”, Финансы, М. 1973 3. Голда З.К. “Организация и планирование материально-технического снабжения предприятий и организаций местного хозяйства” М. 1970 4. Лифшиц Н.И., Левин Е.Т “Механизация и автоматизация процессов отборки и комплектования заказов на складах” М., 1970 5. А.А. Бакаев, В.И. Гриценко, Д.Н. Козлов “Методы организации и обработки баз знаний” Наукова думка, Киев 1993 6. Л.В. Кокорева, О.Л. Перевозчикова “Диалоговые системы и представление знаний” М., 1995 7. С.П. Павлов, З.И. Губонина “Охрана труда в приборостроении” М., 1986 8. А.О. Навакатикян, В.В. Кальнищ “Охрана труда пользователей компьютерных видеодисплейных терминалов” Киев 1997 9. Г. Майерс “Надежность ПО” Мир, М., 1980 10. Г. Майерс “Искусство тестирования программ” Финансы и статистика М., 1982 11. К.Г. Гусев М.Ф. Бабаков “Oсновы теории надежности учебное пособие” ХАИ 1975. 12. Бронин Е.И. “Принципы построения и архитектура САПР” 13. Цветков В.Д. “Системно-структурное моделирование и автоматизация проектирования”; 14. Мартин Дж. “Организация баз данных в вычислительных системах”; 15. Дантеманн Дж. “Программирование в среде Delphi” 16. Сван. Т Delphi 4. “Библия разработчика” 17. Хендерсон К. “Руководство разработчика баз данных” 18. Грого П. “Программирование на языке Паскаль” 19. Ю.Х. Вермишев “Основы автоматизации проектирования” 20. П.Грэй “Логика, алгебра, и БД.” 21. Драммонд Д. “Методы оценки и измерений дискретных вычислительных cистем”. Пер. с англ. – М:Мир 1976. 22. Brown A. R. “Programm Debugging” London: MacDonald 1973. 23. Гради Буч. “Объектно-ориентированный анализ и проектирование.” М.: Издательство Бином 24. Бойко В.В., Савинков В.М. “Проектирование информационной базы автоматизированной системы на основе СУБД.” М.: Финансы и статистика, 1982. 25. Борзов Ю.В. “Методы тестирования и отладки программ ЭВМ.” Рига, ЛГУ им. П. Стучки, 1980.
26. Гудман С. “Введение в разработку и анализ алгоритмов.” М.: Мир, 1981. 27. Джексон Г. “Проектирование реляционных баз данных для использования с микро-ЭВМ” М.: Финансы и статистика, 1991. 28. Кобевник В.Ф. “Охрана труда.” – К.: Вища школа, 1990. Приложение Приложение А
Выходные формы АСИС “ Учет поставок” Выходная форма “Договор” ДОГОВОР № _ От “ ” _199 г. г. _ Предприятие именуемое в дальнейшем Поставщик, в лице _ действующее на основании Устава, с одной стороны и ОАО “Полтавский Гок”, именуемый в дальнейшем Покупатель, в лице генерального директора Бадагова В.Ф. действующее на основании Устава, заключили настоящий договор о нижеследующем: ПРЕДМЕТ ДОГОВОРА. 1.1.В соответствии с настоящим договором Поставщик обязуется поставить Покупателю по согласованным спецификациям, являющимся неотьемлемой частью договора, а покупатель принять и оплатить _.Спецификации составляются Покупателем и Поставщиком по мере возникновения потребности на _ у Покупателя. 1.2.Ориентировочная сумма договора гривен. КАЧЕСТВО И КОМПЛЕКТНОСТЬ. 2.1.Качество и комплектность поставляемой продукции должны соответствовать ГОСТ . 2.2.Качество поставляемой продукции подтверждается сертификатом качества завода-изготовителя. 2.3.Приемка продукции по качеству и количеству в соответствии с Инструкциями о приемке _. Замена некачественной продукции производится в течении дней за счет Поставщика. Поставщик уплачивает Покупателю штраф в размере % стоимости продукции ненадлежащего качества или некомплектной (согл. Инструкций _). СРОКИ И ПОРЯДОК ПОСТАВКИ. 3.1.Поставка продукции производится по запросу Покупателя на условиях DDP Инкотермс 90. Дата поставки товара определяется датой приемки груза Покупателем. 3.2.Срок поставки дней с момента согласования спецификации. 3.3.Перевозка транспортом поставщика. ЦЕНА И ПОРЯДОК РАСЧЕТОВ. 4.1.Продукция, поставляемая Поставщиком, оплачивается покупателем по договорным ценам в национальной валюте Украины. 4.2.Оплата продукции осуществляется по факту ее поставки, не позднее 30 (тридцати) банковских дней. ОТВЕТСТВЕННОСТЬ СТОРОН. 5.1.Все разногласия и споры, которые могут возникнуть при исполнении настоящего договора будут решаться путем переговоров между сторонами. При недостижении соглашения передаются на рассмотрение Арбитражного суда по месту нахождения ответчика. ДОПОЛНИТЕЛЬНЫЕ УСЛОВИЯ. 6.1.Гербовый сбор оплачивает покупатель. 6.2.При изменении отгрузочных, платежных, почтовых реквизитов стороны должны незамедлительно уведомить об этом друг-друга. 6.3.Настоящий договор составлен в двух экземплярах, имеющих равную юридическую силу, по одному экземпляру для каждой стороны. ФОРС-МАЖОР. 7.1.Дни определения форс-мажорных обстоятельств применяются правила Инкотермс 1990 г., а так же Конвенция ООН о договорах международной купли-продажи товаров от 11.04.1980 г СРОК ДЕЙСТВИЯ ДОГОВОРА. 8.1.Срок действия договора: с момента подписания до полного его исполнения. ЮРИДИЧЕСКИЕ АДРЕСА. ПОКУПАТЕЛЬ ПОСТАВЩИК р/с МФО _ ИНН _ ------------------------ ------------------------- Визы: Ком.дир. Нач. юр. отд. _ Гл. бух. _ Нач. УОК Выходная форма “Заявка” ЗАЯВКА № _ От “ ” _199 г. г. _ В соответствии с договором № Поставщику (наименование предприятия) необходимо предоставить счет-заказ на (наименование продукции) согласно спецификации _ Ориентировочная сумма заказа гривен. Визы: Нач. подразделения _ Отд. Цен _ Выходная форма “Заказ” ЗАКАЗ НА ПОСТАВКУ № _ От “ ” _199 г. г. _ В соответствии с договором № Поставщику _ (наименование предприятия) необходимо поставить _ (наименование продукции) согласно спецификации _ Визы: Нач. подразделения _ Отд. Цен _ Приложение B Пример запросов к БД SELECT nomer_dogovora, postav.nomer_postav, dogovor.nomer_postav, naimen_post FROM postav, dogovor WHERE postav.nomer_postav=dogovor.nomer_postav SELECT select nomer_zajavki, zajavka.nomer_dogovora, dogovor.nomer_dogovora, naimen_post,postav.nomer_postav, dogovor.nomer_postav FROM from zajavka,dogovor,postav WHERE (zajavka.nomer_dogovora=dogovor.nomer_dogovora) AND (postav.nomer_postav=dogovor.nomer_postav) SELECT nomer_zakaza, zakaz.nomer_dogovora, dogovor.nomer_dogovora, naimen_post,postav.nomer_postav, dogovor.nomer_postav FROM zakaz, dogovor, postav WHERE (zakaz.nomer_dogovora=dogovor.nomer_dogovora) AND (postav.nomer_postav=dogovor.nomer_postav) Приложение С Тестирование АСИС “Учет поставок”