Как правильно согласно технического задания или техническому заданию: Согласно техническому заданию / Хабр

Содержание

Согласно техническому заданию / Хабр

Добрый вечер, созидающая часть Хабра!

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

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

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

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

Жаль только, что, полное неоспоримых преимуществ, Тех. Задание, содержит пару больших и жирных «но».

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

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

Одна будет грязно-серой, другая – белоснежной; одна — стоить доллар, другая в три раза дороже! Выбрав одну – вы заработаете геморрой, выбрав другую – достигнете небывалых высот мысли.

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

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

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

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

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

Разумное применение

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

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

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

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

Изображения взяты с сайтов: pt.wikinoticia.com cultofmac.cultofmaccom.netdna-cdn.com, www.popwuping.com, www.thinkgeek.com

P.S. Я не уверен в правильности выбранного блога, но не нашел более подходящего.

согласно техническому заданию или технического задания

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

Какие пособия у вас в ходу?? Посоветуйте, пожалуйста!

I Книги, пособия

1. «Логопедическая азбука» (Озон)

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

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

Самый главный плюс — стихи на согласные буквы, где строчки чередуются: одна — со слогами, одна — просто стихотворная. Выглядит так:

Влад просто обожает все эти ба-бе-би-бо-бу-бы-ба, воодушевленно это повторяет, а строчки «со смыслом», мне кажется, не обращает внимания, они нужны чисто для передышки))) В целом стихи довольно бредовые, но пользы у них не отнять!

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

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

И бонус!!! Забавный случай из жизни! Позвольте поделиться, не откажите в любезности. Когда только купила книгу, показала ее мужу, взгляд его падает на фио автора — г.р. лагздынь.
лагздынь?? — удивленно переспрашивает он
И я думаю, что он хочет посмеяться над фамилией, ну а кто из нас возьмется его судить?
Но он без паузы продолжает: Гайда? Рейнгольдовна? Лагздынь??
В первую секунду мне кажется, что он шутит, ну выдумывает вычурное имя из инициалов под стать фамилии, но сразу понимаю — больно уж быстро и складно!
И вот он все еще держит драматическую паузу, и мне становится по-настоящему страшно (а что я вообще знаю о человеке, сидящем напротив меня? какие еще тайны он хранит??)

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

Ладно, давайте вернемся к книжкам))

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

Здесь — все отлично. На каждой страничке по 2 строчки — или целая скороговорка, или ее часть, картинки приятные.

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

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

3. Артикуляционная гимнастика для мальчиков (Озон // Лабиринт)

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

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

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

А эта книжка на скрепке. Значит, вы можете завернуть ее так, чтобы было видно только то упражнение, над которым вы работаете. На каждой странице соответственно только 1.

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

4. «Альбом по развитию речи для самых маленьких» (Озон)

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

Особенно горячим для альбома был период где-то с 9 м. до 1,5 лет.

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

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

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

Всякие задания на звукоподражания, игры.

Есть сказки, которые предлагается рассказывать, опираясь на картинки.

В конце — уже более сложные задания на мышление.

В общем, мне очень нравится, при этом он недорогой, я считаю, его надо обязательно покупать!

5. «Альбом по развитию речи» (Озон // Лабиринт)

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

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

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

Еще большой минус для меня — все картинки выполнены в разном стиле. Если в альбоме для самых маленьких они, пусть и не самые красивые, но хотя бы единообразные, то здесь кто в лес, кто по дрова. То мультяшные, то реалистичные, причем даже на 1 листе. Я ужасно не люблю такую мешанину! Но в целом здесь нет откровенного криминала, блесток, аляповатых рамок и вообще стилистики «Эге-гей! Это для детей!» , так что жить можно.

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

6. «Шумелки. Сказки с озвучиванием» (Озон // Лабиринт)

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

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

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

7. Николай Радлов «Рассказы в картинках» (Озон // Лабиринт)

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

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

Мы смотрим на простенькие сюжеты и пытаемся воссоздать рассказ. Сначала я, потом Влад уже с наводящими вопросами, какие-то картинки — полностью сам. До конца еще не долистали, там 56 страниц. Как правило, 1 история на странице, но есть такие, что занимают полный разворот. Все истории про животных.

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

8. 50 веселых суперразвивающих заданий (Озон // Лабиринт)

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

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

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

Мне нравится оформление и то, что 1 задание — 1 лист, нет этой кучи, как, например, в альбоме выше (но зато он, в свою очередь, более насыщенный и содержательный).

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

Согласно техническому заданию — Yvision.kz

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

Жаль только, что, полное неоспоримых преимуществ, Тех. Задание, содержит пару больших и жирных «но».

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

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

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

Изображения взяты с сайтов: http://pt.wikinoticia.com http://cultofmac.cultofmaccom.netdna-cdn.com, http://www.popwuping.com

Оригинальная статья.

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

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. Однако, имея хороший раздел «данные и списки», расширить ТЗ на эту область будет достаточно просто.

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

Выполнить работы согласно техническому заданию. Как писать техническое задание?! Назначение и цели создания системы

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

Рекомендуем прочитать:

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

Для чего ТЗ заказчику?

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

Рекомендуем прочитать:

Для чего ТЗ исполнителю?

В первую очередь, это ваш ориентир на то, что

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

Введение

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

И так, основные стандарты, методологии и своды знаний, где упоминается ТЗ или 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).

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

Согласно техническому заданию — Horde.me

Жаль только, что, полное неоспоримых преимуществ, Тех. Задание, содержит пару больших и жирных «но».

Разумное применение

Изображения взяты с сайтов: pt.wikinoticia.com cultofmac.cultofmaccom.netdna-cdn.com, www.popwuping.com

Оригинальная статья.

Теги:
техническое задание
, IT
, вне потока
, технологии

Техническое задание — определение технического задания The Free Dictionary

Согласно заявлению кипрско-греческой стороны в понедельник, процесс близок к согласованию круга ведения для возобновления переговоров по Кипру, что открывает путь к встрече двух лидеров с Генеральным секретарем ООН Антониу Гутерришем в Нью-Йорке в конце этого месяца по на полях Генеральной Ассамблеи ООН. В твиттере в среду Локсин заявил, что принимает условия Китая в отношении «идеального» меморандума о взаимопонимании (МоВ) по разведке нефти и газа.Комитет теперь должен будет рассмотреть еще пять областей при составлении своих рекомендаций, в результате чего общий круг ведения составит девять. Иннайос — круг ведения для швейцарской задачи (по состоянию на январь документы находятся в Департаменте транспорта. Он сказал, что « условия ссылки, сообщается в средствах массовой информации, являются расплывчатыми, неопределенными и не затрагивают основных проблем, связанных с отказом системы ». Источники сообщили, что глава Мусульманской лиги Авами (AML) шейх Рашид представил свое техническое задание в суде, где большая коллегия во главе с Анваром Захиром Джамали отметила, что судебная власть не обязана работать в соответствии с вашими условиями.Исламабад — лидер оппозиции в Национальном собрании Хуршид Шах в четверг официально направил премьер-министру Навазу Шарифу круг ведения (ТЗ), совместно составленный оппозиционными партиями для расследования утечек в Панаме. круг ведения (от 18 января 2008 г.) для вынесения арбитражного решения и, кроме того, что недействительный круг ведения не дает арбитру права продлевать установленный срок. В круге ведения указывается, что РОП, до пяти, будет предусматривать поддержка и «короваи безопасности» для тэпоари, сотрудников и членов NZNO; гарантирует, что тиканга всегда соблюдается; обеспечить культурное руководство; и давать советы и рекомендации по вопросам тиканги и маны.В письме Марана премьер-министру просили разбавить круг ведения и обеспечить, чтобы вопрос ценообразования на спектр оставался в ведении министерства связи. В июле министр связи Уэльса Шерил Гиллан дала понять, что комиссия будет создана с широким кругом полномочий. ссылка на нижнюю палату должна быть изменена, сказал Каземи.
.

указателей — Значение «ссылки» и «разыменования» в C

Переполнение стека

Около
Продукты
Для команд

Переполнение стека
Общественные вопросы и ответы
Переполнение стека для команд
Где разработчики и технологи делятся частными знаниями с коллегами
Вакансии
Программирование и связанные с ним технические возможности карьерного роста
Талант
Нанимайте технических специалистов и создавайте свой бренд работодателя
Реклама
Обратитесь к разработчикам и технологам со всего мира
О компании

текстовых справочных терминов | Написание

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

Основные текстовые справочные термины

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

↖	↘
выше	ниже
до	после
предыдущая	следующий
	на обороте
	продолжение продолжение ВОМ (BrE)

Ниже приведены словарные определения основных слов выше с примерами:

выше : упомянуто ранее или далее на той же странице

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

ниже : упомянуты ниже на той же странице или далее в тексте

наш дом на фото внизу справа
по указанному ниже адресу [американский английский]

предшествует : что предшествует или идет раньше

В предыдущих главах мы рассматривали эволюцию человека

после : что следует или будет дальше; о том, чтобы упомянуть

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

предыдущий : что предшествует или идет раньше

, как мы узнали в предыдущем разделе

следующий : что следует после текущего слова или отрывка

в следующей главе мы обсудим его историю

на обратной стороне : на другой стороне страницы или листа

ответы напечатаны на обратной стороне

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

PTO : сокращение от Please Turn Over [британский английский]. Мы пишем PTO внизу страницы, чтобы показать, что текст продолжается на другой стороне.

Иллюстрированные примеры текстовых ссылок

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

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

сверху / снизу

Цены выше могут быть изменены.
Два случая, описанные выше , произошли в прошлом году.
Подробнее см. выше слева.
Квартиры ниже уже свободны.
Доступны ниже квартир (AmE).
Отель на фото внизу слева .

предыдущая / следующая

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

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

предыдущая / следующая

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

на обороте

Прейскурант напечатан на обороте .
Для получения более подробной информации см. на обороте .
Эти апартаменты доступны по указанным ценам на обороте .

продолжение

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

ВОМ

Аббревиатура PTO или P.T.O. (для «Пожалуйста, переверните») можно написать в конце страницы, чтобы показать, что текст продолжается на другой стороне. [Британский английский]

напротив

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

См. Фото напротив .
В таблице на странице напротив перечислены наши отели.

Позиции страниц

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

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

электронных источников // Purdue Writing Lab

Примечание: На этой странице отражена последняя версия руководства по публикации APA (т. Е. APA 7), выпущенная в октябре 2019 года. Аналогичный ресурс для более старого стиля APA 6 можно найти здесь.

Важное примечание: Для некоторых электронных ссылок необходимо использовать скобки. Стиль APA требует, чтобы их содержимое было заключено в квадратные скобки без пробелов (например, [содержимое в квадратных скобках] должно выглядеть так).По возможности указывайте в ссылках год, месяц и дату. Если месяц и дата недоступны, используйте год публикации. Кроме того, выпуск APA 7 ^th больше не требует использования «Получено из» перед URL-адресами или DOI; однако для разархивированных ресурсов делаются особые исключения. Включение даты извлечения для этих источников указывает читателям, что версия работы, которую они извлекают , может отличаться от версии , которая использовалась изначально.

Обратите внимание: ниже содержит список наиболее часто цитируемых электронных источников.Полный список ссылок на электронные источники см. В издании 7 ^th Руководства по публикациям APA.

Веб-страница или часть онлайн-контента

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

Фамилия, Ф. М. (год, месяц, число). Название страницы . Название сайта. URL

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

Название группы. (Год, Месяц, Дата). Название страницы . Название сайта. URL

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

Название страницы . (Год, Месяц, Дата). Название сайта. Дата месяца, год, полученный по URL-адресу

Если дата публикации не указана, используйте аббревиатуру (n.г.).

Автор или название группы. (нет данных). Название страницы . Название сайта (если применимо). URL

Статья в Википедии

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

Название статьи. (Год, Месяц, Дата). В Википедия. URL архивной версии страницы

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

Статья в интернет-научном журнале: цитирование DOI

Обратите внимание: поскольку онлайн-материалы могут потенциально изменять URL-адреса, APA рекомендует указывать идентификатор цифрового объекта (DOI), когда он доступен, а не URL-адрес.DOI — это попытка предоставить стабильные и долговечные ссылки для онлайн-статей. Они уникальны для своих документов и состоят из длинного буквенно-цифрового кода. Многие — но не все — издатели будут указывать DOI статьи на первой странице документа.

Также обратите внимание, что некоторые онлайн-библиографии предоставляют DOI статьи, но могут «скрывать» код под кнопкой, которая может читаться как «Статья» или может быть сокращением имени поставщика, например «CrossRef» или «PubMed». Эта кнопка обычно ведет пользователя к полной статье, которая будет включать DOI.Найдите DOI в печатных публикациях или в публикациях, которые ведут по мертвым ссылкам, с помощью функции doi.org «Разрешить DOI», доступной на домашней странице сайта.

APA 7 также советует авторам включать DOI (если таковой имеется) даже при использовании источника печати.

Статья из онлайн-журнала с присвоенным DOI

Фамилия, Ф. М. и Фамилия, Ф. М. (год). Название статьи. Название журнала, том (выпуск ), номера страниц. DOI

Дроллингер Т., Комер Л.Б. и Уоррингтон П. Т. (2006). Разработка и валидация шкалы активного чуткого слушания. Психология и маркетинг, 23 (2), 161-180. https://doi.org/10.1002/mar.20105

Статья из онлайн-журнала без присвоенного DOI

Если статья в онлайн-научном журнале не имеет DOI и опубликована на веб-сайте, укажите URL-адрес. Если научная онлайн-статья не имеет DOI и опубликована в базе данных, не включайте URL-адрес или какую-либо информацию из базы данных.Единственное исключение — для баз данных, которые публикуют статьи, которые находятся в ограниченном тираже (например, ERIC) или доступны только в этой конкретной базе данных (например, UpToDate). Обратите внимание, что даты извлечения требуются для неархивированных источников, которые могут или должны изменяться с течением времени.

Абстрактные

APA 7 ^th edition не содержит инструкций по цитированию рефератов. Однако, если вы используете только информацию из аннотации, но доступен также полный текст статьи, мы советуем вам добавить «[Аннотация]» после названия статьи или источника.Если полный текст недоступен, вы можете использовать реферат, доступный через базу данных рефератов, в качестве вторичного источника.

Новости онлайн Артикул

Примечание: Формат этого типа источника зависит от того, исходит ли ваш источник от сайта с связанной газетой.

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

Фамилия, Ф.М. (год, месяц, число). Название статьи. Название публикации . URL

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

Фамилия, Ф. М. (год, месяц, число). Название статьи . Название издательского сайта. URL

Электронные книги или книги для Kindle

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

Фамилия, Ф.М. (Год). Название книги . Издатель. URL

Фамилия, Ф.М. (Год). Название книги [электронное издание]. Издатель. URL

Фамилия, Ф.М. (Год). Название книги (Н. Рассказчик, Рассказчик) [Аудиокнига]. Издатель. URL (если есть)

Диссертация / Диссертация из базы данных

Фамилия, Ф.Мое ухо). Название диссертации или диссертации (№ публикации) [Докторская или магистерская диссертация, название учреждения, присуждающего ученую степень]. Имя базы данных.

Дуйс, Дж. М. (2008). Концепции кислотно-основной химии и родственной органической химии студентов бакалавриата-органической химии . (Публикация № 3348786) [Докторская диссертация, Университет Северного Колорадо]. ProQuest Dissertations and Theses Global.

Запись в онлайн-словаре, тезаурусе или энциклопедии с групповым автором

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

Название учреждения или организации. (Год). Заголовок статьи. В Название справочной работы . URL

Запись в онлайн-словаре, тезаурусе или энциклопедии с индивидуальным автором

Фамилия, Ф.М. (Год). Заголовок статьи. В Ф. М. Фамилия (ред.), Название справочной работы (издания). Издатель. URL или DOI

Примечание: Если словарь, тезаурус или энциклопедия не включают издание, просто пропустите этот шаг.

Наборы данных

Фамилия, F. M. или название группы (год). Название набора данных (Номер версии) [Набор данных]. Издатель. DOI или URL

Графические данные (например, интерактивные карты, инфографика и другие графические представления данных)

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

Качественные данные и онлайн-интервью

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

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

Онлайн-лекции и слайды презентаций

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

Фамилия, Ф. М. (год, месяц, число). Название презентации [Конспекты лекций, слайды PowerPoint и т. Д.]. Издатель. URL

Компьютерное программное обеспечение / загружаемое программное обеспечение

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

Фамилия, Ф. М. или название группы. (Год). Название программы (№ версии). Издатель. URL

Электронная почта

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

(E.Роббинс, личное сообщение, 4 января 2001 г.).

Публикация в онлайн-форуме или обсуждении

Фамилия, F. M. или имя группы [имя пользователя]. (Год, Месяц, Дата). Заголовок сообщения [Сообщение на форуме]. Издатель. URL

Твитнуть

Фамилия, Ф. М. или название группы [@username]. (Год, Месяц, Дата). Содержание сообщения до первых 20 слов [Tweet]. Название сайта. URL

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

National Geographic [@NatGeo]. (2020, 12 января). Ученые знали, что африканские серые умны, но теперь задокументировано, что они помогают другим представителям своего вида — даже незнакомцам [Tweet; миниатюрная ссылка на статью]. Twitter. https://twitter.com/NatGeo/status/1216346352063537154

Профиль Twitter

Фамилия, Ф. М. или название группы [@username]. (нет данных). Твитов [профиль в Твиттере]. Дата месяца, год, полученный по URL-адресу

Сообщение в Facebook

Фамилия, Ф.М. или название группы. (Год, Месяц, Дата). Содержание сообщения до первых 20 слов [Тип сообщения]. Название сайта. URL

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

Страница Facebook

Фамилия, Ф. М. или название группы. (нет данных). Home [страница в Facebook]. Название сайта. Дата месяца, год, полученный по URL-адресу

Фото или видео из Instagram

Фамилия, Ф.M. или название группы [@username]. (Год, Месяц, Дата). Содержание сообщения до первых 20 слов [Тип сообщения]. Название сайта. URL

BBC [@bbc]. (2020, 12 января). наблюдателей за небесами побывали в первом полнолунии 2020 года, известном как «волчья луна», одновременно с [фотография]. Instagram. https://www.instagram.com/p/B7OkWqbBwcf/

Сообщение в блоге

Фамилия, Ф. М. (год, месяц, число). Заголовок сообщения. Издатель .URL

YouTube или другое потоковое видео

Фамилия, Ф. М. [Имя пользователя]. (Год, Месяц, Дата). Название видео [Видео]. Потоковая служба. URL

Примечание : Автором считается человек или группа, загрузившие видео. Если имя автора совпадает с именем пользователя, вы можете опустить [Имя пользователя].

Ted Talk

Автор, А.А. (Год, Месяц). Название доклада [Видео]. ТЕД. URL

Или (если на YouTube)

Имя пользователя.(Год, Месяц, Дата). Название доклада [Видео]. YouTube. URL

Эпизод подкаста

Хост, А. А. (Хост). (Год, Месяц, Дата). Название серии (номер, если предоставлено) [Эпизод аудиоподкаста]. В Название подкаста . Издатель. URL