В техническом задании или в задание как правильно писать: «В задании» или «в задание» как пишется? Есть 1 правило!

«В заданиИ» или «в заданиЕ» ℹ️ как правильно писать окончание в слове, правописание части речи, примеры предложений и словосочетаний

Алгоритм написания существительного

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

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

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

В первом случае это существительное написано в винительном падеже, поэтому в окончании ставится буква «е». Второй пример: существительное написано уже в предложном падеже, поэтому в окончании слова написана буква «и».

Точно таким же будет написание на латинице. Например, «v zadanie» или «v zadanii». Чтобы проверить себя можно просклонять по падежам. Более сложный пример — это уменьшительное существительное «заданьице».

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

Правило русского языка

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

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

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

Неправильное написание слова

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

Для наглядности следует разобрать примеры неправильного употребления:

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

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

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

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

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

Как составить ТЗ: подробная инструкция по созданию технического задания

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

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

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

Наши продукты помогают вашему бизнесу оптимизировать расходы на маркетинг

Узнать подробнее

Для чего нужно техническое задание?

Техническое задание не менее значимо, чем юридический акт, в деле закрепления прав и обязанностей сторон — заказчика и исполнителя.

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

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

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

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

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

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

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

Во многих вакансиях на позицию системного аналитика или технического писателя можно встретить требование: знание ГОСТ 19 и ГОСТ 34. Что это такое?

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

10 опасных ошибок в техническом задании

Техническое задание описывает работы, которые должен выполнить исполнитель, и требования к ним. Кажется, опиши все подробно в ТЗ – и проблем на проекте не будет! На практике многие ТЗ содержат опасные ошибки, которые могут серьезно «аукнуться» исполнителю. Давайте разберемся, что нельзя делать в техническом задании? Чтобы было нагляднее, приведем реальные примеры.

1. Недостаточная конкретность

Опасная ошибка, которая может привести к переработкам. Например, в ТЗ указано: «исполнитель обязан написать текст объемом 2000 знаков». Исполнитель считает знаки с пробелами, а заказчик – без пробелов. ТЗ определенность не вносит – про пробелы в нем информации нет.

Правильно написать: «исполнитель обязан написать текст объемом 2000 знаков с пробелами», если вы считаете пробелы.

Или еще пример. В техническом задании написано: «уникальность текста должна быть не менее 80%». Вроде бы все хорошо, но возникает вопрос: в какой системе считается уникальность? Клиент смотрит в одной, вы – в другой. Значения получаются разные. Назревает конфликт.

2. Конкретное значение вместо интервала

Ну вот, мы написали «2000 знаков с пробелами». Кажется, все учли. А нет! Сдаем заказчику текст, а там «всего 1998 знаков». Клиент не доволен – работа не соответствует ТЗ. И он прав! Теперь вам придется думать, как сдать текст объемом ровно 2000 знаков. Кстати, если получится 2001 знак – это тоже нарушает ТЗ.

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

3. Использование интервала вместо конкретного значения

И это может быть ошибкой! Например, вы пишете в ТЗ: «сайт должен корректно открываться во всех современных браузерах». А что это такое, современные браузеры? Для клиента – IE 6 – тоже вполне современный, установлен на компьютере, который пылится на даче и редко включается. Но ведь работает!

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

4. Гарантии невозможного

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

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

5. Отсутствие определений к терминам

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

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

6. Наличие субъективных требований

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

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

Главное: субъективных требований в ТЗ быть не должно!

7. Неполное ТЗ

Хуже сорванного дедлайна, честное слово! Например, вы подробно описали функционал сайта, а добавить структуру в техническое задание – забыли! И начались прения с клиентом: вы думали делать сайт из 10 страниц, а клиент уверен, что страниц должно быть 100, и не меньше!

А еще возник вопрос, кто должен писать тексты для сайта? Клиент уверен – разработчик, а в ТЗ про то, кто должен предоставить контент – ничего не сказано.

8. Все, что не оговорено, выполняется на усмотрение исполнителя

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

9. Устное ТЗ

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

10. А клиент в курсе, что написано в ТЗ?

Убедитесь, что клиент внимательно прочитал техническое задание минимум 2 раза, и у него нет вопросов. Ошибочно думать, что можно написать в ТЗ любые требования к проекту, а если заказчик их не прочитал – это его проблемы. Это ваши проблемы! Если клиент не прочитал ТЗ, значит, он считает его формальностью, а при реализации проекта потребует делать «как он сказал, а что написано в ТЗ – это не важно». Можно, конечно, идти на конфликт, но зачем он вам нужен?

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

Полезные статьи по теме:

Рекомендуем

Работа с возражениями – пожалуй, самая неприятная часть отношений с клиентами. Если возникли возражения – значит, заказчик в чем-то не согласен с …

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

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

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

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

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

Нарушение 1: неясные формулировки, значения

Из описания объекта закупки должно быть однозначно понятно, что заказчик собирается закупить. Требования к показателям характеристик (min, max или точные значения) следует указывать недвусмысленно, предельно понятно и доступно. Согласно ч. 1 и ч. 2 ст. 33 документация должна содержать требования, которые позволяют установить подходят ли предлагаемые товары, (работы или услуги) заказчику. Не следует использовать термины наподобие «не хуже», «не слабее» и тому подобные, это не объективное описание. Что для заказчика лучше, а что хуже, поставщик не обязан знать или угадывать.

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

«Требования к товару. Товар (далее — мебель) должен соответствовать ГОСТ 16371-2014 «Мебель. Общие технические условия» (введен в действие Приказом Росстандарта от 15.06.2015 № 683-ст), ГОСТ 26800.1-86 «Мебель для административных помещений. Функциональные размеры столов». Наименование товара — стол эргономичный. Размер, Ш x Г x В (ширина, глубина, высота): — минимальные значения — 100 x 100 x 71,5 см; — максимальные значения — 165 x 110 x 71,5 см. При этом высота не подлежит изменению. Цвет: коричневый. Требования к столешнице: Материал — высококачественная МДФ, толщина: минимальное значение — 12 мм, максимальное значение — 35 мм. Облицовка — ПВХ-пленка. Столешница должна быть эргономичной и иметь плавные края. В столешнице должно быть предусмотрено отверстие для проводов с заглушкой.»

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

Достаточно часто заказчики переписывают с государственных стандартов все подряд характеристики, при этом товар не может обладать всеми требуемыми характеристиками одновременно. Например, что касается подвижности и жесткости бетона ГОСТ 7473-2010. Бетон может быть либо жестким (Ж), либо подвижным (П). Это взаимоисключающие характеристики. Однако, заказчики умудряются вписать в техзадание и то и другое: жесткость Ж1-Ж4; подвижность П1-П4. Материала с такими характеристиками не может быть. И это является нарушением ч. 2 ст. 33 44-ФЗ.

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

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

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

Нарушение 2: ссылка на ГОСТ без какого-либо описания

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

Нарушение 3: отсутствие фразы «или эквивалент»

Распространённой ошибкой также является указание в описании объекта закупки требования к товарному знаку без ссылки на возможность применения эквивалента, что может привести к ограничению конкуренции. Узнайте подробнее об этом требовании закона в видео на сайте Школы электронных торгов «Правила составления технических заданий в рамках закона 44-ФЗ и требования к их содержанию»

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

Ещё несколько рекомендаций при составлении техзадания по 44-ФЗ

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

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

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

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

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

Какие ещё требования важно указать в техзадании:

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

Главные правила

1. При подготовке документации о закупке обратите внимание на коды Общероссийского классификатора продукции (ОКПД2), относящиеся к объекту закупки. Необходимо чтобы использованный код совпадал с конкретным объектом закупки.
2. Помимо положений 44-ФЗ, разрабатывая техзадание следует иметь в виду также требования иных правовых актов, антимонопольных органов, технических норм и стандартов (ГОСТ, ТУ, СНиП и т.д.).
3. Товары и материалы, запрашиваемые заказчиком в техническом задании, должны соответствовать объекту закупки и сметной документации (если такая имеется).
4. При закупке на строительный подряд необходимо также приложить дефектную ведомость, смету, а в случае капитального строительства (реконструкции, капитального ремонта) также необходимо приложить и проектную документацию.
5. Указывайте, что хотите закупить новые товары и материалы (т.е. они не использовались, не находились в ремонте, реставрации, не были восстановлены). Иначе, заказчик может получить б/у товары.

Распространенные вопросы

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

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

Вопрос: Нужно приобрести прибор для научных исследований к уже имеющейся системе из 3-х приборов одного производителя. Необходимо полное совмещение всего в работе. Эквивалент не желателен. Можно не писать эквивалент и указать производителя? Система тонко настраиваемая и дорогая.
Ответ: Если Ваш случай подходит под «…за исключением случаев несовместимости товаров, на которых размещаются другие товарные знаки, и необходимости обеспечения взаимодействия таких товаров с товарами, используемыми заказчиком…) – можно, в других случаях — нельзя.

Обучение по 44-ФЗ, 223-ФЗ

Повышение квалификации и профпереподготовка в Контур.Школе

Подробнее о курсах

Вопрос: Можно ли в техзадании по капремонту указать узкие показатели, например, цвет стен с конкретным колером, приложить пример композиции из гипсокартона на потолке, конкретную коллекцию плитку без эквивалента, ссылаясь на эстетические предпочтения?
Ответ: При формировании технического задания заказчики должны руководствоваться требованиями статьи 33 Закона № 44-ФЗ. Цвет стен — это выбор заказчика, это его потребность, не ограничивающая число поставщиков. Макет, эскиз композиции из гипсокартона на потолке — это также потребность заказчика, все исполнители смогут повторить приведённый в документации макет. Коллекция плитки без эквивалента — это нарушение пункта 1 статьи 33 Закона № 44-ФЗ: «Документация о закупке может содержать указание на товарные знаки в случае, если при выполнении работ, оказании услуг предполагается использовать товары, поставки которых не являются предметом контракта. При этом обязательным условием является включение в описание объекта закупки слов «или эквивалент». 

10 заповедей технического задания (с толкованием). Читайте на Cossa.ru

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

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

Форматы ТЗ перерабатывались, перерабатываются и будут перерабатываться. Формулировки переписываются, какие-то разделы вымарываются, новые добавляются. Толщина документа непостоянна, как ветер мая.

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

Из этих вопросов и родились «10 заповедей о техническом задании». Я посмотрел на ТЗ не как на документ (артефакт), а как на часть процесса производства, и все стало ясно.

1. ТЗ — обязательный документ при создании любого продукта

Миф о том, что для простых проектов ТЗ не нужно, не выдерживает критики. Нужно! И для простого, и для сложного. Просто для простых проектов пишите простое ТЗ, а для сложных — сложное, если вы верите, что для ТЗ такая градация существует в принципе.

2. ТЗ описывает продукт, но не проект

ТЗ должно отвечать на вопрос «Что делаем?», но не «Как делаем?».

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

3. ТЗ не является договором

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

4. ТЗ описывает не только функциональные требования, но и интерфейс

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

5. ТЗ составляет только обладающий соответствующей компетенцией специалист

Звучит просто, а реализуется сложно.

Я не верю в клиентские ТЗ. Я не верю в ТЗ, которые пишут менеджеры. Кто же его пишет?

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

6. ТЗ разрабатывается после этапа дизайна, но до начала верстки

Подробно я об этом уже писал на Cossa. Коротко. Если делать ТЗ до дизайна, то устанете вносить изменения в этот документ, и потратите кучу сил/денег/времени/сотрудников/заказчиков. Поэтому мы в qb.digital перешли на относительно новую для рынка схему, когда ТЗ делается уже после утверждения дизайна. Таким образом, техническое задание у нас не диктует требования к дизайну, потому что у него на то нет компетенции, а фиксирует дизайн. Тут же возникает резонный вопрос: «А по чему рисуется дизайн?». Отвечаем: по концептуальному описанию, функциональному описанию и прототипам.

7. ТЗ не терпит правок после его утверждения

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

8. ТЗ может править только его автор или обладающий компетенцией специалист

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

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

9. ТЗ должно описывать, как минимум, текущую версию продукта

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

10. ТЗ должно быть прочитано, понято и утверждено всеми заинтересованными лицами

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

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

Ликбез по техническому заданию / Хабр

Польза: получите знания о том, что такое ТЗ и как его составить. Обогатите словарный запас словами: концептуальная модель, data flow, mind card, user flow. use cases, wireframes, ER-model, client-server, API.

Для кого: начинающим разработчикам и желающим чтобы их поняли (заказчикам, стартапам и менеджерам).

Время чтения: 7 минут.

Отправная точка — требования

Хочу пирожное, потом морожное!

Вовка в тридевятом царстве

Существует распространенное заблуждение, что достаточно сказать: “Нужно приложение для музея/кошки/завода” и сразу станет понятно, что вам необходимо.

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

Через полгода вас ожидает нечто в поле и вообще с забором серобуромалинового цвета.

Жутко правда? Бюджет уже потрачен и срок истек.

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

Удобный вид требований — ТЗ

Замесить и нарубить!

Вовка в тридевятом царстве

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

Его также называют ТЗ, SRS, PRD — все это названия документа, в котором в правильной форме зафиксированы требования к продукту.

Подводный камень №2: память человека не безгранична, всегда лучше иметь одно место, где все ваши пожелания и требования зафиксированы (не переписка в telegram или звонок по телефону). Поэтому ТЗ это печатный текстовый документ с приложением схем и инфографики, не написанный от руки или сфотографированный. Лучше всего в формате .PDF или Google Docs.

Рецепт грамотного ТЗ

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

• Концептуальная модель
• Функциональная карта
• Путь пользователя
• Пользовательский интерфейс
• Программные интерфейсы
• Нефункциональные требования

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

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

Концептуальная модель

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

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

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

Стоит рассказать о типах пользователей и их ключевых отличиях.

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

И в завершении расскажите о компонентах вашего продукта.

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

Высшим пилотажем будет сделать так называемый data flow или контекстную диаграмму, в которой будет отражено как пользователи взаимодействуют с продуктом, его компонентами и между собой.

Функциональная карта

Функциональная карта отображает общую концепцию проекта с уровнем детализации необходимым для того, чтобы оценить объем работ, расставить приоритеты.В традиционном формате такая карта напоминает карту сайта. Но удобнее всего ее отобразить в виде mind card (майнд карт, интеллект карт). Часто менеджеры рисуют на совещании на доске или листе бумаги слова и между ними связи, так вот, это и есть майнд карта. Это можно сделать удобно в бесплатных сервисах (coggle, draw.io и mindmeister) или просто в Office Word.

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

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

Путь пользователя

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

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

Путь пользователя — это общий алгоритм работы с продуктом. Также существует еще use cases (варианты использования) — это детализация user flow. В случае мобильного приложения для знакомств вы создали путь пользователя по экранам, а затем описываете, что пользователь может сделать на каждом экране.

Например: на экране регистрации пользователь может:

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

Пользовательский интерфейс

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

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

Дизайнеры скажут вам большое спасибо, если вы укажите стиль дизайна интерфейса, например flat design или material design.

Высшим пилотажем будет добавить wireframes (вайрфреймы) — прототипы интерфейса продукта в виде приближенных схем.

Программные интерфейсы

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

Сервер декомпозируется на модули: базы данных, аутентификации, чата и т.д.Клиент связывается с сервером через API (интерфейсы передачи данных), стоит указать его тип (REST, WEB, RPC и т.д.) и описать методы, ответы и обработку ошибок.

Данные обычно хранятся в базе данных в виде специальных структур, чаще всего таблиц (для реляционных БД) и json структур (для нереляционных). Разработчики скажут вам огромное спасибо, если в техническом задании вы укажите сущности базы данных (ER-модели) и опишите хранимые поля, с указанием их типов данных (string, int и т.д), ключей (primary, foreign), обязательности (required) и пустого значения (nullable).

Нефункциональные требования

Это общие требования к продукту. Их можно разделить на требования к техническому обеспечению, требования безопасности и требования к производительности.В требованиях к техническому обеспечению указывают пожелания к устройствам и операционной среде, например для приложения знакомств это Android 7.0+ и JDK 8+, iOS 11.0+ и Swift 4.2.

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

Советы

1. Создавайте текстовый документ в онлайн офисе или PDF, который легко будет прочесть. Это гораздо лучше переписки в чате или голосового сообщения, его всегда можно будет посмотреть с любого устройства.
2. Соблюдайте последовательность, переходите от общих требований к частным, приведенная выше структура не идеальна, но может служить хорошей основой.
3. Все требования должны быть в одном документе или вики-структуре, не храните их отдельно, они должны быть всегда доступны из одного источника.
4. Давайте четкие и разумные указания, избегайте неточностей, пишите максимально простым языком.
5. Описывайте ваши требования максимально подробно. Лучше один раз все продумать, чем постоянно уточнять различные детали и нюансы.
6. Приготовьтесь потратить больше нескольких дней или обратитесь к профессионалу для составления документа. Грамотное техническое задание спасет вас от долгих обсуждений деталей с разработчиками и обозначит четкие критерии сдачи проекта. Например, полноценное ТЗ по стандарту IEEE-830, приложенное к договору на разработку, является аргументов в суде в случае невыполнения требований.

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

Понимание письменных заданий // Письменная лаборатория Purdue

Понимание письменных заданий

Резюме:

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

Как расшифровать задание на бумаге

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

1. Прочтите подсказку полностью один раз. Это дает вам общее представление о том, что происходит.
2. Подчеркните или обведите в кружок те части, которые вам абсолютно необходимо знать. Эта информация может включать дату выполнения, требования к исследованиям (источникам), длину страницы и формат (MLA, APA, CMS).
3. Подчеркните или обведите важные фразы. Вы должны хотя бы немного узнать своего инструктора — какие фразы он использует в классе? Он неоднократно произносит определенное слово? Если они указаны в приглашении, вы знаете, что преподаватель хочет, чтобы вы использовали их в задании.
4. Подумайте, как вы ответите на подсказку. Подсказка содержит подсказки о том, как написать задание. Ваш преподаватель часто будет описывать идеи, которые они хотят обсудить, в вопросах, в виде маркированного списка или в тексте подсказки. Подумайте о каждом из этих предложений и пронумеруйте их, чтобы при необходимости можно было написать абзац или раздел своего эссе по этой части.
5. Расположите идеи в порядке убывания от наиболее важных к наименее важным. Преподаватели могут включать больше вопросов или тем для обсуждения, чем вы можете охватить в своем задании, поэтому расположите их в том порядке, в котором вы считаете более важным.Одна часть подсказки может быть вам интереснее, чем другая.
6. Задайте вопросы своему инструктору, если они у вас есть.

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

1. Какова цель данного задания? Моя цель — предоставить информацию без аргументации, построить аргумент на основе исследования или проанализировать стихотворение и обсудить его образы?
2. Кто моя аудитория? Мой инструктор — моя единственная аудитория? Кто еще мог это прочитать? Будет ли он размещен в Интернете? Каковы потребности и ожидания моих читателей?
3. Какие ресурсы мне нужны, чтобы начать работу? Нужно ли мне проводить литературные (герменевтические или исторические) исследования, или мне нужно просмотреть важную литературу по данной теме, а затем провести эмпирическое исследование, такое как опрос или наблюдение? Сколько требуется источников?
4. С кем, помимо моего инструктора, я могу связаться, чтобы помочь мне, если у меня возникнут вопросы? Есть ли у вас письменная лаборатория или центр обслуживания студентов, предлагающий письменные инструкции?

Примеры

(Примечания к подсказкам выделены синим цветом)

Плакат или анализ песни: Плакат или песня? Плакат!

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

На что следует обратить внимание: темы для разговора

Плакат:

• Как плакат обращается к своей аудитории и зависит от контекста Я сделаю это в первую очередь — 1.
• Общий план, использование цвета, светотени и т. Д.
• использование контраста, выравнивания, повторения и близости C.A.R.P. Они тоже так говорят. Я сделаю это третьим — 3.
• точка зрения, которую предлагается принять зрителю, позы фигур на плакате и т. Д.любой текст, который может присутствовать
• возможных культурных разветвлений или социальных проблем, которые имеют значение, я расскажу в эту секунду — 2.
• этические последствия
• как плакат влияет на нас эмоционально или какое настроение вызывает
• Неявный аргумент плаката и его эффективность говорят о том, что это было важно в классе, поэтому я буду обсуждать это в последнюю очередь — 4.

Песня:

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

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

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

Длина: 4 страницы Формат: Печатный, с двойным интервалом, 10–12 пунктов Times New Roman, поля в 1 дюйм. Мне нужно запомнить формат.Я напортачил в прошлый раз = (

Эссе по академической аргументации

5-7 страниц, Times New Roman 12 pt. шрифт, поля 1 дюйм.

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

• Срок сдачи проекта: чт. 10/19
• Срок подачи черновика: понедельник 30.10.
• Окончание драфта: чт. 11/9

Помните это! Последний раз пропустил срок

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

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

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

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

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

.

c ++ — Как правильно написать оператор присваивания для производного класса

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

1. Около

2. Продукты

3. Для команд

1. Переполнение стека
   Общественные вопросы и ответы

2. Переполнение стека для команд
   Где разработчики и технологи делятся частными знаниями с коллегами

3. Вакансии
   Программирование и связанные с ним технические возможности карьерного роста

4. Талант
   Нанимайте технических специалистов и создавайте свой бренд работодателя

5. Реклама
   Обратитесь к разработчикам и технологам со всего мира

6. О компании

.

Основные правила // Лаборатория письма Purdue

Эта страница предоставлена ​​вам OWL в Университете Пердью. При печати этой страницы вы должны включить полное юридическое уведомление.

Авторские права © 1995-2018, Лаборатория письма и СОВ при Университете Пердью и Пердью. Все права защищены. Этот материал нельзя публиковать, воспроизводить, транслировать, переписывать или распространять без разрешения. Использование этого сайта означает принятие наших условий добросовестного использования.

Справочный лист: Основные правила

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

Этот ресурс, отредактированный в соответствии с руководством по публикациям APA 7 ^th edition, предоставляет фундаментальные рекомендации по созданию справочных страниц для исследовательских работ. Для получения дополнительной информации обратитесь к Руководству по публикациям Американской психологической ассоциации (7 ^th ed.).

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

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

Форматирование справочного списка

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

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

Основные правила для большинства источников

• Все строки после первой строки каждой записи в вашем списке ссылок должны иметь отступ на полдюйма от левого поля. Это называется выступом.
• Имена всех авторов должны быть перевернуты (т.е. сначала должны быть указаны фамилии).
• Имя и отчество авторов должны быть написаны инициалами.
  • Например, справочная запись для источника, написанного Джейн Мари Смит, должна начинаться с «Smith, J.М. «
  • Если отчество недоступно, просто инициализируйте имя автора: «Smith, J.»
• Указывайте фамилии и первые / средние инициалы для всех авторов конкретной работы до 20 авторов включительно (это новое правило, поскольку APA 6 требует только первых шести авторов). Отделите инициалы каждого автора от следующего автора в списке запятой. Используйте амперсанд (&) перед именем последнего автора. Если есть 21 или более авторов, используйте многоточие (но без амперсанда) после 19-го автора, а затем добавьте имя последнего автора.
• Записи в списке литературы должны быть расположены в алфавитном порядке по фамилии первого автора каждой работы.
• Для нескольких статей одного автора или авторов, перечисленных в одном порядке, перечислите записи в хронологическом порядке, от самых ранних до самых последних.
• При ссылке на заголовки книг, глав, статей, отчетов, веб-страниц, или других источников используйте только первую букву первого слова заголовка и подзаголовка, первое слово после двоеточия или тире в заголовке. , и существительные собственные.
  • Еще раз отметим, что названия академических журналов регулируются особыми правилами. См. Раздел ниже.
• Выделите курсивом названия более длинных произведений (например, книг, отредактированных сборников, названий газет и т. Д.).
• Не выделяйте курсивом, не подчеркивайте и не ставьте кавычки названия более коротких произведений, таких как главы в книгах или эссе в отредактированных сборниках.

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

• Привести названия журналов полностью.
• Названия журналов выделите курсивом.
• Сохраняйте любые нестандартные знаки пунктуации и заглавные буквы, которые используются в названии журнала.
  • Например, вы должны использовать PhiloSOPHIA вместо Philosophia, или Прошлое и настоящее, вместо Прошлое и настоящее.
• Сделайте заглавными буквами всех основных слов в заголовках журналов . Обратите внимание, что это отличается от правила для названия других распространенных источников (например, книг, отчетов, веб-страниц и т. Д.), Описанного выше.
  • Это различие основано на типе цитируемого источника. В названиях научных журналов все основные слова пишутся с заглавной буквы, в названиях других источников — нет.
• Напишите с заглавной буквы первое слово заголовков и подзаголовков статей журнала , а также первое слово после двоеточия или тире в названии и любых имен собственных .
• Не выделяйте курсивом и не подчеркивайте заголовок статьи.
• Не заключайте название статьи в кавычки.
  • Так, например, если вам нужно процитировать статью под названием «Deep Blue: The Mysteries of the Marianas Trench», которая была опубликована в журнале Oceanographic Study: A Peer-Reviewed Publication, вы должны написать заголовок статьи как следует:
    • Deep blue: Тайны Марианской впадины.
  • … но вы бы написали название журнала следующим образом:
    • Океанографическое исследование: рецензируемая публикация

Обратите внимание: Хотя руководство APA предоставляет примеры того, как цитировать общие типы источников, оно не охватывает все возможные источники.Если вы должны указать источник, на который APA не ссылается, APA предлагает найти пример, похожий на ваш источник, и использовать этот формат. Для получения дополнительной информации см. Страницу 282 Руководства по публикациям Американской психологической ассоциации , 7 ^th ed.

.

висящих модификаторов и способы их исправления // Purdue Writing Lab

Висячие модификаторы и способы их исправления

Резюме:

Этот ресурс объясняет, что такое модификатор «висячие» и как исправить проблему.

Авторы: Крис Берри, Карл Столли
Последнее редактирование: 07.01.2013 12:05:23

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

Закончив задание, Джилл включила телевизор.

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

Следующее предложение имеет неправильное употребление:

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

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

Стратегии пересмотра модификаторов висячих элементов:

1. Назовите подходящего или логического исполнителя действия в качестве предмета основного пункта:

Опоздав на тренировку, требовалось письменное извинение.

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

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

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

2. Измените фразу, которая висящая на полных вводных предложениях, указав исполнителя действия в этом предложении:

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

Кто не знал его имени? В этом предложении говорится, что «оно» не знало его имени. Чтобы исправить, решите, кто его пытался представить. Версия может выглядеть примерно так:

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

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

3. Объедините фразу и основное предложение в одно:

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

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

Он улучшил свои результаты, снова выполнив эксперимент.

Еще примеры модификаторов dangling и их модификации:

НЕПРАВИЛЬНО: после прочтения оригинального исследования статья остается неубедительной.

ПЕРЕСМОТРЕННОЕ: После прочтения оригинального исследования я считаю статью неубедительной.

НЕПРАВИЛЬНО: Ваш дом, освобожденный от обязанностей на работе, должен быть местом для отдыха.

ПЕРЕСМОТРЕННО: Освободившись от обязанностей на работе, вы сможете отдыхать дома.

НЕПРАВИЛЬНО: эксперимент закончился неудачей из-за отсутствия внимательного изучения руководства лаборатории.

ПЕРЕСМОТРЕННО: Они провалили эксперимент, не изучив внимательно лабораторное руководство.

.