Автоматизация бизнес-процессов продажи билетов ООО "Зритель"

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

Дt = (1 + б) t,

гдеб--дисконт (число из интервала 0…1),

t--время платежа, указываемое от начала проекта.

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

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

Распределение предоставляемых финансовых средств:

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

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

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

Неутверждённые сметы возможно в трех случаях:

· при обнаружении в ней разного рода ошибок;

· при нарушении общего баланса: суммарные расходы превышают суммарные плановые доходы;

· при локальном (в какие-либо периоды) расхождении предоставляемых средств с объявленной в смете потребностью.

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

Если по смете выходит, что суммарные расходы превышают суммарные плановые расходы (случай 2), то менеджер должен попытаться объяснить руководству причины расхождений и попытаться обосновать предложенный вариант расходов. Если обоснование менеджера принимается, то руководство решает, фирма или заказчик должны нести дополнительные (сверхсметные) расходы. Варианты распределения дополнительных расходов, предлагаемых заказчику, могут быть различными: оплата счетов, включение в итоговые расчеты и т.п. Когда заказчик не соглашается ни на один из вариантов, то либо контракт расторгается, либо дополнительные расходы несет фирма, либо заказ выполняется в сокращенном объеме. Если предусматривается продолжение работ, то от менеджера требуется идентификации ситуаций, в которых проявляется расхождение между объявленной в новой смете потребностью и первоначально выделяемых средств. Таким образом, в указанных условиях случай 2 сводится к случаю 3 или к утверждению новой сметы.

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

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

Выделить работы, которые можно отложить, c нарушением времени выполнения проекта и за счет этого сократить ресурсную потребность, как это делается на шаге 1. Согласовать с заказчиком перенос сроков.

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

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

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

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

2.2 Информационное обеспечение задачи

2.2.2 Информационная модель и её описание

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

Таблица 2.3.

Перечень и описание структурных единиц входных документов

Наименование структурной единицы	Точность числового значения	Источник информации (документ, массив)	Идентификатор источника
Окончательная ведомость
Дата ведомости Код билета Наименование билета Количество билета Цена билета Стоимость билета	99.X(8).9999 999999 X(150) 99999999 99999,99 99999999,99	Состав	Sclad

На рис. 2.6 приведена информационная модель логического уровня БД.

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

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



Рис. 2.6. Информационная модель логического уровня БД

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

Сумма заказа клиента - складывается из суммы стоимостей билетов, учитывая их количество.

Формула 2.1.

,

где,

Sum - сумма j-го заказа клиента;

Price - цена i-того билета в j-м заказе;

Count - количество i-того билета в j-м заказе;

n - количество разновидностей билетов.

Сумма заказов за день - складывается из общей суммы всех заказов клиентов на определенную дату.

Формула 2.2.

,

где,

Sum - сумма заказов за день;

m - количество заказов за день.

2.2.3 Используемые классификаторы и системы кодирования

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

Таблица 2.4.

Описание системы кодировки

Наименование признака	Значительность	Система кодировки	Структура кодового обозначения
Код покупателя	5	последовательная	99999
Код билета	6	последовательная	999999
Код заказа	6	последовательная	999999
Код вида оплаты	1	последовательная	9
Код категории билета	2	последовательная	99
Код характеристики	2	последовательная	99

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

Для решения задачи требуется наличие всех данных о билетах и их характеристиках. Также от СУБД требуется сохранение всех видов целостности БД при функционировании задачи.

Таблица 2.5.

Словарь данных

№ данных	Название элемента данных	Идентификатор	Тип, длина и точность	Назначение
1.	№ платежного поручения	Por_id	9999	Для однозначной идентификации поручений
2.	Банк получателя	Por_bnk_pol	Х(50)	Наименование банка получателя
3.	Банк плательщика	Por_bk_plt_naim	Х(50)	Наименование банка плательщика
4.	Вид оплаты	Ps_id	Х	Код вида оплаты
5.	Дата ведомости	vdata	99.X(8).9999	Для разделения остатков| на дату
6.	Дата получения банком	Por_bk_date	99.X(8).9999
7.	Дата оформления поручения	Por_date	99.X(8).9999	Дата оформления поручения
8.	Дата прайс-листа	Pr_date	99.X(8).9999	Дата прайс-листа
9.	Дата проведения банком	Por_bnk_prov	99.X(8).9999	Дата проведения банком
10.	Дата реестра	Re_date	99.99.9999	Дата реестра
11.	Дебет счета №	Por_deb_c	Х(14)	Дебет счета №
12.	Код банка получателя	Por_bnk_pol_id	Х(6)	Для однозначной идентификации банка
13.	Код банка плательщика	Por_plat_bnk_id	Х(6)	Для однозначной идентификации банка
14.	Код клиента	id	99999	Для однозначной идентификации клиента
15.	Код получателя	Por_pol_id	Х(14)	Для однозначной идентификации получателя
16.	Код плательщика	Por_plat_id	Х(14)	Для однозначной идентификации плательщика
17.	Код билета	pr_id	999999	Для однозначной идентификации
18.	Кредит счета №	Por_cred_c	Х(14)	Кредит счета №
19.	Наименование категории билета	Cat_naim	X(50)	Для различения
20.	Наименование билета	name	X(150)	Для пользователей билетов
21.	Номер заказа	o_id	99999	Для однозначной идентификации заказа
22.	Получатель	Por_pol_naim	Х(50)	Наименование получателя
23.	ФИО клиента	fio	Х(70)	ФИО клиента
24.	Плательщик	Por_plat_naim	Х(50)	Наименование латника
25.	Назначение платежа	Por_nazn	Х(80)	Назначение платежа
26.	Сумма платежа	Por_sum	99999,99	Сумма платежа
28.	Цена билета	price	99999,99	Для оценки остатков|
29.	Наименование характеристики билета	Prop_naim	X(80)	Наименование характеристики билета
30.	Значение характеристики билета	Value_	X(100)	Значение характеристики билета

2.2.4 Характеристика нормативно-справочной, входной и оперативной информации

Таблица 2.6.

Перечень входных и исходных сообщений (документов)

Код документа	Название документа	Входной или исходный|выходной|
0805704	Окончательная ведомость	Входной
0811301	Прайс-лист	Выходной
0811902	Реестр подтвержденных заказов	Выходной
0811903	Платежное поручение	Выходной

Таблица 2.7.

Список входных документов

№ данных	Название реквизита	Фактический или рассчитанный	Назначение
1.	Стоимость билетов	рассчитанный	Для оценки остатков|
2.	Дата ведомости	фактический	Для разделения остатков за датой
3.	Кол-во билетов	рассчитанный	Для оценки остатков
4.	Код билетов	фактический	Для однозначной идентификации билетов
5.	Наименование билетов	фактический	Для покупателей билетов
6.	Цена билетов	фактический	Для оценки остатков|

2.2.5 Характеристика результатной информации

Таблица 2.8.

Список исходных документов

№ данных	Название реквизита	Фактический или рассчитанный	Назначение
1.	№ платежного поручения	фактический	Для однозначной идентификации поручений
2.	№ билета	фактический	Для однозначной идентификации билета
3.	Банк получателя	фактический	Наименование банка получателя
4.	Банк плательщика	фактический	Наименование банка плательщика
6.	Дата получения банком	фактический	Дата получения банком
7.	Дата оформления поручения	рассчитанный	Дата оформления поручения
8.	Дата прайс-листа	рассчитанный	Дата прайс-листа
9.	Дата проведения банком	фактический	Дата проведения банком
10.	Дата реестра	рассчитанный	Дата проведения банком
11.	Дебет счета №	фактический	Дата реестра
12.	Значение характеристики билета	фактический	Значение характеристики билета
13.	Код банка получателя	фактический	Для однозначной идентификации банка
14.	Код банка плательщика	фактический	Для однозначной идентификации банка
15.	Код клиента	фактический	Для однозначной идентификации клиента
16.	Код получателя	фактический	Для однозначной идентификации получателя
17.	Код плательщика	фактический	Для однозначной идентификации плательщика
18.	Кредит счета №	фактический	Кредит счета №
19.	Наименование производителя	фактический	Наименование производителя
20.	Наименование категории билета	фактический	Для различения
21.	Наименование билета	фактический	Наименование билета
22.	Наименование характеристики билета	фактический	Наименование характеристики билета
23.	Номер заказа	фактический	Для однозначной идентификации заказа
24.	Получатель	фактический	Наименование получателя
25.	ФИО клиента	фактический	ФИО клиента
26.	Плательщик	фактический	Наименование латника
27.	Ссылка на сайт производителя	фактический	Ссылка на сайт производителя
28.	Назначение платежа	фактический	Назначение платежа
29.	Сумма заказа	рассчитанный	Сумма заказа

2.2.6 Формализация расчётов показателей

Таблица 2.9.

Формализация таблиц БД и расчет приблизительного объема БД

Таблица	Наименование поля	Идентификатор поля	Тип данных	Размер байт
BANNER	Код баннера	B_ID	INTEGER	4
	Файл баннера	BANNER_FILE	VARCHAR(256)	256
260*8=2080
CATEGORY	Код категории	CAT_ID	INTEGER	4
	Наименование категории	CAT_NAIM	VARCHAR(50)	50
54*10=540
CUSTOMER	Код клиента	ID	INTEGER	4
	ФИО клиента	FIO	VARCHAR(70)	70
	Адрес клиента	ADDRESS	VARCHAR(70)	70
	Телефон	TEL	VARCHAR(18)	18
	Дата регистрации	REG_DATE	DATE	4
	Адрес электронной почты	EMAIL	VARCHAR(50)	50
216*30=6480
MAN	Код пользователя	ID	INTEGER	4
	Логин	LOGIN	VARCHAR(20)	20
	Пароль	PASSWORD	VARCHAR(20)	20
	Признак менеджера	ADM	CHAR(1)	1
45*32=1140
O_ID	Код заказа	ID	INTEGER	4
	Дата заказа	DAT_ORD	DATE	4
	Адрес заказа	ADDRESS	VARCHAR(70)	70
	Вид оплаты	PAY_ID	INTEGER	4
	Дата доставки	DAT_DOS	DATE	4
	Дата фактическойдоставки	DAT_FACT	DATE	4
	Признак подтверждённого заказа	APPLIED	CHAR(1)	1
91*100=9100
ORDER_DESC	Код заказа	O_ID	INTEGER	4
	Код билета	PR_ID	INTEGER	4
	Количество	QNTY	INTEGER	4
12*300=3600
PRODUCER	Код производителя	PRDCR_ID	INTEGER	4
	Наименование производителя	NAME	VARCHAR(50)	50
54*15=810
PRODUCT	Код билета	PR_ID	INTEGER	4
	Код категории	CAT_ID	INTEGER	4
	Наименование билета	NAME	VARCHAR(50)	50
	Файл малого изображения билета	IMAGE_SRC	VARCHAR(256)	256
	Цена	PRICE	NUMERIC(6,2)	4
	Признак новинки	NEW_FLAG	CHAR(1)	1
	Файл большого изображения билета	HIGH_IMG_SRC	VARCHAR(256)	256
	Файл описания билета	DESCRIPTION_URL	VARCHAR(256)	256
	Код производителя	PRDCR_ID	INTEGER	4
835*150=125250
PROD_PROP	Код билета	PR_ID	INTEGER	4
	Код характеристики билета	PROP_ID	INTEGER	4
	Значениехарактеристики	VALUE_	VARCHAR(100)	100
108*500=54000
PROPERTY	Код характеристики	PROP_ID	INTEGER	4
	Код категории билета	CAT_ID	INTEGER	4
	Наименование характеристики	PROP_NAIM	VARCHAR(80)	80
88*150=13200
SITE	Код сайта производителя	SITE_ID	INTEGER	4
	Код производителя	PRDCR_ID	INTEGER	4
	Ссылка на сайт	SITE_URL	VARCHAR(256)	256
264*15=3840
220340 байт

Безусловно, этот расчет является приблизительным. Это объясняется наличием в БД метаданных. Кроме того, размер БД для СУБД Interbase достаточно тяжело определить, потому, что файл БД архивируется после закрытия соединения с СУБД.

2.3 Программное обеспечение задачи

2.3.2 Общие положения (дерево функций и сценарий диалога)

Программа создаётся для автоматизации учетных функций менеджера по продаже. Она реализована с использованием HTML-конструкций и серверного скрипт-языка PHP.

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

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

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

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



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

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

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

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

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

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

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

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



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

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

Техническое описание программных модулей проекта приведено в Приложении 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



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

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

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

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

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

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

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

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

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

Т = Т0 - Т1

где,

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

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

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

КТ =Т / T0 * 100%

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

YT = T0 / T1

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

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

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

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

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

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

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

Расчет расходов на разработку и сопровождение проекта:

1) Определяем объем программного продукта в количестве строк программы:

KLOC = 4413

2) Определяем номинальные расходы труда по формуле:

Зном=а* KLOC*ехр(b)

где,

а,b - коэффициенты модели расходов труда.

Так как тип программного продукта полуизолирован, то а = 3.2, b = 1.05.

Зном = 3,2 * 4413 * 2,857651= 40355.

3) Определяем влияние разных свойств проекта на полные расходы. Сначала уточняем характеристики условий разработки, устанавливая рейтинг каждой характеристики. Рейтинг стоимостных атрибутов приведен в табл. 3.1., где КИТ - коэффициенты изменения трудоемкости.

Рассчитываем корректирующий коэффициент расходов по формуле:

где,

N - количество использованных и учтенных характеристик:

КИТ - коэффициенты изменения трудоемкости.

Таблица 3.1.

Рейтинг стоимостных атрибутов

Стоимостный атрибут	Характеристика условий разработки	Рейтинг	КИТ
1. Сложность	обработка сообщений	Номинальный	1
2. Размер БД	количество переменных	Номинальный	1
3. Надежность функционирования	степень риска (относительно|касательно| финансовых убытков)	Низкий	0,88
4. Ограничение ЭВМ|	использование ресурсов ЭВМ| для проекта (скорость обработки, емкость оперативной памяти в % отношении)	Номинальный	1
5. Период эксплуатации	годы	Низкий	0,8
6. Предполагаемый тираж	количество продаж	Высокий	1,3
7. Мобильность для других разработок	% используемых компонентов в других проектов	Низкий	0,8
8. Мобильность из|с| других разработок	% использование компонентов с другими проектами	Высокий	0,7
9. Современные методы	Использование современных методов и технологий обработки информации	Очень высокий	0,6
10. Уровень автоматизации	инструментальных средств	Сверхвысокий	0,25
11. Тематическая квалификация	период подготовки разработки (поставщиков) проекта, месяцы	Высокий	0,8
12. Технологическая квалификация	период подготовки разработки программного обеспечения проекта, месяцы	Высокий	0,9
13. Квалификация программиста	период подготовки разработки| программного обеспечения проекта, месяцы	Очень высокий	0,8
14. Квалификация пользователя	период подготовки пользователей проекта, месяцы	Высокий	1

ККР= 1 * 1 * 0,88 * 1 * 0,8 * 1,3 * 0,8 * 0,7 * 0,6 * 0,25 * 0,8 * 0,9 *0,8 * 1 = 0,04428

4) Определяем длительность разработки проекта по формуле:

Дл = Зном * ККР / (КР * КМ)

где,

КР - количество разработчиков, КР = 1;

КМ - месячная производительность одного разработчика (строк), КМ = 950.

Дл = 40355 * 0,04428 / (1 * 950) = 1,88

5) стоимость разработки проекта:

Стп = Дл * ЗПМ

где,

ЗПМ - среднемесячная заработная плата одного разработчика проекта.

Стп = 1,88 * 1500 = 2820

6) Определяем стоимость сопровождения проекта (ССП), исходя из количества лет гарантийного сопровождения (К) и коэффициента годовых изменений (КГИ):

ССП = К * КГИ * Стп

КГИ = IKLOC / KLOC

где,

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

К = 2, IKLOC = 200

КГИ = 200 / 4413 = 0,045

ССП = 2 * 0,045* 2820 = 253,8

Определение цены задачи:

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

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

Цмах = Стп + ССП + П

где,

П - предполагаемая величина прибыли.

П = 8000

Цмах = 2820 + 253,8 + 8000 = 11073,8

Определяем минимальную цену проекта, исходя из стоимости тиражирования (СТ) и адаптации (СА) проекта:

Цмin = КП (СТ + СА)

где,

КП - коэффициент прибыльности, ровный 1,3. На стоимость тиражирования влияет время копирования проекта, стоимость материалов и заработная плата исполнителей.

СТ = См/год * Ткоп + См + Змес / 192 * Ткоп

где,

См/год - стоимость машино-часа;

Ткоп - время копирования проекта в часах;

См - стоимость материалов;

Змес - среднемесячная заработная плата исполнителя;

192 - среднее количество часов работы исполнителя в месяц.

См/год = 4,2

Ткоп = 0,2

См = 10

Змес = 1500

СТ= 4,2 * 0,2 + 10 + 1500 / 192 * 0,2 = 12,403

СА = 0,03 * Стп

Тогда,

СА = 0,03 * 2820 = 84,6

Цміn = 1,3 * (12,403 + 84,6) = 126,104

Предполагаемая цена проекта (Ц) находится в ценовом коридоре:

126,104 < Ц < 11073,8

Устанавливаем цену проекта - 5600 долл.

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

где,

ВРt - прибыль от реализации проекта;

R - индекс инфляции t-го года;

t - год;

T - период жизненного цикла;

СТВТ - стоимость КТЗ, что добывается;

СВ - сумма страховых взносов в t-ому году;

СР - расходы на рекламу в t-ому году.

ЧТС = 40093,76 долл.

где,

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

А - сумма амортизационных отчислений.

А = 0,25 * СТВТ

Ток = 0,505

Срок окупаемости составляет 0,505 г.

где,

ПЗ - среднегодовые постоянные расходы;

УПЗ - среднегодовые удельные переменные расходы.

Ткр = 0,704

То есть, критический объем продажи равняется единице на год.



где,

ФСП - среднегодовой объем реализации проекта.

К эб = 468,18%

Коэффициент экономической беспечности составляет 468,18%.

Выводы: ЧТС показывает, сколько будет стоить данный проект с учетом инфляции за весь период жизненного цикла. Из-за того, что жизненный цикл проекта составляет 3 года, то можно сделать вывод о том, что прибыль можно будет получить уже в конце первого года. Критический объем продаж составляет 1 единицу - это объем продажи, при которой прибыль будет немного выше нуля. То есть, если мы продадим меньше 1 штуки, то наш проект будет нерентабельным. Коэффициент экономической безопасности высокий - 468,18% - и, по сути, является чем-то вроде запаса.

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

Заключение

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

Также в ходе выполнения квалификационной работы были полученные практические навыки разработки Web-дополнений, PHP-вставок, и интеграции их из БД.

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

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

Литература

1. Автоматизированные информационные технологии в экономике. Учебник./ Под ред. Проф. Г.А. Титоренко. - М.: Компьютер, ЮНИТИ, 1998.

2. Гилберт А. Черчиль. Маркетинговые исследования.- СПб: Питер, 2001.

3. Голубков Е. П. Маркетинговые исследования: теория, методология и практика. М.: Издательство "Финпресс", 1998.

4. Завьялов П.С. Маркетинг. - Москва, 2002.

5. Компьютерные технологии обработки информации./ Под ред. С.В. Назарова. - М.: Финансы и статистика, 1995.

6. Корнеев В.В., Гареев А.Ф., Васютин С.В., Райх В.В. Базы данных. Интеллектуальная обработка информации. - М: "Ноллидж", 2000.

7. Павленко Л.А. Тенденции развития информационных систем и инструментальных средств организации данных. Язык SQL - инструмент интероперабельности и открытости распределенных информационных систем курса "Инструментальные средства разработки и поддержки распределенных баз данных информационных систем". - Х.: ХГЭУ, 2003.

8. Поршнев А.Г., Азоев Г.Л. "Маркетинг" - Москва: Изд-во РЭА, 2002.

9. Титоренко Г.А., Макарова Г.Л., Дайитбегов Д.М. "Информационные технологии в маркетинге" - Москва: Юнити, 2001.

10. Роль и задачи МИС в маркетинге организации http://eup.ru/

Приложение 1. Программный код

TECHNICAL FILE INFORMATION :

File Type Description :Portable Executable (PE)

FILE CHARACTERISTICS :

File is executable (i.e. no unresolved external references)

COFF line numbers have been removed

COFF symbol table entries for local symbols have been removed

Little endian: LSB precedes MSB in memory

Machine based on 32-bit-word architecture

Big endian: MSB precedes LSB in memory

FILE HEADER :

Machine: 014Ch (i386 or later, and compatible)

Number of Sections: 0008h

Time Date Stamp: 2A425E19h

Symbols Pointer: 00000000h

Number Of Symbols: 00000000h

Size Of Optional Header: 00E0h

Flags: 818Eh

OPTIONAL HEADER :

Magic 010Bh ( PE32 : normal 32-bit )

Linker version 2.25

Size of code 0010EA00h

Size of initialized data 0005CE00h

Size of uninitialized data 00000000h

Address of Entry Point (RVA) 0010F780h

Base of code 00001000h

Base of data 00110000h

Image base 00400000h

Section Alignment 00001000h

File Alignment 00000200h

Required OS version 4.00

Image version 0.00

Subsystem version 4.00

Reserved1 0

Size of image 00172000h ( 1515520 bytes)

Size of headers 00000400h

Checksum 00000000h

Subsystem 0002h (Image runs in the Windows GUI subsystem)

DLL Characteristics 0000h

Size of Stack Reserve 00100000h

Size of Stack Commit 00004000h

Size of Heap Reserve 00100000h

Size of Heap Commit 00001000h

loader flags 00000000h (obsolete)

Number of Data Directory 00000010h

DATA DIRECTORY (Virtual Address and Size)

Export Directory rva: 00000000h size: 00000000h

Import Directory rva: 00116000h size: 00002AD8h

Resource Directory rva: 00131000h size: 00040A00h

Exception table rva: 00000000h size: 00000000h

Security table rva: 00000000h size: 00000000h

Base Relocation table rva: 0011B000h size: 00015F10h

Debug Directory rva: 00000000h size: 00000000h

Architecture Specific Data rva: 00000000h size: 00000000h

Global Pointer rva: 00000000h size: 00000000h

TLS Directory rva: 0011A000h size: 00000018h

Load config table rva: 00000000h size: 00000000h

Bound Import table rva: 00000000h size: 00000000h

Import Address Table rva: 00000000h size: 00000000h

Delay import descriptor rva: 00000000h size: 00000000h

COM descriptor rva: 00000000h size: 00000000h

unused rva: 00000000h size: 00000000h

SECTION TABLE

01 CODE

VirtSize: 0010E820h VirtAddr: 00001000h

raw data offs: 00000400h raw data size: 0010EA00h

relocation offs: 00000000h relocations: 00000000h

line # offs: 00000000h line #'s: 00000000h

characteristics: 60000020h

CODE EXECUTE READ ALIGN_DEFAULT(16)

02 DATA

VirtSize: 00003454h VirtAddr: 00110000h

raw data offs: 0010EE00h raw data size: 00003600h

relocation offs: 00000000h relocations: 00000000h

line # offs: 00000000h line #'s: 00000000h

characteristics: C0000040h

INITIALIZED_DATA READ WRITE ALIGN_DEFAULT(16)

03 BSS

VirtSize: 00001279h VirtAddr: 00114000h

raw data offs: 00112400h raw data size: 00000000h

relocation offs: 00000000h relocations: 00000000h

line # offs: 00000000h line #'s: 00000000h

characteristics: C0000000h

READ WRITE ALIGN_DEFAULT(16)

04 .idata

VirtSize: 00002AD8h VirtAddr: 00116000h

raw data offs: 00112400h raw data size: 00002C00h

relocation offs: 00000000h relocations: 00000000h

line # offs: 00000000h line #'s: 00000000h

characteristics: C0000040h

INITIALIZED_DATA READ WRITE ALIGN_DEFAULT(16)

05 .tls

VirtSize: 00000060h VirtAddr: 00119000h

raw data offs: 00115000h raw data size: 00000000h

relocation offs: 00000000h relocations: 00000000h

line # offs: 00000000h line #'s: 00000000h

characteristics: C0000000h

READ WRITE ALIGN_DEFAULT(16)

06 .rdata

VirtSize: 00000018h VirtAddr: 0011A000h

raw data offs: 00115000h raw data size: 00000200h

relocation offs: 00000000h relocations: 00000000h

line # offs: 00000000h line #'s: 00000000h

characteristics: 50000040h

INITIALIZED_DATA SHARED READ ALIGN_DEFAULT(16)

07 .reloc

VirtSize: 00015F10h VirtAddr: 0011B000h

raw data offs: 00115200h raw data size: 00016000h

relocation offs: 00000000h relocations: 00000000h

line # offs: 00000000h line #'s: 00000000h

characteristics: 50000040h

INITIALIZED_DATA SHARED READ ALIGN_DEFAULT(16)

08 .rsrc

VirtSize: 00040A00h VirtAddr: 00131000h

raw data offs: 0012B200h raw data size: 00040A00h

relocation offs: 00000000h relocations: 00000000h

line # offs: 00000000h line #'s: 00000000h

characteristics: 50000040h

INITIALIZED_DATA SHARED READ ALIGN_DEFAULT(16)

IMPORTS TABLE:

kernel32.dll

Import Lookup Table RVA: 00000000h (Unbound IAT)

TimeDateStamp: 00000000h

ForwarderChain: 00000000h

DLL Name RVA: 00116950h

Import Address Table RVA: 0011617Ch

First thunk RVA: 0011617Ch

Ordn Name

----------

0 DeleteCriticalSection

0 LeaveCriticalSection

0 EnterCriticalSection

0 InitializeCriticalSection

0 VirtualFree

0 VirtualAlloc

0 LocalFree

0 LocalAlloc

0 GetCurrentThreadId

0 InterlockedDecrement

0 InterlockedIncrement

0 VirtualQuery

0 WideCharToMultiByte

0 MultiByteToWideChar

0 lstrlenA

0 lstrcpynA

0 LoadLibraryExA

0 GetThreadLocale

0 GetStartupInfoA

0 GetProcAddress

0 GetModuleHandleA

0 GetModuleFileNameA

0 GetLocaleInfoA

0 GetLastError

0 GetCommandLineA

0 FreeLibrary

0 FindFirstFileA

0 FindClose

0 ExitProcess

0 ExitThread

0 CreateThread

0 WriteFile

0 UnhandledExceptionFilter

0 SetFilePointer

0 SetEndOfFile

0 RtlUnwind

0 ReadFile

0 RaiseException

0 GetStdHandle

0 GetFileSize

0 GetFileType

0 CreateFileA

0 CloseHandle

user32.dll

Import Lookup Table RVA: 00000000h (Unbound IAT)

TimeDateStamp: 00000000h

ForwarderChain: 00000000h

DLL Name RVA: 00116C4Eh

Import Address Table RVA: 0011622Ch

First thunk RVA: 0011622Ch

Ordn Name

----------

0 GetKeyboardType

0 LoadStringA

0 MessageBoxA

0 CharNextA

advapi32.dll

Import Lookup Table RVA: 00000000h (Unbound IAT)

TimeDateStamp: 00000000h

ForwarderChain: 00000000h

DLL Name RVA: 00116C94h

Import Address Table RVA: 00116240h

First thunk RVA: 00116240h

Ordn Name

----------

0 RegQueryValueExA

0 RegOpenKeyExA

0 RegCloseKey

oleaut32.dll

Import Lookup Table RVA: 00000000h (Unbound IAT)

TimeDateStamp: 00000000h

ForwarderChain: 00000000h

DLL Name RVA: 00116CD4h

Import Address Table RVA: 00116250h

First thunk RVA: 00116250h

Ordn Name

----------

0 SysFreeString

0 SysReAllocStringLen

0 SysAllocStringLen

kernel32.dll

Import Lookup Table RVA: 00000000h (Unbound IAT)

TimeDateStamp: 00000000h

ForwarderChain: 00000000h

DLL Name RVA: 00116D1Ch

Import Address Table RVA: 00116260h

First thunk RVA: 00116260h

Ordn Name

----------

0 TlsSetValue

0 TlsGetValue

0 LocalAlloc

0 GetModuleHandleA

advapi32.dll

Import Lookup Table RVA: 00000000h (Unbound IAT)

TimeDateStamp: 00000000h

ForwarderChain: 00000000h

DLL Name RVA: 00116D68h

Import Address Table RVA: 00116274h

First thunk RVA: 00116274h

Ordn Name

----------

0 SetSecurityDescriptorDacl

0 RegQueryValueExA

0 RegOpenKeyExA

0 RegCloseKey

0 InitializeSecurityDescriptor

kernel32.dll

Import Lookup Table RVA: 00000000h (Unbound IAT)

TimeDateStamp: 00000000h

ForwarderChain: 00000000h

DLL Name RVA: 00116DE4h

Import Address Table RVA: 0011628Ch

First thunk RVA: 0011628Ch

Ordn Name

----------

0 lstrcpyA

0 WriteFile

0 WaitForSingleObject

0 VirtualQuery

0 VirtualAlloc

0 UnmapViewOfFile

0 Sleep

0 SizeofResource

0 SetThreadLocale

0 SetFilePointer

0 SetEvent

0 SetErrorMode

0 SetEndOfFile

0 SearchPathA

0 ResumeThread

0 ResetEvent

0 ReleaseMutex

0 ReadFile

0 OpenMutexA

0 OpenFileMappingA

0 OpenEventA

0 MultiByteToWideChar

0 MulDiv

0 MapViewOfFile

0 LockResource

0 LoadResource

0 LoadLibraryA

0 LeaveCriticalSection

0 IsDBCSLeadByte

0 InitializeCriticalSection

0 GlobalUnlock

0 GlobalSize

0 GlobalReAlloc

0 GlobalHandle

0 GlobalLock

0 GlobalFree

0 GlobalFindAtomA

0 GlobalDeleteAtom

0 GlobalAlloc

0 GlobalAddAtomA

0 GetVersionExA

0 GetVersion

0 GetUserDefaultLCID

0 GetTickCount

0 GetThreadLocale

0 GetTempPathA

0 GetTempFileNameA

0 GetSystemInfo

0 GetSystemDefaultLCID

0 GetStringTypeExA

0 GetStdHandle

0 GetProfileStringA

0 GetProcAddress

0 GetModuleHandleA

0 GetModuleFileNameA

0 GetLocaleInfoA

0 GetLocalTime

0 GetLastError

0 GetExitCodeThread

0 GetDiskFreeSpaceA

0 GetDateFormatA

0 GetCurrentThreadId

0 GetCurrentProcessId

0 GetCurrentDirectoryA

0 GetCPInfo

0 GetACP

0 FreeResource

0 InterlockedIncrement

0 InterlockedDecrement

0 FreeLibrary

0 FormatMessageA

0 FindResourceA

0 FindFirstFileA

0 FindClose

0 FileTimeToLocalFileTime

0 FileTimeToDosDateTime

0 FatalAppExitA

0 EnumCalendarInfoA

0 EnterCriticalSection

0 DeleteFileA

0 DeleteCriticalSection

0 CreateThread

0 CreateMutexA

0 CreateFileMappingA

0 CreateFileA

0 CreateEventA

0 CompareStringA

0 CloseHandle

version.dll

Import Lookup Table RVA: 00000000h (Unbound IAT)

TimeDateStamp: 00000000h

ForwarderChain: 00000000h

DLL Name RVA: 001173ECh

Import Address Table RVA: 001163F0h

First thunk RVA: 001163F0h

Ordn Name

----------

0 VerQueryValueA

0 GetFileVersionInfoSizeA

0 GetFileVersionInfoA

gdi32.dll

Import Lookup Table RVA: 00000000h (Unbound IAT)

TimeDateStamp: 00000000h

ForwarderChain: 00000000h

DLL Name RVA: 0011743Ah

Import Address Table RVA: 00116400h

First thunk RVA: 00116400h

Ordn Name

----------

0 UnrealizeObject

0 StretchBlt

0 StartPage

0 StartDocA

0 SetWindowOrgEx

0 SetWindowExtEx

0 SetWinMetaFileBits

0 SetViewportOrgEx

0 SetViewportExtEx

0 SetTextColor

0 SetTextAlign

0 SetStretchBltMode

0 SetROP2

0 SetPixel

0 SetMapMode

0 SetEnhMetaFileBits

0 SetDIBColorTable

0 SetBrushOrgEx

0 SetBkMode

0 SetBkColor

0 SetAbortProc

0 SelectPalette

0 SelectObject

0 SelectClipRgn

0 SaveDC

0 RestoreDC

0 Rectangle

0 RectVisible

0 RealizePalette

0 Polyline

0 PolyPolyline

0 PlayEnhMetaFile

0 PatBlt

0 MoveToEx

0 MaskBlt

0 LineTo

0 LPtoDP

0 IntersectClipRect

0 GetWindowOrgEx

0 GetWinMetaFileBits

0 GetTextMetricsA

0 GetTextExtentPointA

0 GetTextExtentPoint32A

0 GetSystemPaletteEntries

0 GetStockObject

0 GetRgnBox

0 GetPixel

0 GetPaletteEntries

0 GetObjectA

0 GetNearestColor

0 GetEnhMetaFilePaletteEntries

0 GetEnhMetaFileHeader

0 GetEnhMetaFileDescriptionA

0 GetEnhMetaFileBits

0 GetDeviceCaps

0 GetDIBits

0 GetDIBColorTable

0 GetDCOrgEx

0 GetCurrentPositionEx

0 GetClipBox

0 GetBrushOrgEx

0 GetBitmapBits

0 ExtTextOutA

0 ExtCreatePen

0 ExcludeClipRect

0 EndPage

0 EndDoc

0 Ellipse

0 DeleteObject

0 DeleteEnhMetaFile

0 DeleteDC

0 CreateSolidBrush

0 CreateRectRgn

0 CreatePenIndirect

0 CreatePalette

0 CreateICA

0 CreateHalftonePalette

0 CreateFontIndirectA

0 CreateEnhMetaFileA

0 CreateDIBitmap

0 CreateDIBSection

0 CreateDCA

0 CreateCompatibleDC

0 CreateCompatibleBitmap

0 CreateBrushIndirect

0 CreateBitmap

0 CopyEnhMetaFileA

0 CombineRgn

0 CloseEnhMetaFile

0 BitBlt

0 AbortDoc

user32.dll

Import Lookup Table RVA: 00000000h (Unbound IAT)

TimeDateStamp: 00000000h

ForwarderChain: 00000000h

DLL Name RVA: 00117A3Ch

Import Address Table RVA: 00116570h

First thunk RVA: 00116570h

Ordn Name

----------

0 WindowFromPoint

0 WinHelpA

0 WaitMessage

0 ValidateRect

0 UpdateWindow

0 UnregisterClassA

0 UnionRect

0 UnhookWindowsHookEx

0 TranslateMessage

0 TranslateMDISysAccel

0 TrackPopupMenu

0 SystemParametersInfoA

0 ShowWindow

0 ShowScrollBar

0 ShowOwnedPopups

0 ShowCursor

0 SetWindowsHookExA

0 SetWindowTextA

0 SetWindowPos

0 SetWindowPlacement

0 SetWindowLongA

0 SetTimer

0 SetScrollRange

0 SetScrollPos

0 SetScrollInfo

0 SetRect

0 SetPropA

0 SetParent

0 SetMenuItemInfoA

0 SetMenu

0 SetKeyboardState

0 SetForegroundWindow

0 SetFocus

0 SetCursor

0 SetClipboardData

0 SetClassLongA

0 SetCapture

0 SetActiveWindow

0 SendMessageA

0 SendDlgItemMessageA

0 ScrollWindowEx

0 ScrollWindow

0 ScreenToClient

0 RemovePropA

0 RemoveMenu

0 ReleaseDC

0 ReleaseCapture

0 RegisterWindowMessageA

0 RegisterClipboardFormatA

0 RegisterClassA

0 RedrawWindow

0 PtInRect

0 PostQuitMessage

0 PostMessageA

0 PeekMessageA

0 OpenClipboard

0 OffsetRect

0 OemToCharBuffA

0 OemToCharA

0 MsgWaitForMultipleObjects

0 MessageBoxA

0 MessageBeep

0 MapWindowPoints

0 MapVirtualKeyA

0 LoadStringA

0 LoadKeyboardLayoutA

0 LoadIconA

0 LoadCursorA

0 LoadBitmapA

0 KillTimer

0 IsZoomed

0 IsWindowVisible

0 IsWindowEnabled

0 IsWindow

0 IsRectEmpty

0 IsIconic

0 IsDialogMessageA

0 IsChild

0 IsCharAlphaNumericA

0 IsCharAlphaA

0 InvalidateRect

0 IntersectRect

0 InsertMenuItemA

0 InsertMenuA

0 InflateRect

0 GetWindowThreadProcessId

0 GetWindowTextA

0 GetWindowRect

0 GetWindowPlacement

0 GetWindowLongA

0 GetWindowDC

0 GetTopWindow

0 GetSystemMetrics

0 GetSystemMenu

0 GetSysColor

0 GetSubMenu

0 GetScrollRange

0 GetScrollPos

0 GetScrollInfo

0 GetPropA

0 GetParent

0 GetWindow

0 GetMessageTime

0 GetMenuStringA

0 GetMenuState

0 GetMenuItemInfoA

0 GetMenuItemID

0 GetMenuItemCount

0 GetMenu

0 GetLastActivePopup

0 GetKeyboardState

0 GetKeyboardLayoutList

0 GetKeyboardLayout

0 GetKeyState

0 GetKeyNameTextA

0 GetIconInfo

0 GetForegroundWindow

0 GetFocus

0 GetDoubleClickTime

0 GetDlgItem

0 GetDesktopWindow

0 GetDCEx

0 GetDC

0 GetCursorPos

0 GetCursor

0 GetClipboardData

0 GetClientRect

0 GetClassNameA

0 GetClassInfoA

0 GetCaretPos

0 GetCapture

0 GetActiveWindow

0 FrameRect

0 FindWindowA

0 FillRect

0 EqualRect

0 EnumWindows

0 EnumThreadWindows

0 EnumClipboardFormats

0 EndPaint

0 EnableWindow

0 EnableScrollBar

0 EnableMenuItem

0 EmptyClipboard

0 DrawTextA

0 DrawMenuBar

0 DrawIconEx

0 DrawIcon

0 DrawFrameControl

0 DrawFocusRect

0 DrawEdge

0 DispatchMessageA

0 DestroyWindow

0 DestroyMenu

0 DestroyIcon

0 DestroyCursor

0 DeleteMenu

0 DefWindowProcA

0 DefMDIChildProcA

0 DefFrameProcA

0 CreateWindowExA

0 CreatePopupMenu

0 CreateMenu

0 CreateIcon

0 CloseClipboard

0 ClientToScreen

0 CheckMenuItem

0 CallWindowProcA

0 CallNextHookEx

0 BeginPaint

0 CharNextA

0 CharLowerBuffA

0 CharLowerA

0 CharUpperBuffA

0 CharToOemBuffA

0 CharToOemA

0 AdjustWindowRectEx

0 ActivateKeyboardLayout

kernel32.dll

Import Lookup Table RVA: 00000000h (Unbound IAT)

TimeDateStamp: 00000000h

ForwarderChain: 00000000h

DLL Name RVA: 001185BEh

Import Address Table RVA: 0011683Ch

First thunk RVA: 0011683Ch

Ordn Name

----------

0 Sleep

oleaut32.dll

Import Lookup Table RVA: 00000000h (Unbound IAT)

TimeDateStamp: 00000000h

ForwarderChain: 00000000h

DLL Name RVA: 001185D4h

Import Address Table RVA: 00116844h

First thunk RVA: 00116844h

Ordn Name

----------

0 SafeArrayPtrOfIndex

0 SafeArrayPutElement

0 SafeArrayGetElement

0 SafeArrayUnaccessData

0 SafeArrayAccessData

0 SafeArrayGetUBound

0 SafeArrayGetLBound

0 SafeArrayRedim

0 SafeArrayCreate