Чтз это техническое задание

Содержание

Написание технического задания для разработки сайта

Опубликовано: Июнь 30, 2014 в 5:18 пп

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

Грамотно составленное ТЗ позволяет в дальнейшем избежать спорных ситуаций и намного ускоряет процесс создания сайта. Ведь постоянно связываться для уточнения той или иной детали гораздо дольше и трудозатратнее, чем один раз в начале работы указать все пожелания. Поэтому чем конкретнее и полнее техническое задание, тем легче будет обеим сторонам контролировать ход его выполнения. Соответственно, тем выше вероятность, что и заказчик, и исполнитель останутся довольны сотрудничеством.

Что должно включать в себя техзадание?

Какого-то универсального шаблона ТЗ не существует. В этом вопросе многое зависит от специфики веб-ресурса и уровня доверия между сторонами. Главное правило можно сформулировать так: хорошее техническое задание должно охватывать все аспекты, касающиеся будущего сайта — его цели, задачи, тематику, функционал, дизайн и т.д.

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

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

Детализация технического задания должна быть максимально высокой.

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

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

  1. Описание компании-заказчика (продукция, услуги, время существования на рынке и т.д.)
  2. Аудитория сайта (характеристика трафика; кого мы хотим привлечь на сайт и какие действия мы ожидаем от пользователей — просмотр информации, звонок в компанию, онлайн-покупка и пр.)
  3. Задачи сайта (продажи, сервисное сопровождение клиента, информирование о продукции)
  4. Тип сайта (интернет-магазин, корпоративный портал, сайт-визитка)
  5. Функционал (перечень страниц, технических средств и модулей, служащих для достижения заданных целей)
  6. Структура и навигация (разделы сайта, основное меню и подменю, пути перемещения пользователя по внутренним страницам)
  7. Описание модулей и страниц (макеты страниц, дизайн, графика, количество и содержание полей форм обратной связи, виджеты, регистрация и проч.)
  8. Техническая информация («движок сайта», хостинг, совместимость с разными браузерами и операционными системами, требования к администрированию)

Нюансы написания ТЗ

Процесс написания ТЗ становится намного проще и эффективнее, если заказчик сам хорошо представляет, что он хочет в итоге получить. Чем яснее он будет видеть будущий сайт, тем лучше сможет донести задачу до разработчика. Поэтому еще на стадии планирования задания рекомендуется продумать по возможности как можно больше деталей.

  • Хорошее техническое задание имеет последовательную логическую структуру. Каждый следующий пункт должен служить продолжением предыдущего и в то же время быть четко разграничен — это важно для контроля над ходом разработки.
  • Ни в коем случае в ТЗ не должно присутствовать субъективно-оценочных условий вроде «удобный интерфейс», «привлекательный дизайн» и тому подобного.
  • Задание лучше точно распределять по специалистам. Дизайнер, программист, верстальщик и другие участники разработки должны знать свой фронт работы и выполнять то, что входит в их компетенцию.
  • Составлять ТЗ лучше на основе анализа сайтов конкурентов. Желательно привести 2-3 примера решений, которые нравятся заказчику, и 2-3 примера неудачных, на его взгляд, сайтов. В этом случае исполнитель будет точнее понимать рамки задачи.
  • Каждый элемент страницы следует описывать именно так, как его видит заказчик. Например, виджет погоды или курсов валют нужно заказывать с пояснением, откуда следует брать информацию, в каком графическом виде ее представить, какие именно города или валюты требуется указать.

Если заказчик не имеет точного представления о желаемом результате или конкретные детали для него не важны, то можно довериться вкусу исполнителя. Но в этом случае многие претензии по итогу работы будут необоснованными.

Кто должен писать ТЗ?

Техническое задание может составить и сам заказчик. Но в большинстве случаев лучше делегировать эту миссию разработчику, который в силу опыта знает больше тонкостей и может предусмотреть больше нюансов.

Разработчик в 99% случаев может составить ТЗ более грамотно, так чтобы не только клиент, но и программисты полностью понимали условия задачи. Как вариант, схема сотрудничества может выглядеть следующим образом:

  1. Заказчик обрисовывает общие пожелания, кратко описывает свой бизнес и сообщает, для каких целей ему нужен сайт.
  2. Исполнитель составляет примерный вариант техзадания, указывая в нем ключевые параметры.
  3. Затем стороны совместно вносят поправки и оговаривают подробности.
  4. Исполнитель пишет окончательный вариант ТЗ и после полного согласования приступает к основной работе.
  5. После выполнения каждого пункта заказчик проверяет ход разработки, корректирует и направляет процесс.

Написание технического задания для сайта — это обоюдная работа, в которой важно взаимопонимание и доверие между сторонами. Постоянный конструктивный диалог и общий поиск решений — залог успешной реализации самого сложного и технически нагруженного проекта.

Категория:Информационные технологии

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

И насколько скрупулезно обе стороны подойдут к этому этапу работ, настолько будет более точным, правильным, ожидаемым и быстрым результат проекта.
Что ж попробуем разобраться. Давайте для начала все-таки определимся, что же такое техническое задание?
Техническое задание (ТЗ) — исходный документ на проектирование технического объекта (изделия). ТЗ устанавливает основное назначение разрабатываемого объекта, его технические характеристики, показатели качества и технико-экономические требования, предписание по выполнению необходимых стадий создания документации (конструкторской, технологической, программной и т. д.) и её состав, а также специальные требования.
Можно сказать, что ТЗ — документ, в котором описывается, ЧТО нужно заказчику, в отличие от последующей проектной документации, в которой акцент переносится на ответ на вопрос, КАК этого достичь.
(Материал из Википедии).
Данное определение, на мой взгляд, полностью раскрывает суть термина. Итак, основное назначение ТЗ полностью раскрыть и описать все требования, предъявляемые к желаемому результату заказчиком. От того, как сформулированы эти требования, зависит успех или неуспех проекта. И на данном этапе заинтересованность в успехе должны проявлять максимально обе стороны. Заказчик – чтобы потратить меньше средств на переделку неудачного проекта, исполнитель – чтобы меньшими усилиями успешно завершить проект и получить прибыль. И как раз на этом этапе возникает резонный вопрос: кто должен писать данный документ?
С одной стороны, казалось бы, это должен делать заказчик, т.к. он и только он полностью знает, что же он хочет видеть в результате. Но сможет ли данная сторона, не обладая техническими знаниями в области разработки программного обеспечения, корректно изложить все свои требования? Провести их анализ на предмет того, что каждое требование должно быть понятным, конкретным, тестируемым, как того требуют правила составления ТЗ. «Хочу кнопку красного цвета, дающую точные данные по продажам за месяц!». Наверное, ничего вразумительного на основе данного ТЗ исполнитель не реализует.
Тогда ТЗ должен писать сам исполнитель? Тоже не идеальный вариант. Исполнитель, получив от заказчика изложение задачи, может интерпретировать её немного в ином русле, как понимает задачу сам. И сухой технический язык, на котором будут изложены все понятые исполнителем требования, не даст ответа заказчику – то ли он имел в виду, описывая желаемый результат. Особенно комично выглядит ситуация, когда на стол руководителя заказчика попадает документ, изобилующий технической терминологией, специфическими словами, зачастую на английском языке, который он должен подписать и, соответственно, подтвердить, что всё написанное это то, что они и просили!
Поэтому наиболее оптимальный вариант – это работа в тандеме. Именно при полном погружении исполнителя в предметную область заказчика, разговор на одном языке при построении списка требований, когда сходятся воедино язык потребителя-неспециалиста и язык разработчика, рождается документ, на основании которого будет создан продукт, максимально приближенный к исходной поставленной цели. Такой синтез даст обеим сторонам полное понимание описываемого процесса. Не будет сомнений в том, что какая-то часть технического документа осталась «белым пятном» и во что эта часть превратится в результате.
Да, написание ТЗ сложная задача, но лучше временные инвестиции вложить в данный этап, нежели найти брешь и выяснить, что нужно переделывать фундамент, когда пришло время положить крышу.
И главное, перед тем, как создавать документ, заказчику нужно понять, что именно он хочет видеть в результате, а исполнителю – отказаться от реализации невыполнимых требований.
Успешных вам проектов!


Обновление модели конструкции «ЭСПЦ Агрегат печь-ковш» поможет улучшить про …

MicroXperts продемонстрировал IT-директорам Санкт-Петербурга возможности ов …

СТАДИИ РАЗРАБОТКИ ПРОГРАММ И ПРОГРАММНОЙ ДОКУМЕНТАЦИИ

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

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

 

Стадии разработки ПО по ГОСТ 19.102-77:

 

1. стадия «Техническое задание» — соответствует постановке задачи

Эта стадия содержит:

· постановку задачи

· выбор критериев эффективности

· проведение предварительных научно-исследовательских работ

· разработка ТЗ

 

2. стадия «Эскизный проект» — соответствует анализу требований и разработке спецификаций

Эта стадия содержит:

· структура входных и выходных данных

· уточнение методов решения

· общий алгоритм

· разработка документации эскизного проекта

 

3. стадия «Технический проект» — соответствует этапу ЖЦ ПО проектирование

Эта стадия содержит:

· уточнение структуры входных и входных данных

· разработка алгоритмов

· формы данных

· семантика и синтаксис языка

· структура программы

· конфигурация технических средств

· план работ

 

4. стадия «Рабочий проект» — этап – реализация.

Эта стадия содержит:

· программирование и отладка

· разработка документов

· подготовка и проведение испытаний

· корректировка программы и документов по итогам испытаний

 

5.стадия «Внедрение»

· передача программы и документов для сопровождения

· оформление акта

· передача в Фонд алгоритмов и программ.

 

 

РАЗРАБОТКА ТЕХНИЧЕСКОГО ЗАДАНИЯ

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

Существуют факторы, определяющие характеристики разрабатываемого ПО. Это:

· исходные данные и требуемые результаты, которые определяют функции программы или системы;

· среда функционирования (программная и аппаратная) – может быть задана, а может выбираться для обеспечения параметров, указанных в техническом задании;

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

 

Разработка ТЗ выполняется в следующей последовательности: устанавливается набор выполняемых функций, перечень и характеристики исходных данных; определяется перечень результатов, их характеристики и способы представления; уточняется среда функционирования ПО (конкретная комплектация, параметры технических средств, версию ОС, возможно, версии и параметры другого установленного ПО, с которым предстоит взаимодействовать). Если ПО собирает и хранит некоторую информацию или включается в управление каким-либо техническим процессом, необходимо четко регламентировать действия программы в случае сбоев оборудования и энергоснабжения.

На ТЗ существует стандарт ГОСТ 19.201-78 «Техническое задание.

Требования к содержанию и оформлению». В соответствии с этим стандартом ТЗ должно содержать следующие разделы:

· введение;

· основания для разработки;

· назначение разработки;

· требования к программе или программному изделию;

· требования к программной документации;

· технико-экономические показатели;

· стадии и этапы разработки;

· порядок контроля и приемки.

 

Введение должно включать наименование и краткую характеристику области применения программного продукта, а также объекта (например, системы), в котором предполагается их использовать. Основное назначение введения – продемонстрировать актуальность данной разработки и показать, какое место эта разработка занимает в ряду подобных.

Основание для разработки должен содержать наименование документа, на основании которого ведется разработка, наименование организации, утвердившей данный документ, и наименование или условное обозначение темы разработки. Таким документом может служить план, приказ, договор.

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

Требования к программе или программному изделию должен содержать следующие подразделы:

· требования к функциональным характеристикам;

· требования к надежности;

· условия эксплуатации;

· требования к составу и параметрам технических средств;

· требования к информационной и программной совместимости;

· требования к маркировке и упаковке;

· требования к транспортированию и хранению;

· специальные требования.

Наиболее важным является подраздел «Требования к функциональным характеристикам». В этом разделе должны быть перечислены выполняемые функции и описаны состав, характеристики и формы представления исходных данных и результатов. В этом же разделе модно указать критерии эффективности: максимально допустимое время ответа системы, максимальный объем используемой оперативной или внешней памяти.

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

В подразделе Условия эксплуатации указывают особые требования к условиям эксплуатации: температуре окружающей среды, относительной влажности воздуха и т.п.

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

В подразделе Требования к составу и параметрам технических средствуказывают необходимый состав технических средств с указанием их основных технических характеристик: тип микропроцессора, объем памяти, наличие внешних устройств. При этом часто указывают два варианта конфигурации: минимальный и рекомендуемый.

В подразделе Требования к информационной и программной совместимостипри необходимости можно задать методы решения, определить язык или среду программирования для разработки, а также используемую ОС и другие системные и пользовательские программные средства, с которыми должно взаимодействовать разрабатываемое программное обеспечение. В этом же разделе при необходимости указывают, какую степень защиты информации необходимо предусмотреть.

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

В разделе Технико-экономические показатели рекомендуется указывать ориентировочную экономическую эффективность, предполагаемую годовую потребность и экономические преимущества по сравнению с существующими аналогами.

В разделе Стадии и этапы разработкиуказывают стадии разработки, этапы и содержание работ с указанием сроков разработки и исполнителей.

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

В приложенияхпри необходимостиуказывают перечень научно-исследовательских работ, обосновывающих разработку; схемы алгоритмов; таблицы; описания, обоснования, расчеты и другие документы, которые следует использовать при разработке.

Если какие-либо требования предусмотренные ТЗ, заказчик не предъявляет, следует указать «Требования не предъявляются».

 


Читайте также:

Поиск Лекций


ЭТАП 1: РАЗРАБОТКА ТЕХНИЧЕСКОГО ЗАДАНИЯ

Тема 3.

ОПРЕДЕЛЕНИЕ ПРОЕКТА

 

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

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

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

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

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

 

ЭТАП 1: РАЗРАБОТКА ТЕХНИЧЕСКОГО ЗАДАНИЯ

 

Разработка технического задания (ТЗ) готовит почву для разработки плана проекта. Техническое задание — это определение конечного резуль­тата или цели вашего проекта — товара или услуги для вашего заказчика. Основной целью здесь является как можно более четкое определение про­межуточных результатов работы для конечного пользователя и концент­рация (в единое целое) планов проекта. Хотя разработка технического за­дания является фундаментально важной, руководители проектов крупных корпораций с хорошим менеджментом часто поверхностно относятся к данному этапу.

Исследования показывают, что плохая разработка технического зада­ния является наиболее частой преградой на пути к успеху проекта. Изуче­ние проекта строительства большого нефтеперерабатывающего завода, проведенное Смитом и Таккером, показало, что плохая разработка техни­ческого задания и нечеткое определение основных составляющих проек­та самым отрицательным образом сказались на его стоимости и графике работ. Пинто и Слевин доказали, что четкое определение целей больше, чем на 50% предопределяет успех на стадии формулирования концепции, планирования и выполнения проекта. Эшли и другие продемонстрирова­ли, что у выдающихся, успешных проектов были четко разработаны тех­нические задания и определены составляющие работы. Анализ Познера выявил, что, по мнению 60% респондентов-управляющих проектами, ос­новной проблемой является отсутствие четких целей.

В ходе работы с более, чем 1400 управляющими проектами в США и Канаде Гобелай и Ларсон установили, что около 50% проблем планирова­ния связаны с нечетким техническим заданием и постановкой целей. Все эти результаты указывают на прямую зависимость успеха проекта от чет­кого определения его ТЗ. Четкое ТЗ заставляет как заказчика, так и всех участников проекта концентрироваться на целях проекта.

ТЗ должно разрабатываться под руководством управляющего проек­том и клиента. Управляющий проектом должен согласовывать с заказчи­ком цели, промежуточные результаты работы на каждой стадии проекта, технические требования и т.д. Так, например, промежуточным результа­том на ранней стадии проекта может быть разработка документации; на второй стадии — три образца продукта; на третьей — значительное коли­чество товаров для выпуска на рынок и, наконец, продвижение товара на рынке и обучение персонала.

Разработка технического задания на проект — это документ, который будет соответственно оформлен и использован владельцем проекта и уча­стниками проекта для планирования и измерения успеха проекта. ТЗ объяс­няет, какую продукцию вы поставите своему клиенту по завершении про­екта. ТЗ вашего проекта должно представлять намеченные результаты в конкретном и поддающемся измерению виде.

Очевидно, что ТЗ — это краеугольный камень, к которому привязаны все элементы плана проекта. Для того чтобы убедиться в правильности ТЗ, можно использовать следующий контрольный перечень:

Перечень вопросов по ТЗ:

1. Цели проекта.

2. Промежуточные результаты работы.

3. Контрольные точки.

4. Технические требования.

5. Ограничения и исключения.

6. Проверка выполнения работы совместно с клиентом.

1. Цели проекта. Первым этапом в определении ТЗ является опреде­ление основных целей для удовлетворения потребностей клиента. Например, в результате глубокого анализа рынка компания, зани­мающаяся компьютерными программами, решает разработать про­грамму, способную автоматически переводить с английского на русский. Проект должен быть выполнен за три года при затратах, не превышающих $1,5 млн. Или такой проект — спроектировать и выпустить полностью портативную систему термической перера­ботки вредных отходов за 13 месяцев при затратах, не превышаю­щих $13 млн.

2. Промежуточные результаты работы. Следующим этапом являет­ся определение промежуточных результатов работы на протяже­нии всего жизненного цикла проекта. Так, например, промежуточ­ным результатом работы на самой ранней стадии разработки про­екта может быть список спецификаций. На следующем этапе это может быть испытание образцов. Последним этапом может быть окончательное испытание и одобренная программа. Промежуточ­ные этапы работы обычно включают время, количество и/или оцен­ки затрат.

3. Контрольные точки. Контрольная точка — это значительное ме­роприятие в процессе работы над проектом, которое происходит в определенный момент времени. График контрольных точек отра­жает только основные сегменты работы; он показывает первую, приблизительную оценку затрат времени, стоимости и необходи­мых ресурсов для проекта. Этот график составляется с использо­ванием промежуточных результатов работы, как основы для опре­деления основных сегментов работы и конечной даты. Например, испытания проведены и полностью выполнены к 1 июля этого года. Контрольные точки должны быть естественными и важными точ­ками контроля. Они должны быть понятны всем участникам про­екта. График контрольных точек должен установливать, какие ос­новные подразделения организации будут отвечать за основные сегменты работы и обеспечивать проект необходимыми ресурса­ми и специалистами.

4. Технические требования. Обычно товар или услуга для того, что­бы хорошо работать, должны отвечать техническим требованиям. Например, техническим требованием к ПК может быть способ­ность работать от сети переменного тока в 120 вольт или от посто­янного тока в 240 вольт без адаптеров. Еще одним известным при­мером является способность системы 911 определить местонахож­дение и номер телефона звонящего.

5. Ограничения и исключения. Следует четко определить границы ТЗ. Невыполнение этого требования приведет к пустым ожиданиям и тра­те ресурсов и времени. Примером такого ограничения является сбор данных клиентом, а не подрядчиком; какой нужно построить дом, а не то, как он вписывается в пейзаж, или какие приборы, обеспечива­ющие охрану и безопасность, нужно установить; какие программы нужно ввести, а не какую подготовку дать персоналу.

6. Проверка выполнения работы совместно с заказчиком. Кон­трольный список вопросов ТЗ проекта заканчивается совместной с заказчиком проверкой выполнения работы. Основной проблемой является понимание и согласие заказчика с ожидаемыми результа­тами. Получает ли заказчик в виде промежуточных результатов то, что он хочет? Указывает ли определение проекта ключевые достиже­ния, сметы, сроки и требования к выполнению работ? Рассматрива­ются ли вопросы ограничений и исключений? Обсуждение всех этих вопросов крайне необходимо во избежание недопонимания.

Тесное сотрудничество с вашим заказчиком необходимо для разработки такого ТЗ проекта, которое бы удовлетворяло всем требовани­ям заказчика. Также хорошее ТЗ будет вам необходимо, если вдруг что-то начнет меняться. Четкое определение ТЗ проекта является необходимым условием для структурирования работ по этапам. ТЗ дает административ­ный план, который используется при разработке вашего оперативного пла­на. ТЗ должно быть кратким, но полным; для малых проектов это обычно одна-две страницы.

©2015-2018 poisk-ru.ru
Все права принадлежать их авторам. Данный сайт не претендует на авторства, а предоставляет бесплатное использование.
Нарушение авторских прав и Нарушение персональных данных

Добавить комментарий

Закрыть меню