Автоматизация учёта технического обслуживания техники сервисного центра, страница 5

          - существенная – ошибка, приводящая к увеличению времени обслуживания, не позволяющая комфортно использовать систему.

          - грубая ошибка – потеря данных или искажение в любом виде. Недопустимо.

2.6.4 Производительность.

- Время реакции для операции (среднее, максимальное).

          - время сохранения изменений – менее 1с, 5с.

          - время поиска – 1с, 10с.

- Производительность.

Интенсивность запросов не высокая, в среднем 1,2 в секунду.

- Полная мощность.

Одновременная работа в системе более 50 человек, из-за не высокая интенсивность работы с ней.

- Режимы снижения производительности.

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

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

- Использование ресурсов.

          - на сервере: 2Ггц, 2 ГБ ОЗУ, до 3ГБ на ЖД.

          - на клиенте: 1,5Ггц, 30 МБ ОЗУ, 3 МБ на ЖД.

          - компьютерная сеть: до 1 Мбит/сек.

2.7 Возможности поддержки.

Исходные коды компонентов системы структурированы и закомментированы.

СУБД MsSQL  содержит встроенные средства диагностики ошибок и оптимизации хранения данных.

2.8 Проектные ограничения.

·  система создается с использованием  языка программирования - C#.

·  в качестве среды разработки используется MS VisualStudio.

2.9 Требования к интерактивной пользовательской документации и справочной системе.

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

 - необходимо краткое описание функций и возможностей системы.

2.10 Приобретаемые компоненты.

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

2.11 Интерфейсы.

- Пользовательские интерфейсы:

Пользователь взаимодействует с системой посредством экранных форм (Состав экранных форм и их управляющих элементов).

- Аппаратные интерфейсы:

Не используются.

- Программные интерфейсы:

Контроль над клиентским приложением осуществляет операционная система на которой запущено данное приложение.

-  Коммуникационные интерфейсы:

Для связи клиентского приложения с серверной базой данных используется технология Ado.net.

2.12 Лицензионные требования.

АУТ основана на свободно распространяемом программном обеспечении, свободное распространение и редактирование.

2.13 Предупреждения, касающиеся законодательства, авторских прав и другие замечания.

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

·  автор не несет никакой ответственности за причиненный вред, причиной которого является данная система.

·  система распространяется бесплатно, разработчик не несёт ответственности за причинённый явный или не явный ущерб.

3. Разработка рабочего проекта

3.1 Определение классов анализа

1. Классы объектов сущностей

Состав классов анализа:

1) класс «Инженер» описывает информацию о инженерах работающих в сервисном центре.

Атрибуты класса:

- фамилия,

- имя,

- отчество,

- отдел,

- разряд.                                                                

2) класс «Техника» описывает информацию о технике находящейся на ремонте в сервисном центре.

Атрибуты класса:

     - статус,

- номер квитанции,

- марка,

- модель,

- серийный номер,

- ФИО инженера,

- дата принятия.

3) класс «Квитанция» описывает информацию о квитанции, которая используется в работе сервисного центра.

Атрибуты класса:

- номер квитанции,

- дата создания,

     - диспетчер,

     - инженер,

- клиент,

     - текущий статус.

4) класс «Список квитанций» содержит информацию о хранящихся квитанциях

Атрибуты класса:

- номер квитанции,

- количество квитанций,

     - диспетчер,

     - инженер,

- клиент,

5) класс «Клиент» содержит информацию о клиентах, которые принесли на обслуживание свою технику.

Атрибуты класса:

- организация,

- фамилия,

     - имя,

     - отчество,

     - контакты,

- адрес.

 2. Граничные классы – классы объектов, реализующих формы;

1) класс «Форма_диспетчер» характеризует программное окно, в котором диспетчер может просматривать и управлять квитанциями.

Атрибуты класса:

     - Таблица_отображение_квитанций:

столбец_номер_квитанции;

столбец_организация;

столбец_контакты;

столбец_статус;

столбец_инженер;

столбец_дата_принятия;

столбец_дата_завершения;

столбец_техника;

- Поле_ввода_даты;

- Выпадающий_список_статус;

- Выпадающий_список_инженер;

- Кнопки_:

сортировать;

принятие_в_ремонт;

вызов_инженера;

закрыть.

2) класс «Форма_инженера» характеризует программное окно, в котором инженер может просматривать квитанции.

Атрибуты класса:

     - Таблица_отображение_квитанций:

столбец_номер_квитанции;

столбец_организация;

столбец_контакты;

столбец_статус;

столбец_инженер;

столбец_дата_принятия;

столбец_дата_завершения;

столбец_техника;

- Поле_ввода_даты;

- Выпадающий_список_статус;

- Выпадающий_список_инженер;

- Кнопки_:

сортировать;

закрыть.

3) класс «Форма_квитанция_принятие_в_ремонт» характеризует программное окно, в котором формируется квитанция приёма техники.

Атрибуты класса:

     - Номер_квитанции;

     - Техника;

     - Серийный_номер;

     - Тип_ремонта;

     - Описание_внешнего_осмотра;

     - Не исправность_со_слов_клиента;

     - Примечание;

     - Диспетчер;

     - Дата_принятия;

- Дата_выдачи;

- Статус;

- Назначенный_инженер;

- Клиент;

- Контакты;

4) класс «Форма_квитанция_принятие_вызова» характеризует программное окно, в котором формируется квитанция вызова инженера.

Атрибуты класса:

- Номер_заявки;

- Диспетчер;

- Назначенный_инженер;

- Дата_принятия;

- Дата_завершения;

- Клиент;

- Контакты;

- Адрес;

     - Модель;

     - Характеристика вызова.