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

Текст из файла (страница 6)

Преимущества трехзвенной архитектуры

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

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

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

4.3 HTML прототипы

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

Для данной Системы прототипы разрабатывались в среде интегрированной разработки Delphi 2006. Дело в том, что к моменту реализации Системы вышла новая версия Delphi, немного более удобная предыдущей в отношении проектирования ASP.NET страниц.

На данном рисунке представлен прототип окна входа в систему (авторизации):

На данном рисунке представлен прототип окна просмотра Приходных накладных:

Для конечного пользователя прототипы компилировались в HTML страницы:

4.4 Бизнес логика

Бизнес логика – это набор правил, по которым Система должна отвечать на тот или иной запрос пользователя.

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

Бизнес логика реализовывалась на языке Delphi в одноименной среде разработки. Для соединения с базой данных использовались компоненты SqlConnection, SqlDataAdapter, DataSet, SqlCommand:

4.5 Разработка интерфейса пользователя

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

Глава 5: Экономический эффект

5.1 План анализа экономической эффективности

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

1. Технико-экономическое обоснование разработки ПО;

2. Расчет затрат на разработку ПО;

3. Стоимость внедрения ПО Заказчиком;

4. Расходы заказчика при эксплуатации ПО;

5. Эффективность внедрения для Заказчика ПО;

6. Правовые аспекты.

5.2 Технико-экономическое обоснование разработки ПО.

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

Выбор пал именно на разработку, а не приобретение соответствующего ПО по ряду причин:

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

• неприемлемая политика лицензирования аналогов – с ростом количества пользователей растёт стоимость системы. Думая о своей web-системе, заказчик понимал, что при росте пользователей в разумных рамках она не потребует никаких доработок.

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

5.3 Расчет затрат на разработку ПО

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

Затраты на разработку

Поскольку Система разрабатывалась полностью по методологии RUP, было решено отказаться от традиционной системы оценки затрат (ТЗ, эскизный проект, технический проект, рабочий проект, внедрение) в пользу более приемлемой методики. Фазы и содержание работ представлены в таблице 6.1:

Таблица № 6.1

На создание Системы было потрачено 92 рабочих дня или 4 полных месяца.

Оценка затрат включает 3 основных пункта:

• фонд оплаты труда

• приобретение инструментария

• использование Интернет

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

Фонд оплаты труда

В проекте был задействован 2 разработчика. Месячная зарплата установлена в размере 10 тысяч рублей. В их обязанности входили все фазы разработки: от исследования до документации. Затраты на оплату труда составили:

2 * 4мес. * 10000руб. = 80000руб.

Приобретение инструментария

Согласно методологии Borland ALM использовался программный пакет, состоящий из следующих приложений, представленных в таблице 6.2:

Таблица 6.2

(*) примерная цена, т.к.официально продукт еще не продается

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

Использование Интернет

Месячная абонентская плата за использование Интернет составила (таблица 6.3):

Таблица № 6.3

Суммарные затраты обоих разработчиков на Интернет – 4196 рублей.

Агрегация

Теперь объединим единовременные затраты на разработку (таблица 6.4):

Таблица № 6.4

Таким образом, в случае коммерческого использования Системы совокупные затраты на разработку составят 204316 рубелей.

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

5.4 Стоимость внедрения ПО Заказчиком

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

1. Стоимость программного обеспечения специально разработанного для заказчика. В этом случае стоимость равна себестоимости плюс прибыль разработчика (на практике обычно составляет 20-30% от себестоимости), а также налог на добавленную стоимость 20%. Для расчета можно использовать следующую формулу , где - себестоимость ПО, - прибыль разработчика, - налог на добавленную стоимость. Стоимость, рассчитанная по такой формуле становиться слишком высока, поэтому было принято решение распространять созданную систем как тиражируемое ПО. После расчетов, сделанных другим разработчиком было определено, что стоимость лицензии на один компьютер будет составлять 2000 рублей. Итого за 18 компьютеров стоимость покупки программного обеспечения будет составлять 36000.

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

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

4. Стоимость обучения персонала организации на освоение ПО и обучение персонала работе с программой. Расчет производиться по следующей формуле: , где - численность персонала на обучение, - стоимость обучения одного человека в день, - время обучения. Предполагается, что в организации заказчика системой будут пользоваться 4 человека: 3 менеджера и 1 администратор. Время необходимое для обучения предположительно оценивается в два рабочих дня. Стоимость обучения одного человека в день 500 рублей. Итого получается затраты на обучение персонала 4000 рублей.

5. Стоимость первоначальной настройки Системы. Для этого требуется один рабочий день администратора. Исходя из его однодневного заработка затраты будут оцениваться в 320 рублей.

5.5 Расходы заказчика при эксплуатации ПО

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

1. Расходы, связанные с заработной платой менеджерам и администраторам за дополнительную нагрузку, связанную с эксплуатацией Системы. Будем считать, что менеджер будет тратить на работу 1 час в неделю, администратор – 3 часа в неделю. Заработная плата менеджера в час оценивается 80 рублей, администратора – 45 рублей. После расчетов эксплуатация Системы в год будет обходиться в 13680 рублей.

2. Расходы, связанные с сопровождением системы. Стоимость сопровождения оценивается в 5000 рублей в год.

Данные по расходам эксплуатации ПО представлены в таблице 6.5:

Характеристики

Список файлов ВКР