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

Чем отличается проектная документация от рабочей -7 признаков

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

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

Уходим от профессионального сленга – просто и понятно

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

Только иногда буду сокращать, и применять аббревиатуру, принятую в сфере профессионалов.

  • ПД – это проектная документация
  • РД – это рабочая документация

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

Зачем нужна проектная документация

Это оговорено законом. Без этого шага не получить разрешение (экспертизу). 

Поэтому:

Перед строительством, либо перед капитальным ремонтом необходимо сделать проектную документацию, согласно ГК Р.К. № 409-I от 1.07.1999г. Это один из основных правовых документов в нашей деятельности.

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

И при завершении работ, при сдаче объекта в эксплуатацию, согласно  ГОСТу, оценивают на соответствие проектной документации.

  • Для составления сметы. Смета может быть локальная, и этих расчетов может быть несколько. Например, для инженерных работ – одна локальная смета, для благоустройства территории – другая. Расчет стоимости материалов и услуг производиться отдельно.
  • Для согласования с другими ведомствами. Предположим, объект находится в некотором удалении от основной дороги. Чтобы провести участок асфальтированного асфальта, необходимо согласовать с дорожными службами.
  • И наконец, для создания рабочего проекта.

Отвечать на вопрос: «Что входит в проектную документацию?» в рамках текущей темы не будем. Состав ПД мы будем обсуждать в другой статье детально.

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

Для чего нужен рабочий проект

Сразу оговорюсь, под словом «проект» подразумевается документация к строительству.

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

Например, нужно построить завод.

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

*** Перечислена малая часть РД, и конечно, в рамках этой статьи — упрощенно. Более подробно о составе рабочей документации можно почитать вот здесь.

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

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

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

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

Чем отличается проектная документация от рабочей – краткая таблица

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

Отличия проектной и рабочей документации Таблица 1

 Проектная документация (ПД)Рабочая документация (РД)
1ПервичнаВторична
2На этапе планированияВо время строительства
3Крупными вехамиДетализация (дает понимание «как и что»)
4Проходит экспертизуНе требуется
5Содержит текстовую частьНет текстовой части (кроме примечания)
6Выделение сметыРесурсы уже определены
7Можно внести коррективы (до экспертизы)Нельзя вносить корректировки

Теперь разберем каждое отличие отдельно.

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

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

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

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

6.   При завершении ПД заказчик видит окончательную сумму сметы на весь объект. И понимает детализацию бюджета. 

7. Этот пункт широко освещен далее по тексту.

Каверзные вопросы от заказчиков: «Может, не надо?»

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

Потому что:

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

Наша компания отвечает за качество и не идет на риски. А у тех, кто настаивает, можно спросить:

— Помните сказку про 3 поросят?

  • Ниф-ниф строил соломенную избушку
  • Нуф-нуф быстренько сложил  домик из веток
  • Третий, Наф-Наф, построил не быстро, но основательно, каменный дом.

И, в конце концов, непогода снесла первые два домика. А в третьем, каменном, самом прочном, братья спаслись и от волка.

Мораль такова: Не пожалел Наф-Наф средств на возведение прочного, безопасного жилья))

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

И это хорошо. Чем больше вопросов, тем яснее путь к цели))

Например, по теме обсуждения:

  • Можно ли сэкономить на проектной документации? Можно, но …это будет не настолько круто для Вас…
  • Чем отличается проектная от рабочей документации?Ценой и качеством.
  • А что если не делать  проектную, а только рабочую? Можно, но Ваш объект не пропустят госучреждения.
  • Можно ли обойтись только одной рабочей? Да, конечно, можно одной, но она будет не подписана в соответствующих структурах.
  • Может можно обойтись только проектной?  Конечно, но… только ее не поймут рабочие.

Полагаю, на самые каверзные вопросы ответ прояснился))

 Ответы на самые распространённые  вопросы

— Для чего нужна проектная документация?

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

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

Да, есть. При строительстве ИЖС (Индивидуального жилищного строительства) и для дачно-садовых домов.  Или при строительстве временных сооружений, не имеющих основательного фундамента (например, ларьки, киоски).

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

 — Генеральный проектировщик. Компания, которая имеет лицензию и узких специалистов по профилю. С опытом работы более 3 лет.

В нашей проектно-конструкторской компании «АзияПроектГрупп» (Гиперссылка)  работают только  опытные инженеры проектировщики, которые имеют  от 10 до 40 лет стажа. Все программы в нашей компании  для проектно-сметных документаций имеют лицензии. Опыт работы с крупными клиентами.

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

  • СН РК 1.01-01-2011 Государственные нормативы в области архитектуры, градостроительства и строительства. Основные положения.
  • Статьи 63-1 и 64-4 Закона РК «Об архитектурной, градостроительной и строительной деятельности в Республике Казахстан»
  • Гражданский кодекс Республики Казахстан № 409-I от 1 июля 1999 года (Особенная часть)
  • ГОСТ 21.001-2013 – действующий на сегодняшний момент. Но в стадии одобрения находится ГОСТ Р 21.001-2021
  • СНиП 31-01-2003  (СП54.13130.2О11)

Резюме

Хотелось бы верить, что Вы получили ответ на свой вопрос: «Чем отличается проектная документация от рабочей». Но вдруг остались какие-то вопросы, то всегда готов ответить Вам в комментариях.

Если Вы думаете,  где лучше всего заказать проект (проектно – сметную документацию), милости просим)) Наши контакты (Гиперссылка) Кстати, мы работаем и дистанционно.

Надежных партнеров,

с уважением, Сергей Кропачев!

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

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

Возможные изменения в Град Кодексе: «Статья 48 3 Рабочая документация

  1. Подготовка рабочей документации осуществляется застройщиком, техническим заказчиком, лицом, ответственным за эксплуатацию здания, сооружения, региональным оператором в целях обеспечения реализации в процессе строительства, реконструкции объекта капитального строительства архитектурных, технических, технологических и иных решений, содержащихся в проектной документации на объект капитального строительства.
  2. Рабочая документация представляет собой документацию, содержащую материалы в текстовой и графической формах и (или) в форме информационной модели (в том числе рабочие чертежи, спецификации оборудования и изделий, иные документы и (или) материалы) и предусматривающую, в том числе, методы, способы, приемы, технологии реализации в процессе строительства, реконструкции объекта капитального строительства решений, предусмотренных проектной документацией. Графическая часть рабочей документации содержит комплекты рабочих чертежей, используемых при строительстве, реконструкции объекта капитального строительства. Текстовая часть рабочей документации содержит прилагаемые к основным комплектам рабочих чертежей документы (в том числе техническая документация на строительные изделия, сведения о нетиповых изделиях, спецификации оборудования, изделий и материалов, опросные листы и габаритные чертежи, выполняемые в соответствии с данными изготовителей (поставщиков) оборудования, локальная смета, другие документы).
  3. Подготовка рабочей документации осуществляется на основании проектной документации, утвержденной застройщиком, техническим заказчиком, лицом, ответственным за эксплуатацию здания, сооружения, или региональным оператором в порядке, предусмотренном частью 15 статьи 48 настоящего Кодекса, за исключением случаев, предусмотренных частью 4 настоящей статьи.
  4. По решению застройщика, технического заказчика, лица, ответственного за эксплуатацию здания, сооружения, или регионального оператора подготовка рабочей документации может осуществляться без подготовки проектной документации. В указанном случае рабочая документация признается проектной документацией и утверждается в порядке, предусмотренном частью 15 статьи 48 настоящего Кодекса.
  5. В случае, если подготовка рабочей документации осуществляется индивидуальным предпринимателем или юридическим лицом на основании договора подряда на подготовку рабочей документации либо по договору подряда на подготовку проектной документации и рабочей документации, заключенного с застройщиком, техническим заказчиком, лицом, ответственным за эксплуатацию здания, сооружения, региональным оператором, застройщик, технический заказчик, лицо, ответственное за эксплуатацию здания, сооружения, региональный оператор обязаны предоставить таким индивидуальному предпринимателю или юридическому лицу документы и материалы, указанные в части 6 статьи 48 настоящего Кодекса.
  6. Подготовка рабочей документации осуществляется на основании документов и материалов, указанных в части 11 статьи 48 настоящего Кодекса.
  7. Рабочая документация, изменения в рабочую документацию утверждаются застройщиком, техническим заказчиком, лицом, ответственным за эксплуатацию здания, сооружения, или региональным оператором. Рабочая документация, в том числе рабочая документация, в которую внесены изменения, применяется для строительства, реконструкции объекта капитального строительства с момента ее утверждения в соответствии с настоящей частью, за исключением случая, предусмотренного частью 8 настоящей статьи.
  8. В случае внесения в рабочую документацию, подготовленную в соответствии с частью 3 настоящей статьи, изменений, которые затрагивают архитектурные, технические, технологические решения, содержащиеся в утвержденной проектной документации, в указанную проектную документацию вносятся необходимые изменения. Данные изменения утверждаются в порядке, установленном частью 15 статьи 48 настоящего Кодекса. Осуществление строительства, реконструкции объекта в соответствии с рабочей документацией, в которую внесены изменения в соответствии с настоящей частью, допускается только после утверждения застройщиком, техническим заказчиком, лицом, ответственным за эксплуатацию здания, сооружения, или региональным оператором соответствующих изменений в проектную документацию.
  9. В случае, внесения в рабочую документацию подготовленную в соответствии с частью 4 настоящей статьи, изменений, не предусмотренных частью 3.8 статьи 49 настоящего Кодекса данные изменения утверждаются в порядке, установленном частью 15 статьи 48 настоящего Кодекса.
  10. По решению застройщика, технического заказчика лица, ответственного за эксплуатацию здания, сооружения, или регионального оператора внесение в рабочую документацию, подготовленную в соответствии с частью 3 настоящей статьи, изменений может осуществляться без внесения изменений в проектную документацию. В этом случае изменения в рабочую документацию считаются изменениями в проектную документацию и утверждаются в порядке, установленном частью 15 статьи 48 настоящего Кодекса.
  11. Работы по договорам о подготовке рабочей документации, внесению изменений в рабочую документацию в соответствии с частями 3.8 и 3.9 статьи 49 настоящего Кодекса, заключенным с застройщиком, техническим заказчиком, лицом, ответственным за эксплуатацию здания, сооружения, региональным оператором, должны выполняться только лицами, указанными в частях 4, 4. 1 и 5 статьи 48 настоящего Кодекса.
  12. В случае, предусмотренном частью 4 настоящей статьи, экспертиза проводится в отношении рабочей документации в порядке, предусмотренном статьей 49 настоящего Кодекса для экспертизы проектной документации. 13. Состав и требования к содержанию рабочей документации устанавливаются Правительством Российской Федерации.

ПОДРОБНЕЕ

Документация в порядке / Хабр

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

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

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

Теория разбитых окон

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

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

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

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

Зачем писать

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

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

Если коротко — то “без бумажки ты букашка”. Наша память обманчива и недолговечна. Завтрашний ты обманешь себя сегодняшнего или наоборот. Придет новый человек или уйдет старый — каждый такой финт будет стоить вам дорого. Без общей картины вы будете заниматься микроменеджментом и разработкой того, что уже кем-то сделано, но он забыл вам об этом сказать. Будете делать петли и вставлять друг другу палки в колеса. А через полгода мучительно вспоминать, зачем нужен этот огромный кусок кода, который все тормозит. И это даже не касаясь кейса, когда вы заказали разработку на стороне.

Что писать

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

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

Легче кому-то одному потратить пару часов на документирование, чем всей команде постоянно проверять свою память.

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

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

Необходимый минимум

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

  1. Документ-маршрутизатор

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

  2. Артефакты проектных процессов

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

  3. Глоссарий

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

  4. Артефакты бизнес-потребности и бизнес-процесса

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

  5. Концептуальная модель системы

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

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

    Пример верхнеуровнего описания процесса
  6. Классы пользователей и уровни доступа

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

  7. Cценарии использования

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

  8. Логика работы системы

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

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

  9. Описание АПИ

    Да пребудет с нами swagger и стандартный формат ответа методов. Если с вами интегрируются внешние компании — не обойтись и без подробного описания параметров.

  10. Тестовые данные

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

  11. Ограничения/нефункциональные требования

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

Другие типы документов

Потребность в некоторых документах возникает вариативно, в зависимости от особенностей проекта:

  1. Архитектура системы

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

  2. Требования к данным

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

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

  3. UX/UI макеты и прототипы

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

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

  4. Описание интеграций

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

  5. Безопасность

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

  6. Внешняя документация

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

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

Как писать

Несколько инсайтов о работе с документацией:

  • Не забывайте про актуальность

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

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

  • Неоформленные артефакты — тоже документация

    Удобно складывать в одно место те артефакты, которые нет возможности обработать и хорошо оформить.

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

  • Растите культуру документирования в команде

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

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

  • Комментарии в коде не всегда спасают

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

  • Планируйте и декомпозируйте работу с документацией

    Документирование — это задача, которую легко разбить на небольшие отрезки времени и “размазать” по спринту.

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

  • Закрывайте техдолг

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

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

  • Больше схем и диаграмм

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

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

  • Учитесь писать нехудожественные тексты

    Навык написания текстов сильно ускоряет процесс документирования и повышает его качество. Рекомендую использовать https://glvrd.ru. Плюс по возможности почитать «Пиши, сокращай» и «Бизнес-копирайтинг». Так и работа быстрее пойдет, и тексты станут понятнее и приятнее.

    Вот еще хороший доклад на тему «Как писать полезные технические тексты».

Как итог

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

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

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

Что это такое и как его создать! (Шаблон включен)

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

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

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

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

 

Что такое проектный документ программного обеспечения? (Определение)

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

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

Подробнее: Что такое документ с требованиями к программному обеспечению

 

Почему важна документация по разработке программного обеспечения?

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

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

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

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

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

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

 

Что следует включить в проектную документацию по программному обеспечению?

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

Заголовок:  Добавьте заголовок документа по проектированию программного обеспечения.

Введение:  Обзор всего документа.

Обзор системы:  Общее описание и функциональные возможности программной системы.

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

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

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

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

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

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

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

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

Подробнее: Лучшие онлайн-инструменты для документирования программного обеспечения

 

Основные преимущества создания проектной документации с помощью Bit.ai

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

Bit.ai — это новейший инструмент для документирования программного обеспечения и управления знаниями, который помогает командам сотрудничать, обмениваться, отслеживать и управлять всеми знаниями компании в одном месте. Битовые документы, в отличие от ваших стандартных документов Word и Google Docs, являются интерактивными .  Это означает, что разработчики могут легко добавлять блоки кода в документ одним щелчком мыши!

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

Совместная работа с разработчиками, командой разработчиков и клиентами

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

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

Быстрая документация без отвлекающих факторов

Лучшее в Bit — это поддержка Markdown, которая позволяет разработчикам быстро создавать и форматировать текст, не отвлекаясь.

Завершив создание документов, вы можете легко экспортировать их в форматы PDF, файлы Word, Markdown и многое другое. Markdown поддерживается GitHub и другими инструментами разработки программного обеспечения, что позволяет легко делиться работой, которую вы выполняете внутри Bit, с другими платформами.

Обеспечьте надежную и надежную защиту документов программного обеспечения

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

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

Гостевой доступ, клиентские порталы и комнаты данных

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

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

Гостевой доступ — это более разумный способ обмена сложными и личными документами с людьми за пределами вашей организации!

Работайте с вашими любимыми приложениями!

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

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

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

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

Вот некоторые из основных преимуществ использования Bit:

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

 

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

Как создать шаблон документации по дизайну программного обеспечения с помощью Bit

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

Шаг 1. Создайте учетную запись Bit

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

 

Шаг 2. Создание рабочей области

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

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

 

Шаг 3. Добавьте членов команды

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

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

 

Шаг 4. Создайте нужный документ

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

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

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

 

Еще несколько шаблонов документов, которые могут вас заинтересовать:

 

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

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

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

Если у вас есть какие-либо вопросы по приведенному выше шаблону дизайна программного обеспечения или вы хотите узнать, как Bit может помочь вашему бизнесу добиться успеха, немедленно напишите нам в Твиттере @bit_docs!

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

Как написать лучший технический проект

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

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

Какова цель технического проекта?

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

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

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

Загрузите бесплатную электронную книгу вопросов команды инженера-менеджера

Вот шаблон вашего следующего проектного документа

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

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

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

Обзор

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

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

Предыстория

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

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

Цели, нецели и будущие цели

Для того, чтобы согласовать и передать определение выполненного, важно четко сформулировать цели этой работы. Лучшие цели — это простые, правдивые предложения, описывающие будущее состояние мира. В отличие от OKR, эти цели должны быть гиперконкретными. Проекты часто имеют 3-5 целей.

Примеры:

  • Горячие резервные копии доступны в 3 регионах
  • Данные деактивированных учетных записей автоматически очищаются через 30 дней
  • Веб-интерфейс использует React вместо Vue
  • Мобильные клиенты получают автоматические обновления

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

Будущие цели

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

Рабочий проект

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

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

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

(Возможно, вам не нужно отвечать на все из них.)

Сторонние соображения

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

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

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

Например, если третья сторона используется для выполнения операций с данными клиентов, она, вероятно, будет считаться подпроцессором в соответствии с Общим регламентом ЕС по защите данных (GDPR). Итак, вам нужно дополнение по обработке данных? Вам нужно собирать и просматривать отчеты SOC2? Иногда клиентам требуется уведомление о новых подпроцессорах, что повлияет на приведенный ниже план развертывания.

Смета работ

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

План развертывания

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

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

Альтернативные подходы

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

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

Связанная работа

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

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

Будущая работа

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

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

Подведение итогов

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

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

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

Узнайте больше с помощью Lead Time

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

Краеугольным камнем сообщества Lead Time являются чаты Lead Time Chats — незаписанные беседы с руководителями инженеров и другими влиятельными людьми в области технологий, которые ведет Джин Хсу (тренер по лидерству в области инженерии и вице-президент по инженерным разработкам на полигоне). Вы можете просмотреть прошлые эпизоды в любое время в блоге Range, чтобы узнать о лучших методах поддержания продуктивности и связи вашей команды.

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

Подписаться

Отличный контент доставлен на ваш почтовый ящик.

Технический дизайн | Университет ИТ

Обзор

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

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

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

Процесс

  • Руководитель проекта должен убедиться, что все планы проектов программного обеспечения UIT включают задачи по созданию, просмотру, обновлению и утверждению TDD в качестве зависимости для начала разработки. Как и в случае разработки/интеграции, к задачам разработки TDD применяется «правило 80 часов», т. е. все, что длится более двух рабочих недель, должно быть разбито на компоненты, чтобы обеспечить выполнение в срок.
  • Соответствующий руководитель разработки UIT отвечает за создание TDD.
  • Директор практики UIT должен одобрить TDD, прежде чем можно будет начать разработку.
  • В некоторых практических областях могут быть дополнительные типы технических документов, например, картографирование полей, модели данных для проектов BI и т. д. Руководитель разработки UIT отвечает за определение всех необходимых документов и работу с менеджером проекта над определением соответствующих задач с достаточным количеством времени. план проекта по созданию, рассмотрению, обновлению и утверждению всех необходимых технических документов.
  • Крайне важно, чтобы руководители разработки обновляли техническую документацию по проекту всякий раз, когда запросы на изменение или усовершенствования утверждаются в ходе проекта, чтобы гарантировать, что группы поддержки UIT имеют самую точную информацию о проекте, доступную при вводе в эксплуатацию. Хотя это и не входит в обязанности руководителя проекта, рекомендуется напоминать об этом проектным группам и устанавливать регулярность таких обновлений для каждого проекта.

Просмотр открытого содержимого через панель проектов в Altium Designer | Altium Designer 22 Руководство пользователя

Страница выше: Работа с панелями


Панель проектов

Резюме

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

Доступ к панели

Доступ к панели Projects осуществляется следующими способами:

  • Выберите View » Panels » Projects из главного меню.
  • Нажмите кнопку Panels в правом нижнем углу пространства дизайна, затем нажмите Projects .

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

Группы проектов

В Altium Designer вы можете открывать и редактировать несколько проектов и, при желании, сохранять проекты коллективного набора как группу проектов (.DsnWrk ). Это может иметь особое преимущество, когда набор проектов связан или связан, например, дизайн продукта, состоящий из нескольких печатных плат. Создание группы проектов, в которую входят все соответствующие проекты, позволяет открывать, управлять и сохранять несколько проектов как единое целое. На панели Projects самая верхняя запись отображает текущую группу проектов — либо группу по умолчанию, либо ту, которую вы создали или открыли.

  • Чтобы сохранить текущий открытый набор проектов в виде группы, выберите File » Save Project Group As в главном меню.
  • Чтобы открыть существующую группу, выберите File » Open Project Group в главном меню или щелкните правой кнопкой мыши на панели и выберите Open Project Group в контекстном меню. Используйте тот же доступ для команды Сохранить группу проектов .
  • Чтобы создать новую группу проектов, выберите File » New » Design Project Group из главного меню — это загрузит стандартную (пустую) группу проектов ( Project Group 1.ДснВрк ). Тот же метод можно использовать для закрытия текущего файла группы проектов.
  • При открытии другой группы проектов текущая группа будет закрыта. Вам будет предложено сначала сохранить любые несохраненные документы, проекты или изменения в текущей группе.
  • Чтобы добавить еще один проект в группу проектов, откройте или создайте проект, а затем сохраните текущую группу проектов. Либо щелкните правой кнопкой мыши панель и выберите параметр «Добавить существующий проект ».
  • На панели Projects самая верхняя запись отображает текущую группу проектов — либо группу по умолчанию ( Project Group 1.DsnWrk ), либо тот, который вы создали или открыли.


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

Проекты на панели проектов

Altium Designer также поддерживает концепцию проектов, которые полностью хранятся в подключенной рабочей области. Проекты можно создавать или преобразовывать в проекты Workspace, размещенные в безопасном репозитории с контролируемой версией в Workspace. Такой подход значительно упрощает процесс управления хранилищем проекта, управлением версиями, жизненным циклом и внедрением совместной разработки.Проекты будут храниться на панели Projects в рабочей области, в которой они размещены, а не в группе проектов, как локальные проекты. При подключении к рабочей области значок рабочей области (/). Когда локальная рабочая копия проекта открыта, но рабочая область, в которой находится проект, не подключена, отображается серый значок рабочей области (/).


Пример проекта в рабочей области на панели Projects .

Общие значки проектов

Этот значок появляется рядом с .Файл документа PrjPcb при подключении к рабочей области, в которой находится общий проект.
Этот значок появляется рядом с файлом документа .PrjPcb , если он не подключен к рабочей области, в которой находится общий проект.

Чтобы получить доступ к контекстному меню, относящемуся к вашей рабочей области, щелкните правой кнопкой мыши имя вашей рабочей области или щелкните элемент управления

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

Для доступа к этим командам необходимо подключение к рабочей области.

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

► Чтобы узнать больше о проектах Workspace, посетите страницу Design Management with a Connected Workspace.

Дерево документов проекта

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

.
  • Исходные документы – основные проектные документы, такие как схемы, печатные платы и т. д.
  • Настройки — предоставляет различные файлы, используемые в проекте, включая файлы выходных заданий, файлы определений жгутов и документы аннотаций, а также другие соответствующие файлы.
  • Библиотеки – документы местной библиотеки. Документы дополнительно подразделяются в зависимости от типа библиотеки (например, библиотеки схем, библиотеки печатных плат и т. д.).
  • Документация — дополнительные документы, которые были добавлены в проект, типа, который известен Altium Designer (например,например, текст, PDF и т. д.).
  • Other Documents — дополнительные документы, добавленные в проект, тип которых неизвестен Altium Designer. Их можно открыть в Altium Designer, если приложение-владелец известно Windows (например, документы Word, электронные таблицы Excel и т. д.).
  • Сгенерировано – документы сгенерированы как выходные. Документы дополнительно подразделяются на основе типа (например, документы спецификации, текстовые документы и т. д.). По мере создания выходных данных проекта соответствующие подпапки в главном дереве будут создаваться и заполняться.
  • Компоненты — в этой папке перечислены все компоненты (сгруппированные по первой букве в обозначении) и количество компонентов, обозначение которых начинается с этой буквы в проекте. Подтвердите проект, если эта папка не отображается (меню Project ).
  • Сети – в этой папке перечислены все сети, используемые в проекте. Подтвердите проект, если эта папка не отображается (меню Project ).
Для управления видимостью папок Components и Nets используйте параметр Show Components and Nets folders в разделе General всплывающего окна Settings (появляется при нажатии значка вверху панели). Документы, хранящиеся в папке проекта или подпапке папки проекта, связаны в файле проекта с помощью относительных ссылок. Документы, хранящиеся в другом пути к папке, связываются в файле проекта с помощью абсолютной ссылки. Эти документы имеют небольшую стрелку в нижнем углу, указывающую на то, что они связаны с проектом, как показано в файле на изображении выше.

Автоматическая нумерация листов

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

Функция автоматической нумерации листов может быть включена/отключена с помощью параметра Автоматическая нумерация листов (параметр проекта) в диалоговом окне Нумерация листов для проекта и параметра Автоматическая нумерация листов на вкладке Параметры диалогового окна Параметры проекта .

Работа в дереве документов

  • Любые документы, не зависящие от проекта, будут отображаться как Free Documents и отображаться в соответствующих подпапках. Щелкнув правой кнопкой мыши на свободном документе и выбрав команду Добавить в проект из контекстного меню, вы можете добавить открытый в данный момент свободный документ в активный проект. Кроме того, вы можете перетащить его на нужное имя проекта на панели Projects .
  • Наряду с возможностью открывать несколько документов для редактирования, среда также поддерживает одновременное открытие нескольких проектов. Это могут быть связанные или несвязанные проекты.
  • Документы на панели Projects автоматически распределяются в логические группы или «папки», такие как Исходные документы (Схема, Плата и т. д.), Документы настроек (Жгут, Outjob и т. д.) и, в случае иерархический дизайн, схематические документы верхнего уровня. Документы в каждой группе папок отображаются по умолчанию в том порядке, в котором они были добавлены, но их можно перетаскивать на новое место в группе.
  • В случае нового иерархического дизайна в панели будут отображаться отношения родитель-потомок между документами. Обратите внимание, что отношения связности нельзя определить путем перетаскивания документов схемы, поскольку соединения между листами и иерархия проекта фактически определяются обозначениями листов и определениями портов.
  • Подпапки документа проекта, открытые или закрытые, совместно используют следующие команды контекстного меню:
    • Открыть все — используется для открытия всех документов в выбранной подпапке документов проекта.
    • Закрыть все — используется для закрытия всех документов в выбранной подпапке документов проекта.
    • Сохранить все — используется для сохранения всех документов в выбранной подпапке документов проекта.
    • Удалить все — используется для удаления всех документов в выбранной подпапке документов проекта. Используйте следующее диалоговое окно Удалить из проекта , чтобы выбрать способ удаления документов.
    • Обновить — используется для обновления панели с учетом любых внесенных вами изменений.

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

Библиотеки
  • SVN Database Library Maker — используется для доступа к мастеру преобразования библиотеки баз данных SVN из текущего документа библиотеки проекта — либо библиотеки схем ( *.SchLib ), библиотеки моделей компонентов 2D/3D печатных плат ( *.PcbLib ) или интегрированная библиотека ( *.IntLib ).
Компоненты, сети
  • Перекрестный переход к схеме — используется для перекрестного перехода от выбранного компонента или записи цепи на панели Projects к этому объекту в исходном документе (документах) схемы родительского проекта проектирования печатной платы.
  • Cross Probe to PCB — используется для перекрестного зондирования от выбранного компонента или записи цепи на панели Projects до этого объекта в документе платы родительского проекта проектирования платы.
  • Component Grouping — используется для быстрого доступа к элементам управления Components Grouping для панели Projects .
Активный против сфокусированного

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


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

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

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

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

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

В случае, если фокусирует документ, документ становится сфокусированным, только если он закрыт, в противном случае он станет активным документом, а его родительский проект станет активным проектом.Например, на изображении ниже активный проект MiniPC.PrjPcb и активный документ DDR4.SchDoc . Выделенный документ — Ethernet-HPS.SchDoc (обозначен на панели пунктирной рамкой).


Открытый активный документ (синий) и выбранный документ в фокусе, обозначенный пунктирным контуром.

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

Средства быстрого доступа

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

  • Недавние группы проектов — наведите указатель мыши, чтобы открыть список групп дизайн-проектов ( *.DsnWrk ), которые недавно были открыты.
  • Добавить новый проект – используется для создания нового проекта дизайна (печатной платы или Multiboard).
  • Добавить существующий проект — используется для открытия любого существующего проекта Altium Designer.
  • Открыть группу проектов — используется для открытия любых существующих групп проектов дизайна.
  • Сохранить проект как — используется для сохранения текущей группы дизайн-проектов.
  • Переименовать — используется для переименования текущей активной группы проектов дизайна на панели Проекты с новым именем.
  • Сохранить все — используется для локального сохранения всех измененных проектов и документов.
  • Explore — используется для открытия экземпляра проводника Windows в том месте, где хранится текущая группа проектных проектов.
  • Refresh — используется для обновления панели Projects .

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

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

В отношении прямого редактирования поддерживаются следующие типы контента:

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

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

Варианты дизайна на панели проектов

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

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

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


Физический вид редактора схем. Уровень затемнения для нередактируемых объектов задается на странице Schematic – Compiler диалогового окна Preferences .

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

Параметры правой кнопки мыши в подпапке Variant включают:

  • Варианты — используется для открытия диалогового окна «Управление вариантами».
  • [Без вариантов] — нажмите, чтобы отобразить документ без вариантов.
  • <Имя варианта> — нажмите, чтобы отобразить конкретно выбранный вариант.

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

► Чтобы узнать больше о вариантах дизайна, посетите страницу «Варианты дизайна».

Сделать существующий локальный проект доступным в сети

Вы также можете сделать локальный проект (обычный проект или проект, находящийся в настоящее время под контролем версий) доступным для подключенного рабочего пространства Altium 365 — по сути, «зарегистрировав» проект в рабочем пространстве и создав его «зеркало».Это позволяет вам пользоваться функциями совместной работы, доступными на платформе Altium 365, сохраняя исходный проект там, где он есть. Для этого откройте существующий локальный проект как обычно в Altium Designer, затем щелкните правой кнопкой мыши его запись на панели Projects и выберите Make Project Available Online в контекстном меню, открывая доступ к диалоговому окну Make Available Online.


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

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

Установите флажок Контроль версий , чтобы добавить проект в собственную встроенную систему контроля версий (Git) рабочей области. Этот параметр не отмечен по умолчанию, при этом файлы проекта будут просто храниться в рабочей области для базового доступа и предоставления возможности совместного использования с другими только для просмотра и комментирования — так сказать, менее формальная Simple Sync .Рекомендуется включить формальное управление версиями, так как при этом вы получите доступ к максимальной функциональности, предлагаемой посредством Workspace и платформы Altium 365.

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

Обратите внимание, что если опция Version Control отключена — тем самым используется неофициальная функция Simple Sync для локального проекта (который не находится под внешней системой контроля версий) — дизайн-проект может редактировать только один человек (владелец этот проект — тот, кто сделал его доступным онлайн в Workspace). Сила Simple Sync заключается в том, что вы не хотите, чтобы кто-то еще редактировал ваш проект, но вы хотите воспользоваться преимуществами парадигмы Global Sharing Altium 365 и иметь возможность поделиться этим проектом с несколькими другими людьми для просмотра и комментирования. Когда включена опция Version Control — за счет использования репозитория Workspace Versioned Storage на основе Git — тогда несколько человек могут совместно использовать проект для редактирования (при условии, что они являются частью команды Workspace), а также возможность использовать поддержку Global Sharing Altium 365 для совместного просмотра и комментирования.

Щелкните ссылку Advanced , чтобы открыть поле Folder . Это поле используется для указания, где должна быть создана папка для зеркального проекта — в структуре папок рабочей области.Путь по умолчанию для новых проектов указан на странице Admin — Settings — Projects интерфейса браузера Workspace (по умолчанию это будет Projects\ ). Нажмите кнопку

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

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

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

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

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

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

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

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

Зеркальный проект впоследствии будет доступен на странице Projects интерфейса браузера Workspace.

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

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

Простые состояния синхронизации

Если локальный проект доступен онлайн для Altium 365 Workspace с использованием подхода Simple Sync (без использования формального контроля версий Workspace), текущее состояние синхронизации между локальными проектами и проектами на стороне Workspace отображается на панели Projects . через ряд значков. Эти значки и их значение следующие:

Синхронизированный Синхронизированы локальный проект и зеркальный проект в рабочей области.
Выполняется синхронизация Изменения, внесенные в локальный проект, синхронизируются с зеркальным проектом в рабочей области. Для локального проекта не под внешней системой контроля версий это происходит при сохранении локального файла. Для локального проекта во внешней системе контроля версий это происходит при сохранении и фиксации изменений локального файла во внешнем репозитории проекта.
Проект доступен только для чтения Вам предоставлен доступ к проекту, но у вас есть к нему доступ только для чтения.В соответствии с методологией Simple Sync дизайнерский проект может редактировать только один человек (владелец этого проекта — тот, кто сделал его доступным онлайн в Workspace).
Не синхронизировано Изменения внесены локально, но они еще не синхронизированы с зеркальным проектом в рабочей области. Это может произойти, например, когда один и тот же проект открыт для редактирования владельцем/автором на двух компьютерах (ПК1 и ПК2). На ПК1 рабочая область впоследствии отключается.На ПК2 подключение к Workspace сохраняется и вносятся изменения. При сохранении локальных файлов проект остается несинхронизированным. Если вы попытаетесь закрыть проект на ПК2, появится диалоговое окно Закрытие несинхронизированных проектов , предупреждающее вас об этом факте. Если вы решите закрыть проект, изменения не будут доступны на ПК1. Чтобы исправить ситуацию, отключитесь от рабочей области на ПК2, а затем снова подключитесь к ней. Проект будет синхронизирован с Workspace. Синхронизированные данные будут отражены на ПК1, как только туда будет подключено рабочее пространство.
Конфликт

Возник конфликт между данными локального проекта и данными зеркального проекта в рабочей области. Это может произойти, например, когда один и тот же проект открыт для редактирования владельцем/автором на двух компьютерах (ПК1 и ПК2). На ПК1 проект открывается, после чего рабочая область отключается. Затем вносятся изменения и сохраняются локальные файлы. Позже, на ПК2, тот же проект открывается и, пока он еще подключен к Рабочему пространству, вносятся и сохраняются изменения.Еще позже подключение к рабочей области выполняется обратно на ПК1. Конфликт возникает из-за локальных изменений на ПК1, но рабочая область содержит обновленные данные изменений, сделанных и синхронизированных на ПК2.

Чтобы исправить ситуацию, на ПК1 щелкните проект правой кнопкой мыши и выберите команду Resolve Conflicts . Появится диалоговое окно Разрешить конфликты . У вас есть возможность Использовать серверные файлы (данные из зеркального проекта в рабочей области будут использоваться, а локальные изменения будут потеряны) или Использовать локальные файлы (данные из локального проекта будут использоваться и синхронизироваться с перезаписать текущие данные для зеркального проекта в рабочей области).

Сохранить на сервер

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

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

Поделились со мной

Доступ к проекту, совместно используемому пользователем Altium Designer, осуществляется с помощью параметра местоположения Shared With Me в диалоговом окне «Открыть проект». Пользователь не обязан быть членом команды Workspace.

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


Доступ к Web Viewer для общего проекта с панели Projects  .

Значки отображения документов

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

Значки состояния открытия/изменения

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

Измененный документ или проект, который еще не сохранен, отмечен звездочкой рядом с его записью на панели. Измененные документы также отмечены звездочкой внутри их вкладки в главном окне редактора.Когда блокировка файлов включена (см. Управление данными — Блокировка файлов), значки, связанные с документами на панели, указывают, когда файл открыт, изменен, открыт и заблокирован этим экземпляром Altium Designer или открыт и заблокирован другим экземпляром Altium Designer. Программное обеспечение Альтиум. Независимо от блокировки файла измененный документ обозначается звездочкой, связанной с его именем файла.
Значки состояния контроля версий
[пусто] н/д Файл не находится под контролем версий в репозитории VCS,
Без изменений Локальная копия файла соответствует файлу в репозитории и является актуальной.
Запланировано добавление Файл был добавлен в систему управления версиями, но еще не зафиксирован (возвращен) в репозиторий VCS.
Модифицированный Локальная копия файла изменена и сохранена в рабочей папке. Зафиксируйте файл, чтобы создать новую ревизию в репозитории.
Устарело Локальная копия файла (в рабочей папке) старше, чем его копия в репозитории, и поэтому устарела.Используйте параметр «Обновление системы управления версиями», чтобы получить последний файл из репозитория или сохранить файл, что создаст условие конфликта.
Конфликт Файл был зафиксирован другим пользователем до того, как вы зафиксировали свою отредактированную и сохраненную версию этого файла. Используйте команду Version Control Update или Resolve, чтобы определить, какая версия файла станет последней редакцией в репозитории.
Впереди сервера (Git) Файл в локальном рабочем репозитории новее, чем его аналог в удаленном репозитории Git.Это происходит, когда локальный файл был изменен, сохранен и передан в локальный репозиторий, но еще не отправлен в удаленный репозиторий.
Запланировано удаление Файл проекта удален из системы управления версиями и будет удален из репозитория и базы данных VCS во время процесса фиксации системы управления версиями. Этот значок также появляется, когда файл отсутствует в локальной рабочей папке (он был удален, переименован или перемещен), что устраняется повторным заполнением папки из репозитория с помощью команды Version Control » Update .
Заблокировано Файл заблокирован вами или другим пользователем. Заблокированный файл не может быть обновлен до новой версии в репозитории другим пользователем, если только он не будет принудительно разблокирован. Это состояние может быть связано с другими значками, такими как «Изменено» или «Без изменений», когда эти условия состояния также применяются. Заблокированный вами файл не может быть обновлен до новой версии в репозитории другим пользователем (если только он не будет принудительно разблокирован).Хотя один тип значка используется для пометки заблокированного файла, связанный с ним текст будет указывать, кто заблокировал файл — Заблокировано мной или Заблокировано кем-то другим . Текст VCS также будет указывать, например, на комбинированные условия; Изменено и заблокировано мной .

Файл проекта

Щелчок правой кнопкой мыши по файлу проекта на панели обеспечивает доступ к дополнительным параметрам и командам в контекстном меню.


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

Выбор правой кнопкой мыши включает:

  • Проверка проекта печатной платы — процесс компиляции выявляет электрические и чертежные нарушения и является неотъемлемой частью создания действительного списка соединений для проекта. Результаты отображаются на панели сообщений ( View » Panels » Messages ).
  • Сделать проект доступным в сети — при подключении к Altium 365 Workspace эта команда открывает диалоговое окно «Сделать доступным в сети», где вы можете зарегистрировать проект, который в настоящее время не находится под контролем версий Workspace.
  • Сделать проект доступным на сервере — при входе в рабочее пространство Concord Pro эта команда открывает диалоговое окно «Сделать доступным на сервере», позволяющее сделать этот проект доступным как проект в рабочем пространстве.
  • Добавить новый в проект — добавить новую пустую схему, плату, ActiveBOM, Draftsman, тип библиотеки, выходное задание, CAM или ссылку на базу данных в текущий проект.
  • Добавить существующий в проект — добавить существующий локально сохраненный документ схемы или платы в текущий проект.Другие типы файлов (текст и т. д.) также поддерживаются.
  • Клон — используется для клонирования проектов. После запуска команды в диалоговом окне «Клонировать проект» отобразится имя проекта и описание . По умолчанию исходное имя проекта будет использоваться с суффиксом « — копия ».
  • Сохранить – сохраняет проект.
  • Переименовать – переименовать проект.
  • Сохранить на сервер — открывает диалоговое окно «Сохранить на сервер», откуда вы можете локально сохранять измененные файлы.
  • Сделать активным проект — гарантирует, что желаемый проект станет текущим активным проектом.
  • Закрыть документы проекта — используется для закрытия всех открытых и/или открытых и скрытых документов, связанных с выделенным проектом.
  • Закрыть проект — закрывает проект и все активные документы проекта. Вам будет предложено сохранить все измененные документы.
  • Explore — используется для открытия экземпляра проводника Windows в том месте, где хранится целевой документ проекта.
  • Показать различия — обнаружение и устранение различий между двумя файлами дизайна.
  • Варианты — открывает диалоговое окно «Управление вариантами» для определения вариантов базовой конструкции, где компоненты могут быть сконфигурированы как встроенные или нет, или оснащены измененными параметрами компонентов.
  • История и контроль версий — открывает меню истории и параметров контроля версий. Используйте параметр подменю Local History (Legacy) , чтобы сравнить открытый документ с его последним сохраненным содержимым.Обновите, зафиксируйте, обновите или заблокируйте свой проект. Вы также можете разрешать конфликты, отменять локальные изменения или добавлять/удалять из системы управления версиями. Используйте параметр Storage Manager  , чтобы открыть панель Storage Manager .
  • Project Packager — открывает мастер Project Packager для упаковки файлов в переносимый ZIP-файл.
  • Project Releaser — нажмите, чтобы открыть Project Releaser.
  • Показать в Проводнике — используется для открытия панели Проводника Просмотр проекта для выбранного проекта.
  • Показать в веб-браузере — используется для открытия интерфейса веб-браузера проекта.
  • Поделиться — нажмите, чтобы открыть диалоговое окно «Поделиться», в котором вы можете поделиться своими проектами с другими людьми в любой точке мира прямо из программы.
  • Параметры проекта — нажмите, чтобы открыть диалоговое окно «Параметры проекта».

Элементы спецификации

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

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

Чтобы получить доступ к редактору ActiveBOM из панели Projects , необходимо включить параметр BOM.ActiveBOMDesignPreview в диалоговом окне Advanced Settings.Чтобы открыть диалоговое окно Advanced Settings , нажмите кнопку Advanced на странице System – General диалогового окна Preferences. Если в диалоговом окне Advanced Settings вносятся какие-либо изменения, необходимо перезапустить программное обеспечение, чтобы изменения вступили в силу.

Файлы документов

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


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

Некоторые параметры щелчка правой кнопкой мыши в основном такие же, как при щелчке правой кнопкой мыши по проекту, описанному выше. Другие включают:

  • Закрыть — закрытый документ больше не будет открываться в редакторе дизайна.
  • Explore — используется для открытия экземпляра проводника Windows в том месте, где хранится целевой документ проекта.
  • Добавить в проект — используется для добавления открытого в данный момент свободного документа в активный проект.
  • Удалить из проекта — используйте для исключения документа из родительского проекта.
  • Сохранить — сохранить документ локально.
  • Переименовать – переименовать документ.
  • Настройка страницы/Предварительный просмотр/Печать – управление печатью документов, дублирование функций, доступных в основных параметрах печати (Выводы » Документация » Печать).
  • Показать различия — обнаружение и устранение несоответствий в структуре проекта или различий между двумя файлами проекта.
  • История и контроль версий — открывает меню истории и параметров контроля версий.Используйте параметр подменю Local History (Legacy) , чтобы сравнить открытый документ с его последним сохраненным содержимым. Обновите, зафиксируйте, обновите или заблокируйте свой проект. Вы также можете разрешать конфликты, отменять локальные изменения или добавлять/удалять из системы управления версиями. Используйте параметр Storage Manager  , чтобы открыть панель Storage Manager .
  • SVN Database Library Maker — используется для доступа к мастеру преобразования библиотеки баз данных SVN из текущего документа библиотеки проекта — либо Schematic Library ( *.SchLib ), Библиотека моделей компонентов 2D/3D печатных плат ( *.PcbLib ) или интегрированная библиотека ( *.IntLib ).
  • Импорт библиотеки — используется для открытия средства импорта библиотек (простой режим), которое упрощает процесс импорта выбранных библиотек компонентов на основе файлов в рабочую область.

Примечания

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

Альтиум 365 | Руководство пользователя

Altium 365 ® — это облачная инфраструктурная платформа, которая объединяет все ключевые заинтересованные стороны и дисциплины, от конструкторов механических систем до закупки деталей, изготовления и сборки.Другими словами, Altium 365 соединяет проектирование электроники с производством.

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

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

Существует три уровня доступа к платформе Altium 365 и предоставляемым ею услугам:

  • Personal — для тех, кто хочет испытать возможности совместной работы в Altium 365 без необходимости в подключенном рабочем пространстве для хранения своих данных. Поддерживается постоянное хранение «моментальных снимков» проекта (с различных платформ ECAD) и производственных данных Gerber на платформе Altium 365 с возможностью обмена с кем-либо для комментариев и пометок.Существует также веб-доступ к проектам в реальном времени/незавершенном производстве — для просмотра и комментирования — которые были опубликованы за пределами рабочей области.

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

  • Standard — для тех, кто хочет воспользоваться всеми преимуществами Altium 365 Global Sharing и удобством доступа к проектам и компонентам в едином подключенном рабочем пространстве компании, но без строгих формальностей и структурирования управляемых данных.Предлагает возможность хранить живые проекты и делиться ими с кем угодно в мире для просмотра и комментирования или редактирования, а также использовать простые облачные библиотеки компонентов. Также включена поддержка ECAD-MCAD CoDesign.

Требуется регистрация в AltiumLive и Altium Designer с активным стандартным планом подписки. Функциональность доступна в Altium Designer и в веб-браузере.

  • Pro — для тех, кто хочет получить полную формальность и структуру управления данными и испытать все, что может предложить платформа Altium 365.Все ваши управляемые данные создаются и хранятся в единой подключенной рабочей области компании. Предлагает возможность хранить живые проекты и делиться ими с кем угодно в мире для просмотра, комментирования или редактирования. Также включен расширенный уровень поддержки ECAD-MCAD CoDesign. Доступны дополнительные услуги, функции и функции, в том числе полностью управляемые компоненты с проверкой компонентов и возможностью их использования, шаблоны компонентов, управляемые выходные задания и запросы на детали.

Требуется регистрация в AltiumLive и Altium Designer с активным планом подписки Pro.Функциональность доступна в Altium Designer и в веб-браузере.

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

Доступ к интерфейсу платформы Altium 365 из веб-браузера не ограничен. Доступ к рабочему пространству через интерфейс браузера или из программного обеспечения для проектирования MCAD является бесплатным.План подписки Altium необходим только в том случае, если вы хотите подключиться к Altium 365 (и, в частности, к Altium 365 Workspace) из Altium Designer.

Чтобы увидеть подробный список того, что включено в планы подписки Standard/Pro, взгляните на полное сравнение планов. Для получения последней информации о безопасности, надежности, конфиденциальности и соответствии требованиям облачной платформы Altium 365 посетите Центр управления безопасностью Altium 365.

С Altium 365 каждый может насладиться истинным опытом проектирования 21-го века, свободным от цепей изоляции. Работайте откуда угодно . Связь с кем угодно . Altium 365 создает беспрепятственные точки совместной работы в процессе разработки печатных плат, что делает его самым интегрированным опытом проектирования в отрасли. Как пользователю Altium Designer, вам не нужно менять способ работы сегодня, чтобы воспользоваться преимуществами Altium 365 — он дополняет и расширяет то, что вы уже делаете, упрощая сложные задачи (такие как совместная работа, совместное использование и организация). . Совместная работа в области проектирования электроники, механического проектирования, производства и деталей — без особых усилий.

Altium 365: Это просто. Это удобно. Это просто работает.


Рабочая область Altium 365

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

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

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

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

Следуя лучшим отраслевым практикам в области безопасности и целостности данных, Altium 365 поддерживает TLS (Transport Layer Security) 1.2. Таким образом, чтобы иметь возможность подключаться к Altium 365 Workspace из программного обеспечения для проектирования, вы должны использовать Altium Designer 20.1.14 или более поздней версии, которая включает поддержку TLS 1.2.


Глобальный обмен данными

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

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

  • Совместное использование ваших электронных проектов и производственных данных CAM через веб-браузер с помощью бесплатного автономного средства просмотра Altium 365 Viewer. Этот уровень общего доступа поддерживает только просмотр дизайнов без комментариев.
  • Предоставление общего доступа к проектам в реальном времени (WIP) людям, не входящим в вашу команду Workspace — только для просмотра и комментирования или для редактирования — без необходимости приглашать их в эту команду.Это позволяет приглашенным заинтересованным сторонам просматривать/редактировать (если применимо) работающий незавершенный дизайн-проект, не получая доступа к вашему полному серверу проектных данных.
  • Совместное использование «моментальных снимков» ваших проектов и производственных данных CAM — загруженных в ваше личное пространство на платформе Altium 365 — с кем угодно на постоянной основе. Этот уровень общего доступа поддерживает просмотр и комментирование общего моментального снимка. Имейте в виду, что для моментальных снимков проекта это просто статический снимок проекта в определенный момент времени, а не текущий (WIP) проект.
  • Предоставление общего доступа к проектным данным членам вашей рабочей группы. Делитесь проектами, папками и элементами по мере необходимости. Например, для проектов вы можете предоставить доступ только для чтения, чтобы собирать комментарии и отзывы. Или, возможно, предоставить доступ для чтения/записи, чтобы обеспечить полное глобальное сотрудничество географически рассредоточенной команды (с редактированием, выполняемым через Altium Designer).
  • Совместное использование данных о выпуске с вашим производителем через определенный пакет для производства , который они затем могут просмотреть через специальное средство просмотра пакетов для производства платформы Altium 365 — без доступа к вашему рабочему пространству и, следовательно, скрытия ваших проектных данных.Затем они могут загрузить пакет сборки , с помощью которого можно изготовить и собрать вашу плату.
Предоставление общего доступа к дизайн-проекту — будь то временная ссылка, снимок или сам проект в реальном времени — можно выполнять непосредственно из Altium Designer. В Altium Designer 20.1 стала доступна поддержка общего доступа к проекту за пределами Workspace из Altium Designer — только для просмотра и комментирования. Чтобы иметь возможность поделиться проектом за пределами Workspace для редактирования из Altium Designer и даже открыть такой общий проект для редактирования, требуется Altium Designer 20.2 или позже. Дополнительные сведения см. в разделе Совместное использование проекта в Altium Designer.

ECAD-MCAD CoDesign

Большинство разрабатываемых электронных продуктов закрепляются на какой-либо механической конструкции — шасси или корпусе. Обнаружение механического конфликта между платой (ECAD) и шасси/корпусом (MCAD) на позднем этапе проектирования может оказаться дорогостоящим делом. И хотя вы можете экспортировать 3D-модель из Altium Designer, это ручной процесс, требующий сознательного решения и действий.На самом деле это делается очень редко, в результате чего разработчик MCAD никогда не может быть полностью уверен, является ли то, что у него есть, самым последним и лучшим. На самом деле не должно быть так сложно убедиться, что вы не собираетесь тратить кучу денег только потому, что ваши инструменты не говорят.

Altium 365 Workspace упрощает совместную работу ECAD и MCAD, обеспечивая беспрепятственный обмен данными между доменами. Нет больше опроса обновлений и нет больше неопределенности. Данные передаются между доменами по мере развития дизайна, обеспечивая согласованность дизайна.

При использовании последних подключаемых модулей Altium CoDesigner поддерживаются следующие платформы MCAD:

  • Dassault Systemes SOLIDWORKS®
  • Autodesk Inventor Professional®
  • PTC Creo Parametric®
  • Autodesk Fusion 360®
  • Siemens NX® (только для пользователей решения NEXUS)

Официально поддерживаемые версии инструментов MCAD зависят от используемой версии подключаемого модуля Altium CoDesigner. Эту информацию можно найти на странице Новое в CoDesigner для Altium Designer и NEXUS.

MCAD CoDesigner синхронизирует проектирование печатных плат между инженерами-электриками и инженерами-механиками. Он работает напрямую с данными ECAD и MCAD через панель MCAD CoDesigner на стороне Altium Designer и соответствующую панель, подключенную к вашему программному обеспечению MCAD. Последнее обеспечивается путем установки (и регистрации в программе MCAD) подключаемого модуля Altium CoDesigner . Получите соответствующий подключаемый модуль для вашего программного обеспечения MCAD в разделе MCAD CODESIGNER PLUGINS на странице загрузок Altium.ком сайт.

Совместная платформа будущего…

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

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

О будущих возможностях и о том, кому они будут доступны — в плане подписки Standard и/или Pro — будет сообщено во время выпуска этих возможностей.

 

Файл истории проектирования

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

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

Термины DHF, DMR и DHR (обозначаемые как Design History File, Device Master Record и Device History Record соответственно) уже некоторое время ассоциируются с элементами управления проектированием, но схожести букв в каждом соответствующем имени достаточно. чтобы вызвать постоянную путаницу среди специалистов по медицинскому оборудованию.

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

 

Вот уже два года Greenlight Guru признается лидером в области программного обеспечения для управления качеством по версии G2 Crowd благодаря высоким показателям удовлетворенности клиентов и большому присутствию на рынке.

 

DHF — файл истории разработки

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

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

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

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

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

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

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

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

 

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

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

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

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

  • Разработка протоколов и отчетов проверки и валидации 

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

  • Все материалы, относящиеся к проектированию, передаются в производство

 

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

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

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


Управление DHF с помощью систем качества медицинских устройств

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

Многоуровневое программное обеспечение управления проектированием Greenlight Guru MDQMS

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

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

 

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

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 должен включать или ссылаться на местонахождение следующих частей информации:

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

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

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

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

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

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

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

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

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

 

DHF по сравнению с DMR по сравнению с DHR

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

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

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

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

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


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

5 шагов по созданию технической документации, которая (на самом деле) полезна

Джори Маккей

Джори — писатель, контент-стратег и отмеченный наградами редактор книги Unsplash.Он участвует в Inc., Fast Company, Quartz и других компаниях.

15 ноября 2018 г. · 11 минут чтения

🎁 Бонусный материал: Шаблон технической документации



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

Написать свой собственный? Вот бесплатный шаблон и контрольный список!

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

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

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

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

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

Но сначала краткий обзор этой статьи:

Когда, почему и как правильно использовать техническую документацию

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

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

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

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

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

Как планировать, писать и доставлять техническую документацию, которая работает

Так как же создавать эти четкие, лаконичные и удивительно полезные документы?

Написать свой собственный? Вот бесплатный шаблон и контрольный список!

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

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

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

Шаг 1. Проведите исследование и создайте «План документации»

Как говорится в старой поговорке: «Пиши то, что знаешь».

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

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

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

  • Цели: Проще говоря, что вы хотите, чтобы люди могли делать? Это использование вашего продукта? Найти справочные документы быстро и легко? Узнать, как использовать определенные аспекты вашего инструмента? Разрешить товарищам по команде запрашивать ресурсы или выполнять заказы? Наличие и знание четкой цели имеет важное значение для написания хорошей технической документации и поможет информировать обо всем, что вы делаете.
  • Существующие ресурсы: Что сейчас доступно? Вы обновляете или объединяете текущие ресурсы или начинаете с нуля? Есть ли старые, устаревшие версии, которые нужно убить? Проведите быстрый аудит и найдите все, что поможет вам написать или запутает вашу аудиторию, если они это найдут.
  • Руководства по стилю: В некоторых отраслях требуется, чтобы вы писали техническую документацию особым образом (например, руководство на простом языке для государственных сайтов или упрощенный технический английский для аэрокосмических, авиационных или оборонных компаний).В других случаях у вашей компании может быть руководство по стилю, в котором объясняется, какой язык использовать, как общаться с пользователями и даже грамматические стили.
  • Список тем: Какие темы и подтемы вы будете освещать в своей технической документации? Думайте об этом как о содержании и постарайтесь перечислить все основные разделы и подразделы, которые, по вашему мнению, вам понадобятся.
  • Инструменты и управление: Какое программное обеспечение, инструменты или веб-сайты будут использоваться для создания документации и управления ею? Ссылка на соответствующие руководства по стилю.
  • Крайний срок и окончательные результаты: Когда это должно произойти и в каком формате? Техническая документация касается не только содержания, но и структуры и доставки. И знание того, как контент будет представлен до того, как вы начнете, подскажет вам, что вам нужно и куда приложить свои усилия.

Этап 2: Структура и дизайн

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

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

Вот несколько кратких советов по каждому из них:

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

мгновенно понял, что это плохо?

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

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

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

  • Заголовок: Что это?
  • субтитры: Дополнительная информация
  • Обзор
  • Обзор : Что вы узнаете
  • Отделения: Внутренняя навигация
  • Особенности Каждый раздел документа
  • Прочитал следующий: Связанные документы, которые могут помочь пользователю

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

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

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

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

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

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

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

Шаг 3: Создайте контент

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

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

Начните с черновика

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

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

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

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

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

  1. Пишите как человек : По возможности используйте простой и понятный язык. Мы все читали эти документы, которые звучат так, как будто Google Translate пошло не так. Если вы обнаружите, что скатываетесь к неуклюжим предложениям или сложному языку, отойдите на несколько минут. Иногда возвращение к тексту после небольшого перерыва — это все, что нужно, чтобы освежить свой разум.
  2. Помните, ваши читатели — это не вы: Золотая заповедь технического письма — не бери на себя . Вы можете подумать, что говорите откровенно, но вы должны четко осознавать уровень знаний вашей аудитории. Не думайте, что они знают хотя бы половину того, что знаете вы.
    Золотая заповедь технической письменной речи – «не умышляй». Вам может показаться, что вы говорите очевидно, но вы должны знать, на каком уровне знаний находится ваша аудитория.
  3. Пишите столько, сколько нужно, чтобы быть полезным, и ни слова больше: Короткое письмо — это хорошо.Используйте форматирование, чтобы разбить большие куски текста и сохранить четкость в центре. Как пишет технический писатель Amazon Том Джонсон: «Хороший технический писатель сокращает количество слов до нужной краткости, не будучи непонятным».
  4. Помните о силе визуальных эффектов: Это еще одно клише, но изображения действительно говорят тысячу слов. По возможности визуализируйте то, что вы говорите, а не пытайтесь объяснить это.

Используйте правило 30/90, чтобы получить обратную связь

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

Если вы не являетесь экспертом в теме, о которой пишете, рекомендуется пригласить профильного эксперта (SME) после первого и окончательного черновика для проверки. Предоставление обратной связи — это навык сам по себе. А когда дело доходит до технической документации, один из лучших способов оформить ее — это то, что Джейсон Фридман называет «обратной связью 30/90».

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

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

Получите рецензирование и внесите исправления

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

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

Редактировать, редактировать и еще раз редактировать

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

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

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

Шаг 4. Доставка и тестирование

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

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

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

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

Наконец, проверьте удобство использования/UX . Пользователи теряются или путаются? Получают ли они ответы, которые искали (или думали, что получают, основываясь на заголовках или навигации?). Опыт пользователя сводится к большему, чем просто то, что вы написали. Потратьте время на работу со сторонними тестировщиками, чтобы убедиться, что когда реальные пользователи приходят к вашим документам, они уходят довольными.

Шаг 5. Создайте график обслуживания и обновления

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

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

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

Четыре дополнительных качества отличной технической документации

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

  1. Эффективность разработки и использования: Дублированный контент, неорганизованные структуры и нечеткие процессы могут убить техническую документацию. Используйте такой инструмент, как Planio wiki , чтобы поддерживать упорядоченность и эффективность контента.
  2. Актуальная информация: Нет смысла давать пользователям неверную информацию или показывать им устаревшие скриншоты, которые не похожи на то, с чем они имеют дело.Держите свою техническую документацию в актуальном состоянии.
  3. Последовательный дизайн и структура: Каждый раз, когда вы вступаете в контакт со своими пользователями, это время для создания вашего бренда. Придерживайтесь своего дизайна, стиля и тона во всей онлайн-документации.
  4. Доступно везде : Мобильные устройства захватывают мир. Ваша техническая документация, как и остальная часть вашего веб-сайта или приложения, должна быть адаптивной и обеспечивать удобство работы пользователей на всех устройствах.

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

Роль технической документации в успехе вашей компании легко недооценить.

About Author


alexxlab

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

Ваш адрес email не будет опубликован.