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

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

Введение

В условиях перехода общественного развития в информационную эпоху, становится возможным создание электронной экономики, для которой характерны немного другие правила развития, по сравнению с классической экономикой. Развитие этого вида экономики напрямую зависит от развития всемирной сети 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.

Количественно-стоимостные оценки

1.1.2 Организационная структура управления предприятием

Компания ООО «Зритель» структурно состоит из пяти отделов, представленных на рис. 1.3.

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

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

Код подсистемы - 08.

Показатели носят натуральный и стоимостный характер.

Основные задачи, которые решаются в подсистеме, приведены в табл. 1.2.

Таблица 1.2.

Характеристика задач

Задача 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. Выбрав платежное средство, клиенту следует нажать на кнопку «Продолжить».

Для того, чтобы оплатить заказ, клиент заполняет необходимые поля: тип карты (VISA International, 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 in Electronic 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.

Характеристика задач, которые разрешаются на сервере

1.3.3 Выбор и обоснование способа приобретения ИС для автоматизации задачи

Из-за того, что Internet-технологии в своем большинстве являются открытыми технологиями, для разработки самих дополнений можно использовать любой текстовый редактор. Но для разработки дополнений данной квалификационной работы использовался профессиональный пакет разработки Web-страниц Macromedia Dreamweaver MX, который соединяет в себе скорость визуальной разработки сайтов и точность ручной разработки. Кроме того этот пакет поддерживает разработку PHP-скриптов.

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

Для хранения и выборки данных используется СУБД Interbase компании Borland Software Corporation. Она зарекомендовала себя как легкая СУБД с достаточно высокими скоростными показателями и малой потребностью системных ресурсов. Кроме того, по сравнению со стандартной для решения задач данного типа СУБД MySQL, СУБД Interbase имеет достаточные функциональные возможности для последующей интеграции в подсистемы торговой организации. Это, прежде всего, объясняется поддержкой триггеров, процедур, которые сохраняются на сервере, и представлений.

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

Для разметки Web-страниц использовался язык гипертекстовой разметки HTML (HyperText Markup 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 Обоснование проектных решений по информационному обеспечению

Для разработки модели автоматизации использовалось следующее информационное обеспечение:

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

Computer Associates 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 Software Corporation. Она зарекомендовала себя как легкая СУБД с достаточно высокими скоростными показателями и малой потребностью системных ресурсов. Кроме того, по сравнению со стандартной для решения задач данного типа СУБД MySQL, СУБД Interbase имеет достаточные функциональные возможности для последующей интеграции в подсистемы торговой организации. Это, прежде всего, объясняется поддержкой триггеров, процедур, которые сохраняются на сервере, и представлений.

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

Для разметки Web-страниц использовался язык гипертекстовой разметки HTML (HyperText Markup 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. В них указываются календарные даты планируемого (столбец 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.

Характеристика структурных единиц информации исходных сообщений

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.

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

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

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

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

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

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

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

Формула 2.1.

,

где,

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

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

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

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

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

Формула 2.2.

,

где,

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

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

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

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

Таблица 2.4.

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

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

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

Таблица 2.5.

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

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

Таблица 2.6.

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

Таблица 2.7.

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

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

Таблица 2.8.

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

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

Таблица 2.9.

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

Безусловно, этот расчет является приблизительным. Это объясняется наличием в БД метаданных. Кроме того, размер БД для СУБД 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.

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

Значение 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 Расчёт показателей экономической эффективности проекта

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

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

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

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

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

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

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

KLOC = 4413

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

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

где,

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

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

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

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

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

где,

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

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

Таблица 3.1.

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

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

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

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

где,

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

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

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

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

Стп = Дл * ЗПМ

где,

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

Стп = 1,88 * 1500 = 2820

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

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

КГИ = IKLOC / KLOC

где,

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

К = 2, IKLOC = 200

КГИ = 200 / 4413 = 0,045

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

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

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

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

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

где,

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

П = 8000

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

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

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

где,

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

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

где,

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

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

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

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

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

См/год = 4,2

Ткоп = 0,2

См = 10

Змес = 1500

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

СА = 0,03 * Стп

Тогда,

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

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

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

126,104 < Ц < 11073,8

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

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

где,

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

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

t - год;

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

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

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

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

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

где,

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

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

А = 0,25 * СТВТ

Ток = 0,505

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

где,

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

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

Ткр = 0,704

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

где,

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

К эб = 468,18%

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

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

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

Заключение

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

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

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

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

Литература

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

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

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

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

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

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

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

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

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

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

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

TECHNICAL FILE INFORMATION :

File Type Description :Portable Executable (PE)

FILE CHARACTERISTICS :

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

COFF line numbers have been removed

COFF symbol table entries for local symbols have been removed

Little endian: LSB precedes MSB in memory

Machine based on 32-bit-word architecture

Big endian: MSB precedes LSB in memory

FILE HEADER :

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

Number of Sections: 0008h

Time Date Stamp: 2A425E19h

Symbols Pointer: 00000000h

Number Of Symbols: 00000000h

Size Of Optional Header: 00E0h

Flags: 818Eh

OPTIONAL HEADER :

Magic 010Bh ( PE32 : normal 32-bit )

Linker version 2.25

Size of code 0010EA00h

Size of initialized data 0005CE00h

Size of uninitialized data 00000000h

Address of Entry Point (RVA) 0010F780h

Base of code 00001000h

Base of data 00110000h

Image base 00400000h

Section Alignment 00001000h

File Alignment 00000200h

Required OS version 4.00

Image version 0.00

Subsystem version 4.00

Reserved1 0

Size of image 00172000h ( 1515520 bytes)

Size of headers 00000400h

Checksum 00000000h

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

DLL Characteristics 0000h

Size of Stack Reserve 00100000h

Size of Stack Commit 00004000h

Size of Heap Reserve 00100000h

Size of Heap Commit 00001000h

loader flags 00000000h (obsolete)

Number of Data Directory 00000010h

DATA DIRECTORY (Virtual Address and Size)

Export Directory rva: 00000000h size: 00000000h

Import Directory rva: 00116000h size: 00002AD8h

Resource Directory rva: 00131000h size: 00040A00h

Exception table rva: 00000000h size: 00000000h

Security table rva: 00000000h size: 00000000h

Base Relocation table rva: 0011B000h size: 00015F10h

Debug Directory rva: 00000000h size: 00000000h

Architecture Specific Data rva: 00000000h size: 00000000h

Global Pointer rva: 00000000h size: 00000000h

TLS Directory rva: 0011A000h size: 00000018h

Load config table rva: 00000000h size: 00000000h

Bound Import table rva: 00000000h size: 00000000h

Import Address Table rva: 00000000h size: 00000000h

Delay import descriptor rva: 00000000h size: 00000000h

COM descriptor rva: 00000000h size: 00000000h

unused rva: 00000000h size: 00000000h

SECTION TABLE

01 CODE

VirtSize: 0010E820h VirtAddr: 00001000h

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

relocation offs: 00000000h relocations: 00000000h

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

characteristics: 60000020h

CODE EXECUTE READ ALIGN_DEFAULT(16)

02 DATA

VirtSize: 00003454h VirtAddr: 00110000h

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

relocation offs: 00000000h relocations: 00000000h

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

characteristics: C0000040h

INITIALIZED_DATA READ WRITE ALIGN_DEFAULT(16)

03 BSS

VirtSize: 00001279h VirtAddr: 00114000h

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

relocation offs: 00000000h relocations: 00000000h

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

characteristics: C0000000h

READ WRITE ALIGN_DEFAULT(16)

04 .idata

VirtSize: 00002AD8h VirtAddr: 00116000h

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

relocation offs: 00000000h relocations: 00000000h

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

characteristics: C0000040h

INITIALIZED_DATA READ WRITE ALIGN_DEFAULT(16)

05 .tls

VirtSize: 00000060h VirtAddr: 00119000h

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

relocation offs: 00000000h relocations: 00000000h

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

characteristics: C0000000h

READ WRITE ALIGN_DEFAULT(16)

06 .rdata

VirtSize: 00000018h VirtAddr: 0011A000h

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

relocation offs: 00000000h relocations: 00000000h

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

characteristics: 50000040h

INITIALIZED_DATA SHARED READ ALIGN_DEFAULT(16)

07 .reloc

VirtSize: 00015F10h VirtAddr: 0011B000h

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

relocation offs: 00000000h relocations: 00000000h

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

characteristics: 50000040h

INITIALIZED_DATA SHARED READ ALIGN_DEFAULT(16)

08 .rsrc

VirtSize: 00040A00h VirtAddr: 00131000h

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

relocation offs: 00000000h relocations: 00000000h

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

characteristics: 50000040h

INITIALIZED_DATA SHARED READ ALIGN_DEFAULT(16)

IMPORTS TABLE:

kernel32.dll

Import Lookup Table RVA: 00000000h (Unbound IAT)

TimeDateStamp: 00000000h

ForwarderChain: 00000000h

DLL Name RVA: 00116950h

Import Address Table RVA: 0011617Ch

First thunk RVA: 0011617Ch

Ordn Name

----------

0 DeleteCriticalSection

0 LeaveCriticalSection

0 EnterCriticalSection

0 InitializeCriticalSection

0 VirtualFree

0 VirtualAlloc

0 LocalFree

0 LocalAlloc

0 GetCurrentThreadId

0 InterlockedDecrement

0 InterlockedIncrement

0 VirtualQuery

0 WideCharToMultiByte

0 MultiByteToWideChar

0 lstrlenA

0 lstrcpynA

0 LoadLibraryExA

0 GetThreadLocale

0 GetStartupInfoA

0 GetProcAddress

0 GetModuleHandleA

0 GetModuleFileNameA

0 GetLocaleInfoA

0 GetLastError

0 GetCommandLineA

0 FreeLibrary

0 FindFirstFileA

0 FindClose

0 ExitProcess

0 ExitThread

0 CreateThread

0 WriteFile

0 UnhandledExceptionFilter

0 SetFilePointer

0 SetEndOfFile

0 RtlUnwind

0 ReadFile

0 RaiseException

0 GetStdHandle

0 GetFileSize

0 GetFileType

0 CreateFileA

0 CloseHandle

user32.dll

Import Lookup Table RVA: 00000000h (Unbound IAT)

TimeDateStamp: 00000000h

ForwarderChain: 00000000h

DLL Name RVA: 00116C4Eh

Import Address Table RVA: 0011622Ch

First thunk RVA: 0011622Ch

Ordn Name

----------

0 GetKeyboardType

0 LoadStringA

0 MessageBoxA

0 CharNextA

advapi32.dll

Import Lookup Table RVA: 00000000h (Unbound IAT)

TimeDateStamp: 00000000h

ForwarderChain: 00000000h

DLL Name RVA: 00116C94h

Import Address Table RVA: 00116240h

First thunk RVA: 00116240h

Ordn Name

----------

0 RegQueryValueExA

0 RegOpenKeyExA

0 RegCloseKey

oleaut32.dll

Import Lookup Table RVA: 00000000h (Unbound IAT)

TimeDateStamp: 00000000h

ForwarderChain: 00000000h

DLL Name RVA: 00116CD4h

Import Address Table RVA: 00116250h

First thunk RVA: 00116250h

Ordn Name

----------

0 SysFreeString

0 SysReAllocStringLen

0 SysAllocStringLen

kernel32.dll

Import Lookup Table RVA: 00000000h (Unbound IAT)

TimeDateStamp: 00000000h

ForwarderChain: 00000000h

DLL Name RVA: 00116D1Ch

Import Address Table RVA: 00116260h

First thunk RVA: 00116260h

Ordn Name

----------

0 TlsSetValue

0 TlsGetValue

0 LocalAlloc

0 GetModuleHandleA

advapi32.dll

Import Lookup Table RVA: 00000000h (Unbound IAT)

TimeDateStamp: 00000000h

ForwarderChain: 00000000h

DLL Name RVA: 00116D68h

Import Address Table RVA: 00116274h

First thunk RVA: 00116274h

Ordn Name

----------

0 SetSecurityDescriptorDacl

0 RegQueryValueExA

0 RegOpenKeyExA

0 RegCloseKey

0 InitializeSecurityDescriptor

kernel32.dll

Import Lookup Table RVA: 00000000h (Unbound IAT)

TimeDateStamp: 00000000h

ForwarderChain: 00000000h

DLL Name RVA: 00116DE4h

Import Address Table RVA: 0011628Ch

First thunk RVA: 0011628Ch

Ordn Name

----------

0 lstrcpyA

0 WriteFile

0 WaitForSingleObject

0 VirtualQuery

0 VirtualAlloc

0 UnmapViewOfFile

0 Sleep

0 SizeofResource

0 SetThreadLocale

0 SetFilePointer

0 SetEvent

0 SetErrorMode

0 SetEndOfFile

0 SearchPathA

0 ResumeThread

0 ResetEvent

0 ReleaseMutex

0 ReadFile

0 OpenMutexA

0 OpenFileMappingA

0 OpenEventA

0 MultiByteToWideChar

0 MulDiv

0 MapViewOfFile

0 LockResource

0 LoadResource

0 LoadLibraryA

0 LeaveCriticalSection

0 IsDBCSLeadByte

0 InitializeCriticalSection

0 GlobalUnlock

0 GlobalSize

0 GlobalReAlloc

0 GlobalHandle

0 GlobalLock

0 GlobalFree

0 GlobalFindAtomA

0 GlobalDeleteAtom

0 GlobalAlloc

0 GlobalAddAtomA

0 GetVersionExA

0 GetVersion

0 GetUserDefaultLCID

0 GetTickCount

0 GetThreadLocale

0 GetTempPathA

0 GetTempFileNameA

0 GetSystemInfo

0 GetSystemDefaultLCID

0 GetStringTypeExA

0 GetStdHandle

0 GetProfileStringA

0 GetProcAddress

0 GetModuleHandleA

0 GetModuleFileNameA

0 GetLocaleInfoA

0 GetLocalTime

0 GetLastError

0 GetExitCodeThread

0 GetDiskFreeSpaceA

0 GetDateFormatA

0 GetCurrentThreadId

0 GetCurrentProcessId

0 GetCurrentDirectoryA

0 GetCPInfo

0 GetACP

0 FreeResource

0 InterlockedIncrement

0 InterlockedDecrement

0 FreeLibrary

0 FormatMessageA

0 FindResourceA

0 FindFirstFileA

0 FindClose

0 FileTimeToLocalFileTime

0 FileTimeToDosDateTime

0 FatalAppExitA

0 EnumCalendarInfoA

0 EnterCriticalSection

0 DeleteFileA

0 DeleteCriticalSection

0 CreateThread

0 CreateMutexA

0 CreateFileMappingA

0 CreateFileA

0 CreateEventA

0 CompareStringA

0 CloseHandle

version.dll

Import Lookup Table RVA: 00000000h (Unbound IAT)

TimeDateStamp: 00000000h

ForwarderChain: 00000000h

DLL Name RVA: 001173ECh

Import Address Table RVA: 001163F0h

First thunk RVA: 001163F0h

Ordn Name

----------

0 VerQueryValueA

0 GetFileVersionInfoSizeA

0 GetFileVersionInfoA

gdi32.dll

Import Lookup Table RVA: 00000000h (Unbound IAT)

TimeDateStamp: 00000000h

ForwarderChain: 00000000h

DLL Name RVA: 0011743Ah

Import Address Table RVA: 00116400h

First thunk RVA: 00116400h

Ordn Name

----------

0 UnrealizeObject

0 StretchBlt

0 StartPage

0 StartDocA

0 SetWindowOrgEx

0 SetWindowExtEx

0 SetWinMetaFileBits

0 SetViewportOrgEx

0 SetViewportExtEx

0 SetTextColor

0 SetTextAlign

0 SetStretchBltMode

0 SetROP2

0 SetPixel

0 SetMapMode

0 SetEnhMetaFileBits

0 SetDIBColorTable

0 SetBrushOrgEx

0 SetBkMode

0 SetBkColor

0 SetAbortProc

0 SelectPalette

0 SelectObject

0 SelectClipRgn

0 SaveDC

0 RestoreDC

0 Rectangle

0 RectVisible

0 RealizePalette

0 Polyline

0 PolyPolyline

0 PlayEnhMetaFile

0 PatBlt

0 MoveToEx

0 MaskBlt

0 LineTo

0 LPtoDP

0 IntersectClipRect

0 GetWindowOrgEx

0 GetWinMetaFileBits

0 GetTextMetricsA

0 GetTextExtentPointA

0 GetTextExtentPoint32A

0 GetSystemPaletteEntries

0 GetStockObject

0 GetRgnBox

0 GetPixel

0 GetPaletteEntries

0 GetObjectA

0 GetNearestColor

0 GetEnhMetaFilePaletteEntries

0 GetEnhMetaFileHeader

0 GetEnhMetaFileDescriptionA

0 GetEnhMetaFileBits

0 GetDeviceCaps

0 GetDIBits

0 GetDIBColorTable

0 GetDCOrgEx

0 GetCurrentPositionEx

0 GetClipBox

0 GetBrushOrgEx

0 GetBitmapBits

0 ExtTextOutA

0 ExtCreatePen

0 ExcludeClipRect

0 EndPage

0 EndDoc

0 Ellipse

0 DeleteObject

0 DeleteEnhMetaFile

0 DeleteDC

0 CreateSolidBrush

0 CreateRectRgn

0 CreatePenIndirect

0 CreatePalette

0 CreateICA

0 CreateHalftonePalette

0 CreateFontIndirectA

0 CreateEnhMetaFileA

0 CreateDIBitmap

0 CreateDIBSection

0 CreateDCA

0 CreateCompatibleDC

0 CreateCompatibleBitmap

0 CreateBrushIndirect

0 CreateBitmap

0 CopyEnhMetaFileA

0 CombineRgn

0 CloseEnhMetaFile

0 BitBlt

0 AbortDoc

user32.dll

Import Lookup Table RVA: 00000000h (Unbound IAT)

TimeDateStamp: 00000000h

ForwarderChain: 00000000h

DLL Name RVA: 00117A3Ch

Import Address Table RVA: 00116570h

First thunk RVA: 00116570h

Ordn Name

----------

0 WindowFromPoint

0 WinHelpA

0 WaitMessage

0 ValidateRect

0 UpdateWindow

0 UnregisterClassA

0 UnionRect

0 UnhookWindowsHookEx

0 TranslateMessage

0 TranslateMDISysAccel

0 TrackPopupMenu

0 SystemParametersInfoA

0 ShowWindow

0 ShowScrollBar

0 ShowOwnedPopups

0 ShowCursor

0 SetWindowsHookExA

0 SetWindowTextA

0 SetWindowPos

0 SetWindowPlacement

0 SetWindowLongA

0 SetTimer

0 SetScrollRange

0 SetScrollPos

0 SetScrollInfo

0 SetRect

0 SetPropA

0 SetParent

0 SetMenuItemInfoA

0 SetMenu

0 SetKeyboardState

0 SetForegroundWindow

0 SetFocus

0 SetCursor

0 SetClipboardData

0 SetClassLongA

0 SetCapture

0 SetActiveWindow

0 SendMessageA

0 SendDlgItemMessageA

0 ScrollWindowEx

0 ScrollWindow

0 ScreenToClient

0 RemovePropA

0 RemoveMenu

0 ReleaseDC

0 ReleaseCapture

0 RegisterWindowMessageA

0 RegisterClipboardFormatA

0 RegisterClassA

0 RedrawWindow

0 PtInRect

0 PostQuitMessage

0 PostMessageA

0 PeekMessageA

0 OpenClipboard

0 OffsetRect

0 OemToCharBuffA

0 OemToCharA

0 MsgWaitForMultipleObjects

0 MessageBoxA

0 MessageBeep

0 MapWindowPoints

0 MapVirtualKeyA

0 LoadStringA

0 LoadKeyboardLayoutA

0 LoadIconA

0 LoadCursorA

0 LoadBitmapA

0 KillTimer

0 IsZoomed

0 IsWindowVisible

0 IsWindowEnabled

0 IsWindow

0 IsRectEmpty

0 IsIconic

0 IsDialogMessageA

0 IsChild

0 IsCharAlphaNumericA

0 IsCharAlphaA

0 InvalidateRect

0 IntersectRect

0 InsertMenuItemA

0 InsertMenuA

0 InflateRect

0 GetWindowThreadProcessId

0 GetWindowTextA

0 GetWindowRect

0 GetWindowPlacement

0 GetWindowLongA

0 GetWindowDC

0 GetTopWindow

0 GetSystemMetrics

0 GetSystemMenu

0 GetSysColor

0 GetSubMenu

0 GetScrollRange

0 GetScrollPos

0 GetScrollInfo

0 GetPropA

0 GetParent

0 GetWindow

0 GetMessageTime

0 GetMenuStringA

0 GetMenuState

0 GetMenuItemInfoA

0 GetMenuItemID

0 GetMenuItemCount

0 GetMenu

0 GetLastActivePopup

0 GetKeyboardState

0 GetKeyboardLayoutList

0 GetKeyboardLayout

0 GetKeyState

0 GetKeyNameTextA

0 GetIconInfo

0 GetForegroundWindow

0 GetFocus

0 GetDoubleClickTime

0 GetDlgItem

0 GetDesktopWindow

0 GetDCEx

0 GetDC

0 GetCursorPos

0 GetCursor

0 GetClipboardData

0 GetClientRect

0 GetClassNameA

0 GetClassInfoA

0 GetCaretPos

0 GetCapture

0 GetActiveWindow

0 FrameRect

0 FindWindowA

0 FillRect

0 EqualRect

0 EnumWindows

0 EnumThreadWindows

0 EnumClipboardFormats

0 EndPaint

0 EnableWindow

0 EnableScrollBar

0 EnableMenuItem

0 EmptyClipboard

0 DrawTextA

0 DrawMenuBar

0 DrawIconEx

0 DrawIcon

0 DrawFrameControl

0 DrawFocusRect

0 DrawEdge

0 DispatchMessageA

0 DestroyWindow

0 DestroyMenu

0 DestroyIcon

0 DestroyCursor

0 DeleteMenu

0 DefWindowProcA

0 DefMDIChildProcA

0 DefFrameProcA

0 CreateWindowExA

0 CreatePopupMenu

0 CreateMenu

0 CreateIcon

0 CloseClipboard

0 ClientToScreen

0 CheckMenuItem

0 CallWindowProcA

0 CallNextHookEx

0 BeginPaint

0 CharNextA

0 CharLowerBuffA

0 CharLowerA

0 CharUpperBuffA

0 CharToOemBuffA

0 CharToOemA

0 AdjustWindowRectEx

0 ActivateKeyboardLayout

kernel32.dll

Import Lookup Table RVA: 00000000h (Unbound IAT)

TimeDateStamp: 00000000h

ForwarderChain: 00000000h

DLL Name RVA: 001185BEh

Import Address Table RVA: 0011683Ch

First thunk RVA: 0011683Ch

Ordn Name

----------

0 Sleep

oleaut32.dll

Import Lookup Table RVA: 00000000h (Unbound IAT)

TimeDateStamp: 00000000h

ForwarderChain: 00000000h

DLL Name RVA: 001185D4h

Import Address Table RVA: 00116844h

First thunk RVA: 00116844h

Ordn Name

----------

0 SafeArrayPtrOfIndex

0 SafeArrayPutElement

0 SafeArrayGetElement

0 SafeArrayUnaccessData

0 SafeArrayAccessData

0 SafeArrayGetUBound

0 SafeArrayGetLBound

0 SafeArrayRedim

0 SafeArrayCreate

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 )