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

[QUOTE]ADVANCED пишет:
Для чего? Писателю администрировать вряд ли придется, ну только в личных целях что-то.
[/QUOTE]Может и придется. Например, если пишешь руководство по развертыванию интернет-сервиса, придется самому развернуть какой-то демонстрационный вариант. А значит, настроить сервера, используемые сервисом, и их взаимодействие.
.

Используйте версию со звездочкой

[B]\chapter*[/B]{Введение}

И затем введите команду, если нужно чтобы этот заголовок был в оглавлении

[B]\addcontentsline{toc}{chapter}{[/B]Введение[B]}[/B]

http://www.ozon.ru/context/detail/id/7607778/

[QUOTE]Марина пишет:
34 гост введен в действие в 90-х годах. Техническое задание отлично пишется по 34 госту, если использовать его в ситуации, для которой он и был предназначен - создание автоматизированной системы "под ключ", включая установку и настройку ПО на технике заказчика, возможно, поставку или апгрейд техники, обучение персонала.
[/QUOTE]34 ГОСТ про техническое задание (ГОСТ 34.602-89) введен в 1989 году, идеология там от 1970-х гг. По сравнению со стандартом IEEE/ISO/IEC 29148-2011 "Systems and software engineering -- Life cycle processes -- Requirements engineering" это каменный век. На поставку и апгрейд информационных систем и обучение персонала имеются отдельные и тоже весьма подробные стандарты. Зато в ГОСТ 34 больше половины содержимого - про формочки и рамочки.

Если начальство и руководство заказчика находится по своему развитию на уровне 70-80 гг. прошлого века. то ГОСТ 34.602-89 это именно то что надо.

Программа и методика испытаний чего?

Для разных видов продукции, технологий, услуг имеется более [B]4200 [/B]международных стандартов ISO, излагающих или уточняющих методики испытаний.

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

[QUOTE]fs444 пишет:
А как стандарт ISO? вижу, он мало где требуется? потому что дорого? =)
[/QUOTE]Стандартов ISO много тысяч, из них к созданию технической документации относятся несколько десятков.

Это не дорого. Просто не по сеньке шапка. Эти стандарты ориентированы на уровень технологий и уровень организации и менеджмента разработок, который в российских коммерческих организациях будет достигнут лет через 20, а в государственных и обслуживающих их организациях - дай Бог лет через 50. Пока же нам милее и понятнее ГОСТЫ 1970 гг.

Тогда оформите титульные листы по ГОСТ 3.1105-2011, присвойте документам коды по ГОСТ 3.1201-85. Что ни сделаешь чтобы угодить незаконным требованиям органов сертификации.

[QUOTE]DimonP пишет:
Виктор, возможно я не правильно поставил вопрос  :)  Речь идет о цифровом коде, а конкретней о коде характеристики документа.
Программы и методики проведения испытаний относятся к ЕСТД? Какой это вид документа?
[/QUOTE]Смотря что испытывается. Испытание программных систем например к ЕСТД никаким боком. Кроме того, применение давно устаревших нормативов это дело добровольное и нужно лишь если заказчик того желает или если начальник идиот.

Вид документа - видимо "вспомогательный документ", см. [url=http://www.google.ru/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CB4QFjAA&url=http%3A%2F%2Fvsegost.com%2FCatalog%2F51%2F51112.shtml&ei=SucvVJaLJeWhyAOZiYL4BQ&usg=AFQjCNH5ju9Qm74sz2OLoTGFeypz3eZtwA&sig2=mGC-8K4WtPBC-rkSuBvvcg&bvm=bv.76802529,d.bGQ&cad=rjt][I]ГОСТ 3.1102-2011[/I][/url] Код не установлен.

[QUOTE]DimonP пишет:
Есть уже готовые программы и методики проведения приемо-сдаточных испытаний, необходимо присвоить им обозначения. Как правильно это сделать?
[/QUOTE]Составляете перечень этих программ и методик, придумываете для них обозначения или записываете общепринятые обозначений, помещаете в документ раздел с названием "Перечень принятых обозначений".

[B]\renewcommand{\familydefault}{\sfdefault} [/B]
Изменит стандартный шрифт документа на сансерифный.

[url=http://en.wikibooks.org/wiki/LaTeX/Fonts]Здесь[/url] можно прочесть и про другие возможности...

[QUOTE]Ден пишет:
Да у меня трудность с определением этого запроса т.е я пытаюсь сказать, что это вообще такое, а у меня ничего не получается
[/QUOTE]Запрос к системе — это структурированное сообщение, созданное согласно некоторому протоколу обмена данными, при получении которого система должна выполнить некоторое заданное действие.

Если формат (протокол) запроса уже описан, надо сослаться на описание.

Если не описан, то надо его описать. Например, так как [url=http://www.w3.org/TR/2007/REC-soap12-part1-20070427]здесь[/url] или [url=http://www-01.ibm.com/support/knowledgecenter/SSGSG7_7.1.0/com.ibm.itsm.srv.doc/t_queries_tsm_display_info.html?lang=ru]здесь[/url].
В дальнейшем при описании запросов указывается назначение запроса, его параметры и получаемые результаты.

[QUOTE]Ден пишет:
тут я понимаю, что запрос это не [I]список требований к системе,[/I] а нечто другое) а что?[/QUOTE]Как правило, это структурированное сообщение, созданное согласно некоторому протоколу обмена данными.

[QUOTE]writer пишет:
Программисты в нашей компании описывают бизнес-процессы (со стороны работы программы) весьма сумбурно и бессистемно. Соответственно и техническому писателю очень трудно что-либо понять по ним. Новому человеку вообще нереально понять о чем там идет речь, так вот...есть ли у кого шаблон или рекомендация по описанию бизнес-процессов,[/QUOTE]Скорее всего, вы хотите поставить телегу впереди лошади. Если программисты описывают бизнес-процессы сумбурно и бессистемно, то скорее всего и сами эти бизнес-процессы непродуманные, сумбурные, бессистемные. Почти наверняка, с "дырами" и противоречиями. И нужно сначала продумать и переструктурировать эти процессы, чтобы они были ясны, понятны и непротиворечивы. Тогда и программист сможет их понятно описать.

Для формального описания бизнес процессов имеется множество методологий: IDEF0, IDEF3, DFD, ARIS, и др. Но любая из них весьма непроста в изучении, и не сделает из дерьма конфетку. Принцип GIGO - [I]Garbage In, Garbage Out[/I], универсален и никакой волшебной палочкой не обходится.

Место интересное, но в зарплате терять совсем не хочется.  :D

[QUOTE]zukatoka пишет:
У меня задание написать Руководство программиста к API web-приложения. ... Пока на данный момент имею на руках только набор методов и и краткое описание. Помогите, кто чем сможет, неопытной)
[/QUOTE]Как правило, для описания API больше ничего и не надо. Для каждого объекта указывается назначение, родительские и дочерние объекты, свойства, методы и т.д. Для каждого метода указывается назначение, синтаксис вызова, параметры, результаты, требования, факультативно - замечания и полезные ссылки ("см. также" ;) . И так далее. Посмотрите как описано, например, Windows API в MSDN, [url]http://msdn.microsoft.com/en-us/library/windows/desktop/hh920508(vs.85).aspx[/url]

Еще могу добавить

Guide to Software Engineering Body of Knowledge (SWEBOK), v. 3.0, 2014
ISO 42010-2007 - Recommended practice for architectural description of software-intensive systems
ISO/IEC 15288:2008 Standard for Systems and Software Engineering — System Life Cycle Processes
IEEE 1074-2006 Standard for Developing a Software Project Life Cycle Process
IEEE 1016-2009 Standard for Information Technology—Systems - Design—Software Design Descriptions

[QUOTE]Ирина Сидорова пишет:
при котором этот рисунок будет изображаться целым количеством точек фотонаборного автомата[/QUOTE]Верно. Но это для черно-белых рисунков (штриховых). Для рисунков в оттенках серого размер печатаемого пикселя рисунка должен быть кратен размеру точки фотонаборного автомата умноженной на округленный вверх квадратный корень из эффективного количества градаций цвета... Например, если требуется 64 градаций цвета (при цветной печати - градаций цвета каждой краски), то при размере точки фотонаборного автомата 1/2400 дюйма размер пикселя рисунка должен быть кратен 1/300 дюйма.

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

1) 75, 150, 300 точек на дюйм это разрешение древних лазерных принтеров типа HP LaserJet II. Отсюда традиция.

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

3) Чтобы при печати не возникали "линии разной толщины", муар и т.п., следует учитывать разрешение используемого печатного устройства или фотонаборного автомата при создании и масштабировании рисунков.
Например, если фотонаборный автомат работает с 2400 DPI, то можно все используемые рисунки делать с 300 DPI, и масштабировать их так, чтобы масштаб был кратен 12,5% (=300/2400). Например, масштабировать рисунок на 112,5% можно, а на 110% или на 115% нельзя. На 62,5% можно, а на 60% или 65% нельзя.

[QUOTE]Elanor пишет:
У меня другие данные от типографии, с которой мы работаем, и нашего верстальщика.
[/QUOTE]Это не данные, а ошибочное мнение. Работники типографии и верстальщик знают, что для того, чтобы изображения выглядели хорошо при печати, их надо отсканировать с разрешением, например, 300 dpi.
И поэтому тупо предъявляют требование: все рисунки должны быть с 300 dpi. Ничего больше за этим не стоит.

Когда такому работнику типографии или верстальщику предъявляешь три абсолютно  одинаково напечатанных скриншота, и просишь определить, где скриншот с разрешением  50 dpi, где 300 dpi а где 1200 dpi - у них в голове происходит короткое замыкание, они не понимают, как такое возможно.

[QUOTE]Elanor пишет:

Вставленный скрин, снятый в 96 dpi, уменьшают, чтобы он влез на страницу А5 - и вот тут как раз и уменьшается качество отображения всяких надписей, кнопок...
Чего не происходит при увеличении на верстке скриншота, снятого с 300 dpi.
[/QUOTE]Вы заблуждаетесь. Скриншот "снятый с 96 dpi" и скриншот "снятый с 300 dpi" ничем не отличаются друг от друга, кроме значения DPI, то есть 4 байт в заголовке в графического файла. Это значение DPI сообщает рекомендуемый размер печати для изображения (ширина в пикселях/DPI х высота в пикселях/DPI).

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

Вы можете снять скриншот размера 800х600 пикселей, задав при снятии разрешение 100 dpi, вставить в Word или Indesign и напечатать без масштабирования. Затем вы можете снять тот же скриншот размера 800х600 пикселей, задав при снятии разрешение 300 dpi, вставить в Word или Indesign, растянуть вставленный рисунок в 3 раза и напечатать. Затем вы можете снять тот же скриншот размера 800х600 пикселей, задав при снятии разрешение 50 dpi, вставить в Word или Indesign, уменьшить вставленный рисунок в 2 раза и напечатать. Результат будет в точности одним и тем же. Потому что во всех трех случаях вы будете печатать одинаковое изображение размером 800х600 пикселей на одном принтере с одними и теми же линейными размерами отпечатанного изображения.

[QUOTE]ADVANCED пишет:
Разве DPI влияет на размер изображение? По-моему, этот параметр влияет только на качество печати не изменяя размеры изображения. Один и тот же рисунок может быть напечетан примитивным матричным принтером 30 точек на дюйм, другой лазерным 1200 точек на дюйм.
[/QUOTE]DPI это количество точек на дюйм. При сканировании величина DPI указывает, сколько точек растра создаётся на линейный дюйм сканируемого изображения. В растровом графическом файле величина DPI сообщает рекомендуемый размер печати для изображения (ширина в пикселях/DPI х высота в пикселях/DPI).

DPI печатающего устройства это  число точек на линейный дюйм выводимого принтером изображения. Но надо понимать что в современных системах, основанных на графическом интерфейсе, растровые графические изображения в процессе печати автоматически масштабируются с учетом DPI принтера. А именно, если вы отсканировали документ с разрешением 200 dpi и получили растровый файл размера 1000х1500 точек, а потом хотите напечатать его на принтере с разрешением 600 DPI так, чтобы физический размер отпечатанного изображения совпадал с размером исходного документа, то в действительности принтер напечатает изображение размером 3000х4500 точек, которое будет создано в процессе печати из вашего изображения размером 1000х1500 точек. Это будет сделано либо драйвером принтера (например, для GDI-принтеров), либо встроенным программным обеспечением принтера (например, для PostScript-принтеров).

[QUOTE] ADVANCED пишет: В этом случае используется не величина DPI, а ,PPI.[/QUOTE]PPI тут вообще ни при чем.

Стандарт IEEE-830 устарел (его первая версия от 1984 года, и в дальнейшем идеология не менялась) и был отменен.
Пользоваться им крайне не рекомендую.

Вместо IEEE-830 принят стандарт IEEE/ISO/IEC 29148-2011 "Systems and software engineering -- Life cycle processes -- Requirements engineering"

О SRS посмотрите раздел 8.4 стандарта IEEE/ISO/IEC 29148-2011 - там все понятно и подробно написано.

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

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

Если пишете документацию по-английски - следуйте правилам англо-американской типографики. Там это уместно.

TechSmith Camtasia Studio. http://www.techsmith.com/camtasia.html

Она платная - но триал-версия фактически вечная. ПО истечении срока действия ее можно снести и загрузить снова.

Вы наверное запутались.
Я сдавал десятки книг в разные типографии. Никогда с "96 dpi" проблем не имел.  И ухудшений не видел. В т.ч. при применении Индизайна.

DPI это просто служебная информация в графическом файле. Значение DPI не меняет само изображение.
А только указывает желаемый размер изображения при печати.

Вы снимаете область экрана, предположим, 800 х 600 пикселей. Получается графический файл.
В этом графическом файле должно быть 800 х 600 пикселей, и эти пиксели никак не поменяются от того, какое вы укажете dpi.
Хоть 72, хоть 96, хоть 300, хоть 2400 dpi напишите - без разницы.
Если у файлов разное dpi, но одинаковое количество пикселей по  горизонтали и вертикали, и они печатаются с одинаковым выходным размером, то они напечатаются абсолютно одинаково.  

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

Например, снимаешь область 800х600 пикселей, указываешь 300 dpi - а программа делает графический файл размером 2500 * 1875 пикселей. Растянула.

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

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