Литеры конструкторской документации: Литера в КД, виды, порядок присвоения

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

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

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

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

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

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

Литера — Энциклопедия по машиностроению XXL

Подписи тех же лиц Дату подписания чертежа Литеры изменения чертежа  [c.114]

А (эту литеру присваивают чертежам установочной серии)  [c.114]

Б (эту литеру присваивают чертежам серийного или массового производства)  [c.114]

Количество изменений, одновременно произведенных по данной литере  [c.115]

Литеры изменения чертежа а — для первого случая изменения 6— для второго случая изменения и т. д.  [c.103]

Конструкторским документам в зависимости от стадии разработки присваивается литера. При выполнении технического проекта-литера Т. При разработке рабочей документации опытной партии — литера О установочной серии-литера А установившегося производства-литера Б.  [c.126]

Учебным чертежам может условно присваиваться литера У.  [c.126]

В графе 4 проставляется литера чертежа, которая на учебных чертежах условно может обозначаться буквой У.  [c.127]

В производственных чертежах по ГОСТ 2.103-68 указываются литеры в зависимости от стадии разработки конструкторской документации. Например, в рабочей документации опытного образца (опытной партии) — литерой О , установочной серии — литерой А , серийного и массового производства — литерой Б и т. д.  [c.127]

В графе 4 — литеру, присвоенную данному документу (см, п. 77.15)  [c.159]

Документам технического предложения присваивается литера Я эскизного проекта — литера 5 технического проекта — литера Т .  [c.217]

Конструкторским документам для индивидуального производства, предназначенным для разового изготовления изделия, присваивают литеру Я . Конструкторским документам опытного образца присваивают литеру Oj. При последующих (повторных) изготовлениях опытного образца, а также соответствующей корректировке конструкторских документов им присваивают литеры Юр, Оз и т. д. Конструкторским документам установочных серий изделия присваивают литеру Л , а установившегося серийного или массового производства — литеру .  [c.217]

Примечания 1. Учебным чертежам рекомендуется присваивать литеру ЯУ — индивидуальный, учебный.  [c.217]

Литера указывается в графе 4 (см. рис. 143) основной надписи.  [c.217]

Г рафа 4 — литера, присвоенная данному документу по ГОСТ 2.103-68.  [c.19]

Сталь, в свою очередь, подразделяется на четыре группы обыкновенную, качественную, инструментальную и легированную, в последнюю входит ряд компонентов, которым в обозначении марки стали соответствуют следующие литеры В — вольфрам Г — марганец Д — медь М — молибден Н — никель Р — бор С — кремний Т — титан Ф — ванадий X — хром Ю — алюминий.  [c.286]

Сплавы цветных металлов, полученные на основе меди и алюминия, широко распространены в машиностроении. В обозначении сплавов цветных металлов основным компонентам присваиваются следующие литеры А — алюминий, Ж — железо, К — кремний, Мг — магний, Мц — марганец, Н — никель, О — олово, С — свинец, Ф — фосфор, Ц — цинк.  [c.290]

Учебным конструкторским документам присваивают литеру У .  [c.389]

Смысл литер ЗД , помещаемых в начале обозначения стандарта, ясен из приводимого примера ЭД1 1155 6—87. Краны башенные строительные. ТУ. Экспортное дополнение. (Цифра 1 означает, что это дополнение является первым.) Литеру А добавляют к обозначению стандартов на изделия, предназначенные для атомной техники.  [c.12]

Проектная организация (конструкторское бюро), получив техническое задание на проектирование и изучив его, разрабатывает техническое предложение (документы литеры П ). Оно должно состоять из чертежа общего вида (ГОСТ 2.118—73 ), содержащего изображения вариантов изделия пояснительную записку — характеристику области и условий применения изделия и его основные технические характеристики расчеты, подтверждающие работоспособность и надежность конструкций, и др.  [c.157]

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

Разработка рабочей КД, как правило, подразделяется на ряд стадий разрабО Тка документации (без литеры) для изготовления опытного образца (или опытной партии) корректировка документации по результатам испытания опытного образца с присвоением ей литеры О корректировка документации по результатам повторного (при необходимости) испытания опытного об-  [c.157]

Литера характеризует степень отработки КД изделия, а также степень отработки и оснащения технологического процесса его изготовления.  [c.157]

Допускается не присваивать литеру эскизной конструкторской документации. Литерой полного комплекта КД изделия считают низшую из литер, указанных в документах, входящих в комплект. Литеру указывают в графе 4 основной надписи.  [c.158]

На учебных чертежах обычно применяют литеру У .  [c.158]

Литера, присвоенная данному документу по ГОСТ 2. 103—68 (графу заполняют последовательно, начиная с крайней левой клетки).  [c.9]

Лапка 140 Латунь 186 Линейка 138 Линии 10 Линии-выноски 33 Линии штриховки 53…56 Линия нулевая 68 Литера 9  [c.218]

Содержание граф / — наименование чертежа 2 — обозначение чертежа (устанавливает кафедра с учетом рекомендаций ГОСТ 2.201—80) 3 — обозначение материала детали (заполняют только на чертежах детален) 4 — литера чертежа (обычно в курсе черчения используют литеры У и О) 5 — масса изделия (на учебных чертежах обычно не указывают) 6 — масштаб 7 — порядковый номер листа (на документах, состоящих из одного листа, графу не заполняют) 8 — количество листов (графу заполняют только на первом листе), 9 — иачме-нование предприятия, выпустившего чертеж 10 — характер работы, выполняемой лицом, подписавшим чертеж (на учебных чертежах обычно заполняют первую строчку — Разработал , вторую — Проверил и последнюю — Утвердил ) и — фамилии лиц, подписавших чертеж 2 — подписи лиц, фамилии которых указаны в графе 11 13 — даты, когда были сделаны подписи 14—18 — предназначены для отметок изменений, вносимых в чертежи. (На учебных чертежах обычно остаются незаполненными).  [c.20]

На основе одобренного заказчиком технического предложения разрабатывается эскизный проект (документы литеры Э ), содержащий необходимые чертежи, схемы, расчетнопояснительную записку, технико-экономический анализ изделия и другие материалы, позволяющие, в частности, изготовить макет (ГОСТ 2.119—73 ).  [c.157]

ГОСТ 2.103-68 — Единая система конструкторской документации. Стадии разработки

ГОСТ 2.103-68

Группа Т52

МКС 01.110

Дата введения 1971-01-01

Утвержден Комитетом стандартов, мер и измерительных приборов при Совете Министров СССР в декабре 1967 г. Дата введения установлена 1971-01-01

Изменение N 2 принято Межгосударственным советом по стандартизации, метрологии и сертификации по переписке (протокол N 23 от 28 февраля 2006 г.)

За принятие изменения проголосовали национальные органы по стандартизации следующих государств: AZ, AM, BY, KZ, KG, MD, RU, TJ, TM, UZ, UA [коды альфа-2 по МЭК (ИСО 3166) 004]

ИЗДАНИЕ (апрель 2011 г. ) с Изменениями N 1, 2, утвержденными в июле 1981 г., июне 2006 г. (ИУС N 10-81, 9-2006)

ВНЕСЕНА поправка, опубликованная в ИУС N 2, 2012 год

Поправка внесена изготовителем базы данных

1. Настоящий стандарт устанавливает стадии разработки конструкторской документации изделий всех отраслей промышленности и этапы выполнения работ на каждой стадии разработки (см. таблицу).

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

Примечания:

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

2. Макет разрабатывается:

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

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

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

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

Макеты могут выполняться в материальной форме (материальный макет) или электронной форме (электронный макет).

3. Необходимость разработки макетов, их вид, условия и программы испытаний (анализа), а также необходимость разработки документации для изготовления и испытания макетов устанавливает разработчик. Требования к материальному макету — по ГОСТ 2.002-72, к электронному макету — по ГОСТ 2.052-2006.

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

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

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

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

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

3. (Исключен, Изм. N 1).

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

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

Перечень работ — по ГОСТ 2.118-73.

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

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

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

Перечень работ — по ГОСТ 2.119-73.

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

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

Перечень работ — по ГОСТ 2.120-73.

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

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

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

б) в конструкторской документации с литерами «» («»), «А» и «Б», если литерность применяемого документа та же или высшая.

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

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

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

Законы :: ГОСТ 2.103 от 0000-00-00 N 0

ГОСТ 2.103-68
 
Группа Т52

МЕЖГОСУДАРСТВЕННЫЙ СТАНДАРТ

Единая система конструкторской документации

СТАДИИ РАЗРАБОТКИ

Unified system for design documentation.
Stages of designing

     
     
Дата введения 1971-01-01

     
     УТВЕРЖДЕН Комитетом стандартов, мер и измерительных приборов при Совете Министров СССР в декабре 1967 г.
     
     ИЗДАНИЕ (март 2001 г.) с Изменением N 1, утвержденным в июле 1981 г. (ИУС N 10-81)
     
     ВНЕСЕНО Изменение N 2, принятое Межгосударственным Советом по стандартизации, метрологии и сертификации (протокол N 23 от 28. 02.2006). Государство-разработчик Россия. Приказом Ростехрегулирования от 22.06.2006 N 117-ст введено в действие на территории РФ с 01.09.2006 с правом досрочного применения
     
     Изменение N 2 внесено юридическим бюро по тексту ИУС N 9, 2006 год
             
     
     1. Настоящий стандарт устанавливает стадии разработки конструкторской документации изделий всех отраслей промышленности и этапы выполнения работ на каждой стадии разработки (см. таблицу).         
     
     

     
     
    Обязательность выполнения стадий разработки и этапов выполнения работ, форму представления конструкторской документации (бумажная или электронная) устанавливает разработчик, если это не предусмотрено техническим заданием на разработку.
     
     Примечания:
     
     1. Стадия «Техническое предложение» не распространяется на конструкторскую документацию изделий, разрабатываемых по заказу Министерства обороны.
     
     2. Макет разрабатывается:
     
     а) на стадии технического предложения с целью выявления и проверки вариантов основных конструктивных решений разрабатываемого изделия или его составных частей, анализа различных вариантов изделия, выявления дополнительных или уточненных требований к изделию;
     
     б) на стадии эскизного проекта с целью проверки принципов работы изделия или его составных частей, условий размещения в отведенном пространстве, условий эргономичности использования и других свойств изделия или его составных частей;
     
     в) на стадии технического проекта с целью проверки основных конструктивных решений разрабатываемого изделия или его составных частей по пространственно-кинематическому взаимодействию с другими изделиями и составных частей между собой, а также условий эргономичности;
     
     г) на стадии рабочего проекта для предварительной проверки целесообразности изменения отдельных частей изготовляемого изделия до внесения этих изменений в рабочие конструкторские документы опытного образца (опытной партии).
     

     Макеты могут выполняться в материальной форме (материальный макет) или электронной форме (электронный макет).
     
     3. Необходимость разработки макетов, их вид, условия и программы испытаний (анализа), а также необходимость разработки документации для изготовления и испытания макетов устанавливает разработчик. Требования к материальному макету — по ГОСТ 2.002-72, к электронному макету — по ГОСТ 2.052-2006.
              
     4. Под разовым изготовлением понимается единовременное изготовление одного или более экземпляров изделия, дальнейшее производство которого не предусматривается.
          
     5. При выполнении конструкторской документации в электронной форме требования к форматам данных рекомендуется устанавливать на предшествующей стадии разработки, если это не предусмотрено техническим заданием.
     
     
     (Измененная редакция, Изм. N 1, 2).
     
     2. Рабочим конструкторским документам изделия единичного производства, предназначенным для разового изготовления, присваивают литеру «И» при их разработке, которой может предшествовать выполнение отдельных стадий разработки (техническое предложение, эскизный проект, технический проект) и соответственно этапов работ, указанных в таблице.
     
     (Измененная редакция, Изм. N 1).
     
     3. (Исключен, Изм. N 1).
     
     4. Техническое предложение — совокупность конструкторских документов, которые должны содержать технические и технико-экономические обоснования целесообразности разработки документации изделия на основании анализа технического задания заказчика и различных вариантов возможных решений изделий, сравнительной оценки решений с учетом конструктивных и эксплуатационных особенностей разрабатываемого и существующих изделий и патентные исследования.
     
     Техническое предложение после согласования и утверждения в установленном порядке является основанием для разработки эскизного (технического) проекта.
     
     Перечень работ — по ГОСТ 2.118-73.
     

     (Измененная редакция, Изм. N 1, 2).
     
     5. Эскизный проект — совокупность конструкторских документов, которые должны содержать принципиальные конструктивные решения, дающие общее представление о назначении, об устройстве, принципе работы и габаритных размерах разрабатываемого изделия, а также данные, определяющие назначение, основные параметры и габаритные размеры разрабатываемого изделия.
     
     Эскизный проект после согласования и утверждения в установленном порядке служит основанием для разработки технического проекта или рабочей конструкторской документации.
     
     Перечень работ — по ГОСТ 2.119-73.
     
     6. Технический проект — совокупность конструкторских документов, которые должны содержать окончательные технические решения, дающие полное представление об устройстве разрабатываемого изделия, и исходные данные для разработки рабочей документации.
     
     Технический проект после согласования и утверждения в установленном порядке служит основанием для разработки рабочей конструкторской документации.
     
     Перечень работ — по ГОСТ 2.120-73.
     
     5, 6. (Измененная редакция, Изм. N 2).
     
     7. Ранее разработанные конструкторские документы применяют при разработке новых или модернизации изготовляемых изделий в следующих случаях:
     
     а) в проектной документации (техническом предложении, эскизном и техничесом проектах) и рабочей документации опытного образца (опытной партии) — независимо от литерности применяемых документов;
     
     б) в конструкторской документации с литерами «» («»),  «А» и «Б», если литерность применяемого документа та же или высшая.
     
     Литерность полного комплекта конструкторской документации определяется низшей из литер, указанных в документах, входящих в комплект, кроме документов покупных изделий.
     
     (Измененная редакция, Изм. N 1).
     
     8. Конструкторские документы, держателями подлинников которых являются другие предприятия, могут применяться только при наличии учтенных копий или дубликатов.     

Дизайн документов — Техническое написание

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

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

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

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

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

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

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

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

Средний абзац. Основное внимание уделяется цели отчета и дает краткий обзор содержания отчета.

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

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

Обязательно создайте титульную страницу для своего отчета. Об этом шаге забывают некоторые составители отчетов. Без ярлыка отчет анонимный; это игнорируется.

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

Сопроводительное письмо и обложка отчета (с обложкой).

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

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

Описательная аннотация. Традиционно он размещается на титульном листе (а не на титульном).

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

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

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

При создании ТОС у вас есть ряд дизайнерских решений:

• Уровни заголовков для включения. В более длинные отчеты не включайте только два верхних уровня заголовков. Благодаря этому оглавление не станет длинным и громоздким. TOC должен обеспечивать быстрый способ поиска информации в отчете.
• Отступы, интервалы и заглавные буквы. Обратите внимание на иллюстрации ниже, что элементы на каждом из трех уровней заголовков выровнены друг с другом. Хотя вы не можете увидеть это на иллюстрации, номера страниц выровнены по правому краю друг относительно друга. Обратите внимание на использование заглавных букв: все главные главы или разделы пишутся заглавными буквами; заголовки первого уровня используют заглавные буквы в каждом главном слове; Разделы нижнего уровня используют заглавные буквы только в первом слове.
• Расстояние по вертикали. Обратите внимание, что в разделах первого уровня есть дополнительное пространство сверху и снизу, что повышает удобочитаемость.

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

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

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

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

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

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

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

См. Этот пример введения:

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

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

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

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

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

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

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

Если вы вручную отформатируете каждый отдельный заголовок, используя рекомендации, представленные в предыдущем списке, вы обнаружите, что выполняете довольно много повторяющейся работы. Стили, предоставляемые Microsoft Word, OpenOffice Writer и другим программным обеспечением, сохранят вам эту работу. Вы просто выбираете заголовок 1, заголовок 2, заголовок 3 и так далее. Вы заметите, что формат и стиль отличаются от представленных здесь. Однако вы можете создавать собственные стили для заголовков.

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

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

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

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

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

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

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

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

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

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

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

Сведения об авторстве главы

Эта глава была получена из следующих источников.

Дизайн документов | Центр передового опыта в универсальном дизайне

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

Основные рекомендации по оформлению документов включают:

Используйте не менее 12 пунктов

Используйте шрифт размером не менее 12 пунктов для удобства чтения в целом. Скорость чтения увеличивается с увеличением размера текста.

Совет

Разные шрифты выглядят крупнее других — размер «x» обычно является лучшим ориентиром. Если размер «x» в выбранном вами шрифте (например, Times New Roman) небольшой, лучше использовать шрифт из 14 пунктов.

Например,

• Это текст из 12 пунктов в Tahoma
• Это текст из 12 пунктов в Verdana
• Это текст из 12 пунктов в Franklin Gothic Book
• Это текст из 14 пунктов в Times New Roman

Используйте четкий, легко читаемый шрифт

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

Сравнение простых и более сложных для чтения шрифтов проиллюстрировано ниже:

Советы

По возможности сделайте свои услуги доступными для более широкой аудитории, предлагая письменное общение в альтернативных форматах, например, крупным шрифтом (14- точечный шрифт или более), шрифт Брайля или «легко читаемый».

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

Выделите важные моменты

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

Общие рекомендации по выделению важной информации:

• Избегайте использования ПЕЧАТНЫХ ЗАГЛАВНЫХ букв.
• Избегайте использования курсивом .
• Избегайте подчеркивания.

Люди узнают форму знакомых слов, а не читают каждую букву по отдельности. Ввод слова ЗАГЛАВНЫМИ БУКВАМИ, курсивом или подчеркиванием искажает форму слова, что затрудняет его чтение, особенно для людей с проблемами зрения.

Используйте полужирный или крупный шрифт для выделения текста

Чтобы показать важность слова или частей текста, используйте жирный шрифт или более крупный текст.

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

Текст должен быть установлен горизонтально

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

Избегайте разделения слова между двумя строками

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

Шаблоны с доступным форматированием

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

Используйте доступное форматирование

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

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

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

1. Щелкните в том месте, где вы хотите вставить оглавление — обычно в начале документа.
2. Щелкните «Ссылки»> «Оглавление», а затем выберите автоматическую таблицу из галереи стилей.

Используйте согласованный и логичный макет

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

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

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

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

Ограничьте каждый абзац одной идеей

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

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

• Оставляйте пробелы между абзацами.
• Избегайте отступов в начале абзацев.
• Избегайте продолжения абзаца над страницей.

Используйте изображения и графики, относящиеся к тексту

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

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

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

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

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

Убедитесь, что между абзацами достаточно места. Это измерение контролируется параметром «Интервал — после» в функции «Абзац» в Microsoft Word. Расстояние между абзацами в 12 пунктов, как правило, является хорошим выбором.

Убедитесь, что строки текста в абзаце также имеют достаточный интервал. Это измерение контролируется параметром «Межстрочный интервал» в функции «Абзац» в Microsoft Word. Одинарный межстрочный интервал между одной строкой и следующей должен быть минимальным в основном тексте.

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

Создайте свободное пространство, разделяющее столбцы

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

Изображения не должны нарушать поток текста

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

Не передавайте информацию только через изображения

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

Обеспечьте хороший контраст между текстом и цветом фона

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

Основное руководство по цветовому контрасту:

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

Узнать больше

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

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

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

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

* Примечание. * Здесь я описываю небольших клиентов, которые хотят получить от своего разработчика единоличную армию. Это не единственный путь, по которому может пойти фрилансер, и это не единственные клиенты, с которыми мы работаем в Toptal, но это тот путь, который мне нравится больше всего. Конечно, если вы работаете в команде, а не в одиночку, некоторые из перечисленных ниже не применимы. Например, если вы используете методологии Agile или Scrum, вы, вероятно, захотите немного по-другому структурировать свои этапы.

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

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

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

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

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

Итак, когда вы беретесь за новый проект , прежде чем даже откроете Xcode или Visual Studio, вам необходимо иметь четкие и согласованные цели дизайна . И эти цели должны быть установлены в документе спецификации. Если клиент еще не написал его, вам следует написать его и отправить ему на рассмотрение, прежде чем вы даже откроете свою IDE. И , если вы встречаетесь с клиентом, который откровенно говорит: «У нас нет времени на проектную документацию», вам следует отказаться от проекта , потому что впереди вас ждут проблемы. Спецификация не должна быть особенно длинной; это может быть всего несколько страниц, но, по крайней мере, он должен содержать макет пользовательского интерфейса, включать каркасы (если есть компонент пользовательского интерфейса) и устанавливать этапы завершения.

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

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

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

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

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

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

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

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

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

1. Всегда ли элементы управления видны и / или включены? При каких условиях меняются их состояния?
2. Похоже на растровое изображение — это кнопка?
3. Какие переходы происходят между этими состояниями и представлениями? А как их анимировать?

Если вам нужно сгенерировать пользовательский интерфейс для согласования с клиентом, сделайте то же самое в обратном порядке: используйте инструмент каркаса и создайте полный набор макетов экрана, включая любые варианты, которые представления отображаются в разных состояниях приложения. Это может быть исчерпывающая и утомительная работа, но вы не пожалеете об этом — она ​​может избавить вас от переписывания огромных объемов кода и воссоздания интерфейсов из-за небольшого недоразумения с серьезными последствиями. Если вы создаете двойное приложение (например, для iPhone и iPad), создайте отдельные каркасы для обоих.

Размеры экрана тоже важны. Есть (на момент написания) три размера экранов iPhone. Отдельные каркасы для экранов 3,5 и 4 дюйма, вероятно, излишни, но вам, возможно, придется их сделать; в большинстве случаев можно просто изменить пропорции.

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

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

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

• Что делает приложение и как быстро оно это делает?
• Каковы возможные состояния отказа и как они обрабатываются?
• Какие разовые операции выполняются при первом выполнении (т.е., после установки)?
• Если пользователь создает какие-либо записи (например, закладки), каковы ограничения?

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

Вехи

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

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

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

Заявление о целях

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

Функциональное описание

Что делает приложение ? С какими состояниями приложения (высокоуровневыми описаниями основных пользовательских сценариев) столкнется пользователь?

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

• Первый запуск
• Создание нового _____ (игра, поиск и т. Д.)
• Операции
• Поведение фона и переднего плана

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

Включите каркасы для каждой страницы с подробным описанием:

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

Вот макеты, относящиеся к моему последнему приложению для iOS, NotifEye:

Если вам интересно, я сделал эти макеты с помощью инструмента каркасного моделирования Balsamiq.

Например, описание вашего пользовательского интерфейса может выглядеть так:

• Панель навигации
  • Левый элемент управления навигацией: возврат на главную страницу
  • Строка заголовка: текущий экран или название операции
  • Новая кнопка: создать новую вещь
• Просмотр таблицы
  • Раздел 0: Название раздела
  • Секция 0 строк:
    • Контроль ряда 0 (e.г., изображение)
    • Текстовая строка 0
    • Текстовая строка 2

Вехи

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

Например, раздел этапов в шаблоне проектного документа может выглядеть так:

1. Фасадное приложение с изображением экрана и с временными переходами и примерами изображений / текста
2. Протокол связи: приложение подключается к сети / серверу
3. Функциональная веха 1:…
4. Альфа-приложение (с полной функциональностью)
5. Устойчивость
6. Выпуск

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

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

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

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

1. Над чем только что работал разработчик?
2. Над чем сейчас работает разработчик?
3. Над чем разработчик будет работать дальше?

Документирование процесса проектирования | Проектирование машин

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

Блокноты для дизайна

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

Страница из дизайнерской записной книжки Томаса Эдисона.

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

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

Обзоры дизайна

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Титульный лист

Дата

Руководитель группы

Члены команды

Краткое содержание

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

Оглавление: Включить заголовки разделов и номера страниц

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

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

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

1. Предположения сделаны, убедившись, что проектные решения обоснованы.
2. Функция системы.
3. Соответствие технической документации.
4. Prototypes разработали свои испытания и результаты в соответствии с технической спецификацией.
5. Анализ затрат.
6. Используемые производственные процессы.
7. результатов DFX.
8. С учетом человеческого фактора.
9. Все диаграммы, таблицы и рисунки должны быть точно и четко помечены значимыми именами и / или заголовками.

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

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

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

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

Безопасность: Укажите соответствующие соображения безопасности в предлагаемой конструкции.

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

Благодарности: Перечислите лиц и / или компании, которые предоставили поддержку в виде оборудования, советов, денег, образцов и т. п.

Ссылки: Включите книги, технические журналы и патенты.

Приложения: Необходимы для следующей информации:

1. Подробные вычисления и компьютерные данные.
2. Спецификации производителей.
3. Оригинальные лабораторные данные.

Эта статья основана на отрывке из книги Дэвида Ульмана «Процесс механического проектирования» (6-е изд.), 2018 г. (www.mechdesignprocess.com).

Файл истории проектирования (DHF) по сравнению с основной записью устройства (DMR) и записью истории устройства (DHR): в чем разница?

В индустрии медицинского оборудования много сокращений.

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

Что еще хуже, эти три аспекта элементов управления дизайном довольно тесно связаны и имеют много общего. Мы создали эту статью, чтобы прояснить различия между DHF, DMR и DHR.Давайте начнем.

DHF означает файл истории проектирования.

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

FDA 21 CFR Part 820.30 имеет некоторые требования относительно DHF:

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

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

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

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

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

Что входит в DHF?

Вот конкретные документы, которые вы должны включить в свой DHF:

• Потребности пользователей и исходные данные, которые вы определили в начале проекта

• Проектные результаты, которые вы создали для создания устройства

• Протоколы и отчеты о проверке и валидации проекта

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

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

Управление DHF с помощью бумажных систем качества

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

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

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

^{Программа управления многоуровневым проектированием Greenlight Guru MDQMS}

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

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

DMR — это основная запись устройства.

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

Согласно FDA, DMR для каждого типа устройства должен включать или относиться к расположению следующих частей информации:

(a) Технические характеристики устройства, включая соответствующие чертежи, состав, рецептуру, спецификации компонентов и спецификации программного обеспечения

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

(c) Обеспечение качества процедуры и спецификации, включая критерии приемки и используемое оборудование для обеспечения качества

(d) Спецификации упаковки и маркировки, включая используемые методы и процессы

(e) Процедуры и методы установки, технического обслуживания и ремонта

Производители должны гарантировать, что они готовят каждый DMR в соответствии с 21 CFR Part 820.40.

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

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

Хорошая новость заключается в том, что FDA требует, чтобы вы ссылались только на обязательные элементы, а не дублировали их. Если вы организовали создание своего DHF, вы легко сможете указать это место в своем DMR.

Как видите, DHF и DMR во многом похожи, так в чем же разница?

Разница между DHF и DMR

Разница между DHF и DMR в первой букве — дизайн против устройства.

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

Теперь, когда вы спроектировали устройство (DHF) и получили рецепт для его создания и тестирования (DMR), пришло время создать устройство. Вот тогда в игру вступает DHR.

DHR — ИСТОРИЧЕСКАЯ ЗАПИСЬ УСТРОЙСТВА

DHR — это запись истории устройства. Здесь содержится все, что вы сделали для изготовления устройства.

Согласно FDA, DHR должен включать или указывать местонахождение следующих частей информации:

(а) Даты изготовления

(б) Произведенное количество

(c) Количество выпущено для распределения

(d) Протоколы приемки, подтверждающие, что устройство изготовлено в соответствии с DMR

(e) Этикетка первичной идентификации и маркировка, используемые для каждой производственной единицы

(f) Любой уникальный идентификатор устройства (UDI) или универсальный код продукта (UPC), а также любые другие используемые идентификаторы устройства и контрольные номера

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

Подумайте об этом так: запись истории устройства — это буквально история устройства. История и информация о том, как вы сделали устройство в соответствии с DMR, хранятся в DHR.

Подобно тому, как DHF — это история дизайна, DHR — это история устройства.

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

Думать об этом последовательно — полезный трюк.Вы начинаете с истории дизайна. Это приводит к записи о том, как построить и тестировать устройство, что затем ведет к истории устройства, которое вы сделали.

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

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

Greenlight Guru — единственное программное обеспечение для управления качеством, разработанное специально для индустрии медицинского оборудования. Наша специализированная платформа поставляется в готовом виде с автоматическими контрольными журналами, полной прослеживаемостью между документами и служит единым источником достоверной информации о содержимом ваших DMR, DHF и DHR.

Ищете решение для контроля конструкции, которое поможет вам быстрее выводить на рынок более безопасные медицинские устройства с меньшим риском? Щелкните здесь, чтобы ознакомиться с программным обеспечением Greenlight Guru’s Medical Device QMS →

Документы | Бизнес-приложения ESA

Техническое письмо | Научные документы

РУКОВОДСТВО ПО ТЕХНИЧЕСКОМУ НАПИСАНИЮ

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

ИСПОЛЬЗУЙТЕ ЖАРГОН ДОЛЖНЫМ ОБРАЗОМ

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

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

ИСПОЛЬЗУЙТЕ ГЕНДЕРНО-НЕЙТРАЛЬНЫЙ ЯЗЫК

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

— Пожарный вместо пожарного

— Продавец или торговый представитель вместо продавщицы, продавщицы или продавца

— Стюардесса вместо стюардессы или стюарда

— Сотрудник полиции вместо полицейского или полицейского

— Пресс-секретарь вместо пресс-секретаря

— Синтетические или искусственные вместо искусственных

— Рабочий вместо рабочего

ИСПОЛЬЗУЙТЕ ПРОСТЫЕ ПРЕДЛОЖЕНИЯ

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

ИЗБЕГАЙТЕ ПАССИВНЫХ И ИЗБЫТОЧНЫХ СЛОВ

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

— Использовать вместо использования

— Начать вместо запуска

— Человек вместо физического

— Сейчас, а не в этот момент

— Потому что вместо того, что

— Рассмотрим вместо того, чтобы принимать во внимание

— Вместо расследования проведено расследование

— Подать заявку вместо подачи заявки

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

ИСПОЛЬЗУЙТЕ АКТИВНЫЙ ГОЛОС

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

Активный или пассивный голос?

Голос в письменной форме указывает на то, действует ли субъект предложения или принимает действие.
Активным голосом субъект выполняет действие; например: «Менеджер порекомендовал провести расследование».
В пассивном голосе субъект воспринимает действие; например: «Менеджер порекомендовал провести расследование».

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

ИСПОЛЬЗУЕМЫЕ ИМПЕРАТИВЫ

Императивы — это инструкции или директивы. Они говорят читателю, что и как что-то делать. Например, «Прочтите следующие инструкции».

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

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

ВЫБОР ПЕРВОГО, ВТОРОГО ИЛИ ТРЕТЬЕГО ЛИЦА

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

Первое лицо — я, я, мы

Второе лицо — Вы

Третье лицо — Он, она, они, они

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

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

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

ИСПОЛЬЗУЙТЕ ПРАВИЛЬНОЕ НАПИСАНИЕ, ГРАММАТИЮ И ПУНКТУАЦИЮ

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

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

— Делайте предложения короткими и ясными.

— Изменяйте длину предложений.

— Используйте правильный синтаксис (то есть правильное расположение слов в предложении).

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

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

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

Технические редакторы также должны быть знакомы с менее часто используемыми знаками препинания, такими как en rules, em rules, ellipses и solidus.

Подробнее: Щелкните здесь, чтобы просмотреть наш курс технического письма

Вас также могут заинтересовать ….