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

[QUOTE]'''ADVANCED''' написал:
Размер (вес) в байтах конечно же. [/QUOTE]
Размер графического файла в байтах зависит от алгоритма сжатия и выбранного цветового пространства. Он может быть изменен, иногда в несколько раз, без потерь информации. Для этого имеются многочисленные утилиты.

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

[QUOTE]TatLeo написал:
А зачем изобретать велосипед?! В тексте программы достаточно много комментариев, из которых все понятно. И  классы расписаны, и методы и параметры. Возьму комментарии и все! Лучше разработчика не сделаешь описание кода. По сути, цель задачи собрать в одно документацию по проекту.
Структуру всего документа я ведерживаю по ГОСТу[/QUOTE]
Читать текст программы и разбираться в комментариях - долго и неудобно. Особенно если программа большая. И часто комментарии относятся к деталям реализации. Вы же должны сделать краткий документ, описывающий назначение программы, входные и выходные данные, требуемые ресурсы и т.п. Чтобы читатель смог быстро получить представление о назначении, возможностях и условиях применения программы. В этом описании не должно быть конкретных деталей реализации, они могут меняться.

[QUOTE]techwriter написал:
я бы ещё сделала описание физической структуры. На мой взгляд, описания физической структуры недостаточно.[/QUOTE]

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

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

Если это критично - попробуйте добавить в компьютер оперативной памяти. Иногда помогает. Или сгенерируйте рисунки и вставляйте рисунки.

Лучше избегать помещения объектов в документы Word. Разве лишь формулы с помощью Mathtype/Equation Editor вставляются более или менее удовлетворительно. Но эти формулы для того и предназначены. В отличие от документов Visio.

[QUOTE]ADVANCED пишет:
[IMG]http://techwriters.ru/bitrix/components/bitrix/forum.interface/show_file.php?fid=4824&width=500&height=500[/IMG] [/QUOTE]Я бы порекомендовал:

Sierra K., Bates B. Head First Java, 2nd Edition / O'Reilly Media, 2005. - 688 pp.
перевод:
Сьерра К., Бейтс Б. Изучаем Java / пер. с англ., Эксмо, 2012 - 708 pp.


Schildt H. Java, A Beginner's Guide, 5th Edition / McGraw-Hill, Osborne Media, 2011. - 640 pp.
перевод:
Шилдт Г. Java. Руководство для начинающих (5-е издание) / Вильямс, 2012. - 626 c.

Bloch J. Effective Java, 2nd Ed. / Prentice Hall, 2008, 384 pp.
перевод:
Блох Дж. Java. Эффективное программирование / пер. с англ. М.:, Лори, 2014 - 461 с.

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

Люди запускали без особых проблем. https://appdb.winehq.org/objectManager.php?sClass=version&iId=29818

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

Управление и планирование документирования программного обеспечения описано в подробном стандарте ISO/IEC/IEEE 26511 "Systems and software engineering — Requirements for managers of user documentation". Планирование освещено в главах 6 и 7 этого стандарта, а также в приложении А.

[QUOTE]zukatoka пишет:
даже видео с обзором программы есть.
[/QUOTE]Войдите в yuotube.com, наберите в строке поиска Madcap Flare, получите более 500 видео.

Flare - это не переходный продукт, а другой продукт. Это готовый инструмент, с которым можно работать "из коробки", создавая печатную и онлайн документацию. Тогда как  DITA (Open DITA Toolkit, DITA foir Publishers плюс разные добавления и утилиты) — это конструктор. Мощный, но сложный, запутанный и архаичный.

Ответы на ваши вопросы.

1. Поддержка Flare и другие продукты Madcap Software на английском языке. Очень качественная. По телефону и электронной почте - как вам удобно. Но платная.

Обращаться за помощью можно в поддержку или на форум пользователей Flare. Форум достаточно активный и компетентный.

2. Да, все эти возможности имеются.

3. Русификация самой программы отсутствует. Интерфейс программы английский, немецкий, французский и японский. Все надписи, насколько я помню, задаются в XML файлах настроек, поэтому наверное можно добавить и русский интерфейс. Есть русская проверка орфографии. Генерируемые программой онлайн-справки можно делать для разных языков,
http://docs.madcapsoftware.com/FlareV10/FlareLanguageSupportGuide.pdf

[QUOTE]zukatoka пишет:
Автоматическая нумерация рисунков - проблема и для HTML-справок, в чём бы они ни разрабатывались. У меня пока что  для этого есть только одно решение - CSS-счётчики.[/QUOTE]В Flare и FrameMaker проблем нет. Там есть встроенные мощные средства автонумерации.

А насчет  CSS-счётчиков у меня весьма большие сомнения. Как CSS счетчик, при выводе главы или параграфа большого документа узнает, с какого номера начинается нумерация рисунков?

Руководства пользователя программы, автоматизированной системы и изделия машиностроения/приборостроения регламентируются разными наборами ГОСТов,

[QUOTE]Гость пишет:
на основании какого ГОСТа или иного нормативного документа я могу так поступить?
[/QUOTE]То, что не запрещено — разрешено.

[QUOTE]sonriza пишет:
ГОСТ 2.105 п.4.2.22
[/QUOTE]ГОСТ 2.105 применим только для конструкторской документации на изделия машиностроения, приборостроения и строительства.

В польском языке 5 родов https://pl.wikipedia.org/wiki/Gramatyka_j%C4%99zyka_polskiego#Rodzaje
И в языке диирбалу посложнее:
Но русский язык - всё равно один из самых сложных!  

[QUOTE]techwriter пишет:
Метод описывает поведение сущности. Я считаю, некорректно называть метод атрибутом сущности.
[/QUOTE]С глубоким прискорбием сообщаю, что при посылке вашего сообщения вы использовали метод POST, являющийся атрибутом HTML-формы. :D

[QUOTE]techwriter пишет:
[QUOTE] Т.е у сущности есть атрибуты, у которых в свою очередь могут быть параметры?
[/QUOTE]
Нет.
[/QUOTE]Да. Атрибутом сущности может быть метод (процедура, функция). У этого метода (процедуры, функции) могут быть параметры.

[QUOTE]eoi пишет:
Кто-нибудь может подсказать чем отличаются атрибуты и параметры?
[/QUOTE]Сильно зависит от контекста. Например, в Java
[LIST][*]request.[B]getParameter[/B](имя-параметра) выдает строку - значение параметра с заданным именем, переданного от клиента серверу в запросе.[*]request.[B]getAttribute[/B](имя-атрибута) выдает Java-объект, сохраненный сервером под заданным именем, или null если атрибут с таким именем не существует.
[/LIST]В других случаях параметр рассматривается как вид атрибута. Например, в Powershell параметры являются атрибутами коммандлета, но наряду с ними есть другие атрибуты, например, максимальное и минимальное количество параметров коммандлета.

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

[QUOTE]rusja пишет: Думаем о переводе хелпов и программной документации(которая вообще в Word ведется, т.к. ПО коробчное и особых доработок мало) в wiki или Сonfluence. Но инфо о безболезненном импорте из H&M я не нашла.
[/QUOTE]Насколько я знаю,такого импорта нет. В Atlassian Confluence есть импорт из Word и HTML. И не слишком хороший.

Импорта из H&M вообще нигде не видел. Видимо, потому что H&M мало кем используется, так что разрабатывать импорт из него нерентабельно. Впрочем, Atlassian Confluence + Scroll Versions для подготовки документации это тоже экзотика. Wiki и Confluence все-таки для других целей предназначены.

В  перечне видов документов, приведенных в стандартах ISO по жизненному циклу информационных систем, вид документа "Пояснительная записка" отсутствует.  Какой-то иной документ, состоящий из разделов, указанных в п. 2.2. РД 50-34.698-90 - тоже отсутствует. Как и большинство других документов, выдуманных советскими бюрократами в 70-е годы и перечисленных в ГОСТ 34-201-89.

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

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

Российские стандарты относятся к эпохе, когда пользовательский интерфейс использовал перфокарты, магнитные ленты и АЦПУ.

На сайте H&M написано: [url=http://www.helpandmanual.com/products_hm_features2.html]ссылка[/url]
[TABLE][TR][TD][B]Multi-user Editing, Team Authoring[/B]
Work on your project in a team. With Help & Manual Professional, [B]multiple authors can work on the same project at the same time[/B]. No databases or additional server components are required. Help+ Manual locks the topics that users are editing, presenting them in read-only mode to other users until the first user is finished. This is the perfect solution for documentation teams with up to around ten authors.
[/TD][TD][url=http://www.helpandmanual.com/screens/screen_multiuser_refresh.png][IMG]http://www.helpandmanual.com/screens/screen_multiuser_refresh_tn.png[/IMG][/url]
Team authoring
[/TD][/TR][TR][TD][B]Version Control[/B]
Store your projects in a version control system for additional security and the ability to roll back to earlier versions. Help & Manual Professional has active support for [B]Microsoft Visual SourceSafe[/B] and 100% compatibles. Topics are checked out of the version control database automatically when you edit them and are checked back in again when you save. Manual check-out is also available as an option, and multi-user editing is also supported in combination with version control, of course.
Starting with version 6.2 (Professional Edition), Help & Manual also includes built-in support for [B]SubVersion[/B].
[/TD][/TR][/TABLE]