Технология реализации системы

Системы «Холмы России».

Версия 1.0 от 20.06.2017 г.

 

ООО "СимбирСофт"

432071, г. Ульяновск,

Проспект Наримановка, 1, строение 2

Телефон:: +7 /8422/ 44-66-91

E-mail: [email protected]

Web: www.simbirsoft.com

Оглавление

2. Общие положения. 4

3. Требования и ограничения. 5

4. Варианты использования приложения. 7

4.1. Перечень пользователей приложения. 7

4.2. Перечень вариантов использования. 7

5. Основные сущности Приложения. 8

 

История изменений

Версия	Автор	Комментарий
1.0 от 20.06.2016 г.	Кузин Алексей	Создание документа

 

 

1. Термины и определения

 

Система – разрабатываемая система «Холмы России».

ОС – Операционная система.

 

Общие положения

 

2.1. Наименование системы

«Система подсчета результатов гонки «Холмы России», далее кратко «Холмы России».

 

Назначение системы

Основные функции системы

· Автоматизации подсчетов результатов этапов гонки по ралли-рейдам.

 

Основные модули системы

Система имеет клиентский модуль. Разделение ролей не предусмотрено

 

Рисунок 1 - Общая схема бизнес процесса посредством системы

 

 

Технология реализации системы

ВАЖНО: Перед окончательным согласованием ТЗ с заказчиком требуется согласовать данные требования с разработчиками!

2.3.1. Web приложение

Пример:

· Интеграция с 1С (1С: Управление торговлей).

· Реализация сайта – Битрикс («1С-Битрикс: Управление сайтом - Стандарт»).

Требования и ограничения

Требования к аппаратному и программному обеспечению

Требования к серверной части

Серверная часть должна корректно работать на популярных дистрибутивах Linux:

· CentsOS версии 5.x и 6.x;

· Ubuntu 12.x и 13.x;

· Debian 7.x.

.

 

Требования к клиентской части

3.1.2.1. Веб приложение

Все страницы сайта должны корректно (согласно ТЗ) отображаться и работать в популярных современных браузерах:

· Google Chrome 21.x – 32.x;

· Internet Explorer 10.x и 11.x;

· Opera 15.x - 18.x;

· Mozilla Firefox 20.x – 26.x.

ВАЖНО: Перед окончательным согласованием ТЗ с заказчиком требуется согласовать данные требования с тестировщиками на предмет актуальности версий браузеров!!!
Не допускается неоднозначной формулировки, например: «версия 2.0 и выше».

 

 

3.2. Требования к производительности и быстродействию системы

Требования к серверной части

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

Требование к клиентской части

ВАЖНО: Перед окончательным согласованием ТЗ с заказчиком требуется согласовать данные требования с разработчиками, а именно: отдельно обозначить требования к скорости загрузки для страниц/экранов/элементов, которые могут выйти за пределы стандартных требований по времени загрузки!!!

3.2.2.1. Веб приложение

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

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

3.2.1.2. Время, требующееся для повторной загрузки и отображения страницы сайта с локального сервера (когда все кэшируемые ресурсы уже были загружены), не должно превышать 5 секунд.

3.2.1.3. Время, требующееся для загрузки и отображения AJAX элементов на странице, не должно превышать 3 секунд с момента активации элемента.

Примечание – При условии, что на сервере отсутствует какая-либо дополнительная нагрузка со стороны других пользователей или программ.

 

3.3. Требования к графическому дизайну

ВАЖНО: Также в данном разделе оговариваются все дополнительные требования к дизайну как «Цветовая гамма», «Используемые шрифты» и т.п.
Если Заказчик предоставляет макеты, требуется в данном разделе зафиксировать список предоставленной Заказчиком на момент согласования ТЗ документации и присоединить документ(~ы) к ТЗ в качестве Приложения.

 

3.4. Требования к локализации

· Разрабатывается русскоязычная версия системы.

· Добавление языковых версий не предусматривается.

· Система измерения пользователя – СИ (метрическая).

 

3.5. Требования к надежности системы

Приложение должно выполнять безошибочное выполнение тест плана.

 

 

3.6. Требования к нагруженности системы

· Количество одновременно работающих пользователей – max 250 пользователей.

· Объем каталога – max 500 тысяч позиций (общее количество по всем производителям).

· Количество зарегистрированных пользователей – max 650 за первый год, и предполагаемое увеличение - 650 в каждый последующий год.

· Количество заказов – max 1000 в месяц.

 

3.7. Требования к сбору статистики

Варианты использования

Основные сущности

В данном разделе дан список основных сущностей и их параметров, используемых приложением.

Именно «приложением», т.к. тут нас не интересует структура данных на сервере и т.п.

Примечание - Структура сущностей может корректироваться и уточняться на стадии разработки или на следующих этапах написания ТЗ.

 

Список сущностей

Тут надо перечислить (просто перечислить) все сущности, которые будут использованы (храниться) в приложении. Например:

· Пользователь

· Категория товаров

· Товар

· Отзыв

Параметры сущностей

Тут надо перечислить параметры сущностей. Например:

Пользователь

Категория товаров

Товар

Отзыв

 

Справочники приложения

Тут надо перечислить справочники (если они есть) и варианты их значений. Например:

Статус пользователя

 

 

Карта экранов системы

 

 

Рисунок 7.1 – Карта экранов системы.

 

Описание интерфейса

 

Главный экран

 

· Задача навигация по системе. На экране отображается список модулей системы

 

Рисунок 5.1 – Главная страница

5.1.1. При клике на прямоугольник с названием модуля мы попадаем на страницу модуля

Модуль Ввод условий гонки

Рисунок 5.2.1 – Ввод условий гонки форма 1

5.2.1. При клике на прямоугольник ввод условий гонки мы попадаем на экран №1. На экране Вводится название этапа. Дата начала и дата окончания. После ввода информации нажимается клавиша вперед

 

 

Рисунок 5.2.2 – Ввод условий гонки форма 2

 

5.2.2. На второй форме вводим данные на каждый день. Количество спецучастков (СУ) и время явки на старт первого участника. Вводится шаг (в минутах) явки на старт следующих участников. Всего возможно ввести три группы участников. В каждой группе вводится количество участников и шаг на который увеличивается плановое время явки на старт.

Данные вводятся на каждый день гонки. Нажимается клавиша вперед.

 

Рисунок 5.2.3 – Ввод условий гонки форма 3

5.2.3. На третей форме вводим данные по спецучасткам (СУ). Вручную вводится количество КС и КП. Также вводится колонка начало у тех СУ, которые не являются первыми в день. Вводится цифра. (она означает количество минут с времени финиша каждого участника). Нажатие на клавишу вперед означает, что данные о начале гонки введены.

 

Модуль «Лист исключения»

Рисунок 5.6 – Форма «Лист исключения»

5.6.1. Форма «Лист исключения» предназначена для ввода данных по экипажам выбывших из соревнований.

5.6.2. Вводятся данные Стартовый №, спецучасток.

5.6.3. Причина вводится из всплывающего списка (два значения искл. и сх) Искл – экипаж исключен по решению судей. СХ – экипаж сошел с дистанции по техническим либо иным причинам.

5.6.4. «При нажатии клавиши сохранить данные сохраняются»

Приложения

 

Системы «Холмы России».

Версия 1.0 от 20.06.2017 г.

 

ООО "СимбирСофт"

432071, г. Ульяновск,

Проспект Наримановка, 1, строение 2

Телефон:: +7 /8422/ 44-66-91

E-mail: [email protected]

Web: www.simbirsoft.com

Оглавление

2. Общие положения. 4

3. Требования и ограничения. 5

4. Варианты использования приложения. 7

4.1. Перечень пользователей приложения. 7

4.2. Перечень вариантов использования. 7

5. Основные сущности Приложения. 8

 

История изменений

Версия	Автор	Комментарий
1.0 от 20.06.2016 г.	Кузин Алексей	Создание документа

 

 

1. Термины и определения

 

Система – разрабатываемая система «Холмы России».

ОС – Операционная система.

 

Общие положения

 

2.1. Наименование системы

«Система подсчета результатов гонки «Холмы России», далее кратко «Холмы России».

 

Назначение системы

Основные функции системы

· Автоматизации подсчетов результатов этапов гонки по ралли-рейдам.

 

Основные модули системы

Система имеет клиентский модуль. Разделение ролей не предусмотрено

 

Рисунок 1 - Общая схема бизнес процесса посредством системы

 

 

Технология реализации системы

ВАЖНО: Перед окончательным согласованием ТЗ с заказчиком требуется согласовать данные требования с разработчиками!

2.3.1. Web приложение

Пример:

· Интеграция с 1С (1С: Управление торговлей).

· Реализация сайта – Битрикс («1С-Битрикс: Управление сайтом - Стандарт»).

Требования и ограничения

Требования к аппаратному и программному обеспечению

Требования к серверной части

Серверная часть должна корректно работать на популярных дистрибутивах Linux:

· CentsOS версии 5.x и 6.x;

· Ubuntu 12.x и 13.x;

· Debian 7.x.

.

 

Требования к клиентской части

3.1.2.1. Веб приложение

Все страницы сайта должны корректно (согласно ТЗ) отображаться и работать в популярных современных браузерах:

· Google Chrome 21.x – 32.x;

· Internet Explorer 10.x и 11.x;

· Opera 15.x - 18.x;

· Mozilla Firefox 20.x – 26.x.

ВАЖНО: Перед окончательным согласованием ТЗ с заказчиком требуется согласовать данные требования с тестировщиками на предмет актуальности версий браузеров!!!
Не допускается неоднозначной формулировки, например: «версия 2.0 и выше».

 

 

3.2. Требования к производительности и быстродействию системы

Требования к серверной части

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

Требование к клиентской части

ВАЖНО: Перед окончательным согласованием ТЗ с заказчиком требуется согласовать данные требования с разработчиками, а именно: отдельно обозначить требования к скорости загрузки для страниц/экранов/элементов, которые могут выйти за пределы стандартных требований по времени загрузки!!!

3.2.2.1. Веб приложение

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

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

3.2.1.2. Время, требующееся для повторной загрузки и отображения страницы сайта с локального сервера (когда все кэшируемые ресурсы уже были загружены), не должно превышать 5 секунд.

3.2.1.3. Время, требующееся для загрузки и отображения AJAX элементов на странице, не должно превышать 3 секунд с момента активации элемента.

Примечание – При условии, что на сервере отсутствует какая-либо дополнительная нагрузка со стороны других пользователей или программ.

 

3.3. Требования к графическому дизайну

ВАЖНО: Также в данном разделе оговариваются все дополнительные требования к дизайну как «Цветовая гамма», «Используемые шрифты» и т.п.
Если Заказчик предоставляет макеты, требуется в данном разделе зафиксировать список предоставленной Заказчиком на момент согласования ТЗ документации и присоединить документ(~ы) к ТЗ в качестве Приложения.

 

3.4. Требования к локализации

· Разрабатывается русскоязычная версия системы.

· Добавление языковых версий не предусматривается.

· Система измерения пользователя – СИ (метрическая).

 

3.5. Требования к надежности системы

Приложение должно выполнять безошибочное выполнение тест плана.

 

 

3.6. Требования к нагруженности системы

· Количество одновременно работающих пользователей – max 250 пользователей.

· Объем каталога – max 500 тысяч позиций (общее количество по всем производителям).

· Количество зарегистрированных пользователей – max 650 за первый год, и предполагаемое увеличение - 650 в каждый последующий год.

· Количество заказов – max 1000 в месяц.

 

3.7. Требования к сбору статистики

Варианты использования