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

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

Введение
Вусловиях перехода общественного развития в информационную эпоху, становитсявозможным создание электронной экономики, для которой характерны немного другиеправила развития, по сравнению с классической экономикой. Развитие этого видаэкономики напрямую зависит от развития всемирной сети Internet, котораясоставляет инфраструктуру этого вида экономики. Проявлением электроннойэкономики является электронный бизнес. Электронный бизнес — это то, что выходит,когда вы объединяете ресурсы традиционных информационных систем с широтойраспространения Web и соединяете ключевые системы бизнеса через сети Intranet,Extranet и Web непосредственно сключевыми целевыми аудиториями — потребителями, рабочими и поставщиками. В своюочередь, электронная коммерция является одной из разновидностей электронногобизнеса, основной сутью которой является возможность торговли через сеть.
Следовательно,целью квалификационной работы является разработка элементов автоматизированнойинформационной системы управления сбытом билетов, в результате внедрениякоторой повышается скорость бизнес-процессов торговой организации.
Основнымизадачами квалификационной работы являются:
§     практическоеовладение современными методологиями проектирования;
§     применениена практике современных CASE-средств проектирования;
§     практическоеовладение технологией формализации прикладных задач, построения математическихмоделей и разработки алгоритмов их решения;
§     приобретениенавыков разработки и оформления проектной документации в соответствии стребованиями государственных стандартов;
§     развитиеи закрепление навыков ведения самостоятельной работы, овладение методикойтеоретических и экспериментальных исследований при решении вопросов, которыерассматриваются в квалификационной работе;
§     освоениеметодов разработки научно-технических решений с учетом экономических,технических требований;
§     овладениерациональными методами поиска и анализа отечественной и зарубежнойнаучно-технической информации.

IАналитическая часть
 
1.1          Технико-экономическаяхарактеристика предметной области и предприятия. Анализ деятельности «КАК ЕСТЬ»
1.1.1   Характеристикапредприятия и его деятельности
КомпанияООО «Зритель» входит в состав крупнейшего в Европе холдинга CTS Eventim AG(организация мероприятий, продажа билетов, разработка soft).
КомпанииООО «Зритель» принадлежат такие бренды как Parter.ru (Партер.ру) иKontramarka.ru (Контрамарка.ру) – первые официальные билетные агентства вРоссии. Они существуют на рынке услуг с 2000 года. Это интернет — магазины,созданные в соответствие с самыми последними европейскими стандартами(www.eventim.de, www.oeticket.com): «корзина заказа», заказ билетов по схемезала, оплата заказа пластиковыми картами через интернет. Доступны две версиисайтов — русская и английская. Единая билетная база позволяет продавать билетына мероприятия, проходящие в разных городах и странах.
Средипартнеров компании ООО «Зритель» — крупнейшие театральные и концертныекомпании. Компания ООО «Зритель» может предоставить своим партнёрам 3 модуляинтернет — партнёрства.
Модуль1:
§     Предоставлениедоступа к партнерской программе.
§     Партнерполучает ссылки на страницу мероприятия/сеанса, которые снабжены уникальнымиидентификаторами, позволяющими отследить заказы.
§     Предоставлениедоступа к статистике по продажам.
Модуль2:
§     Предоставлениедоступа к уникальному Web-services, который включает: информацию обо всехмероприятиях, которые находятся в продаже (название, место проведения, дата,страна, описание и т.д.)
§     Возможностьнастроить внешний вид страниц оформления заказа под дизайн сайта.
§     Партнерполучает доступ к статистике продаж.
§     Возможностьреализовать продажу билетов в собственных кассах. А также самостоятельнорегулировать размер услуги бронирования.
§     Собственнаяклиентская база.
Модуль3:
§     Интеграциясайта с использованием CI партнера (создание собственного интернет — магазина врамках уже существующего сайта)
§     Всяинформация о мероприятиях на сайте экспортируется на сайт партнера.
§     Возможностьсамостоятельно реализовывать билеты в собственных кассах/собственная службадоставки. А также регулировать размер услуги бронирования.
§     Собственныезарегистрированные пользователи.
§     Возможностьсобственной новостной рассылки, TOP-10 etc.
§     Получениеспециальной программы для web-партнерства (собственные web-агенты).
§     Получениедоступа к статистике посещаемости и продаж.
Ежедневно,в компании ООО «Зритель» более 1300 мероприятий, билеты на которые она можетпредложить своим клиентам.
Ежемесячно,сайты компании ООО «Зритель» (www.parter.ru, www.kontramarka.ru) (рис. 1.1.,1.2.) посещают более 700 тысяч человек.
Клиентскаябаза компании насчитывает более 200 тысяч клиентов.
Вближайших планах компании ООО «Зритель» — выход на международную арену, чтопозволит пользователям сайтов покупать билеты на мероприятия в других странах.
Аудиториясайтов компании ООО «Зритель» (Партер.ру, Контрамарка.ру) разница. Аудиториясайта «Партер.ру» — люди с достатком, которые ценят экономию времени, комфорт ипланируют свой досуг заблаговременно. Аудитория сайта «Контрамарка.ру» –молодые и активные люди, предпочитающие совершать покупки на сайтах. Склонны кспонтанному принятию решения о проведении досуга.
«Партер.ру»– лидер среди интернет — агентств на билетном рынке Москвы, предлагающий самыйполный ассортимент и новейшие технологические сервисы для клиентов, лауреат«Премии Рунета-2005», лауреат конкурса «БРЭНД ГОДА/EFFIE 2007», учредитель иорганизатор ежегодной премии «Эмоция».
С2006 года «Контрамарка.ру» является учредителем и организатором ежегоднойпремии «Эмоция», вручаемой промоутерам, внесшим особый вклад в развитиекультурной жизни столицы.
КомпанияООО «Зритель» реализует билеты по их номинальной цене. Стоимость услугибронирования самая низкая в Москве и составляет от 0 до 10% от цены билета.
Таблица1.1.
Количественно-стоимостныеоценки
№
Наименование характеристики (показателя)
Значение показателя на первый квартал 2008 г. 1 Клиентская база компании Более 200 тыс. клиентов 2 Стоимость услуги бронирования От 0 до 10% 3 Наценка на билеты 4 Кол-во мероприятий в системе ежедневно Более 1300 5 Посещаемость сайтов компании Более 700 тыс. чел/мес. 6 Заказов на сайте «Партер.ру» Более 1 млн. за 7 лет 7 Проданных билетов на сайте «Партер.ру» Более 3 млн. за 7 лет
1.1.2    Организационнаяструктура управления предприятием
КомпанияООО «Зритель» структурно состоит из пяти отделов, представленных на рис. 1.3.
/>
Рис.1.3. Схема общей организационной структуры управления предприятием
Целямифункционирования организации является осуществление реализации билетов,продвижение мероприятий, проведение маркетинговых исследований.
Кодподсистемы — 08.
Показателиносят натуральный и стоимостный характер.
Основныезадачи, которые решаются в подсистеме, приведены в табл. 1.2.

Таблица1.2.
Характеристиказадач
Функция управления
Код задачи
Наименование задачи
Назначение задачи
Исходная|выходная| информация
Входная информация Маркетинговые исследования 0801 Исследование емкости рынка Определение непокрытой емкости рынка Статистическая оценка емкости рынка Анкеты респондентов, информация в СМИ, справочник 0802 Исследование компьютерного рынка Оценить деление рынка среди конкурентов Статистическая оценка деления рынка среди конкурентов|распределения| Прайс-листы конкурентов, информация в СМИ Заключение договоров 0803 Заключение и оформление договоров на снабжение Документальное оформление договоров с поставщиками Договор на снабжение Справочник поставщиков, банков Заключение договоров 0804 Заключение и оформление договоров по продаже Документальное оформление договоров с покупателями |Договор на продажу Справочник покупателей, банков 0805 Оформление заказов с розничными покупателями через|из-за| Internet Оформление и запись в БД заказов через Internet Реестр заказов покупателей, ВК платёжные поручения для клиентов, прайс-лист Справочник покупателей, банков, электронных платёжных систем Планирование 0806 Планирование продаж Формирование плана купли и продажи Планы купли и продажи Договоры с покупателями и поставщиками, оценка емкости рынка, оценка деления|распределения| рынка среди конкурентов, реестр заказов, окончательная ведомость Учет продаж 0808 Учет продаж Учет продаж |Реестр договоров с клиентами Договоры с покупателями, реестр заказов Анализ продаж 0809 Анализ продаж Анализ продажи определенного билета определенным покупателем |Оценка спроса на определенный билет Договоры с покупателями
Задача0801 разрешается с целью исследования емкости рынка, то есть определениевероятности получения прибыли от реализации определенных билетов. Эта задачарешается на основе проведения анкетирования респондентов, которыми могутвыступать как клиенты организации, так и обычные люди.
Задача0802 разрешается с целью исследования конъюнктуры рынка, то есть определениеделения рынка среди конкурентов. Разрешается с целью оценки перспективногоположения организации, а также с целью определения будущего поведенияконкурентов, то есть определение их судьбы рынка в следующие периоды.
Задача0803 разрешается для оформления заключения и оформления договоров споставщиками билетов на определенную дату.
Задача0804 разрешается для оформления заключения и оформления договоров спокупателями билетов на определенную дату.
Задача0805 разрешается для оформления розничных заказов клиентов через сеть Internet.Это способствует снижению расходов на консультационный персонал, арендную платуза помещения и др.
Задача0806 разрешается с целью планирования продажи и приобретения билетов согласно смаркетинговыми исследованиями (тактикой). Целью этой задачи является разработкаплана продажи билетов с учетом судьбы рынка.
Задача0808 разрешается для учета продажи билетов определенному покупателю. Этосвязано с планомерностью самого процесса продажи.
Задача0809 разрешается с целью установления тенденций в спросе на определенныебилеты.
Схемасвязей задач подсистемы приведена на рис. 1.4.
Источникамиинформации для задачи, что разрешается, есть: отдел сбыта и бухгалтерия.
Входнойинформацией для задачи является информация справочников билетов и их описания.
Исходнойинформацией задачи является реестр подтвержденных заказов на дату, прайс-листбилетов и платежные поручения для клиентов.
Пользователямиинформации является клиенты магазина, менеджеры по продажам и сотрудники компании.
/>
Рис.1.4. Схема связей задач
1.1.3    Программнаяи техническая архитектура ИС на предприятии, использование их функциональныхвозможностей. Обеспечение информационной безопасности
Информационнаясистема ООО «Зритель» состоит из двух подсистем (Рис. 1.5).Первая подсистема предназначена для автоматизации бизнес-процессов продаж.Вторая — для автоматизации работы с финансовой составляющей процесса продаж.

/>
Рис. 1.5. Архитектура информационной системы ООО «Зритель»
Работаудаленных офисов реализуется двумя способами:
§     врежиме удаленного терминала;
§     черезweb-интерфейс (по технологии Extranet).
Впервом случае требуется канал связи высокой пропускной способности. Во второмслучае интерфейс пользователя системы – более упрощенный и менее эргономичный.В остальном, для пользователей порядок работы с системой не различается. Дляпростоты на схеме взаимодействие клиентов с удаленными офисами компании неотражено; оно – полностью аналогично взаимодействию с главным офисом.
Даннаяавтоматизированная система реализована на платформе MS Windows, реализацияBack-Office осуществляется в среде системы 1С-Предприятие.
Автоматизациябизнес-процессов продажи ООО «Зритель» билетов включает:
§     автоматизациюпроцессов заказа билетов;
§     возможностьиспользования одновременно различных способов оплаты;
§     автоматизацияфинансового учета и отчетности;
§     возможностьорганизации службы доставки билетов.
Автоматизацияпроцессов заказа билетов реализует:
§     заказтрадиционными способами (личный контакт с клиентом;
§     предварительныйзаказ по телефону, факсу);
§     заказчерез Интернет (в том числе удаленными пользователями через web-сайт компании);
§     продажусопутствующих услуг.
Заказчерез Интернет возможен в двух режимах:
§     черезсобственный веб-сайт компании;
§     путеминтеграции данной системы с web-сайтами сторонних компаний.
ДаннаяИС позволяет использовать различные способы оплаты:
§     наличнымив кассе компании;
§     безналичныйрасчет;
§     оплатапо кредитным и дебетовым картам;
§     отложенныеплатежи для крупных клиентов (постоянный контроль текущей задолженности);
§     оплатачерез системы электронных платежей;
§     Оплатачерез банковские сети.
Автоматизацияфинансового учета и отчетности реализует:
§     собственноучет финансовой составляющей процессов продажи;
§     автоматизациюсоставления бухгалтерской отчетности;
§     контрольза поступлением средств (оплата билетов и сопутствующих услуг);
§     интеграциюс электронными платежными системами.
Даннаяавтоматизированная система поддерживает работу многочисленных офисов продажбилетов, территориально удаленных от главного офиса. При этом для каждого офисанастраивается свой набор способов заказа, доставки и оплаты перевозок исопутствующих услуг.
Всостав возможностей системы входит ведение базы клиентов. Это позволяетповысить качество и существенно снизить трудоемкость их обслуживания. Она такжепредоставляет возможности проведения маркетинговых исследований и создаетоснову для проведения маркетинговых акций.
1.1.4    Структурно-функциональнаядиаграмма организации деятельности «КАК ЕСТЬ»
/>
Рис.1.6. Функциональное направление деятельности предприятия

/>
Рис.1.7. Функциональное направление деятельности предприятия
1.2          Характеристикакомплекса задач, задачи и обоснование необходимости автоматизации
1.2.1    Выборкомплекса задач автоматизации и характеристика существующих бизнес процессов
Видыуслуг, оказываемые компанией ООО «Зритель»:
§     информацияо мероприятии (сайт компании, call-центр)
§     заказбилетов на мероприятие (сайт компании, call-центр)
§     доставкабилетов на мероприятие (Москва, МО)
§     выкупбилетов на мероприятие в кассе (Москва, МО, регионы России).
Намой взгляд, самым приоритетным комплексом задач на данный момент в компании ООО«Зритель» является: заказа билетов на зрелищные мероприятия через web-порталыwww.parter.ru и www.kontramarka.ru.
1.2.2    Определениеместа проектируемой задачи в комплексе задач
Задачаавтоматизации, которую я в дальнейшем планирую исследовать и разрабатывать,является «Автоматизация реализации билетов через web-порталООО «Зритель».
Входныеинформационные потоки:
§     регистрационныеданные клиента;
§     заказклиента.
Выходныеинформационные потоки:
§     обработанныйзаказ
Клиентрегистрируется на одном из сайтов компании ООО «Зритель» (parter.ru,kontramarka.ru) указывая всю необходимую информацию о себе (e-mail, Ф.И.О.,телефон, адрес). После этого, он сможет выбрать интересующее его мероприятие, изаказать на него билеты.
Этопроисходит следующим образом:
Клиентищет интересующее мероприятие. Найдя его, он заходит на страницу мероприятия(где может ознакомиться с описанием мероприятия, со схемой зала и т.п.).Выбирает интересующий его сеанс, и нажимает на ссылку «Заказать билеты». Послеэтого, он попадает на страницу заказа билетов, где может выбрать кол-во билетови расположение мест. В момент заказа, клиент может изменить адрес доставки, выбратьвид доставки (самовыкуп в кассе, доставка), выбрать удобный для себя способоплаты, удобное время доставки, детально ознакомиться со всей информацией позаказу, и осуществить заказ.
1.2.3    Сущностьзадачи и предметная технология её решения
ООО«Зритель» — общество с ограниченной ответственностью«Зритель». Билетное интернет-агентство.
 Интернет-портал — web-сайт, предоставляющий пользователюИнтернета различные интерактивные сервисы, работающие в рамках одного web-сайта,такие как почта, поиск, погода, новости, форумы, обсуждения, голосования и т.д.
Интернет-магазин — сайт, принимающий заказы на материальные или электронные услуги отпосетителей в режиме on-line.
Call-центр — операторский центр обработки входящих и исходящих звонков.
Наданный момент процесс заказа билетов осуществляется по средствам web-порталаи через операторов Call-центра. Дляосуществления заказа через операторов Call-центра,клиенту достаточно позвонить по телефону (258-0000), и оператор поможет выбратьинтересующее мероприятие, интересующий сеанс, места в зале и объяснит, какимобразом клиент сможет выкупить билеты. Заказывая билеты через web-портал,клиент сам выбирает интересующее мероприятие, сеанс, места в зале, и способвыкупа билетов.
Способывыкупа билетов:
§     доставкакурьером по Москве и МО
§     выкупбилетов в кассе (Москва, МО, регионы России)
Послеавтоматизации, которую я планирую осуществить в данной компании, добавиться ещёодин способ заказа и получения билетов (print@home– печать билетов клиентом на домашнем принтере).
Print@home:
Впервыев России у интернет пользователей появиться уникальная возможность распечататьнастоящий билет дома или в офисе, на собственном принтере.
Процедуразаказа и получения билетов очень проста:
Клиентзаказывает билеты на сайте и выбирает способ оплаты через интернет.
Минуяутомительные походы в кассу или ожидание курьера, распечатывает билет напринтере самостоятельно.
Простаяи удобная услуга, которой уже давно пользуются во всем мире, впервые будетвведена в России только сейчас.
Работас print@home:
Услугаprint@home возможна только при оплате заказа через интернет.
Настранице «Оплата» оформления заказа клиент выбирает способ оплаты заказа«Оплата через Интернет».
Настранице «Доставка» оформления заказа клиент выбирает способ получения билетов«print@home».
Послеэтого, клиент проверяет все данные заказа на странице «Обзор заказа»: названиемероприятия, количество билетов, способ получения заказа, общая стоимостьзаказа. Для перехода на страницу оплаты клиент нажимает кнопку «Завершитьзаказ».
Далееосуществляется переход на страницу системы электронных платежей Asssist. Выбравплатежное средство, клиенту следует нажать на кнопку «Продолжить».
Длятого, чтобы оплатить заказ, клиент заполняет необходимые поля: тип карты (VISAInternational, MasterCard International), 16-тизначный номер карты, срок карты,имя владельца карты, CVC2/CVV2, защитный код и нажимает кнопку «Оплатить».
Посленажатия на кнопку «Оплатить» клиент снова переходит на сайт на страницу сномером своего заказа, а также ссылкой на страницу своих заказов, где он можетраспечатать свой билет. Билет предоставляется в формате .pdf (для его просмотраклиенту необходим Acrobat Reader).
Билетдействителен только в формате А4. Ни в коем случае не следует его обрезать. Повторныйпроход на место проведения мероприятия по копии или оригиналу билетаневозможен.
1.2.4    Обоснованиянеобходимости использования вычислительной техники для решения задачи
Вычислительнаятехника, которая используется в ООО «Зритель» должна обеспечивать:
§     автоматизациюпроцессов заказа билетов;
§     возможностьиспользования одновременно различных способов оплаты;
§     автоматизациюфинансового учета и отчетности;
§     возможностьорганизации службы доставки билетов.
Всявычислительная техника ООО «Зритель» объединена в единую компьютерную сеть,которая поддерживает работу многочисленных филиалов по продаже билетов,территориально удаленных от главного офиса.
Всостав сети входит сервер базы клиентов, который позволяет повысить качество исущественно снизить трудоемкость их обслуживания.
1.2.5    Описаниесвойств ИС, требуемых для решения выбранной задачи
Послезавершения автоматизации, будет внедрён новый способ заказа и получения билетовна зрелищные мероприятия.
Плюсыданной автоматизации таковы:
§     уклиента отпадёт необходимость выкупать билеты в кассе, что в свою очередьпозволит ему сэкономить драгоценное время;
§     клиентуне нужно будет проводить время в томительном ожидании курьера с приобретённымибилетами;
§     клиентбудет сам осуществлять весь процесс заказа и распечатки билетов;
§     даннаяуслуга положительно скажется на имидже компании, т.к. в России эта услуга ещёни разу не предоставлялась другими билетными – агентствами;
§     высокаястепень защиты позволит обезопасить клиентов от подделки их билетов.

1.3          Анализсуществующих разработок и выбор стратегии автоматизации «КАК ДОЛЖНО БЫТЬ»
1.3.1    Анализсуществующих разработок для автоматизации задачи
Прошлите времена, когда представительство или интернет-магазин открывались компаниямитолько из-за того, что это считалось модным и престижным. Сейчас объективноето, что электрона коммерция с каждым днем набирает обороты. Ключевыми словамипри создании собственного бизнеса в глобальной сети становятся слова«выгодный», «прибыльный». Да, по данным Austin's Center for Research inElectronic Commerce только на сегодняшний день в интернет — индустрии занятобольше чем 2.5 млн. людей.
Ежегоднаяпродажа через глобальную сеть составляет более 132 млрд. $, при этомпрогнозируется, что уже до 2009 года эта цифра вырастет до 2 трлн. $.
Этоимеет под собой логические обоснования, потому что преимущества электроннойкоммерции очевидны:
§     открытиеинтернет — магазина в кратчайшие сроки;
§     сокращениерасходов на аренду торговых площадей;
§     уменьшениерасходов на торговом оборудовании, содержании штата сотрудников и томуподобное;
§     отсутствиесогласований и расходов на лояльные отношения с многообразными инстанциями:пожарной инспекцией, коммунальными службами и др.;
§     расширениезоны охватывания бизнеса;
§     суточныеканалы реализации;
§     представлениевсего ассортимента и полной информации о нём.
Ноза определенными позициями электронная коммерция также требует денежныхвложений:
§     созданиеинтернет – магазина;
§     размещениев сети и техническая поддержка;
§     обновлениеи администрирование;
§     отдельнаямаркетинговая стратегия и схема продаж;
§     организациядоставки и послепродажного сервиса;
§     рекламноераскручивание и продвижение.
Всеэти расходы обязательные для достижения успеха на рынке электронной коммерции.
Задачаэффективного обеспечения поставок всегда стояла перед предприятиями независимоот их профиля, национальной или территориальной принадлежности и существующейэкономической модели. Даже во времена СССР, когда особенно ценились специалистыпо снабжению, которые способны перехитрить бюрократическую машину плановогоделения дефицитной продукции и все же сделать возможным выполнение иперевыполнение производственного или торгового плана предприятия. Многоизменилось с тех пор, но управление поставками не стало проще.
Программыдля торговли в глобальной сети скорее подходят для продажи билетов, а не услуг.Информация о билетах размещается в каталогах, которые пользователипросматривают и делают заказ. Заказанные билеты потом доставляются потребителю.Главная разница между билетами и услугами являются в том, что билетыпроизводятся в массовом порядке и поддаются массовой персонализации.Предоставление услуг в каждом конкретном случае требует от поставщикаспециальных усилий, и к тому же у всех потребителей свои представления о техили других услугах. Например, служба переводов занимается переводами текстовдля пользователей, но все тексты разные. Услуги такого рода нельзя в точностивоспроизвести. По-настоящему персонализировавшая услуга предназначена толькодля конкретного потребителя и предоставляется только конкретным продавцом; онане подходит другому пользователю и не может применяться при других условиях.Более того, она может оказаться бесполезной для этого же потребителя в другойситуации.
Передтем как выбирать программу, которая лучше других подойдет к нашей специфике,необходимо точно определить ассортимент.
Таккак компания предлагает только билеты при небольшом объеме заказов, то сложнаяи дорогая программа не нужна. Несколько Web-страниц с описанием билетов достаточноудовлетворит как владельца магазина, так и потребителей. Каждая из такихстраниц должна быть связана с HTML-формой, которая используется для обработкизаказа. Это достаточно экономное решения, с помощью которого любой магазинможет начать онлайновую торговлю. С увеличением объему заказов или расширениямассортимента билетов такую систему несложно расширить и перевести наавтоматический режим обработки заказов, если Web-сайт имеет модульнуюструктуру.
Программапродажи должна быть удобной для потребителя. Это значит, что она должна хранитьего данные и преимущества. Это упрощает заказ для постоянных клиентов иповышает уровень их удовольствия. Следует сделать так, чтобы пользователи моглиискать необходимые билеты разными способами, как с помощью обычного пересмотрапредставленной продукции, так и с помощью поисковой системы. Еще один важныйвопрос: «Когда можно ожидать начала окупаемости инвестиций?» Чтобы ответить нанего, необходимо четко сформулировать цель. Вы хотите как возможно скорее выйтина уровень рентабельности? Ставите ли вы перед собой более долгосрочные задачии согласны на то, чтобы возвращение инвестиций начнется лишь через нескольколет?
Анализируярынок программных продуктов, наше внимание привлекло ряд автоматизированныхсистем, которые подойдут нам, например:
1.Билетнаясистема «Базис»
Билетнаясистема «Базис» представляет собой аппаратно-программный комплекс, выполняющийзадачи по автоматизации всех основных процессов реализации билетов (в том числечерез Интернет). Базис не только ведет учет денежных средств, вырученных спродажи билетов в зрелищных учреждениях, но и дает статическую информацию одинамике продаж и всевозможную необходимую отчетность. Этой программой можнообъединить в единую сеть разнообразные зрелищные учреждения и удалённораспространять билеты.
Предлагаемаятехнология основана на базе автоматизации технологических операций иинформации, циркулирующей в билетном хозяйстве зрелищного учреждения.
Основныепринципы:
Всяинформация, циркулирующая в билетном хозяйстве, структурируется, и заноситься вобщую базу данных. Программа, при необходимости, сама может отследить продажибилетов и предоставить отчёт в электронной форме.
Вместообычных операций с бумажными документами каждая технологическая операцияпроводится соответствующими сотрудниками (пользователями системы) черезкомпьютерную билетную систему. Таким образом, в любой момент времени сотрудникиоперативно получают доступ к самой актуальной информации из общей базы данных,изменяя ее в ходе выполнения операций; в том числе все отчеты, аналитическиесправки т.п. не хранятся, а динамически формируются в момент запроса ихпользователями.
Бумажныйдокумент, необходимый в деятельности билетного хозяйства, может быть полученпутем распечатки из системы, либо в момент совершения соответствующей операции,либо позже по явному запросу пользователя. Помимо этого бумажный билетраспечатывается на специализированном билетном термопринтере непосредственно вмомент выдачи (продажа зрителю кассиром, выдача распространителю и т.п.).
Внедрениеописанных принципов позволяет не только автоматизировать ведение билетногохозяйства, но и получить качественно новые возможности и перспективы в своейдеятельности за счет программного комплекса «Базис».
/>
Рис.1.8. Автоматизация при помощи программного комплекса «Базис»
Основныепреимущества:
Длязрелищных учреждений:
§     Оперативныйцентрализованный контроль над всеми технологическими процессами и ихучастниками.
§     Возможностьлегкой интеграции с другими программно-аппаратными средствами, в том числе ссистемами входного контроля зрителей.
§     Различныесхемы обслуживания зрителей и распространителей (текущая продажа,предварительная продажа, адресная продажа, возврат билетов, разовые заявки,постоянный договор и др.).
§     Оперативноецентрализованное управление текущей реализацией билетов в реальном режимевремени.
§     Возможностиоперативной информационной рекламы на билетных носителях.
§     Бухгалтерскийучет операций в билетном хозяйстве.
§     Ведениебазы данных клиентов, адресный маркетинг, сбор и анализ статистическойинформации.
§     Полныйи четкий учет информации по каждому мероприятию, зрителю, клиенту, отдельномуместу, билету.
§     Прозрачностьбизнес — информации и данных.
§     Автоматическаяпубликация в Интернет, информации из базы данных о репертуаре, наличиисвободных мест и стоимости билетов.
§     Возможность удаленного заказабилетов пользователями сети Интернет, в реальном времени отслеживая статусымест в залах.
§     Различныеварианты оплаты (по магнитным картам, по безналичному расчету и др.).
§     Возможностьорганизации удалённых (мобильных) касс с использованием подключения через модеми выделенные линии.
Крометого, зрелищное учреждение, оснащенное автоматизированной билетной системой,получает возможность интегрирования в общее информационное пространство как своейкорпоративной организации (например, сеть кинотеатров), так и вмежкорпоративное информационное пространство (например, региональныйИнтернет-портал, городское билетное агентство и т.п.). Это дает ему следующиепреимущества:
Информационноевзаимодействие в реальном режиме времени при выполнении учреждениями корпорациисвоих технологических операций.
Продажабилетов из любого учреждения корпоративной сети не только на свои мероприятия,но и на любые другие мероприятия других учреждений корпоративной сети.
Получениесводной статистической, аналитической, отчетной информации, как по отдельномуучреждению, так и по всем учреждениям сети с различного рода группировкиинформации (по учреждениям, операторам, мероприятиям, времени и др.) в любыхсочетаниях.
Возможностьоборудования удаленных (вынесенных) точек реализации билетов во все учреждениякорпорации, билетных и справочных автоматов в местах наибольшего сосредоточенияпотенциальных зрителей.
Возможностьорганизации новых маркетинговых схем для привлечения посетителей: единыедисконтные клубные карты, системы накопительных скидок и депозитной оплаты, ит.п.
Централизованныйконтроль, разграничение доступа операторов корпоративной сети к общейинформации и выполнению технологических операций.
Хранениеи обработка информации в одной единой корпоративной базе данных, что повышаетнадежность работы и эффективность обслуживания системы.
Возможностьустановки на базе оборудования сети других корпоративных информационных систем,что повышает общую эффективность использования информационной инфраструктурыкорпорации и уменьшает затраты на ее содержание.
/>
Рис.1.9. Автоматизация при помощи программного комплекса «Базис» (2)
Длязрителя:
§     Возможностьполучения актуальной информации, заказа и бронирования билетов через Интернет.
§     Бронированиебилетов для коллективных заказчиков с выписыванием счетов на оплату.
§     Предоставлениезрителю информационных и рекламных услуг.
§     Возвратбилетов.
§     Возможностьразличных схем оплаты (клубная карта, дисконтная карта и т.д.)
Дляпартнеров:
§     Предоставлениерекламных услуг рекламодателям (например, на бланках билетов, программках,репертуарах, информационных табло).
§     Автоматизациядоговорных отношений с корпоративными и частными распространителями.
§     Быстротаи оперативность выполнения заявок корпоративных и частных распространителей.
§     Использованиесети Интернет для осуществления заявок.
§     Различныеформы оплаты.
2.Автоматизацияпродажи билетов GiS-Cinema
КомпаниейООО ”Гирус Софт” разработан и внедрен в ряд мультиплексов и кинотеатров Россиипрограммно-аппаратный комплекс для автоматизации продажи билетов.
Программно-аппаратныйкомплекс (далее GiS-Cinema) помогает осуществлять работу более продуктивно имаксимально эффективно, отвечать современным условиям ведения бизнеса.
Работас комплексом позволяет создавать новые и изменять существующие планымероприятий, переносить и утверждать сроки их проведения, определять абонементына каждое мероприятие, определять сектора доступные для продажи. На фирменныхбилетах организации, изготовленных в типографии, при продаже печатается всяинформация о мероприятии, дата и время его проведения.
Опытвнедрения автоматизации показывает, что увеличивается скорость продажи билетов,качество обслуживание посетителей мероприятия, возможность использования всехвидов платежей, широкий набор скидок или абонементов.
Каждыйкассир может продавать все свободные билеты, если иное не предусмотренонастройками программы. Отчеты формируются в реальном масштабе времени.Сформированный отчет можно получать по локальной сети или через Интернет.
Контроль,оперативность, полная информация помогают экономить время и деньги, чтопозволяет, изучая аналитическую и финансовую отчетность, улучшать работуорганизации, искать возможности увеличения прибыли и уменьшения затратнойчасти, привлечения новых рекламодателей и спонсоров мероприятий. Таким образом,GiS-Cinema позволяет:
§     Усилитьконтроль деятельности персонала;
§     Повыситьточность и скорость исполнения заказов;
§     Значительнорасширить перечень услуг привлечения клиентов;
§     Кардинальноуменьшить сроки обучения нового персонала;
§     Обеспечитьоперативное получение информации руководством.
Автоматизированнымрабочим местом (АРМ) будем называть оборудование и установленное на негопрограммное обеспечение (ПО) для выполнения определенных задач. В составкомплекса включены следующие АРМ:
§     Рабочееместо кассира;
§     Рабочееместо администратора кинотеатра;
§     Рабочееместо бухгалтера;
§     Рабочееместо руководителя;
§     Рабочееместо оператора Call-центра.
КомплексGiS-Cinema работает на АРМ, объединенных в локальную вычислительную сеть:

/>
Рис.1.10. Локальная вычислительная сеть, реализованная при помощи комплексаGiS-Cinema
Максимальноеколичество АРМ, подключаемых в сеть, ограничивается характеристикамикомпьютерной сети и центральным сервером.
Вкачестве рабочего места кассира используется IBM PC – совместимый компьютер, вкачестве дополнительных устройств используется принтер печати билетов(производители DATAMAX, ZEBRA и т.д.) и денежный ящик. При использованииабонементных карточек подключается считыватель штрих-кода или считывательмагнитных карт.
Кромеэтого еще на рынке программных продуктов присутствует множествоавтоматизированных систем, позволяющие решить данное задание, однако, все ониявляются дорогостоящими и имеют другое целевое предназначение, по этомувыгоднее решить эту задачу с помощью открытых систем.
1.3.2    Выбори обоснование стратегии автоматизации задачи
Цельюсоздания системы печати билетов клиентом на собственном принтере являетсявозможностью расширения аудитории покупателей билетов благодаря использованиюInternet-технологий.
Internetявляется гетерогенной системой, то есть системой, узлы которой могут иметьмногообразную внутреннюю аппаратную и программную структуру. Из-за этого нетвозможности использовать технологии, реализация которых возможна лишь наопределенном виде программно-технических средств. Следовательно, в решениизадачи необходимо использовать открытые технологии.
Задачареализуется с использованием Internet — технологий, которые являются открытымипо их способу реализации.
ИспользованиеHTML-конструкций предоставляет возможность просмотра страниц сайта на любом ПК,на котором есть Web-браузер и подключение к Internet, что даёт возможностьрасширить аудиторию покупателей интернет — магазина. Из-за того, что страницысайта должны быть динамическими и иметь возможность обновляться с БД сервера,нам необходимо использовать бесплатно распространяемый языка программированияPHP. Программные вставки PHP используются для динамического наполнения страницсайта, доступа к базам данных серверов или для других целей.
Вкачестве Web-сервера используется также бесплатно распространяемый HTTP-серверApache. Сервер Apache имеет возможность подключения новых типов документов имодулей с возможностью их обработки.
Задачаиспользует СУБД Interbase из-за того, что данная СУБД обладает достаточной для Web-дополненийпроизводительностью, и некоторыми функциональными особенностями по сравнению состандартной для решения задач этого плана СУБД MySQL.
Общаясхема стратегии решения задачи предоставлена на рис. 1.11. На рисунке видно,что конечными пользователями системы является клиент (пользователь Internet) именеджер по продаже. Клиент, просматривая каталог мероприятий, выбирает,заказывает билеты на сайте и подтверждает заказ. После этого клиент выбираетвид оплаты. Если это оплата по платежному поручению, то клиенту дополнительно пересылаетсябланк платежного поручения с заполненными графами получателя платежа. Менеджерпо продаже просматривает подтвержденные заказы, которые загружает из БД сайта,и сравнивает полученные данные с данным выписки из счета торговой организации(если оплата по платежному поручению). Характеристика задач, которые разрешаютсяна сервере, приведена в табл. 1.2.
/>
Рис.1.11. Общая стратегия решения задачи
Таблица1.3.
Характеристиказадач, которые разрешаются на сервере
Код задачи
Наименование задами
Назначение задачи
Режим решения
Периодичность решения 0810 Заказ билета Оформление заказа покупателем Интерактивный По запросу клиента 0811 Поиск мероприятия покупателем Получение информации покупателем Интерактивный По запросу клиента 0812 Формирование реестра заказов Получение реестра заказов менеджером по продаже Интерактивный Один раз в день
1.3.3    Выбори обоснование способа приобретения ИС для автоматизации задачи
Из-затого, что Internet-технологии в своем большинстве являются открытымитехнологиями, для разработки самих дополнений можно использовать любойтекстовый редактор. Но для разработки дополнений данной квалификационной работыиспользовался профессиональный пакет разработки Web-страниц MacromediaDreamweaver MX, который соединяет в себе скорость визуальной разработки сайтови точность ручной разработки. Кроме того этот пакет поддерживает разработкуPHP-скриптов.
 Вкачестве языка серверных вставок используется бесплатный скрипт-язык PHP. Онаявляется удобной для разработки серверных вставок и кроме того, из-за того, чтоее интерпретатор является реализованным в виде модулей, поддерживается многимиHTTP-серверами.
 Дляхранения и выборки данных используется СУБД Interbase компании Borland SoftwareCorporation. Она зарекомендовала себя как легкая СУБД с достаточно высокимискоростными показателями и малой потребностью системных ресурсов. Кроме того,по сравнению со стандартной для решения задач данного типа СУБД MySQL, СУБДInterbase имеет достаточные функциональные возможности для последующейинтеграции в подсистемы торговой организации. Это, прежде всего, объясняетсяподдержкой триггеров, процедур, которые сохраняются на сервере, ипредставлений.
 Такжеиспользуется бесплатный HTTP-сервер Apache, который зарекомендовал себя какбезопасный, надежный, быстрый сервер с возможностью подключения модулейрасширения.
 Дляразметки Web-страниц использовался язык гипертекстовой разметки HTML (HyperTextMarkup Language). Сам язык реализован в виде дескрипторов маркеров, которыеописывают размещения элементов страницы, а также дополнительные характеристикикаждого элемента.
1.4          Развёрнутаяпостановка целей, задачи и подзадач автоматизации
1.4.1    Трансформациябазовой технологии решения задачи
Трансформациязадачи заключается в следующем. Клиент со своего домашнего компьютера «заходит»на главную страницу интернет — магазина, регистрируется там, если он не былклиентом раньше, выбирает интересующее его мероприятие, оформляет заказ,подтверждает его и выбирает вид оплаты. После этого, перед окончанием рабочегодня, менеджер по продажам делает запрос на получение реестра заказов,просматривает его и сравнивает его с выпиской из банка, которую предоставилабухгалтерия. После этого менеджер оповещает клиента, что тот может распечататьбилеты на своём принтере, что тот и делает.
 Такимобразом, в БД сохраняются данные о клиентах, их идентификационные данные,информация о билетах и заказах.
 Данныео клиенте формируются при регистрации его на сайте, при этом указывается адресдоставки, телефон, адрес электронной почты, паспортные данные клиента. Послеэтого клиент может пользоваться услугами интернет — магазина и таким образомформировать файл заказов, в котором указываются заказанные билеты, ихколичество и дата заказа. Информация о заказе окончательно записывается в файлзаказов после его подтверждения клиентом.
Процессыданной задачи носят учетный характер, поэтому их можно автоматизировать.
Переченьобъектов, при управлении которыми решается задача:
 Задачарешается под управлением отдела сбыта при взаимодействии с маркетинговымотделом и подсистемой учета. При решении задачи автоматизируются функцииконсультационного персонала.
Периодичностьрешения и ограничения сроков выдачи исходной информации:
 Задачаоформления заказов решается в зависимости от запроса клиентов, а задачаформирования реестра заказов — ежедневно. Формирование реестра система должнареализовывать с приблизительной задержкой 6 секунд.
Условия,при которых прекращается решение задачи автоматизированным способом:
 Решениезадачи прекращается при выходе из строя компонентов аппаратной части сервера,коммуникационного оборудования, HTTP-сервера или его модулей, СУБД, припрекращении соединения клиентской части с сетью.
Сотрудники,наименования подразделов, которые определяют условия и характеристикиконкретного решения задачи:
 Условияи время решения данной задачи определяет начальник отдела сбыта.
Делениефункций между персоналом и техническими средствами в разных ситуациях решениязадачи:
 ОбновлениемБД сайта и самого сайта занимается его администратор и редактор.
1.4.2    Целии назначение автоматизированного варианта решения задачи
Цельюрешения задачи является автоматизация рутинных функций менеджера по продаже ифункций торговых касс с целью снижения расходов на их содержание. Кроме того,решение этой задачи уменьшает расходы относительно аренды помещений под кассы идоставки билетов.

1.5          Обоснованиепроектных решений
1.5.1    Обоснованиепроектных решений по техническому обеспечению
Техническоеобеспечение (ТО) является одной из наиболее важных подсистем инфраструктуры ИС,т.к. она определяет эффективность внедрения ИС и ее быстродействие. Уровень автоматизациифункций управления в значительной мере зависит от прогрессивности применяемыхтехнических средств.
ОсновуТО ИС составляют компьютеры, размещенные в отделах организации, и сетевыесоединения, которые определяют скорость передачи информации, то есть скоростьполучения информации конечным или промежуточным пользователем.
Любойкомпьютер имеет три основных части: процессор, память и периферийныеустройства. Они взаимодействуют между собой с помощью шин, стандартизациякоторых делает архитектуру компьютеров открытой.
Процессорявляется основным «мозговым» узлом, в задачи которого входит выполнениепрограммного кода, который находится в памяти.
Памятькомпьютера предназначена для краткосрочного и долгосрочного хранения информации- кодов команд и данных. Память делиться на внешнюю и внутреннюю. Под последнейпонимается электронная память, которая устанавливается на системную плату илина платах расширения. Внешняя память — память, которая реализована в видеустройств с разными принципами хранения информации и обычно подвижныминосителями. Сюда входят устройства магнитной памяти, оптической имагнитооптической памяти.
Дляподсистемы памяти важными параметрами являются следующие:
§     объеминформации, что сохраняется;
§     времядоступа — средняя задержка начала обмена полезной информацией относительнопоявления запроса на данные;
§     скоростьобмена при передаче потока данных (после задержки на время доступа);
§     удельнаястоимость хранения единицы данных — цена накопителя (с носителями), отнесеннаяк единице хранения (байту или мегабайту).
Системнаяили материнская плата персонального компьютера является основой системногоблока, которая определяет архитектуру и производительность компьютера в целом.Современные платы выполняются на основе чипсетов (chipset) — наборов изнескольких ВИС, которые реализуют все необходимые функции связи основныхкомпонентов — процессора, памяти и шин расширения.
Требованияк современным видеокартам в целом простые: они должны обеспечивать работу вразных операционных системах и разных программных дополнениях, поддерживатьакселерацию работы с документами в двумерном режиме, презентациями имультимедиа.
Основныминтерфейсами «общения» человека с ПК есть монитор компьютера, клавиатура иманипулятор мышь. Они являются основными приборами ввода-вывода информации, безкоторых бы процесс диалога пользователя с ПК существенно осложнился бы. Дополнительными,периферийными устройствами являются принтеры, сканеры др.
Насовременном этапе развития компьютерной техники различают такие в зависимостиот принципа действия распространенные типы мониторов, это:
§     мониторына жидких кристаллах;
§     мониторыс электронно-лучевой трубкой.
Выборзависит от типа задач, которые выполняются пользователем, требованийотносительно энергосбережения и безопасности пользования.
Мониторына жидких кристаллах имеют плоский экран и низкую мощность потребленияэлектрической энергии но они не очень приспособлены для использования их вработе с цветом сравнительно с мониторами с электронно-лучевой трубкой. Дляофисных дополнений возможностей мониторов этого типа достаточно.
Мониторыс электронно-лучевой трубкой имеют высокую мощность потребления электрическойэнергии и занимают много места на рабочем столе из-за конструктивныеособенности. Кроме того, мониторы этого типа имеют ионизирующее излучение.
Такжемониторы различают по диагонали экрана. Наиболее распространенные линейки с диагональю15, 17, 19 и 21 дюймов. Мониторы большого размера лучше использовать дляграфических работ, в которых нужно видеть все детали изображения. Оптимальнымидля массового использования являются 15- и 17-дюймовые мониторы.
Другаяхарактеристика монитора — частота регенерации. Этот параметр также называетсячастотой кадровой развертки. Он показывает, сколько раз за секунду мониторполностью обновляет изображение на экране. Чем большая частота, тем меньшаяусталость глаз. Сегодня минимально допустимой считается частота в 75 Гц,нормальной — 85 Гц, комфортной — 100 Гц и больше. Этот параметр зависит такжеот характеристик видеокарты.
Любойперсональный компьютер должен уметь хранить данные, а для этого необходимоиметь накопитель на жестком магнитном диске (НЖМД) достаточной емкости. Дляобеспечения высокой производительности дополнений также необходимо чтобы НЖМДимел достаточное быстродействие записи и чтения из носителя информации. Сейчас впродаже существует много разновидностей НЖМД в зависимости от емкости — этовинчестеры от 20Гб до 250Гб.
Дополнительнодля архивного накопления информации можно использовать привод для записиоптических дисков. Современные технологии позволяют на одном DVD диске хранитьприблизительно 8Гб информации. Привод для чтения записи характеризуетсяскорость чтения, записи и перезаписи дисков.
Проектноерешение:
Именнорешение задачи требует разработки сетевой инфраструктуры, потому что именно каналысети могут соединять отдалённые один от другого узлы.
Подтопологией вычислительной сети понимают конфигурацию графа, вершинам которогоотвечают компьютеры сети, а ребрам — физические связки между ними. Следуетотметить, что конфигурация физических связей определяется электрическимисоединениями компьютеров между собой и может отличаться от конфигурациилогических связей между узлами сети. Логические связки являют собой маршрутыпередачи данных между узлами сети и создаются путем соответствующегоналаживания коммуникационного оборудования.
Выбортопологии электрических связей существенно влияет на многие характеристикисети. Например, наличие резервных связей повышает надежность сети и даетвозможность балансирования загрузки отдельных каналов. Простота присоединенияновых узлов, что свойственно для некоторых топологий, делает сеть легкорасширяемой. Экономические рассуждения часто приводят к выбору топологии, длякоторой является характерным минимальная суммарная длина линий связи.
Нарис. 1.12. изображена физическая структура ТО ООО «Зритель». Сетеваяинфраструктура организована с использованием архитектуры Fast Ethernet. Для нееявляется характерной физическая организация сети в виде звезды. На рисунке видно,что сеть имеет древовидную структуру. Ее центром является маршрутизатор, которыйсоединяет сети всех подразделов организации в единственную вычислительную сеть.Также в ТО сети присутствующие концентраторы для соединения отдельных узловсети. Они служат также для морализации использования маршрутизатора, чтообусловливается стремлением локализовать трафик подразделов. Кроме того такаяорганизация сети повышает ее беспечность. Скорость обмена данных для сетейархитектуры Fast Ethernet составляет 100Мбит/с. Это достаточная скорость дляработы современных программных комплексов офисного направления.
Вообщедля сети с архитектурой Ethernet характерна легкая расширяемость и простота вэксплуатации. В частности для сетей архитектуры Fast Ethernet характернанадежность функционирования сети даже при выходе из строя одного из узлов. Изрис. 1.12. видно, что только при условии выхода из строя главногомаршрутизатора возможна остановка функционирования сети. Расширяемость сетейэтой архитектуры зависит только от наличия свободных портов концентраторов(маршрутизаторов), но эта проблема является разрешимой, если использоватькаскадное подключение концентраторов (маршрутизаторов).
Сетиэтого типа имеют физическую организацию в виде звезды, и логическую — общейшины.
Каквидно из рис. 1.12. сердцем информационного обеспечения организации являетсяраспределенный сервер, который исполняет роль, как сервера web-дополнений,так и сервера распределенной БД.

/>
Рис.1.12. Структура технического обеспечения ООО «Зритель»
1.5.2    Обоснованиепроектных решений по информационному обеспечению
Дляразработки модели автоматизации использовалось следующее информационное обеспечение:
RationalRose использовалась для анализа требований к проекту, проектированию классовпроекта, их поведения, с использованием унифицированного языка моделированияUML. В настоящее время UML является одним из наиболее популярных инструментов всфере разработки объектно-ориентированных систем. UML является визуальнымязыком моделирования, который позволяет системным архитекторам представлятьсвое виденье системы в стандартной и легкой для понимания форме. Кроме того,UML предоставляет эффективный механизм общего использования проектных решений ивзаимодействия разработчиков друг с другом.
ComputerAssociates ERwin 4.0 использовалась для проектирования логической и физическойструктуры БД. В качестве нотации использовалась нотация IDEF1X. ERwin былразработан для поддержки таких стандартов моделирования как IDEF1X и IE. МетодологияIDEF1X поддерживает многоуровневую структуру модели. Более того высокой уровеньмодели меньше будет зависеть от физической реализации БД. Например, одна и та жемодель БД спроектирована для СУБД DB2 будет отличаться от той же модели БД дляСУБД MS SQL, но на более высоких уровнях они (модели) будут одинаковыми. Этотпринцип и используется в ERwin. Computer Associates ERwin поддерживаетгенерацию БД для многих серверов. Генерация БД реализована через механизмODBC-драйверов. Также поддерживается генерация SQL-скрипта БД. Этот метод и былиспользован при генерации БД модулю.
HTML- (HyperText Markup Language) язык разметки гипертекста. Представляет собойорганизованную совокупность маркеров, которые интерпретируются браузеромопределенным образом. В связи с конкуренцией за рынки сбыта компаний Microsoftи Netscape не было разработано единого стандарта этого языка. Это поставилоразработчиков web-дополнений в тяжелоеположение, из-за того, что было необходимо поддерживать два основных стандартаHTML: стандарт от Microsoft и Netscape. Но вскоре появился единственныйстандарт от консорциума W3, но и сейчас браузеры компаний-производителей невсегда в полном объеме поддерживают этот стандарт.
CSS- (Cascading Style Sheets) каскадные таблицы стилей являют собой простуютехнологию определения и присоединения стилей к HTML документу. Стиль — это всето, что определяет внешний вид документу при его отображении в окне браузера:шрифт, цвет, границы таблиц, их цвет, позиционирование объектов и др. Таблицастилей — это шаблон, который руководит форматированием HTML тэгов в web-документе.
PHPявляется слабо типизирующим языком. Был избран именно этот язык благодаря егосходству со структурами управления на язык С++. Кроме того, использование этогоязыка в разработке web-дополненийявляется достаточно распространенным явлением. Это в большинстве случаев обусловленоего доступностью и простотой.
JavaScript- используется в основном для проверки данных пользователя и реализацииинтерактивности web-дополнений.Скрипт выполняется со стороны клиента. Его синтаксис очень похож синтаксис С++.Имеет встроенные объекты, которые позволяют обращаться к некоторым функциямбраузера.
1.5.3    Обоснованиепроектных решений по программному обеспечению
Из-затого, что Internet-технологии в своем большинстве являются открытымитехнологиями, для разработки самих дополнений можно использовать любойтекстовый редактор. Но для разработки дополнений данной квалификационной работыиспользовался профессиональный пакет разработки web-страницMacromedia Dreamweaver MX, который соединяет в себе скорость визуальнойразработки сайтов и точность ручной разработки. Кроме того этот пакетподдерживает разработку PHP-скриптов.
Вкачестве языка серверных вставок используется бесплатный скрипт-язык PHP. Онудобен для разработки серверных вставок и, кроме того, из-за того, что егоинтерпретатор реализован в виде модулей, поддерживается многими HTTP-серверами.
Дляхранения и выборки данных используется СУБД Interbase компании Borland SoftwareCorporation. Она зарекомендовала себя как легкая СУБД с достаточно высокимискоростными показателями и малой потребностью системных ресурсов. Кроме того,по сравнению со стандартной для решения задач данного типа СУБД MySQL, СУБДInterbase имеет достаточные функциональные возможности для последующейинтеграции в подсистемы торговой организации. Это, прежде всего, объясняетсяподдержкой триггеров, процедур, которые сохраняются на сервере, ипредставлений.
Такжеиспользуется бесплатный HTTP-сервер Apache, который зарекомендовал себя какбезопасный, надежный, быстрый сервер с возможностью подключения модулейрасширения.
Дляразметки Web-страниц использовался язык гипертекстовой разметки HTML (HyperTextMarkup Language). Сам язык реализован в виде дескрипторов маркеров, которыеописывают размещения элементов страницы, а также дополнительные характеристикикаждого элемента.

IIПроектная часть
2.1          Разработкапроекта автоматизации: информационный менеджмент
2.1.1 Этапы жизненного цикла проектаавтоматизации
Очевидно,что функции, выполняемые разработчиками проекта, в ходе его развитияпретерпевают изменения, как, в прочем, и сам проект. Сначала он существует ввиде заявки на разработку, затем — как функциональные и технические требования,далее — как спецификации разрабатываемого изделия, набор программных модулей,скомпонованная из модулей система и т.д. Этот перечень можно рассматривать какодин из примеров модели жизненного цикла программного изделия, т.е.представления эволюции разработки и последующего использования программнойсистемы.
Жизненныйцикл — это проекция пользовательского понятия «время жизни» на понятиеразработчика «технологический цикл (цикл разработки)».
Необходимостьвнесения изменений в действующие программы есть по сути дела продолжениеразработки программного обеспечения после передачи его пользователю и в течениевсего времени жизни программ. Деятельность, связанная с решением довольномногочисленных задач такой продолжающейся разработки получила названиесопровождения программного обеспечения (Рис. 2.1.) Использование Разработка Продолжающаяся разработка (сопровождение)
Рис. 2.1. Разработка,использование и сопровождение
программного обеспечения

Историческиразвитие концепций жизненного цикла связано с поиском для него адекватныхмоделей. Как и всякая другая, модель жизненного цикла является абстракциейреального процесса, в которой опущены детали, несущественные с точки зренияназначения модели. Разнообразие назначений определяет разнообразие моделей.
Вероятно,самым распространенным мотивом обращения к понятию жизненного цикла являетсяпотребность в систематизации работ в соответствии с технологическим процессом.Этому назначению хорошо соответствует так называемая общепринятая модельжизненного цикла программного обеспечения, согласно которой программные системыпроходят в своем развитии две фазы: разработку и сопровождение.
Фазыразбиваются на ряд этапов (Рис. 2.1., 2.2.).
/>
Рис. 2.2. Модель жизненного цикла проекта
Разработканачинается с идентификации потребности в новом приложении, а заканчиваетсяпередачей продукта разработки в эксплуатацию.
Первымэтапом фазы разработки является постановка задачи и определение требований.Определение требований включает описание общего контекста задачи, ожидаемыхфункций системы и ее ограничений. На этом этапе заказчик совместно сразработчиками принимает решение, стоит ли делать систему.
Вслучае положительного решения начинается этап спецификации требований.Разработчики программного обеспечения пытаются осмыслить выдвигаемые заказчикомтребования и зафиксировать их в виде спецификаций системы. Важно подчеркнуть,что назначение этих спецификаций — описывать внешнее поведение разрабатываемойсистемы, а не ее внутреннюю организацию, т.е. отвечать на вопрос, что онадолжна делать, а не как это будет реализовано. Здесь говорится о назначении, ане о форме спецификаций, поскольку на практике при отсутствии подходящего языкаспецификаций, к сожалению, нередко приходится прибегать к описанию «что»посредством «как». Прежде чем приступать к созданию проекта по спецификациям,они должны быть тщательно проверены на соответствие исходным целям, полноту,совместимость (непротиворечивость) и однозначность.
Разработкапроектных решений, отвечающих на вопрос как, должна быть реализована система,чтобы она могла удовлетворять специфицированным требованиям, выполняется наэтапе проектирования. Поскольку сложность системы в целом может быть оченьбольшой, главной задачей этого этапа является последовательная декомпозициясистемы до уровня очевидно реализуемых модулей или процедур.
Наследующем этапе реализации, или кодирования каждый из этих модулей программируетсяна своем наиболее подходящем для данного приложения языке. С точки зренияавтоматизации этот этап традиционно является наиболее развитым.
Далеефаза разработки заканчивается этапом тестирования (автономного и комплексного)и передачей системы в эксплуатацию.
Фазаэксплуатации и сопровождения включает в себя всю деятельность по обеспечениюнормального функционирования программных систем, в том числе фиксированиевскрытых во время исполнения программ ошибок, поиск причин и их исправление,повышение эксплуатационных характеристик системы, адаптацию системы кокружающей среде, а также, при необходимости, и более существенные работы посовершенствованию системы.
Всвязи с этим данная фаза разбивается на два этапа: собственно сопровождение иразвитие. В ряде случаев на данную фазу приходится большая часть средств,расходуемых в процессе жизненного цикла программного обеспечения.
Такимобразом, данный проект по автоматизации содержит семь этапов, разделенных вовремени (Рис. 2.3.).
/>
Рис.2.3. Модель жизненного цикла проекта автоматизации

2.1.2    Разработкаи описание проекта автоматизации, плана-графика автоматизации и сетевой моделизадач
План-график— это поэтапно разбитая и упорядоченная по времени выполненияпоследовательность работ проекта. Его содержание позволяет руководствупланировать деятельность коллектива разработчиков проекта как подразделенияфирмы в целом. Как правило, план предъявляется заказчику с тем, чтобы заказчикориентировался в сроках поэтапного выполнения задания. Это внешние функциикалендарного плана.
Обычныйплан-график представляется в виде таблицы со следующей структурой:
Таблица2.1.
Обычныйплан-графикНаименование работ (тема, работа, задача, задание) Сроки выполнения начало/конец Ответственный исполнитель и исполнители, роли Требуемые ресурсы и сроки их предоставления план/факт Примечания план факт 1 2 3 4 5 6
Столбец1 заполняется в соответствии с разбиением заказанного проекта на составляющие.Обычно глубина рубрикации разбиения зависит от уровня проработанности того илииного фрагмента проекта. По мере углубления декомпозиции и уточнения задачвводятся новые строки таблицы, которые должны вписываться в ранее составленнуюструктуру и не противоречить ограничениям, налагаемым ранее (сроки,исполнители, ресурсы).
Распределениевремени и контроль над ним — назначение столбцов 2 и 3. В них указываютсякалендарные даты планируемого (столбец 2) и фактического (столбец 3) сроковвыполнения работы, задачи или задания. Планируемое начало работы — это самаяранняя дата, после которой можно приступать к выполнению; конец — этопредельный срок отчета исполнителей перед менеджером. Иногда граф планируемыхсроков дополняется критическими и целесообразными сроками начала/конца работы.Это позволяет менеджеру более точно следить за распределением временныхресурсов.
Столбец4 «Ответственный исполнитель и исполнители, роли» задает информацию о том, ктоработает над данным заданием, и какая квалификация от исполнителей требуется.Возможно дополнение этого столбца сведениями о том, на какие периоды выделентот или иной исполнитель для выполнения задания, предполагается ли подменаисполнителей и т.п. В прочем, необходимость подобных дополнений свидетельствуето некачественном решении задачи распределения кадровых ресурсов. А вот еще однодополнение столбца исполнителей, которое часто практикуют в управлении,напротив, весьма полезно. Имеются ввиду подписи всех упомянутых исполнителей, подтверждающаязнакомство с содержанием, сроками и условиями выполнения задания.
Распределениетехнических ресурсов и задание сроков их предоставления — содержание столбца 5.Здесь указывается необходимая для выполнения задания техническая, а в рядеслучаев, и программная база. Иногда этот раздел дополняется сведениями о лицах,отвечающих за выполнение указываемых требований. Это удобно как для менеджера,так и для ответственных исполнителей: наглядно видны нарушения поставок(несоответствия между плановыми и фактическими сроками). Полезным расширениемсостава сведений столбца 5 является включение в него информации о зависимостиработ внутри проекта, т.е. перечисление заданий (в том числе, ссылки на другиестроки данного календарного плана), без выполнения которых осуществимостьпланируемых работ нарушается. Отслеживание зависимостей работ — это болеесодержательная задача выполнения проекта по сравнению с тем, что можно получитьчерез только что указанное расширение календарного плана, и ей в дальнейшембудет уделено внимание.
План-графикудобен в трех отношениях. Во-первых, его верхний уровень рубрикации почти вточности совпадает (должен совпадать) с тем, что составляет предметрассмотрения технического задания на проектирование (во времена СССР ГОСТы требовалиобязательного включения календарного плана в документы, сопровождающиепроцедуру заключения договора на проведения любых работ). Во-вторых, дополнениекалендарного плана новыми рубриками (строками таблицы), в том числе, в процессевыполнения проекта не вызывает трудностей. Наконец, в-третьих, он достаточнонагляден.
Вто же время, по мере углубления декомпозиции, календарный план имеет тенденциюк разрастанию, а, следовательно, обозревать работы проекта в целом становитсявсе труднее. В результате приходится дублировать логически единый документ,разбивать его на части в соответствии с уровнями ответственности иерархииработников проекта. Другой недостаток календарного плана — егонеприспособленность к решению такой важной задачи планирования, как учет загруженностиработников и определение текущих потребностей в перераспределении исполнителей.
Наиболееузким местом календарного плана является то, что его рубрикация зачастуюпротиворечит распараллеливанию работ, привязки параллельных работ и поставок ксрокам. Трудно увидеть все нужные показатели на определенный момент времени,трудно решать другие подобные задачи. Для преодоления указанных проблем обычноиспользуют графики сетевого планирования, или сетевых графиков.
Идеявсех многочисленных вариантов сетевого планирования заключается в выстраиванииработ проекта в виде специальных размеченных графов. Графы зависимостей работ,вершины которых представляют все работы проекта, а дуги — зависимости работ,определяемые следующим образом. Считается, что, если из одной вершины в другуюведет дуга, то работа, соответствующая второй вершине, может начаться только послезавершения первой работы, или вторая работа зависит от первой. Содержательныйсмысл, вкладываемый в понятие зависимости, может быть различным: от фактическойзависимости, когда одна работа использует результаты другой и именно поэтому неможет начаться до того, как эти результаты не будут получены, допринудительного упорядочивания работ, например, для учета ресурсныхограничений.
Графыспециально приспособлены для планирования времени и в этом качестве они болееуниверсально применимы. Для сетевого планирования очень больших проектовприменяют сочетание событийно-ориентированных графовых описаний проекта играфов зависимостей работ.
Графсетевой модели работ обычно дополняют начальной вершиной, в которую не ведет ниодна дуга, и конечной вершиной, достижимой из любой другой вершины.Приписываются ли конкретные работы этим двум выделенным вершинам, не имеетзначения, важно только то, что пути, ведущие из начальной в конечную вершину,отражают те и только те последовательности работ, которые нужно пройти приразвитии проекта. Каждый из таких путей называется операционным маршрутом. Сточностью до определения отношения зависимости работ другие допустимыепоследовательности работ невозможны.
Длянашего проекта сетевая модель работ представлена на рис. 2.4. Здесь каждая извершин графа зависимостей снабжается атрибутом длительности выполнения работы.Здесь возможны варианты: минимально необходимое и рациональное время выполненияработы, длительность выполнения работы как функция от квалификации исполнителейи т.п. Атрибут длительности позволяет расположить граф зависимостей вдольвременной оси, как это изображено на рис. 2.4. Изображение графа зависимостей впривязке к временной оси называется сетевым графиком выполнения работ.

/>
Рис. 2.4. Сетевая модель работ проекта автоматизации
Какпоказывает рисунок, построение сетевого графика не однозначно: рис. 2.4 (а)демонстрирует задание одновременности «начал» работ, а рис. 2.4 (б) — их«окончаний». Жирными стрелками на рисунке выделена последовательность работ 3,4, 10, 13, 14, которая определяет общую длительность проведения всех работ,выполняемых параллельно. При жесткой фиксации длительностей работ быстрее, чемза время
t(Р3) + t (Р4) + t(Р10) + t (Р13) + t(Р14)
(t(Рn) — длительность работы n) выполнить все планируемые работы невозможно. Этотак называемый критический операционный маршрут, т.е. такой маршрут, суммарноевремя прохождения которого является предельным для выполнения всех работграфика.
Возможно,что длительность работ жестко не фиксируется, в частности, когда онарассматривается как функция от используемых ресурсов (к примеру, некотораяработа выполняется за время t1 силами k1 исполнителей, и за t2 при использованииk2 исполнителей). Тогда правомерно ставить задачу перераспределения ресурсов ипостроения критического операционного маршрута, оптимального с точки зрениятого или иного критерия.
Впрактике планирования развития программных проектов более важным, чем решениеоптимизационных задач, для менеджера является построение реальной картинывыполнения работ с возможностью оперативного перераспределения ресурсов. Дляэтого каждую работу следует снабжать не одним атрибутом априорной еедлительности, а несколькими параметрами, важными для управления. Среди нихаприорная длительность занимает особое место лишь как параметр, с помощьюкоторого строится сетевой график. Другие параметры, важные для характеристикисостояния дел, это:
§     минимальнаякадровая и техническая ресурсная потребность, без удовлетворения которойвыполнение работы невозможно;
§     максимальновозможная ресурсная потребность;
§     минимальнонеобходимое время выполнения работы (при условии полной ее ресурснойобеспеченности).
Следующиехарактеристики каждой работы определяются после построения сетевого графика:
§     время,когда данная работа в принципе может начаться (по графику) — время возможногоначала работы;
§     время,позднее которого данная работа не должна продолжаться — время допустимого концаработы.
Входе выполнения проекта определяются и указываются на графике:
§     времяфактического начала работы;
§     времятекущего планового завершения работы;
§     времяфактического завершения работы.
Наконец,в каждый текущий момент выполнения проекта определяются:
§     текущаяресурсная обеспеченность (как доля максимально возможной потребности);
§     объемработы, выполненный и оставшийся к текущему моменту времени.
Приведенныйсписок адаптируется к условиям выполнения проекта. Методы привязки указанныхпараметров к сетевому графику могут быть различны. В частности, они зависят отсистемы автоматизации сетевого планирования (если ее использование в проектепредусмотрено то, как правило, такая система дает свои возможности оперированияс параметрами, сопутствующими сетевому графику). Тем не менее, можно указать наряд общих положений, которых стоит придерживаться при любом варианте сетевогопланирования (в том числе и при отсутствии средств его автоматизации):
Сетевойграфик можно строить как для проекта в целом, так и для отдельных его этапов.Кроме того, для больших проектов полезно использовать сетевые графики работгрупп исполнителей и даже отдельных исполнителей;
Целесообразноварьировать уровень детализации работ и отслеживаемых параметров на сетевыхграфиках, а также на отдельных операционных маршрутах. Большей детализациитребуют текущий и ближайший следующий этапы, больше отслеживаемых параметровтребуется для критического маршрута;
Дугиграфа зависимостей работ являются важной, но менее информативной частью сетевогографика по сравнению с выстраиваемой последовательностью работ. Гораздо важнееизображать временную вариантность выполняемых работ. В частности, по этойпричине в большинстве систем сетевого планирования предписывается изображатьявно все области возможного выполнения работ, т.е. отмечать:
§     времявозможного начала работы,
§     времядопустимого конца работы,
§     времяфактического начала работы,
§     времяфактического конца работы,
§     текущиймомент выполняемой в настоящее время работы.
2.1.3    Характеристикаархитектуры разрабатываемого проекта
Архитектура разрабатываемого проекта содержит, преждевсего, ряд основных элементов и связей между ними (Рис. 2.5).
/>
Рис. 2.5. Общая архитектура разрабатываемого проекта

Характеристикаструктурных единиц информации исходных сообщений, при такой архитектуре,приведена в табл. 2.2.
Таблица2.2.
Характеристикаструктурных единиц информации исходных сообщений
Тип строки
Наименование структурной единицы информации
Обозначение
Шаблон Прайс-лист Заглавный
Дата прайс-листа
Наименование категории билета
Pr_date
Pr_cat
99.X(8).9999
X(50) Информационный
№ билета
Наименование билета
Цена билета
Pr_id
Pr_name
Pr_price
999999
X(150)
99999,99 Платежное поручение Заглавный № платежного поручения Por_id 9999 Информационный
Дата оформления поручения
Дата получения банком
Плательщик
Банк плательщика
Код плательщика
Код банка плательщика
Дебет счета №
Получатель
Код получателя
Банк получателя
Код банка получателя
Кредит счета №
Сумма платежа
Назначение платежа
Дата проведения банком
Por_date
Por_bk_date
Por_plat_naim
Por_bk_plt_naim
Por_plat_id
Por_plat_bnk_id
Por_deb_c
Por_pol_naim
Por_pol_id
Por_bnk_pol
Por_bnk_pol_id
Por_cred_c
Por_sum
Por_nazn
Por_bnk_prov
99.X(8).9999
99.X(8).9999
Х(50)
Х(50)
Х(14)
Х(6)
Х(14)
Х(50)
Х(14)
Х(50)
Х(6)
Х(14)
99999,99
Х(80)
99.X(8).9999 Реестр подтвержденных заказов Заглавный Дата реестра Re_date 99.99.9999 Информационный
Номер заказа
Код клиента
ПІБ клиента
Сумма заказа
Вид оплаты
Re_ord_id
Re_clt_id
Re_clt_fio
Re_ord_sum
Re_paysys
99999
99999
Х(70)
99999,99
Х Итоговый Всего Re_sum 9999999,99
2.1.4    Характеристикаэтапа внедрения разрабатываемого проекта
Основной составляющей этапа внедренияявляется тестирование. План тестирования отвечает на вопросыкто, когда, что и как тестирует в данном проекте. Он специфицирует, какого видатесты нужно проводить для проверки результатов, и в каком порядке. Если проекттребует специальных видов проверок (например, используемыхпрограммно-технических ресурсов), это также отражается в плане.
Зачемнужно тестировать промежуточные рабочие продукты? Ответ на этот вопрос заключаетсяв двух положениях:
·                  во-первых,обнаружение ошибок как можно раньше позволяет избавиться от напраснойреализации неправильных решений, от использования неправильных (а потомупеределываемых в дальнейшем) компонентов, от обременительных возвратов к ужепройденному;
·                  во-вторых,легче обнаружить и исправить ошибку не в результате следствий из нее, которыесделали противоречие явным, а во время ее появления, когда ошибка не «обросла»многими связями и влияниями на другие компоненты программной системы.
Конкретныйплан тестирования может быть составлен, когда готов план итераций проекта, т.е.после прохождения контрольной точки 2 жизненного цикла проекта «Общиетребования и общий план составлены». До этого момента целесообразно разработатьобщие положения о тестировании, которые служат технологическим регламентом вдальнейшем. Эти положения фиксируют следующее. Для каждой деятельности,определенной в плане итераций, для каждой итерации и для проекта в целомуказывается:
·                  какиерезультаты тестируются, каким методом и как определяется, что тестированиевыполнено;
·                  какдля деятельности данного вида определяется период тестирования — время,отводимое для тестирования в плане итерации;
·                  какиекадровые и технические ресурсы требуются для каждого из периодов тестирования;
·                  какиеинструменты используются при тестировании данного вида деятельности.
Наиболеепросты для планирования тестирования рабочие продукты, связанные с анализом иконструированием: требуется проверка полноты, непротиворечивости и соответствияполучаемых результатов исходным положениям (требованиям — для анализа испецификациям — для конструирования). Период тестирования здесь можноопределить довольно точно. Он зависит от размеров рабочего продукта и заранеесоставляемого перечня вопросов, требующих ответа при изучении материалов,которые рассматриваются как содержание тестировочной работы. Кадровые ресурсыдля такого тестирования также вполне определены: как правило, изучениематериалов рабочего продукта не может быть поручено нескольким исполнителям,т.е. данный вид тестирования не допускает распараллеливания. Нет проблем и сопределением технических ресурсов, а также с тем, что считать окончаниемтестирования (получение ответов на весь перечень вопросов). В качествеинструментальной поддержки такого рода тестирования используются обычныесредства работы с текстами.
Болеесложным для планирования является тестирование программных рабочих продуктов.Главные причины тому — неопределенная сложность программирования как этапажизненного цикла. Она непосредственно зависит от решаемых на данном этапезадач, от использования инструментария поддержки (в частности, от языка исистемы программирования), а также от квалификации исполнителей рабочегопродукта. Кроме того, именно на этапе проверки программных рабочих продуктовпроявляют себя ошибки более ранних этапов, что вносит существенный вклад внеопределенность планирования тестирования. Эти трудности практическинепреодолимы при последовательной стратегии развития проекта. Длявозвратно-поступательного итеративного наращивания они во многом сглаживаютсяза счет обозримости свода задач каждой из итераций.
Конкретныеметодики, позволяющие планировать процессы тестирования программных рабочихпродуктов, связываются с разделением системы тестов на группы, отвечающие запроверку различных аспектов итерации:
·                  тестыдля проверки функциональности;
·                  тестыдля проверки корректности преобразований данных;
·                  интерфейсныетесты;
·                  специфичныедля данного проекта (итерации) тесты.
Длякаждой итерации определяется, что именно проверяется путем тестирования:идентифицируются тестируемые ситуации и что в этих ситуациях следует проверять(возможно, в виде базового набора тестов каждой группе), и что считаетсяправильным для данной ситуации. Требуется, чтобы в каждой тестируемой ситуациибыло определено, от каких программных и документных компонентов проекта оназависит. Эти сведения используются в ходе диагностики и исправления найденныхошибок.
Дляпроекта в целом устанавливаются единые правила протоколирования ошибок. В протоколецелесообразно указывать не только ошибочные ситуации, но и в результате чегоони проявили себя. Очень полезен, а для проектов с требованием высокогокачества тестирования обязателен пополняемый банк тестов со средствамиавтоматической (по крайней мере, автоматизированной) проверки выполненияимеющихся тестов, накапливаемых в банке.
Припланировании тестирования для проекта в целом и для каждой итерацииустанавливается требуемый уровень качества тестирования: высокий, средний инизкий (возможна и другая градация). Для его задания используются сведенияуточненного заказа и соглашения из Концепций развития проекта. Уровень качестватестирования — неформальный показатель, отражающий какое количество ошибок,оставшихся после проведения тестирования, считается допустимым (учитывается,что одни ошибки исправляются на текущей итерации, а другие — в ходе последующихитераций, возможно, в следующих релизах). Этот показатель прямо связывается свыделением времени и других ресурсов, для проведения тестирования, выполнениядиагностики и исправления ошибок:
·                  высокий— требует выделения для тестирования времени 95% и более из суммарного времени,отведенного для работ данной итерации;
·                  средний— для тестирования требуется от 20% до 50% из суммарного времени работ даннойитерации;
·                  низкий— для тестирования отводится порядка 5% суммарного времени работ даннойитерации.
Плантестирования, регламентирующий деятельность разработчиков проекта на этапепрограммирования итерации, просто расширяет временные рамки работ данного этапа— для автономной отладки строго разделять индивидуальные работынецелесообразно.
Плантестирования, регламентирующий деятельность тестировщиков и разработчиков наэтапе оценки (т.е. когда на данной итерации достигается контрольная точка 6жизненного цикла «Автономная проверка завершена, комплексное тестированиеначалось»), предусматривает соответствующий период в ходе оценочных работ,иногда выделяя его в качестве самостоятельного этапа.
Фиксируемыев ходе тестирования ошибки указывают на необходимость их исправления, котороеможет быть проведено либо в рамках текущей итерации, либо на последующихитерациях. Какой из этих вариантов для конкретной ошибки должен быть принят,определяется в рамках специальной деятельности, называемой диагностикой ошибки.Цели диагностики:
указатьпричину ошибки;
определить,что надо исправить и оценить ресурсы, которые необходимо выделить наисправление;
установитькогда исправление будет сделано.
Сточки зрения распределения ролей исполнителей проекта тестировщик решает толькозадачу фиксации ошибок, и, вообще говоря, оставляет в стороне задачудиагностики, решение которой — функция проектировщика подсистемы иразработчиков.
Критериемтого, что исправление ошибки следует перенести на последующие итерации, служитинформация о том, что на данной итерации не хватает ресурсов: временные рамкиили дефицит кадров итерации не позволяют осуществить исправление. Если это так,то менеджеру надлежит позаботиться о корректировке общего плана работпоследующих итераций. Как вариант, в рамках плана управления рискамидопускается увеличение сроков текущей итерации, которое должно быть согласованос заказчиком и планировщиком.
Приподготовке к началу проекта следует запланировать работы, прямо или косвенносвязанные с тестированием. К первого рода работам относится организация ужеупомянутого ведения банка тестов. Соответствующие средства могут бытьзаимствованы, и тогда требуется предусмотреть работы по их адаптации, либо ониреализуются как комплекс рабочих продуктов данного проекта, производимых наначальных этапах развития проекта, возможно, на первых итерациях. Косвенносвязаны с тестированием задачи минимизации ошибок, решение которых можетпотребовать специальных соглашений и регламентов разработки, а такжедополнительного кода программных компонент, предназначенного для контрольныхфункций. Выработка соглашений и регламентов для проекта — это деятельность,которая требует ресурсов на этапах конструирования, а составлениедополнительного кода нуждается в ресурсах, как при конструировании, так и наэтапах программирования.

2.1.5    Характеристикаэтапа эксплуатации разрабатываемого проекта и возможных работ
Основнойхарактеристикой этапа эксплуатации проекта является выпуск релизов по анализуэтапа.
Релиз— это вариант производимого программного изделия, предоставляемый дляиспользования. План выпуска релизов отображает требования к разработке в целомв последовательность релизов, версий, итераций в течение всего развитиясистемы. На уровне детального проекта этот план группирует конкретные этапы иработы графика работ, которые определяются исходя из концепции развитияпроекта, используемой в подготовительной деятельности в качестве моделидальнейшего развития проекта.
Такимобразом, план релизов строиться, исходя из двух, возможно, противоречивыхустремлений:
·                  логикипоступательного развития и
·                  важностипостепенного предоставления средств заказчику, которому план дает представлениео последовательности удовлетворения требований к изделию.
Следовательно,план выпуска релизов должен составляться менеджером при тесном контакте ссистемным архитектором, с одной стороны, а с другой — в ходе содержательныхконсультаций с заказчиком. В частности, выделение ближайших задач проекта, окоторых уже шла речь, — это не что иное, как первый релиз разрабатываемойсистемы. И этот релиз не должен противоречить логике развития проекта.
Совместнаяработа менеджера, архитектора и заказчика над планом релизов особенно важна длябольших проектов, когда только за счет постепенности наращивания предоставляемыхпользователю средств можно добиться действенной обратной связи длякорректировки априорных решений. В то же время, и не очень большие проекты,даже такие, которые предусматривают лишь один релиз, нуждаются в аналитическомисследовании, определяющем группировку и дифференциацию итераций, другиеэлементы декомпозиции. По существу, независимо от масштабов проекта планрелизов задает основу общего плана проекта, согласованного с пользовательскойпотребностью.
Изэтого следует, что план выпуска релизов должен составляться и утверждаться какможно раньше. Фактически все обязательные предпроектные работы (составлениедокументов о концепции развития проекта и распределении ресурсов, построениеплан-графика работ) исходят из пользовательского представления процессаразработки как последовательности поставок — релизов проектируемого изделия. Вчастности, при составлении плана выпуска релизов и его согласовании выясняется,какие решения неприемлемы для компании, для заказчика. Если проблемы окажутсянеразрешимыми, то это свидетельствует о том, что от заказа придетсяотказываться, и чем раньше выяснятся подобные обстоятельства, тем менееболезненным будет разрыв отношений со всех точек зрения.
Вообщеговоря, работа над планом выпуска релизов — это отбор вариантов на основеанализа наиболее общих требований, учитывающая, что из того, что хочетсяполучить заказчику, можно сделать наиболее скоро. Но без детализации требованийзачастую невозможно отдать предпочтение тому или иному варианту. Поэтому планвыпуска релизов должен быть открыт для включения альтернативных вариантов,которые отсеиваются при детализации на основе опыта развития проекта.Целесообразно производить ревизию плана релизов после завершения работ каждойитерации, т.е. на ее этапе оценки. В это время производятся комплексныеизмерения проекта, которые уточняют предварительную оценку продуктивностивыполнения работ и полезности получаемых рабочих продуктов. Полученнаяинформация позволяет корректировать план релизов и сделать его болеереалистичным. Новая версия плана утверждается после появления очередногорелиза.
Припервоначальном составлении плана релизов не стоит стараться слишкомдетализировать его этапы, если нет четких критериев, когда должен окончитьсяодин этап и начаться другой. Вместо этого проект просто разбивается на6-8-недельные итерации каждого релиза, исходя из возможностей реализации требуемыхфункций. Вопрос о том, какие функции, к какой итерации должны быть отнесены,решается на основе принципа: ближе к началу проекта относят, в первую очередь,наиболее приоритетные функции, во вторую очередь более простые для реализациифункции. Последнее делается с целью оставить разработчикам время для болееполного изучения предметной области в ходе подготовки первого релиза, а такжедля решения организационных вопросов.
Чтобыизбежать сбоев нарушения плана выпуска релизов при выполнении итерации, неследует завершать работу с этим планом в ходе конструирования. Если становитсяясно, что по тем или иным причинам рабочие продукты, запланированные к выпускуна данной итерации, не могут быть сделаны вовремя, рекомендуетсявоспользоваться следующими приемами корректировки плана:
·                  разбиениеэтапа — выделение в нем той части, которая может быть выполнена на даннойитерации, и перенесение остального на другие итерации. Это делается, когдатрудности возникают с реализацией высокоуровневых требований, от которых многоезависит;
·                  сдвигработ — перенос запаздывающего рабочего продукта на следующую итерацию ссохранением даты окончания итерации. Этот прием применяется для требований снизким приоритетом, а также на ранних итерациях, разгрузка которых позволяетпотратить освобождающееся у разработчиков время на дополнительное изучениепредметной области;
·                  перераспределениеработ — ускорение работ за счет привлечения к проекту дополнительных ресурсов(как правило, кадровых) с сохранением даты окончания итерации изапланированного объема работ. Этот прием можно применять для рабочихпродуктов, которые поддаются декомпозиции на части, допускающие раздельноевыполнение. Разумеется, он лишен смысла, если менеджер не располагаетрезервными ресурсами.
2.1.6    Ожидаемыериски на этапах жизненного цикла и их описание
Рискприменительно к программным проектам — это любая причина, по которой развитиепроекта может быть прервано. Конечно, это неформальное определение, оно толькообозначает возможность ситуаций, когда проект может быть прерван вопрекижеланию менеджера продолжать проект. Ситуации, когда проект прекращается дляменеджера, но, возможно, продолжается с другим менеджером или завершается всвязи с причинами, на которые нельзя повлиять, здесь не рассматриваются,поскольку разумная целевая установка менеджера — преодоление рискованнойситуации с минимальными потерями и продолжение проекта. В соответствии с этойустановкой менеджер должен еще до начала основных работ проанализировать, из-зачего данный проект может быть сорван, и понять, как он и его фирма могут идолжны поступать, чтобы исключить, или хотя бы минимизировать риски. Вчастности, результатом такого анализа может стать отказ от проекта. С другойстороны, риск невыполнения проекта является одной из причин, из-за которыхзаказ на разработку может быть не получен.
Причинывозможного срыва работ весьма разнообразны, они зависят от конкретных условий ине сводятся лишь к техническим аспектам. Разработчики должны учитывать такиеособенности ведения проекта, как техническая политика руководства фирмы изаказчика, их компетентность, их расчет на удачу, с одной стороны, а с другой —кредитоспособность, репутацию тех, кто предлагает заказ. Риск невыполненияпроекта может быть связан и с изменением рыночной конъюнктуры. Наконец, естьчисто внутренние причины рисков: сбои в используемом окружении (программном итехническом), неточность предъявляемых требований, ненадежность подрядчиков идр. и, возможно, кадров (нельзя исключать, что принятый на ключевую рольработник откажется от контракта в самый неподходящий момент).
Чтобыснизить влияние рисков на развитие проекта, менеджер должен разработатьспециальный план, называемый далее планом управления рисками. Содержание этогоплана — идентификация рисков для данного проекта и мероприятия, снижающиезависимость проекта от рисков.
Преодолениерисков может осуществляться на нескольких уровнях:
Исключениериска. Некоторые рискованные ситуации могут быть исключены полностью. Например,чтобы увольнение работника с ключевой ролью не очень сказалось на продолженииразвития проекта, целесообразно с самого начала предложить для занятия этойроли двух человек сравнимой квалификации. В начале проекта их дискуссии полезныдля выработки объективных решений, а если один из них откажется от контракта,второй все еще сможет продолжать дело. Полезные дискуссии — эта та жертва,которая в ряде случаев возможна для исключения риска. К сожалению, дублированиене может быть рекомендовано для исключения всех рискованных ситуаций.
Частныйслучай исключения риска — переключение его с проекта на окружение. К примеру,если рыночная ценность создаваемого изделия кажется сомнительной, для егоразработки комфортнее договориться с заказчиком об авансовых платежах, темсамым, заставив его самого решать задачу преодоления риска и освободив от этогоразработчиков (возможно, за счет снижения оплаты проекта). К сожалению, этастратегия является исключением риска только для разработчиков, но не дляпроекта в целом.
Уменьшениериска. Если риск не может быть исключен, можно постараться уменьшить егопоявление на практике. Продолжая пример с увольнением работника, для снижениявероятности этого следует предугадать причины поступка и постараться создатьдля работника более комфортные условия (повысить заработную плату, создатьльготы и т.п.). Нужно, чтобы подобные решения делались не в ответ на заявлениеоб увольнении, а заранее. Это сохранит определенную стабильность в коллективе,которая сама по себе является методом уменьшения риска.
Другойпример уменьшения риска — объявление (для заказчика, руководства и коллектива)о пересмотре требований, когда становится понятным, что график выполнения работможет быть сорван. Как и в предыдущем случае, важным моментом здесь являетсяупреждение, т.е. пересмотр требований не в ответ на нарушение графика, а вкачестве превентивной меры.
Предупреждениеущерба от риска. Когда не получается удовлетворительно уменьшить риск, следуетподготовиться к встрече неприятности так, чтобы минимизировать потери. Если этоудается, то продолжение проекта во многих случаях оказывается успешным. Впримере с увольнением следует как можно скорее найти замену данному работнику.Естественно, время выполнения проекта увеличится (в частности, потому чтоновому работнику придется входить в курс дела), но работа все-таки будетпродолжена. Это так, но при одном условии: на всех уровнях проектированиязаложена возможность отчуждения результатов труда от разработчиков. Еслирезультаты персонифицированы, то трудности подмены для некоторых ролей могутоказаться непреодолимыми.
Примеровподобного контроля из области техники можно привести множество (бамперы идворники автомашин, плавкие предохранители, дублирующие и сети т.д.). Впрактике конструирования программного обеспечения для предупрежденияпоследствий риска используются строго регламентированные технологические приемыи методы разработки.
Планированиедействий в непредвиденных ситуациях. Если шаги, направленные на предупреждениеущерба планируются для данного проекта, их выполнение должно быть проведено какможно быстрее. План действий в непредвиденных ситуациях обеспечивает исключениепрепятствий на этом пути. Так, чтобы произвести скорейшую замену уволенногоработника, у менеджера должен быть заранее готов список лиц, способных занятьосвобождающуюся вакансию. Составной частью этого плана является резервированиев основном графике работ времени, необходимого для вхождения в курс дела новогоисполнителя.
Примерамипланирования действий в непредвиденных ситуациях из области техники могутслужить запасные детали, а в практике конструирования программного обеспечения— средства отката и архивирования.
Длявсех рискованных ситуаций планом управления рисками предусматриваютсямероприятия на указанных уровнях в различной комбинации, возможно, дополненныеболее тонкой реакцией на возникновение риска. Детализация такого плана можетбыть различной, она зависит от ответственности проекта, его важности длякомпании и заказчика, с одной стороны, а с другой — от степени новизны проекта,и от наработки технологии его выполнения.
 Оченьважно, чтобы исполнители проекта были осведомлены о возможных рисках и о планеуправления ими. Это создает уверенность в успехе и подготавливает работников кпреодолению трудностей. Для менеджера при составлении плана самое важное — неупустить все возможные рискованные ситуации.
Проектс большой долей новаций является рискованным предприятием всегда. По этойпричине для него план управления рисками является обязательным и должен бытьмаксимально детализированным в части учета неверных решений, ошибок в оценкеситуаций и т.п.
Многиепроекты зависят от окружающих факторов в большей мере, чем от организации дел иподготовленности исполнителей. Анализ рисков в такой ситуации имеет цельюкомпенсации внешней зависимости за счет внутренних ресурсов. И здесь плануправления рисками обязателен при подготовке к проекту, но по сравнению спредыдущим случаем в нем несколько смещаются акценты. Так, менеджер должен предусмотретьдействия разработчиков, когда оборудование или внешнее программное обеспечениепоставляются с задержкой, когда возникают сбои в финансировании, в иных случаяхотрицательного внешнего влияния.
Посравнению с традиционным последовательным развитием ориентация проекта наитеративное развитие делает его более устойчивым к рискам, поскольку рабочийпродукт каждой итерации планируется не тогда, когда контекст его разработкипредсказать можно лишь в общих чертах, а когда он полностью определен. Тем не менее,план управления рисками уместен и здесь. По-видимому, при итеративном развитиинаиболее важным для него является распределение реализуемых в проектетребований по итерациям так, чтобы минимизировался риск проекта в целом.
Составлениеплана управления рисками — это необходимая часть подготовки к началу проектахотя бы по той причине, что он влияет на распределение ресурсов. Она начинаетсяс фиксации и ранжирования всех возможных рискованных ситуаций и планируемыхреакций на них. Кроме того, определяются временные издержки и цена мероприятий,которые планируется выполнять, когда риски проявляют себя. Таким образом, плануправления рисками представляет собой перечень рисковых ситуаций с планируемымиреакциями на них, временными издержками и затратами на их проведение. Этисведения дополняют затратные характеристики проекта и его план-график, темсамым, расширяя схему финансовых и временных потребностей проекта.
Каки в других случаях, при планировании управления рисками детально расписываютсярисковые ситуации начала проекта, в том числе, для первой итерации. Грубыеоценки рисков последующих периодов корректируются перед каждой очереднойитерацией. Другое время, когда целесообразно пересмотреть план управлениярисками, — после возникновения рискованной ситуации и ее преодоления. Вкачестве примера того, что должно быть предусмотрено, можно указать наперераспределение ресурсов, первоначально выделенных на поддержку мероприятий врисковых ситуациях.
Полезноперед корректировкой планов управления рисками в случае возникновения ипреодоления рискованной ситуации провести анализ ситуации. Требуется оценитьэффективность предусмотренных, выполненных и невыполненных мероприятий, понять,что могло бы быть лучше организовано, проверить качество предварительных оценок.Опыт, полученный при таком анализе, применяется непосредственно: при пересмотреплана. Это весьма важно, поскольку ситуации, подобные той, которая преодолена,вполне вероятно могут повториться в ходе дальнейшего развития проекта.
Нижеприводится перечень (далеко неполный) ситуаций, которых должен избегатьменеджер, и которые он должен учитывать, составляя план управления рисками:
·                  задержканачала проекта никогда не компенсируется;
·                  еслисетевой график выполняется с большими нарушениями сроков, трудно ожидатьсоздание хорошего продукта;
·                  еслипользовательский интерфейс не является интуитивно понятным и превышает уровенькомпетенции потребителя изделия, продукт будет плохо распространяться;
·                  упущенныевозможности требуют дополнительных усилий при их более поздней реализации иувеличивают затраты;
·                  непротестированный продукт снижает репутацию разработчиков;
·                  нестоит рассчитывать на постоянство пользовательских намерений, никогда нельзязнать, что хочется пользователю и чего на самом деле ему нужно. Как следствие,необходимо планировать время на переделку того, что в начале проекта казалосьприемлемым.
2.1.7    Оценкастоимостных параметров проекта автоматизации
Приопределении финансовых потребностей показатели, задаваемые в ходе выяснениятехнических и кадровых ресурсов, переводятся в денежное выражение. Для каждогоиз таких показателей должны быть известны нормативы перевода. Это либостандартизованные (внешние и внутрифирменные) коэффициенты, либо просто ценыиспользуемых в проекте билетов и услуг. Если по каким-либо причинам точныхнормативов перевода нет, то вместо них применяются экспертные оценки. Например,при приглашении для участия в проекте конкретного специалиста может оказаться,что требования его заработной платы не соответствуют квалификационной сеткеставок, принятой в компании. Для такого сотрудника приходится вводитьиндивидуальный норматив перевода почасовой занятости в денежное выражение.
Ценына билеты и услуги также могут варьироваться. В этой связи использование их какнормативов перевода означает не точное определение финансовых потребностей,связанных с приобретением данного билета или с получением услуги, а указаниенижней и верхней границ требуемых денежных средств. В практике оценкифинансовых ресурсов для программных проектов применяются расчеты следующихвидов:
·                  поминимальной границе цен,
·                  помаксимальной границе цен,
·                  посредней величине между максимальной и минимальной ценой или
·                  посредневзвешенной величине.
Последнийвариант используется для более точного вычисления, когда удается оценитьраспределение вероятности приобретения билета или услуги в зависимости отуровня цен.
Составляяминимальную и рациональную схемы распределения потребностей, не следуетполагать, что в минимальной схеме затратные характеристики обязательно должныстроиться исходя из минимальных цен (хотя и это возможно). Понятие минимальнойсхемы отражает, прежде всего, результативный аспект рассмотрения заказа, т.е.то, какие минимально необходимые результаты предполагается получить, а сфинансовыми расходами оно связано уже во вторую очередь. Полезно дляминимальной и для рациональной схем определять как верхнюю, так и нижнююграницы финансовых потребностей проекта.
Прииспользовании цен, как нормативов, нельзя путать вариантность стоимостиоднородной продукции у различных продавцов и ситуации, когда уровень ценыотражает уровень качество билета или услуги. К примеру, более совершенноевычислительное оборудование делает поставку дороже, чем при использованиибытовых аналогов, программная система может работать как в облегченной, так и вполной конфигурации оборудования. Все подобные качественные вариации проектаследует отмечать в документах, отражая их влияние на объем, качестворезультатов, и сроки разработки.
Финансовыепотребности проекта рассчитываются по-разному для краткосрочных и долгосрочныхпроектов. Это связано с тем, что для длительных проектов начинает играть рольинфляционный фактор, и, как следствие, приходится учитывать дисконтирование.Иными словами, обсуждая проектные решения, необходимо оперироватьсяинформацией, выраженной в сопоставимых ценах.
Приведениепоздних затрат к ценам начального периода развития проекта осуществляется путемвведения поправочного коэффициента дисконтирования:
Д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 T11 Специальные требования к безопасности 1 4 4 T12 Непосредственный доступ к|до| системе со стороны внешних пользователей 1 5 5 T13 Специальные требования к обучению пользователей 1 Сумма 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)               абсолютноеснижение трудовых затрат (DТ) в часах за год:
DТ= Т0 — Т1
где,
Т0- трудовые затраты в часах за год на обработку информации по базовому варианту;
Т1- трудовые затраты в часах за год на обработку информации по предлагаемомуварианту;
2)               коэффициентотносительного снижения трудовых затрат (КТ):
КТ=DТ/ T0 * 100%
3)               индексснижения трудовых затрат или повышение производительности труда (YT):
YT= T0 / T1
Кстоимостным показателям относятся: абсолютное снижение стоимостных затрат (DC)в рублях за год, коэффициент относительного снижения стоимостных затрат (КC)индекс снижения стоимостных затрат (YC), рассчитываемые аналогично.
3.2Расчёт показателей экономической эффективности проекта
Длякоммерческих программных продуктов оценка величины доходов от вложенных вразработку средств строится на основе ряда предположений о проекте, которыескладываются исходя из анализа предполагаемых ситуаций использования (BusinessCases) проектируемого изделия. Например, такой анализ может показать, чтоотдача от вложенных в разработку средств будет пятикратной, если разработказавершится за год, двукратной при двухгодичной разработке и окажетсяотрицательной при более длительных сроках выполнения проекта.
Другойаспект оценки вероятных доходов от реализации проекта — это подсчет затрат наразработку и их разнесение на продукцию при тиражировании. Иными словами,исходя из финансовой потребности самого проекта, определяется, какая стоимостьпродукта может обеспечить компенсацию затрат. Важным моментом здесь являетсяразграничение проплат, которые обязуется сделать заказчик, и расходов,обеспечение которых берет на себя фирма. В соответствии с этой пропорциейраспределяется и будущий доход от реализации.
Соглашениео разделе продукции является одной из составляющих договора между заказчиком иразработчиками. В принципе, это соглашение может стать одним из критериев прирешении вопроса о размещении заказа. Варианты распределения будущего доходамогут быть различными: от соглашения о прямом и полном финансировании и,соответственно, получения всего дохода заказчиком до таких случаев, когдавнешний заказчик отсутствует и фирма выполняет проект исключительно дляпродажи.
Предположенияо доходах от реализации проекта делаются на базе составления сметы проекта, содной стороны, а с другой — исходят из прогноза финансовой и рыночной ситуации(какой сектор рынка может занять разрабатываемое изделие, какие цены на негоцелесообразно установить и т.д.). Они формулируются в ходе предпроектнойдеятельности, а затем проверяются при выполнении фазы оценки (после прохожденияконтрольной точки 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
Устанавливаемцену проекта — 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.       Рольи задачи МИС в маркетинге организации eup.ru/

Приложение1. Программныйкод
TECHNICAL FILE INFORMATION:
File Type Description :Portable Executable (PE)
FILE CHARACTERISTICS:
File is executable (i.e. no unresolved externalreferences)
COFF line numbers have been removed
COFF symbol table entries for local symbols havebeen 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 GUIsubsystem)
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
 0 VariantChangeTypeEx
 0 VariantCopyInd
 0 VariantCopy
 0 VariantClear
 0 VariantInit
 ole32.dll
Import Lookup Table RVA: 00000000h (Unbound IAT)
TimeDateStamp: 00000000h
ForwarderChain: 00000000h
DLL Name RVA: 001186F6h
Import Address Table RVA: 00116880h
First thunk RVA: 00116880h
Ordn Name
----------
 0 CreateStreamOnHGlobal
 0 IsAccelerator
 0 OleDraw
 0 OleSetMenuDescriptor
 0 CoCreateInstance
 0 CoGetClassObject
 0 CoUninitialize
 0 CoInitialize
 0 IsEqualGUID
 oleaut32.dll
Import Lookup Table RVA: 00000000h (Unbound IAT)
TimeDateStamp: 00000000h
ForwarderChain: 00000000h
DLL Name RVA: 001187A2h
Import Address Table RVA: 001168A8h
First thunk RVA: 001168A8h
Ordn Name
----------
 0 GetErrorInfo
 0 SysFreeString
 comctl32.dll
Import Lookup Table RVA: 00000000h (Unbound IAT)
TimeDateStamp: 00000000h
ForwarderChain: 00000000h
DLL Name RVA: 001187D0h
Import Address Table RVA: 001168B4h
First thunk RVA: 001168B4h
Ordn Name
----------
 0 ImageList_SetIconSize
 0 ImageList_GetIconSize
 0 ImageList_Write
 0 ImageList_Read
 0 ImageList_GetDragImage
 0 ImageList_DragShowNolock
 0 ImageList_SetDragCursorImage
 0 ImageList_DragMove
 0 ImageList_DragLeave
 0 ImageList_DragEnter
 0 ImageList_EndDrag
 0 ImageList_BeginDrag
 0 ImageList_Remove
 0 ImageList_DrawEx
 0 ImageList_Replace
 0 ImageList_Draw
 0 ImageList_GetBkColor
 0 ImageList_SetBkColor
 0 ImageList_ReplaceIcon
 0 ImageList_Add
 0 ImageList_GetImageCount
 0 ImageList_Destroy
 0 ImageList_Create
 0 InitCommonControls
 winspool.drv
Import Lookup Table RVA: 00000000h (Unbound IAT)
TimeDateStamp: 00000000h
ForwarderChain: 00000000h
DLL Name RVA: 001189F2h
Import Address Table RVA: 00116918h
First thunk RVA: 00116918h
Ordn Name
----------
 0 OpenPrinterA
 0 GetPrinterDriverA
 0 EnumPrintersA
 0 DocumentPropertiesA
 0 DeviceCapabilitiesA
 0 ClosePrinter
 comdlg32.dll
Import Lookup Table RVA: 00000000h (Unbound IAT)
TimeDateStamp: 00000000h
ForwarderChain: 00000000h
DLL Name RVA: 00118A70h
Import Address Table RVA: 00116934h
First thunk RVA: 00116934h
Ordn Name
----------
 0 PrintDlgA
 0 ChooseFontA
 0 GetSaveFileNameA
 0 GetOpenFileNameA
 kernel32.dll
Import Lookup Table RVA: 00000000h (Unbound IAT)
TimeDateStamp: 00000000h
ForwarderChain: 00000000h
DLL Name RVA: 00118AC0h
Import Address Table RVA: 00116948h
First thunk RVA: 00116948h
Ordn Name
----------
 0 MulDiv
DOS HEADER
Header Information :
Signature :5A4Dh
Bytes on last page of file :0050h
Total Pages in File :0002h
Relocation Items :0000h
Size of header in paragraphs :0004h
Minimum Extra Paragraphs :000Fh
Maximum Extra Paragraphs :FFFFh
Initial Stack Segment :0000h
Initial Stack Pointer :00B8h
Complemented Checksum :0000h
Initial Instruction Pointer :0000h
Initial Code Segment :0000h
Relocation Table Offset :0040h
Overlay Number :001Ah
Extra Header Information :
Reserved WORD 0:0000h
Reserved WORD 1:0000h
Reserved WORD 2:0000h
Reserved WORD 3:0000h
OEM identifier :0000h
OEM information :0000h
Reserved WORD 0:0000h
Reserved WORD 1:0000h
Reserved WORD 2:0000h
Reserved WORD 3:0000h
Reserved WORD 4:0000h
Reserved WORD 5:0000h
Reserved WORD 6:0000h
Reserved WORD 7:0000h
Reserved WORD 8:0000h
Reserved WORD 9:0000h
New Header Address :00000100h
Memory Needed :1104 B ( 1 KB )