2013 07-22 тз-пожилая-система

ДЛЯ ОБЩЕГО ПОЛЬЗОВАНИЯ
МОСКВА ИЮЛЬ 2013 ГОД
Утверждаю
______________________
Согласовано
______________________
Техническое задание
на разработку автоматизированной Системы
«Планшет для неквалифицированного
пользователя»
(Рабочее наименование «Бабушка»)
Согласовано
______________________
Разработал
Белкин К.Р.
______________________

Экземпляр _________ неконтролируемая копия
ТЕХНИЧЕСКОЕ ЗАДАНИЕ НА ПРОЕКТИРОВАНИЕ СИСТЕМА БАБУШКА СТРАНИЦА: 2/15
История документа
Версия Дата Автор Комментарии
1 22/07/2013 Белкин К.Р. Разработка Технического задания
Контактные данные kbelkin@gmail.com
+7(985)411-30-52

Техническое задание на проектирование Система
Бабушка
1. Общие сведения
Полное наименование системы: Система «Планшет для неквалифицированного
пользователя».
Договор № ___ от дата_год
Наименование разработчика: ______ далее Разработчик.
Наименование Заказчика: ______________ далее Заказчик.
Создание системы осуществляется на основании настоящего Технического задания и частных
технических заданий, разрабатываемых при необходимости на базе настоящего ТЗ.
Плановые сроки начала работ: ___________.
Сведения о источнике финансирования: ___________ .
Порядок оформления и предъявления Заказчику результатов работ определен в разделе 6.
2. Назначение и цели создания системы
2.1 Назначение системы
Автоматизированная система Бабушка предназначена для:
Повышения комфортности и предоставления помощи при использования пожилыми людьми
современных цифровых устройств класса смартфон или планшетный компьютер.
2.2 Цели создания системы
1. Основная цель создания единой Системы для пожилых людей обеспечение комфортного
использования планшетного компьютера или смартфона (далее Планшета).
a. Специальное, гибкое, настраиваемое в широком диапазоне Интерфейсное решение
основной оболочки Планшета(далее Шелл, от eng.Shell).
b. Самовосстанавливающееся интерфейсное окружение Планшета осуществляемое
нажатием некой «Магической кнопки»,
c. Удаленное управление Планшетом в режиме реального времени, конфигурациями,
настройками и ПО.
2. Критерии оценки достижения целей, ранжированные по приоритетам:
• Принятие Интерфейсного решения программы оболочки П. Пользователем типа
Бабушка,
• Работоспособность, надежность и функционирования Системы,
• Доступность и простота подключения к Системе,
• Простота использования Системы,
• Низкие (нулевые) затраты подключения к Системе,
• Наличие в Системе дополнительных привлекательных платных сервисов.

3. Характеристика объектов автоматизации
3.1 Перечень объектов автоматизации
Роль 1 – Ведущий – Сын(Дочь, внук – «условно» взрослый компьютерно грамотный
пользователь П.)
Роль 2 – Ведомый – Бабушка (Дедушка, Мама, иные члены семей, не знакомые с компьютером
и/или П.)
Семья (групповой объект, включающий любое число любых объектов)
«Оператор HelpDesk» - сотрудник компании обслуживающей/владеющий Системой,
исполняющий функции удаленного и/или персонального помощника, как для объекта Сын так и
для объектов типа Бабушка. (Реализуется на последующих этапах развития Системы).
3.2 Условия эксплуатации
Система обеспечивает полную функциональность при нахождении терминала объекта (читай
Планшета) в зоне сети GSM, 2G/ 3G/ 4G/ LTE или иной мобильной, или беспроводной сети передачи
данных.
4. Требования к системе
Описание идеи – на правах Вводной части
Основная особенность трудностей использования – это в общем надуманные трудности двух типов:
• «Я в этом ничего не понимаю»,
• «Я боюсь сделать что то не так и сломать дорогую вещь».
Таким образом один из основных моментов, кроме решения технологических задач является
популяризация устройства как класса бытовой техники. Причем бытовыми оффлайн методами.
Разработка специализированного П. для пожилых, представляется сомнительным мероприятием
(если конечно не целится в Государственную или Федеральную программу). К примеру в Яндекс
Маркет представлены 2024 моделей планшетов, при этом 857 в ценовом диапазоне до 9900 руб.
Электронные книги в эти цифры не вошли, а на настоящее время половина из них имеют Андроид
«на борту».
Для разрешения технологической части проблемы предполагается достаточным иметь три
составляющих компонента:
1. Оболочка пользователя, то есть то что вызывается при старте П. и по кнопке Home.
2. Управляющая программа – аналог TeamView, плюс удаленное конфигурирование ПО из п.1,
включая установку и удаление программ и контента, создание ярлыков на «Главном экране»,
восстановление Шелл, изменение размеров шрифтов, громкости, цветовой гаммы и тому
подобное.
3. Веб Сервис обеспечивающий, регистрацию, авторизацию, конфигурирование, передачу
сообщений, хранение конфигурации, управление пользователями, выполнение команд –
восстановление разрушенной Системы или утраченного контента на П. Бабушка, доставку
сообщений, контента, фотографий или видео. И конечно же помощь Пользователю.
Несколько идей (которые частью могут быть отброшены и должны быть дополнены) для повышения
привлекательности разработки:
Если вы уже разработали Планшет для пожилых – ничего страшного, оболочку вы все равно
разрабатывали(уже разработали)) – сертифицируйте «чужие» Планшеты на совместимости с
Бабушкой.
Реклама по телевизору – «Я разговариваю с сыном/внуком по видео». «У меня всегда много
фотографий внуков», «Он не поцарапается в дамской сумочке и в сумке с картошкой то же»,
«У меня руки-крюки и я дважды в день роняю его со стола и раз неделю в суп и ничего ему не
делается».

Дизайн постера для подъезда любимой бабушки. Сын/внук распечатает его сам и сам же
повесит – готовя почву.
Кассета VHS или DVD для проигрывания фильма (имеется ввиду любимого бабушкиного
фильма) с рекламой Планшета.
Пожилые «Леди» работающие в ХелпДеске.
Устройство по умолчанию работает фоторамкой, к примеру через DropBox или 2Safe, для чего
предпочтения(сертификация) отдаются моделями с зарядкой-докстанцией.
При звонке по Скайпу (чему то иному) Пользователь «Сын» сам может нажать «принять
вызов», через ПО управления.
Планшет бабушки должен самостоятельно уметь присоединяться к любой беспроводной сети
WiFi, в том числе прокликивать кнопки типа Free WiFi Макдональдс «Соврите что вам есть 18
лет». Хотя лучше конечно установить у Бабушке в квартире и/или на даче WiFi.
4.1 Требования к системе в целом
4.1.1 Структура системы
Презентационный уровень.
Web-сайт визитка, руководство пользователя, описание Системы, репозитарий пакетов и
контента.
Сервисная часть
Ядро/Engine – База данных пользователей и их конфигураций,
Прикладное программное обеспечение,
Мобильные клиенты – Программное обеспечение оболочка устанавливаемое на Планшет
пользователей.
4.1.1.1 Web-сайт:
Отдельное частное ТЗ.
4.1.1.2 Ядро:
• База данных RDBMS или Ключ-значение
• Engine
o AAA (Authentication, Authorization, Accounting)
o Web-сервисы
o Message Queue
• Back office –
o АРМ Администратора Системы. Набор форм управления пользовательскими данными
и параметрами Системы, включая управление параметрами работы мобильных
приложений.
o Управление запросами пользователей (форум, хелпдеск, голосовалка, блог
разработчиков)
o АРМ Оператора HelpDesk
o Система тарификации и «биллинговая система» (разрабатывается на этапе 2)
4.1.1.3 Прикладноепрограммноеобеспечение:
• Web-приложение
• Android приложение(-я)
• iOS приложение(-я) – реализуется на 2 этапе.

4.1.1.4 ПодсистемаИБ:
Как выделенная система реализуется по мере необходимости, или в случае использования
государственным или корпоративным Заказчиком.
4.1.1.5 Комплекстехническихсредств:
• Служебные сервисы:
o Кэширование сессий
o Балансировка (Nginx)
o Mail сервис
o DDNS сервис
o …прочее…
• Система виртуализации или Облачная среда PAAS
• Вспомогательные сервисы:
o Сквозной мониторинг Системы
o Статистика
o Аналитика
o …прочее…
4.1.2 Информационный обмен между компонентами подсистем
В рамках работы по настоящему техническому заданию необходимо разработать Схему
функциональной структуры.
4.1.3 Режимы функционирования Системы
Предусматриваются следующие режимы работы системы:
• Нормальный режим работы – все функции обеспечиваются в полном объеме,
• Режим обновления (системного или базового ПО или смены версий прикладного ПО или
смена хостинг/cloud провайдера) – допустимо отсутствие части функционала на
непродолжительное (до 30 минут) время. Предусматривается оповещение пользователей на
портале и в приложении.
• Автономный (система не выполняет основные функции в результате аварии или отсутствия
сетевой связности, ведутся работы по восстановлению работоспособности. Пользователи
могут взаимодействовать в ручном режиме – через резервный SMS транспорт Мобильного
Приложения. Реализуется на втором этапе развития Системы.
4.1.4 Требования по мониторингу и само-диагностированию системы
Необходимо предусмотреть модуль само мониторинга Системы, ее составных частей и бизнес
процессов реализуемых Системой.
4.1.5 Перспективы развития Системы
Система имеет возможные перспективы развития или интеграции с параллельными модулями:
• Удаленный медицинский мониторинг,
• Вызов экстренной помощи,
• Радио-няня – средство мониторинга состояния, сна и двухсторонней связи с
престарелым/больным или ребенком на удалении по протоколу TCP/IP,
• Домашняя автоматика,
• Домашняя сигнализация,

• ect...
4.1.6 Пользователи Системы
4.1.6.1 ПользователемСистемыможетбыть
• Пользователь Планшета предоставленного родственниками или опекунами с
предустановленным ПО Системы, не имеющий навыком пользования компьютерными
устройствами,
• Владелец Планшета или смартфона, поддерживающего перечу данных по IP, и возможность
установки программного обеспечения Мобильный программное обеспечение Системы,
• Пользователь персонального компьютера, подключенного к публичной сети Интернет.
4.1.6.2 Численностьпользователейсистемы
На этапе пилотного развертывания 1000 пользователей,
На этапе тестового развертывания до 100 000 пользователей,
Целевая (плановая, максимальная) численность 32 000 000 пар пользователей.
В соответствии со статистикой «Число лиц старше трудоспособного возраста в России с 2006
года постоянно растет и на начало 2012 года составило 32,4 миллиона человек или 22,7% от
общего населения. Численность лиц старше трудоспособного возраста сегодня на 8,9
миллиона человек превышает численность лиц моложе трудоспособного возраста» ©
Вовченко, Минтруд.
4.1.6.3 Режимработыпользователей
Пользователи работают во все часовых поясах страны назначения – Россия.
Численность распределения пользователей в соответствии с процентным распределением
численности населения страны.
Рабочее время Системы – круглосуточно.
Распределение нагрузки пользователей на Систему
• Пик с 8 часов локального времени нарастание до 70% в течении часа
• Снижение нагрузки до 18 часов до уровня 50%
• Снижение нагрузки до 22 часов до уровня 10%
• Снижение нагрузки до 00 часов до уровня 5% .
Уточненный расчет нагрузки по часовым поясам и элементам Системы – см. Методология расчета
нагрузки, количества пользователей информационной системы — web-сайта или сервиса.
4.1.7 Показатели назначения
Разрабатываются и уточняются в процессе работы над проектом.
Сервисная часть Системы разрабатывается в отказо-устойчивом исполнении с учетом размещения
на хостинг инфраструктуре типового Cloud провайдера.
То есть все части Системы должны быть способны размещаться:
• на виртуальных машинах,
• иметь способность к горизонтальному масштабированию,
• иметь способность к созданию региональных реплик Системы.

4.2 Требования к функциональности системы
На уровне функционирования Система состоит из Ядра – База данных и Engine и Мобильных
Приложений.
Ядро Системы реализует функционал:
• предоставление доступа пользователям к услугам системы при помощи:
o Мобильного приложения Android,
o Мобильного приложения iOS,
o Интернет браузера,
• прием, хранение и обработку сообщений ;
• прием и обработку команд управления.
Реализация Системы по принципу «Приложения приходят и уходят – Базы данных остаются».
То есть максимально весь функционал Системы реализуется в Базе данных на уровне:
• Структуры
• Связей
• Представлений
• Хранимых процедур.
• WEB сервисов.
Приложения работают с Ядром системы посредством вызовов WEB сервисов API ядра.
Принцип построения и работы систем основывается на ряде общих постулатов – все взаимодействия
подсистем и модулей – сетевое, асинхронное.
Подтверждение о приеме передаче данных не производится в большинстве случаев.
Сведения о параметры времен ожидания, периодов повторения операций (запросов к серверам),
условия проверок (выполняется не выполняется) хранится в файле конфигурации приложения
который приложение должно загружать с сервера при старте.
4.2.1 Подсистема Портал
Подсистема Портал обеспечивает следующий перечень функций:
• Преставление информации о сервисе (Сайт/Визитка/Витрина)
• Возможность работы с основными функциями Системы для Пользователя (Кабинет)
o Возможность «регистрации» пользователей в Системе (авторизации из
распространенных соцсетей)
o Конфигурирование Сервиса, Пользователей, Группы (Семьи) добавление исключение
пользователей, изменение информации профиля пользователя, изменение прав
доступа, рассылка сообщений.
• Функции управления Пользователями, Сервисами и Правами.
4.2.2 Подсистема База данных
Осуществляет
Хранение пользовательских данных (UsersDB)– примерная номенклатура:
Поле Описание
UID Уникальный идентификатор пользователя
Type Тип пользователя см.4.1.7
Email Не уникальное поле
Логин Не уникальное поле 1…9 a…z (пара Логин Email – уникальная пара)
Name Текст русский
Password
ID_Groups возможно членство в разных группах
TimeZone

CellPhone +7(123)123-45-67 отдельная таблица UID <=> телефоны
Field_1 Фамилия – поле не используется, но присутствует изначально в
структуре данных (отсыл к закону о защите персональных данных)
Field_2 Имя – не используется
Field_3 Отчество – не используется
Field_4 Страна – не используется
Field_5 Город – не используется
Field_6 Адрес – не используется
DateBD День рождения
DateStart Дата регистрации в сервисе
Phone_ID Тип/модель устройства
Адрес
И далее… Поля и связи определить при проектировании.
Таблица Группы
ID_Groups
Groups_Name
Descr Описание
Таблица Членство
в Группе
ID_Groups Много ко
UID многим
Role к одному
Требование к реализации Подсистемы Базы данных.
При проектировании подсистемы необходимо
• Предусмотреть:
o Возможность как вертикального так и горизонтального масштабирования подсистемы.
• Рассмотреть:
o Реализацию сервиса очередей как надстройки над Базе данных,
o Реализацию WEB сервисов как надстройки над Базой данных.
4.2.3 Подсистема Engine
Обеспечивает:
Авторизацию пользователя мобильного терминала или устройства, выдачу сессионного ключа,
Обеспечение легитимизации сессии связи для передачи/запроса/получения данных
Передачу сообщений П2П, С2П и П2С (между пользователями и пользователями и Системой).
4.2.4 Вспомогательные служебные сервисы
4.2.4.1 Mail
Отправка почтовых сообщений.
Прием почтовых сообщений и перенаправление их на почтовый сервер Оператора Системы.

Реализуется как аренда почтового сервиса у провайдера/регистранта или Gmail.
4.2.4.2 DDNS
Не реализуется на первом этапе. Следует иметь ввиду возможность его применения – если
технологически будет востребован.
4.2.4.3 Мониторинг
Модуль мониторинга должен обеспечивать «безагентскую» (SNMP) и WEB технологию
мониторинга основных функций Системы методом полной имитации работы пользователей в
Системе с замерами качественных показателей (время реакции) и возможностью сообщения о
состоянии Системы или аварии на адрес электронной почты.
А так же визуализацию всего ПАК и Бизнес логики Системы в WEB интерфейсе.
4.2.4.4 Статистика
Подсистема WEB статистики для интернет должна быть реализована на базе пакета.
Часть специальной, аналитической бизнес статистики реализуется хранимыми процедурами
Базы данных и интегрируется в BackOffoce отдельными WEB формами. При развитии Системы
возможно реализация при помощи систем класса BI.
4.3 Приложение клиент (iOS, Android, Web) Общие требования
Базовой системой для описания выбрана ОС Android.
4.3.1 Приложение Android
Для указанной платформы должно быть разработано 2 типа приложений связанных с друг другом
• Шелл – оболочка пользователя по отдельному дорогому и сложному ТЗ основное внимание в
котором должно быть уделено вопросам Психологической проработке концепции управления
и дизайна, к примеру в виде книги. Подробно вопросы проектирования рассмотрены в
Источниках разработки.
• Программа управления удаленным Шелл-ом. Обеспечивающая полное управление
удаленным устройством – как в режиме online, так и пакетно-командным методом через ядро
системы.
Основные функции Программы управления:
• Удаленное конфигурирование устройства,
• Установка и переустановка ОС удаленного устройства,
• Подключение к удаленному устройству в режиме Удаленный Десктоп и удаленный Viewer,
• Поиск местонахождения удаленного устройства,
• Телефонный или VOIP или Видео звонок на удалённое устройство, в том числе удаленный
прием звонка,
• Загрузка контента на удаленное устройство.
4.3.2 WEB сайт Системы
Отдельное частное ТЗ. Функционал WEB сайта должен пересекаться с функционалом управляющего
приложения.

4.4 Требования к видам обеспечения
5. Состав и содержание работ по созданию системы
5.1 Стадии и этапы работ
5.1.1 Прототипирование
Цель этапа:
создать программно-аппаратное решение, обеспечивающее демонстрацию основных
возможностей Системы в реальном времени на реальных терминалах для того, чтобы привлечь
инвестиции, необходимые для полноценного запуска и продвижения Системы.
Результат:
• Функционируют:
o Ядро,
o сайт-визитка,
o Web-приложение управление Планшетом Бабушка,
o iOS-приложение доступно на АппСторе
o Android-приложение доступно на Гуглоплее,
• Разработан прототип Оболочки Бабушка
• Разработан комплект технической документации на Систему
• Разработан комплект инвестиционных документов
o финансовая модель,
o бизнес план,
o стратегия инвестиций
o презентационные материалы
• Разработан маркетинговая стратегия (план, описание ЦА, бюджет)
• Разработан перечень мероприятий по обеспечению ИБ
• Сформирована проектная команда. Отлажена процедура взаимодействия.
Ограничения:
• Не более 1000 одновременных пользователей.
• Ограничения на объем услуг установлены.
• Сервисы встроенных покупок не реализованы.
• Маркетинговое продвижение не предусмотрено.
5.1.2 Опытная эксплуатация
Вывести полнофункциональную Систему на массовый рынок, обеспечив ей маркетинговую
поддержку.
Результат:
• Инвестор в проект вошел.
• Разработка завершена. Все подсистемы, заявленные в ТЗ, функционируют в полном
объеме. Ограничений по количеству пользователей нет.
• Проведены и продолжаются мероприятия, предусмотренные маркетинговым планом
• Мобильные приложения доступны на AppStore и GooglePlay
Ограничения:
• Прочие языковые сегменты не реализованы

5.1.3 Промышленная эксплуатация.
Извлечь прибыль, определенную инвестиционным планом.
Результат:
• Клиентское приложение адаптировано на все разумно необходимые платформы.
• Набор функций разумно увеличивается
• Языковые сегменты подключаются в соответствии с планом
Этапы работ
№
этапа
Стадия Этап Описание Сроки Исполнит
ель
1. Подготовительная Обследование.
Формирование
требований.
Разработка
Концепции.
Дата Ч
2. Прототипирование Разработка ТЗ Разработка и
согласование
Технического задания на
Систему.
Дата Ч +
2 недели
3. Разработка ЧТЗ на
подсистемы
Мобильные приложения
Android, iOS.
WEB сайт.
Ядро Системы.
Дата Ч +
1 месяц
4. Поднятие хостинга
и вспомогательных
инструментов
Jelastic
GitHUB
Моделирование данных
etc
Дата Ч +
2 месяца
5. Макетирование Развертывание Ядра
системы
Дата Ч +
2 месяца
6. API Системы Передача разработчику
описание Интерфейсов
Ядра
Дата Ч +
2 месяца
7. Разработка и
реализация WEB
сайта.
Дата Ч +
2 месяца
8. Тестирование Разработка
приложения iPhone
9. Разработка
приложения iPad
приложения
Android Smartfon
приложения
Android планшет

5.2 Технология производства работ
Требования к производству работ по разработке Системы включают в себя:
1. Использование всеми исполнителями облачной структуры Amazon, Jelastic или иные
развитые облачные среды с целью минимизации эксплуатационных, административных и
управленческих затрат на Пилотном и Тестовом этапах.
2. Регистрация и передача заказчику Аккаунтов разработчика в Репозитариях Apple iTunes и Play
Google.
3. Использование при разработке GIT репозитария. Доступ к репозитарию Заказчика.
4. Реализация автоматизированной процедуры выкладки и сборки из GIT Системы на Тестовую
и Продуктивную версию Системы.
5. Реализация автоматизированной сборки Приложений из Git.
6. Реализация процедуры замены(Swap – быстрого переключения) Тест – Продуктив и откат
версий.
7. Использование Case средств и передача Заказчику исходных материалов при
проектировании и разработке
• Баз данных
• Интерфейсов программных модулей
• Функционального поведения Системы и дизайна
8. Комментирование программного кода не ниже 1/20 (обсуждаемо / субъективная оценка).
6. Порядок контроля и приемки системы
7. Требования к составу и содержанию работ по подготовке объекта
автоматизации к вводу Системы в действие
Требования и порядок ввода Системы в действие требуется разработать в процессе
проектирования Системы и подсистем.
Ответственность за разработку – в порядке приоритета:
Главный конструктор,
Руководитель проекта.
8. Требования к документированию
Требования к документированию вырабатываются и согласовываются с каждым Исполнителем
отдельно – с учетом объема выполняемых им работ.
Рекомендованный минимальный состав:
1. Схема Функциональная.
2. Описание комплекса технических средств.
3. Схема организационной структуры.
4. Методика Примо-сдаточных испытаний Комплексная.
5. Методика Примо-сдаточных испытаний составляющий подсистем.
6. Описание API Системы. Инструкция для разработчика Мобильного приложения.
7. Частное техническое задание на Интернет часть Системы.
8. Частное техническое задание на Моюильное приложение Бабушка.
9. Инструкция по эксплуатации – администрирование Системы.
10. Инструкция по пуско наладке Системы.
11. Инструкция по резервному копированию и восстановлению Системы.

12. Инструкция пользователя Бабушка. Буклет – твердая копия 1 лист А4, плотность упаковки
информации 8 бод. Книжка, твердая копия, подробная инструкция – в формате комикса-
русской народной сказки. Видео мультфильм(Диафильм) с ритмом передачи информации
1937 года.
13. Инструкция пользователя Сын.
14. Кейсы по Применению системы для Сына.
15. Промо ролики для Дом-2 или Утренняя зорька или что там они смотрят.
16. Постеры для подъезда – она(старушка) болтает с внуком по Планшету.
И уже совсем Опционально
17. Инвестиционный меморандум.
Приложения к нему
18. Бизнес план.
19. Кеш флоу.
20. Презентация для инвестора.
9. Источники разработки
1. Планшет для пожилых. Часть первая. Часть вторая.
10. Приложения
10.1 Приложение 1. Термины и определения
Термин или сокращение Расшифровка или определение
Мобильный терминал Мобильный(или сотовый) телефон переносное
средство связи, предназначенное
преимущественно для голосового общения,
обладающий способностью установки
Мобильного приложения Системы.
Смартфон Мобильный телефон оснащенный достаточно
развитой операционной системой (iOS, Android,
Windows Phone и др.), открытой для разработки
программного обеспечения сторонними
разработчиками.
Планшет (Интернет планшет) Интернет-планшет (англ. Internet tablet или Web
tablet — Веб-планшет, или Pad tablet — Pad-
планшет (Блокнотный планшет), или Web-pad —
Веб-блокнот, или Surfpad — Веб-серфинг-
блокнот) — одним словом Планшет – мобильный
компьютер, относящийся к типу планшетных
компьютеров с диагональю экрана как правило от
7 до 12 дюймов, построенный на аппаратной
платформе того же класса, которая используется
для смартфонов. Для управления интернет-
планшетом используется сенсорный экран,
взаимодействие с которым осуществляется при
помощи пальцев, без использования физической
клавиатуры и мыши.
П. как правило, имеют возможность быть
постоянно подключёнными к сети интернет —

через Wi-Fi или 3G/4G-соединение.
ПАК Программно-аппаратный комплекс

2013 07-22 тз-пожилая-система

More Related Content

Featured

2013 07-22 тз-пожилая-система