воскресенье, 29 августа 2010 г.

Разработка многопользовательской автоматизированной системы управления организацией. – Часть 1 (FDS)

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

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 Требования по защите данных:

  • Доступ к системе может получить только зарегистрированный пользователь;
  • У каждого зарегистрированного пользователя свой пароль (рекомендуется);
  • Каждый пользователь будет иметь доступ только к той информации, которой он пользуется.

Комментариев нет:

Отправить комментарий