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

На этапе ТЗ у нас обычно уже есть в наличии прототип и результаты SEO аудита. Поэтому ТЗ у нас состоит из 4х частей:

Часть 1. Описание структуры сайта и структуры основных сущностей (пользователь, новость, товар и так далее). Это не описание структуры БД, а перечень полей, их тип и связи между ними. Например — «заголовок новости: строка». В таком виде описание понятно и программисту, и заказчику.

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

Часть 3. Администрирование и сервисы. Эту часть ТЗ очень часто упускают (но не мы). В ней содержатся требования к администрированию сайта и такие описания как алгоритм подбора и поиска, алгоритм вывода краткого набора атрибутов товаров на уровень списка, алгоритм попадания товаров в блоки Рекомендуемые и так далее. Также в этой части ТЗ описываются внешние интеграции, всевозможные уведомления, реакция на исключительные ситуации (например, ошибки при заполнении форм) и многое другое. Заказчик зачастую изначально полагается на опыт разработчика, а разработчик делает как проще. Но на этапе запуска сайта это всплывает и вызывает много негативных эмоций. Поэтому лучше потратить время, все детально расписать и разъяснить.

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

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

Как программисту лишиться работы. 5 способов от руководителя IT-студии

Сооснователь Alef Development Стас Гольденшлюгер рассказал, почему программисты теряют работу и дал советы, как этого избежать.

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

Почему так неправильно. Часто менеджер знает о проекте больше, чем программисты. Кроме того, в машине должен быть один водитель: если левыми и правыми колесами управляют разные люди — машина не приедет в назначенную точку в нужное время.

Пример. Менеджер просит сделать комнату с дверью. Но по ТЗ в двери нет ручки, вместо нее педаль. Программист видел в жизни тысячи дверей и решает, что менеджер сошел с ума. Он пытается спорить, а потом делает «правильно». Его увольняют.

Программиста уволили, потому что:

1. это дверь для склада, куда люди заходят с коробками в руках — ножная педаль была главной идеей;
2. клиент — фирма, производящая ножные педали для дверей;
3. дверную ручку продали клиенту за огромные деньги — она должна была войти во вторую версию проекта, не в первую.

Мораль. Читай ТЗ, делай по ТЗ. Если не понимаешь — обсуждай. Если не согласен — спорь. Нельзя молча делать не то, что требуется.

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

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

В программировании есть понятие, пришедшее из радиоэлектроники — «smoke test». Ты запускаешь свой прибор и смотришь, а не пошел ли из него дым. Это самая простецкая проверка. Понятно, что тестирование — дело тестировщиков. Но если программист регулярно допускает «баги невнимательности», то коллектив его уважать не будет.

Мораль. Когда твои 5 минут, могут сэкономить другому человеку целый день — не ленись. Программирование — профессия педантов, которые готовы проверить и перепроверить.

Способ 3. Заниматься посторонними делами в рабочее время

Почему так неправильно. Ты получаешь деньги в обмен на то, что продаешь свое время. Если ты присваиваешь время себе — это воровство.

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

Мораль. Если ты договорился работать на полную ставку — работай на полную ставку. Если есть свободное время — попроси у начальства больше задач и больше денег.

Как составить ТЗ для программиста

Бывает, что сайт уже готов, но нужно добавить на него какую-нибудь программу:

• онлайн-калькулятор;
• программу рассылки;
• анализатор статистики;
• парсер и так далее.

Или вы хотите создать какой-то уникальный сервис для пользователей.

В таких случая не всегда получается воспользоваться готовыми решениями и приходится нанимать программиста.

Составление вакансии и ТЗ для программиста

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

Требуется программист, чтобы добавить функцию X на готовый сайт на WordPress.

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

Когда вы определитесь с выбором исполнителя и обговорите все важные моменты, можно отправлять ТЗ. В нем должно быть:

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

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

Желаемый результат

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

• в какое поле пользователь может вставлять текст;
• должен ли он проверяться в режиме реального времени;
• как будут выделяться ошибки;
• будут ли комментарии к ошибкам;
• будет ли ограничение на объем или количество попыток.
• какой объем текста можно проверить за один раз или за один день;
• как пользователи будут оплачивать дополнительные попытки или объем;
• какие бонусы будут получать пользователи;
• нужно ли измерять грамотность текста в баллах;
• нужно ли сохранять текст в базу данных и так далее.

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

Техническая информация

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

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

Идентификация сетевых ресурсов является важным подготовительным этапом перед осуществлением взлома. Если хакер знает, что ваш корпоративный портал работает под управлением IIS 7 под управлением Windows Server 2008, то ему необходимо найти уязвимости, которым подвержены данные программные продукты. Для этого проще всего поискать в базах уязвимостей. В случае если найти ничего не удалось, то особо продвинутый взломщик может попытаться самостоятельно найти «лазейку», собрав у себя точную копию взламываемой системы и попытавшись самостоятельно проанализировать код. «Информационная безопасность: защита и нападение», Бирюков А. А.

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

Программа должна отображаться на странице page.php, а исполнительный файл в файле core.php. Взаимодействие между файлами с помощью ajax. Все обработанные данные нужно записывать в таблицу data_table (My_SQL) со столбцами id, name и url.

Нельзя создавать функции и переменные с названиями: generate, crop и analyze. Иначе возможен конфликт.

Стандарты оформления кода

Разные люди по-разному пишут. Хороший пример – наш блог. В нем несколько авторов, у каждого из которых свой стиль. То же самое и с программистами.

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

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

Допустим, нужен код, который будет проверять, равна ли переменная $a единице, и выводить об этом сообщение. Кроме того, что этот код можно по-разному оформить, его можно по-разному реализовать.

Переменные можно называть по-разному: $aB, $ab, $a_b, $A и так далее. Если это незначительно, добавлять комментарии критически важно. Без них в коде тяжело ориентироваться, даже если его писали вы, но отложили на неделю.

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

Подключение и тестирование

Перед подключением программы лучше проверить код на наличие лазеек – предумышленных или нет. Если их нет, можно подключать. Дальше идет тестирование и открытие доступа для всех пользователей.

Заключение

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

Техническое задание для программиста 1С

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

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

В жизни часто так бывает, что человек не может объяснить, что хочет от другого. А когда дело доходит до постановки задачи программисту и вовсе вызывает ступор. Есть метод в программировании, который называется «разделяй и властвуй»- дословно можно перевести как разделяй задачу на более мелкие блоки и властвуй (управляй) подзадачей. Для заказчика это метод тоже применим: если у тебя есть ряд «хотелок», то необходимо их разделить на подзадачи и формализовать (описать).

2. Зачем нужно техническое задание

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

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

Идеально, если техническое задание для программиста будет писать заказчик, только он знает чего хочет и чего ожидает от действий программы. Но на практике это далеко не так, связано это может быть с отсутствием должных навыков или банально нехваткой времени у заказчика. Чаще всего ТЗ готовит сам программист 1С или помощник со слов заказчика. Моя любимая «история» по этому поводу, представлена ниже.

Рис1. Техническое задание -глазами участников проекта.

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

4. Что должно содержать в себе техническое задание

Обязательными полями в документе должны быть:

цель— описание результата, который мы получим после внедрения доработок;

описание— краткое описание изменений, необходимые для достижения цели;

способ реализации— здесь требуется описание на техническом уровне, как будет выполнена та или иная задача, какие внутренние объекты будут затронуты: справочники, документы, регистры и т.д. Как правило, этот пункт пишут технические специалисты;

оценка стоимости— оценка трудозатрат и их стоимости;  

Пример  технического задания: скачать документ

Вывод

Техническое задание на доработку 1С-является важным документом взаимодействия между заказчиком и исполнителем проекта. Не стоит пренебрегать им, особенно если дело касается проектной работы. Лучше все вопросы обсудить «на берегу», что бы не получилось как в той самой истории…

Подробнее о наш возможностях здесь >

Спасибо за внимание!

Как делается техническое задание. Как грамотно составить ТЗ для программиста. Основы взаимопонимания. Требования к видам обеспечения

Многие компании не готовы привлекать подрядчиков на этап написания технического задания, полагая, что каждый подрядчик будет писать понятный только его сотрудникам документ, фактически гарантируя себе привилегированное положение на конкурсе\тендере.

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

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

Кроме того, есть ряд ГОСТов, например, 19.201-78, в которых прописано, что и в каком виде должно содержаться в подобном документе.

Однако, как показывает практика, под заветной аббревиатурой «ТЗ» понимаются совершенно разные по сути, содержанию, оформлению и детализации документы. К сожалению, многие заказчики уверены, что, написав пару страниц требований к будущей системе, они получат от нас точную (максимум с дельтой в 10-20%) оценку с календарным планом работ. Получая в очередной раз на почту «ТЗ, по которому к завтрашнему дню надо дать оценку и выслать КП», я всегда морально готовлюсь увидеть очередное творение в стиле «система должна обмениваться с сайтом всей необходимой информацией».

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

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

Так как же составить ТЗ, по которому в итоге получится именно то, что было заложено его автором(-ами), а не то, что «умеет типовой функционал конфигурации»?

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

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

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

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

3. Usability. Из двух предыдущих пунктов есть простое следствие – понятная логика работы и максимальная визуализация будущей системы помогут в итоге заложить в ТЗ нужное количество примечаний\пунктов, касающихся удобства использования системы. Для систем, с которыми работают низкоквалифицированные сотрудники, это может стать решающим фактором успешности проекта (впрочем, этот параметр также крайне важен и для топ-менеджмента, не желающего иметь дела с «этими бухгалтерскими программами»). Например, в ТЗ на систему для розничных продаж не указали, что поиск артикула должен занимать не более трех секунд. Если бы систему реализовали через типовой поиск конфигурации, то это могло привести к критическим ситуациям в реальной эксплуатации, т.к. с учетом количества номенклатуры этот поиск занимал до 30 секунд, что недопустимо при работе с розничными покупателями, где каждая секунда на счету.

4. Ссылки на популярные решения . Зачастую, для всех, к примеру, менеджеров по продажам компании, фраза «функционал ведения сделок» означает примерно одно и то же, но для сотрудников подрядчика эта фраза не значит ровным счетом ничего. Но добавьте пару слов в эту фразу, и из варианта «карточка сделки, аналогичная таковой в Битрикс24(или 1С:CRM)» уже понятно, чего примерно ожидает от этой самой карточки Заказчик.

5. Первичная обратная связь . Еще раз повторюсь — для успешной реализации ТЗ его не обязательно писать по ГОСТу. Не нужно писать документ, предназначенный только техническим специалистам. Техническое задание в первую очередь должно быть понятно коллегам его составителя, а потом и тем, кто будет его реализовывать. Крайне важно получить положительную обратную связь от коллег бизнес-пользователей, прежде чем направлять документ потенциальным подрядчикам или внутреннему отделу разработки. Документ, предельно ясный одному человеку, но не понятный даже ближайшему окружению не имеет шансов на успешную реализацию.

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

От автора: Как написать техническое задание (тз) на разработку сайта ? Тема достаточно обширная, и в рамках одной заметки ее сложно разобрать на все 100% (если вообще это возможно). Но общие положения, о том что нужно учесть и на что следует обратить сое внимание при составлении тз веб-сайта, я постараюсь изложить достаточно подробно.

Итак, техническое задание на разработку сайта

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

Давайте проанализируем такой пример:

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

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

JavaScript. Быстрый старт

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

Что мы имеем. Исполнитель пункт тз выполнил, а вы хотели совсем иное. Вроде все в соответствии, никто не виноват, до конфликта не дошло, но самое главное потеряны время и деньги .

Это пример всего-то банального календаря.

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

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

Из каких пунктов обычно состоит техническое задание?

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

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

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

Поехали по пунктам.

Описание

Здесь можно в пару предложений написать о предприятии, чем занимается. Что – то типа вступление сделать.

для кого — целевую аудиторию:

потенциальные покупатели

продавцы продукции (магазины, интернет-магазины)

сервисные центры

партнеры (фирмы)

потребители продукции (тот, кто уже купил)

Для чего нужен сайт:

Для повышения имиджа компании

Для увеличения продаж

Для удобства клиентов

Корпоративный

Сайт – визитка

Интернет магазин

Языковые версии:

Английский

Сайт должен решать какие-то задачи. Соответственно далее двигаемся по целям и задачам.

Цели и задачи

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

Потенциальные покупатели продукции.

Цель: привлечь больше покупателей и убедить сделать первую покупку, помочь сделать выбор.

Необходимо решить задачи:

Дать качественную, исчерпывающую информацию о продукции, дополнительных услугах, гарантии, сервисе, методах выбора.

Дать информацию о салонах-магазинах

Дать информацию о розничной торговой сети

Дать возможность задать вопрос посредством организации Online-консультирования потенциальных покупателей специалистами предприятия по вопросам выбора, покупки продукции.

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

Теперь перечисляем модули.

Функционал сайта

Для того чтобы перечислить функционал, нужно решить что ему необходимо:

Нужна ли регистрация

Нужен ли закрытый раздел (только для зарегистрированных пользователей)

Нужна ли форма обратной связи

И т.д. и т.п.

JavaScript. Быстрый старт

Изучите основы JavaScript на практическом примере по созданию веб-приложения

После того, как все это описали, мы подбираемся к самому главному и интересному. Конечно, вся проделанная выше работа очень важна, но теперь становиться еще «жарче».

Описание функционала

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

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

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

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

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

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

о компании

история компании

контакты

продукция

каталог продукции

отзывы о продукции

служба сервиса

гарантийное обслуживание

послегарантийное обслуживание

потребителю

покупка и доставка

пользование

о сервисе

магазинам и интернет магазинам

фотографии продукции

Часто задаваемые вопросы

сервисным центрам

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

Часто задаваемые вопросы

партнерам

приглашение к сотрудничеству

Часто задаваемые вопросы

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

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

Главное теперь описать логику работы.

Логика работы

Я описывать буду исходя из рисунка выше.

Верхняя часть (header) остается неизменной на каждой странице. Новостная лента видна только на главной странице. На второстепенных страницах слева показываем подпункты меню того пункта, в котором в данный момент находимся (например если мы на странице «служба сервиса», то показываем ссылки на «гарантийное обслуживание», «послегарантийное обслуживание»). Соответственно и переходы по этим ссылкам ведут на соответствующие страницы. Здесь же, под подпунктами слева отображаем данные для связи с он-лайн консультантами (Skype, ICQ). Блок акции и релизы остаются на каждой странице. Подвал (футер) отображается один и тот же на каждой странице.

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

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

«Новостная лента» из 10-ти последних новостей. Каждая новость должна состоять из заголовка новости, даты публикации, краткого начала новости (4-5 строк) и ссылки «читать полностью». При нажатии на ссылку «читать полностью» попадаем на страницу новостей. Новость, на которую попали, отображается на месте основного содержимого. Включает также заголовок новости, дату публикации. Слева так же отображается новостная лента. Новости за прошлые месяцы и года попадают в архив. То есть под новостями за текущий месяц отображаем «архив за (такой-то месяц или год)». При нажатии на ссылку «архив за (такой-то месяц или год)» вниз выпадает список новостей за соответствующий месяц/год.

Примерно так описываем работу каждого блока. Не забываем про случай с календарем. И самое главное нужно расписать работу каталога товара. Здесь я даю вам задание: попробуйте продумать и описать, как будет работать каталог. Свои варианты присылайте на e-mail. Лучший мы опубликуем.

Что еще должно быть? Неплохо было бы указать совместимость.

Совместимость

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

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

Заключение

В данной статье я не стремился показать, что именно так составляется тз и никак иначе. Делайте так и проблем не будет. Составить качественное техническое задание на разработку сайта – это скорее вопрос опыта . На первых парах составить грамотное техническое задание получиться далеко не у всех.

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

И не забывайте про задание!

Техническое задание важно и исполнителю, и клиенту. Исполнителю оно помогает лучше понять, что хочет заказчик, застраховаться от внезапных «хотелок» со стороны клиента, ускорить работу по выполнению задачи. Клиенту — рассказать точно о том, что он хочет, упростить контроль качества, получить точную стоимость услуги. Мы расскажем о том, как правильно составить ТЗ и что с ним потом делать.

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

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

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

• разработке приложений;
• проектировании дома;
• написании текстов и другие.

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

Как составить техническое задание: структура ТЗ на сайт

Прежде чем приступать к работе:

• Определитесь, кто будет составлять техническое задание
• Разъясните термины
• Откажитесь от субъективных терминов

На первый взгляд кажется, что ТЗ на сайт должен составлять клиент , потому что он заказывает ресурс и выдвигает требования к нему. На самом деле в процессе должны участвовать оба: клиент озвучивает требования, а исполнитель записывает их конкретно, точно и понятно. Например, клиент говорит, что хочет сайт, адаптированный под всех пользователей, а разработчик прописывает требования к адаптивности под 4 доступных размера — ПК, ноутбуки, планшеты, смартфоны.

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

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

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

Опишите сайт

Расскажите, какой тип сайта нужен, кем он будет использоваться, для чего он вообще создается. Например, напишите, что вам нужен интернет-магазин, лендинг для продажи товара или сайт-визитка с 10 страницами. Укажите ориентировочное количество страниц, если не знаете точного числа.

Если у проекта есть конкретная целевая аудитория, опишите ее. Это поможет создать ресурс, который понравится клиентам — например, использовать подходящие выражения в статьях или дизайн, который нравится молодежи или представителям старшего поколения.

Расскажите о структуре

Без представления о структуре невозможно разработать нормальный сайт. Распишите, какие страницы будут на сайте, и покажите уровни их вложенности. Сделать это можно разными способами:

• Схемой
• Таблицей
• Списком

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

Опишите, что будет на каждой из страниц

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

Если все страницы сайта примерно схожи — например, вы планируете создать сайт-визитку, можно обойтись двумя прототипами: для главной страницы и остальных разделов. Если есть несколько групп схожих страниц — например, разделы в каталоге интернет-магазина, блог со статьями и описание услуг по доставке/сборке/установке, лучше сделать свой прототип для каждой группы.

Выдвините требования к дизайну

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

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

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

Опишите требования к инструментам, коду, хостингу, домену

Это нужно, чтобы заранее знать, с какими инструментами можно работать, а с какими — нет. Опишите отдельным блоком:

• На какой должен находиться сайт — Вордпресс, Джумла, Модэкс и так далее
• Какой язык программирования можно использовать — PHP, JavaScript, HTML, другие
• На каком хостинге и в какой доменной зоне должен располагаться сайт, какое доменное имя можно использовать
• Какую программную платформу можно использовать — .NET, OpenGL, DirectX
• И так далее

Если клиент не понимает ничего в используемых терминах — объясните, чем отличается Вордпресс от Модэкса, PHP от HTML, домен в зоне.ru от домена в зоне.com. Вместе составьте требования так, чтобы они устроили клиента.

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

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

• Приемлемую для вас скорость загрузки сайтов или стандартное значение — 1–5 секунд
• Кроссбраузерность — распишите, в каких браузерах сайт должен открываться
• Адаптивность — укажите размеры экранов, под которые должен подстраиваться дизайн, и используемые устройства
• Устойчивость к нагрузкам — сколько человек должно находиться на сайте одновременно, чтобы он не «лег»
• Устойчивость к хакерским и dDos-атакам: сайт должен выдержать небольшие атаки

Распишите сценарии работы сайта

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

Уточните, кто занимается контентом.

Какие-то разработчики сами пишут тексты, кто-то заказывает их у копирайтеров, кто-то использует рыбу. Сразу уточните, входит ли предоставление контента в услугу разработки. Если да, можно сразу прописать дополнительные требования, например, к:

• — не меньше 95% по Адвего, Текст.ру, Контент.Вотч
• Тошноте (заспамленности)- не более 10% по Адвего иди 65% по Текст.ру
• Баллам по Главреду — не менее 6,5 или 7 баллов

Конечно, разные сервисы — не панацея, но они минимизируют риск того, что он будет «водянистым» или переспамленным. Кроме того, так появляются точные критерии оценки качества текстов.

Укажите сроки

Об этом часто забывают. В большинстве технических заданий должны быть прописаны сроки, иначе разработка может затянуться на несколько месяцев, полугодий, лет. Не используйте некорректные формулировки — например, «через месяц». Пишите точную дату: 1 декабря 2018 года, например.

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

Запомните: в каждом ТЗ должны быть несколько основных блоков:

• Цели и задачи — о том, для чего вообще вы создали ТЗ, что хотите сделать с продуктом
• Каким должен быть продукт — описание в общих чертах
• Технические требования — площадь дома, объем текста, функционал приложения и так далее
• Сроки — они важны, чтобы исключить споры.

Пример составления ТЗ на программное обеспечение

Нужно создать ПО. Технические требования — ниже.

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

Что должно делать ПО: после ввода ключевого слова находит статьи на сайтах, которые внесены заранее в качестве авторитетных источников, выводит список совпадений в таком формате:

• Линк
• Название статьи
• Лид-абзац

Если больше 10 совпадений, нужно разделить на страницы — по 10 на каждой.

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

Сроки : до 15.09.2018.

Естественно, это ТЗ можно улучшить — мы предоставили его в качестве примера. А как вы считаете, как можно доработать техническое задание, чтобы оно стало еще понятнее, проще, удобнее?

Федеральный закон № 44-ФЗ о контрактной системе устанавливает единые требования к описанию объекта закупок, которым заказчик обязан следовать при составлении документации о закупке, независимо от способа их осуществления (ст. 33 44-ФЗ). Рассмотрим, какими правилами должен руководствоваться заказчик при составлении технического задания.

Техническое задание: что из себя представляет

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

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

При описании в документации о закупке заказчик должен руководствоваться следующими правилами, установленным 44-ФЗ:

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

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

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

Что запрещено включать в объект закупки

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

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

Указание ГОСТов и техрегламентов

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

Заказчик может несколько изменить условия по сравнению с техническим регламентом, ГОСТом или СанПиНом, но только в сторону улучшения характеристик.

Пример
1. В соответствии с СанПин 2.4.1.1249-03 площадь озеленения территории дошкольного образовательного учреждения должна составлять не менее 50%, заказчик может предусмотреть озеленение не менее 60% территории.

2. В восстановительные соки допускается добавление лимонной кислоты в дозировке не более 3 г/л (в соотв. с тех. регламентом). Заказчик может уточнить этот показатель, уменьшив ее содержание, например, до 2 г/л. Если заказчик ссылается на ГОСТ, который содержит в себе диапазонные значения, то лучше эти значения отдельно расписать, чтобы уже участник в своей заявке нам показал конкретное значение из этого диапазона ГОСТа.

Положения п. 2 ч. 1 ст. 33 Закона № 44-ФЗ не обязывают заказчика абсолютно во всех случаях закупок руководствоваться ГОСТами, стандартами или техническими регламентами. Заказчик использует и обосновывает необходимость использования других показателей, требований, условных обозначений и терминологии только в случае, если законодательством установлены технические регламенты, национальные стандарты и иные требования.

В случае отсутствия ГОСТов, Технических регламентов товар, для которого существует функционирующий рынок заказчик может сформировать описание на основании данных производителей, качественных показателей, которые необходимы заказчику, данных поставщиков о характеристиках товара по причине отсутствия установленных ГОСТов, стандартов и технических регламентов для данного объекта закупки (Письмо Минэкономразвития России от 03.08.2016 № ОГ-Д28-9745).

В случае если ГОСТы являются устаревшими, то следует применять данный номер ГОСТа, но в действующей редакции (с иным индексом после номера)».

Характеристики ТРУ

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

При этом обязательным условием является включение в описание объекта закупки слов «или эквивалент», за исключением случаев несовместимости товаров, на которых размещаются другие товарные знаки, и необходимости обеспечения взаимодействия таких товаров с товарами, используемыми заказчиком, а также случаев закупок запасных частей и расходных материалов к машинам и оборудованию, используемым заказчиком, в соответствии с технической документацией на указанные машины и оборудование (п. 1 ч. 1 ст. 33).

При описании характеристик товара заказчик указывает минимальные и (или максимальные) значения показателей. При этом участники в своих заявках должны указывать конкретное значение, присущее тому или иному товару. В заявках участников не допускается двусмысленное толкование значений, слова «или эквивалент», «от и до», «не более», «не менее», за исключением тех случаев, которые предусмотрены Государственными стандартами.

Как через техническое задание заказчик может ограничить конкуренцию?

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

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

Что запрещено включать в один лот?

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

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

1. При составлении документации, описание объекта закупки должно носить объективный характер. То есть четкое и ясное описание того, что именно нужно заказчику, не допускающее двусмысленностей и разночтений. Кроме того, для уточнения отдельных моментов поставщик может подать запрос на разъяснение.
2. Заказчик в описании предмета закупки описывает его функциональные, технические и иные характеристики, которые требуются от поставленного товара (произведенных работ).
3. Техническое задание должно быть нейтральным, не ставить ограничений на количество потенциальных участников путем прописывания чрезмерных требований к поставляемой продукции. Нельзя «подгонять» описание только под один конкретный товар одного производителя. Это является ограничением конкуренции. Единственным исключением тут является ситуация, когда нет другого способа исчерпывающего описания свойств объекта закупки (п.1 ч. 1 ст. 33).
4. Заказчику рекомендуется указывать в техническом задании, что поставляемый товар должен быть новым (который не был в употреблении, в ремонте, в том числе который не был восстановлен, у которого не была осуществлена замена составных частей, не были восстановлены потребительские свойства), иначе заказчик может получить товар, бывший в употреблении.

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

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

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

Есть мнение некоторых “побитых” опытом людей, что ТЗ надо писать так, как будто с ним вы будете присутствовать на суде и использовать его в качестве защиты. Может это и крайность, но тем не менее — повод лишний раз задуматься о важности хорошо написанного и детализированного ТЗ .

По своему объему ТЗ может быть достаточно большим документом. Web-компании часто предлагают помощь по составлению ТЗ отдельной услугой, как правило 10-20% от стоимости всей разработки сайта.

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

Чем детализированнее ТЗ (в разумных пределах конечно), тем лучше для обеих сторон — как для клиента, так и для исполнителя работы. В выигрыше так сказать оба:
— клиент будет уверен, что все задуманное им в проекте четко прописано и должно быть реализовано в соответствии с ТЗ.
— исполнитель – застрахован от множества мелких или крупных корректировок и доработок, опять же опираясь на то самое ТЗ.

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

• Простая истина — чем сложнее проект, тем детализирование должно быть ТЗ.
• Среди возможных вариантов можно назвать ТЗ, описывающее главные страницы интерфейса со всей совокупностью элементов на ней и описанием их поведения. Или же это может быть лаконичное описание нескольких страниц для сайта-визитки и т.п.
• В ТЗ для программиста не должен упоминаться дизайн элементов или звучать пожелания по дизайну. Задание все-таки для программиста..
• Описания задач в отдельных частях ТЗ должны быть граничными. Что это значит? Нужно четко обозначать конец конкретного пункта задания. В ТЗ не должно быть абстрактных фраз типа «должна быть удобная навигация». Это все субъективные признаки – одним удобно, другим не удобно и понять выполнен ли данный пункт бывает сложно из-за нечеткости положений ТЗ. Т. е. это необходимо контролировать.
• Для несложных сайтов, где нужно описать какой-нибудь функциональный модуль, чтобы заново не изобретать велосипед, нужно проанализировать сайты с похожим функционалом, так сказать, провести анализ конкурентов; сохранить гиперссылки на страницы с требуемыми элементами интерфейса и функциями, и включить их в ТЗ с расширенными пояснениями о том, что именно делать. Также необходимо в обязательном порядке снять скриншоты с нужных страниц на случай, если сайт через время будет не доступен. При этом можно ставить свои пометки на изображениях (благо средств сейчас много для этого — Clip2net, Joxi, Awesome Screenshot и прочие).
• Если дизайна для страниц нету или он не так важен в рамках какого-то проекта, скажем, заказчик решил сэкономить на дизайне админ-панели сайта, в этом случае программист вполне может использовать прототипы.

Справка

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

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

Из популярных можно выделить:
— среди бесплатных: iPlotz, MockFlow, Mockup Builder, Cacoo;
— среди платных: Creately, ProtoShare, Adobe Fireworks,Axure . Возможностей в общем много — выбирай, осваивай, рисуй…

Общая структура ТЗ. От абстракции к конкретике

Одна из возможных структур сайта, подчеркну возможных, может выглядеть примерно так:

1. Общая информация о сайте.
2. Функциональное назначение сайта.
3. Понятия и термины
4. Описание модулей сайта
5. Функциональные характеристики
6. Описание страниц.
7. Резервирование и надежность.
8. Хостинг для сайта.

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

2. Функциональное назначение сайта
Тут краткий перечень того, какими техническими средствами или инструментами должен обладать сайт, исходя из общей цели. Поясню на примере. Для сайта-визитки это может быть банально, форма обратной связи, перечень основных страниц, например с «о компании», «контакты» и прочие.

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

4. Описание модулей сайта
Этот раздел включает список модулей, которые используются на сайте. Это вполне например может быть упоминаемая выше форма обратной связи (ФОС). Но, что очень важно — нельзя просто писать «Должна присутствовать ФОС». Каждая сущность требует определения своих атрибутов! В данном случае атрибуты могут быть такими:

• Поле «Ваш имя»;
• Поле «Ваш е-mail»;
• Поле «Ваш вопрос»;
• Поле ввода капчи для защиты от спам-роботов.

И все это должно быть четко прописано, что бы потом не возникло вопросов: «…а где перечень выбора категории вопроса? » или что-то в этом роде.

5. Функциональные характеристики
Сюда можно отнести, например, список браузеров, где сайт должен корректно отображаться и работать. Например, некоторые заказчики могут требовать, что бы их сайт работал корректно и в небезызвестном Internet Explorer 6, что бы не терять хоть и небольшую, но долю возможных посетителей.
Если планируется делать высоконагруженный сайт – это тоже нужно указывать. Высоконагруженный сайт требует другого подхода при разработке и по настройке сервера.

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

6. Описание страниц сайта
Это довольно обширный пункт, где прорисовуются все страницы сайта и пишутся комментарии к их работе.
Также может приводиться общая структура страниц сайта. Так называемые «высокоуровневые» прототипы. Например, для простого сайта-каталога это может быть:

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

Остальные страницы

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

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

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

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

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

Удачных Вам проектов и человеческого взаимопонимания!

ГОСТ 19.201-78 Техническое задание. Требования к содержанию и оформлению

Г О С У Д А Р С Т В Е Н Н Ы Й   С Т А Н Д А Р Т   С О Ю З А   С С Р

Дата введения с 01.01.80

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

Стандарт полностью соответствует СТ СЭВ 1627-79.

1. ОБЩИЕ ПОЛОЖЕНИЯ

1.1. Техническое задание оформляют в соответствии с ГОСТ 19.106-78 на листах формата 11 и 12 по ГОСТ 2.301-68, как правило, без заполнения полей листа. Номера листов (страниц) проставляются в верхней части листа над текстом.

1.2. Лист утверждения и титульный лист оформляют в соответствии с ГОСТ 19.104-78.

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

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

1.4. Техническое задание должно содержать следующие разделы:

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

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

(Измененная редакция, Изм. № 1)

2. СОДЕРЖАНИЕ РАЗДЕЛОВ

2.1. В разделе «Введение» указывают наименование, краткую характеристику области применения программы или программного изделия и объекта, в котором используют программу или программное изделие.

(Измененная редакция, Изм. № 1)

2.2. В разделе «Основания для разработки» должны быть указаны:

• документ (документы), на основании которых ведется разработка;
• организация, утвердившая этот документ, и дата его утверждения;
• наименование и (или) условное обозначение темы разработки.

(Измененная редакция, Изм. № 1)

2.3. В разделе «Назначение разработки» должно быть указано функциональное и эксплуатационное назначение программы или программного изделия.

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

• требования к функциональным характеристикам;
• требования к надежности;
• условия эксплуатации;
• требования к составу и параметрам технических средств;
• требования к информационной и программной совместимости;
• требования к маркировке и упаковке;
• требования к транспортированию и хранению;
• специальные требования.

(Измененная редакция, Изм. № 1)

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

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

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

2.4.4. В подразделе «Требования к составу и параметрам технических средств» указывают необходимый состав технических средств с указанием их основных технических характеристик.

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

При необходимости должна обеспечиваться защита информации и программ.

(Измененная редакция, Изм. № 1)

2.4.6. В подразделе «Требования к маркировке и упаковке» в общем случае указывают требования к маркировке программного изделия, варианты и способы упаковки.

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

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

(Введен дополнительно, Изм. № 1).

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

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

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

2.8. В приложениях к техническому заданию, при необходимости, приводят:

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

Переиздание (Ноябрь 1987 г.) с Изменением № 1, утвержденным в июле 1981 г (ИУС 7-81)

часовых поясов для разработчиков программного обеспечения | by Бикаш Панеру

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

Отображение времени в часовом поясе пользователя

Это довольно распространенная задача во многих приложениях. Допустим, у нас есть следующие требования:

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

Например, если я размещу фотографию своей несуществующей собаки в 22:00. Непальское время, тогда кто-то, просматривающий изображение в Нью-Йорке, должен увидеть 11:15 утра как время публикации, когда летнее время не соблюдается, и 12:15 p.м. в качестве времени публикации, когда наблюдается переход на летнее время (источник преобразования: TimeIs)

Решение

Когда пользователь создает сообщение:

• Получите дату в формате UTC из серверной части. Для большинства внутренних серверов часовой пояс по умолчанию установлен на GMT, так что это не должно быть проблемой. Вы также можете отправить метку времени из внешнего интерфейса, но не стоит полагаться на клиента, если вам не нужно.
• Если ваша база данных поддерживает тип даты, сохраните полученную дату по Гринвичу напрямую.Если нет, то преобразуйте его в метку времени UNIX и сохраните в базе данных.

Когда средство просмотра запрашивает сообщение:

• Если ваша база данных поддерживает тип даты, преобразуйте его в метку времени UNIX. Если нет, значит, вы уже сохранили необработанную метку времени и можете просто использовать ее. Отправьте эту временную метку клиентской части.
• Библиотека дат вашего внешнего интерфейса (стандартная или сторонняя) наверняка будет настроена на часовой пояс системы по умолчанию и будет иметь методы для получения строк даты относительно часового пояса системы.Если вы просто используете библиотеку дат для преобразования отметки времени в строку, тогда она уже будет в часовом поясе зрителя.

Отображение времени в другом часовом поясе

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

Например, если я размещу фотографию своей несуществующей собаки в 22:00. По непальскому времени, то, кто смотрит картину в Нью-Йорке, должен увидеть 22:00.из Азии / Катманду в качестве почтового времени. Здесь Asia / Kathmandu — часовой пояс Непала.

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

Решение

Когда пользователь создает сообщение:

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

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

Например:

• В JavaScript new Date (). GetTimezoneOffset () даст нам разницу между местным временем и UTC в минутах, которую мы можем использовать для определения смещения. Однако сама по себе эта информация не скажет нам, какой часовой пояс. Это связано с тем, что несколько часовых поясов могут иметь одинаковое смещение, и пользователь может даже находиться в регионе с переходом на летнее время.
• JavaScript также поддерживает Intl.DateTimeFormat (). ResolvedOptions (). TimeZone , который даст нам имя часового пояса. Однако в старых версиях браузеров это не работает.
• Moment Timezone, популярная библиотека дат для JavaScript, имеет метод moment.tz.guess () , который угадывает, в каком часовом поясе находится пользователь. Хорошая новость заключается в том, что он будет использовать Intl. DateTimeFormat , который мы обсуждали ранее, если браузер поддерживает его.

Когда зритель запрашивает сообщение:

• Если наша база данных поддерживает тип даты или если мы храним необработанные временные метки, то мы можем использовать библиотеку дат, которая поддерживает часовые пояса, например часовой пояс Moment, чтобы преобразовать ее в формат плаката. часовой пояс.Напомним, что на предыдущем шаге мы сохранили часовой пояс плаката.
• На этот раз мы отправим фактическую дату, преобразованную в строку, во внешний интерфейс и напрямую отобразим ее. Мы могли бы использовать библиотеку часовых поясов для преобразования во внешнем интерфейсе, но эти библиотеки обычно имеют большой размер из-за информации о часовых поясах, которую они несут, и увеличивают время загрузки нашего приложения.

• Обратите внимание, что мы также можем сделать это без использования сторонней библиотеки, просто добавив смещение часового пояса плаката к нашей исходной отметке времени, а затем преобразовав это в строку даты в формате UTC.Однако нам нужно было бы получить смещение от внешнего интерфейса и сохранить его с каждым постом. Это связано с тем, что нам нужно было бы учитывать переход на летнее время, если бы мы не сохраняли смещение для каждого сообщения. В предыдущем примере это не проблема, потому что Moment Timezone сделает это за нас.

Преобразование времени из одного часового пояса в другой

Название этого примера немного вводит в заблуждение. На самом деле реального «перевода» времени из одного часового пояса в другой нет.Как мы узнали ранее, время можно выразить с помощью меток времени UNIX, которые всегда находятся в формате UTC. Таким образом, мы можем отображать время только относительно разных часовых поясов, а не «конвертировать» время из одного часового пояса в другой. Если мы всегда храним временную метку UNIX, тогда вообще не должно быть необходимости выполнять какое-либо преобразование. Нам нужно только иметь возможность отображать время в целевом часовом поясе.

Однако, если у нас нет метки времени UNIX, но вместо этого есть строка даты в стандартном формате даты (E.g., MM / DD / YYYY HH: MM: SS), который, как мы знаем, относится к некоторому часовому поясу, тогда мы можем легко извлечь из него метку времени UNIX. Затем мы можем использовать эту отметку времени для создания строки даты в любом другом часовом поясе.

Это может показаться простым делом, если мы подумаем об этом с точки зрения смещений по всемирному координированному времени. Все, что нам нужно сделать, это вычесть смещение исходного часового пояса из UTC и добавить смещение целевого часового пояса к результату. Однако проблема здесь в том, что нам нужно учитывать переход на летнее время.Чтобы обойти эту проблему, нам нужно использовать базу данных часовых поясов. Эта задача влечет за собой множество сложных вещей, поэтому мы всегда должны использовать библиотеку при отображении метки времени UNIX в виде строки даты относительно некоторого часового пояса. Библиотека выполнит вышеуказанные действия за вас, учитывая переход на летнее время.

Вот пример этого часового пояса момента (на основе документации):

Встроенная ОС, поддержка и услуги | ОСРВ, гипервизор

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

Предлагаем:

• Продукты Foundation, включая ОСРВ QNX Neutrino, платформу разработки программного обеспечения QNX (SDP) с POSIX-совместимой средой разработки и гипервизор QNX.
• Сертифицированные по безопасности варианты наших продуктов, которые ускорят ваши усилия по сертификации.
• Решения безопасности, включая наше решение для безопасного обновления по беспроводной сети (OTA) и наше уникальное решение для анализа двоичного кода.
Промежуточное ПО
• Plus для ускорения ваших усилий по разработке и ускорения вывода на рынок.

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

Предлагаем:

• Разнообразные пакеты поддержки и технические советы от разработчиков, инженеров и архитекторов.
• Лучшая в своем классе документация по продукту, дополненная нашей базой знаний.
Пакеты поддержки платы
• для широкого спектра процессоров Arm® и x86.
• Управляемый жизненный цикл продукта с регулярными обновлениями и исправлениями.

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

Предлагаем:

• Услуги безопасности и решения для двоичного анализа
• Разработка под заказ
Службы безопасности
• помогут вам получить сертификаты IEC 61508, ISO 26262, IEC 62304 и EN 5012X.
• Учебные курсы, разработанные и проведенные экспертами в области функциональной безопасности и разработки встроенного программного обеспечения.

для часовых поясов и перехода на летнее время — Ужас

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

ЧАСОВЫЕ ПОЯСЫ

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

Перемешать часовые пояса

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

Многие части мира борются с изменениями времени. Например, давайте посмотрим на часовой пояс Pacific / Apia, который является временем зона независимой страны Самоа.До 29 декабря 2011 г. это было -11 часов от всемирного координированного времени (UTC). С 31 декабря 2011 г. компания Pacific / Apia стала +13 часов от UTC.

Что произошло 30 декабря 2011 года? Ну это никогда произошло на Самоа, потому что следует 29 декабря, 23: 59: 59-11: 00 сразу до 31 декабря, 0: 00: 00 + 13: 00.

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

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

Всегда конвертировать в UTC?

Как программисты, мы рекомендуем избегать проблем с часовыми поясами, «преобразование» времени в UTC (координированное Всемирное время) как можно раньше и конвертировать в местное время. зона только тогда, когда это необходимо для отображения времени людям. Но с этим есть проблема.

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

Например, предположим, что я нахожусь в Северной Каролине, в восточный часовой пояс, но я планирую мероприятие в Мемфисе, который находится в центральном часовом поясе. Я иду в свой календарь программы и внимательно введите дату и «15:00 CST». Календарь следует обычному соглашению и преобразует мою запись в UTC. добавив 6 часов, чтобы время сохранялось как 21:00. UTC, или 21:00 УНИВЕРСАЛЬНОЕ ГЛОБАЛЬНОЕ ВРЕМЯ. Если в календаре используется Django, даже лишнего кода нет. необходимо для преобразования, потому что Django делает это автоматически.

На следующий день я смотрю в свой календарь, чтобы продолжить работу над своим мероприятие. Время события было преобразовано в мой местный часовой пояс, или по восточному времени, поэтому календарь показывает, что событие происходит в «4:00 p.m. «(вместо 15:00, как должно быть). Конвертация мне не нужна, потому что я хочу, чтобы планировать вокруг других событий в том месте, где это мероприятие происходит, в котором используется CST, поэтому мой местный часовой пояс не имеет значения.

Суть в том, что следуя совету всегда конвертировать раз до UTC приводит к потере информации.Иногда нам лучше хранить время с их часовыми поясами, отличными от UTC. Вот почему немного раздражает то, что Django всегда «конвертирует» местное время в UTC перед сохранением. в базу данных или даже перед их возвратом из формы. Это означает, что исходный часовой пояс будет утерян, если вы не перейдете в проблема с сохранением его отдельно, а затем с преобразованием времени из базу данных обратно в этот часовой пояс после того, как вы получите ее из база данных. Я писал об этом раньше.

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

ВРЕМЯ ЭНЕРГОСБЕРЕЖЕНИЯ

Летнее время (DST) еще больше человеческое изобретение, чем часовые пояса.

Часовые пояса — довольно очевидная адаптация к конфликту между тем, как наши тела предпочитают быть активными в часы, когда солнце встает, и как мы проводим время с людьми в других частях света. Исторические изменения часовых поясов с годами раздражают, но с тех пор часовые пояса — изобретение человека, поэтому неудивительно, что мы изменили их то и дело.

DST, с другой стороны, означает изменение целых часовых поясов дважды. каждый год. Что означает часовой пояс США / восток? Я не знаю, если ты не скажешь мне дату. С 1 января 2018 г. по 10 марта 2018 г. имел ввиду UTC-5. С 11 марта 2018 г. по 3 ноября 2018 г. это означало UTC-4. А с 4 ноября 2018 года по 31 декабря 2018 года снова UTC-5.

Но становится еще хуже. Из Википедия:

Закон о едином времени 1966 года установил переход на летнее время. будет работать с последнего воскресенья апреля до последнего воскресенья в октябре в США.В закон были внесены поправки, согласно которым первое воскресенье апреля начало летнего времени время с 1987 года. Закон об энергетической политике 2005 года продлил Переход на летнее время в США с 2007 года. Таким образом, местное время меняется с 2:00 утра по восточному стандартному времени на 3:00 утра по восточному времени. во второе воскресенье марта и вернуться в 2:00 утра по восточному времени в 1:00 утра по восточному стандартному времени в первое воскресенье ноября.

Итак, за 50 с небольшим лет правила менялись 3 раза.

Даже если у вас есть полная и точная информация о правилах, переход на летнее время удивительным образом все усложняет.Для Например, вы не можете преобразовать 2:30 утра 11 марта 2018 г. в американский / восточный часовой пояс до UTC, потому что этого времени никогда не было — наши часы должны были прыгать прямо с 1:59:59 утра до 3:00:00 утра См. ниже:

Вы не можете преобразовать 1:30 a.м. 4 ноября 2018 г. по американскому / восточному времени. зона по Гринвичу тоже, потому что это время произошло дважды . Вам придется чтобы указать, было ли это 1:30 утра 4 ноября 2018 г. по восточноевропейскому времени или 1:30 утра. 4 ноября 2018 г., EST:

Советы по правильному управлению временем даты

Вот несколько правил, которым я стараюсь следовать.

При работе на Python никогда не использует наивное время. (Это объекты datetime без информации о часовом поясе, которые, к сожалению, значение по умолчанию в Python, даже в Python 3.)

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

Позвольте мне еще больше усилить это. Это невозможно до правильно построить дату с информацией о часовом поясе, используя только собственные библиотеки Python при работе с часовыми поясами, которые используйте DST . Я должен использовать pytz или что-то подобное.

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

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

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

Заключение

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

Время и дата: основные понятия

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

Документ «Работа с часовыми поясами» предоставляет более подробную информацию по каждой из этих тем, а также рекомендации по работе с временем и датой в Интернете. Прочтите это для более подробного изучения.

UTC

UTC также известно как GMT (время по Гринвичу). Между ними есть некоторые тонкие различия, но ни один из них не заметил бы ни одного из них.

Универсальное координированное время (UTC) является основой современного хронометража. Среди прочего, он обеспечивает общую основу для преобразования инкрементального и местного времени.

Смещение часового пояса для UTC равно 0. UTC часто указывается в полевых форматах с использованием Z .

Полевые форматы времени

Когда вы пишете время, используя формат на основе полей, вы делите дату и / или время на отдельные значения полей, такие как год, месяц, день, час, минута, секунда и т. Д., Например 2016-09-11T06 : 10: 32 . Сравните это с альтернативным способом выражения того же времени, 1465621816590 , который не основан на полях и его довольно трудно читать.

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

Форматы, описанные стандартом ISO 8601, основаны на полях.

Время приращения

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

Java (и многие другие системы) считают время количеством миллисекунд, прошедших с полуночи (00:00 утра) 1 января 1970 года по всемирному координированному времени (без учета всех промежуточных дополнительных секунд). В других системах используются другие единицы и / или эпохи.

Например, в какой-то момент при написании этого абзаца время инкремента для JavaScript в моем браузере было 1465621816590 (т.е. 11 июня 2016 г., 6.10 утра по московскому времени).

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

Стенка / местное время

Время на стене или по местному времени — это момент времени, который может быть сопоставлен с определенной точкой в ​​инкрементальном времени, если вы примените любую соответствующую информацию о часовом поясе, но это соответствует тому, что человек распознал бы, если бы они смотрели на часы и / или календарь, прикрепленные к стене в определенном месте.

Использование слова local в HTML не относится к настенному времени — вместо этого время, описанное как datetime-local , на самом деле является плавающим временем.

Так, например, при написании предыдущего раздела я, возможно, взглянул на время, отображаемое на моем компьютере, и увидел Сб 11 июня 06:10 . Если я применяю знания о том, как это время соотносится с всемирным координированным временем (в моем случае с поправкой на один час для учета британского летнего времени), я могу преобразовать это время в инкрементное время 1465621816590 .

Также возможно преобразовать это время в настенное время в другом месте, например в Сан-Франциско, где кто-то, одновременно глядя на отображение времени своего компьютера, увидел бы Пт 10 июня 22:10 .

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

Плавающее время

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

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

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

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

Другие примеры событий с плавающим временем включают дату публикации выпуска газеты, дату начала Олимпийских игр в Рио, время начала Нового года, часы работы, установленные на «с 9 до 5», независимо от часового пояса и т. Д.

Часовой пояс

Часовой пояс — это набор правил для определения местного времени (время стены), поскольку оно относится к инкрементному времени (используемому в большинстве вычислительных систем) для определенного географического региона, и наоборот.

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

Смещение зоны

Смещение зоны — это сумма, которая добавляется или вычитается из всемирного координированного времени в зависимости от местоположения события по всему миру относительно нулевого меридиана.Обычно смещения выполняются с интервалом в один час, но смещения могут также включать другие различия, например, 30 или 45 минут.

Обычно смещение зоны в форматах на основе полей выражается с помощью +/-, за которым следует смещение. Так, например, Япония на 9 часов опережает UTC, поэтому вы можете увидеть время, записанное как 2016-06-11 05: 10 + 09: 00 .

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

Переход на летнее время

Переход на летнее время (DST) или «летнее время» был принят как способ дать людям больше солнечных часов в вечернее время.

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

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

Например, корейское стандартное время и японское стандартное время в настоящее время используют одно и то же смещение зоны, и ни в одном из них не используется летнее время.Однако Япония отказалась от летнего времени в 1951 году, в то время как Южная Корея использовала его последний раз в 1988 году, поэтому приложение, которое отслеживает значения времени, которые достигают таких значений, может нуждаться в отслеживании этих часовых поясов отдельно.

Идентификаторы часовых поясов

Идентификаторы часовых поясов позволяют ссылаться на конкретное отличие от UTC, которое включает как смещения зон, так и переход на летнее время.

Наиболее точным справочным материалом для определения наборов правил часовых поясов является база данных TZ (также известная как база данных часовых поясов Олсона), которая используется такими системами, как различные коммерческие операционные системы UNIX, Linux, Java, CLDR, ICU и многие другие. другие системы и библиотеки.Существуют и другие системы: например, Microsoft Windows использует собственный набор данных и идентификаторы.

В базе данных TZ часовым поясам присваиваются идентификаторы, которые обычно состоят из региона и города-образца. Образцовый город — это город в рассматриваемом часовом поясе, который должен быть хорошо известен людям, использующим этот часовой пояс. Например, для тихоокеанского часового пояса США идентификатор базы данных TZ составляет America / Los_Angeles . База данных TZ также предоставляет псевдонимы для многих идентификаторов; например, Азия / Улан-Батор эквивалентно Азия / Улан-Батор .

Репозиторий данных общего языка (CLDR) может использоваться для предоставления локализованной формы для идентификаторов. Обратите внимание, что некоторые системы, такие как Mac OS от Apple, предоставляют дополнительные образцы городов.

григорианский и другие календари

Григорианский календарь — наиболее широко используемый способ представления гражданского времени. Это солнечный календарь, в котором годы обычно состоят из 365 дней, плюс понятие «високосный год». Это добавляет дополнительный день каждые 4 года, за исключением случаев, когда год делится на 100 без остатка (если год также не делится на 400 без остатка).

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

Существуют технологии, такие как ICU или Dojo, которые поддерживают преобразование между различными календарными системами.

Условия HTML5

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

глобальная дата и время

Дата из 6 цифр, T или пробел, время из 4-9 цифр (обязательно), смещение часового пояса (обязательно), равное Z или +/- 2 цифры, с необязательными секундами

2016-05-25T21: 19: 47.123 + 08

2016-05-25 21: 19: 47-08

2016-05-25 21: 19: 47Z

25.05.2016 21:19:00.123 + 23: 45

нормализованные глобальные дата и время

То же, что и выше, за исключением того, что требуется T, 00 опускается в поле секунд, а смещение часового пояса может быть только Z.

2016-05-25T21: 19: 47.123Z

2016-05-25T21: 19Z

плавающие дата и время

То же, что и глобальная дата и время, но без информации о смещении часового пояса

2016-05-25T21: 19: 47.123

25.05.2016 21:19:00

нормализованные плавающие дата и время

То же, что и выше, за исключением того, что требуется T, а 00 в поле секунд опускается.

2016-05-25T21: 19: 47.123

2016-05-25T21

UTC хватит для всех, верно?

Время хранения

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

Шаг первый: использовать UTC .Хорошо, я не собираюсь сразу говорить, что все эти советы, которые мы давали годами, неверны. UTC — прекрасный стандарт, на котором основывается ваше время. Так что используйте это. Не делайте глупостей и не меняйте часовой пояс серверов на UTC.

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

UTC, конечно же, означает:

U универсальный
Coordina T ed…?
C ммм … дай мне понять это … T ime?

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

Но да, этот инициализм UTC не имеет никакого смысла. Давайте углубимся в это еще немного.

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

Англоязычный народ был похож на йо, это определенно звучит как Всемирное координированное время , бум, отправь его. И франкоговорящие были такие, как да, это имеет смысл! Temps Universel Coordonné ДЕЙСТВИТЕЛЬНО работает и на нашем языке, отправьте его! Потом они оба посмотрели и поняли, что круто, они создали CUT и TUC для сокращений. Дерьмо.

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

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

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

Уф.

Итак.Мы используем UTC, потому что у него смещение от 00:00: другими словами, у него нет смещения часового пояса. Остальные часовые пояса смещены от UTC , а не наоборот.

Важно отметить, что UTC — , а не GMT. GMT — это время по Гринвичу, которое исторически было центром времени в мире. У них обоих есть смещение 00:00. Но вы не должны использовать GMT на своем сервере, например, потому что UTC — это стандартный , а GMT — часовой пояс .На самом деле люди живут в местах, где время по Гринвичу; UTC напрямую не используется людьми (если только они не являются действительно странными).

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

лампочка

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

Один вопрос, который вы, возможно, захотите задать с самого начала: вам действительно нужно для хранения времени?

Как программисты, мы отчасти созданы для того, чтобы иметь АБСОЛЮТНЫЕ ЛУЧШИЕ ФОРМАТЫ ВЫСОКОЙ НАДЕЖНОСТИ ЗА ВСЕ ВРЕМЯ. Как черт возьми, мне, , нужно меток времени с точностью до микромиллинаносекунды для каждого чизбургера, который добавляется в мое приложение Watch-The-BK-Throne .Если у меня нет точных данных с точностью до миллисекунды, когда я съел этот бутерброд с беконом BBQ WHOPPER® от Burger King®, я могу умереть.

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

Правильное хранение времени с учетом часового пояса

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

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

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

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

Один из способов сделать это — рассматривать этот столбец как целое число; скажем, сохраните -240 в строке, чтобы представить смену в 4 часа (4 * 60 минут). Это круто, и это действительно приближает вас, но опять же, мы говорим о варианте использования, в котором действительно важно быть максимально точным (а отсутствие часового перерыва может привести к бессмысленным данным). Простое числовое смещение не дает точного определения местоположения. Это было во время летнего времени? Как насчет сравнения этого с сегодняшним днем? мы учитываем летнее время или нет? Кроме того, нужно ли нам учитывать изменения часовых поясов, которые могли произойти с того момента времени?

Вместо числового смещения используйте строку.В частности, используйте полное квалифицированное имя в базе данных Olson, например, Australia / Adelaide или America / Los_Angeles . Это стандартизированные дескрипторы часовых поясов, используемых в мире, и вы можете использовать их практически во всех языках программирования, когда-либо использовавшихся за последние несколько десятилетий.

Опять же, все это, вероятно, не актуально для каждого приложения — кого волнует, просматривает ли кто-то статью Красиво причесанные волосы Брэда Питта: друг или враг пролетариата? и шесть моих комментариев — это , технически указано на час раньше, чем было на самом деле.Независимо от времени, мои комментарии были совершенно актуальными и отлично исследовали проблему. Но для некоторых приложений может иметь смысл подробное описание, особенно если вы сравниваете много раз друг с другом (например, календарь).

лампочка

   шесть минут назад 
  

   шесть минут назад 
  

   шесть минут назад 
  

  FREQ = WEEKLY; BYDAY = TU; INTERVAL = 1
  

 вызов tzutc () 

000 datetime.time609 (0) 902 90 timezone путь к файлу  gettz ()  для получения объектов tzinfo для других часовых поясов. 
 
 tzfile ('/ usr / share / zoneinfo / US / Pacific') 
  tz.gettz (  'Europe / Paris'  ) 
 tzfile ('/ usr / share / zoneinfo / Europe / Paris ') 
  tz.gettz (  'US / Pacific'  ) .utcoffset (datetime.datetime.utcnow ()) 
 datetime.timedelta (-1, 61200) 
 Для изменения элемента даты и времени, отличного от UTC для UTC необходимо учитывать часовой пояс. Если вы попытаетесь изменить доверчивую дату и время на UTC, вы получите исключение ValueError. Чтобы иметь в виду наивный часовой пояс datetime, вы в основном вызываете стратегию  replace ()  с правильным tzinfo. Как только элемент datetime имеет tzinfo, в этот момент можно изменить UTC, вызвав метод  astimezone ()  с  tz.Тзутц () .
  abc   =   tz.gettz (  'US / Pacific'  ) 
  dat   =   datetime.datetime (  2010  ,   9  ,   25  ,   10  ,   36  ) 
  dat.tzinfo 
  dat.astimezone (tz.tzutc ()) 
 (последний звонок последний):
 Файл "/ usr / lib / python2.6 / doctest.py ", строка 1228, в __run
 compileflags, 1) в test.globs
 Файл "", строка 1, в
 dat.astimezone (tz.tzutc ())
ValueError: astimezone () не может быть применен к наивному datetime 

 datetime.datetime (2010, 9, 25, 10, 36, tzinfo = tzfile (
'/ usr / share / zoneinfo / US / Pacific')) 

 datetime.datetime ( 2010, 8, 4, 18, 30) 

 datetime.datetime (2010, 8, 4, 18, 30, tzinfo = tzfile ('
/ usr / share / zoneinfo / US / Central ')) 

  секунд: 32 бита
микросекунды: 20 бит
               --------
всего: 52 бита  

  struct timeval {
   time_t tv_sec; / * секунды * /
   suseconds_t tv_usec; / * микросекунды * /
};  

  struct timespec {
   time_t tv_sec; / * секунды * /
   long tv_nsec; / * наносекунды * /
};  

  struct itimerspec
{
    struct timespec it_interval;
    struct timespec it_value;
};  

  секунд: 64 бита
доли секунды: 48 бит
                    --------
всего: 112 бит