Тз образец: Стандарты и шаблоны для ТЗ на разработку ПО / Хабр

Leave a Comment / Разное / By /

Содержание

Стандарты и шаблоны для ТЗ на разработку ПО / Хабр

Введение


Недавно ко мне обратились, чтобы я посоветовал стандарты для написания технического задания (ТЗ) на разработку автоматизированных систем (АС) и программного обеспечения (ПО). Вот думаю, сейчас зайду в Яндекс, найду подходящую статейку и отправлю её. Но не тут-то было! Одной статьи, где перечисляются стандарты для ТЗ, включая шаблоны и примеры готовых документов, я не нашел. Придется сделать такую статейку самому…

И так, основные стандарты, методологии и своды знаний, где упоминается ТЗ или SRS (Software (or System) Requirements Specification):

• ГОСТ 34
• ГОСТ 19
• IEEE STD 830-1998
• ISO/IEC/ IEEE 29148-2011
• RUP
• SWEBOK, BABOK и пр.

ГОСТ 34


ГОСТ 34.602-89 Техническое задание на создание автоматизированной системы регламентирует структуру ТЗ на создание именно СИСТЕМЫ, в которую входят ПО, аппаратное обеспечение, люди, которые работают с ПО, и автоматизируемые процессы.

Согласно ГОСТ 34 техническое задание должно включать следующие разделы:

1. Общие сведения
2. Назначение и цели создания (развития) системы

3. Характеристика объектов автоматизации
4. Требования к системе
5. Состав и содержание работ по созданию системы
6. Порядок контроля и приемки системы
7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие
8. Требования к документированию
9. Источники разработки

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

ГОСТ 19


“ГОСТ 19.ххх Единая система программной документации (ЕСПД)” — это комплекс государственных стандартов, устанавливающих взаимоувязанные правила разработки, оформления и обращения программ (или ПО) и программной документации. Т.е. этот стандарт относится к разработке именно ПО.
Согласно ГОСТ 19.201-78 Техническое задание, требования к содержанию и оформлению техническое задание должно включать следующие разделы:

1. Введение;
2. Основания для разработки;
3. Назначение разработки;
4. Требования к программе или программному изделию;
5. Требования к программной документации;
6. Технико-экономические показатели;

7. Стадии и этапы разработки;
8. Порядок контроля и приемки;
9. Приложения.

Естественно ГОСТ 34 (и 19) уже устарели, и я не люблю их использовать, но при правильном интерпретации стандартов, можно получить хорошее ТЗ, см. Заключение.

IEEE STD 830-1998


Достаточно хорошее определение стандарта 830-1998 — IEEE Recommended Practice for Software Requirements Specifications дано в самом его описании:

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

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

1. Введение

  • 1. Назначение
  • 2. Область действия
  • 3. Определения, акронимы и сокращения
  • 4. Ссылки
  • 5. Краткий обзор

2. Общее описание
  • 1. Взаимодействие продукта (с другими продуктами и компонентами)
  • 2. Функции продукта (краткое описание)
  • 3. Характеристики пользователя
  • 4. Ограничения
  • 5. Допущения и зависимости

3. Детальные требования (могут быть организованы по разному, н-р, так)
  • 1. Требования к внешним интерфейсам
    • 1. Интерфейсы пользователя
    • 2. Интерфейсы аппаратного обеспечения
    • 3. Интерфейсы программного обеспечения
    • 4. Интерфейсы взаимодействия
  • 2. Функциональные требования
  • 3. Требования к производительности
  • 4. Проектные ограничения (и ссылки на стандарты)
  • 5. Нефункциональные требования (надежность, доступность, безопасность и пр.)
  • 6. Другие требования

4. Приложения
5. Алфавитный указатель

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

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

ISO/IEC/ IEEE 29148-2011


Стандарт IEEE 29148-2011 обеспечивает единую трактовку процессов и продуктов, используемых при разработке требований на протяжении всего жизненного цикла систем и программного обеспечения. Он приходит на смену стандартов IEEE 830-1998, IEEE 1233-1998, IEEE 1362-1998.

Данный стандарт содержит два шаблона спецификации требований:

• System requirements specification (SyRS)
• Software requirements specification (SRS)

System Requirements Specification (SyRS) определяет технические требования для выбранной системы и удобства взаимодействия предполагаемой системы и человека. Она определяет высокоуровневые требования к системе с точки зрения предметной области, а также информацию об общей цели системы, ее целевой среде и ограничениях, допущениях и нефункциональных требованиях. Она может включать в себя концептуальные модели, спроектированные для иллюстрации содержания системы, сценариев использования, основных сущностей предметной области, данных, информаций и рабочих процессов. Из определения следует, что это аналог ТЗ, описанного в ГОСТ 34.

SyRS может содержать следующие разделы:

1. Введение

  • 1. Назначение системы
  • 2. Содержание системы (границы системы)
  • 3. Обзор системы
    • 1. Содержание системы
    • 2. Функции системы
    • 3. Характеристики пользователей
  • 4. Термины и определения

2. Ссылки

3. Системные требования

  • 1. Функциональные требования
  • 2. Требования к юзабилити
  • 3. Требования к производительности
  • 4. Интерфейс (взаимодействие) системы
  • 5. Операции системы
  • 6. Состояния системы
  • 7. Физические характеристики
  • 8. Условия окружения
  • 9. Требования к безопасности
  • 10. Управление информацией
  • 11. Политики и правила
  • 12. Требования к обслуживанию системы на протяжении ее жизненного цикла
  • 13. Требования к упаковке, погрузке-разгрузки, доставке и транспортировке

4. Тестирование и проверка (список необходимых приемочных тестов, которые отражают зеркально раздел 3)

5. Приложения

  • 1. Предположения и зависимости
  • 2. Аббревиатуры и сокращений

SRS это спецификация требований для определенного программного изделия, программы или набора программ (продукт), которые выполняют определенные функции в конкретном окружении. Из определения следует, что это аналог ТЗ, описанного в ГОСТ 19, а по структуре очень напоминает SRS из стандарта IEEE 830.

SRS может содержать следующие разделы:

1. Введение

  • 1. Назначение
  • 2. Содержание (границы)
    • 3. Обзор продукта
    • 1. Взаимодействие продукта (с другими продуктами и компонентами)
    • 2. Функции продукта (краткое описание)
    • 3. Характеристики пользователей
    • 4. Ограничения
  • 4. Термины и определения

2. Ссылки

3. Детальные требования

  • 1. Требования к внешним интерфейсам
  • 2. Функции продукта
  • 3. Требования к юзабилити
  • 4. Требования к производительности
  • 5. Требования к логической структуре БД
  • 6. Ограничения проектирования
  • 7. Системные свойства ПО
  • 8. Дополнительные требования

4. Тестирование и проверка (список необходимых приемочных тестов, которые отражают зеркально раздел 3)

5. Приложения

  • 1. Предположения и зависимости
  • 2. Аббревиатуры и сокращений

Данный стандарт достаточно сложно найти в открытом виде в Интернете, но постараться можно, и опять же только на англ.

RUP


Структура SRS в RUP(Rational Unified Process) представляет собой документ, в котором необходимо описать артефакты, полученные в процессе специфицирования требований.

Шаблон SRS в RUP адаптирован из стандарта IEEE STD 830 и содержит два варианта:

• Традиционный шаблон SRS со структурированными функциональными требованиями по функциям Системы, максимально похож на 830 стандарт.
• Упрощенный шаблон SRS со структурированными функциональными требованиями в виде вариантов использования (use cases):

1. Введение.

  • 1. Цель.
  • 2. Краткая сводка возможностей.
  • 3. Определения, акронимы и сокращения.
  • 4. Ссылки.
  • 5. Краткое содержание.

2. Обзор системы
  • 1. Обзор вариантов использований.
  • 2. Предположения и зависимости.

3. Детальные требований
  • 1. Описание вариантов использования.
  • 2. Дополнительные требования.
  • 3. Другие функциональные требования.
  • 4. Нефункциональные требования.

4. Вспомогательная информация.

Естественно, что в Интернете можно найти шаблон и примеры SRS от RUP.

SWEBOK, BABOK и пр.


SWEBOK, BABOK, а также множество других методологий разработки ПО и сводов знаний при упоминании SRS ссылаются на вышеупомянутые зарубежные стандарты.

Также стоит сказать, что для описания требований к АС и ПО используются и другие виды документов, кот каждый называет по разному: FRD (Functional Requirements Document), RD (Requirements Document), ПЗ (Постановка задачи или Пояснительная записка) и пр. Но это все производные документы от вышеупомянутых стандартов, не имеющих отраслевой стандартизации, хотя, в некоторых случаях, уже и с устоявшейся терминологией.

А как же Agile?


Я скажу одной фразой из Манифеста Agile: “Working software over comprehensive documentation”. Поэтому в Agile документации отводится совсем мало места.

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

Заключение


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

Но главное, чтобы ТЗ не превращалось в ХЗ, а, именно, содержание (наполнение) в ТЗ — самое главное! Но это уже совсем другая история… Если есть интерес, то можно пройти он-лайн курс Разработка и управление требованиями к ПО.

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

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

Техническое задание на сайт / Хабр

UPD: Продолжение статьи с примером техзадания

Не так давно на хабре были две статьи (Согласно техническому заданию и А зачем мне ТЗ? Я и так знаю!) посвященные техническим заданиям. У меня обе статьи вызвали, мягко говоря, недоумение, в особенности статья «Согласно техническому заданию». На мой взгляд, это вообще вредная статья, которая приводит к неверному понимаю сути ТЗ. В связи с этим хочу выразить свой взгляд на этот вопрос. Не буду говорить обо всех тех. заданиях, слишком широка тема, но думаю смогу рассказать о ТЗ на сайт.

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

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

1. Обоснование необходимости ТЗ

А зачем вообще нужно ТЗ на сайт? Заказчик говорит: «Нужен следующий сайт: каталог товаров, корзина, форма заказа, доставка, мы на карте, о нас, обратная связь». Что не ясно? Ничего необычного, всё обыденно и рутинно.

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


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

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

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

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

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

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

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

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

Синяя линяя — стоимость ТЗ, она растет с ростом детализации, красная линия — стоимость diff-а, его стоимость, напротив, падает с ростом детализации.

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

Отсюда важный вывод: ТЗ должно хорошо описывать проект, но не более того.

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

2. Что в нем должно быть и чего нет. Формулировки

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

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

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

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

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

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

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

3. Разделы ТЗ

3.1 Общие слова

Этот раздел вводит в курс дела. Исходите из того, что вам нужно отдать ТЗ стороннему программисту, и вас не будет на связи всё время работы над проектом вплоть до сдачи. Т.е. программист должен взять ТЗ, и у него не должно возникнуть ни одного вопроса, а первый вопрос, который он мог бы задать — это: «а про что сайт делать будем?» Раздел «Общие слова» в вольной форме и отвечает на этот вопрос.
3.2 Эксплуатационное. назначение

Коротко говоря, эксплуатационное назначение — это выгода, которую должен принести сайт. Вообще, чаще всего, выгода сводится к деньгам (если сайт как-то завязан на коммерции, а таких большинство), и в разделе можно было бы всегда ограничиться написанием того, что эксплуатационное назначение сайта — подзаработать деньжат, но мы не будем столь циничными. Остановимся на шаг раньше, непосредственно перед «подзаработать деньжат». Для интернет магазина это будет продажа товара (с которого мы получим деньги), для скидочного сайта это состыковать клиентов и продавцов или поставщиков услуг (чтоб с этого получить свой процент денег), для сайта визитки — это прорекламироваться в инете (а реклама нужна для получения денег) и т.д.
3.3 Функциональное назначение

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

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

3.4 Термины и определения

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

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

3.5 Данные и списки

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

Данные

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

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

Для примера, та же самая новость:

  • Заголовок
  • Текст
  • Дата публикации

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

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

Списки

Как подсказывает Кэп, новость — это новость, а список новостей — это список новостей.
Зачем это описывать? Допустим мы должны отобразить на главной странице «последние новости». Вот последние новости, это как раз такой список. А что есть «последние новости»? Это уже можно понять по разному, это могут быть последние 5 новостей, а может это новости за последние 24 часа? Приведенный пример прост, его недорого исправить и при сдаче проекта. Но есть более тяжелые случаи.

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

3.6 Страницы с описанием

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

Тут будет уместно описать не только, что отображается, но и как. Не в том смысле, что мы описываем дизайн: «Большими красными буквами отображается название новости», а в смысле, как работает: «Слева плавно выезжает окошко с предложением ввести логин и пароль». Или так: «при нажатии кнопки „Отправить комментарий“, комментарий появляется на странице без перезагрузки, с помощью AJAX».

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

Естественно, будет очень здорово добавить к каждой странице эскиз вроде такого:

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

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

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

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

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

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

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

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

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

Сюда стоит включить требования к интерпретаторам, библиотекам, пакетам, гемам, требования к дисковому пространству, памяти, smtp, pop, ftp, внешним программам и прочему, что имеет значение для работы проекта.

3.9 Наполнение контентом

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

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

Описание этого раздела предостережет нас от разного понимания того, кто должен залить 500 фотографий и наполнить каталог товарами.

3.10 Сдача и приемка

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

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

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

Заключение

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

Да, это ТЗ имеет пробелы, например, не сказано, как быть если у сайта должно быть API. Однако, имея хороший раздел «данные и списки», расширить ТЗ на эту область будет достаточно просто.

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

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

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


Структура технического задания:
1. Термины, используемые в техническом задании
2. Общие положения
2.1. Название сайта
2.2. Наименование предприятий (объединений) разработчика и заказчика (пользователя) сайта и их реквизиты
2.3. Перечень документов, на основании которых создается сайт
2.4. Состав и содержание работ по созданию системы
2.5. Порядок оформления и предъявления заказчику результатов работ по созданию сайта
3. Назначение и цели создания сайта
3.1. Цели создания сайта
3.2. Задачи, решаемые при помощи сайта
4. Требования к сайту и программному обеспечению
4.1. Требования к программному обеспечению сайта
4.2. Общие требования к оформлению и верстке страниц
4.3. Требования к численности и квалификации персонала обслуживающего сайт
4.4. Требования к системе администрирования
5. Структура сайта
6. Языковые версии сайта
7. Группы пользователей
8. Дизайн сайта
9. Навигация по сайту
9.1. Основное навигационное меню
9.2. Дополнительная навигация по сайту
10. Описание страниц сайта
10.1. Описание статических страниц
10.2. Описание динамических страниц
11. Функционал сайта
12. Контент и наполнение сайта
12.1. Формат предоставления материалов для сайта
13. Дополнительная информация
14. Порядок контроля и приемки работ
15. Реквизиты и подписи сторон

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

Скачать шаблон ТЗ в формате .doc

От идеи до реализации. Часть третья — создаем ТЗ (техническое задание) / Хабр
Данилевский Кирилл

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

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

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

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

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

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

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

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

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

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

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

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

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

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

СОЗДАЕМ ТЗ ДЛЯ ПРОЕКТА

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

1. Очень подробно описывается идея проекта. Аргументируется эта идея. Почему она должна сработать. Какие конкуренты уже присутствуют на рынке. Какая у них доля рынка. Насыщен ли данный рынок или испытывает голодание на подобное решение.

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

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

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

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

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

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

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

9. Для подобных сложных проектов просто необходима система самодиагностики. Она должна быть разбита на две части. Первая — это диагностика базы данных, на корректность данных. Ведь речь идет о сложных математических расчетах. А значит, даже маленькая ошибка (например, некий коэффициент в базе равен не 0.5, а 0.6) может привести к фатальным последствиям. Для этого нужно иметь некие эталонные данные, которые будут сверятся с реальными в базе. И если реальные данные вышли за предел допустимого порога, то администратор должен это знать и сам принять решение, что с этим делать. Тоже касается и формул вместе с входными параметрами. Параметры должны быть только в рамках допустимой погрешности.

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

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

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

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

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

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

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

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

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

Всем спасибо и до новой встречи.

Образец технического задания на разработку программы. Пишем техническое задание
1. Введение
1.1. Наименование программы
1.2. Назначение и область применения программы
2. Требования к программе
2.1. Требования к функциональным характеристикам программы
2.2. Требования к надежности программы
2.2.1. Требования к обеспечению надежного функционирования программы
2.2.2. Время восстановления программы после отказа
2.2.3. Отказы программы из-за некоректных действий оператора
3. Условия эксплуатации программы 3.1. Климатические условия эксплуатации программы
3.2. Требования к квалификации и численности персонала
3.3. Требования к составу и параметрам технических средств
3.4. Требования к информационной совместимости
3.4.1. Требования к информационным структурам и методам решения
3.4.2. Требования к исходным кодам и языкам программирования
3.4.3. Требования к программным средствам, используемым программой
3.4.4. Требования к защите информации и программ
3.5. Специальные требования
4. Требования к программной документации
4.1. Предварительный состав программной документации
5. Технико-экономические показатели
5.1. Экономические преимущества разработки программы
6. Стадии и этапы разработки программы
6.1. Стадии разработки программы
6.2. Этапы разработки программы
6.3. Содержание работ по этапам
7. Порядок контроля и приемки
7.1. Виды испытаний
7.2. Общие требования к приемке работы

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

Наименование программы: "Тестовая программа"

1.2. Назначение и область применения

Программа предназначена для...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.3.1. В состав технических средств должен входить IВМ-совместимый персональный компьютер (ПЭВМ), выполняющий роль сервера, включающий в себя:
3.3.1.1. процессор Pentium-2.0Hz, не менее;
3.3.1.2. оперативную память объемом, 1Гигабайт, не менее;
3.3.1.3. оперативную память объемом, 1Гигабайт, не менее;
3.3.1.4. операционную систему Windows 2000 Server или Windows 2003;
3.3.1.5. операционную систему Windows 2000 Server или Windows 2003;
3.3.1.6. Microsoft SQL Server 2000

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

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

База данных работает под управлением Microsoft SQL Server. Используется много поточный доступ к базе данных. Необходимо обеспечить одновременную работу с программой с той же базой данной модулей экспорта внешних данных.

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

Дополнительные требования не предъявляются

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

Системные программные средства, используемые программой, должны быть представлены лицензионной локализованной версией операционной системы Windows 2000 Server или Windows 2003 и Microsoft SQL Server 2000

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

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

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

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

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

Состав программной документации должен включать в себя:
4.1.1. техническое задание;
4.1.2. программу и методики испытаний;
4.1.3. руководство оператора;

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

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

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

Разработка должна быть проведена в три стадии:
1. разработка технического задания;
2. рабочее проектирование;
3. внедрение.

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

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

На этапе разработки технического задания должны быть выполнены перечисленные ниже работы:
1. постановка задачи;
2. определение и уточнение требований к техническим средствам;
3. определение требований к программе;
4. определение стадий, этапов и сроков разработки программы и документации на неё;
5. согласование и утверждение технического задания.
На этапе разработки программы должна быть выполнена работа по программированию (кодированию) и отладке программы.
На этапе разработки программной документации должна быть выполнена разработка программных документов в соответствии с требованиями к составу документации.
На этапе испытаний программы должны быть выполнены перечисленные ниже виды работ:
1. разработка, согласование и утверждение и методики испытаний;
2. проведение приемо-сдаточных испытаний;
3. корректировка программы и программной документации по результатам испытаний.
На этапе подготовки и передачи программы должна быть выполнена работа по подготовке и передаче программы и программной документации в эксплуатацию на объектах Заказчика.

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

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



Что было раньше


Мы небольшая региональная компания, занимающаяся заказной веб-разработкой, которая, как и многие другие, в самом начале бралась за проекты, не особо представляя как их делать. Но подобный “вынужденный рост” крайне положительно сказался на членах команды, благодаря огромному желанию развиваться, и помог прокачать и скилы, и голову. Разработка становилась все качественнее, но техническое задание оставалось на самом низком уровне. Как и большинство начинающих студий, мы использовали обычный описательный подход к ТЗ: какие страницы, что должно отображаться, некоторые технические моменты, да и все, пожалуй.

На многих проектах это выливалось в следующие проблемы:

  1. Описан внешний вид, но не принцип работы. Простой пример с корзиной интернет-магазина. В ТЗ было написано “Кнопка “Оформить заказ”. Но что должно произойти, когда пользователь нажал на эту кнопку? По каким правилам формируется номер заказа? Какой статус ему присваивается? Куда идет переадресация? А если один из товаров раскупили, пока пользователь оформлял заказ? На эти и многие другие вопросы в ТЗ ответов не было, а ведь это лишь один небольшой элемент. Подобные неописанные моменты приводили к спорам с Заказчиком, сильному выходу из бюджета и прочим неприятным последствиям.
  2. Отсутствие переиспользуемых блоков. На многих сайтах есть одинаковые блоки, используемые в разных местах, например, превью товара. Но данный блок в результате описывался в каждой странице. Это очень плохо по нескольким причинам. Во-первых, при необходимости изменения надо вносить сразу в нескольких местах, можно что-то упустить и будет несоответствие. Во-вторых, даже при одинаковых элементах в превью, заказчик может потребовать сделать их по-разному, что влечет за собой дополнительные затраты.
  3. ТЗ не коррелирует с задачами для команды. Чем дальше постановка задачи от реальности, тем ниже будет качество на выходе. Это еще одна проблема, которую хотелось решить.

Новый подход


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

ТЗ состоит из следующих разделов:

  1. Введение
  2. Статика
  3. Динамика
  4. Задачи
  5. Административная панель
  6. Общие технические требования

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

Введение и подготовка к реализации

  • Кратко описываем проект, его цели, ЦА, оставляем ссылки на предпроектную аналитику.
  • Описываем процесс инициализации проекта: настройку окружения для разработчиков и подход к разработке концепции дизайна для дизайнеров.
  • Принципы адаптивности или разбиения на версии. Последнее время в своей работе мы придерживаемся следующего принципа — “адаптивь все, что адаптивится”. Иначе говоря, в начале работы над ТЗ мы понимаем, какой сложный функционал нам нужен (или может понадобиться в ближайшем будущем) и вместе с дизайнером и front-end разработчиком придумываем способы его заадаптивить. При новом подходе отрицательных результатов еще не было, поэтому отдельные версии описывать не приходилось.

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

Статика

Как мы все знаем, страницы могут содержать либо статическую информацию, либо динамическую, присылаемую с сервера. Подразделы статики — страницы проекта. Каждую страницу мы разбиваем на блоки. Если блок статический, то мы описываем его суть и вид контента. Например, описание одного из блоков страницы “О компании” может выглядеть так. “Основные преимущества компании. 5-6 иконок с описаниями.” Это очень краткое, но достаточное для точной оценки описание блока. При описании статики главная цель — задать четкие рамки. Сделать адаптив иконок не составит труда, а с графиком или таблицей все не так просто и однозначно. Но при этом нам не важно какие именно будут иконки и подписи к ним.

Если же страница содержит блок, который можно “вынести за скобки”, то в месте его интеграции мы пишем “Интегрируется функционал “NAME”, а сам функционал описываем в разделе “Динамика”.

Помимо страниц Статика включает в себя описание pop-up и письма. На мой взгляд их нет смысла выносить в отдельный большой раздел и раздувать структуру.

Динамика

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

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

Задачи

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

Административная панель

Здесь описываем структуру, модели и поля. Разбиение идет по разделам, например, “Товары”, “Каталог”, “Заказы” и т.д. Описываем что разные роли пользователей могут просматривать, что редактировать.

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

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

  1. SEO-требования к тегам и микроразметке
  2. Правила транслитерации
  3. Ручное и автоматическое тестирование
  4. Поддерживаемые браузеры
  5. …

Новые версии


При описании новых версий необходимо вносить изменения в существующие элементы. Мы рассматривали следующие способы описания доработок: в начале каждого из разделов (Статика, Динамика, АП) писать “Доработка функционала “NAME”, либо сделать отдельный раздел “Доработки”, в котором в кучу будут свалены сразу все изменяющиеся задачи. Пока остановились на втором варианте, но это связано скорее удобством на конкретных проектах. В других условиях лучше подойдет первый способ.

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

Пример


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

Статика


Страница “Раздел каталога”

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

Интегрируется следующий функционал:

  1. “Хлебные крошки”
  2. “Дерево каталога”
  3. “Фильтрация. Общие положения”
  4. “Фильтрация. Текст”
  5. “Фильтрация. Текст и изображение”
  6. “Фильтрация. Диапазон”
  7. “Сортировка. По умолчанию”
  8. “Сортировка. По возрастанию цены“
  9. “Сортировка. По убыванию цены”
  10. “Превью товара. Плитка”
  11. “Пагинация. Постраничная”
  12. “Текстовый блок”. Интегрируется в виде блока для SEO-текста перед подвалом сайта

URL: /c/1745-name, где 1745- id текущей категории каталога, а name — транслитерированное название этой категории.

Динамика


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

Функционал “Фильтрация. Общие положения”

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

  • выпадающий список закрывается, а фильтр применяется. В текущем разделе остаются только товары, соответствующие текущим активным фильтрам
  • название кнопки фильтра приобретает вид: “Название фильтра: K”, где K — количество выбранных значений фильтра, если их 2 или больше, или “Название фильтра: значение”, если было выбрано одно значение.
  • цвет кнопки фильтра меняется на вид используемого фильтра
  • в значениях других фильтров остаются только варианты, удовлетворяющие текущим активным фильтрам. Если в одном из неактивных фильтров остается одно значение, его кнопка приобретает вид неактивной, а название выводится в формате “Название фильтра: значение”
  • у всех активных фильтров после названия добавляется крестик, при клике на который сбрасывается только этот фильтр
  • пагинация сбрасывается

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

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

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

Выбранные фильтры добавляются в URL посредством query-параметров.

Функционал “Превью товара. Плитка”

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

  1. Цена (целое число в рублях РФ)
  2. Название товара
  3. Метка “В магазине” или “С витрины”
  4. Изображение
  5. Размер
  6. Кнопка “В корзину” (Интеграция функционала “Добавить в корзину”)
  7. Кнопка “В избранное” (Интеграция функционала “Добавить в избранное”)

При клике на любую область превью, кроме кнопки “В корзину” осуществляется переход на страницу товара.

На одной строке должно помещаться 3-4 плитки с превью товара.

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

Административная панель


Одна страница требует большого количества разделов АП, опишу один из них.

Товар

Список всех товаров с фильтрацией. При редактировании/добавлении товара доступны следующие поля:

  1. Название (текст)
  2. Бренд (радио)
  3. Изображения
  4. Цена (целое число)
  5. Описание (текстовый блок)
  6. Тип (магазин/витрина, радио)
  7. Состояние. Значение включает в себя Название (текст) и Пояснение (текст).
  8. Статус. Возможны варианты:
    1. на продаже
    2. на модерации
    3. на доработке
    4. отклонен
    5. продан
    6. не прошел проверку
    7. отменен Продавцом
  9. Размер с бирки (необязательное). Текстовое поле без валидации
  10. …

Полей более 30 и, дабы не раздувать статью, опустим их.

Выводы


Плюсы нового подхода:
  1. Полнота. Данное ТЗ позволяет однозначно описывать требования, что является основным и необходимым параметром любого ТЗ.
  2. Понятность. Около половины наших клиентов не имеют на своей стороне технического специалиста и сталкиваются с разработкой впервые. Поэтому очень важно было сделать ТЗ максимально понятным и читаемым. И у нас получилось! Даже технически не подкованные клиенты понимают, как оно устроено, могут спокойно его читать и давать отличную обратную связь.
  3. Молекулярность. ТЗ полностью соответствует нашим требованиям к разбиению на отдельные элементы, что значительно упрощает и решает проблемы, описанные выше. Блоки ТЗ напрямую соответствуют задачам, которые выполняются разработчиками, что было встречено на ура. Также ТЗ отлично ложится на дизайн-систему (про нее статья выйдет уже на следующей неделе).
  4. Простота оценки и конфигурации сметы. Хорошо описанные и разбитые задачи стало просто и приятно оценивать. Если во время оценки мы понимаем, что требования неполные, то дописываем их. Под каждый проект (этап) делаем гугл таблицу, в которой заказчик может попробовать разные конфигурации проекта и определить наиболее подходящий для себя вариант по цене/функционалу.
  5. Взаимодействие с заказчиками поднялось на новый уровень. Внесенные изменения позволяют четко определить границы проекта. Если необходимо внести изменения относительно ТЗ, это оценивается как новая задача, хотя при старом подходе это вызывало много споров.
  6. Рентабельность. Т.к. это в первую очередь бизнес, данный показатель наравне с предыдущим является одним из самых важных. Детальная проработка позволила свести количество плохо оцененных задач к минимуму. Ни по одному из проектов, реализуемых по новому подходу, не было превышения бюджета.

Минусы:
  1. Внесение доработок. На одном из проектов было необходимо ввести статусы товаров. В итоге получилось огромное количество доработок по 2-3 строчки. Нельзя это назвать явным минусом, т.к. полното требований в приоритете, но и идеальным данных подход назвать нельзя.
  2. Сложность восприятия при автоматизации бизнес-процессов. Если взять бизнес-процессы некоторых компаний от момента продажи до получения товара покупателем, не всегда есть возможность (или необходимость на первых этапах) покрыть весь процесс за счет Статики, Динамики и АП, т.к. многие задачи выполняются вручную, обсуждаются с клиентами по телефону и т.д. Это немного усложняет восприятие ТЗ в чистом виде, и требует дополнительного описания процессов.
  3. Стоимость и время разработки. Продавать ТЗ, конечно, стало сложнее, ведь далеко не все при первом контакте с разработкой готовы платить за него 10-20% от проекта при том что многие наши конкуренты берут за него 10-20 тыс. Но подобная работа сполна окупается при реализации, снижая риски проекта и улучшая качество.

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

Мы настолько довольны результатом, что решили отказаться от стандартных тасктрекеров в пользу доработки Google Docs для полноценной работы с задачами на основе ТЗ. Если опыт будет удачным, напишем об этом отдельную статью. А пока ждем от вас объективную критику и советы, с надеждой, что кому-то эта статья помогла).

надо ли и как писать. Критика примера / Хабр

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


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

Разработке подлежит дизайн сайта компании АА (имя сайта АА-company.ru)

Исходные материалы: логотип, визитка, буклет, примеры продукции компании, фотографии работ, текстовое наполнение (15 стр в doc).

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

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

Конкуренты
Основные:

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

— Конкурент 2
Достоинства: обширное портфолио.
Недостатки: дизайн сайта крайне примитивен, как и навигация.

— Конкурент 3
Достоинства: яркая, хотя и не очень впечатляющая, графика. Много грамотно написанных текстов (встречаются ошибки).
Недостатки: каталог товаров и услуг не проиллюстрированы фотографиями и ценами. приходится качать файлы прайсов.

Дополнительно рассмотрены:

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

— Конкурент 5
Достоинства: нет.
Недостатки: скучный дизайн, примитивное оформление страниц

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

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

— Конкурент 8
Достоинства: яркий и простой дизайн с применением флеш-анимации. Простая и понятная навигация.
Недостатки: шрифты страниц неконтрастны, плохо читаемы.
Хороший дизайн и концепцию испортили наполнением.

— Конкурент 9
Достоинства: проработанный дизайн, множество иллюстраций
Недостатки: внутри сайта нет фотографий, тексты смотрятся слепыми

— Конкурент 10
Достоинства: яркий дизайн, качественное наполнение, удачная флеш-анимация.
Недостатки: нет

— Конкурент 11
Достоинства: любовно и старательно наполнен
Недостатки: некоторые странные решения по дизайну и огрехи по наполнению
В целом очень достойно

— Конкурент 12
Достоинства: яркие страницы, простой и хорошо структурированный каталог.
Недостатки: глаза устают.
Сайт абсолютно классический, на твердую 4.

— Конкурент 13
Достоинства: флешка красивая.
Недостатки: крайне неприятная цветовая гамма, наполнение сделано странно.

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

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

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

Слоган для использования на сайте:
главная ценность нашей компании — наши клиенты

Сайты, на стиль исполнения которых следует обратить внимание, т.к. они нравятся заказчику:
www.alfa-suvenir.ru
www.elenara.ru
www.tipograf.info
www.vremenagoda.biz
www.viveska.info
www.emotiondesign.ru
www.driada-pr.ru — не открылся
www.corporative.ru
www.credo-positive.ru

Образцами можно считать:
alfa-suvenir.ru — да
www.viveska.info — да, построение шапки, стиль оформления текстов и меню
www.vremenagoda.biz — да, структура страницы. можно использовать как образец при наличии исходных материалов для создания коллажей. создание иллюстраций не включается в разработку сайта

Пункты меню главной страницы:
О компании
Новости
Услуг
Портфолио
Контакты
Полезно знать (статьи о рекламе)
Заказать

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

На всех страницах — шапка, меню, логотип.

Первое предлагаемое решение по созданию дизайна сайта.
Сайт создается как растягивающийся на любую ширину страницы.
1. Стартовая и внутренние страницы имеют разную структуру. общие цвета: белый/кремовый, оранжевый, гамма синего, буквы черные.
2. Стартовая страница:
— содержит крупный логотип (до 25% высоты сайта) и в качестве шапки цветовую полосу (может быть неправильной формы) с блоками, иллюстрирующими направления деятельности (или конкретные работы) компании
— имеет структуру, собранную из информационных блоков: о компании, наши преимущества, что умеем, полезно знать, последние работы, наши услуги, новости, баннер перехода на форму, возможно еще что-то (скомпоновано по принципу www.ra-alterego.ru/?id=manufacture). Каждый блок построен по принипу вынесения главного или самого современного. Все блоки одного размера. В будущем возможно расширение и обновление сайта путем замены одного блока на другие.
2. Основные страницы (портфолио, клиенты, новости, услуги):
— логотип и шапка имеют меньшую высоту (10-15%), шапка содержит коллаж из работ или иллюстрацию (при наличии)
— имеют трехколоночное построение (лого, шапка, вертикальное меню, поле дополнительной иформации). В поле дополнительной информации выводятся небольшие блоки информации, которая может быть интересна при просмотре раздела (в новоястях-портфолио, в клиентах-услуги и т.п.) или блоки, аналогичные блокам на главной.
3. Внутренние и текстовые страницы имеют двухколоночное представление: шапка+меню+текст страницы.
4. Наобходимо придумать визуальное решение, позволяющее подчеркнуть широкий спектр оказываемый услуг и собственную производственную базу.

Второе предлагаемое решение по созданию дизайна сайта.
Идея решения заключается в использовании в дизайне в качестве рамки символов печати (штампа), сувенирной продукции, других примеров продукции компании. Сайт будет иметь фиксированную ширину. По периметру располагаются графические элементы, созданные на основе графики продукции компании (печати, буклеты, сувенирка).
По высоте сайт растягивается либо путем добавления белого пространства слева и справа по периметру, либо повторяющегося рисунка.
1. Стартовая и внутренние страницы имеют разную структуру. общие цвета: белый фон, графика фона с приглушенными серо-сине-желтыми тонами, заголовки в гамме синего, буквы черные.
2. Стартовая страница:
— содержит крупный логотип (до 25% высоты сайта) и левое текстовое меню с графическими маркерами (стиль как на www.viveska.info)
— имеет структуру, собранную из вертикально следующих информационных блоков: о компании, наши преимущества, что умеем, полезно знать, последние работы, наши услуги, новости. Каждый блок построен по принципу вынесения главного или самого современного. Все блоки одного размера. В будущем возможно расширение и обновление сайта путем замены одного блока на другие.
Под меню можно разместить ленту работ.
2. Основные страницы (портфолио, клиенты, новости, услуги):
— логотип имеет меньшую высоту (10-15%), левая колонка содержит коллаж из работ или иллюстрацию (при наличии)
— имеют двухколоночное построение (лого вертикальное меню).
3. Внутренние и текстовые страницы имеют двухколоночное представление: шапка+меню+текст страницы.

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

этикеток · takecy / tz-sample · GitHub

перейти к содержанию
  • Почему GitHub? Особенности →
    • Обзор кода
    • Управление проектами
    • Интеграции
    • Действия
    • Пакеты
    • Безопасность
    • Управление командой
    • Хостинг
    • Отзывы клиентов →
    • Безопасность →
  • команда
  • предприятие
  • Проводить исследования
    • Исследуйте GitHub →
    учиться и внести свой вклад
    • Темы
    • Коллекции
    • Тенденции
    • Learning Lab
    • Руководства с открытым исходным кодом
    Общайтесь с другими
    • События
    • Общественный форум
    • GitHub Education
  • базарная площадь
  • ценообразование
.

Panasonic Lumix TZ200 Образцы фотографий

Мы взяли Lumix TZ200 на прогулку по городу, чтобы протестировать его циферблаты, увеличение и другие функции.

| Panasonic Lumix TZ200 в компактных камерах

Lumix TZ200

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

Поскольку это предсерийный образец, нам пока не разрешено тщательно проверять качество изображения (хотя это нас и поразило!) Или сравнивать его с изображениями TZ100, но это дает вам возможность увидеть, какой тип изображений, которые эта новая камера способна производить. Ниже вы найдете галерею изображений с портретами, архитектурой, съёмками еды, уличной фотографией и многим другим. Кроме того, мы также добавили новый монохромный цифровой фильтр L вместе с режимом панорамы и, конечно же, полной шириной и длиной 24-360 мм (эквивалент 35 мм), 15-кратным оптическим зумом.

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

Panasonic Lumix TZ200 (ZS200) Образцы фотографий

Панорамные фотографии Panasonic Lumix TZ200

Panoramic captured with a Pre-Production Panasonic TZ200
Панорамный снимок с предсерийного производства Panasonic TZ200

Panoramic captured with a Pre-Production Panasonic TZ200
Панорамный снимок с предсерийного производства Panasonic TZ200

Тестовые изображения объектива Panasonic Lumix TZ200 (ZS200)

Panasonic Lumix TZ200 (ZS200) Технические характеристики

Тип датчика 90 9005 2 Выдержка Comp
Производитель Panasonic
Объектив
Макс. Диафрагма f / 3.3 - f / 6.4
эквивалент 35 мм 24 - 360 мм
Оптический зум 15x
Датчик изображения
пикселей 20,1Mp (мегапикселей)
пикселей (Вт) 5472
пикселей (В) 3648
Назад- горит CMOS (B.SI)
Размер сенсора 1 дюйм
Размер сенсора (ширина) 13,2 мм
Размер сенсора (высота) 8,8 мм
Аспект Коэффициент
ЖК-монитор
ЖК-монитор 3 дюйма
Разрешение экрана 1240К точек
Сенсорный экран Да
Фокусировка
Мин. Фокус 3 см
Режимы фокусировки
  • Автофокус
  • Ручная
  • Точечный
  • Обнаружение лица
  • Отслеживание АФ
  • Мульти
  • Центр
  • Touch 100
Контроль экспозиции
Кратчайшие скорости затвора 1 / 16000сек
Кратчайшие выдержки 60сек
Режим лампы Нет
Режимы Exp
  • Программа 9020 9054 Aperture-Priority
  • Shutter-Priority
  • Ручная
  • Сюжетные режимы
  • Программная переменная
Измерение
  • Средневзвешенная - средняя
  • 900 900 902 90552 90552 90552 90902 Точечная
Чувствительность ISO 80 - 25600
Баланс белого
  • Авто
  • Руководство
  • На открытом воздухе / дневной свет
  • Облачно
  • Лампа накаливания
  • Тень

    • 900 вспышка 90552

+/- 5
Параметры съемки
Непрерывная съемка 10 кадров в секунду
Видео
Режим видео Да
Разрешение видео
Видео FPS 60, 30, 24
Стереозвук Да
Оптический зум с видео Да
Другие особенности
Стабилизация изображения Да
Интерфейс
HDMI Да
USB USB 2
Wi-Fi Да
Хранение
Тип карты
Тип файла
Источник питания
Тип батареи Литий-ионный аккумулятор (7.2 В, 1025 мАч, 7,4 Втч)
Срок службы батареи (рейтинг CIPA) 370 снимков
Содержимое коробки
Комплектация Аккумулятор, адаптер переменного тока, USB-кабель, ручной ремешок, адаптер для ремешка
Размеры
Вес 340 г
Ширина 111.2 мм
Высота 66,4 мм
Глубина 45,2 мм

Смотреть полную информацию о товаре

Поддержите этот сайт, сделав пожертвование, купив членство Plus или совершив покупки у одного из наших партнеров: Amazon UK, Amazon US, Amazon CA, Ebay UK, WEX

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

Panasonic Lumix TZ60 Black Large (3)

Вот несколько необработанных фотографий и фотографий в формате JPEG с Panasonic Lumix TZ60 (ZS40) - камера оснащена фирменным 30-кратным оптическим зум-объективом Leica, встроенным GPS и Wi-Fi.

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

Испытательные изображения Panasonic Lumix DMC-TZ60 (ZS40) ISO

Panasonic Lumix DMC-TZ60 (ZS40) Тестовые изображения баланса белого

Panasonic Lumix DMC-TZ60 (ZS40) Технические характеристики

Чувствительность к центру Точка 901 900 Чувствительность к центру 91765
  • Чувствительность к центру
    • Производитель Panasonic
    Объектив
    Макс. Диафрагма f / 3.3 - f / 6.4
    35 мм эквивалент 24 мм - 720 мм
    Оптический зум 30x
    Датчик изображения
    пикселей 18,1Mp (мегапикселей)
    пикселей (Вт) 4896
    пикселей (В) 3672
    Тип датчика Live MOS Датчик
    Размер датчика 1/2.3 дюйма
    Размер датчика (ширина) Нет данных
    Размер датчика (высота) Нет данных
    Соотношение сторон
    ЖК-монитор
    ЖК-монитор 3 дюйма
    Разрешение экрана 460k
    Сенсорный экран №
    Фокусировка
    Мин. Фокус 3 см
    Режимы фокусировки
    • Автофокус
    • Следящий АФ
    • Центр
    Контроль экспозиции
    Кратчайшая скорость затвора 1 / 2000сек
    Максимальная выдержка 4сек
    Режим лампы Нет данных
    Режимы экспозиции
    • Программа
    • Приоритет диафрагмы
    • Приоритет выдержки
    • Ручной
    • Сюжетные режимы
    Измерение
    • Пятно
    • Измерение освещенности ESP
    • 900 900 900 900 900
    Чувствительность к центру 91765
    		• 100 - 6400
    Баланс белого
    • Авто
    • Ручной
    • На открытом воздухе / Дневной свет
    • Облачно
    • Лампа накаливания
    • Тень
    Экспонирование
    Параметры съемки
    Непрерывная съемка 10fps
    Видео
    Режим видео Да
    Разрешение видео
    Видео FPS 50p
    Стереозвук Да
    Оптический зум с Видео Да
    Другие особенности
    Стабилизация изображения Да
    Интерфейс
    HDMI Да
    USB USB 2
    Wi-Fi Да
    Хранение
    Тип карты
    Тип файла
    Источник питания
    Тип батареи Литий-ионный
    Срок службы батареи (рейтинг CIPA) 300 снимков
    Содержимое коробки
    Комплектация Нет данных
    Размеры
    Вес 240г
    Ширина 110.6 мм
    Высота 64,3 мм
    Глубина 34,4 мм

    Смотреть полную информацию о товаре

    Поддержите этот сайт, сделав пожертвование, купив членство Plus или совершив покупки у одного из наших партнеров: Amazon UK, Amazon US, Amazon CA, Ebay UK, WEX

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

    TZ / TZL | Саберметрическая библиотека

    Хотя UZR и DRS основаны на данных, собранных Бейсбольными Информационными Решениями (BIS), Общая Зона (TZ) является единственной защитной статистикой, рассчитанной исключительно с использованием данных об игре за игрой, доступных в Retrosheet. Изобретенный Шоном Смитом, он рассчитывается различными способами в зависимости от того, сколько данных доступно в этом конкретном году (подробности можно найти здесь), но, поскольку для этого требуются только данные для воспроизведения, оценки TZ можно рассчитать для любого игрок в истории бейсбола.В результате TZ используется в исторических результатах WAR на Baseball-Reference.com и FanGraphs (до 2002 года).

    Общая зона с данными о местонахождении (TZL) - это улучшенная версия TZ, разработанная Шоном Смитом в 2010 году. Вы можете прочитать обо всех ее деталях здесь, но вкратце, он использует данные о месте попадания в Gameday, чтобы сделать свои расчеты более точными.

    Контекст:

    Как и UZR и DRS, TotalZone и TotalZone с данными местоположения представлены как «Сохраненные прогоны».Среднее значение по лиге равно нулю, в то время как положительные оценки представляют поле выше среднего, а отрицательные - поле ниже среднего.

    Золотая перчатка
    Способность Защиты TZ / TZL
    Калибр +15
    отлично +10
    выше среднего +5
    Средний 0
    ниже среднего -5
    Плохо -10
    Ужасно -15

    Что нужно запомнить:

    ● TZ и TZL являются хорошими показателями, хотя UZR и DRS по-прежнему считаются более точными показателями поля.Тем не менее, UZR и DRS могут быть рассчитаны только для современных игроков из-за технологических ограничений, поэтому TZ является наилучшей доступной статистической статистикой по полям. Если вы хотите сравнить поле современного игрока с игроком 1940-х годов, TZ будет статистикой для использования.

    Ссылки для дальнейшего чтения:

    TotalZone Data - Бейсбольный справочник

    Обновления TotalZone с использованием мест попаданий MLB Gameday - бейсбольные прогнозы

    ,

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

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