Виктор Фигурнов (Все сообщения пользователя)

[QUOTE]Elanor пишет:
А мы с десятого вернулись к SnagIT 8 - часто в процессе подготовки документации нужны скриншоты с разрешением, отличным от 96 dpi (например, для типографии порой требуется 300 dpi), а в более новых версиях почему-то возможность настроить разрешение урезали.
[/QUOTE]В скриншоте можно поставить любое разрешение, например, с помощью imagemagick, без переделки файла. Разрешение в скриншоте это просто указание желаемого размера при печати. От того, что вы поставите разрешение 300 или 2400 dpi в скриншоте больше точек не появится, более чётким он не станет..

Для скриншотов использую Snagiit 8 и Hypersnap 7///

Нормальные системы подготовки документации типа Flare, Robohelp и др., насколько я знаю, не работают с Git и ему подобными Distributed revision control systems. Только с централизованными системами управления версиями типа SVN, Perforce и т.п. И тут есть определенные резоны. Для писательских целей централизованной системы управления версиями обычно вполне достаточно.

Возможно, вы используете стили абзаца. Эти стили применяются только к абзацу.

К отдельным словам можно применить стили символов или стили символов и абзацев (связанные стили)

См. http://office.microsoft.com/ru-ru/word-help/HA102647012.aspx

[QUOTE]techwriter пишет:
У них есть user documentation или information products. Даже больше скажу, у них есть types of information.
[/QUOTE]User documentation - это один из [B]91[/B] видов документации по information products, перечисленных в стандарте ISO 15289:2011 Content of life-cycle information products (documentation) :D

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

[QUOTE]techwriter пишет:
Эксплуатационная документация" - это ГОСТовый термин, ИМХО. Поэтому и имеет смысл называть документацию эксплуатационную, если она разрабатывается по требованиям ГОСТа.
[/QUOTE]Гостовский солипсизм какой-то... На западе почти никто совковых Гостов не знает, а кто о них что-то знает, как правило, не имеет ни малейшего желания соблюдать эти странные архаичные предписания. Так что, у них на западе эксплуатационной документации поэтому нет? :D

[QUOTE]techwriter пишет[/QUOTE][QUOTE]Виктор Фигурнов пишет:
Как правило, разработчик - не пользователь. Разработчик тампакса может быть мужчиной, например.   :)   [/QUOTE][QUOTE]А кто ж он?[/QUOTE]Мало ли кто. Программист, дизайнер, художник, менеджер, и т.д.

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

А в эту игру он не играет. Вообще. Значит, он не пользователь.

[QUOTE]techwriter пишет:
Документация разработчиков - тоже пользовательская документация. Чем разработчик не пользователь?
[/QUOTE]Как правило, разработчик - не пользователь. Разработчик тампакса может быть мужчиной, например. :)

Согласно ГОСТ Р ИСО/МЭК 12207-2010, п. 4.53, Пользователь - это лицо или группа лиц, извлекающих пользу из системы в процессе ее применения.
Разработчик может вообще никогда не использовать систему для извлечения пользы, т.е. для каких-то практических задач.

[QUOTE]ADVANCED пишет:
Если рассматривать техническую документацию, касаемо тех.писателей, я бы выделил тра пункта.
1. Эксплуатационная (руководства всех видов и для всех аудиторий, справки, FAQ)
2. Проектная (ТЗ, технические требования, спецификации)
3. Технологическая (регламенты, методики, стандарты)
[/QUOTE]Вообще документация бывает нормативно-техническая, конструкторская, проектная, технологическая, эксплуатационная, программная, инструктивно-методическая и другая.

Стандарт ISO/IEC/IEEE 15289:2011 выделяет 7 групп видов документов относящихся к информационным технологиям - описание, план, политика, процедура, отчет, запрос и спецификация. В этих группах он перечисляет 91 видов документов.

Еще можно делить документацию по тому, к какому этапу жизненного цикла систем, программ, услуг она относится (стандарты ISO 15288:2008, 12207:2008, и 20000-1,2:2011 соответственно).

Долго придется составлять. Только для документации по информационным продуктам стандарт ISO/IEC/IEEE 15289 "Systems and software engineering — Content of life-cycle information products (documentation)" перечисляет 91 вид технических документов.

Посмотрите имеющиеся корпоративные стандарты. Вот, например:

Cisco Technical Documentation Style Guide
http://www.cisco.com/c/dam/en/us/td/docs/general/style/guide/SGAug09/stylegd.pdf

SAE Technical Paper Style Guide
http://volunteers.sae.org/authors/styleguide.pdf

[QUOTE]techwriter пишет: Недавно читала батл в американском сообществе технических писателей на тему Framemaker   :)   )) У них два лагеря было: Framemaker и DITA. Первых было меньшинство. Framemaker преподносился как устаревший софт, не отвечающий современным нуждам технических писателей.
[/QUOTE]Вы, наверное, что-то не так поняли. Framemaker это приложение, а DITA это архитектура. Сравнивать приложение и архитектуру (модель) бессмысленно. FrameMaker поддерживает DITA начиная с версии 7. В последних версиях (11, 12) эта поддержка вполне пристойная. Кроме того, есть различные дополнения, улучшающие работу по модели DITA в Framemaker (DITA-FMx и др.).

Framemaker уже лет 20 широко используется для документирования крупных проектов, включающих сотни, тысячи и десятки тысяч взаимосвязанных документов. Действительно, в его развитии был застой, но Framemaker 12 вполне неплох, и "отставание от  современных нужд технических писателей" там в общем-то ликвидировано. Теперь Framemaker 12 позволяет создавать и печатную, и онлайн  документацию в самых разных форматах, в нём есть средства интеграции со многими SMS, позволяющие сделать нормальный поток работ при документировании сложных проектов. И это отставание (в некоторых аспектах) было вовсе не от H&M, а от Flare, Robohelp и других ведущих систем подготовки документации.

FrameMaker и Open DITAToolkit тоже сравнивать трудно.

[QUOTE]techwriter пишет: Даже не представляю, чтобы они сказали, если бы узнали, что в России основным инструментом разработки документации является Word    :)   )) На самом деле, я считаю, что главным в выборе средства разработки является степень достижения целей документирования..[/QUOTE]Если цель - написать бумажку "для галочки", но по ГОСТу, то и Word вполне годится.

Help & Manual это вообще довольно редкая программа, и причины её популярности в России мне не понятны.

Что-то вроде популярности в России в начале 1990 г., редактора Сhiwriter, мало известного на своей родине.

В опросе технических писателей, проведенном американским сайтом WritersUA, из 501 респондентов

- 199 использует Adobe Framemaker
- 165 использует Adobe Robohelp
- 148 использует Madcap Flare
и т.д.
...
- 19 использует Help & Manual,

причем важность Help & Manual для своей деятельности 12 человек из этих 19 оценивает как крайне несущественную (1 или 2 балла по 5-балльной шкале).

[QUOTE]writer пишет:
[QUOTE] Виктор Фигурнов пишет:
ISO/IEC 26514-2008 Systems and software engineering — Requirements for designers and developers of user documentation.
[/QUOTE]Виктор, а у вас есть эти стандарты?
[/QUOTE]Да. Пришлось купить. :)

[QUOTE]techwriter пишет:
[QUOTE]описывала сам процесс разработки документации, его участников, их роли, порядок взаимодействия и пр.[/QUOTE][/QUOTE]Кроме этого, хорошо бы описать ещё процедуры:
-- определения целей, аудитории, задач разработки документации
-- активации проекта документирования,
-- создания плана документирования и плана управления документированием,
-- создания и утверждения спецификаций стилей документирования
-- управления документированием
Структуру декомпозиции работ
Инфраструктуру документирования
Методы и процедуры контроля качества и производительности документирования.

Видимо, такой документ должен основываться также на положениях  п.п. 7.2.1 и 6.3.6 стандарта ISO/IEC 12207:2008 ( ГОСТ Р ИСО/МЭК 12207-2010 "Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств" )

Процесс разработки технической документации подробно описан в стандарте ISO/IEC 26514-2008 Systems and software engineering — Requirements for designers and developers of user documentation.

Процесс управления разработкой технической документации описан в стандарте ISO/IEC/IEEE 26511-2011 Systems and software engineering — Requirements for managers of user documentation

Применительно к языку родных осин, надо добавить еще торжественные обещания следовать ГОСТам.

В майкрософтовском глоссарии:

Термин: [B]check box[/B]
Описание: A control that indicates whether or not an option is selected. A check mark or "x" appears in the box when the option is selected.
Перевод: [B]флажок[/B]

Термин: [B]flag[/B]
Описание: Broadly, a marker of some type used by a computer in processing or interpreting information; a signal indicating the existence or status of a particular condition. Flags are used in such areas as communications, programming, and information processing.
Перевод: [B]флаг[/B]

Термин: [B]flag[/B]
Описание: A graphic that indicates follow-up action is required, or otherwise identifies an important item.
Перевод: [B]флажок[/B]

Термин: [B]marker[/B]
Описание: A visual indicator that identifies a data point. In a map report, a marker is the visual indicator that identifies the location of each point on the point layer.
Перевод: [B]метка[/B]

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

Или можно сделать анимированный GIF.

Но не лучше ли сделать 1 обычную картинку,
или 3 картинки, если так важно показывать разные состояния: неактивно, наведен курсор, нажато?

Добавлю еще:

Не написано, какая именно версия программы описывается. В заголовке написано про Ashampoo Burning Studio, неизвестной версии, картинки даны из Ashampoo Burning Studio Free, тоже неизвестной версии.  

Раздел "Назначение программы" очень сокращен по сравнению с тем, что написано во встроенной справке программы.

Раздел "Условия выполнения программы" не соответствует тому, что написано во встроенной справке программы. Многие условия пропущены. Указание, что программа выполняется на Win7 (32bit и 64bit), дано 2 раза.

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

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

Иллюстрации, если в документе их более одной, нумеруют арабскими цифрами в пределах всего документа (ГОСТ 19.106-78).

Есть ГОСТ 19.002-80 ЕСПД. Схемы алгоритмов и программ. Правила выполнения, и ГОСТ 19.003-80 ЕСПД. Схемы алгоритмов и программ. Обозначения условные графические , ГОСТ 19.005-85 ЕСПД. Р-схемы алгоритмов и программ и РД 50-34.698-90 Автоматизированные системы. Требования к содержанию документов. Всё это устарело и каменный век. Для современных технологий программирования мало применимо. На западе используются UML-схемы и другие средства. Стандарт ISO/IEC/IEEE 15289:2011 Systems and software engineering — Content of life-cycle information products (documentation) перечисляет 87 видов документации, используемой на всех этапах жизненного цикла, но документов типа "Схема алгоритма" или "Описание алгоритма" там нет.

[QUOTE]Гость пишет:
Вопрос: как писать руководство пользователя, описание автоматизированных функций и программу и методику испытаний? Только на новые функции или руководство пользователя и пми должно описывать все функции, описание автоматизируемых, только те что в ТЗ? Как правильно? По идее документация должна актуализироваться, но тогда руководство пользователя не будет биться с ТЗ. ... Или подскажите, пожалуйста, какой-нибудь стандарт на актуализацию документации. [/QUOTE]Обычно для существенно изменившейся версии программы делается новая версия документации, и в нее включается перечень изменений (Release notes), включающий описание новых/изменившихся/удаленных функций.программы. Заменять новую версию документации списком изменений стандарт ISO/IEC 26514:2008 запрещает, так как это трудно воспринимается новыми пользователями.

Стандарты на обновления документации:
ISO/IEC 26514:2008 Systems and software engineering —- Requirements for designers and developers of user documentation, раздел 9.4 "Updating and maintenance"
ISO/IEC/IEEE 26515:2011 Systems and software engineering -- Developing user documentation in an agile environment

[QUOTE]Elanor пишет:
Ок, номер изменили. [url]https://www.iso.org/obp/ui/#iso:std:iso-iec:25051:ed-2:v1:en[/url]
Не думаю, что в плане требований к полноте и правильности пользовательской документации, требования сильно изменились.
[/QUOTE]В новом стандарте 19 требований к документации пользователя, в старом - 5. Да и те 5 требований несколько поменялись. Это сильное изменение или нет? :D

[QUOTE]Elanor пишет:
Я писала про стандарт Российской Федерации. У нас 12119 вроде бы действует
[/QUOTE]Да, к сожалению, в России действует стандарт 20-летней "свежести" - перевод стандарта ISO 1994 года. С тех пор в софтверной индустрии очень много изменилось.

[QUOTE]Elanor пишет:
Про стандарт. Есть чудный ГОСТ Р ИСО/МЭК 12119-2000, в котором приводятся требования к документации, как то: полнота, правильность, простота обозрения, непротиворечивость.
[/QUOTE]Этот стандарт ISO уже 8 лет как отменила. Действующий стандарт ISO/IEC 25051:2014 "Software engineering -- Systems and software Quality Requirements and Evaluation (SQuaRE) -- Requirements for quality of Ready to Use Software Product (RUSP) and instructions for testing"

Шапка и подвал. Можно заголовочная часть и подвал.

Это термины ещё времён вёрстки газет на наборных машинах, им более 150 лет.

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

Для сведения: средняя зарплата в Москве по состоянию на апрель 2014 г. - 64338 рублей. (данные Росстата).
Вы хотите квалифицированного специалиста за  50000-70000 руб.? С "глубиной понимания продукции на уровне инженера тех. поддержки)? Надейтесь, может вам и повезет.