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

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

Версия 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. Требования к сбору статистики

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