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

Рис. 2.1 Функциональная структура предприятия

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

На следующем этапе моделирования бизнес-процессов будет подробно рассмотрена предметная область и построена функциональная модель в нотации IDEF0.

2.3 Построение модели предметной области «Как есть» (AS-IS)

Необходимым условием построения модели системы является сбор данных о функционировании предприятия и возможно о уже существующей информационной системе. После анализа предприятия, его документооборота, функций и т.д. строится модель «Как есть» (AS-IS). Т.е. модель предприятия и его информационной системы в текущем состоянии. На основе этой модели принимается решение об оптимизации бизнес процессов и предполагается, как будет использована новая информационная система. После чего строиться модель «Как надо» (TO-BE).

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

Цель: моделирования текущих бизнес-процессов софтверной компании.

Точка зрения: директор предприятия

Ниже, на рис. 2.2 представлена контекстная диаграмма. Данная диаграмма является исходным отображением функционирования web студии.

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

Рис. 2.2 Взаимодействия производственной деятельности предприятия с внешней средой

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

Рис. 2.3 Производственная деятельность компании

Как видно из представленной диаграммы, организация производственной деятельности предприятия состоит в выполнении 4 видов работ: организации работы с заказчиками, организации разработки, организации бухгалтерского учёта, организации управления кадрами. Для дальнейшего анализа наибольший интерес для нас представляют все работы, исключая «Организацию бухгалтерского учёта».

Организация управления кадрами подразумевает собой все работы, связанные с сотрудниками: приём на работу, увольнение, рассмотрение просьб на получение отпусков и отгулов и т.п. В более подробном рассмотрении эта работа не нуждается. Более подробно рассмотрим же организацию работы с заказчиками (рис. 2.4).

Рис. 2.4 Организация работы с заказчиками

Организация работы с заказчиками включает в себя: анализ заказа, подготовку ТЗ, оформление договоров на выполнение заказа. Все эти операции выполняет менеджер отдела заказов.

Теперь рассмотрим «Организацию разработки» (см. рис. 2.5, 2.6). На этих диаграммах можно видеть, какие работы выполняются, на каждом из уровней декомпозиции и какие документы фигурируют в бизнес-процессе.



Рис. 2.5 Организация разработки

Рис. 2.6 Процедура составления проектных планов

2.4 Построение оптимизированной модели предметной области «Как надо» (TO-BE)

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

Цель: Моделирование разрабатываемых бизнес-процессов web студии.

Точка зрения: аналитик.

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

Рис. 2.7 Контекстная диаграмма модели «Как надо»

Первый уровень декомпозиции представлен на рис. 2.8

Рис. 2.8 Второй уровень декомпозиции модели «как надо»



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

Рис. 2.9 Организация управления кадрами

Теперь рассмотрим подробно организацию работы с заказчиками. На рис. 2.10 представлена диаграмма декомпозиции этой работы.



Рис. 2.10 Организация работы с заказчиками

До использования информационной системы менеджер отдела заказов выполнял все работы «вручную» и его действия не были формализованы. Внедрение ИС позволяет проводить анализ заказа по известным шаблонам, что упрощает работу менеджера и делает её эффективнее. На основе анализа проекта частично формируется ТЗ и договор на выполнение. Для примера рассмотрим более подробно процесс анализа заказа. На рис. 2.11 представлена диаграмма IDEF3 декомпозиции «Анализа заказа».

Рис. 2.11 Процедура анализа заказа

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

2.5 Построение модели информационной системы на языке «ДРАКОН»

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

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

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

Для обозначения блок-схем, построенных по правилам языка Дракон, используется термин «дракон-схемы», они удовлетворяют критерию сверх высокой понимаемости.

Дракон-схема с ветками называется «силуэтом», без веток -- «примитивом».

«Примитив» есть последовательное соединение иконы «заголовок» шампур-блоков и иконы «конец». У примитива иконы «заголовок» и «конец» обязательно лежат на одной вертикали, которая называется шампуром. На этой же линии лежат главные вертикали шампур-блоков. Образно говоря, шампур пронизывает иконы примитива. «Примитив» рекомендуется использовать, если дракон-схема очень простая (примитивная) и содержит не более 5...15 икон. В противном случае, чтобы улучшить читаемость программы, выгоднее использовать «силуэт». Таким образом, в сложных случаях «силуэт» позволяет существенно уменьшить интеллектуальные усилия, затрачиваемые на понимание алгоритма. В «силуэте» крупные структурные части программы (ветки) четко выделены, они пространственно разнесены в поле чертежа, образуя вместе с тем легко узнаваемый, стабильный, предсказуемый и целостный зрительный образ.

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

Разработанная модель будет отражать процесс приёма заказа и подбора группы разработчиков, т.к. этот процесс затрагивает не только работников фирмы, но и заказчиков. Исходя из выводов сделанных в разделе 1 именно этому процессу следует уделить наибольшее внимание. На рис. 2.12 представлена ДРАКОН-схема приёма заказа.

Рис. 2.12 ДРАКОН-схема приёма заказа

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

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

3. РАЗРАБОТКА ПРОЕКТА ИНФОРМАЦИОННОЙ СИСТЕМЫ УПРАВЛЕНИЯ ЗАКАЗМИ

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

3.1 Модель информационной системы в объектно-ориентированных нотациях языка UML

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

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

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

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

Моделирование контекста системы состоит из следующих шагов:

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

2. Организация похожих актеров с помощью отношений обобщения/специализации.

3. Введение стереотипов для каждого актера, если это облегчает понимание.

4. Помещение актеров на диаграмму прецедентов и определение способов их связи с прецедентами системы.

Для достижения понятности диаграммы разобьём разрабатываемую систему на три подсистемы: подсистема отдела заказов, подсистема отдела производства, подсистема отдела кадров. Ниже, на рис. 3.1, 3.2, 3.3, представлены диаграмма прецедентов для каждого отдела.

Рис. 3.1 «Use-case» диаграмма отдела заказов

Рис. 3.2 «Use-case» диаграмма отдела кадров



Рис. 3.3 «Use-case» диаграмма отдела разработки

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

3.2 Выбор архитектуры информационной системы

По способу организации ИС имеют следующие виды;

· архитектура файл-сервер;

· архитектура клиент-сервер;

· многоуровневая система;

· на основе интернет/интранет-технологий.

Рассмотрим более подробно особенности архитектуры построения информационных приложений.

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

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

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

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

Многоуровневая архитектура стала развитием архитектуры клиент-сервер и в классической форме состоит из трех уровней;

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

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

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

Подобную концепцию обработки данных пропагандируют, в частности, фирмы Oracle, Sun, Borland и д.р. [4]

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

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

Интернет/интранет - технологии основной акцент пока что делается на разработке инструментальных средств. В то же время наблюдается отсутствие развитых средств разработки приложений, работающих с базами данных. Компромиссным решением для создания удобных и простых в использовании и сопровождении информационных систем, эффективно работающих с базами данных, стало объединение интернет/интранет-технологии с многоуровневой архитектурой. При этом структура информационного приложения приобретает следующий вид: браузер - сервер приложений - сервер баз данных - сервер динамических приложений - web-сервер. [4]

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

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

Таблица 3.1

Сравнительная характеристика архитектуры ИС

Параметры сравнения	Файл-сервер	Клиент-сервер	Многоуровневая система	Интернет/интранет технологии
Установка СУБД	На клиентском компьютере	Отдельный сервер	Несколько отдельных серверов	Несколько отдельных серверов
Объемы передаваемых данных	Малые	Большие	Очень большие	Очень большие
Применяемые на предприятии	Нет	Да	Нет	Нет
Знакомство обслуживающего персонала с представленными архитектурами	Да	Да	Нет	Нет

Проведем расчет выбора архитектуры ИС по выбранным параметрам на основании технико-экономической эффективности.

Оценим их по каждому i-ому показателю качества по 5-ти бальной шкале.

Определим каждому критерию весовой коэффициент k_j, причем k_j= 1.

Таблица 3.2

Шкала оценок

Параметр	Баллы	Оценка
	4	Отлично
	3	Хорошо
	2	Удовлетворительно
	1	Предельно допустимо
	0	Неприемлемо

Результаты сравнения сведем результаты сравнения в таблицу 3.3.

Таблица 3.3

Оценка технико-экономической эффективности

Параметры сравнения/оценка	Весовой коэффициент	Файл-сервер	Клиент-сервер	Многоуровневая система	Интернет/интранет технологии
		Ajf	kj •Ajf	Ajk	kj •Ajk	Ajm	kj •Ajm	Aji	kj •Aji
Установка СУБД	0,15	1	0,15	4	0,6	3	0,45	3	0,45
Объемы передаваемых данных	0,25	1	0,25	3	0,75	4	1	4	1
Применяемые на предприятии	0,35	0	0	4	1,4	0	0	0	0
Знакомство обслуживающего персонала с представленными архитектурами	0,25	2	0,5	3	0,75	1	0,25	1	0,25
Интегральный технико-экономический показатель, Q		Qf = 0,9	Qk = 3,5	Qm = 1,7	Qi = 1,7

Посчитаем интегральный технико-экономический показатель:

для файл-сервера Q_f:

для клиент-сервер Q_k:

для многоуровневой системы Q_m:

для интернет/интранет технологии Q_i:

Интегральный технико-экономический показатель между файл-серверной архитектурой и клиент-серверной равен:

Q = Q_k/ Q_f = 3,5/0,9 = 3,89

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

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



Q = Q_k/ Q_m = 3,5/1,7 = 2,06

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

Интегральный технико-экономический показатель между клиент-серверной архитектурой и интернет/интранет технологии равен:

Q = Q_k/ Q_m = 3,5/1,7 = 2,06

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

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

3.3 Разработка логической и физической структуры БД

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

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

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

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

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

Рис. 3.4 Логическая модель данных

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



Таблица products Таблица categories Таблица orders

Проекты категории товаров данные о покупателе

Таблица ordered_cats

заказы

Рис. 3.5 Физическая структура базы данных



4. РЕАЛИЗАЦИЯ ВЫБРАННОГО ВАРИАНТА РЕШЕНИЯ

4.1 Обоснование выбора СУБД

Требования, предъявляемые к СУБД должны соответствовать условиям и требованиям заказчика, одним из требований является экономическая составляющая, т.е. относительная дешевизна продукта.

Рассмотрим некоторые из представленных на рынке СУБД, сведённых в таблицу 4.1.

Таблица 4.1

Сравнение СУБД

Название критерия выбора	SQL Server 2000	ORACLE 10g	MySQL
Стоимость сервера (лицензия на процессор и на сам сервер)	5448$	4995$	Общедоступная
Стоимость клиента	146$	149$	Общедоступная
Максимальное число пользователей	Зависит от лицензии	Зависит от лицензии	Зависит от лицензии
Технические требования к серверу	166 Мгц 64 Мб ОЗУ 140-500 Мб на HDD	300 Мгц 128 Мб ОЗУ 1,5 Гб на HDD	100 Мгц 64 Мб ОЗУ 100 Мб на HDD
Поддерживаемые серверные ОС	Windows 2000 Server, Windows 2000 Advanced Server, Windows 2000 Datacenter Server, Windows NT Server 4.0, Windows NT Server 4.0 Enterprise Edition	Windows 2000 Server, Windows 2000 Advanced Server, Windows 2000 Datacenter Server, Windows NT Server 4.0, Windows NT Server 4.0 Enterprise Edition, UNIX-подобные системы.	Windows 2000 (SP2), Windows Server 2003, Windows NT® 4.0 (SP6a или выше), Windows XP Red Hat Enterprise Linux, SUSE Enterprise Linux Server 9 Solaris 7, 8, 9
Степень защищенности хранения данных	Средняя	Высокая	Средняя

На основании выбранных критериев проведем расчет технико-экономической эффективности MySQL, SQL Server 2000, ORACLE 10g.

Оценим их по каждому i-ому показателю качества по 5-ти бальной шкале.

Таблица 4.2

Шкала оценок

Параметр	Баллы	Оценка
	4	Отлично
	3	Хорошо
	2	Удовлетворительно
	1	Предельно допустимо
	0	Неприемлемо

Определим каждому критерию весовой коэффициент k_j, причем k_j= 1.

Результаты сравнения сведем результаты сравнения в таблицу 4.3

Посчитаем интегральный технико-экономический показатель:

для SQL Server 2000 Q_s:

,

для ORACLE 10g Q_d:

и для MySQL:



Таблица 4.3

Оценка технико-экономической эффективности

Параметры сравнения/оценка	Весовой коэффициент	MySQL	SQL Server 2000	ORACLE 10g
Стоимость сервера	0,15	4	0,6	1	0,1	1	0,2
Стоимость клиента	0,10	4	0,40	3	0,30	3	0,3
Максимальное число пользователей	0,10	3	0,3	3	0,3	3	0,3
Технические требования к серверу	0,15	3	0,45	2	0,3	1	0,15
Поддерживаемые серверные ОС	0,05	3	0,15	4	0,2	3	0,15
Степень защищенности хранения данных	0,20	4	0,8	2	0,4	1	0,2
Интегральный технико-эконом. показатель, Q	=1		Qa= 3,7		Qs = 2,1		Qo = 1,8

Интегральный технико-экономический показатель между MySQL и SQL Server 2000, равен:

Q = Q_a/ Q_s = 3,7/2,1 = 1,76

Между MySQL и ORACLE 10g, равен:

Q = Q_a/ Q_o = 3,7/1,8 = 2,06

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

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

4.2 Обоснование выбора средств реализации

Выбор средства разработки приложений был основан на сравнении Borland Delphi 2007, C++Builder 2007, и C#(MS Visual Studio 2007) (Таблица 4.4).

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

Новая версия продукта C++Builder 2007, ведущей интегрированной среды для быстрой разработки приложений на С++, сочетает поддержку операционной системы Windows Vista API и технологий Web 2.0 с самыми последними стандартами: значительно выросшей производительностью, интегрированными функциями проверки и множеством сочетаний клавиш, позволяющих экономить время и значительно упрощать выполнение типовых задач.

C#(MS Visual Studio 2007) - являясь последним из широко распространенных языков программирования, впитал в себя весь имеющийся опыт и вобрал лучшие стороны существующих языков программирования, при этом являясь специально созданным для работы в NET. Сама архитектура NET продиктовала ему объектно-ориентированную направленность. При этом сразу выделаются такие особенности, как возможность объявлять несколько классов в одном файле, из чего следует синтаксическая поддержка иерархической системы пространств имен. Из вещей, включенных в спецификацию языка, но не являющихся чисто "программистскими" необходимо отметить возможность использование комментариев в формате XML. Если комментарии отвечают специально описанной структуре, компилятор по ним может сгенерировать единый XML-файл документации.

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

Таблица 4.4

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

Критерии сравнения	Borland Delphi 2007	C++Builder 2007	C#(MS Visual Studio 2007)
Степень соответствия назначения языка и целей разработки	Ориентирован на разработку систем любой степени сложности	Ориентирован на разработку систем любой степени сложности	Ориентирован на разработку систем любой степени сложности
Использование международных стандартов	Имеет собственный стандарт	Полностью стандартизирован	Полностью стандартизирован
Поддерживаемые СУБД	Inter Base 7.5, Oracle, IBM DB2, Microsoft SQL Server 2000/2005, Informix, SQL Anywhere, MySQL, Sybase	MS SQL Server 2000/2005, My SQL, Oracle, Sybase, Interbase 2007, SQL Anywhere, DB2, Informix	Inter Base 7.5, Oracle, IBM DB2, Microsoft SQL Server 2000/2005, Informix, SQL Anywhere, MySQL, Sybase
Поддерживаемые ОС	Microsoft Windows 2000/ XP Professional (SP2 или выше)/ Vista Professional/ Microsoft Windows Server 2003.	Windows Vista/ Server 2003/ XP Professional/ 2000 Professional / 2000 Server	MS Windows OC
Квалификация разработчиков	Высокая	Высокая	Высокая
Стоимость продукта	900 у.е.	900 у.е.	900 у.е.

Проведем расчет выбора архитектуры ИС по выбранным параметрам на основании технико-экономической эффективности.

Оценим их по каждому i-ому показателю качества по 5-ти бальной шкале.

Определим каждому критерию весовой коэффициент k_j, причем k_j= 1.

Таблица 4.5

Шкала оценок

Параметр	Баллы	Оценка
	4	Отлично
	3	Хорошо
	2	Удовлетворительно
	1	Предельно допустимо
	0	Неприемлемо

Результаты сравнения сведем результаты сравнения в таблицу 27.

Посчитаем интегральный технико-экономический показатель:

для C++Builder 2007 Q_c:

для Borland Delphi 2007 Q_b:

для C#(MS Visual Studio 2007) Q_#:

Интегральный технико-экономический показатель между C#(MS Visual Studio 2007) и C++Builder 2007 равен:

Q = Q_#/ Q_c = 3,6/2,75 = 1,31

т.к. технико-экономический показатель больше 1 выбор в сторону C#(MS Visual Studio 2007).

Таблица 4.6

Оценка технико-экономической эффективности

Параметры сравнения/оценка	Весовой коэффициент	C++Builder 2007	Borland Delphi 2007	C#(MS Visual Studio 2007)
		Ajk	kj •Ajk	Ajm	kj •Ajm	Aji	kj •Aji
Степень соответствия назначения языка и целей разработки	0,25	3	0,75	2	0,5	4	1
Использование международных стандартов	0,10	2	0,2	2	0,2	3	0,3
Поддерживаемые СУБД	0,20	2	0,4	2	0,4	3	0,6
Поддерживаемые ОС	0,15	2	0,3	3	0,45	4	0,6
Квалификация разработчиков	0,2	4	0,8	4	0,8	4	0,8
Стоимость продукта	0,1	3	0,3	3	0,3	3	0,3
Интегральный технико-экономический показатель, Q		Qc = 2,75	Qb = 2,65	Q# = 3,6

Интегральный технико-экономический показатель между C#(MS Visual Studio 2007) и Borland Delphi 2007равен:

Q = Q_#/ Q_b = 3,6/2,65 = 1,36

т.к. технико-экономический показатель больше 1 выбор в сторону C#(MS Visual Studio 2007).

Вывод: Borland Delphi 2007 более удобная и доступная для нас среда и является наиболее подходящей по критериям оценки.



5. СОЦИАЛЬНАЯ ЗНАЧИМОСТЬ ПРОЕКТА

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

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

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

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



6. ТЕХНИКО-ЭКОНОМИЧЕСКОЕ ОБОСНОВАНИЕ ПРОЕКТА

6.1 Расчет затрат на проектирование

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

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

t_o = (3t_min +2t_max)/5,

где t_о - ожидаемая длительность работ;

t_min, t_max - наименьшая и наибольшая по мнению эксперта длительность работ.

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

Таблица 6.1

Длительность всех работ на этапе проектирования

Наименование работ	Длительность работ (дней)	Расход машинного времени
	tmin	tmax	t0	tM
1. Разработка ТЗ	8	12	5,2	-
2. Анализ ТЗ	5	7	3,8	-
3. Поиск и изучение литературы	3	8	5,0	-
4.Обзор существующих аналогов системы;	7	14	9,8	-
5. Разработка основных этапов работы	9	11	5,8	-
6. Разработка алгоритма	10	14	11,6	-
7. Разработка программы	25	40	31,0	190
8. Отладка работы программы	21	31	25,0	100
9. БЖ и экологичность разработки	10	15	7,0	35
10. Технико-экономическое обоснование работы	9	14	5,8	30
11. Оформление пояснительной записки	6	10	12,0	80
Итого:	113	176	139,2	435

Для определения продолжительности этапа проектирования Т_П по данным табл. 6.1 построим график организации работ во времени (см. рис. 6.1).

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

Рис. 6.1 Ленточный график

Так как некоторые процессы можно проводить параллельно, общая продолжительность работ уменьшается. По графику видно, что общее время проектирования Т_П=130 дней.

Капитальные затраты на этапе проектирования К_п рассчитываются по формуле:

K_П = Z_П + M_П + Н_П,

где Z_П - заработная плата проектировщика задачи на всем этапе проектирования;

M_П - затраты на использование ЭВМ на этапе проектирования;

Н_П - накладные расходы на этапе проектирования.

Одним из основных видов затрат на этапе проектирования является заработная плата проектировщика, которая рассчитывается по формуле:

где Z_д - дневная заработная плата разработчика задачи на этапе проектирования;

А_с - процент отчислений на социальное страхование (26%);

А_п - процент премий.

Средняя дневная плата рассчитывается по формуле:

Z_д= ОК / Д_р,

где: ОК - оклад разработчика (5000 руб.);

Д_р - среднее число рабочих дней (21 дней);

Получим,

Z_д== 15000 / 21 = 714 руб.

Отсюда,

Z_П = 714130 (1+0,07)(1+0,26) = 125140 руб.

Стоимость одного часа машинного времени примем 3 руб, тогда затраты на использовании ЭВМ равны:

М_П = С * 435 = 3 * 435 = 1035 руб.

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

Н_П= Z_П * 0,8 = 100112

Таким образом, капитальные затраты на этапе проектирования продукта составят:

К_П= 125140 + 1035 + 100112 =226287.



6.2 Расчет эксплуатационных расходов

В эксплуатационные расходы входят:

· содержание персонала, занятого работой с программой;

· расходы на функционирование программы;

· накладные расходы;

· прочие расходы.

Стоит заметить, что внедрение информационной системы не повлияет на сокращение работников. Экономия при использовании данной системы будет состоять лишь в том, насколько будет увеличена эффективность после использования ИС. Чтобы это отразить в расчетах, примем, что на текущий набор проектов до внедрения ИС требовалось n₁ работников, а после внедрения с этими проектами могут справиться n₂ работников. Расходы по различным видам работающих определяются по формуле:

где n_i - численность персонала i - вида;

z_i - среднегодовая заработная плата работника i-го вида;

а_c - процент отчислений на социальное страхование, пенсионный фонд и фонд стабилизации (обычно a_c = 26,6%);

а_п - средний процент премий за год.

До внедрения программы: n₁=50, z₁=180000 руб., а₁=10%. Следовательно:

Z₁ = 50 * 180000 * (1+0,26) * (1+0,1) = 12474000

После внедрения программы: n₂=30, z₂=180000 руб., а₂=10%. Значит:

Z₂ = 30 * 180000 * (1+0,26) * (1+0,1) = 7484400

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

Расходы на функционирование программы

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

М = С * t,

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

t - необходимое для решения задачи машинное время (в часах).

При условии, что до внедрения программы компьютеры не использовались, М₁=0. Если стоимость одного часа работы составляет 3 рублей, а программа работает 720 часов в год, то М₂ = 3 * 720 = 2160 руб.

Накладные расходы

Накладные расходы составляют 80% от основной зарплаты персонала, занятого эксплуатацией программы. Т.о., накладные расходы составляют в год:

- - до использования программы:

12474000* 0,8 = 9979200

- после внедрения программы:

334224 * 80 / 100 = 5987520

Прочие расходы:

Прочие расходы составляют 2% от суммы всех эксплуатационных расходов.

До внедрения программы: (12474000+ 2160 + 9979200) * 0,02 = 449107 руб.

После внедрения программы: (7484400+ 2160 + 5987520) * 0,02 = 269481 руб.

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

Р₁ = 12474000 + 2160 + 9979200 + 449107 = 22902467 руб.

Р₂ = 7484400 + 2160 + 5987520 + 269481 = 13743561 руб.

6.3 Расчет экономии от увеличения производительности труда пользователя

Если пользователь при выполнении работы j-го вида после использования системы экономит Т_j часов, то повышение производительности труда Р_j (в процентах) определяется по формуле:

p_j = (?T_j / (t_j - ?T_j)) * 100

где t_j - время, которое планировалось пользователю для выполнения работы j-того вида до внедрения разработанной системы (в часах);

Т_j - экономия машинного времени при использовании разработанной программы (в часах).

Т_j и t_j должны быть определены в среднем за год.

В нашем случае затрачиваемое на решение без использования программы время составляет 1620 часа, с использованием программы - 720 часа, то есть экономия составляет 900 часов в год. Таким образом,

Р_j = (900 / (1620 - 900)) * 100 = 125%

Экономия, связанная с повышением производительности труда пользователя, определяется как

Р_п = Z_п Р_j / 100,

где Z_п - среднегодовая заработная плата пользователя при использовании разрабатываемого проекта.

Экономия от увеличения производительности труда пользователя равна.

Р_п = 7484400 * 1,25 = 9355500

6.4 Расчет экономического эффекта от использования системы

Критерием эффективности создания и внедрения новых методов является ожидаемый экономический эффект. Он определяется по формуле:

Э = Э_г - Е_нК_п,

где Э_г - годовая экономия;

Е_н - нормативный коэффициент (Е_н = 0,15);

К_п - капитальные затраты на проектирование (см. главу 6.2).

Годовая экономия Э_г складывается из экономии эксплуатационных расходов и экономии в связи с повышением производительности труда пользователя (см. главу 6.3):

Э_г = (Р₁ - Р₂) + Р_n,

где Р₁ и Р₂ - соответственно эксплуатационные расходы до и после внедрения разрабатываемой программы;

Р_n - экономия от повышения производительности труда пользователя.

Годовая экономия будет равна:

Э_г = (22902467 - 13743561) + 9355500 = 18514406 руб/год.

Таким образом, ожидаемый экономический эффект составит:

Э = 18514406 - 0,15 * 226287= 18480462

6.5 Сопоставление технико-экономических характеристик разработки с аналогом

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

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

1. количественные параметры - быстродействие.

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

3. новые возможности - автоматизация.

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

Выбранные критерии сведены в таблицу.

Таблица 6.2

Перечень критериев для сравнения разработки и аналога

Количественные параметры	Качественные параметры	Новые возможности
1. Защищенность 2. Надежность	3. Удобство пользования 4. Оперативность получения результатов	5. Автоматизация

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

Расчет сравнительной технико-экономической эффективности аналога и разработки

Оценим качество аналога и разработки по каждому i-ому показателю качества по 5-ти бальной шкале. Предлагается следующая шкала оценок.



Таблица 6.3

Шкала оценок

Параметр	Баллы	Оценка
	4	Отлично
	3	Хорошо
	2	Удовлетворительно
	1	Предельно допустимо
	0	Неприемлемо

Определим каждому критерию весовой коэффициент k_j, причем k_j= 1.

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

,

и для разработки:

Таблица 6.4

Оценка технико-экономической эффективности

Параметр, оценка	Весовой коэффициент	Аналог	Разработка
Защищенность	0,35	3	1,05	4	1,4
Надежность	0,25	1	0,25	3	0,75
Удобство пользования	0,10	2	0,20	4	0,40
Оперативность получения результатов	0,20	1	0,20	3	0,60
Автоматизация	0,10	1	0,1	4	0,4
Интегральный технико-экономический показатель, Q		Qа = 1,80	Qр = 3,55

Интегральный технико-экономический показатель, таким образом, равен:

Q = Q_h / Q_a = 3,55 / 1,8 = 1,97.

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



7. БЕЗОПАСНОСТЬ И ЭКОЛОГИЧНОСТЬ РАЗРАБОТКИ ИНФОРМАЦИОННОЙ СИСТЕМЫ

7.1 Электробезопасность

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

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

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

Значение силы тока, проходящего через организм человека, зависит от напряжения, под которым находится человек и от сопротивления участка тела, к которому приложено это напряжение. Учитывая, что большинство поражений происходит при напряжении 127, 220 и 380В, а пробой кожи начинается при напряжении 40-50В, в качестве безопасного напряжения переменного тока в нашей стране выбрано 42В, 110В для постоянного тока.

Основными причинами электротравматизма являются:

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

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

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

Эксплуатация комплекса предполагается на ПЭВМ. Источником питающего напряжения является сеть переменного тока с напряжением 220В, на которую распространяется ГОСТ 25861-83.

В соответствии с требованиями для предупреждения поражений электрическим током необходимо:

· Чётко и в полном объёме выполнять правила производства работ и правила технической эксплуатации.

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

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

· Подводить электропитание к ПЭВМ от розетки здания при помощи специальной вилки с заземляющим контактом.

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

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

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

7.2 Требования к уровню шума и вибрации

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

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

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

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

Оптимальные показатели уровня шумов в рабочих помещениях конструкторских бюро, кабинетах расчетчиков, программистов определяются по ГОСТ 12.1.003-83.

Характеристики постоянного шума - уровни звукового давления в децибелах в октавных полосах со среднегеометрическими частотами в герцах приведены в табл. 7.1.

Таблица 7.1

Уровни звукового давления в октавных полосах

Уровень, дБ	63	152	250	500	1000	2000	4000	8000
Частота, Гц	71	61	54	49	45	42	40	38

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