ГОССТАНДАРТ РОССИИ - Информационная технология ПРОЦЕСС СОЗДАНИЯ ДОКУМЕНТАЦИИ ПОЛЬЗОВАТЕЛЯ ПРОГРАММНОГО СРЕДСТВА

8.1.5.1 Общие положения

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

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

Примечания

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

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

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

4 Тестирование на практичность может быть использовано для оценки (измерения) практичности по ГОСТ Р ИСО/МЭК 12119.

8.1.5.2 Планирование

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

a) этап(ы) жизненного цикла разработки, на котором(ых) должно проводиться тестирование;

b) цели тестирования;

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

d) среду тестирования;

e) число и вид привлекаемых пользователей;

f) процесс описания результатов тестирования и рекомендаций по ним;

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

h) процесс доведения результатов тестирования до всего персонала разработчиков документации и заказчика;

i) обязанности персонала разработчиков документации, участвующего в тестировании; j) процесс определения необходимости последующего тестирования.

Примечания

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

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

8.1.5.3 Программные средства

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

8.1.5.4 Типовые пользователи

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

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

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

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

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

Примечание — Документатор должен заключить соглашения с субподрядчиками в соответствии с настоящим стандартом.

8.1.7 Контроль изменений и сопровождение документации

8.1.7.1 Общие положения

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

a) функциональные изменения данной версии (this-version function changes) — изменения функции программного средства, внесенные при разработке документации и отраженные в опубликованной документации;

b) функциональные изменения последующей версии (next-version function changes) — изменения функции программного средства, внесенные при разработке документации и не отраженные в опубликованной документации, но подлежащие учету в последующей редакции документации.

Примечание — Различие между перечислениями а) и b) обычно определяется термином «дата пересмотра (cut-off date)»;

c) изменения программного средства после публикации (post-publication software changes) — изменения конкретных функций программного средства после издания данной документации;

d) изменения документа после публикации (post-publication document changes) — изменения в опубликованной документации, обусловленные изменениями программного средства или обнаружением погрешностей в данной документации.

8.1.7.2 Процедуры

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

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

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

b) наименование документа и номер версии или дата были указаны в верхнем или нижнем колонтитуле конкретного документа;

c) в бумажном документе с замененными страницами была предусмотрена таблица действующих страниц (лист изменений) или нечто подобное, позволяющее пользователю контролировать наличие каждой страницы документа;

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

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

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

8.2 Содержание спецификации стиля

8.2.1 Общие положения

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

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

8.2.2 Стиль описания

8.2.2.1 Язык

Должен быть указан язык, на котором составлена документация для конкретной страны, например французский (для Канады).

8.2.2.2 Орфография

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

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

8.2.2.3 Грамматика и ее применение

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

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

8.2.3 Бумажная документация

8.2.3.1 Компоновка и оригинал-макеты

8.2.3.1.1 Размер (формат) бумаги

Должен быть определен используемый размер бумаги.

Примечание — При выборе размера бумаги должно быть учтено следующее:

a) форматы А4, А5 и В5 указаны в настоящем стандарте (см. 4.1 и 4.5);

b) как будут храниться данные документы (в некоторых архивах возникают проблемы с хранением документов в конкретных форматах);

c) используются ли распечатки экранов (распечатки целых экранов в формате А5 недостаточно разборчивы);

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