Проектирование АИС "Работа с абонентами оператора сотовой связи"
Изучение технологического процесса работы биллинговой компании. Инфраструктура предоставления услуг связи. Базовые бизнес-процессы. Цели и задачи проектируемой информационной системы "Работа с абонентами оператора сотовой связи". Этапы разработки проекта.
Рубрика | Программирование, компьютеры и кибернетика |
Вид | курсовая работа |
Язык | русский |
Дата добавления | 17.01.2009 |
Размер файла | 695,2 K |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
45
- Введение
- Концептуальная модель.
- Содержательное описание объекта
- Базовые бизнес-процессы (уровень 1)
- Базовые бизнес-процессы (уровень 2)
- Базовые бизнес-процессы (уровень 3)
- Базовые бизнес-процессы (уровень 4)
- Базовые бизнес-процессы (уровень 5)
- Базовые бизнес-процессы (уровень 6).
- Базовые бизнес-процессы (уровень 7)
- Базовые бизнес-процессы (уровень 8)
- Описание проблемной ситуации
- Функциональная структура проектируемой системы
- Уровень А0. Декомпозиция
- Информационно-логическая модель
- UseCase - диаграммы прецедентов
- Диаграмма взаимодействий
- Диаграмма обслуживания абонентов
- Взаимодействие оператора с БД
- Диаграмма взаимодействия администратора с БД
- Диаграмма состояний
- Процесс заключения договора
- Физическая модель
- Имитационная модель
- Заключение
- Глоссарий
- Библиографический список
Введение
Целью курсовой работы является проектирование автоматизированной информационной системы «Работа с абонентами оператора сотовой связи».
Существует два основных способа проектирования программных систем - структурное проектирование, основанное на алгоритмической декомпозиции и объектно-ориентированное проектирование, основанное на объектно-ориентированной декомпозиции.
Алгоритмическую декомпозицию можно представить как обычное разделение алгоритмов, где каждый модуль системы выполняет один из этапов общего процесса. При объектно-ориентированной декомпозиции каждый объект обладает своим собственным поведением, и каждый из них моделирует некоторый объект реального мира. С этой точки зрения объект является вполне осязаемой вещью, которая демонстрирует вполне определенное поведение. Объекты что-то делают, и мы можем, послав им сообщение, попросить их выполнить некоторые операции.
Объектная декомпозиция имеет несколько преимуществ перед алгоритмической:
Объектная декомпозиция уменьшает размер программных систем за счет повторного использования общих механизмов, что приводит к существенной экономии вычислительных средств;
Объектно-ориентированные системы более гибки и проще эволюционируют со временем, потому что их схемы базируются на устойчивых промежуточных формах. Действительно, объектная декомпозиция существенно снижает риск при создании сложной программной системы. Так как она развивается из меньших систем, в которых мы уже уверены;
Объектная декомпозиция помогает нам разобраться в сложной программной системе, предлагая нам разумные решения относительно выбора подпространства большого пространства состояний.
В объектно-ориентированном анализе существует четыре основных типа моделей: динамическая, статическая, логическая и физическая. Через них можно выразить результаты анализа и проектирования. Выполненные в рамках любого проекта. Эти модели в совокупности семантически достаточно богаты и универсальны, чтобы разработчик мог выразить все заслуживающие внимания стратегические и тактические решения, которые он должен принять при анализе системы и формировании ее архитектуры.
Структурный подход состоит в декомпозиции (разбиении) системы на элементарные функции, т.е. система разбивается на функциональные подсистемы, которые в свою очередь делятся на подфункции, подразделяемые на задачи и т.д. Процесс разбиения продолжается вплоть до конкретных процедур. При этом создаваемая система сохраняет целостное представление, в котором все составляющие компоненты взаимосвязаны.
Концептуальная модель.
Содержательное описание объекта
В курсовой работе объектом исследования является изучение технологического процесса работы биллинговой компании.
Инфраструктура предоставления услуг связи
Для предоставления услуг связи оператору необходимо иметь определенную инфраструктуру, которая в минимальном варианте состоит из компонентов, показанных на следующем рисунке.
Рис. 1. Инфраструктура предоставления услуг связи
Также нужно средство контроля лицевых счетов. При небольшом количестве абонентов это можно делать с помощью стандартной программы бухгалтерского учета, например, 1С-Бухгалтерия.
Базовые бизнес-процессы (уровень 1)
Список базовых бизнес процессов определен уже для простейшей организации компании оператора сотовой связи. Предположим, что есть определенное количество постоянных абонентов. Кроме того, предположим, что ситуация статична, то есть, по меньшей мере, нет новых подключений, нет смен тарифных планов, нет замен оборудования, нет работ по развитию сети и т.д.
В такой минимальной ситуации имеют место следующие бизнес-процессы:
1) Контроль работоспособности оборудования: отслеживание журналов сбоев оборудования, проведение регулярных тестов и пр.
2) Изменение профиля периодических услуг абонента по его заказу. Абонент приходит в абонентский отдел, пишет заявление. В простейшем случае заявка фиксируется в бумажном виде (бумажная карточка абонента). Формируется запрос на программирование для операторов коммутатора. По запросу выполняется программирование коммутатора, делается запись в журнал программирования услуг на коммутаторе.
3) Тарификации разговоров. На регулярной основе выполняется забор тарификационных данных коммутатора (именуемых ТТ-файлами). Выполняется тарификация записей о разговорах. Тарификация в простейшем случае основывается на следующих параметрах звонка: типе, направлении, длительности, времени совершения. Далее выполняется соотнесение записей абонентам. Даже в простейшем случае должен существовать программный тарификатор.
4) Тарификации периодических услуг (подписок). На основании данных о подписках абонента выполняется расчет абонентских плат. Может варьироваться политика начисления: кредит или аванс. Может использоваться программное средство для начисления абонентской платы, либо эта операция может выполняться вручную.
5) Предоставление разовых услуг. Спектр разовых услуг, предоставляемых оператором, может быть весьма широк. Тем не менее, существуют услуги, предоставляемые даже в самом простом случае, например, разовая детализация разговоров. Реализация любой разовой услуги подразумевает какой-либо разовый сервис, за которым следует выписка счета-фактуры (и, возможно, счета на оплату). Формирование данных документов дает основание для выполнения проводок по лицевым счетам в бухгалтерии.
6) Прием платежей от абонентов. Даже в самом простейшем случае компания оператор должна быть в состоянии принимать платежи от абонентов по крайней мере двумя способами: наличными и перечислением с расчетного счета. При приеме платежа происходит обновление состояния лицевого счета абонента, который ведется в бухгалтерской программе. Если платеж происходит через кассу оператора, то появляется документ: приходный кассовый ордер.
7) Закрытие периода и выставление счетов. Закрытие отчетного периода (месяца) подразумевает внесение в бухгалтерскую программу всех операций по лицевым счетам абонентов. Как было показано ранее, платежи уже внесены, по крайней мере, частично. Также внесены данные по разовым услугам. Остается только внести данные по начислениям за звонки и начислениям абонентских план. Необходимо отметить, что закрытие периода есть длительная операция. В частности это связано с тем, что на момент календарного окончания периода нет и не может быть окончательных данных по всем операциям с лицевыми счетами. В частности, необходимо получить окончательные данные с коммутатора о звонках и провести «последнюю тарификацию», а также данные о безналичных платежах. Таким образом, закрытие периода реально может быть выполнено не ранее двух-трех дней с календарного момента его окончания. При закрытии отчетного периода выполняется выставление счетов. В простейшем случае в результате закрытия периода для каждого лицевого счета образуется два печатных документа: счет к оплате и счет-фактура. Помимо того, может оказаться необходимым формировать для абонентов, являющихся юридическими лицами, акты выполненных работ, а для абонентов, являющихся физическими лицами, квитанции на оплату услуг наличными. Одной из типовых услуг является периодическая детализация звонков и услуг, которая также представляет собой формируемый при биллинге документ. После того, как счета выставлены, их необходимо напечатать, отсортировать и принять минимальные меры по доставке.
8) Формирование бухгалтерской отчетности. По результатам закрытия периода необходимо выполнить формирование бухгалтерской отчетности для последующей сдачи ее в налоговую инспекцию. Так или иначе но должна быть сформирована книга продаж, которая включает в себя все выписанные счета-фактуры. Кроме того, книга продаж включает особый вид счета-фактуры - фактуру на сформированные авансы.
9) Взаимодействие с компаниями-провайдерами. В простейшем случае (в рассматриваемой статической ситуации) взаимодействие с компаниями-провайдерами подразумевает оплату их услуг по результатам закрытия биллингового периода.
10) Информационное обслуживание абонента. В любой момент оператор должен быть готов ответить на определенные вопросы абонентов, начиная от справочной информации общего характера (тарифы), и заканчивая информацией о состоянии лицевого счета. Последнее не так уж и просто, если данные о тарификации звонков и начисления абонентских плат не сводятся с состоянием лицевых счетов с какой-либо разумной периодичностью. Надо также учитывать, что выполнять бухгалтерские проводки на самом деле неправильно, поскольку в течение месяца не выписываются счета-фактуры.
11) Формирование отчетов для ГСН. В зависимости от действующего в настоящий момент законодательства, возможно будет необходимым формировать отчеты по абонентской базе для Гос-Связь-Надзора.
Базовые бизнес-процессы (уровень 2)
В природе практически не существует операторов связи, которые не развиваются в сторону расширения абонентской базы. Реально ограничениями могут служить: отсутствие номерной емкости, невозможность развития сети, устаревание стандарта, жесткая конкуренция. Допустим, что оператор развивается нормально. В этом случае дополнительно появляются следующие бизнес процессы.
1) Получение SIM-карт и предпродажная подготовка. Оператор получает SIM-карты от изготовителя вместе с данными аутентификации. Последние представляют собой файл, в котором указаны SIM, IMSI, коды pin и puk, а также ключ Ki. Для того, чтобы SIM-карты правильно воспринималась коммутатором, необходимо загрузить в него аутентификационную информацию, а именно связки IMSI-Ki. Дальнейшие действия по предпродажной подготовке SIM-карт зависят от оператора. Возможны следующие подходы:
a) Предпрограммация карты с активацией. Этот подход подразумевает предварительное связывание IMSI-MSISDN и программирование этой связки на коммутаторе. Кроме того, после программирования созданный на коммутаторе профиль активируется. Таким образом, карта поступает в продажу готовой к использованию. Этот метод наиболее популярен, когда управление профилями абонентов на коммутаторе происходит вручную.
b) Предпрограммация карты без активации. Этот способ аналогичен предыдущему с тем исключением, что профиль на коммутаторе не активируется до специального распоряжения, которое дается по факту подключения.
c) Постпрограммирование карты. При таком подходе связки IMSI-MSISDN не создаются на коммутаторе до момента фактического подключения. Данный способ является наиболее гибким, потому что облегчается задача выбора MSISDN при наличии на руках у продавца конкретной SIM-карты. Кроме того, этот способ наиболее защищен от злоупотреблений. Тем не менее, способ наиболее трудоемкий, потому что необходимо выполнять создание и активацию связок IMSI-MSISDN на коммутаторе «на лету», а также нужна общая база данных по свободным номерам.
После того, как SIM-карты должным образом подготовлены, они поступают на склад.
2) Получение терминального оборудования и его предпродажная подготовка. В рассматриваемой нами ситуации оператор вынужден торговать не только SIM-картами и «подключениями», но и терминальным оборудованием. Наиболее важно то, что терминальное оборудование поступает на склад оператора и должно отслеживаться. Кроме того, в зависимости от стандарта сотовой связи, может потребоваться предпродажная подготовка. Это наименее актуально для стандартов, подразумевающих использование SIM-карт. Тем не менее, как правило новое оборудование тестируется на предмет его работоспособности.
3) Подключение абонента. Это один из самых длинных и сложных бизнес-процессов, в ходе которого совершается объемный документооборот, а также выполняется масса разнообразных действий. Классическая схема подключения является одновременно наиболее сложной из всех. Рассмотрим ее по шагам.
a) Проверка существующей базы. Когда приходит очередной желающий подключиться к сети оператора связи, последний вынужден выполнить проверку своей абонентской базы во избежание мошенничества при подключении (Subscription fraud). В случае бумажной абонентской базы это весьма нелегкая операция.
b) Создание карточки абонента. Если вновь подключающийся абонент «чист», оператор должен зафиксировать его реквизиты в карточке абонента, которая в простейшем случае ведется на бумаге. В этот момент также создается лицевой счет: в наихудшем случае прямо на карточке, в наилучшем - в бухгалтерской программе.
c) Резервирование номера, оборудования, SIM-карты. Далее торговый представитель оператора должен зарезервировать по выбору абонента оборудование и абонентский номер, а также по собственному усмотрению SIM-карту. Необходимо отметить, что выбор номера по усмотрению абонента, как правило, является платной разовой услугой. Есть такие термины «золотой» или «серебряный» номер, отражающие его престиж. При резервировании, естественно, необходимо выполнить проверку, есть ли требуемое оборудование на складе, а также запомнить факт резервирования.
d) Выбор параметров подключения. В простейшем случае при подключении абонент также выбирает тарифный план, заказывает дополнительные периодические услуги, а также вариант исходящего доступа. Эта информация также фиксируется в карточке абонента.
e) Выписка счета на оплату подключения. Счет на оплату подключения выписывается для предоставления абоненту основания для первого платежа.
f) Ожидание оплаты. Далее оператор вынужден ожидать оплаты счета. Здесь возникает масса проблем. Первая из них - отказ от оплаты. В этом случае оператор должен отслеживать «незавершенные» подключения с тем, чтобы снимать резервирование оборудования, номеров и SIM-карт на складе. Более сложная проблема связана с несвоевременной оплатой счета в условиях смены курса валюты.
g) Создание лицевого счета и прием платежа. Прием платежа выполняется точно так же, как мы рассмотрели ранее. Однако, предварительно надо создать лицевой счет. Создавать его заранее, вероятно, не имеет смысла, так как платеж может «не случиться никогда».
h) Активация. Этот шаг имеет место только в том случае, если для оборудования практикуется постпрограммация или предпрограммация без активации.
i) Выписка счета-фактуры, выдача оборудования. В качестве завершающего шага выполняется выписка счета-фактуры (по факту реализации подключения), выписка накладной и выдача оборудования со склада. С этого момента абонент передается для текущего обслуживания абонентскому отделу.
4) Ведение базы данных реквизитов абонентов. Реквизиты абонентов не являются статичной информацией. Время от времени возникает необходимость их изменения: могут измениться паспортные данные, платежные реквизиты, адреса доставки счетов. Данная операция выполняется оператором абонентского отдела по просьбе абонента и фиксируется в карточке абонента.
Базовые бизнес-процессы (уровень 3)
Там где есть рост абонентской базы, там неизбежно появляются «ненадежные» абоненты. Это приводит к ряду бизнес-процессов, которые трудно назвать простыми. Все они направлены на минимизацию дебиторской задолженности, на соблюдение условий договоров, на повторное использование оборудования и номерной емкости, на предотвращение мошенничества.
1) Кредитный контроль. Суть кредитного контроля - проверка состояния лицевых счетов на регулярной основе с целью ограничения подписки абонентов, которое в свою очередь приводит к снижению возможностей по увеличению дебиторской задолженности. Последним шагом по ограничению подписки является полная блокировка абонента. Обратной операцией является «разблокировка» при погашении задолженности. Уровень автоматизации данных процессов напрямую зависит от возможностей по вычислению квази-четких балансов и по управлению коммутатором. В простейшем случае, сведение балансов выполняется вручную по бумажным карточкам абонентов. Далее формируется пакет заявок для операторов коммутатора на ограничение/расширение подписок. Заявки отрабатываются операторами с записью (подшивкой) в журнал. Ясно, что добиться высокого качества кредитного контроля невозможно при низком уровне автоматизации.
2) Работа с блокированными абонентами. Работа с блокированными абонентами, по большому счету, ведется только в двух направлениях. Во-первых, могут рассматриваться вопросы типа «а не было ли сделано неправомерных начислений, с которыми абонент, тем не менее, согласен». Во-вторых, при определенных сроках пребывания абонента в блокированном состоянии возможно начисление пени.
3) Расторжение договоров с должниками. При пассивности абонента в течение определенного промежутка времени, как правило, оператор расторгает договор в одностороннем порядке. Данный процесс позволяет вернуть номерную емкость в оборот для повторного использования. Так же, как и при реализации кредитного контроля, требуется выполнять определенную пакетную обработку данных о лицевых счетах: необходимо проверить наличие операций по лицевому счету. Естественно, эффективность процесса зависит от уровня автоматизации.
4) «Отстой» номеров. При расторжении договоров высвобожденная номерная емкость возвращается в оборот. С одной стороны, особенность заключается в том, что возможно повторное ее использование, с другой стороны в том, что это повторное использование не может быть начато ранее определенного срока (во избежание неудобств и жалоб «новых» абонентов при использовании «старых» номеров). В определенных случаях возможно также повторное использование терминального оборудования и SIM-карт. Суть «отстоя» номеров заключается в выдержке определенного времени до того момента, когда номер поступает в повторную реализацию. Так же, как и в бизнес-процессах, описанных выше в данном разделе, эффективная реализация «отстоя» номеров возможна только при достаточном уровне автоматизации данного процесса.
5) Черные списки IMEI. Ведение черных списков IMEI является одним из способов борьбы с мошенничеством и направлено на предотвращение повторного подключения краденого/утерянного оборудования. Не смотря на то, что стандарт GSM подразумевает возможность использования регистра EIR для контроля черных списков, в России данное решение считается дорогим и популярностью не пользуется. Поэтому реализация черных списков выполняется какими-либо сторонними (менее затратными, и в то же время, менее эффективными) средствами. Реализация черных списков опирается на использование тарификационных данных коммутатора и регистрацию серийных номеров при подключении. Эффективность черных списков, опять же, зависит от уровня автоматизации и при бумажной технологии выполняется ограниченно: есть возможность лишь воспрепятствовать повторному подключению краденого/утерянного оборудования.
Базовые бизнес-процессы (уровень 4)
При реальной работе с абонентами возникают дополнительные бизнес-процессы, назовем их «продвинутыми». Мы выносим их в уровень 4 только потому, что они не являются частыми (хотя и обязательно встречаются), либо потому, что необходимость в них возникает только при существенном росте абонентской базы.
Предварительные замечания по поводу термина «тарифный план». Под тарифным планом понимается набор правил, в соответствии с которыми обслуживается абонент. Эти правила делятся на две части: (1) тарифы и (2) ограничения на подписки.
1) Смена тарифного плана по заказу абонента. Абонент приходит в абонентский отдел и пишет заявление на смену тарифного плана. Далее это заявление отрабатывается в абонентском отделе на предмет расчетов, и в конце концов может завершаться отработкой заявок на коммутаторе. Если уровень автоматизации невысок, то наверняка смены тарифных планов будут допустимы только с первого числа месяца. Вообще говоря, при смене тарифного плана надо полностью рассчитаться за подписки и звонки по старому тарифному плану, затем изменить профиль подписки, и, если это нужно начислить авансовые абонентские платы.
2) Смена тарифного плана по инициативе оператора. Как правило смена тарифного плана по инициативе оператора происходит в случае устаревания какого-либо тарифного плана. Обычно это событие происходит на границе отчетных периодов. В качестве особенностей можно отметить массовость изменений.
3) Ожидаемый платеж. Данный механизм вводится для определенной компенсации задержек при приеме безналичных платежей. При должном уровне автоматизации, этот механизм может также использоваться для повышения удобства абонентов.
4) Регистрация и разбор конфликтов и претензий абонентов. Претензии абонентов могут обусловливаться различными причинами, например, проблемами с оборудованием, ошибками при начислениях за звонки или услуги, ошибками в расчете налогов и т.д., либо несоблюдением условий договора той или иной стороной. Разрешение таких конфликтов ложится на абонентский отдел, в худшем случае дело может дойти до разборок в суде. При существенном росте абонентской базы возникает необходимость фиксации претензий.
5) Возврат средств. Абонент в праве потребовать возврата аванса со своего лицевого счета. Также возврат средств может быть необходим при расторжении договора. В простейшем случае возврат средств выполняется через кассу с выпиской расходного кассового ордера. В случае, когда абонент является юридическим лицом, возврат средств может быть сделан перечислением с расчетного счета оператора.
6) Решение проблемы инкассации. Проблема инкассации заключается в несоответствии расписания работы кассы оператора и службы инкассации. Проблема решается путем выписки приходных кассовых ордеров будущей датой.
7) Расторжение договора. Расторжение договора может выполняться как по желанию абонента, так и оператором в одностороннем порядке. В общем случае при расторжении необходимо выполнить следующие шаги:
a) Прекращение обслуживания всех абонентских номеров данного абонента.
b) Сбор всех операций по лицевому счету.
c) Отмена всех ожидаемых платежей.
d) Проведение внеочередного биллинга.
e) Прием оплаты или возврат средств.
8) Контроль доставки счетов. Включает печать реестров счетов и квитанций на подпись по факту доставки. Данные документы используются отделом доставки или сторонними курьерскими организациями для формирования отчетности по успешно доставленным счетам. Регистрация факта успешной доставки избавляет оператора от претензий недобросовестных абонентов типа «услуги не оплачены, потому что счет не доставлен».
9) Замена оборудования, SIM-карты, номера. Данные операции выполняются на основании заявления абонента. Замена оборудования бывает гарантийная или в порядке апгрэйда. Замена SIM-карт бывает по причине утери, поломки, блокировки или апгрэйда. При замене работоспособного оборудования или SIM-карты последние возвращаются на склад, поэтому должен быть соответствующий складской документооборот. При замене номера высвобожденный номер помещается в «Отстой» для повторного использования в будущем. Замена SIM-карты может сопровождаться заменой номера.
Базовые бизнес-процессы (уровень 5)
Дальнейшим развитием нашей модели будет участие оператора в соглашениях по обеспечению автоматического роуминга. Инфраструктура в этом случае будет выглядеть так, как показано на рисунке 2.
Рассмотрим возникающие бизнес-процессы.
1) Проведение тестов IREG.21, обмен тестовыми SIM-картами. Когда у оператора появляются партнеры по роумингу, сфера его ответственности расширяется, в частности он должен гарантировать работу автоматического роуминга как для своих абонентов в сети партнера, так и для абонентов партнера в своей сети. Способом контроля является регулярное проведение IREG.21 тестов. Они основаны на обмене между операторами тестовыми SIM-картами и регулярном выполнении тестовых звонков.
2) Тарификация звонков гостевых абонентов. Тарификация звонков гостевых абонентов в целом выполняется абсолютно так же, как и тарификация звонков своих абонентов. Особенность состоит в учете таких разговоров. Для учета необходим лицевой счет партнера по роумингу, на который будут относиться все звонки абонентов данного партнера в сети нашего оператора. Отнесение звонков на такой лицевой счет основано на том, что принадлежность звонка абоненту идентифицируется по IMSI абонента, а IMSI для конкретного оператора выбираются вовсе не произвольно, и возможно выделить префикс в IMSI, по которому и определить принадлежность абонента конкретному оператору.
3) Тарификация звонков типа «транзитный в роуминг». Звонки типа «транзитный в руоминг» (Т/Р) возникают, когда совершается входящий звонок для нашего абонента, находящегося в сети партнера по роумингу. Т/Р - это «часть» звонка между домашним коммутатором абонента и обслуживающим коммутатором. При этом на нашем коммутаторе звонок фиксируется как звонок нашего абонента, находящегося в роуминге, на специальный временный номер (MSRN) в той сети, где он находится в роуминге. По номеру MSRN можно определить направление звонка и тарифицировать его.
4) Контроль за тестовыми SIM-картами. Тестовые SIM-карты - это типовые карты оператора, точно такие же, с которыми он подключает абонентов. Тестовые звонки точно так же тарифицируются, как и любые другие, и включаются в роуминговый счет. Кроме роуминговых тестовых карт оператор, как правило, имеет также определенное количество служебных карт и карт, предназначенных для выполнения тестов в своей сети. Все звонки этих карт также тарифицируются. Существуют нормативы, определяющие максимальную стоимость тестовых и служебных звонков, которую можно отнести к расходам (порядка 2% трафика).
5) Fraud-контроль для визитеров. Один из видов Fraud-контроля для визитеров заключается в том, что ежедневно рассчитывается суммарная стоимость звонков по каждому гостевому абоненту и в случае превышения суммой определенного порога (оговоренного в роуминговом соглашении) высылается fraud report. Рассылка происходит по электронной почте или факсом. Fraud report содержит список подозрительных IMSI и стоимость их разговоров за последние сутки. На основании принятого fraud report'a оператор может принять решение о блокировании своего абонента.
6) Обмен роуминговыми тарификационными файлами. Клиринговые центры. Для проведения текущих расчетов с абонентами, бывающими в роуминге, операторы обмениваются между собой на регулярной основе роуминговыми тарификационными файлами (TAP-файлами). TAP-файл содержит детализацию звонков (и услуг), совершенных абонентами нашего оператора в сети партнера по роумингу. На основе TAP-файлов делаются начисления абонентам за звонки в роуминге. Обмен TAP-файлами выполняется по электронной почте. Когда партнеров по роумингу становится очень много, становится неудобным обмениваться TAP-файлами по принципу «каждый с каждым». Для уменьшения трафика TAP-файлов вводятся клиринговые центры.
7) Выставление роуминговых счетов. По окончание отчетного периода партнеры по роумингу выставляют друг другу счета за услуги, предоставленные гостевым абонентам. Особенность состоит в том, что счета выставляются на основе отправленных TAP-файлов. При наличии клирингового центра счета выставляются ему, а не каждому оператору, в сети которого наши абоненты были в роуминге.
Базовые бизнес-процессы (уровень 6).
Рассмотрим бизнес-процессы, возникающие у оператора при внедрении им системы предоплаченного обслуживания (prepaid). Оператор может внедрить только поддержку системы карт экспресс-оплаты, но мы не будем рассматривать отдельно бизнес-процессы, связанные с этим, поскольку все они будут перечислены в данном разделе.
Не зависимо от того, каким образом реализована prepaid-платформа, набор бизнес-процессов оператора пополняется следующим образом.
1) Обеспечение жизненного цикла карты экспресс-оплаты. Жизненный цикл карты экспресс-оплаты состоит из следующих этапов:
a) Генерация. Генерация заключается в формировании номеров и pin-кодов карт. Основная проблема - получить надежно засекреченную информацию о pin-кодах.
b) Изготовление и получение. Изготовлением карт занимаются самостоятельные организации, причем основной проблемой является секретность при передаче данных о pin-кодах производителю карт. После того, как карты изготовлены и получены оператором от производителя, они помещаются на склад.
c) Блокирование и разблокирование. Если при доставке карт от производителя они были похищены, а также в других подобных случаях, произошедших до момента реализации карты абоненту, необходимо блокировать возможность зачисления данной серии карт. Если карты будут найдены целыми и невредимыми, то возможность зачисления серии надо разблокировать.
d) Инициализация и реализация. Непосредственно перед выдачей карт на реализацию их необходимо инициализировать - привести в состояние, когда они могут быть зачислены. Далее реализация может осуществляться через дилерскую сеть, через собственный магазин оператора или через какую-либо еще сеть продавцов.
e) Активация. Активация карт может осуществляться с привлечением оператора или без него. Активация без привлечения оператора может выполняться в том случае, если она поддерживается платформой (с учетом текущего местоположения абонента и доступных ему средств). Возможность активации через оператора должна быть всегда.
f) Гашение. Карты, не зачисленные за установленный срок необходимо гасить - переводить в состояние, когда их уже нельзя зачислить.
2) Обнуление балансов препэйдных абонентов. Это мероприятие нацелено на принуждение препэйдных абонентов вносить платежи. Это особенно важно в том случае, если тарифные планы для препэйдных абонентов продуманы плохо, например, если абонент может совершать бесплатные звонки в полезных для него направлениях (например, пэйджинговая служба). Также необходимо учитывать, что абонентской платы для препэйдных абонентов как правило нет. Поэтому единственным надежным способом списания средств с лицевого счета препэйдного абонента является обнуление баланса.
3) Бухгалтерский учет карт экспресс-оплаты. Это достаточно сложный вопрос, потому что имеются определенные технические проблемы. Например, нет реальной возможности отследить факт продажи конкретной карты, что может быть важно в случае, если абонент потерял только что купленную карту, не успев ее зачислить. В связи с этим встает вопрос, как проводить по бухгалтерии продажу карт и активацию карт.
4) Подключение препэйдного абонента по «коробочному варианту» (опционально). Данный процесс включает следующие шаги:
a) Предпрограммирование оборудования. Выполняется так же, как было описано в бизнес-процессе Предпрограммация карты с активацией.
b) Комплектация наборов. Процесс заключается в сборе наборов, которые, как правило, состоят из SIM-карты, недорогого телефона, одной карты экспресс-оплаты, комплекта документации и анкеты.
c) Реализация через розничную сеть. При реализации покупатель должен заполнить анкету, которая впоследствии будет использоваться для актуализации данных в базе prepaid-платформы.
d) Создание абонента в базе данных prepaid-платформы. Этот процесс автоматически происходит в момент первого зачисления карты экспресс-платы.
e) Актуализация данных в абонентской карточке. Поскольку абонент создается в базе данных prepaid-платформы автоматически в момент первого зачисления, то, очевидно, это происходит в произвольный момент времени и, вероятно, в условиях отсутствия личных данных абонента. В результате приходится актуализировать эти данные по анкетам в ручном режиме позднее.
Базовые бизнес-процессы (уровень 7)
В определенный момент развития оператор начинает работать с дилерской сетью, при этом дилерам делегируются, по меньшей мере, следующие функции:
1) Реализация оборудования (составляет основную часть доходов дилера).
2) Подключение абонентов (дилер получает от оператора определенное вознаграждение за подключения).
3) Реализация карт экспресс-оплаты.
4) Текущее обслуживание абонентов:
a) Информационное
b) Изменение профиля подписок
5) Прием платежей от абонентов (имеются особенности законодательства, например, плательщиком налога с продаж является дилер).
Рассмотрим бизнес-процессы оператора, возникающие при появлении дилерской сети.
1) Передача терминального оборудования на реализацию. Обычно дилеры не пользуются оборудованием, предоставляемым оператором, то есть сами ищут поставщиков. Однако, все зависит от условий дилерского договора. Если оператор предоставляет дилеру оборудование на реализацию, то имеет место операция выдачи дилеру оборудования со склада оператора по накладной. Обратная связь (по факту продажи оборудования) реализуется с помощью документа типа акта передачи материальных ценностей.
2) Передача SIM-карт на реализацию. В простейшем случае, при использовании бумажных технологий, при работе с дилерами используется предпрограммированное терминальное оборудование. Документооборот аналогичен возникающему при работе с терминальным оборудованием: выдача по накладной, подтверждение реализации по акту. Предпрограммация оборудования оставляет простор для злоупотреблений дилером. Поэтому необходимо предпринимать какие-либо административные меры и осуществлять текущий контроль.
3) Передача карт экспресс-оплаты на реализацию. Карты экспресс-оплаты выдаются дилеру со склада оператора по накладной. Как было отмечено ранее, составляет определенную проблему проконтролировать факт продажи карты экспресс-оплаты (именно продажи, а не активации). Очевидно, что выписывать какой-либо документ по факту реализации карты экспресс-оплаты не представляется разумным. Поэтому обратная связь, отражающая реализацию, должна организовываться с помощью специального документа - ежемесячного отчета по реализации. Опираясь на данный отчет можно проконтролировать сумму, которую дилер должен выплатить оператору за реализованные карты. Для дополнительного контроля необходимо использовать данные prepaid-платформы, показывающей статистику активации карт.
4) Ведение лицевого счета дилера. Лицевой счет дилера ведется оператором в бухгалтерии для контроля приема оплаты услуг связи абонентами через дилера, реализации оборудования, SIM-карт, карт экспресс-оплаты и дилерских платежей.
5) Прием платежей от дилера. Оператор должен принимать платежи дилера в счет оплаты реализованных оборудования, SIM-карт, карт экспресс оплаты, подключений, а также платежей, принятых от абонентов в счет оплаты услуг связи.
6) Выплата вознаграждений за подключение. Механизм выплаты вознаграждений определяется дилерским договором. Например, по итогам отчетного периода (количеству подключений, количеству и номиналу проданных карт экспресс-оплаты и т.п.) оператор выплачивает дилеру определенную сумму, либо предоставляет какие-либо льготы.
7) Предоставление льгот. Дилеры, как правило, являются абонентами оператора, но в отличие от регулярных абонентов, обычно, обслуживаются по специальным тарифным планам. Оператор разрабатывает и поддерживает такие тарифные планы специально для своих партнеров по бизнесу.
8) Поддержка инфраструктуры для автоматизации дилерской деятельности. В простейшем случае автоматизировать повседневную деятельность дилера можно с помощью электронной почты, либо web-технологий.
Базовые бизнес-процессы (уровень 8)
Для привлечения новых клиентов, повышения качества услуг, а также в рамках конкурентной борьбы оператор должен, по крайней мере, развивать сеть и вводить новые тарифные планы. В связи с этим возникают бизнес-процессы статистического анализа и моделирования:
1) Анализ загрузки сети. Выполняется на двух уровнях. Во-первых, коммутатор сам производит замеры по количеству абонентов по сотам, по количеству разговоров по сотам и т.п. Во-вторых, оператор может производить анализ тарификационных файлов коммутатора. Это помогает правильно развивать сеть, например, устанавливать новые базовые станции.
2) Анализ эффективности тарифных планов. Оператор должен время от времени анализировать свои тарифные планы на предмет решения задач, поставленных при создании того или иного тарифного плана. Для этого необходимо считать статистики: подключений по тарифным планам, отключений по тарифным планам, смены тарифных планов, начислений по тарифным планам за периодические услуги, разовые услуги, звонки, оборудование и т.п. Все эти статистики надо рассчитывать по маркетинговым категориям клиентов.
3) Моделирование тарифных планов. После принятия решения о необходимости внедрения нового тарифного плана необходимо проводить моделирование, чтобы проверить, оправдает ли новый тарифный план возлагаемые на него надежды. Например, если предполагается ввести новый тарифный план с тем, чтобы существующие клиенты перешли на него, необходимо собрать данные по подключениям, отключениям, начислениям данных абонентов за прошлые периоды и просчитать все эти события по новому плану. Далее оценивается эффективность решения.
Описание проблемной ситуации
Ежедневно к оператору сотовой связи «подключаются» десятки тысяч людей, которые являются как первичными абонентами, так и повторными. На каждого абонента заводится личная карточка, присваивается определенный идентификационный номер. Сотовый оператор, в определенный момент развития, начинает работать с дилерами, над которыми должен осуществляться контроль.
Цели и задач проектируемой информационной системы:
- обеспечить ведение абонентской базы (ввод, редактирование, удаление информации)
- обеспечить заключение/расторжение договоров с абонентами
- контролировать прием платежей от абонентов
- обеспечить тарификацию разговоров, услуг
- производить смену тарифного плана по запросу абонента
- обеспечить формирование отчетов
Функциональная структура проектируемой системы
Функциональная модель является структурированным изображением функций проектируемой организационно-технической системы, а также информации, поддерживающей выполнение этих функций. На этапе проектирования функциональная модель используется для анализа существующих систем и механизмов реализации этих функций. При этом оценивается распределение функций между подразделениями, взаимодействие подразделений, распределение ответственности, документооборот, достоверность получаемой информации, порядок принятия решений и эффективность функционирования системы управления.
В процессе декомпозиции выявляются задачи, обеспечивающие достижение поставленной цели.
Границы модели определяются посредством описания внешних интерфейсов. На функциональных и информационных моделях все стрелки, выходящие извне, - внешние интерфейсы.
Модель, основанная на методологии IDEF, позволяет описать структуру объекта в виде многоуровневой иерархической системы объектов с необходимой глубиной проникновения, сделать информационные и материальные потоки, а также взаимосвязь их и подсистем объекта максимально “прозрачными”.
Блоки на диаграмме размещаются по ступенчатой схеме в соответствии с их доминированием. Согласно этому принципу расположения в левом верхнем углу располагается самый важный процесс или процесс, выполняемый по времени первым. Далее вправо вниз располагаются менее важные или выполняемые позже процессы. Такое расположение облегчает чтение диаграмм. (BPwin автоматически располагает блоки по ступенчатой схеме). Кроме того, блоки должны быть пронумерованы, в соответствии с их доминированием.
Блоки на диаграммах изображаются прямоугольниками и сопровождаются текстом, описывающим подпроцесс. Каждая сторона блока имеет вполне определенное назначение: левая сторона блока предназначена для входов (материал или информация, которые используются или преобразуются для получения результата), верхняя - для управления (правила, стратегии, стандарты), правая - для выходов (материал или информация, получаемые в результате выполнения процесса), нижняя - для механизмов (ресурсы, которые выполняют процесс). Такое обозначение отражает определенные принципы активности: входы преобразуются в выходы, управления ограничивают или предписывают условия выполнения, исполнители описывают, за счет чего выполняются преобразования.
Уровень А0. Декомпозиция
После создания контекстной диаграммы, которая представляет собой описание контекста моделируемой системы, проводится функциональная декомпозиция - система разбивается на подсистемы и каждая подсистема описывается в том же синтаксисе, что и система в целом. Затем каждая подсистема разбивается на более мелкие и так до достижения нужного уровня подробности. В результате такого разбиения, каждый фрагмент системы изображается на отдельной диаграмме декомпозиции. Диаграмма декомпозиции предназначена для детализации работы.
При декомпозиции процесса все стрелки, входящие или исходящие из него, должны быть перенесены на диаграмму нижнего уровня и использованы при ее построении. При этом запрещены всякие новые стрелки, выходящие за пределы новой диаграммы, кроме специальных, так называемых "тоннелированных" стрелок.
Информационно-логическая модель
Первым шагом при создании логической модели БД является построение диаграммы ERD (Entity Relationship Diagram). ERD-диаграммы состоят из трех частей: сущностей, атрибутов и взаимосвязей. Сущностями являются существительные, атрибуты - прилагательными или модификаторами, взаимосвязи - глаголами.
ERD - диаграмма позволяет рассмотреть систему целиком и выяснить требования, необходимые для ее разработки, касающиеся хранения информации.
ERD - диаграмма графически представляет структуру данных проектируемой информационной системы.
Первым этапом является определение сущностей и атрибутов. В БД будут храниться записи об абонентах, следовательно, сущностью будет абонентская база.
Таблица 1. Атрибуты сущности «Абонентская база».
Атрибут |
Описание |
|
№ договора |
Уникальный номер для идентификации заключенного договора с абонентом |
|
Дата заключения |
Дата |
|
Абонент |
Фамилия, имя, отчество абонента, паспортные данные |
|
Лицевой счет |
Информация о состоянии счета обонента |
|
Тарифный план |
Список тарифов для выбора абонентом |
|
Услуги |
Список предоставляемых услуг |
|
Состояние договора |
Физическое состояние договора (например: заключен, расторгнут, приостановлен) |
В полученном списке существуют атрибуты, которые нельзя определить в виде одного поля БД. Такие атрибуты требуют дополнительных определений и должны рассматриваться как сущности, состоящие, в свою очередь, из атрибутов. К таковым относятся: Абонент, Тарифный план, Лицевой счет, Услуги.
Таблица 2. Атрибуты Сущности «Абонент».
Атрибут |
Описание |
|
ФИО абонента |
Фамилия, имя, отчество абонента |
|
Серия паспорта |
Паспортные данные |
|
№ паспорта |
||
Дата рождения |
Дата рождения |
|
Адрес |
Адрес по прописке |
Таблица 3. Атрибуты сущности «Тарифный план»
Атрибут |
Описание |
|
Тариф |
Наименование тарифного плана |
|
Ст вх вн с |
Стоимость входящих звонков внутри сети |
|
Ст исх вн с |
Стоимость исходящих звонков внутри сети |
|
Ст вх с др с оп |
Стоимость входящих звонков с телефонов других сотовых операторов |
|
Ст исх с др с оп |
Стоимость исходящих звонков с телефонов других сотовых операторов |
|
Ст вх с гор тел |
Стоимость входящих звонков с городских телефонов |
|
Ст исх с гор тел |
Стоимость исходящих звонков с городских телефонов |
|
Sms |
Стоимость исходящих sms сообщений (за шт) |
Таблица 4. Атрибуты сущности «Лицевой счет»
Атрибут |
Описание |
|
№ лицевого счета |
Уникальный номер для оплаты услуг оператора |
|
Дата |
Дата внесения денежных средств |
|
Сумма |
Сумма внесенных денежных средств |
Таблица 5. Атрибуты сущности «Услуга»
Атрибут |
Описание |
|
Код услуги |
Уникальный код для идентификации предоставляемой услуги |
|
Описание |
Описание услуги |
|
Примечание |
Правила предоставления услуги |
|
Стоимость |
Стоимость услуги |
Составим ERD-диаграмму, определяя типы атрибутов и проставляя связи сущностями.
Следующим этапом построения логической модели является определение типов атрибутов.
Таблица 6. Типы атрибутов.
Атрибут |
Тип |
|
№ договора |
Integer |
|
Дата заключения |
Date |
|
ФИО абонента |
String |
|
Серия паспорта |
Integer |
|
№ паспорта |
Integer |
|
Дата рождения |
Date |
|
Адрес |
String |
|
№ абонента |
Integer |
|
Состояние договора |
String |
|
Тариф |
String |
|
Ст вх вн с |
Float |
|
Ст исх вн с |
Float |
|
Ст вх с др с оп |
Float |
|
Ст исх с др с оп |
Float |
|
Ст вх с гор тел |
Float |
|
Ст исх с гор тел |
Float |
|
Sms |
Float |
|
№ лицевого счета |
Float |
|
Дата |
Date |
|
Сумма |
Float |
|
Код услуги |
Integer |
|
Описание |
String |
|
Примечание |
String |
|
Стоимость |
Float |
UseCase - диаграммы прецедентов
Прецедентом (Use case) называется описание множества последовательностей действий (включая варианты), выполняемых системой для того, чтобы актер мог получить определенный результат. Графически прецедент изображается в виде эллипса. Нотация прецедента похожа на нотацию кооперации.
Диаграммы прецедентов представляют собой один из пяти типов диаграмм, применяемых в UML для моделирования динамических аспектов. Диаграммы прецедентов играют основную роль в моделировании поведения системы, подсистемы или класса. Каждая такая диаграмма показывает множество прецедентов, актеров и отношения между ними.
Диаграммы прецедентов применяются для моделирования вида системы с точки зрения варианта использования. Чаще всего это предполагает моделирование контекста системы, подсистемы или класса либо моделирование требований, предъявляемых к поведению указанных элементов.
Диаграммы прецедентов имеют большое значение для визуализации, специфицирования и документирования поведения элемента. Они облегчают понимание систем, подсистем или классов, представляя взгляд извне на то, как данные элементы могут быть использованы в соответствующем контексте. Кроме того, такие диаграммы важны для тестирования исполняемых систем в процессе прямого проектирования и для понимания их внутреннего устройства при обратном проектировании.
Диаграммой прецедентов, или использования (Use case diagram), называется диаграмма, на которой показана совокупность прецедентов и актеров, а также отношения между ними.
Диаграммы Use Case определяют поведение системы с точки зрения пользователя. Элемент Use Case описывает, что должна делать система, но не определяет, как она должна это делать. Это позволяет отделить внешнее представление от внутреннего представления.
Вершинами в этой д. являются актеры и элементы Use Case, которые представляют собой действия, выполняемые системой в интересах актеров.
Актер - роль объекта вне системы. Актер прямо взаимодействует с ее частью - конкретным элементом Use Case. Различают актеров и пользователей. Пользователь может играть несколько ролей и моделироваться несколькими актерами. Набор всех элементов Use Case определяет полные функциональные возможности системы.
Абонент
Основной |
Альтернативный |
|
Заключить контракт на обслуживание |
||
Предоставить личные данные (паспортные данные)Открыть лицевой счетВыдать копию договораВвести информацию об абоненте в БД |
Если отсутствуют личные данные - договор не заключать. |
|
Запрос информации о состоянии счета |
||
Идентификация пользователяЗапрос баланса на счетеВыдать отчет |
Если абонент не идентифицирован - запрос не выполнять. |
|
Заказать услугу |
||
Идентификация абонентаПроверка состояния лицевого счетаВыбор услугиВыдать подтверждение |
Если абонент не идентифицирован - запрос не выполнять.Если средств на счете не достаточно - услугу не предоставлять. |
Оператор
Основной |
Альтернативный |
|
Ввод информации в БД |
||
Получить доступ к БДВвести информацию в БД |
Если доступ закрыт - выход из системы. |
|
Обслуживание абонента |
||
Выбор предоставляемой услугиВвод информации о предоставляемой услуге |
Если средств на лицевом счете не достаточно - не предоставлять обслуживание. |
Диаграмма взаимодействий
На диаграммах взаимодействий показывают связи, включающие множество объектов и отношений между ними, в том числе сообщения, которыми объекты обмениваются. При этом диаграмма последовательностей акцентирует внимание на временной упорядоченности сообщений, а диаграмма кооперации - на структурной организации посылающих и принимающих сообщения объектов.
Диаграммы взаимодействий используются для моделирования динамических аспектов системы. Сюда входит моделирование конкретных и прототипических экземпляров классов, интерфейсов, компонентов и узлов, а также сообщений, которыми они обмениваются, - и все это в контексте сценария, иллюстрирующего данное поведение. Диаграммы взаимодействий могут существовать автономно и служить для визуализации, специфицирования, конструирования и документирования динамики конкретного сообщества объектов, а могут использоваться для моделирования отдельного потока управления в составе прецедента.
Диаграммы взаимодействий важны не только для моделирования динамических аспектов системы, но и для создания исполняемых систем посредством прямого и обратного проектирования.
Диаграмма взаимодействий (Interaction diagram) описывает взаимодействия, состоящие из множества объектов и отношений между ними, включая сообщения, которыми они обмениваются. Диаграммой последовательностей (Sequence diagram) называется диаграмма взаимодействий, акцентирующая внимание на временной упорядоченности сообщений. Графически такая диаграмма представляет собой таблицу, объекты в которой располагаются вдоль оси X, а сообщения в порядке возрастания времени - вдоль оси Y. Диаграммой кооперации (Collaboration diagram) называется диаграмма взаимодействий, основное внимание в которой уделяется структурной организации объектов, принимающих и отправляющих сообщения. Графически такая диаграмма представляет собой граф из вершин и ребер.
Диаграмма обслуживания абонентов
Взаимодействие оператора с БД
Диаграмма взаимодействия администратора с БД
Диаграмма состояний
Процесс заключения договора
Подобные документы
Описание основных целей и рабочих процессов оператора сотовой связи. Шкала оценки важности информации. Построение матрицы ответственности за аппаратные ресурсы. Разработка структурной схемы их взаимодействия между собой и модели информационных потоков.
практическая работа [336,0 K], добавлен 28.01.2015Анализ информационной системы салона сотовой связи. Разработка модели бизнес-процессов учебной информационной системы. Создание справочников и их заполнение, документов и их программного кода. Порядок разработки регистров, трех видов планов и отчетов.
курсовая работа [1,4 M], добавлен 05.06.2013Обоснование актуальности проблемы. Анализ степени изученности. Структурная сеть для анализа Интернет источников. Описание объекта исследования. Структурная схема оператора сотовой связи. Применение системного анализа для решения проблемы.
курсовая работа [1,6 M], добавлен 26.02.2007Этапы разработки программной системы, позволяющей контролировать использование сервисов сотовой связи клиентами. Описание процесса проектирования и классов. Описание структуры данных, хранимых в файле клиентов. Диаграмма деятельности для провайдера.
курсовая работа [5,2 M], добавлен 30.06.2014Описание салона-магазина по предоставлению услуг оператора мобильной связи. Обоснование создания автоматизированной информационной системы "Оператор". Выбор программного обеспечения, проектирование реляционной базы данных. Описание основ интерфейса.
дипломная работа [1,9 M], добавлен 27.05.2015Разработка веб-сайта "Салон сотовой связи", деятельностью которого является продажа телефонов и прочих сопутствующих услуг и продуктов. Горизонтальное выравнивание объектов. Работа с языком гипертекстовой разметки HTML и каскадными таблицами стилей CSS.
курсовая работа [32,6 K], добавлен 24.06.2013Определение типов сущности и связи, атрибутов и их доменов с целью автоматизации учета междугородних телефонных разговоров между абонентами как через оператора связи, так и напрямую с вызываемым абонентом. Проверка моделей с помощью правил нормализации.
курсовая работа [1,3 M], добавлен 01.02.2011Анализ деятельности салона сотовой связи "РИТМ". Автоматизация процесса подключения абонентов к сети. Характеристика комплекса технических средств и программного обеспечения ЭВМ. Алгоритмы и их описание. Расчет затрат на формирование информационной базы.
дипломная работа [69,9 K], добавлен 24.04.2013Общие понятия реляционного похода к базам данных. Разработка программы для автоматизации функций руководителя салона сотовой связи. Детализация бизнес-процессов. Интерфейс для работы пользователя. Тестирование разработанной информационной системы.
курсовая работа [2,2 M], добавлен 26.06.2012Правила создания баз данных в Access. Основы строения таблиц базы "Оператор сотовой связи" с помощью Конструктора; изучение их связи. Определение полей и типов данных. Создание параметрических универсальных запросов, главной кнопочной формы и отчетов.
курсовая работа [1,7 M], добавлен 22.04.2014