ТЗ на разработку сайта: как составить, основные требования

Оглавление

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

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

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

Услуга на разработку ТЗ сайта

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

Плюсы для клиента

Плюсы для исполнителя

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

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

Как правильно составить ТЗ?

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

1. ТЗ составляет отдельный специалист

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

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

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

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

2. Писать нужно без двусмысленностей

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

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

Красивый, удобный, современный – это субъективно.

То, что может показаться красивым и удобным специалистам, совсем не значит, что будет удобным клиенту. И наоборот – часто клиент называет современным дизайн и функционал, которые были в ходу десятки лет назад. Большие нагрузки также надо расписывать – сколько человек планируется на сайте одновременно? 100, 1000 или миллион?

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

Пример однозначных желаний:

• Сайт должен загружаться быстро. → Нужно подключить композитную технологию.
• Сайт должен выдерживать высокие нагрузки. → На сайте одновременно может быть до 100 тысяч посетителей.
• На главной должен быть список новостей. → На главной должен выводится список из 3-х последних новостей.

3. Укажите информацию о компании

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

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

4. Создайте глоссарий

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

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

5. Распишите инструменты и требования к хостингу

Можно представить себе ситуацию, когда после уже выполненной работы, клиент узнаёт, что сайт сделан на 1С-Битрикс, а клиент предпочитает работать с WordPress. Клиент разгневан, недоволен работой, даже если до этого всё устраивало.

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

6. Распишите требования к работе сайта

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

7. Распишите структуру сайта

Перед тем как отдать сайт дизайнеру, необходимо сначала расписать структуру.

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

Пример структуры сайта

Подходите к этому этапу внимательно. Структура – это основа сайта. Если её не продумать именно со всеми связями, то навигация будет неочевидной, пользователи могут запутаться в ней и уйти с сайта, так и не совершив целевое действие.

8. Опишите содержание страниц

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

У разработчика есть несколько вариантов показать вид страниц.

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

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

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

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

1. Пользователь совершает действие.
2. Сайт отвечает на это действие.
3. Дополнительные действия пользователя (если требуются).
4. Результат.

Количество пунктов схемы зависит от сценария. Чем подробнее вы распишите схему, тем проще будет исполнителям работать, а клиенту – проверять работу.

Сценарии можно не расписывать, если вы разрабатываете лендинг со стандартным функционалом.

Услуга на Веб-разработку

10. Определите поставщика контента

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

Варианты работы по созданию контента:

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

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

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

Размещение контента тоже обговаривается заранее:

• исполнитель полностью заполняет сайт;
• исполнитель заполняет сайт определённым количеством контента;
• исполнитель оставляет на сайте тестовое наполнение.

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

11. Опишите дизайн

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

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

Вывод

Компания «Цифровой Элемент» более 10 лет занимается разработкой сайтов. Наша работа с клиентом по разработке сайта всегда начинается именно с написания ТЗ. Мы ответственно подходим к этому процессу. Наш опыт позволяет задать клиенту такие вопросы, которые помогают получить необходимую информацию.

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

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

Как написать ТЗ на установку и монтаж оборудования

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

Нужна помощь? Наши специалисты бесплатно составят ТЗ на монтаж, перемещение и установку оборудования. Обращайтесь!

Для чего необходимо ТЗ

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

«100 ТОНН МОНТАЖ» стремится к тому, чтобы еще на этапе подготовки коммерческого предложения максимально полно изучить задачу клиента. Именно подробное ТЗ позволяет нам сделать точные расчеты затрат на монтаж оборудования, предложить наилучшие инженерные решения, подобрать оптимальную грузоподъемную технику, инструмент и материалы, определить численность бригад.

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

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

На основе 17-летнего опыта работы на рынке монтажа оборудования наши руководители проектов и инженеры ПТО рекомендуют включать в техзадание следующие основные пункты:

• Перечень работ, которые необходимо выполнить. В этом пункте необходимо указать, что именно нужно демонтировать, смонтировать, законсервировать или утилизировать. К каким коммуникациям требуется подключить оборудование. Нужно ли слить и утилизировать технологические жидкости. Требуются ли пусконаладочные работы и испытания. Именно ведомость объёма работ делает будущую совместную работу прозрачной и предсказуемой.
• Место (адрес) выполнения работ.
• Параметры оборудования: назначение, производитель, новое или бывшее в употреблении.
• Массогабаритные характеристики оборудования или его компонентов, длина и сечение трубопроводов (или их масса), длина и тип кабелей и т.п.
• Высотные отметки, на которых планируется устанавливать оборудование (этаж, высота фундамента).
• Состояние производственного объекта: действующее, строящееся, реконструируемое, демонтируемое производство, производство на консервации.
• Характеристики дорожного покрытия и пола в производственном помещении.
• Высота потолочных перекрытий над местом монтажа или демонтажа.
• Ширина пролетов цеха и размеры въездных ворот.
• Выступы, приямки, иные препятствия на пути перемещения груза.
• Наличие на площадке заказчика штатных грузоподъемных механизмов и средств малой механизации.
• Возможность применения дизельной техники в помещении цеха.
• Наличие и возможность использования санитарно-бытовых помещений.
• Пропускной режим на объекте.

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

Сроки выполнения работ

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

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

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

Приложения к ТЗ

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

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

Чего стоит избегать в ТЗ

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

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

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

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

Матрица ответственности

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

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

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

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

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

Почему мы пишем ТЗ сами

Первый способ исправить ТЗ

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

С ответом на вопрос: «Для чего?» могут помочь в отделе продаж (и / или маркетинга тоже) заказчика. Скорее всего, там наблюдают за конкурентами уже сейчас и совершенно трезво сравнивают себя с ними, слушают возражения клиентов и могут выявить то самое свойство изделия, которое надо прописать как стержень ТЗ, сделать основной задачей проекта — добавить или усилить именно это свойство нового продукта.

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

С этой картинкой уже можно идти к электронщикам и спрашивать: «Вот такая штука нужна, когда сделаете?» Электронщики вам крылья, конечно, подрежут, но это уже рабочий процесс…

Второй способ

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

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

Как составить техническое задание на текстовый контент

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

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

Давайте жить дружно!

Главные ошибки при составлении ТЗ и работе с ним

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

Ошибки и заблуждения со стороны заказчика

ТЗ на 100500 страниц

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

Виктория Кучинова, заместитель главного редактора блога «Кокос»:

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

И все бы хорошо, если бы такое ТЗ составлялось на комплексные работы. У нашего блога есть редполитика — по сути расширенное ТЗ на тексты, которое мы даем изучить всем нашим авторам. Там много ценной информации, которая пригодится при написании текстов. Но техзадание на 8 страниц А4 для коротенького текста — увольте, мне было жаль своего времени. От этой работы я отказалась.

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

Слишком маленькое ТЗ

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

Не всегда краткость — сестра таланта

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

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

Слишком много технических требований

Аббревиатура ТЗ означает “техническое задание”, и заказчики порой понимают это буквально. Например, просят проверить текст по всем возможным сервисам и добиться идеальных показателей. В итоге автор старается, прогоняет свою работу через все сервисы, а на выходе получается текст с уникальностью в 146 %, который нереально читать из-за тотальной синонимизации и мутных потоков «воды».

Пример технических требований в ТЗ. На мой взгляд, это перебор

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

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

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

Что такое SEO-статья и как правильно писать SEO-тексты

«Хочу то, не знаю что», или «А сделайте что-нибудь эдакое!»

Владельцы сайтов часто и сами не знают, зачем им нужен тот или иной текст. Вроде бы увидели у конкурентов — надо повторить. А зачем это целевой аудитории, что она должна понять и СДЕЛАТЬ после прочтения текста — неизвестно. Или того хуже: заказчики просят копирайтера написать «что-то необычное, огненное и вообще лучшую статью в Рунете». Как будет оцениваться степень огненности, не уточняется. Критериев для оценки нет, вернее, есть один: «Мне не нравится, переделывайте».

Как надо: давать конкретику. Если вы заказываете текст, то должны четко представлять, что хотите увидеть на выходе. Прямо напишите в ТЗ, что работа будет оцениваться по следующим критериям: соответствие редполитике, теме, структуре, стилистике, техническим требованиям (уникальность, заспамленность, водность, объем), достаточная глубина проработки, наличие или отсутствие экспертизы и другим.

Главное — прописать эти критерии в ТЗ, а не озвучить их автору сразу же после того, как он пришлет вам готовый текст

Ошибки и заблуждения со стороны автора

«А зачем мне вообще ТЗ? Я умный, я профи, я и так пойму, что нужно заказчику»

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

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

«Я художник, я так вижу!»

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

Если бы все авторы были Камеронами…

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

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

Заказчики — садисты, им только дай волю поиздеваться над автором!

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

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

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

16 действенных способов увеличить трафик сайта

Что должно быть в техническом задании на контент

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

Цель материала

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

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

Информация о бизнесе и продукте заказчика, целевой аудитории

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

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

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

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

• У нас собственное производство сумочек, в штате 23 швеи, работают на станках ЧПУ.
• Нам нужно обогнать конкурентов в поисковой выдаче по Москве и Московской области, другие регионы пока не в приоритете.
• Мы продаем сумки для деловых женщин: никаких аляповатых расцветок и дешевых материалов, все строго, стильно и дорого.
• Наши самые популярные модели — сумки «Анна-Мария», «Стиль» и «Лама».

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

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

Объем текста

Зависит от тематики и вида текста: для описания карточки товаров достаточно 500-1000 знаков без пробелов, для информационной статьи-лонгрида бывает недостаточно и 10 000 знаков. Главное — чтобы тема была раскрыта полностью без воды.

Уникальность

Для SEO-текста достаточно 85% уникальности. Если больше — хорошо, меньше — текст придется отправить на доработку. Проверить уникальность можно с помощью сервисов Text.ru, Advego, Etxt.ru и других. Укажите их прямо в ТЗ, чтобы облегчить автору задачу.

Попросите автора, чтобы прислал ссылку на страницу с результатом или скриншот

Заспамленность, или тошнота

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

Заспамленность тоже в норме

Ключевые слова

Подберите их самостоятельно по сервису «Яндекс.Вордстат» или поручите это задание своему SEO-специалисту. Если у вас уже составлено семантическое ядро — отлично, берите ключи из него.

Какие должны быть ключи:

• Разнотипные: высокочастотные, и средне-, и низкочастотные. Опыт «Кокоса» показывает: чтобы продвигаться по трафику, на одних ВЧ-запросах далеко не уедешь, особенно в высококонкурентной тематике. А вот если использовать все запросы в совокупности, шанс попасть в топ повышается.
• Читаемые. Необязательно использовать ключи только в прямом вхождении: это смотрится неестественно. Вполне можно разбавить ключ “купить женскую сумку москва недорого” и написать по-человечески: «Если вы хотите недорого купить женскую сумку, присмотритесь в Москве к следующим магазинам…».
• Релевантные теме текста. Если мы пишем про недорогие сумки, в таком материале явно будет лишним ключ “сумки от шанель”.

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

«Яндекс.Вордстат»: руководство по работе со статистикой поисковых запросов

Метатеги. Иногда копирайтеров просят прописывать метатеги (Title, Description, Alt) заголовки и подзаголовки Н1-Н4 и далее. Поручайте это только тем копирайтерам, которые хорошо разбираются в SEO, или научите их сами: дайте в ТЗ примеры хороших метатегов и технические задания, по которым они написаны.

Title обычно дублирует заголовок Н1 и объясняет содержание статьи. В Description главное — отразить краткое описание страницы. В обоих метатегах должны содержаться ключевые слова.

Например, Title этой статьи будет «Как составить техническое задание на текст: честный взгляд с двух сторон баррикад». Description — «Эксперты агентства “Кокос” рассказали, как заказчикам и копирайтерам лучше понимать друг друга и как составить идеальное ТЗ на текст». Стандартная длина метатегов — не более 65 знаков для Title и не более 220 для Description.

Также не забывайте про метатеги Alt — подписи под иллюстрациями. В них тоже можно и нужно вставлять ключевые слова, чтобы их учитывали сервисы Google Images и «Яндекс.Картинки».

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

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

Пример структуры из реального ТЗ

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

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

Если у вас разработан официальный tone of voice, или голос бренда, укажите это в ТЗ и отметьте, что требуете полного соответствия. Если вы только нащупываете стилистику или интуитивно склоняетесь к определенному стилю (например, нравится информационный стиль или намеренно хотите эпатировать читателя), объясните это своими словами.

Мы в блоге «Кокос» пишем просто, но не примитивно. Стремимся давать концентрированную пользу, но не любим излишнюю сухость — ведь нас читают люди, а не роботы. Хотим, чтобы контент должен быть не только полезным, но и интересным, поэтому приветствуем яркую авторскую подачу. В то же время мы категорически не приемлем развязного тона, шуточек 18+, грубых провокаций.

Примеры текстов, которые нравятся

Наверняка вы изучали, что пишут популярные сайты вашей тематики или прямые конкуренты. Дайте автору референсы: приведите примеры материалов и расскажите, что именно вам в них нравится и почему.

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

Максимум, что получится на выходе, — очередной текст про перетяжку дивана, стотысячный в Рунете

Учитывайте нюансы своего бизнеса и рассказывайте об этом копирайтеру. Например:

• «В этой статье мне нравится стиль: он легкий, позитивный, молодежный. Давайте попробуем написать так же и привлечь молодую целевую аудиторию. Правда, мы так еще ни разу не пробовали, но надо же начинать. Кстати, вот наши модели спортивной одежды для молодежи».
• «В этом тексте отлично проработаны возражения покупателей. Давайте их отрерайтим под нас, но добавим несколько своих: вот вам список вопросов, которые спрашивают клиенты у наших менеджеров».
• «Здесь очень органично вставлены ссылки на модели: рука сама тянется кликнуть. Давайте и мы так сделаем. А вот карточки товаров, которые можно нативно прорекламировать в статье».
• «В этом тексте просто шикарная подборка фото! Но знаете, давайте лучше проиллюстрируем текст своими фотографиями: как раз недавно отсняли новую коллекцию, вот ссылка на диск, подберите лучшие».

Требования к оформлению

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

• Форматирование. В тексте должны быть заголовки и подзаголовки, абзацы, списки, по необходимости — врезки и цитаты
• Шрифт и кегль. Укажите предпочитаемые значения. На первый взгляд это кажется неважным, но если вы заказываете много текстов и каждый автор использует свой шрифт, у вас рано или поздно «сломаются» глаза. Намного легче, когда все тексты приведены к одному виду.
• Кавычки, тире, написание слов. И снова принцип единообразия решает: раз и навсегда укажите, что кавычки используются «елочки», а тире — длинное. Что интернет пишется с маленькой буквы, Рунет — с большой, и так далее. Этим вы сильно облегчите себе жизнь, проверено.
• Изображения и видео. Они должны быть релевантными теме, не стоковыми, с хорошим разрешением, по возможности уникальными. Если требуются авторские фото — например, вы заказываете рецепт блюда с пошаговым изображением процесса приготовления — доплатите за них, это отдельный вид работы. Никогда не выдавайте взятые откуда-то картинки и видео за свои!
• Перелинковка. Укажите, на какие страницы сайта нужно поставить ссылки, допустимы ли ссылки на другие источники.
• Таблицы, графики, диаграммы. Используйте их там, где визуальное отображение данных будет смотреться лучше, тем текстовое.

Условия и порядок работы

Эта информация обговаривается индивидуально или прописывается в договоре. Но я считаю не лишним отразить ее и в ТЗ:

• Сроки работы. Не люблю горящие дедлайны и вам не советую: автор будет торопиться и упустит важную информацию. Оптимальный срок, в течение которого можно вникнуть в тему и написать хороший материал — 4–7 дней. Если работаете с автором впервые, дайте ему пару дней про запас, чтобы в случае форс-мажора отдать задачу другому копирайтеру.
• Порядок работы. Например: автор сдает текст в Google Docs, открывает доступ на редактирование. В течение скольких-то рабочих дней редактор проверяет материал. Далее возможно два варианта: текст отправляется на правки или отправляется на верстку и публикуется на сайте.
• Стоимость. Укажите, во сколько оцениваете материал, каким образом будет начисляться оплата: на карту, на расчетный счет, на кошелек и т. д. Не забудьте упомянуть, как скоро гонорар будет выплачен: по факту написания, публикации, в конце месяца — смотря какие у вас договоренности.

Совет от редактора: если у вас команда авторов, много статей и еще нет редакционной политики, создайте ее и пропишите там все требования к материалам, о которых мы рассказали выше. Так вы сэкономите себе массу времени на проверку и сможете сразу отсеять как текущих (c’est la vie), так и потенциальных авторов, которые не справляются или не справятся с требованиями.

На этом все. Уверен, эта статья поможет заказчикам и копирайтерам лучше понимать друг друга и жить дружно. Сохраните наш материал и используйте его как основу при составлении и изучении ТЗ. Хороших вам текстов!

Что такое хорошее ТЗ на сайт? — CMS Magazine

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

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

Вводная

Зачем составлять техническое задание (ТЗ) на сайт?
Какую бы методику разработки вы не использовали, и какого бы размера ни был ваш сайт, вы в любом случае столкнетесь с вопросом: “А когда мы будем заканчивать работу, то как мы поймем, что мы ее действительно закончили?” В разработке как ПО, так и любого сайта частая проблема — никто не видит конечной точки. С одной стороны можно сказать, что конечным видением проекта должен обладать проектный менеджер. Но если конечный продукт совпадет с образом менеджера, но не совпадет с ожиданиями клиента? А если за время проекта меняется 3 менеджера?

Следствие закона Паркинсона “девяносто-девяносто”:
Первые 90% кода отнимают 90% времени разработки. Оставшиеся 10% кода отнимают вторые 90% времени разработки.
Из книги А.Купера “Психбольница в руках пациентов”.

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

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

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

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

Стоит разделять ТЗ для малых и больших сайтов. Это — два. Различия маленьких и больших проектов заключаются не в объеме документа на выходе, а в процессе их разработки. Если у вас всего 4 человека в проектной группе, все давно знают друг друга, то можно предполагать отсутствие формализма. Если же разработкой занимаются несколько “отделов”, а проектная команда состоит из более 10-ка (до бесконечности) сотрудников, то управлять этой ордой может только процесс. Процесс рождает формализацию, а формализм накладывает свой отпечаток на формат документации.

По сути, толщина документов зависит от сложности процесса в больше степени, нежели от размеров проекта.

Мы будем следовать самому сложному пути.

ТЗ отвечает на вопросы

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

1. Разработчики проекта (дизайнеры и программисты).
2. Проект-менеджер.
3. Клиент.
4. Бюрократы (они могут не участвовать в проекте, но на них тоже надо рассчитывать).

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

Для кого создается сайт и для чего?

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

Как будут решены задачи заказчика и пользователей?

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

Как будет проходить создание проекта?

Как я уже писал выше, ТЗ (а может и отдельный документ) иногда описывает процесс разработки проекта. Это совершенно необходимо, если принять во внимание, что сайт может разрабатываться по отличной от принятой в компании методики разработки, которая как правило не описывается ни одним документом. Можно сколько угодно долго мучить себя мечтами о стандартизации по ISO, но что показать дотошному заказчику?
По ГОСТу предусмотрен отдельный раздел “Этапы разработки системы”. В таком разделе можно не слишком подробно описать процесс и установить майлстоуны.

Что будет приниматься на выходе?

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

Что требуется для дальнейшего запуска проекта?

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

Больше не нужно искать и обзванивать каждое диджитал-агентство
Создайте конкурс на workspace.ru – получите предложения от участников CMS Magazine по цене и срокам. Это бесплатно и займет 5 минут. В каталоге 15 617 диджитал-агентств, готовых вам помочь – выберите и сэкономьте до 30%.
Создать конкурс →

Из чего состоит ТЗ

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

Общая информация

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

Общая информация включает в себя:

• Информацию о заказчике и исполнителе.
  Обязательно указание ответственных лиц с каждой стороны. Указываются документы, на основании которых производится разработка. Как правило, подобным документом является договор. Статус текущего документа и конфиденциальность.
• Назначение проекта.
  Указывается: для чего будет использоваться полученный продукт.
• Цели создания и задачи, которые должен решить ресурс.
  С одной стороны это довольно короткий раздел, но по важности проработки он занимает первое место. Если цели и задачи поставлены нечетко и неизмеримо, то может быть довольно сложно им следовать.
• Описание аудитории проекта.
  Критично важная информация для разработки хороших и правильных сайтов. Ясно, что информацию об аудитории не только надо правильно собирать, но еще важнее это уметь этой информацией пользоваться.
  Описание аудитории должно содержать не только информацию, которую так любят маркетологи (демография, потребности, сегментирование и т.п.), но также информация, которая пригодится дизайнерам и проектировщикам: какие задачи решает пользователь, какие его цели в работе с сайтом, что его привлекает. Алан Купер рекомендует описывать аудиторию сайта не в виде безликой массы, а выделять персонажи — описывать собирательный образ конкретных людей.
• Термины и определения.
  В большом документе вы сможете употребить огромное количество терминов и сленговых выражений, которые редко понимают специалисты по маркетингу или крупные руководители. Они могут читать этот документ, поэтому лучше предусмотреть для них список определений. Я не тешу себя надеждой, что этот список хоть раз в жизни был прочтен, но зато я могу всегда сослаться на него.

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

Эта информация собирается в рамки проекта.

Рамки проекта

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

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

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

Рамки проекта пишутся в виде сценариев работы пользователей с сайтом и описывают общую функциональность и интеракции с интерфейсом.

Информационная архитектура и интерфейс

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

Для описания ИА потребуется описывать сверху вниз:

1. Структуру сайта. Это так называемые высокоуровневые прототипы.
2. Шаблоны страниц. Низкоуровневые прототипы, описывающие непосредственно интерфейс сайта.
3. Опись контента. Табличное описание содержания каждой страницы сайта.

Структура сайта

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

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

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

Полезные советы при рисовании карты сайта:

• Не жалейте места. Старайтесь располагать блоки так, чтобы они были отделены друг от друга. Это поможет читабельности карты.
• Не мельчите. Прочитать текст, напечатанный 4 кеглем, в принципе можно, но это уже причина для ненависти.
• Выравнивайте “квадратики” страниц относительно друг друга, выстраивая в линии. Это улучшит восприятие уровней вложенности страниц.
• Не пересекайте линии. Старайтесь избегать большого количества пересечений линий связей. Если они пересекаются, то должны “перескакивать” одна над другой. Кто занимался черчением функциональных схем в университете, меня поймет.
• Подписывайте карту. Подпишите саму карту, а также отдельные блоки. Это позволит меньше путаться в дальнейшем.
• Почаще сохраняйте файл. Банально, но надо просто помнить об этом. Не стоит лишний раз вспоминать родственников разработчиков программы Visio, в сущности, они ни в чем не виноваты.

Пример карты сайта.

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

Шаблоны страниц

На уровне карты сайта каждая страница представляет для нас только “квадратик” на листе бумаги. Для дизайнера, верстальщика и программиста этого недостаточно, чтобы разработать сайт. Надо еще знать наличие и расположение блоков информации и функций на страницах сайта. Поэтому мы переходим к шаблонам сайта. В идеале каждый квадратик должен быть детализирован до схемы каждой отдельной страницы. Это прототипирование сайта. Использование прототипирования зависит от принятой схемы работы в компании-разработчике, но стоит признать, что это становится для заказчика крайне недешево.

Для упрощения выделяют ряд шаблонов интерфейса сайта, которые описываются вслед за картой сайта.

Описание шаблонов состоит из 3х частей:

1. Перечень шаблонов. Выявляются основные типы страниц и описывается их использование.
2. Типовой шаблон. Основные блоки. Описываются основные блоки страниц с целью уменьшить повторяемость информации.
3. Описание каждого шаблона согласно перечня. Шаблоны отрисовываются в любом графическом пакете (Adobe Illustrator, Adobe InDesign, MS Visio и др.), а затем дополняются кратким описанием.

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

Пример разворота из ТЗ с описанием шаблона интерфейса (вайрфрейма).

Описание контента

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

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

Хорошее описание контента залог спланированной работы на этапе запуска сайта и внесения информации.

Функционал

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

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

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

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

Требования

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

• Технические требования к системе;
• Требования к персоналу;
• Требования к надежности;
• Требования к эргономике и технической эстетике;
• Требования к защите информации от НСД;
• Требования по сохранности информации при авариях;
• Требования к видам обеспечения;
• Требования к программным средствам;
• Требования к информационному обеспечению;
• Требования к техническим средствам;

Может быть также ряд специфических требований.

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

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

Прочее

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

Что дальше?

ТЗ составлено, подписано и поступило в работу. Что дальше? Заканчивается ли работа с ним на этом этапе? Нет.

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

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

В сухом остатке

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

• Общую информацию о документе и его составителях;
• Цели и задачи сайта;
• Описание пользователей сайта, их цели и задачи;
• Рамки проекта;
• Информационная архитектура (ИА) сайта: карта сайта, шаблоны, описание интерфейса;
• Описание контента сайта;
• Описание функционала сайта;
• Описание процесса и майлстоунов, если требуется;
• Перечень всевозможных требований при разработке сайта и верификации полученной работы.

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

Полезные ссылки

Об авторе

Юрий Шиляев, г. Минск. проектировщик сайтов, консультант. Директор минского офиса компании Artics Internet Solutions.
Сайт автора: http://yuri.shilyaev.com/.

советы по составление ТЗ на разработку сайта

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

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

Зачем оно нужно

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

Начинать работу без чёткого плана — всё равно что вообще её не начинать. Есть такая поговорка: «Без внятного ТЗ результат ХЗ». Заказчик и исполнитель могут по-разному видеть даже одинаковые задачи. В результате придётся всё переделывать, а это траты времени, денег и нервных клеток.

Цели написания технического задания для сайта:

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

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

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

Виды технических заданий

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

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

В зависимости от желаний и возможностей клиента, мы выделяем 3 типа ТЗ на разработку сайта. Рассмотрим подробнее каждый из трёх типов.

Задание на разработку сайта для бизнеса

Самая распространенная задача — сайт для себя или своего бизнеса. Это может быть лендинг, корпоративный сайт, интернет-магазин. Обычно в таких случаях не нужны сложные технологические решения. Эти проекты разрабатываются на типовых системах управления типа Битрикс, Tilda, Canape CMS и др. Для них не нужно описывать подробно технические требования, например, корректную работу во всех браузерах или на мобильном устройстве. Современные платформы по умолчанию включают в себя актуальные технические возможности и типовые интерфейсы.

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

От вас требуется:

1. Рассказать о целевой аудитории сайта: кто и для чего должен прийти на ваш сайт.
2. Указать пожелания по дизайну: есть ли фирменный стиль, указать примеры сайтов, которые вам нравятся, написать пожелания по использованию фотографий и видео.
3. Написать, какие модули и функции должны быть: корзина, онлайн-оплата, интеграция с CRM, калькулятор подбора, языковая версия.
4. Расписать примерную структуру разделов на сайте: разделы о компании, структуру каталога.
5. Указать примерный объем товаров и услуг на сайте.
6. При наличии указать доменное имя и хостинг.

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

Задание на разработку сайта с нестандартным функционалом

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

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

Что будет требоваться от вас:

1. Для чего этот модуль разрабатывается: какую пользу он должен принести посетителю сайта.
2. Описание логики работы модуля: можно своими словами, к примеру, «хочу чтобы пользователь ввел в поле А данные своего адреса, а сайт в ответ выдал тип дома (кирпичный или панельный), показав это в формате таблицы».
3. Источник данных: программы, базы данных, сервисы, откуда сайт должен получать данные.
4. Примеры подобных модулей: ссылки на другие сайты, где есть аналогичные или похожие решения.
5. Пожелания по внешнему виду модуля.

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

Вот пример подобного ТЗ для модуля интеграции сайта по доставке еды с системой автоматизации ресторанов IIKO.

Задание на разработку сайта по ГОСТу

Последний вариант — это классическое техническое задание по ГОСТу. Чаще всего оно нужно при разработке проекта для государственного заказчика или для международной компании. Как правило, оно требуется для организации тендера.

Состав документа четко регламентирован ГОСТ 34.602-89 или ISO / IEC / IEEE 29148: 2018.

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

Как написать техническое задание для сайта

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

Этапы составления техзадания на разработку сайта:

1. Оценка необходимости стандарта: если нужен, читаем ГОСТ 34.602-89 «Техническое задание на создание автоматизированной системы». Если нет, пропускаем пункт.
2. Определить цели и задачи бизнеса: для чего нужен сайт, кому он будет интересен, какие материалы на нём размещать — информацию о компании, товары и т. д.
3. Анализ сайта: выявить проблемы текущего сайта при его наличии: технические — долгая загрузка, ошибки и т. д., юзабилити — насколько сайтом удобно пользоваться, качество контента.
4. Изучение продукта и рынка: его особенности, предлагаемые товары и услуги, бизнес-модель компании.
5. Работа с целевой аудиторией: разделение на сегменты, создание портрета типового клиента, путь клиента, изучение требований, потребностей и возражений ЦА.
6. Анализ конкурентов: дизайн и юзабилити их сайтов, ассортимент, контент, сервис.
7. Работа с уникальным торговым предложением: сравнение с УТП конкурентов, составление УТП для каждого сегмента ЦА.
8. Разработка структуры сайта: с учётом поисковых запросов, ассортимента, потребностей клиентов — сколько разделов и категорий, как они расположены относительно друг друга.
9. Создание прототипов страниц: схема расположения объектов на странице, подбор базовой палитры.
10. Определение объёма контента: сколько нужно фотографий, текстов, видео.
11. Утверждение технических требований: хостинги и тарифные планы, варианты доменных имён, CMS, необходимые интеграции, например, 1С-Предприятие.
12. Оценка стоимости и сроков: в зависимости от количества страниц, времени работы над сайтом, объёма контента и интеграций устанавливается цена за разработку или реконструкцию сайта.

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

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

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

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

Хотите заказать качественное техническое задание на разработку эффективного сайта? Свяжитесь с нами по телефону:+7 (800) 200-94-60, доб. 321 или оставьте запрос на электронную почту [email protected].

ТЗ на программу — Информационные технологии в профессиональной деятельности

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

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

Правила оформления

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

Лист утверждения и титульный лист

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

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

Указанной возможностью следует воспользоваться. Меньше слов – меньше вопросов.

Изменения и дополнения

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

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

Состав разделов технического задания

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

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

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

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

Содержание разделов

Задача рекомендаций — указать методику, дать практические рекомендации по разработке технического задания на программу (программное изделие) с учетом требований ГОСТ 19.201-78.

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

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

Введение

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

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

Наименование программы

Наименование – «Текстовый редактор для работы с файлами формата rtf».

Краткая характеристика области применения

Программа предназначена к применению в профильных подразделениях на объектах Заказчика.

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

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

В разделе должны быть указаны:

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

В подразделе следует привести сведения, содержащиеся в Договоре.

Основание для проведения разработки

Основанием для проведения разработки является Договор (письмо и т.д.) № 666 от 32 мартобря 2004 года (входящий № такой-то от такого-то). Договор согласован с Директором ГУП «Спецтяжмонтажстройсельхозавтоматика» Ивановым Петром Ивановичем, именуемым в дальнейшем Заказчиком, и утвержден Генеральным директором ОАО «Суперсофт» Блюмкинсом Иваном Ароновичем, именуемым в дальнейшем Исполнителем, такого-то мартобря 2004.

Удобно воспользоваться разделом «Общие сведения» ГОСТ 34.602-89, поскольку разработчик имеет полное право дополнять и удалять разделы технического задания на свое усмотрение. В то же время сведения, указанные выше, содержатся в Договоре. Следует ли приводить их в Техническом задании – зависит от конкретного случая.

Наименование и условное обозначение темы разработки

Наименование темы разработки – «Разработка текстового редактора для работы с файлами формата rtf».

Условное обозначение темы разработки (шифр темы) – «РТФ-007».

Назначение разработки

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

Функциональное назначение

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

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

Эксплуатационное назначение может трактоваться достаточно широко. Где, как, кем, с чем должна эксплуатироваться программа?

Резина одного типоразмера может успешно экслуатироваться на Жигулях и Волгах, но не на КаМАЗе. И наоборот. Но для каждого конкретного типоразмера резины можно определить ее эксплуатационное назначение.

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

Эксплуатационное назначение

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

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

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

Раздел должен содержать следующие подразделы:

1. требования к функциональным характеристикам;
2. требования к надежности;
3. условия эксплуатации;
4. требования к составу и параметрам технических средств;
5. требования к информационной и программной совместимости;
6. требования к маркировке и упаковке;
7. требования к транспортированию и хранению;
8. специальные требования.

Если существуют стандарты, содержащие общие (технические) требования к программе, системе или изделию, к примеру, «ГОСТ 12345-67. Автоматизированные информационно-измерительные системы. Общие (технические) требования», разработка технического задания существенно упрощается. Большая часть содержимого указанного стандарта просто переписывается в техническое задание.

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

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

Требования к составу выполняемых функций

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

1. функции создания нового (пустого) файла.
2. функции открытия (загрузки) существующего файла.
3. функции редактирования открытого (далее — текущего) файла путем ввода, замены, удаления содержимого файла с применением стандартных устройств ввода.
4. функции редактирования текущего файла с применением буфера обмена операционной системы.
5. функции сохранения файла с исходным именем.
6. функции сохранения файла с именем, отличным от исходного.
7. функции отправки содержимого текущего файла электронной почтой с помощью внешней клиентской почтовой программы.
8. функции вывода оперативных справок в строковом формате (подсказок).
9. функции интерактивной справочной системы.
10. функции отображения названия программы, версии программы, копирайта и комментариев разработчика.

Клише «обеспечивать возможность выполнения» применимо к современным программным средствам, разработанным с использованием графического пользовательского интерфейса. Указанные программные средства большей частью «простаивают» (idle), ожидая действий оператора.

Требования к организации входных данных

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

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

Любой файл иного формата, но с расширением rtf, открываться не должен.

Файлы http://domain.net/file.rtf или ftp://domain.net/file.rtf открываться не должны. Если файловая система отформатирована как FAT32, файлы с локального или съемного носителя, отформатированного, к примеру, в формате ext3, открываться не должны.

См. Требования к организации входных данных.

Требования к организации выходных данных

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

Требования к временным характеристикам

Требования к временным характеристикам программы не предъявляются.

Следует уточнить, предъявляет ли Заказчик требования к быстродействию программы, к примеру, за какое время программа должна стартовать, открывать и закрывать файлы заданного объема. Если Заказчик укажет конкретные цифры, следует подстраховаться и заложить в требованиях к составу и параметрам технических средств суперкомпьютер стоимостью от $2500. Правда, такую сумму придется обосновывать. Если временные характеристики для Заказчика не принципиальны, следует обязательно написать об отказе от требований к временным характеристикам (см. формулировку выше).

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

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

Надежность – вещь тонкая и очень опасная. Но перечень функций и видов их отказов, согласно п. 1.3.2. ГОСТ 24.701-86, обязан составить Заказчик и согласовать с Исполнителем. Скорее всего, дождаться от Заказчика чего-либо вразумительного не удастся. Стоит разъяснить Заказчику, что надежное функционирование программы зависит не столько от Исполнителя, сколько от надежности технических средств и операционной системы, а также предложить Заказчику ряд жестких мер для повышения надежности и устойчивости функционирования программы.

Требования к обеспечению надежного (устойчивого) функционирования программы

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

1. организацией бесперебойного питания технических средств;
2. использованием лицензионного программного обеспечения;
3. регулярным выполнением рекомендаций Министерства труда и социального развития РФ, изложенных в Постановлении от 23 июля 1998 г. «Об утверждении межотраслевых типовых норм времени на работы по сервисному обслуживанию ПЭВМ и оргтехники и сопровождению программных средств»;
4. регулярным выполнением требований ГОСТ 51188-98. Защита инфоpмации. Испытания пpогpаммных сpедств на наличие компьютеpных виpусов.

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

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

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

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

Время восстановления после отказа

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

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

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

Отказы из-за некорректных действий оператора

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

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

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

Очень опасный подраздел.

Климатические условия эксплуатации

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

Программа будет прекрасно работать от плюс 5 до плюс 35 °C при относительной влажности 90% и атмосферном давлении 462 мм.рт.ст., поскольку такие условия приблизительно соответствуют условиям эксплуатации современных компьютеров непромышленного исполнения. Но, как только в техническом задании окажется конкретика и задание будет утверждено, Заказчик получает отличный шанс заставить Исполнителя провести климатические испытания в полном объеме за счет Исполнителя.

Лет пятнадцать тому назад автор статьи, в силу своей молодости и неукротимого желания отстоять свою позицию (в техническом задании, в частности), «попал» на «климатику», причем «попал конкретно», на довольно крутом «железе». Автор статьи мигом усвоил, что такое «показать кузькину мать» и «где раки зимуют». Упаси Вас господь «попадать на климатику»!

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

Требования к видам обслуживания

См. Требования к обеспечению надежного (устойчивого) функционирования программы.

или

Программа не требует проведения каких-либо видов обслуживания.

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

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

Требования к численности и квалификации персонала

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

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

1. задача поддержания работоспособности технических средств;
2. задачи установки (инсталляции) и поддержания работоспособности системных программных средств – операционной системы;
3. задача установки (инсталляции) программы.

Конечный пользователь программы (оператор) должен обладать практическими навыками работы с графическим пользовательским интерфейсом операционной системы.

Персонал должен быть аттестован на II квалификационную группу по электробезопасности (для работы с конторским оборудованием).

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

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

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

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

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

В состав технических средств должен входить IBM-совместимый персональный компьютер (ПЭВМ), включающий в себя:

1. процессор Pentium-1000 с тактовой частотой, ГГц — 10, не менее;
2. материнскую плату с FSB, ГГц — 5, не менее;
3. оперативную память объемом, Тб — 10, не менее;
4. и так далее…

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

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

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

Требования к информационным структурам и методам решения

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

или

Требования к информационным структурам (файлов) на входе и выходе, а также к методам решения не предъявляются.

Требования к исходным кодам и языкам программирования

Исходные коды программы должны быть реализованы на языке C++. В качестве интегрированной среды разработки программы должна быть использована среда Borland C++ Buider.

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

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

Требования к защите информации и программ

Требования к защите информации и программ не предъявляются.

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

Требования к маркировке и упаковке

Программа поставляется в виде программного изделия — на дистрибутивном (внешнем оптическом) носителе (компакт-диске).

Речь идет о маркировке и упаковке дистрибутивного носителя — программного изделия (см. ГОСТ 19.004-80).

Требование к маркировке

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

Маркировка должна быть нанесена на программное изделие в виде наклейки, выполненной полиграфическим способом с учетом требований ГОСТ 9181-74.

Качество маркировки проверяется самыми изощренными способами – сначала пытаются смыть маркировку водой, затем бензином и прочими органическими растворителями. Пусть полиграфическое предприятие несет ответственность за некачественную маркировку. Задача Исполнителя — прикрыться сертификатом соответствия (затребовать сертификат у полиграфистов).

Требования к упаковке

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

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

Условия упаковывания

Упаковка программного изделия должна проводиться в закрытых вентилируемых помещениях при температуре от плюс 15 до плюс 40 °С и относительной влажности не более 80 % при отсутствии агрессивных примесей в окружающей среде.

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

Порядок упаковки

Подготовленные к упаковке программные изделия укладывают в тару, представляющую собой коробки из картона гофрированного (ГОСТ 7376-89 или ГОСТ 7933- 89) согласно чертежам предприятия-изготовителя тары.

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

Для заполнения свободного пространства в упаковочную тару укладываются прокладки из гофрированного картона или пенопласта.

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

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

Потребительская тара должна быть оклеена лентой клеевой 6-70 по ГОСТ 18251-87.

Упакованные в потребительскую тару программные изделия должны быть уложены на поддон, стянуты лентой для предотвращения потери формы груза и упакованы в полиэтиленовую пленку М 0,2 для защиты от попадания влаги.

В коробку поддона должна быть вложена товаросопроводительная документация, в том числе упаковочный лист согласно ГОСТ 25565-88.

Габариты грузового места должны быть не более 1250 x 820 x 1180 мм.

Масса НЕТТО — не более 200 кг.

Масса БРУТТО — не более 220 кг.

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

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

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

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

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

Условия транспортирования и хранения

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

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

• температура окружающего воздуха, °С — от плюс 5 до плюс 50;
• атмосферное давление, кПа — такое-то;
• относительная влажность воздуха при 25 °С — такая-то.

Специальные требования

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

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

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

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

Состав программной документации предусмотрен ГОСТ 19.101-77.

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

Состав программной документации должен влючать в себя:

1. техническое задание;
2. программу и методики испытаний;
3. руководство системного программиста;
4. руководство оператора;
5. ведомость эксплуатационных документов.

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

Ценное замечание поступило от Primadonna:

Согласно п. 2.6. ГОСТ 19.101-77 «Допускается объединять отдельные виды эксплуатационных документов (за исключением ведомости эксплуатационных документов и формуляра). Необходимость объединения этих документов указывается в техническом задании. Объединенному документу присваивают наименование и обозначение одного из объединяемых документов».

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

И еще одно ценное замечание от Primadonna:

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

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

Ориентировочная экономическая эффективность не рассчитываются.

Предполагаемое число использования программы в год – 365 сеансов работы на одном рабочем месте.

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

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

Идея позаимствована здесь.

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

Экономические преимущества разработки

Экономические преимущества разработки в сравнении с лучшими отечественными и зарубежными аналогами составит:

число рабочих мест	аналоги	разработка	экономические преимущества
10	$1500	$1000	$500
100	$11500	$1000	$10500
и так далее

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

Стадии и этапы разработки

Стадии разработки и этапы регламентированы ГОСТ 19.102-77. ГОСТ 19.102-77 не препятствует исключению отдельных стадий работ, а также объединению отдельных этапов работ.

Стадии разработки

Разработка должна быть проведена в три стадии:

1. разработка технического задания;
2. рабочее проектирование;
3. внедрение.

Этапы разработки

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

На стадии рабочего проектирования должны быть выполнены перечисленные ниже этапы работ:

1. разработка программы;
2. разработка программной документации;
3. испытания программы.

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

Содержание работ по этапам

На этапе разработки технического задания должны быть выполнены перечисленные ниже работы:

1. постановка задачи;
2. определение и уточнение требований к техническим средствам;
3. определение требований к программе;
4. определение стадий, этапов и сроков разработки программы и документации на неё;
5. выбор языков программирования;
6. согласование и утверждение технического задания.

На этапе разработки программы должна быть выполнена работа по программированию (кодированию) и отладке программы.

На этапе разработки программной документации должна быть выполнена разработка программных документов в соответствии с требованиями ГОСТ 19.101-77 с требованием п. Предварительный состав программной документации настоящего технического задания.

На этапе испытаний программы должны быть выполнены перечисленные ниже виды работ:

1. разработка, согласование и утверждение программы (в ГОСТ, похоже, опечатка – «порядка») и методики испытаний;
2. проведение приемо-сдаточных испытаний;
3. корректировка программы и программной документации по результатам испытаний.

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

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

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

Виды испытаний

Приемо-сдаточные испытания должны проводиться на объекте Заказчика в сроки…

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

Ход проведения приемо-сдаточных испытаний Заказчик и Исполнитель документируют в Протоколе проведения испытаний.

Общие требования к приемке работы

На основании Протокола проведения испытаний Исполнитель совместно с Заказчиком подписывают Акт приемки-сдачи программы в эксплуатацию.

Приложения

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

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

Если есть, почему не привести. И обязательно выложить перечень ГОСТ, на основании которых должна проводиться разработка. Например:

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

Выводы

Настоящий стандарт, несмотря на свой 25-летний возраст, позволяет разработать полноценное техническое задание на современную программу с графическим пользовательским интерфейсом. Разработчики ГОСТ 19.201-78 смотрели в будущее и учли практически все аспекты, касающиеся разработки программных средств.

Что осталось неучтенным? Сроки, объемы и этапы финансирования? Техническое задание всегда разрабатывается на основании Договора, письма и т.д. Указанные сведения должны быть отражены в Договоре.

Каковы спорные моменты? Отсутствие в стандарте конктретных требований, положим, к пользовательскому интерфейсу? Разработчиками стандарта предусмотрен раздел «Специальные требования», возможность добавления новых разделов, допустим, разделов «Дополнительные требования» или «Требования к интерфейсу».

oz / tz: 🌐 Помощник по часовому поясу

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

Просто запустите tz без аргументов, чтобы показать местное время, а также Часовой пояс UTC. Становится интереснее, когда вы проводите время зоны в программу, так как они отображаются под текущим часовым поясом.

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

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

Проверьте tz -h на наличие других флагов.

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

Если для вашей архитектуры предусмотрена сборка, вы можете напрямую загрузить релиз, но никто не пострадает, если вы строите из исходников, так как только На данный момент доступны сборки linux / amd64.

Пакеты

Отвар

Brew имеет пакет tz: brew install tz

Archlinux

Если вы пользователь Archlinux, также доступны пакеты:

• tz следует за релизами и,
• tz-git строит основную ветку git.

TZ использует стандартные часовые пояса, как описано здесь. Вы можете указать, какие часовые пояса вы хотите отображать, установив TZ_LIST переменная среды. Ваше местное время всегда будет отображается.Итак, если вы хотите отображать местное время + время в Калифорния и Париж, вы должны установить TZ_LIST на США / Тихоокеанский регион; Европа / Париж

Псевдоним зоны

tz настраивается только через TZ_LIST , и это ограничивает нас tz имена баз данных, но вы можете использовать псевдонимы для этих имен, используя специальное значение: tz name, за которым следует ; и ваш псевдоним:

TZ_LIST = "Европа / Париж, офис в регионе EMEA; США / Центральная часть, офис в США"

Вам нужна последняя версия go с поддержкой модулей:

  git clone https: // github.com / oz / tz
cd tz
иди строи
  

Лицензия GPL3.

Copyright (c) 2021 Арно Бертомье

SonicWall TZ 105 Wireless Series Unified Threat Management Firewall

Поддержка

¹ Методики тестирования: максимальная производительность согласно RFC 2544 (для межсетевого экрана).Фактическая производительность может варьироваться в зависимости от условий сети и активированных служб.
² Пропускная способность UTM / Gateway AV / Anti-Spyware / IPS измерена с помощью стандартного отраслевого теста производительности HTTP Spirent WebAvalanche и инструментов тестирования Ixia. Тестирование проводилось с несколькими потоками через несколько пар портов.
³ Фактическое максимальное количество подключений меньше, когда включены службы DPI.
⁴ Пропускная способность VPN измерена с использованием трафика UDP с размером пакета 1280 байт в соответствии с RFC 2544.
⁵ 3G-карта и модем в комплект не входят. См. Http://www.sonicwall.com/us/products/cardsupport.html для получения информации о поддерживаемых USB-устройствах.
⁶ Комплексная служба защиты от спама поддерживает неограниченное количество пользователей, но рекомендуется для 250 пользователей или меньше.
⁷ С устройствами серии SonicWall WXA.
⁸ Веб-прокси с использованием X-Forwarded-For

Модели:	TZ 105 серии	TZ 205 серии	TZ 215 серии
Версия SonicOS	SonicOS 5.8.1 и более поздние версии
Пропускная способность с отслеживанием состояния 1	200 Мбит / с	500 Мбит / с	500 Мбит / с
Пропускная способность IPS 2	60 Мбит / с	80 Мбит / с	110 Мбит / с
Пропускная способность GAV 2	40 Мбит / с	60 Мбит / с	70 Мбит / с
Пропускная способность UTM 2	25 Мбит / с	40 Мбит / с	60 Мбит / с
Максимальное количество подключений 3	8 000	12 000	48 000
Максимальное количество подключений UTM / DPI	8 000	12 000	32 000
Новые соединения / сек.	1 000	1 500	1,800
Поддерживаемые узлы	Неограниченный
Защита от атак отказа в обслуживании	22 класса DoS, DDoS и сканирующих атак
Поддерживаемые точки SonicPoints	1	2	16
Пропускная способность 3DES / AES 4	75 Мбит / с	100 Мбит / с	130 Мбит / с
VPN-туннели типа «сеть-сеть»	5	10	20
Объединенные клиентские лицензии Global VPN (максимум)	0 (5)	2 (10)	2 (25)
Объединенные лицензии SSL VPN (максимум)	1 (5)	1 (10)	2 (10)
Шифрование / аутентификация / группа DH	DES, 3DES, AES (128, 142, 256 бит), MD5, SHA-1, SHA-2 / DH Группа 1, 2, 5, 14
Виртуальный помощник в комплекте (максимум)	–	30-дневная пробная версия (1)	30-дневная пробная версия (2)
Обмен ключами	IKE, ручной ключ, сертификаты (X.509), L2TP через IPSec
Поддержка сертификатов	Verisign, Thawte, Cybertrust, RSA Keon, Entrust и Microsoft CA для SonicWall-to-SonicWall VPN, SCEP
Функции VPN	Обнаружение мертвого узла, DHCP через VPN, прохождение IPSec NAT, резервный шлюз VPN, VPN на основе маршрутов
Поддерживаемые глобальные клиентские платформы VPN	Microsoft® Windows XP, Vista 32/64-бит, Windows 7 32/64-бит
Поддерживаемые платформы SSL VPN	Microsoft Windows XP / Vista 32/64-бит / Windows 7, Mac OSX 10.4+, Linux FC3 + / Ubuntu 7 + / OpenSUSE
Платформа Mobile Connect	Apple® iOS 4.2 или выше, Google® Android ™ 4.0 или выше
Услуги глубокой проверки пакетов	Gateway Anti-Virus, Anti-Spyware, Prevention, Intrusion Intelligence and Control (TZ 215 only)
Служба фильтрации содержимого (CFS)	URL-адрес HTTP, IP-адрес HTTPS, сканирование ключевых слов и содержимого, ActiveX, Java-апплет и управление пропускной способностью для блокировки файлов cookie по категориям фильтрации, списки разрешений / запретов
Принудительный клиентский антивирус и антишпионское ПО	McAfee®
Комплексная служба защиты от спама 6	Поддерживается
Аналитика и управление приложениями	Контроль приложений		Визуализация трафика приложений и расширенный контроль приложений
Назначение IP-адреса	Статический, (DHCP, PPPoE, L2TP и PPTP-клиент), внутренний DHCP-сервер, DHCP-ретранслятор
Режимы NAT	1: 1, 1: многие, многие: 1, многие: многие, гибкий NAT (перекрывающиеся IP-адреса), PAT, прозрачный режим
сети VLAN	5, Портшилд	10, Портшилд	10, Портшилд
DHCP	Внутренний сервер, реле
Маршрут	OSPF, RIP v1 / v2, статические маршруты, маршрутизация на основе политик, многоадресная рассылка
Аутентификация	LDAP, локальная БД, RADIUS, XAUTH, X-форвардеры 8
Единый вход	AD, eDirectory, учет RADIUS, NTLM, X-Forwarders 8		AD, eDirectory, учет RADIUS, NTLM, X-Forwarders 8 , сервер терминалов и Citrix
Локальная база данных пользователей	150 пользователей
VoIP	Full H.323v1-5, SIP, поддержка привратника, управление исходящей полосой пропускания, VoIP через WLAN, безопасность глубокого контроля, полная совместимость с большинством шлюзов VoIP и коммуникационных устройств
Зона безопасности	Есть	Есть	Есть
Расписания	Есть	Есть	Есть
Объектно-групповое управление	Есть	Есть	Есть
DDNS	Поставщики динамического DNS включают: dyndns.org, yi.org, no-ip.com и changeip.com
Управление и мониторинг	Локальный интерфейс командной строки, веб-интерфейс (HTTP, HTTPS), SNMP v3; Глобальное управление с SonicWall GMS
Ведение журнала и отчетность	Analyzer, Scrutinizer, GMS, Local Log, Syslog, Solera Networks, NetFlow v5 / v9 (TZ 215), IPFIX с расширениями (TZ 215), визуализация в реальном времени (только TZ 215)
Аппаратное восстановление после сбоя	–	Активный / Пассивный	Активный / Пассивный
Защита от спама	RBL, разрешенные / заблокированные списки, дополнительная служба комплексной защиты от спама SonicWall 6
Балансировка нагрузки	Да, исходящие и входящие
Стандарты	TCP / IP, UDP, ICMP, HTTP, HTTPS, IPSec, ISAKMP / IKE, SNMP, DHCP, PPPoE, L2TP, PPTP, RADIUS, IEEE 802.3
Поддержка ускорения WAN 7	Да, с устройствами SonicWall WXA
Стандарты	802.11b / г / п	802.11a / b / g / n (3×3)	802.11a / b / g / n (3×3)
Стандарты безопасности беспроводной связи	WEP, WPA, WPA2, 802.11i, TKIP, PSK, 02.1x, EAP-PEAP, EAP-TTLS
Виртуальные точки доступа (VAP)	До 8
Антенны	Двойной, съемный, сдвоенный	Triple: 2 внешних съемных, 1 внутренний	Тройной, съемный, внешний
Мощность радио: 802.11b / 802.11g / 802.11n	18 дБм макс. / 18 дБм при 6 Мбит / с, 15 дБм при 54 Мбит / с	15,5 дБм макс. / 18 дБм макс. / 17 дБм при 6 Мбит / с, 13 дБм при 54 Мбит / с
Мощность радио: 802.11a / 802.11b / 802.11g / 802.11n	–	15,5 дБм макс. / 18 дБм макс. / 17 дБм при 6 Мбит / с, 13 дБм при 54 Мбит / с
Мощность радио: 802.11n (2,4 ГГц) / 802.11n (5,0 ГГц)	19 дБм MCS 0, 12 дБм MCS 15	19 дБм MCS 0, 11 дБм MCS 15/17 дБм MCS 0, 12 дБм MCS 15
Чувствительность радиоприема: 802.11a / 802.11b / 802.11g	-90 дБм при 11 Мбит / с / -91 дБм при 6 Мбит / с, -74 дБм при 54 Мбит / с	-95 дБм MCS 0, -81 дБм MCS 15 / -90 дБм при 11 Мбит / с / -91 дБм при 6 Мбит / с, -74 дБм при 54 Мбит / с
Чувствительность радиоприема: 802.11n (2,4 ГГц) /802.11n (5,0 ГГц)	-89 дБм MCS 0, -70 дБм MCS 15	-89 дБм MCS 0, -70 дБм MCS 15 / -95 дБм MCS 0, -76 дБм MCS 15
Интерфейсы	(5) 10/100 Fast Ethernet, 1 USB, 1 консоль	(5) 10/100/1000 Медный гигабит, 1 USB, 1 консоль	(7) 10/100/1000 Медный гигабит, 2 USB, 1 консоль
Процессор	Одноядерный	Двухъядерный	Двухъядерный
Флэш-память / RAM	32 МБ / 256 МБ	32 МБ / 256 МБ	32 МБ / 512 МБ
3G беспроводной / модем 5	Поддерживается утвержденными адаптерами 5
USB-порты	1	1	2
Потребляемая мощность	от 100 до 240 В переменного тока, 50-60 Гц, 1 А
Макс.потребляемая мощность	5.2 Вт / 7,0 Вт	6,4 Вт / 10,5 Вт	9,0 Вт / 12,0 Вт
Общее тепловыделение	17,8 БТЕ / 23,7 БТЕ	21,9 БТЕ / 35,8 БТЕ	30,6 БТЕ / 41,4 БТЕ
Сертификаты	VPNC, межсетевой экран ICSA 4.1
Ожидается сертификация	EAL4 +, FIPS 140-2, уровень 2, IPv6, фаза 1, IPv6, фаза 2
Размеры	5.555 x 1,42 x 7,48 дюйма (14,1 x 3,6 x 19 см)	5,555 x 1,42 x 7,48 дюйма (14,1 x 3,6 x 19 см)	7,125 x 1,5 x 10,5 дюйма (18,1 x 3,81 x 26,67 см)
Вес	0,75 фунта / 0,34 кг 0,84 фунта / 0,38 кг	0,75 фунта / 0,34 кг 0.84 фунта / 0,38 кг	1,95 фунта / 0,97 кг 2,15 фунта / 0,97 кг
Соответствие основным нормативным требованиям	FCC, класс A, CES, класс A, CE, C-Tick, VCCI, соответствие требованиям MIC, NOM, UL, cUL, TUV / GS, CB, NOM, WEEE, RoHS
Окружающая среда / влажность	40-105 ° F, 0-40 ° C / 5-95% без конденсации
МТБ	28 лет / 15 лет

Анализ бинарной системы TZ Fornacis

A&A 617, A36 (2018)

Анализ двойной системы TZ Fornacis

Дж.Higl ¹ , L. Siess ^{2 , 1} , A. Weiss ¹ и H. Ritter ¹

¹ Институт астрофизики им. Макса Планка, Karl-Schwarzschild-Str. 1, 85748 Гархинг, Германия
электронная почта: [email protected]
² Institut d’Astronomie et d’Astrophysique, Université Libre de Bruxelles ULB, CP 226, 1050 Брюссель, Бельгия

Поступило: 27 Март 2018 г.
Принято: 6 июнь 2018 г.

Аннотация

Контекст .TZ Fornacis (TZ For) — это развитая отдельная двойная система, которую сложно моделировать и интерпретировать, но она очень полезна для проверки теории и физики звездной эволюции.

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

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

Результатов . Мы успешно получили два разных решения модели TZ For. Оба зависят от избегания длительной эволюции на первой гигантской ветви и подразумевают достаточно большое конвективное ядро ​​на главной последовательности. TZ For можно последовательно смоделировать как обособленную двойную систему, вызывая либо значительный выброс за пределы ядра, либо усиленную приливом потерю массы ветром вдоль ветви красных гигантов.Однозначно исключить эволюцию с переполнением лепестков Роша.

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

Ключевые слова: звезды: эволюция / двойные системы: затмение

© ESO 2018

1. Введение

TZ Fornacis (TZ For; HD 20301) — это затменная двойная двойная линия, которая фигурирует в каталоге FK 4 Фрике (1963).Андерсен и Нордстром (1983) обнаружили, что обе звезды имеют схожие спектральные классы, и первоначально классифицировали их как звезды G2 III. Затмения глубиной около 0,15 звездной величины были фотометрически обнаружены Олсеном (1977), который также подтвердил, что эта система альгольтипа состоит из двух похожих ранних G-звезд. Андерсен и др. (1984) представили предварительные данные для TZ For, показывающие, что обе звезды имеют массы, близкие к 2 M _⊙ , причем первичная звезда — гигант G5, а вторичная — слегка эволюционировавшая после главной последовательности звезда спектрального класса F7.В то время TZ For была второй двойной двойной системой после Капеллы с определенными массами, но первой затменной (Olsen 1977) и, следовательно, с гораздо более точно известными массами. Предполагалось, что первичная обмотка по совпадению изохрон (на 1,2 млрд лет) находится на первой гигантской ветви. Вторичная обмотка, как уже было известно, быстро вращалась.

Андерсен и др. (1991) обновили данные наблюдений с помощью спектроскопических измерений орбиты, спектрального анализа химического состава и полной фотометрической кривой блеска ubvy .Полученные массы 2,05 ± 0,06 M _⊙ и 1,95 ± 0,03 M _⊙ , а также радиусы 8,32 ± 0,12 R _⊙ и 3,96 ± 0,09 R _⊙ составили в пределах ошибок, что согласуется с предыдущими определениями, но с увеличением точности вдвое. Период обращения 75,7 суток, орбита круговая. Было обнаружено, что вращение первичной обмотки синхронизировано примерно на 4 ± 1 км с ^-1 , в то время как вторичная вращается со скоростью 42 ± 2 км с ^-1 , примерно в 16 раз быстрее, чем требуется для синхронизации с орбитальным периодом.Эффективные температуры также были приблизительно подтверждены при 5000 К и 6300 К. В то время как вторичный компонент хорошо соответствовал эволюционному треку в возрасте 1,16 × 10 ⁹ год, модель для вторичного элемента требует возраста на 10% выше, чтобы соответствовать наблюдаемому. радиус и расположение в диаграмме Герцшпрунга-Расселда (HRD). Однако Андерсен и др. (1991) уже подозревали, что модели с выходом за пределы сердечника позволят получить удовлетворительное совпадение. В этом случае первичный элемент достигает фазы горения гелия в ядре и располагается в так называемом «сгустке».Это решение также обеспечивает естественное объяснение синхронизации первичной обмотки и приводит к увеличению возраста системы до 1,75 млрд лет. Авторы также упоминают, что главная звезда не превысила бы своего критического радиуса Роша, даже в самой яркой позиции ветви красных гигантов (RGB). Однако, используя другой набор эволюционных треков, который также включал выход за пределы, они не смогли найти удовлетворительного соответствия.

С тех пор TZ For неоднократно использовался в качестве строгого теста для моделей звездной эволюции, всегда отмечаясь как исключительная система из-за ее широкой орбиты и продвинутого эволюционного состояния первичной звезды.В частности, что касается вопроса о конвективном превышении, это был любимый объект. Хотя Pols et al. (1997) нашли в качестве лучшего решения модель без выхода за пределы, они отметили, что в этом случае первичный сигнал все еще будет находиться на RGB, и его синхронизацию будет трудно объяснить (см. Раздел 2). Следовательно, они сочли модель, включающую перескакивание, более привлекательной, которая, согласно с Андерсеном и др. (1991) помещает первичный элемент в группу. Напротив, Stancliffe et al.(2015) выбирают решение RGB для этого «проблемного» объекта, которого они достигают с большим количеством отклонений, чем для большинства других 12 отдельных затменных двойных систем, которые они исследовали.

С очень точным определением массы Gallenne et al. (2016), Валле и др. (2017) провели обширный анализ TZ For с целью «калибровки» количества перерегулирования. Параметры их лучшего решения были использованы Higl & Weiss (2017) в их собственном коде и привели к противоречивому результату: первичная обмотка, находящаяся сейчас в фазе горения гелия в ядре, превысила бы свой объем Роша во время восхождения по RGB, нарушая фундаментальное предположение всех этих исследований о том, что система остается обособленной.Это не означает, что то же самое произошло в моделях Valle et al. (2017), где они принимают другое описание выхода за пределы без функции отсечения (см. Обсуждение в разделе 3), но поскольку в этой статье нет комментариев о максимальном радиусе, достигаемом различными моделями по отношению к радиусу Роша, неясно, нарушали ли это необходимое условие лучшие решения или какие-либо другие случаи ¹ . В любом случае вопрос о переполнении лепестка Роша не рассматривался при оценке вероятности.Отметим, что во многих цитируемых статьях химический состав рассматривался как (в определенных пределах) регулируемый параметр, в то время как Higl & Weiss (2017) использовали литературные значения, включая ошибки. В разд. 3 мы представим собственное моделирование двух компонентов TZ For, следуя в основном подходу Higl & Weiss (2017). В таблице 1 мы суммируем параметры системы по умолчанию, использованные в наших расчетах. Наш выбор идентичен выбору Валле и др. (2017). Отклонения будут явно указаны в тексте.

Мы завершаем этот обзор предыдущих исследований системы TZ For включением работы Eggleton & Yakut (2017), которая смоделировала оба компонента одновременно, включая эффекты приливного взаимодействия. Опять же, первичный элемент был помещен в фазу комкования, но, что удивительно, стандартная скорость потери массы должна быть уменьшена в 20 раз для успешного моделирования. Аналогичное расследование будет содержаться в разд. 4.

В следующем разделе (Раздел 2) будут обсуждаться исключительные свойства двойной системы, включая скорости вращения обеих звезд и последствия для предыдущей истории TZ For.Короче говоря, проблема моделирования этой системы заключается в том, что синхронизированное вращение первичной обмотки требует эффективного крутящего момента, достигаемого, когда звезда становится красным гигантом. Однако первичный элемент должен избегать переполнения лепестков Роша (RLOF), потому что система пост-массообмена будет либо демонстрировать экстремальное соотношение масс, которое сильно не согласуется с фактическим, либо даже приведет к слиянию. Требование одновременного возраста для обоих компонентов дополнительно ограничивает возможные решения и требует очень специфического набора параметров системы.После представления наших успешных моделей в разделах. 3 и 4 и обсуждение неопределенностей, выводы завершат статью в разд. 5.

2. Вращение и массообмен

2.1. Вращение

Синхронное вращение первичного звена полностью объясняется его эволюционной историей и эффектами приливного взаимодействия, учитывая его структуру оболочки (конвективную) и относительно большой радиус R ₁ в единицах орбитального разноса a , R ₁ / a = 0.069. Это, в свою очередь, также означает, что у нас нет никакой информации о ротации первичного звена, когда оно было на главной последовательности.

Что касается скорости вращения второстепенного, то здесь дело обстоит иначе. Поскольку эта звезда только что достигла финальной фазы центрального горения водорода (см. Раздел 3), ее эффективная температура всегда была достаточно высокой, чтобы она сохраняла по существу радиационную оболочку. Следовательно, учитывая его небольшой относительный радиус R ₂ / a (текущее значение 0.033, а на главной последовательности 0,0070), приливное взаимодействие никогда не было значимым. Как следствие, мы можем предположить, что его угловой момент вращения не сильно изменился во время его эволюции от ранней главной последовательности. Этот факт позволяет нам теперь оценить скорость вращения вторичного компонента на главной последовательности по его текущей скорости вращения v _{вращений, 2} = 42 км с ^-1 .

Если мы предположим, что звезда из-за слабого приливного взаимодействия продолжала вращаться как твердое тело, то сохранение углового момента дает следующую оценку скорости вращения вторичного компонента на главной последовательности нулевого возраста (ZAMS) 🙁 1 )

Здесь r _{g, 2} и r _{g, 2, ZAMS} — радиусы инерции, где r _g определяется формулой (2)

, где I — момент инерции. R ₂ и R _{2, ZAMS} — соответствующие радиусы, и v _{rot, 2} наблюдаемая скорость вращения вторичной звезды. Из нашей звездной модели 1,95 M _⊙ получаем и r ² _{г, 2, ZAMS} = 0,045. Таким образом, предполагая вращение твердого тела, мы оцениваем скорость вращения вторичной обмотки на ZAMS как v _{rot, 2, ZAMS} ≈ 59 км с ⁻¹ .Это соответствует периоду вращения P _{rot, 2, ZAMS} ≈ 1,3 дня.

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

Это соответствует периоду вращения на ZAMS P _{rot, 2, ZAMS} ≈ 0.69 дн.

Эти оценки говорят нам о том, что вторичный элемент вращался в высокой степени сверхсинхронно на главной последовательности с, предполагая вращение твердого тела, P _{rot, 2, ZAMS} / P _orb ≈ 0,017 или P _{rot, 2, ZAMS} / P _orb ≈ 0,0091, если удельный угловой момент поверхностных слоев сохраняется. Каким бы быстрым ни было это вращение, оно все еще намного ниже критической скорости вращения. Если критическая угловая частота вращения определяется как Ω _{крит, 2} = ( GM ₂ / R ₂ ³ ) ^1/2 , наши оценки дают на главной последовательности Ω _{rot , 2} / Ом _{крит, 2} ≈ 0.12 в случае вращения твердого тела, или Ω _{rot, 2} / Ω _{крит, 2} ≈ 0,22 в другом случае. Таким образом, кажется, что скорость вращения вторичной обмотки на главной последовательности была на удивление высокой, но все же значительно ниже критической. Насколько это верно и для конвективного ядра, конечно, нельзя вывести из имеющихся данных. Однако, как мы показали, вторичный элемент мог вращаться довольно быстро на главной последовательности, и поэтому на его эволюцию могло повлиять быстрое вращение ядра, которое, однако, мы не моделируем в данной статье.

2.2. Массообмен

Модели для TZ Для вовлечения переполнения лепестка Роша в качестве первичного подъема, RGB непригодны по следующим причинам: если первичный контур TZ For действительно претерпел даже небольшую потерю массы из-за переполнения лепестка Роша, то его начальное соотношение масс q _i = M _{1, i} / M _{2, 1} было бы больше, чем его текущая стоимость, то есть q _i > q = 1.057. Теперь хорошо известно, что двойные системы с отношением масс q _i > 1 и с главной звездой, заполняющей ее критический объем Роша во время фазы, когда она имеет глубокую внешнюю конвективную оболочку, как, например, в случае в то время как звезда поднимается по гигантской ветви на пути к воспламенению центрального горящего гелия, они очень нестабильны по отношению к неуправляемому переносу массы (см., например, Ge et al. 2015; Павловский и Иванова 2015). Как следствие, скорость массопереноса значительно вырастет за короткий промежуток времени по сравнению с эволюционной шкалой времени звезды-донора.В конце концов, скорость массопереноса достигнет значения порядка — M ₁ ≈ M ₁ / τ _conv ≈ M _⊙ / год, где τ _conv — шкала времени конвективного оборота в оболочке звезды с потерей массы.

В качественном отношении результат такой эволюции, иногда называемой конвективным массопереносом случая B, хорошо известен. Такие системы входят в эволюцию общей оболочки, в которой ядро ​​основной звезды и звезды-компаньона закручиваются по спирали в общую оболочку, которая, в свою очередь, формируется бывшей конвективной оболочкой звезды-донора.Результат такой эволюции зависит от того, достаточно ли энергии, высвобождаемой в процессе нарастания спирали (в основном гравитационная энергия связи двойной и энергия рекомбинации оболочки), для развязывания общей оболочки (см., Например, Иванова и др., 2013 г.) ). Если оболочка может быть успешно выброшена, результатом эволюции общей оболочки будет короткопериодическая отдельная двойная звезда, состоящая из ядра бывшей первичной и практически неизменной вторичной звезды. С другой стороны, если выброс оболочки не удается, двойная система сливается и в конечном итоге образует единую звезду.Применяя стандартные методы, как, например, подробно описано в Ivanova et al. (2013), чтобы оценить результат эволюции общей оболочки в нашем интересующем случае, мы обнаружили, что предполагаемый прародитель TZ For, как только он войдет в RLOF, слился бы и превратился в единую звезду. Следовательно, массоперенос через RLOF во время RGB-фазы первичной обмотки можно безопасно исключить.

3. Две одиночные звезды

3.1. Физика ввода

Мы используем Код эволюции звезд Гархинга (GARSTEC; Weiss & Schlattl, 2008) для создания двух независимых моделей одиночных звезд с целью воспроизведения измеренных фундаментальных параметров, перечисленных в таблице 1.Расчеты GARSTEC рассматривают эволюцию двух звезд по отдельности, предполагая постоянную орбиту двойной системы. Чтобы проверить справедливость этого предположения, мы провели моделирование с помощью BINSTAR (раздел 4), используя ту же физику входных данных. Наши расчеты показывают, что в отсутствие RLOF и потери массы ветром орбитальный период остается слабым под влиянием приливов. Причина в том, что большая часть углового момента находится на орбите, а не в спинах звезд. Следовательно, предположение о том, что система остается обособленной, оправдано, а эволюция невзаимодействующих одиночных звезд является допустимым подходом.

Все вычисления начинаются с предглавной последовательности. Параметр длины смешения равен α _mlt = 1,74, полученный в результате стандартной калибровки солнечной модели. Внешнее граничное условие — серая атмосфера Эддингтона. Как и у Valle et al. (2017) мы рассматриваем солнечный состав Asplund et al. (2009), но также сравниваем наши результаты с моделями, рассчитанными с использованием солнечного состава Grevesse & Noels (1993). Таблицы непрозрачности были рассчитаны для тех же относительных содержаний металлов и представляют собой комбинацию таблиц OPAL для высоких температур (Iglesias & Rogers, 1996), дополненных при низких температурах молекулярными непрозрачностями Александера и Фергюсона штата Уичито (Ferguson et al.2005). Уравнение состояния также является OPAL (Rogers & Nayfonov 2002, выпуск 2005). За исключением обновленной скорости реакции ¹⁴ N ( p , γ ) ¹⁵ O (Marta et al. 2008), мы берем наши скорости реакции из сотрудничества NACRE (Angulo et al. 1999). За всеми остальными деталями кода и физики ввода мы отсылаем читателя к Weiss & Schlattl (2008).

Наше описание устранения превышения реализовано в соответствии с Freytag et al. (1996), где предполагается, что перерегулирование является диффузионным процессом, с коэффициентом диффузии D ( z ), определяемым по формуле (4)

, где z — расстояние до границы Шварцшильда, высота шкалы давления на конвективной границе, а D ₀ = 1/3 ν .значение коэффициента конвективной диффузии, где v ₀ — это скорость конвективных массивов массы вблизи конвективной границы, полученная из теории длины смешения. Чтобы избежать нефизически большого перерегулирования для небольших конвективных ядер, возникающего из-за расходящейся шкалы давления около центра звезды, наша реализация модифицирована геометрическим ограничением области перерегулирования. Мы ограничиваем масштаб в формуле. (4) относительно радиальной протяженности конвективной зоны ΔR _CZ , заменив ее на (5)

Это (искусственное) обрезание позволяет нам моделировать морфологию выключения старых рассеянных скоплений и гарантирует, что конвективное ядро ​​во время эволюции Солнца (и других звезд в этом диапазоне масс) перед главной последовательностью исчезает (Schlattl & Weiss 1999).В нашем моделировании по умолчанию мы применяем это перерегулирование с тем же значением f _ov на краю конвективного ядра и в основании оболочки, если не указано иное.

Альтернативный и более традиционный метод реализации перерегулирования состоит в том, чтобы просто расширить конвективно перемешанную область на фиксированную долю от высоты шкалы, так как β здесь является параметром перерегулирования. Для небольших конвективных ядер d _ov иногда ограничивается как функция начальной массы звезды (например,грамм. как у Pietrinferni et al. 2004 г.). Поскольку наша конкретная реализация отличается от кодов, используемых Valle et al. (2017), неудивительно, что модели не воспроизводят результаты этой статьи. Однако, в отличие от Valle et al. (2017), которые намеревались определить параметр превышения, который приводит к модели, наилучшим образом подходящей (для двух кодов звездной эволюции), и которые подробно исследовали влияние неопределенностей параметров, наша цель — определить необходимое условие для успешного соответствия системы и предыдущая эволюция, которая согласуется со свойствами двойной системы.Попутно отметим, что дополнительные физические детали, которые могут повлиять на воспламенение гелия в ядре, и, следовательно, максимальный радиус, достигаемый на RGB, могут отличаться между нашими моделями и моделями Валле и др. (2017). Примерами являются проводящие непрозрачности и нейтринное излучение плазмы. Также известно, что выбор граничных условий и α _mlt влияет на эволюцию HRD и, следовательно, на радиус наконечника RGB (см., Например, Cassisi 2017).

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

Как и в работе Higl & Weiss (2017), считается, что модели воспроизводят двойную систему, если они учитывают наблюдаемые радиусы для одного и того же возраста. Еще одним показателем качества модели является то, воспроизводятся ли должности в HRD в этом возрасте. Соответствие в HRD также подразумевает, что модели соответствуют более непосредственно наблюдаемым отношениям температуры и светимости (обсуждение см. В Higl & Weiss 2017).Мы не собираемся воспроизводить анализ Valle et al. (2017) и обеспечивают еще одно соответствие TZ For, но, скорее, для того, чтобы подчеркнуть, что помимо физических параметров модели, дополнительные источники неопределенностей, связанные, например, с реализацией алгоритма перерегулирования, могут иметь сильное влияние на калибровку наблюдаемых.

3.2. Влияние превышения

Чтобы начать этот анализ, мы пересчитали модели Valle et al. (2017) с GARSTEC, используя одинаковый состав для каждой модели и эквивалентные параметры превышения (таблица 2).Чтобы преобразовать параметр перерегулирования из описания перерегулирования, используемого в FRANEC (Эволюционный код Фраскати Рафсона-Ньютона; F-модели в Валле и др., 2017), к диффузионному подходу, реализованному в GARSTEC, мы аппроксимировали f _ov ≈ β /10 (см., например, Ventura 2007). M-модели были рассчитаны с помощью кода модулей для экспериментов в звездной астрофизике (MESA; Paxton et al. 2013), где используется та же реализация с превышением, что и в GARSTEC. Следовательно, значение f _ov идентично, но, тем не менее, реализация как базовой теории длины смешения, так и самого перерегулирования различается между кодами.Это особенно верно для геометрического обрезания, которое мы используем (уравнение (5)).

Valle et al. (2017) определяют общую вероятность своих моделей в зависимости от того, насколько хорошо они соответствуют наблюдаемым, включая позиции в HRD. Первичный элемент может достигать наблюдаемого радиуса на двух этапах эволюции: при подъеме первой гигантской ветви, во время горения водородной оболочки и позже, после воспламенения гелия в ядре на сгустке. Для пяти моделей с наибольшей вероятностью (F-I, F-II, F-I / II, M-I, M-II) первичный элемент действительно находится в сгустке.Повторение этих модельных вычислений с нашим кодом во всех случаях приводит к переполнению лепестка Роша, в то время как первичный преобразователь развивает RGB (см. Столбец 7 в таблице 2 и рис. 2), что неприемлемо, как показано в разд. 2.2. Причина этого несоответствия явно связана с использованием нашей процедуры отсечения, как видно из характеристик моделей G-I и F-II в таблице 2 (см. Также обсуждение ниже). Поэтому решение может заключаться в том, что первичный элемент все еще находится на RGB, но это приводит к значительному расхождению в возрасте около 10% (Кол.5 таблицы 2). Более того, положения в HRD больше не воспроизводятся: первичная обмотка холоднее, чем наблюдаемая, а вторичная слишком светится (см. Столбцы 9 и 10 в таблице 2).

Рисунок 1. Эволюция на центральной диаграмме температура-плотность первичной звезды TZ Для системы для различных значений превышения, как указано. Модели с f ov > 0,0175 избегают нецентрального вырожденного воспламенения гелия.

Рис. 2. Эволюция радиусов с использованием параметров, приведенных в Valle et al. (2017). Модели F и M показаны красным и синим цветом соответственно. Модели F и M, пронумерованные I, II и III, представлены сплошными, пунктирными и штриховыми линиями соответственно. Модель F-I / II показана пунктирной линией. Сверху вниз панели показывают эволюцию радиуса первичной обмотки относительно ее радиуса Роша, а также первичный и вторичный радиусы.Соответствующие наблюдаемые радиусы, включая диапазоны ошибок, обозначены горизонтальными серыми длинными и короткими штриховыми линиями .

В моделях F-III и M-III параметр перерегулирования увеличен, что позволяет моделям развивать более массивное ядро ​​и, следовательно, избегать RLOF. В этих случаях мы можем одновременно подобрать радиус первичной обмотки и ее положение HRD во время фазы сгустка. Тем не менее, позиция HRD вторичного уровня отсутствует для обеих моделей.Моделирование F-III все еще показывает существенное несоответствие возраста (Таблица 2), поскольку первичная обмотка достигает своего радиуса уже в самом начале горения гелия в ядре. Это не относится к первичному устройству M-III. Оба компонента установлены одного возраста.

G-модели в таблице 2 являются вариациями F- и M-моделей. Для G-I мы использовали параметры F-II, но удалили функцию отсечки в нашей реализации с превышением (уравнение (5)), тем самым уменьшив разницу в обработке перерегулирования со случаями сравнения.В этом случае первичный блок избегает переполнения, так как в этом случае смешанное ядро ​​больше с начала эволюции главной последовательности. Вторичный, рассчитанный с таким же превышением, испытывает длительную главную последовательность, достигая наблюдаемого радиуса и положения HRD в красном крючке в конце главной последовательности (см. Рис. 3). Таким образом, модель G-I хорошо подходит для обоих компонентов TZ For. Поскольку только размер смешанного сердечника имеет решающее значение для предотвращения RLOF, тот же результат может быть достигнут с активированной отсечкой за превышение, если параметр выхода за пределы увеличивается с 0.От 017 до 0,035 (модель G-II).

Рис. 3. HRD наших наиболее подходящих моделей GARSTEC. Модели для основного и дополнительного показаны красным и синим цветом, соответственно, а поля ошибок в их положениях HRD заключены в линии одного цвета. Сплошные, штриховые и пунктирные линии соответствуют моделям G-II, G-I и G-III соответственно

Поскольку первичный элемент TZ For находится в переходной области между звездами с низкой и средней массой, изменение массы ядра, вызванное пролетом, может иметь сильное влияние.В частности, звезды с малой массой, у которых развиваются вырожденные ядра, достигают гораздо больших радиусов на вершине RGB, чем их более массивные аналоги. Следовательно, при увеличении параметра выброса звезда будет развивать более массивное ядро ​​и зажигать He в центре в невырожденных условиях. Таким образом, звезда может оставаться в пределах своего радиуса Роша в любое время. Чтобы проиллюстрировать высокую чувствительность этой модели к дополнительному перемешиванию на краю конвективного ядра, мы представляем на рис. 1 эволюцию центральной температуры как функцию центральной плотности для различных величин выхода за пределы.Эти симуляции были рассчитаны с помощью кода BINSTAR с использованием предположений модели G-I. Как видно, небольшое увеличение f _ov с 0,0175 до 0,018 оказывает драматическое влияние на первичную обмотку. Эволюция переходит от вырожденного смещения центра к тихому центральному зажиганию гелия. Увеличение конвективной массы ядра, вызванное этим небольшим увеличением f _ov , очень мало, порядка 10 ⁻³ M _⊙ , но оказывает сильное влияние на радиус, который уменьшается. от 76 R _⊙ до 27 R _⊙ .Вследствие такой высокой чувствительности предельного RLOF в модели M-II можно избежать, используя либо более высокое значение α _mlt = 2, либо игнорируя выход за нижнюю границу диапазона (раздел 3.1). Оба метода значительно уменьшают разницу в возрасте для α _mlt и случай превышения до 30 и 70 млн лет соответственно, но не воспроизводят положения HRD.

Другим важным параметром является содержание гелия, которое зависит от нашего предположения о законе обогащения, Δ Y / Δ Z .Как и Валле и др. (2017) мы обнаружили, что значение два препятствует успешному моделированию, и необходимо уменьшенное значение, равное единице. Это верно для обоих вариантов солнечного состава, Asplund et al. (2009) или Grevesse & Noels (1993). Модель G-III из Таблицы 2 является примером успешного совпадения с последним выбором для солнечного состава с использованием стандартного значения Δ Y / Δ Z = 1. Его более высокая общая металличность при том же наблюдаемом [Fe / H], существенно не влияет на модели.

4. Сценарий CRAP

4.1. Физика ввода

Бинарные вычисления были выполнены с помощью кода BINSTAR с использованием той же входной двоичной физики, как описано в Siess et al. (2013). Модели рассчитаны с помощью Asplund et al. (2005) состав Солнца и длина смешения α _mlt = 1,75. Выход за пределы керна моделируется расширением перемешивания за формальную границу Шварцшильда на расстояние, как описано в Разд. 3.1. В этом моделировании мы предполагаем, что звезды вращаются как твердые тела и что ветер уносит определенный орбитальный угловой момент звезды в ее положении на орбите (так называемая мода Джинса).

4.2. Бинарные модели

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

Эта скобка закрыта, мы увидели, что во избежание переполнения полости Роша главная звезда должна вести себя как более массивная звезда, поэтому ее радиус вершины RGB меньше. Один из способов сделать это — увеличить массу сердечника во время основной последовательности, что подразумевает большое превышение сердечника. Альтернативная возможность, которую мы здесь изучаем, состоит в том, чтобы начать с первичной первичной массы с изначально более высокой массой и увеличить потерю массы. Такое усиление ветра было предложено для объяснения образования определенных двойных систем RS CVn, где первоначально более массивная первичная звезда (масса M ₁ ) теперь более развита и менее массивна, чем ее компаньон (масса M ₂ ).В отличие от Algols, эти системы не развивались через фазу массопереноса, что означает, что потеря массы ветром должна быть существенно увеличена, чтобы объяснить обратное соотношение масс ( q = M ₁ / M ₂ <1) . Чтобы решить эту проблему, Tout & Eggleton (1988b) разработали так называемый процесс усиленного истирания сопутствующего вещества (CRAP), при котором приливное трение и динамо-активность каким-то образом увеличивают скорость потери массы. Они разработали выражение для коэффициента усиления, которое имеет ту же зависимость от радиуса, что и приливный момент, действующий на звезду, что привело к эффективной скорости потери массы вида (6)

, где Ṁ — скорость потери массы по умолчанию, в нашем случае Schröder & Cuntz (2007), R — радиус звезды и R _L — радиус Роша, оцененный с использованием выражения Эгглтона (1983).Показано, что значение параметра B зависит от типа моделируемой системы. Например, Tout & Eggleton (1988b) требуется B ≈ 10 ⁴ для воспроизведения свойств Z Her, двоичного файла RS CVn, в то время как в другом контексте Siess et al. (2014) рекомендуют более высокое значение B ≈ 3,6 × 10 ⁴ , чтобы учесть высокий эксцентриситет системы IP Eri. Таким образом, этот параметр остается в значительной степени неизвестным, поскольку его значение, вероятно, зависит от структуры двух звезд.Следует также отметить, что сценарий с усилением приливного ветра был предложен для объяснения свойств Алголов (Tout & Eggleton 1988a), катаклизмической переменной, подобной новой (Qian et al. 2007), для объяснения эксцентриситета бариевых звезд (Karakas et al. 2000; Bonačić Marinović et al. 2008), или как потенциальный второй параметр в формировании горизонтальной ветви шаровых скоплений (Lei et al. 2013).

Поскольку только первичная обмотка будет испытывать повышенную потерю массы, начальная вторичная масса очень близка к наблюдаемому значению и, как утверждалось ранее, необходимо сильное превышение, чтобы воспроизвести ее положение на диаграмме HR.Хорошая подгонка получается для M ₂ = 1,98 M _⊙ и β = 0,22, что очень хорошо согласуется со значениями, используемыми Claret & Gimenez (1995). Подчеркнем, что для обоих компонентов системы учитывается одинаковое количество превышений. Для первичного звена ситуация немного сложнее, потому что масса в момент, когда вторичный достигает своего положения на диаграмме HR, зависит от эффективности приливного ветра. Дискриминантный фактор обусловлен возрастным ограничением.Если первичный элемент изначально слишком массивен, даже при более сильной потере массы, он будет развиваться слишком быстро, и будет невозможно сопоставить свойства обоих компонентов одновременно. С другой стороны, при более низкой начальной первичной массе параметр CRAP должен быть уменьшен, а также количество превышений керна, чтобы избежать только что упомянутой проблемы возраста. В конце концов, для B = 0 модель должна сходиться к предыдущему решению. Так что есть некоторое вырождение в параметрах, которое, к сожалению, не снимается.Чтобы проиллюстрировать эту двойную эволюцию, мы рассмотрим систему с M _{1, i} ≈ 2,2 M _⊙ , M _{2, i} ≈ 1,98 M _⊙ , = 0,22 для обеих звезд, и B ≈ 4000. В этом исследовании мы не пытались точно подогнать под данные, что по сути не является проясняющим, а скорее, чтобы продемонстрировать последовательность этого двоичного сценария.

Эволюция системы представлена ​​на рис. 4. Во время главной последовательности медленное увеличение радиуса звезды вызывает умеренное замедление вращения звезд.В то же время потеря массы, происходящая в основном из-за более массивного компонента, приводит к небольшому увеличению орбитального периода. Когда главная звезда покидает главную последовательность (в возрасте около 995 млн лет), поверхностная скорость значительно падает, пока звезда пересекает промежуток Герцшпрунга. Когда он достигает основания RGB ( t ≈ 1,01 млрд лет), первичный элемент вращается субсинхронно и развивает расширенную конвективную область поверхности. Приливные моменты становятся эффективными, и угловой момент передается от орбиты к звезде, вызывая сокращение периода обращения.По мере того, как звезда поднимается по RGB и постепенно заполняет свою полость Роша, потеря массы усиливается, достигая значения в 60 раз выше, чем при стандартной эволюции без CRAP. Во время этого восхождения главная теряет ≈0,1 M _⊙ и из-за эффективных приливов остается синхронизированной. Возгорание происходит около t ≈ 1.0265 млрд лет и вызывает сильное сжатие звезды, которая теперь вращается сверхсинхронно. Поскольку первичный элемент сохраняет протяженную конвективную зону на поверхности, угловой момент теперь передается обратно от звезды на орбиту, что приводит к увеличению периода обращения.Во время последующей фазы горения гелия в ядре ничего не происходит, за исключением вторичной, которая теперь выходит из основной последовательности и начинает замедляться из-за расширения. В конце концов, в возрасте ~ 1.26 млрд лет обе звезды достигают своих наблюдаемых положений в HRD (рис. 5). Как указано Claret (2011), учитывая орбитальные параметры TZ For, первичный элемент всегда будет достигать синхронизации по прибытии на сгусток, независимо от его начальной скорости вращения. Это не относится к вторичной обмотке, где приливы неэффективны, и нужно учитывать начальную (ZAMS) поверхностную скорость ≈70 км с ⁻¹ , что составляет около 15% критической скорости вращения, чтобы соответствовать наблюдениям.Это значение немного выше, чем оценка, приведенная в разд. 2.1 из-за потери углового момента из-за звездных ветров и приливов.

Рис. 4. Эволюционные свойства системы 2.2 + 1.98 M ⊙ , P orb = 69 d с повышенной потерей массы и начальной скоростью вращения поверхности ZAMS 70 км с −1 . На различных панелях сплошные черные и красные точки относятся к основному и второстепенному соответственно. Сверху вниз панели показывают диаграмму Киппенхана первичной звезды ( a ), эволюцию отношения вращения к орбитальной угловой скорости ( b ) радиусов звезд ( c ) скорость вращения поверхности ( d ), период обращения ( e ) и звездные массы ( f ). Ограничения наблюдений также обозначены светлыми квадратами. Расчетный возраст системы составляет ~ 1,26 млрд лет.

Инжир.5. Эволюция на диаграмме HR системы 2.2 + 1.98 M ⊙ , P orb = 69 d с повышенной потерей массы.

5. Заключение и обсуждение

Мы представили несколько вариантов успешного моделирования отделенной затменной двойной системы TZ For, которая очень интересна из-за совершенно разных эволюционных состояний двух компонентов и множества точно измеренных свойств системы.Чтобы достичь самосогласованного решения, необходимо принять во внимание несколько ограничений: первичный элемент находится на продвинутой стадии, либо на RGB, либо уже в фазе сгустка. Наше моделирование показывает, что решение RGB сталкивается с большой проблемой, связанной с неспособностью моделей соответствовать всем свойствам системы в одном и том же возрасте. Если положения HRD совпадают, то радиусы звезд достигаются в разном возрасте, а расхождение составляет порядка 10%. Это решение также может создавать проблемы для объяснения синхронизации первичной обмотки с орбитальным движением.Таким образом, из наших исследований мы пришли к выводу, что раннее решение RGB невозможно в основном из-за разницы в возрасте. Напротив, находясь в основной фазе горения гелия на сгустке, звезда прошла гигантскую фазу с глубокой конвективной оболочкой, где равновесные приливы очень эффективны, что привело к наблюдаемой синхронизации независимо от начальной скорости вращения.

Однако во время восхождения по RGB первичный элемент может переполнить свою полость Роша, что приведет к серьезному массопереносу.Даже если два компонента не слились, как мы считаем наиболее вероятным сценарием в Разд. 2.2, окончательная масса первичной обмотки будет равна массе ядра — несколько десятых солнечной массы, что противоречит измеренной массе M ₂ . Таким образом, развитие RGB должно быть прекращено на достаточно малом радиусе. Поскольку первичная масса (2,05 M _⊙ ) находится в диапазоне масс перехода от вырожденного к невырожденному воспламенению гелия в ядре, максимальный радиус, достигаемый на RGB, сильно зависит от подробных свойств ядра в более ранние фазы.Решающей величиной является протяженность конвективного ядра или, точнее, центрально перемешанной области на главной последовательности.

Мы исследовали два варианта увеличения массы смешанного ядра: за счет увеличения начальной массы и за счет выхода за пределы конвективного ядра. В последнем случае мы проследили эволюцию обоих компонентов в предположении независимой эволюции одиночных звезд. Физические допущения были обязательно идентичными из-за очень близких звездных масс.Мы показали в Разд. 3.2 видно, что с увеличенным параметром превышения 0,035 (наше стандартное значение 0,017) система может быть приспособлена как с точки зрения радиуса, так и с точки зрения согласования HRD. В качестве альтернативы, если мы отбросим геометрическое ограничение области выхода за пределы (уравнение (5)), значение f _ov 0,017 приведет к тому же результату. Это в основном согласуется с более ранними попытками моделировать TZ For Андерсеном и др. (1991), Валле и др. (2017) и Eggleton & Yakut (2017), однако без каких-либо оговорок, упомянутых в этих документах (см.1). Мы также показали, что с использованием тех же параметров, что и у Valle et al. (2017) в нашем коде, в частности в коде их предпочтительной модели F-I, приведет к переполнению лепестка Роша, в то время как первичный поднимается по RGB, и, следовательно, к несовместимой модели. Основная причина заключается в упомянутом геометрическом вырезе для выхода за пределы небольших конвективных ядер, который реализован в GARSTEC, а не в Valle et al. (2017), но другие физические величины, которые влияют на воспламенение гелия, такие как проводящие непрозрачности или потери энергии из-за испускания нейтрино, также могут влиять на максимальный радиус, а также на детальную реализацию теории длины смешения и внешние граничные условия, предоставляемые моделью атмосферы.

Возможность неограниченного выхода за пределы (для обеих звезд) фактически согласуется с трактовкой конвективных ядер в звездах малых масс Пьетринферни и др. (2004), которые использовали линейную, зависящую от массы активацию параметра превышения между 1,1 M _⊙ и 1,7 M _⊙ . Таким образом, это указывало бы на то, что наш собственный подход к геометрическому обрезанию уравнения. (5) может быть слишком ограничительным и поддержит результат, касающийся превышения допустимого значения сердечника, сделанный Higl & Weiss (2017).В качестве альтернативы, необходимость в расширенной смешанной области может частично объясняться дополнительным эффектом перемешивания, вызванным быстрым вращением звезд на ZAMS.

Альтернативным вариантом ограничения радиуса, достигаемого на RGB, является увеличение начальной массы первичной обмотки, что также приводит к увеличению конвективного ядра. Это, однако, должно быть сделано с учетом изменения срока службы главной последовательности и, таким образом, риска одновременного возраста обоих компонентов. Мы протестировали этот вариант в разд.4, где с помощью соответствующего кода моделировалась эволюция двойной системы в целом (BINSTAR). Увеличенная потеря массы в соответствии со сценарием CRAP, разработанная Tout & Eggleton (1988b), была вызвана для уменьшения начальной первичной массы до нынешнего наблюдаемого значения. Опять же, успешная подгонка может быть достигнута с помощью этого подхода (раздел 4.2) в возрасте 1,26 миллиарда лет, чтобы сравнить с 1,29 миллиардами лет пригодности из раздела. 3.2.

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

---

¹

Судя по всему, лучшие модели решений не превышали радиуса Роша (П. Г. Прада Морони, приват. Комм.).

Благодарности

Благодарим нашего рецензента П. Г. Прада Морони за полезные и поучительные комментарии. Эта работа проводилась во время визита Л.С. в астрофизический институт Макса Планка в Гархинге. LS благодарит MPA за гостеприимство. LS — старший FRS-F.N.R.S. научный сотрудник.

Список литературы

1. Андерсен, Дж., & Нордстрем, Б. 1983, A&AS, 52, 479 [НАСА ОБЪЯВЛЕНИЕ] [Google ученый]
2. Андерсен, Дж., Клаузен, Дж. В., Нордстром, Б., и Майор, М. 1984, в Наблюдательные тесты теории звездной эволюции, под ред. А. Мэдер и А. Рензини, IAU Symp., 105, 397 [Google ученый]
3. Андерсен, Дж., Клаузен, Дж. В., Нордстрем, Б., Томкин, Дж., И мэр, М. 1991, A&A, 246, 99 [НАСА ОБЪЯВЛЕНИЕ] [Google ученый]
4. Ангуло, К., Arnould, M., Rayet, M., et al. 1999 г., Nucl. Phys. А, 656, 3 [НАСА ОБЪЯВЛЕНИЕ] [CrossRef] [Google ученый]
5. Асплунд, М., Гревесс Н. и Соваль А. Дж. 2005, в Космическое изобилие как записи звездной эволюции и нуклеосинтеза, ред. Т. Г. Барнс III, и Ф. Н. Баш, ASP Conf. Сер., 336, 25 [Google ученый]
6. Асплунд, М., Гревесс, Н., Соваль, А.Дж. И Скотт, П. 2009, ARA & A, 47, 481 [НАСА ОБЪЯВЛЕНИЕ] [CrossRef] [Google ученый]
7. Боначич Маринович, А.А., Глеббек, Э., & Полс, О. Р. 2008, A&A, 480, 797 [НАСА ОБЪЯВЛЕНИЕ] [CrossRef] [EDP Sciences] [Google ученый]
8. Кассизи, С.2017, Eur. Phys. J. Web Conf., 160, 04002 [CrossRef] [Google ученый]
9. Кларе, А.2011, A&A, 526, A157 [НАСА ОБЪЯВЛЕНИЕ] [CrossRef] [EDP Sciences] [Google ученый]
10. Кларе, А., & Хименес, A. 1995, A&A, 296, 180 [НАСА ОБЪЯВЛЕНИЕ] [Google ученый]
11. Эгглтон, П.П. 1983, ApJ, 268, 368 [НАСА ОБЪЯВЛЕНИЕ] [CrossRef] [Google ученый]
12. Эгглтон, П.П., Якут, К. 2017, МНРАС, 468, 3533 [НАСА ОБЪЯВЛЕНИЕ] [CrossRef] [Google ученый]
13. Фергюсон, Дж.W., Alexander, D. R., Allard, F., et al. 2005, ApJ, 623, 585 [НАСА ОБЪЯВЛЕНИЕ] [CrossRef] [Google ученый]
14. Фрейтаг, Б., Людвиг, Х.-Г., и Штеффен, М. 1996, A&A, 313, 497 [Google ученый]
15. Fricke, W. 1963, Veröff. Astr. Recheninst. Гейдельберг, 11 [Google ученый]
16. Галленн, А., Петржински Г., Грачик Д. и др. 2016, A&A, 586, A35 [НАСА ОБЪЯВЛЕНИЕ] [CrossRef] [EDP Sciences] [Google ученый]
17. Ге, Х., Уэббинк, Р. Ф., Чен, X., и Хан, З. 2015, ApJ, 812, 40 [НАСА ОБЪЯВЛЕНИЕ] [CrossRef] [Google ученый]
18. Гревесс, Н., & Ноэлс, A. 1993, в Происхождении и эволюции элементов, ред. Н. Пранцос, Э. Вангиони-Флам и М. Касс, 15 [Google ученый]
19. Хигл, Дж. И Вайс, А. 2017, A&A, 608, A62 [НАСА ОБЪЯВЛЕНИЕ] [CrossRef] [EDP Sciences] [Google ученый]
20. Иглесиас, К.А., и Роджерс, Ф. Дж. 1996, ApJ, 464, 943 [НАСА ОБЪЯВЛЕНИЕ] [CrossRef] [Google ученый]
21. Иванова, Н., Justham, S., Chen, X., et al. 2013, A & ARv, 21, 59 [НАСА ОБЪЯВЛЕНИЕ] [CrossRef] [MathSciNet] [Google ученый]
22. Каракас, А.И., Тоут, К. А., и Латтанцио, Дж. К. 2000, MNRAS, 316, 689 [НАСА ОБЪЯВЛЕНИЕ] [CrossRef] [Google ученый]
23. Лей, З.-X., Zhang, F.-H., Ge, H.-W., & Han, Z.-W. 2013, A&A, 554, A130 [НАСА ОБЪЯВЛЕНИЕ] [CrossRef] [EDP Sciences] [Google ученый]
24. Марта, М., Formicola, A., Gyürky, G., et al. 2008, Phys. Ред. C, 78, 022802 [НАСА ОБЪЯВЛЕНИЕ] [CrossRef] [Google ученый]
25. Ольсен, Э.Г. 1977, A&AS, 29, 313 [НАСА ОБЪЯВЛЕНИЕ] [Google ученый]
26. Павловский, К., & Иванова, Н. 2015, МНРАС, 449, 4415 [НАСА ОБЪЯВЛЕНИЕ] [CrossRef] [Google ученый]
27. Пакстон, Б., Кантиелло, М., Аррас, П. и др. 2013, ApJS, 208, 4 [НАСА ОБЪЯВЛЕНИЕ] [CrossRef] [Google ученый]
28. Пьетринферни, А., Кассизи, С., Саларис, М., & Кастелли, Ф. 2004, ApJ, 612, 168 [НАСА ОБЪЯВЛЕНИЕ] [CrossRef] [Google ученый]
29. Польс, О.Р., Тоут, К. А., Шредер, К.-П., Эгглтон, П. П., и Маннерс, Дж. 1997, MNRAS, 289, 869 [НАСА ОБЪЯВЛЕНИЕ] [CrossRef] [Google ученый]
30. Цянь, С.-B., Dai, Z.-B., He, J.-J., et al. 2007, A&A, 466, 589 [НАСА ОБЪЯВЛЕНИЕ] [CrossRef] [EDP Sciences] [Google ученый]
31. Роджерс, Ф.Дж., И Найфонов А. 2002, ApJ, 576, 1064 [НАСА ОБЪЯВЛЕНИЕ] [CrossRef] [Google ученый]
32. Шлаттль, Х., & Вайс, A. 1999, A&A, 347, 272 [НАСА ОБЪЯВЛЕНИЕ] [Google ученый]
33. Шредер, К.-П. И Кунтц, М. 2007, A&A, 465, 593 [НАСА ОБЪЯВЛЕНИЕ] [CrossRef] [EDP Sciences] [Google ученый]
34. Сисс, Л., Иззард, Р. Г., Дэвис, П. Дж., И Дешам, Р. 2013, A&A, 550, A100 [НАСА ОБЪЯВЛЕНИЕ] [CrossRef] [EDP Sciences] [Google ученый]
35. Сисс, Л., Дэвис, П. Дж., И Йориссен, А. 2014, A&A, 565, A57 [НАСА ОБЪЯВЛЕНИЕ] [CrossRef] [EDP Sciences] [Google ученый]
36. Стэнклифф, Р.Дж., Фоссати, Л., Пасси, Дж .-К., и Шнайдер, Ф. Р. Н. 2015, A&A, 575, A117 [НАСА ОБЪЯВЛЕНИЕ] [CrossRef] [EDP Sciences] [Google ученый]
37. Тут, К.А., и Эгглтон, П. П. 1988a, ApJ, 334, 357 [НАСА ОБЪЯВЛЕНИЕ] [CrossRef] [Google ученый]
38. Тут, К.А., и Эгглтон, П. П. 1988b, MNRAS, 231, 823 [НАСА ОБЪЯВЛЕНИЕ] [CrossRef] [Google ученый]
39. Валле, Г., Dell’Omodarme, M., Prada Moroni, P. G., & Degl’Innocenti, S. 2017, A&A, 600, A41 [НАСА ОБЪЯВЛЕНИЕ] [CrossRef] [EDP Sciences] [Google ученый]
40. Вентура, П.2007, в пабе EAS. Сер., Ред. К. В. Страка, Ю. Лебретон и М. Дж. П. Ф. Г. Монтейро, 26, 79 [CrossRef] [Google ученый]
41. Вайс, А., & Schlattl, H. 2008, Ap & SS, 316, 99 [НАСА ОБЪЯВЛЕНИЕ] [CrossRef] [Google ученый]

Все таблицы

Все фигуры

	Инжир.1. Эволюция на центральной диаграмме температура-плотность первичной звезды TZ Для системы для различных значений превышения, как указано. Модели с f ov > 0,0175 избегают нецентрального вырожденного воспламенения гелия.
По тексту

Рис. 2. Эволюция радиусов с использованием параметров, приведенных в Valle et al. (2017). Модели F и M показаны красным и синим цветом соответственно.Модели F и M, пронумерованные I, II и III, представлены сплошными, пунктирными и штриховыми линиями соответственно. Модель F-I / II показана пунктирной линией. Сверху вниз панели показывают эволюцию радиуса первичной обмотки относительно ее радиуса Роша, а также первичный и вторичный радиусы. Соответствующие наблюдаемые радиусы, включая диапазоны ошибок, обозначены горизонтальными серыми длинными и короткими штриховыми линиями .

По тексту

	Инжир.3. HRD наших наиболее подходящих моделей GARSTEC. Модели для основного и дополнительного показаны красным и синим цветом, соответственно, а поля ошибок в их положениях HRD заключены в линии одного цвета. Сплошные, штриховые и пунктирные линии соответствуют моделям G-II, G-I и G-III соответственно
По тексту

Рис. 4. Эволюционные свойства системы 2.2 + 1.98 M ⊙ , P orb = 69 d с повышенной потерей массы и начальной скоростью вращения поверхности ZAMS 70 км с −1 .На различных панелях сплошные черные и красные точки относятся к основному и второстепенному соответственно. Сверху вниз панели показывают диаграмму Киппенхана первичной звезды ( a ), эволюцию отношения вращения к орбитальной угловой скорости ( b ) радиусов звезд ( c ) скорость вращения поверхности ( d ), период обращения ( e ) и звездные массы ( f ). Ограничения наблюдений также обозначены светлыми квадратами.Расчетный возраст системы составляет ~ 1,26 млрд лет.

По тексту

	Рис. 5. Эволюция на диаграмме HR системы 2.2 + 1.98 M ⊙ , P orb = 69 d с повышенной потерей массы.
По тексту

Аспартам (неактивный ингредиент) — Drugs.com

1. Неактивные ингредиенты
2. аспартам

Наполнитель (фармакологически неактивное вещество)

Проведено медицинское освидетельствование Drugs.com. Последнее обновление 5 апреля 2021 г.

Что это?

Аспартам (C14h28N2O5) — это обычный подсластитель, не содержащий сахара, известный под торговыми марками Equal или NutraSweet. Он используется в фармацевтических продуктах, часто как заменитель сахара в жевательных таблетках и жидкостях без сахара. FDA одобрило использование аспартама в пищевых продуктах в 1981 году. Это искусственный подсластитель, часто используемый в качестве заменителя сахара в различных продуктах питания и напитках. С химической точки зрения аспартам представляет собой метиловый эфир фенилаланина. ^[1]

Основное беспокойство при использовании аспартама вызывают пациенты с аутосомно-рецессивной фенилкетонурией. Побочным продуктом аспартама при его расщеплении в организме является фенилаланин. Большинство людей могут метаболизировать аминокислоту фенилаланин; Однако некоторым пациентам с гомозиготной генетической предрасположенностью к фенилкетонурии или ФКУ при строгом ограничении питания следует избегать приема аспартама. FDA требует, чтобы все продукты питания и напитки, содержащие аспартам, имели это предупреждение, указанное на этикетке питания.FDA сообщило, что аспартам безопасен в качестве подсластителя общего назначения в пищевых продуктах и ​​не является канцерогенным. ^[2] Европейский пищевой код для аспартама — E951.

Головная боль — часто сообщаемый побочный эффект при приеме аспартама. Также сообщалось о нейропсихиатрических побочных эффектах при приеме более высоких доз аспартама, хотя они еще не подтверждены в контролируемых клинических исследованиях. Хроническое употребление аспартама может с большей вероятностью вызвать головные боли. FDA задокументировало судороги, и есть доказательства, что они могут быть связаны с употреблением аспартама, хотя окончательных доказательств нет.Исследования показывают, что пациентам с плохо контролируемыми «абсансами» следует избегать приема аспартама. ^[1] Краткосрочное клиническое испытание также оценивало влияние аспартама на когнитивные и поведенческие функции у детей от 3 до 10 лет. Исследование показало, что даже когда потребление превышает типичные диетические уровни, ни сахароза (сахар), ни аспартам не влияют на поведение или когнитивные функции детей. ^[3]

Лучшие лекарства с этим наполнителем

Список литературы

[1] Неактивные ингредиенты в фармацевтических продуктах: обновление.Комитет по лекарственной педиатрии 1997; 99; 268

[2] FDA США. Еда. Заявление FDA о европейском исследовании аспартама. CFSAN / Управление безопасности пищевых добавок. 20 апреля 2007 г. По состоянию на 30 марта 2012 г. 1 http://www.fda.gov/Food/FoodIngredientsPackaging/FoodAdditives/ucm208580.htm

[3] Волрайч М.Л., Линдгрен С.Д., Стумбо П.Дж. и др. Влияние диет с высоким содержанием сахарозы или аспартама на поведение и когнитивные способности детей. N Engl J Med. 1994; 330: 301-7.

Дополнительная информация

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

Заявление об отказе от ответственности за медицинское обслуживание

Как открыть файлы TZ с помощью WinZip

Что это за файл — TZ?

Архив TAR, сжатый с помощью базового алгоритма сжатия Unix, образует файл TZ. Это сокращение от .TAR.Z, поскольку оно объединяет файлы .TAR и .Z. Это собственный формат сжатия для ОС Unix. Использование файлов TZ в Unix может быть выполнено с помощью простых команд, но если кто-то хочет получить к ним доступ в Windows, для этого потребуются утилиты сжатия, такие как Winzip.

Как открыть файлы TZ

1. Сохранить.tz на рабочий стол. Если ваш сжатый файл был загружен с веб-сайта, его можно сохранить в папке «Загрузки» в ваших документах или в пользовательском каталоге.
2. Запустите WinZip из меню «Пуск» или из ярлыка на рабочем столе. Откройте сжатый файл, щелкнув Файл> Открыть. Если ваша система имеет расширение сжатого файла, связанное с программой WinZip, просто дважды щелкните файл.
3. Выберите все файлы и папки внутри сжатого файла. Или выберите несколько файлов или папок, которые вы хотите открыть, удерживая клавишу CTRL и щелкая по ним левой кнопкой мыши.
4. Щелкните «Распаковать» одним щелчком мыши и выберите «Распаковать на ПК» или «Облако» на панели инструментов WinZip на вкладке «Распаковать / Поделиться».
5. Выберите папку назначения для размещения распаковываемых файлов и нажмите кнопку «Распаковать».
6. Найдите извлеченные файлы в папке назначения.

Открытие файлов TZ в Windows или Mac

WinZip 26

• Окна 10
• Окна 8
• Окна 7
• Windows Vista
• Windows XP
• Internet Explorer 8 или новее

WinZip Mac 9

• Mac OS X 10.8, 10.9 или 10.10
• 64-разрядный процессор Intel
• поддерживает дисплеи Apple Retina

WinZip открывает и извлекает файлы сжатого архива TZ — и многие другие форматы.

Мы разработали WinZip для открытия и извлечения из самого широкого диапазона форматов файлов, включая все следующие:

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

Купить WinZip сейчас

Canon U.S.A., Inc. | МФУ imagePROGRAF TZ-30000 Z36

Тип принтера

Пятицветный 36-дюймовый принтер

Количество форсунок

Всего: 15360
MBK: 5120 сопел
C, M, Y, BK: 2560 сопел каждое

Шаг сопла

1200 dpi
Обнаружение и компенсация несрабатывания сопла

Разрешение печати (до)

Разрешение печати (до): 2400 × 1200 точек на дюйм (макс.)

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

Windows® 7, 8.1, 10 (32/64-разрядная)
Windows® Server 2008 R2, 2012, 2012 R2, 2016 (64-разрядная)
MacOS 10.12.6 и новее

Стандартные интерфейсы

Высокоскоростной USB 2.0
10/100/1000 Base-T / TX

Размер капли чернил

5 пиколитров

Емкость чернил

330 мл или 700 мл на цвет

Размер капли чернил

Пигментные чернила

Набор цветов

Матовый черный, черный, голубой, пурпурный, желтый

Буферный барабан

128 ГБ (виртуальный) 2 ГБ (физический)

Ширина носителя

Отдельные листы — 8–36 дюймов
Роликовая подача — 8–36 дюймов

Толщина материала

0.07-0,8 мм (2,8-31,4 мил)

Максимальная длина печати рулона

Рулонная подача — 59 футов (18 метров)

Максимальный диаметр рулона носителя

6,9 дюйма (175 м)

Ширина печати без полей

Все размеры

Метод подачи бумаги

Рулонная подача: два рулона, фронтальная загрузка
Отдельные листы: фронтальная загрузка

Языки

SGRaster, HPGL / 2, HP-RTL, PDF, JPEG

Уровень шума Приблизительно

В рабочем состоянии: не более 52 дБ (А)
В режиме ожидания: не более 35 дБ (А)
Акустическая мощность: 7.0 бел или меньше

Физические размеры

47 x 61 x 38 дюймов (основной блок + подставка для вывода бумаги + верхняя направляющая вывода)

Источник питания

AC-100-240V (50-60 Гц)

Потребляемая мощность

Максимум: 157 Вт или меньше
Режим ожидания 2.0 Вт или меньше
В выключенном состоянии: 0,3 Вт или меньше (в соответствии с распоряжением правительства)

Операционная среда

Температура: 59 ° -86 ° F (15 ° -30 ° C)
Относительная влажность: 10-80% (без конденсации)

Детали, заменяемые пользователем

Печатающая головка (PF-06) Картридж для отработанных чернил (MC-30) Чернильницы (PFI-340 / PFI-740)

Доступно программное обеспечение

Менеджер по бухгалтерскому учету, Canon Print Service, Консоль управления устройством, Direct Print Plus, Free Layout Plus, Драйвер принтера Canon, Инструмент настройки мультимедиа, PosterArtist Lite для Windows, Оптимизированный драйвер для AutoCAD, CPP Publisher Select, CPP Driver Select

Установите py37-tz на macOS с MacPorts

pytz переносит базу данных Olson tz в Python.Эта библиотека позволяет точные и кросс-платформенные расчеты часовых поясов.

pytz переносит базу данных Olson tz в Python. Эта библиотека позволяет точные и кросс-платформенные вычисления часовых поясов.

Чтобы установить py37-tz, вставьте его в терминал macOS после установки MacPorts

sudo порт установить py37-tz Копировать

Дополнительные инструкции

• Если это еще не сделано, установите MacPorts.
• Чтобы установить py37-tz, выполните следующую команду в терминале macOS (Приложения-> Утилиты-> Терминал)

  sudo порт установить py37-tz Копировать

• Чтобы узнать, какие файлы были установлены py37-tz, запустите:

  содержимое порта py37-tz Копировать

• Для более позднего обновления py37-tz, запустите:

  sudo port selfupdate && sudo port upgrade py37-tz Копировать

.