В данной статье мы опишем разработку проекта по автоматизации управления телефонной станцией.
1. Введение
1.1 Назначение
Цель данного проекта – разработать автоматизированную систему управления организацией. Область применения – Телефонная станция. Система должна упростить работу сотрудников по управлению организацией, тем самым позволяя сосредоточить свое внимание на основной работе.
Пользователями данного продукта являются сотрудники телефонной станции, службы трех типов: ремонтная, планово-статистическая и управляющая и бухгалтерия.
1.2 Релизация
Проект реализуется при помощи MS SQL Server 2000 & MS Visual Studio .NET 2003.
Клиентская часть пишется на C#.
Для доступа к данным будет использована технология ADO.NET.
1.3 Определения и принятые сокращения
В настоящем документе приняты следующие определения и сокращения:
| Сокращение | Определение |
| БД | База Данных |
| ОС | Операционная Система |
2. Общее описание
Поселок городского типа имеет свою телефонную станцию. На данном этапе станция имеет 20 каналов связи и не может обслуживать одновременно более 340 телефонных номеров. Абонентами могут быть как физические, так и юридические лица. Юридическое лицо (организация) в отличие от физического может являться владельцем нескольких телефонных номеров. Зато физические лица могут получать льготы по абонентной плате.
Телефонная станция осуществляет связь как внутри города, так и с другими городами. Все разговоры с другими городами оплачиваются повременно в зависимости от удаленности объекта. Внутригородские разговоры частично оплачиваются за счет абонентной платы (10 минут ежедневно), а частично – повременно (все, что сверх 10 минут). Абонентная плата установлена 30 руб. ежемесячно для физических лиц и 120 руб – для юридических лиц.
На каждый междугородный разговор составляется квитанция на оплату и отсылается абоненту. В квитанции указывается дата разговора, длительность разговора, код города, куда звонил абонент, и сумма оплаты разговора. Также указывается крайний срок оплаты по квитанции. В случае неуплаты после указанного срока телефон может быть отключен.
На внутригородские разговоры квитанция составляется ежемесячно и отправлятся абоненту вместе с квитанцией на абонентную плату. В квитанцию включаются все телефонные звонки сверх установленной бесплатной нормы, сделанные абонентом за текущий месяц, с указанием даты, длительности разговора и телефонного номера, по которому был звонок, сумма по конкретному разговору и общая сумма по квитанции.
При разработке программного продукта необходимо учесть, что прохождение телефонного звонка фиксируется в БД. В нашем случае должен быть разработан специальный программный блок, имитирующий работу станции.
2.1 Функции продукта
В функции ремонтной службы входит:
· Прием заявок от абонентов в случае неисправности на телефонной сети. Заявка фиксируется в специальном журнале с указанием телефонного номера абонента, даты заявки, типа неисправности, срока устранения неисправности и кто устранил неполадку. Последних три типа данных записываются в журнал наладчиком, проводившим работы. Неисправностей может быть несколько.
· Сбор статистических данных о неисправностях одинакового типа и места их возникновения с целью предупреждения их в дальнейшем.
В функции работника бухгалтерии входит:
· ежемесячное формирование квитанций на абонентную плату с учетом льгот и плату за телефонные разговоры сверх установленной нормы и отправка абонентам.
В функции планово-статистической и управляющей службы входит:
· Сбор статистики о звонках
· Введение в строй новых телефонных номеров и подключение новых абонентов.
· Принятие решений об отключении телефона при неправильной его эксплуатации абонентом и за неуплату.
· Формирование штата сотрудников.
· Формирование справочных таблиц.
2.2 Характеристика пользователей и требования по выпуску
· Пользователь должен свободно владеть компьютером.
· Пользователь должен хорошо знать ту организацию, для которой создана БД.
· Администратор системы должен иметь навыки работы с MS SQL Server 2000 и знать язык Transact-SQL.
· Для работы клиентской части необходим .NetFrameWork версии 1.1(или выше).
· Необходимо учесть системные требования MS SQL Server 2000.
2.3 Общие требования и ограничения
· Разработка должна представлять законченный продукт, предназначенный для испытаний и продажи.
· БД должна быть удобна и максимально проста в использовании.
3. Специфические требования
3.1 Регистрация звонков:
- Запись о звонке добавляется в таблицу CallLog;
- Все поля таблицы являются обязательными;
- Запись в таблицу производит блок моделирования звонков;
- Для блока моделирования указывается диапазон дат и количество звонков;
3.2 Прием заявок от абонентов в случае неисправности:
- Запись о заявке добавляется в таблицу Crash;
- Все заявки имеют уникальный идентификатор;
- Указываются:
1. номер абонента;
2. дата заявки;
3. тип неисправности (из списка по таблице CrashType);
4. срок устранения неисправности;
5. кто устранил неполадку (из списка по таблице User);
- Фиксируется факт устранения;
- Все поля, кроме даты устранения, являются обязательными.
3.3 Сбор статистических данных о неисправностях:
- Составляется запрос по таблицам Crash и CrashType;
- Возможно получение списка неисправностей одного типа;
- Результаты запроса отображаются на экране в виде таблицы.
3.4 Ежемесячное формирование квитанций:
- Запись о квитанции добавляется в таблицу Receipt;
- Запись формируется на основе данных из таблицы CallLog
- После оплаты флаг Receipt .State = true
3.5 Принятие решений об отключении телефона:
- Телефон отключается путём установки в false флага Phone.State
- Возможно отключение абонента путём установки в false флага Abonent.State
3.6 Формирование списка скидок:
- Запись добавляется в таблицу DiscountType;
- Все записи имеют уникальный идентификатор;
- Все поля таблицы являются обязательными;
- При удалении скидки все записи о ней из таблицы AbonentType удаляются.
3.7 Формирование списка городов:
- Запись добавляется в таблицу City;
- Все записи имеют уникальный идентификатор;
- Все поля таблицы являются обязательными;
- При удалении города все записи о нём из таблицы CallLog удаляются.
3.8 Формирование списка типов абонентов:
- Запись добавляется в таблицу AbonentType;
- Все записи имеют уникальный идентификатор;
- Все поля таблицы являются обязательными;
- При удалении типа удаляются все записи с его использованием из таблицы Abonent (при удалении абонента все записи о нём из таблиц CallLog, PayLog, Receipt, Phone, Crash удаляются).
3.9 Формирование списка служб:
- Запись добавляется в таблицу Service;
- Все записи имеют уникальный идентификатор;
- Все поля таблицы являются обязательными;
- При удалении службы все записи о ней из таблиц User, Crash удаляются.
3.10 Формирование списка типов неисправностей:
- Запись добавляется в таблицу CrashType;
- Все записи имеют уникальный идентификатор;
- Все поля таблицы являются обязательными;
- При удалении типа удаляются все записи с его использованием из таблицы Crash.
3.11 Формирование списка абонентов:
- Запись добавляется в таблицу Abonent;
- Все записи имеют уникальный идентификатор;
- Все поля таблицы являются обязательными.
- При удалении абонента все записи о нём из таблиц CallLog, PayLog, Receipt, Phone, Crash удаляются.
3.12 Формирование штата сотрудников:
- Запись добавляется в таблицу User;
- Все записи имеют уникальный идентификатор;
- Все поля таблицы являются обязательными.
- При удалении сотрудника все записи о нём из таблицы Crash удаляются.
4. Требования к данным
4.1 Типы данных:
| Поле | Тип | Обязательность | |
| Service | ServiceID | int | да |
| AccessType | tinyint | да | |
| Description | text | да | |
| User | UserID | int | да |
| FName | varchar | да | |
| LName | varchar | да | |
| ServiceID | int | да | |
| UserName | varchar | да | |
| Password | varchar | нет | |
| Abonent | AbonentID | int | да |
| FName | varchar | да | |
| LName | varchar | да | |
| Company | varchar | нет | |
| AbonentTypeID | bit | да | |
| State | bit | да | |
| AbonentType | AbonentTypeID | int | да |
| DiscountTypeID | int | да | |
| Cost | money | да | |
| Phone | PhoneID | int | да |
| AbonentID | int | да | |
| Number | varchar | да | |
| State | bit | да | |
| Crash | CrashID | int | да |
| CrashTypeID | int | да | |
| PhoneID | int | да | |
| RegDate | smalldatetime | да | |
| FixDate | smalldatetime | нет | |
| UserID | int | да | |
| State | bit | да | |
| CrashType | CrashTypeID | int | да |
| Description | text | да | |
| CallLog | CallLogID | int | да |
| PhoneID | int | да | |
| CallDate | smalldatetime | да | |
| LongTime | smalldatetime | да | |
| CityID | int | да | |
| ReceiptState | bit | нет | |
| DiscountType | DiscountTypeID | int | да |
| Rate | tinyint | да | |
| Description | text | да | |
| City | CityID | int | да |
| City | varchar | да | |
| CityCode | varchar | да | |
| Cost | money | да | |
| Receipt | ReceiptID | int | да |
| AbonentID | int | да | |
| LocalCost | money | да | |
| TrunkCallCost | money | да | |
| State | bit | да | |
| Date | smalldatetime | нет | |
| PayDate | smalldatetime | да | |
| Archive | AbonentID | int | да |
| FName | varchar | да | |
| LName | varchar | да | |
| Company | varchar | нет | |
| State | bit | да | |
| Cost | money | да | |
| Rate | tinyint | да |
4.2 Требования по защите данных:
- Доступ к системе может получить только зарегистрированный пользователь;
- У каждого зарегистрированного пользователя свой пароль (рекомендуется);
- Каждый пользователь будет иметь доступ только к той информации, которой он пользуется.
Комментариев нет:
Отправить комментарий