46620 (588405), страница 12

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

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

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

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

Программа реализована как совокупность HTML-страниц с PHP-вставками, с помощью которых и осуществляется доступ в БД и робота с ней.

Задача реализована как последовательность страниц, которые загружает клиент. Задача решается поэтапными процессами (регистрации клиента, заказа билетов, подтверждения заказа). Кроме того для менеджера по продаже формируется реестр подтвержденных заказов тоже через этап идентификации менеджера и процесс формирования самого реестра. Последний использует расчетные формулы (2.1., 2.2.). Алгоритм решения задачи приведен на рис. 2.7.

Рис. 2.7. Алгоритм решения задачи

2. Характеристика базы данных

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

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

Для определения структуры БД необходимо построить родовидовые списки реквизитов входных и исходных документов.

На рис. 2.8. изображена физическая модель БД.

1. Структурная схема пакета (дерево вызова программных модулей)

После анализа словаря данных была определена структура внутримашинной ИБ, которую составляют файлы НИИ и оперативные файлы. К файлам НИИ можно отнести файлы «категории билетов» (CATEGORY), «билеты» (PRODUCTS), «клиенты» (CUSTOMER), «сайты производителя» (SITE), «производитель» (PRODUCER), «характеристики билета» (PROPERTY), «пользователь системы» (MAN). К файлам оперативной информации относим соответственно файлы «заказа клиентов» (ORDERS), «билеты в заказах» (ORDER_DESC), «характеристика-значение» (PROD_PROP). Для каждого из файлов НИИ разработаны триггеры для обеспечения автоматического генерирования уникальных ключей таблицы.

Рис. 2.8. Физическая модель БД, используемая при автоматизации проекта

1. Описание программных модулей

Техническое описание программных модулей проекта приведено в Приложении 1.

Техническая сложность проекта (TCF - Technical Complexity Factor) вычисляется с учетом показателей технической сложности. Все показатели приведены в табл. 2.10.

Каждому показателю присвоено значение в диапазоне от 0 до 5 (0 помечает отсутствие значимости показателя для данного проекта, 5 - высокую значимость) и значение с условием веса показателя.

Таблица 2.10.

Показатели технической сложности

Показатель	Описание	Вес	Значение	Значение с учетом веса
T1	Распределённая система	2	2	4
T2	Высокая производительность (пропускная способность)	1	4	4
T3	Работа конечных пользователей в режиме он-лайн	1	5	5
T4	Сложная обработка данных	1	3	3
T5	Повторное использование данных	1	3	3
T6	Простота установки	0,5	4	2
T7	Простота использования|употребления|	0,5	5	2,5
T8	Переносная	2	5	10
T9	Простота внесения изменений|смен|	1	5	5
T10	Параллелизм	1	0	0
T11	Специальные требования к безопасности	1	4	4
T12	Непосредственный доступ к|до| системе со стороны внешних пользователей	1	5	5
T13	Специальные требования к обучению пользователей	1	0	0
Сумма				37,5

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

Формула 2.2.

TCF=0,6+(0,01*(oTi*Вагаi))

Следовательно, рассчитаем значение TCF для модуля регистрации:

Формула 2.2.

TCF=0,6+(0,01*37,5) = 0,975

1. Технологическое обеспечение задачи

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

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

Пользователь-клиент загружает страницу магазина, где регистрируется или идентифицируется, выбирает категорию билетов, кладет билеты в «корзину» и делает заказ.

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

Сценарий диалога менеджера с системой приведен рис. 2.9. Как здесь видно также есть деление режимов работы с системой. Есть формы для работы клиента и формы для менеджера.

1. Схемы технологического процесса сбора, передачи, обработки и выдачи информации

Для клиента системы необходимо иметь любую ОС, в состав которой входит браузер с поддержкой графического интерфейса. Браузер должен обеспечивать поддержку стандартов: HTML 4, DOM CSS2.

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

Рис. 2.9. Сценарий диалога менеджера с системой

На экране постепенно появится страница каталога билетов, на которой слева находится перечень наименований каталога, панель для поиска билета по названию и «корзина» пользователя.

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

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

Для добавления билета в «корзину» нужно нажать на ссылку, которая расположена слева от наименования билета. После этого с левой стороны появится панель «корзина», на которой и будет изображаться её состав.

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

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

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

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

Если клиент не проходил идентификацию, будет выведено соответствующее сообщение.

После подтверждения, заказ будет записан в БД.

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

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

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

1. Контрольный пример реализации проекта и его описание

В качестве примера автоматизации реализации билетов можно привести результат работы ООО «Зритель», т.е. вариант билета и инструкции к нему (рис. 2.10., 2.11.).

Рис. 2.10. Вид квитанции подтверждения заказа билета

Рис. 2.11. Вид самого билета

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

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

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

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

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

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

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

1. абсолютное снижение трудовых затрат (Т) в часах за год:

Т = Т0 - Т1

где,

Т0 - трудовые затраты в часах за год на обработку информации по базовому варианту;

Т1 - трудовые затраты в часах за год на обработку информации по предлагаемому варианту;

1. коэффициент относительного снижения трудовых затрат (КТ):

КТ =Т / T0 * 100%

1. индекс снижения трудовых затрат или повышение производительности труда (YT):

YT = T0 / T1

К стоимостным показателям относятся: абсолютное снижение стоимостных затрат (C) в рублях за год, коэффициент относительного снижения стоимостных затрат (КC) индекс снижения стоимостных затрат (YC), рассчитываемые аналогично.

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

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

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

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

Предположения о доходах от реализации проекта делаются на базе составления сметы проекта, с одной стороны, а с другой — исходят из прогноза финансовой и рыночной ситуации (какой сектор рынка может занять разрабатываемое изделие, какие цены на него целесообразно установить и т.д.). Они формулируются в ходе предпроектной деятельности, а затем проверяются при выполнении фазы оценки (после прохождения контрольной точки 7 «Тестирование завершилось, начата подготовка новой итерации» жизненного цикла), т.е. когда планы и достижения могут быть сопоставлены более точно. Смета и оценка конъюнктуры рынка делаются на каждой итерации процесса развития проекта.

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

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