Введение документации: Ведение документации по производимым на предприятии изделиям в системе Omega Production

Введение документации: Ведение документации по производимым на предприятии изделиям в системе Omega Production

Ведение документации по производимым на предприятии изделиям в системе Omega Production

Максим Панфилов, Евгений Кукареко

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

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

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

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

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

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

• серийное производство с небольшим циклом изготовления изделий и малой степенью конфигурируемости изделий под заказ;

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

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

В данной статье рассказывается о возможностях и опыте использования системы Omega Production по ведению электронной документации для производимых на предприятии изделий.

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

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

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

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

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

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

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

Рис. 1. Ведение общей конструкторской документации

 

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

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

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

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

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

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

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

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

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

Рис. 2. Спецификация произведенного изделия

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

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

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

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

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

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

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

Рис. 3. Ведение заказных комплектаций

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

В мелкосерийном и единичном производстве необходимо хранить документацию на каждое изделие. Естественно, это связано со спецификой производства, где каждый объект живет своей жизнью. Он может находиться в эксплуатации, возвращаться в ремонт или дорабатываться (например, в случае опытного производства). Состав каждого изделия может меняться с течением времени. Какими бы незначительными ни были изменения, они должны быть зафиксированы в документации. Вместе с тем независимые, но одинаковые объекты могут производиться по одной общей документации. Для решения такого рода задач в системе Omega Production введено понятие экземпляров объектов (рис. 4). Экземпляр сочетает в себе свойства документа и объекта производства и формируется на основе общей документации. Однако состав экземпляра в дальнейшем уже не зависит от изменения общей документации. Экземпляры, так же как и общая документация, являются электронными документами, для которых определяется свой жизненный цикл, не заканчивающийся производством, а имеющий п остпроизводственные этапы, такие как экс­плуатация и утилизация.

Рис.

4. Экземпляры изделий

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

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

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

 

Более подробную информацию о системе Omega Production можно найти на сайте www.omegasoftware.ru.

«САПР и графика» 6’2004

Как вести документацию, чтобы не было обидно за потраченное время / Хабр

Привет, Хабр! Меня зовут Татьяна Шуравина, я системный аналитик Innovative People, работаю на проекте в банковском секторе. Вместе с командой оптимизируем и автоматизируем операции сотрудников банка для обслуживания юридических лиц. В своей первой статье я рассказывала, как стать системным аналитиком без специального образования. Сегодня хочу поделиться с теми, кто начал свой путь в аналитике, тонкостями магического процесса ведения проектной документации. Не для кого не секрет, что зачастую бывает такое, что система есть, а документации, чтобы понять, как она работает, нет. В статье расскажу, какие есть подходы к ведению документации, зачем это нужно и поделюсь практическим опытом.

Что относится к проектной документации?

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

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

Итак, на первом этапе ведется предпроектная документация, которая описывает подготовку для запуска проекта и крупными мазками — план‑график проекта.

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

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

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

Зачем нужны правила оформления документации?

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

1) сокращение сроков первичных согласований на предпроектном этапе;

2) быстрый онбординг новичков и адекватная оценка сроков проекта;

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

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

Документация, необходимая для системного анализа и начала разработки продукта

Для начала системного анализа в моей команде аналитику достаточно иметь 3 основные составляющие:

• согласованный вижн;

• бизнес‑требования;

• макеты интерфейсов.

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

Бизнес‑требования могут приходить в аналитику в разных вариантах: в виде оформленного документа в ворде или user‑story, в которой описано поведение системы сейчас (as is) и как должно быть, в соответствии с требованиями заказчика (to be).

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

Ведение документации на примере одного проекта

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

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

1) ведение спецификаций требований к АС (СТАС) по ГОСТу в электронном виде с загрузкой документа в электронный архив;

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

Сравним описанные выше подходы на предмет удобоваримости формата работы с каждым.

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

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

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

Для аналитики мы разбили информацию на несколько разделов и подразделов:

• архитектура;

• описание процессов;

  • подраздел метрики;

• база данных.

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

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

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

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

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

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

Эффект от ведения документации, которое устраивает всю команду

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

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

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

• Google Drive для хранения разного вида файлов с общим доступом и редактированием онлайн.

• Dropbox, как замена Google Drive. Если, кто‑то из сотрудников потерял телефон, то в Dropbox можно отключить доступ к этому устройству.

• Confluence — общее рабочее пространство, база знаний для создания, хранения, редактирования документов.

• Notion — «википодобный» ресурс. Хорошо работает для базовой документации, особенно о каком‑то продукте. В целом, можно использовать как замену Confluence и сильно экономить, потому что Notion дешевле.

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

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

1. Документация должна быть актуальной. Для удаленных команд с десятью часами разницы во времени онлайн оборот особенно актуален: можно быстро редактировать документ и все это видят.

2. Документация должна быть доступной. Перепроверяйте права доступа.

В течении всего жизненного цикла проекта:

• выбирайте правильные инструменты для хранения и работы с документами;

• создавайте навигацию, в которой сможет разобраться даже новичок;

• делегируйте работу и проверяйте сделанное другими.

Так же полезными ссылками на интересные статьи:

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

Подход к ведению документации на ОС: наш опыт

Как научиться создавать полезную проектную документацию ИТ‑систем

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

Введение в изучение документации | ALA Store

Введение в изучение документации | Магазин АЛА

Перейти к основному содержанию

Поиск по сайтуГлавное меню

Главное меню

1. Дом
2. Введение в изучение документации

Основное содержание

Niels Lund

Это название будет доступно весной 2023 года. Вы можете разместить заказ, и товар будет отправлен, когда он станет доступен. Покупатели за пределами Северной Америки (США и Канада) должны связаться с Facet Publishing для получения информации о покупке.

Добавить в корзину

Цена:

66,99 $

Член ALA 

60,29 $

• Описание
• Содержание
• Об авторе

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

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

• человеческая жизнь с точки зрения документации;
• документация в теории;
Документация
• : концептуальная история;
• дополнительная теория документации;
• модель для анализа документации;
• документации на практике: 6 тематических исследований;
• документация в обществе; и
• наука и профессия документации.

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

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

Экзаменационные копии доступны для инструкторов, которые заинтересованы в принятии этого названия для использования в курсе.

1. Пролог: человеческая жизнь в перспективе документации

Часть I Документ в теории

2. Документ: концептуальная археология
3. Дополнительная теория документа
4. Модель анализа документа

Часть II Документация на практике

5. Музыка: Реквием K626 В. А. Моцарта
6. Литература: «Индейский лагерь» Эрнеста Хемингуэя
7. Наука: «Датская революция» Торкильда Кьергорда
8. Администрация: Карта социального обеспечения
9. Политика: Марш за гражданские права
10. Субкультуры: Домашняя страница байкера
11. Документация в обществе
12. Наука и профессия Документация
13. Эпилог: Общество в Перспектива документации
14. Литература и другие источники

Нильс Лунд

Нильс Лунд стал первым сотрудником и профессором документоведения на факультете документоведения Университета Тромсё, Норвегия. Д-р Лунд был адъюнкт-профессором Королевской школы библиотечных и информационных наук в Дании и дважды был приглашенным профессором Калифорнийского университета в Беркли. В 2001 году д-р Лунд основал The Document Academy, международную сеть по изучению документации, организующую ежегодные конференции DOCAM в Северной Америке и летние школы в Норвегии в Университете Тромсё. Он по-прежнему работает в качестве почетного профессора, курирует аспирантов и участвует в исследовательских проектах.

Также представляет интерес:

Литература для молодежи: от романтики к реализму, четвертое издание 002 $59,99

Номер товара: 

978-0-8389-4747-0

Год публикации: 

Издатель: 

ALA Neal-Schuman

Количество страниц: 

Ширина0:

Формат: 

Мягкая обложка

AP Категории: 

A, C, E, I

Как управлять обработкой в ​​архивах и специальных коллекциях: введение

Pam Hackbart-Dean

Elizabeth A. Slomba

Детали:

Цена:

$70,00 

Издатель: 

Количество страниц:

Ширина:

Высота:

Формат:

Мягкая обложка

Управление знаниями: введение 0003

Доктор Кевин С. Desouza

Scott Paquette

Детали:

Цена:

$82,00

Артикул:

978-1-55570-720-0

2 A00009A03000 Издатель Нил-Шуман

Количество страниц:

Ширина: 

Высота: 

Формат: 

Мягкая обложка

Имеют ли ценность архивы?

Добавить в корзину

Посмотреть всю страницу товара

Авторы:

Майкл Мосс

Дэвид Томас

Детали:

Цена:

90 000 90 000 90 000

90 039 Номер: 0 $86,99 90 03

978-1-78330-332-8

Год публикации: 

Издатель: 

Facet Publishing, Великобритания

Количество страниц: 

Ширина:

Высота:

Формат:

Мягкая обложка

Аутрич-услуги для подростков: руководство для начинающих

В корзину s Снег

Детали:

Цена:

49,99 $

Артикул:

978-0-8389-4815-6

Год публикации:

Издатель:

ALA Издания 9002 из 900 002 Ширина:

Высота:

Формат:

Мягкая обложка

AP Категории:

A, C

Введение в организацию знаний

Клаудио Ньоли

Детали:

Цена:

$70,99

Артикул:

978-1-7833-0465-3

Год публикации:

Издатель:

UK Publishing 9

Facet Количество страниц:

Ширина:

Высота:

Формат:

Мягкая обложка

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

В корзину с:

Aaron D. Purcell

Детали:

Цена:

85,00 $

Номер позиции:

978-0-8389-1450-2

Год публикации: 90 03 

0003

ALA Neal-Schuman

Количество страниц:

Ширина:

Высота:

Формат:

Мягкая обложка

AP Категории: 0 0 I

90,002 Практические знания и управление информацией

Добавить в CART

Просмотр Полного продукта Страница

Авторы:

Кэтрин Шопффин

Мэтт Уолш

Подробности:

Цена:

$ 86,99

Номер.78-1-78330-335-9

Год публикации:

Издатель:

Facet Publishing, UK

Количество страниц:

Ширина:

Высота:

2 Формат 0002 Мягкая обложка

Нижний колонтитул

Введение в документацию

Введение

В этом ознакомительном модуле вы узнаете, как начать работу в группе документации OpenOffice.

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

Ваша первая задача — подписаться на нашу рассылку документации. Вы можете подписаться, отправив электронное письмо по адресу [email protected].

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

Примечание. Параллельно с элементами, относящимися к Doc, на этой странице, вы можете также ознакомиться с ознакомительными модулями уровня 1 и уровня 2. В них есть полезная справочная информация о The Apache Way, этикете списка рассылки, принятии решений в проекте и т. д. Быстрый обзор — хорошая идея, особенно если вы новичок в работе с проектами с открытым исходным кодом в стиле Apache.

Теперь, когда знакомство завершено, давайте начнем!

Общая картина

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

Когда у пользователей возникает вопрос, когда они застревают, у них есть широкий выбор вариантов:

• Они могут обратиться за помощью к другу
• Они могут искать помощь в Google
• Они могут нажать F1 в приложении и искать помощь
• Они могут задать вопрос на нашем форуме поддержки сообщества
• Они могут зайти на сайт OpenOffice.org и поискать там решение

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

Разновидности документации

Мы поддерживаем документацию в различных формах:

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

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

Цели и ограничения

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

• Только около 1/3 пользователей OpenOffice говорят на английском как на родном языке. Это относится и к волонтерам, работающим над документацией. Таким образом, в наших разговорах по спискам и в нашей документации мы должны стремиться к хорошей, простой английской прозе, избегая региональных идиом и жаргона. По соглашению мы принимаем орфографию английского языка США для документации. Таким образом, мы должны планировать, чтобы документация, которую мы пишем, была переведена в какой-то момент.
• Мы также должны написать документацию, чтобы ее можно было перевести на другие языки. Это означает, что нам нужно быть осторожными в том, как мы смешиваем текст и графику на любых диаграммах.
• Мы используем лицензию Apache 2.0 для всех результатов проекта. Эта «разрешающая» лицензия с открытым исходным кодом гарантирует, что каждый имеет возможность адаптировать и повторно использовать документацию, которую мы создаем. Но это также означает, что нам нужно быть осторожными с тем, какие сторонние материалы мы используем в нашей документации. Пока вы не ознакомитесь с правилами Apache по использованию сторонних материалов в продукте Apache, вам следует начать обсуждение в списке рассылки любых сторонних материалов, которые вы хотите повторно использовать. Сюда входят также материалы из устаревшего проекта OpenOffice.org, поскольку некоторые из них были под другой лицензией.
• Мы стремимся предоставить как можно больше контента в виде страниц MWiki. Пользователям легко получить к ним доступ с любого устройства. Кроме того, поскольку они индексируются поисковыми системами, их будет легко найти пользователям, которые любят решать проблемы, ища решения в Google.

Приветствуются волонтеры

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

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

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

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

Приступая к работе

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

1. Подпишитесь на нашу рассылку документации, отправив электронное письмо по адресу [email protected].
2. Зарегистрируйте учетную запись на нашей MWiki, отправив электронное письмо с предпочитаемым именем пользователя и адресом электронной почты в список рассылки документации
3. Зарегистрируйте учетную запись на нашем CWiki (Почему у нас две вики? Это долгая история.