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

Задачи сервера паутины - распределение ресурсов информационной системы. Именно он считывает необходимые файлы с дисков, запускает программы и передает клиентским программам (навигаторам) гипертекстовый документ. Сервер распознает, где ему брать документы и программы и как предавать им параметры. Для этого используются так называемые URL (Uniform Resource Locator) - унифицированный указатель на ресурс. Этот указатель содержит следующую информацию для сервера:

Является файл программной или документом;

Если файл - программа, то на каком языке она написана;

Если файл - программа, то какие параметры ей передаются.

Применение унифицированного указателя - часть шлюзового интерфейса Web (Common Gateway Interface - CGI).Этот интерфейс позволяет интегрировать в паутину любую программу.

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

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

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

Web - технологию можно применять повсеместно. На сегодняшний день Intranet используется в основном в следующих областях:

Полная информационная поддержка деятельности компании;

Централизация пользовательского интерфейса;

Электронный документооборот.

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

1.10.4 Обзор полузаказных систем

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

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

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

На рынке экономического программного обеспечения выделяют 5 секторов:

1. Первый сектор - это дешёвые массовые бухгалтерские программы для мелкого и среднего бизнеса. По некоторым данным около 70% этого рынка делят 3 компании: "1С", "Информатик", "ДИЦ" (при этом "1С" занимает в данной группе большую долю).

2. Второй сектор объединяет недорогие массовые бухгалтерские и управленческие системы для среднего бизнеса. Основные потребители данного рынка - средние и частично крупные компании, а основными производителями программ в этом секторе являются такие компании, как "Парус", "Интеллект- Сервис", "Инфин", "Инсофт" и "1С" - эти компании занимают около половины данного рынка.

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

4. К четвёртому сектору относятся массовые аналитические системы. Наиболее крупными поставщиками подобных систем является фирма "ИНЭК" И "Про-Инвест Колсалтинг".

5. Пятый сектор - это сектор информационно-правовых систем, в которых лидируют 3 компании: "Гарант", "Консультант" и ЦКР.

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

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

"1С"________________________________________ 21,1

MS Office _____________________________________ 7,8

Бухгалтерские программы _______________________ 3,5

"Парус"_______________________________________ 2,0

"Бэст"________________________________________ 1,2

"Инфо-бухгалтер"_______________________________0,8

"Турбо-бухгалтер"______________________________ 0,4

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

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

Следующий класс ПО экономического анализа существенно полнее интегрирован по данным с автоматизированными системами прочих контуров управления, и, прежде всего с бухгалтерским. К ним относятся разработки фирм корпорации «Галактика», фирм «Инфософт», «Интеллект-Сервис», «Фолио» и некоторые другие. Здесь естественной информационной базой анализа являются данные, создаваемые при использовании иных модулей программных комплексов указанных фирм. Тем самым исключается лишняя и довольно трудоемкая и технологическая операция ручного ввода базовых данных и создаются условия для решения всего спектра перечисленным выше аналитических задач. Реализованные в программных системах этих фирм функции поддержки анализа финансово-хозяйственной деятельности предприятия весьма разнообразны, причем каждая из разработок имеет как свои достоинства, так и недостатки.

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

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

1.11 Ориентировочный план реализации выбранного варианта концепции ПС

Проект начинается с постановки задачи. За ней следуют :

системный анализ;

проектирование;

разработка.

На стадии разработки уже начинается то, что, собственно, и называется “управление проектом” показанном на рисунке 9.

Размещено на http://www.allbest.ru/

Рисунок 9 - Структура разработки проекта

За разработкой следуют:

внедрение;

сопровождение;

консалтинг.

1.12 Описание автоматизированной информационной системы предприятия

В основу автоматизированной информационной системы (АИС) заложены следующие ключевые принципы:

· работа в едином информационном пространстве;

· поддержка единой технологии обработки и представления информации;

· обеспечение принципа однократного ввода данных;

открытость структур хранения информации.

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

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

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

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

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

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

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

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

1. Общий сервер для обслуживания всей сети, он располагается в защищенном помещении с ограниченным доступом сотрудников. С рабочими параметрами: AMD Athlon 2500-XP, не меньше 500 Мb оперативной памяти, жесткий диск не меньше 80 Gb с операционной системой Windows 2000-Сервер.

2. Рабочие станции, которые располагается в каждом магазине и торговом центре. Для нормального функционирования системы требуются параметры: AMD Duron 1600 Mhz, 256 Мb оперативной памяти, 40 Gb винчестер операционной системой Windows Me.

В АИС включаются рабочие станции для рабочего персонала со следующими параметрами:. AMD Athlon 2000-XP, 256 Мb оперативной памяти, 40 Gb винчестер, операционной системой Windows XP. Рабочие станции соединены по типу «общая шина» с использованием 100Мb канала передачи данных в сети Ethernet.

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

1.13 Требования, гарантирующие качество ПС

В числе основных требований к архитектуре современной ИC в первую очередь выделяются те, которые обеспечивают максимум эффективности их использования:

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

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

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

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

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

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

· тесная координация между стратегическим планированием деятельности предприятия и архитектурой ИС.

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

Среди других условий можно выделить:

· управление эффективностью использования ИС на основе обязательного измерения характеристик;

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

· управление эффективностью использования человеческих ресурсов и подготовка кадров.

2. ПОСТАНОВКА КОМПЛЕКСА ЗАДАЧ НА ПРЕДПРИЯТИИ СООО «ЕВРОСТИЛЬ» ДЛЯ ПРОЕКТИРОВАНИЯ ПС

2.1 Описание постановки комплекса задач для проектирования программного средства

программный автоматизация денежный оборот

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

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

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

четко отработанной технологией их обработки;

большим штатом работников организации;

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

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

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

2.2 Требования к бухгалтерским системам

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

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

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

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

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

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

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

· стоимость системы должна зависеть от объема решаемых задач и уровня технологичности. Очевидно, что стоимость локальной мини-бухгалтерии будет в несколько раз меньше, чем стоимость крупного комплексного модуля по ведению бухгалтерского учета, например такого, как «1С-Бухгалтерия» и т. п. Объясняется это используемой программной платформой, заложенной архитектурой, трудоемкостью разработки, внедрения и сопровождения.

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

2.3 Назначение комплекса задач

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

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

обработка справочников;

обработка начислений;

обработка расчётов.

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

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

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

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

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

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

уменьшения роли «ручного» ввода информации;

уменьшения объемов по оформлению соответствующих документов «ручным» способом.

2.4 Условия, при которых прекращаются решение комплекса задач автоматизированным способом

отключение электроэнергии по различным причинам, в том числе и аварийное отключение;

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

ошибки при работе программы - механические или алгоритмические дефекты, которые создают сбой;

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

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

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

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

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

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

факторы социального, политического или военного характера.

2.5 Входная и выходная информация

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

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

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

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

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

· сдельщики (наряды, табели / новый наряд, новый табель);

· повременщики (табели ИТР / табель, прочие);

· прочие начисления / удержания;

· аванс;

· отпускные;

· больничные.

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

· Ведомость по заработной плате №1;

· Ведомость по заработной плате №2;

· Внесение констант.

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

Целесообразно объединить подразделения предприятия в единую информационную систему и спроектировать ее на основе архитектуры “клиент - сервер”, которая предполагает использование разделяемых информационных ресурсов, т.е. базы данных.

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

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

2.6 Обзор модели объект - отношения

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

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

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

ключевое свойство, уникальное в некотором контексте;

однозначное или многозначное свойство, т.е. разрешены повторяющиеся группы;

отсутствующее свойство, т.е. “неизвестное” или ”неприменимое”;

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

2.7 Проектирование базы данных

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

Каждый правильный тип объекта соответствует некоторому базовому отношению. Каждое базовое отношение должно иметь первичный ключ. Все эти факты должны быть задокументированы с помощью соответствующего набора утверждений на языке определения данных (data definition language - DDL) или, по крайней мере, с помощью некоторых предпосылок для такого набора утверждений. Иначе говоря, для записи решений, принятых при проектировании базы данных, предполагается использование DDL либо SQL (structured query language) утверждений. Хотя это не единственный способ выполнения данной функции, но кокой бы формальный метод при этом не использовался, он должен быть функционально эквивалентен этим утверждениям.

В общем случае проектирование на основе модели “объект-отношение” включает четыре больших этапа; цель каждого из них можно кратко сформулировать следующим образом:

идентифицировать полезные семантические концепции;

вывести формальные объекты;

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

вывести формальные операторы.

2.7.1 Ссылочная целостность и нормализация

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

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

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

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

Нормализация

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

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

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

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

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

2.8 Обзор объектно-ориентированной модели - OMT

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

Объектно-ориентированная методология OMT (Object Modeling Technique) является одной из наиболее продвинутых и популярных объектно-ориентированных методологий. Более того, ее графический язык (система обозначений для диаграмм) получил достаточно широкое распространение и используется в некоторых других объектно-ориентированных методологиях, а также в большинстве публикаций по объектно-ориентированным методологиям.

В технологии OMT проектируемая программная система представляется в виде трех взаимосвязанных моделей:

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

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

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

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

2.8.1 Проектирование БД на основе объектной модели системы

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

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

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

Анализируя атрибуты объектов вышеперечисленных классов, был сделан вывод о необходимости введения суперкласса “документ”. Все остальные классы становятся классами-наследниками. В суперкласс “документ” выносятся только те атрибуты и методы, которые могут быть общими для всех классов-наследников

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

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

Размещено на http://www.allbest.ru/

Рисунок 10 - Объектная диаграмма класса «справочник» (исходные объекты)

2.8.2 Динамическая модель системы

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

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

Динамическая модель приведена на рисунке 11. Квадратные скобки задают условия по наступлению определенного события. Под названием документа понимается конкретный объект, состояния которого рассматриваются на диаграмме.



Размещено на http://www.allbest.ru/

Рисунок 11 - Диаграмма состояний объектов суперкласса “справочники”

2.8.3 Функциональная модель подсистемы

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

ДПД содержит процессы, которые преобразуют данные, потоки данных, которые переносят данные, активные объекты (экторы), которые производят и потребляют данные, и хранилища данных, которые пассивно хранят данные.

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

определены входные и выходные значения;

построены ДПД;

описаны функции.

3. РАСЧЕТ ЭКОНОМИЧЕСКОЙ ЭФФЕКТИВНОСТИ

3.1 Общие положения

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

Определение эффективности ПС основано на принципах определения экономической эффективности производства и использования в народном хозяйстве новой техники.

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

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

предварительный;

потенциальный;

гарантированный;

фактический.

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

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

Гарантированный экономический эффект рассчитывается в виде гарантированного экономического эффекта для конкретного объекта внедрения и общего гарантированного внедрения по ряду объектов.

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

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

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

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

улучшение показателей их основной деятельности, происходящее в результате использования ПС;

сокращение сроков освоения новых ПС за счет их лучших эргономических характеристик;

сокращение расхода машинного времени и других ресурсов на отладку и сдачу задач в эксплуатацию;

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

увеличение объемов и сокращение сроков переработки информации;

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

снижение трудоемкости работ программистов при программировании прикладных задач с использованием новых ПС в организации - потребителе ПС;

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

3.2 Расчет затрат на проектирование и внедрение ПС

Из всех выше перечисленных расчетов экономической эффективности ПС наиболее приемлемым является расчет гарантированного экономического эффекта для конкретного объекта внедрения.

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

К=К_п + К_р, (3.1)

где К_п - капитальные вложения на проектирование;

К_р - капитальные вложения на реализацию проекта.

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

Капитальные вложения на проектирование ПС определяются путем составления смет расходов и включают следующие элементы:

· стоимость материалов (К_м);

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

· затраты, связанные с использованием машинного времени на отладку программы (К_маш);

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

Таким образом, капитальные вложения на проектирование (К_п) определяются по формуле 3.2:

К_п= К_м+ К_пр+ К_маш+ К_с+ К_н (3.2)

Все расчеты будут производиться в условных единицах (у.е.), что соответствует стоимости одного доллара США в Приднестровском Региональном Банке на момент разработки ПС.

1 Затраты на материалы

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

Таблица 3.1 - Смета затрат на материалы

Материал	Единица измерения	Цена за единицу (у.е.)	Количество	Сумма (у.е.)
Дискета	шт.	1	3	3
Бумага	кг.	2	0,5	1
Карандаш	шт.	0,2	1	0,2
Ручка	шт.	0,4	2	0.8
Резинка	шт.	0,1	1	0,1
Картридж для принтера	шт.	5	1	5

Итого : 10,1 у.е.

Транспортно-заготовительные расходы (5%) : 0,5 у.е.

Всего : 10,6 у.е.

2 Затраты на оплату труда

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

Дополнительная заработная плата начисляется в размере 10% от суммы основной заработной платы, а отчисления на социальные страхования - в размере 39% от фонда заработной платы. Смета затрат на оплату труда представлена в таблице 3.2.

Таблица 3.2 - Смета затрат на оплату труда

Должность работника	Должностной оклад (у.е.)	Дневная ставка	Занятость по теме	Сумма основной зарплаты (у.е.)
Программист	5	0,227	65	14,76
Руководитель проекта	70	3,18	65	206,70

Итого K_пр: 221,46 у.е.

3 Затраты на отладку программы

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

Затраты на отладку программы определяются по формуле

К_маш= С_мч* Т_отп * S_пр, (3.3)

где С_мч - стоимость одного часа машинного времени;

Т_отп- время отладки программы (ч);

S_пр - количество программистов.

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

С_мч = 0,1 у.е., Т_отл = 30 часов,

S_пр = 1 программист.

К_маш = 0,1 * 30 * 1 = 3 у.е.

4 Оплата сторонним организациям и накладные расходы

Затраты на оплату работ сторонним организациям не производились, поэтому коэффициент К_с равен нулю. Накладные расходы (К_н) на разработку НИР берутся в размере 45% от основной заработной платы разработчиков НИР для покрытия административно-хозяйственных и других не предусмотренных расходов.

К_н = 221,46 * 0,45 = 99,66 у.е.

3.2.2 Общая величина капитальных вложений на реализацию проекта

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

Таблица 3.3 - Общая смета затрат на проектирование

Статьи	Затраты
	Сумма(у.е.)	Удельный вес статьи в общей стоимости, %
Материалы и покупные полуфабрикаты	10,6	2,39
Основная заработная плата	221,46	49,96
Дополнительная заработная плата	22,15	5,00
Отчисления на соцстрах	86,37	19,49
Затраты на отладку программы	3	0,68
Накладные расходы	99,66	22,48

Итого: К_п = 443,24 у.е.

3.2.3 Расчет эксплуатационных затрат

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

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

Затраты, связанные с эксплуатированием задачи АСУ вычисляются по формуле 3.4:

С_фз = С_мч * Т_э, (3.4)

где С_мч - стоимость одного часа работы технических средств

Т_э - время эксплуатации задачи в течении года

Стоимость одного часа работы технических средств возьмем равную 0,1 у.е., а время эксплуатации задачи в течение года будет равно: Т_э=528 часов. Подставляя фактические значения в формулу 3.4, полученные в ходе опытной эксплуатации задачи, получаем величину годовых эксплуатационных расходов:

С_фз = 0,1 * 528 = 52,8 у.е.

3.3 Определение экономической эффективности внедренной задачи

Экономический эффект, как реальная экономия, обусловлена следующими факторами:

сокращение недостач и порчи технических средств;

сокращением потерь рабочего времени.

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

...