1. Информация для управления
Во время разработки программного обеспечения администрации необходимо оценивать ход работы, возникающие проблемы и вероятности развития процесса. Периодические отчеты, согласно которым проверяют ход работ по графику и представляют планы на следующий период, обеспечивают контрольные механизмы и обзор проекта.
2. Связь между задачами
Большинство проектов разработки программного обеспечения разделяется на задачи, зачастую выполняемые различными группами. В типовом варианте:
- специалисты в предметной области начинают проект;
- аналитики формулируют требования к системе;
- проектировщики разрабатывают системный и программный проекты;
- специалисты по изданиям создают пользовательскую документацию в соответствии со стратегией и стандартами по документированию;
- специалисты по обеспечению качества и ревизоры оценивают общую полноту и качество функционирования программного обеспечения;
- сопровождающие программисты улучшают эксплуатируемое программное обеспечение и разрабатывают его изменения или расширения.
Этим людям необходимы средства общения друг с другом, обеспечивающие информацию, которую можно, при необходимости, воспроизводить, распространять и на которую можно ссылаться.
Большинство методологий разработки программного обеспечения устанавливают официальные документы для связи между задачами. Например, аналитики представляют официальные спецификации требований для проектировщиков, а проектировщики выдают официальные проектные спецификации для программистов.
3. Обеспечение качества
Требуется документация разработки и документация продукции для выполнения задач, связанных с обязанностями по обеспечению, качества программного обеспечения.
4. Инструкции и справки
Документация, требующаяся операторам, пользователям, руководителям и другим заинтересованным лицам для того, чтобы понимать и использовать программную продукцию.
5. Сопровождение программного обеспечения
Сопровождающим программистам требуется детальное описание программного обеспечения, такое, чтобы они могли локализовать и корректировать ошибки и модернизировать или изменять программное обеспечение соответствующим образом.
6. Исторические справки
Документация, требуемая в качестве исторической справки по проекту. Данная документация может помочь в переносе и переводе программного обеспечения в новое окружение.
Из-за существенной роли, которую играет документация на всех стадиях жизненного цикла программного обеспечения, должна быть подготовлена официально утвержденная стратегия. Каждый затронутый стратегией должен быть информирован о ней и должен ее понимать. Официальная, описанная, разрекламированная стратегия устанавливает дисциплину, требуемую для эффективного документирования программного обеспечения. Стратегия должна поддерживать основные элементы эффективного документирования:
1) требования документации охватывают весь жизненный цикл программного обеспечения. Документация требуется на ранних стадиях проекта и должна быть доступна и сопровождаться на всем протяжении процесса разработки программного обеспечения. После завершения процесса разработки документация необходима для использования, сопровождения, модернизации, преобразования или передачи программного обеспечения;
2) документирование должно быть управляемым. Управление и контроль требуются для получения и сопровождения документации. Руководители и специалисты по изданиям должны подготовить подробные планы, охватывающие документирование продукции, графиков, обязанностей, ресурсов, обеспечения качества и процедур проверок;
3) документация должна соответствовать ее читательской аудитории. Читателями могут быть руководители, аналитики, специалисты по экспертным системам, сопровождающие программисты, канцелярский персонал и т. д. В зависимости от выполняемых задач им требуются различные степени детализации и различное представление материала. Специалисты по изданиям должны быть готовы соответствующим образом спроектировать различные типы документации, предназначенные для различных читателей;
4) работы по документированию должны быть объединены в общий процесс разработки программного обеспечения;
5) должны быть определены и использованы стандарты по документированию. По возможности, должны быть приняты существующие стандарты. Когда подходящие стандарты отсутствуют, должны быть разработаны требуемые стандарты и руководства;
6) должны быть определены средства поддержки. Должны быть использованы там, где это экономически целесообразно, средства, помогающие разработке и сопровождению программной продукции, включая документацию.
ОПРЕДЕЛЕНИЕ СТАНДАРТОВ И РУКОВОДСТВ ПО ДОКУМЕНТИРОВАНИЮ
Внутри организации должны быть приняты стандарты, и руководства для:
- модели жизненного цикла программного обеспечения;
- типов и взаимосвязей документов;
- содержания документа;
- качества документа;
- форматов документа;
- обозначения документа.
Данные стандарты и руководства будут определять, как следует выполнять задачи документирования, и будут обеспечивать критерии для оценки полноты, полезности и соответствия программной документации, создаваемой в организации.
По возможности, должны быть приняты действующие международные и национальные стандарты. Если подходящие стандарты отсутствуют, то организация должна разработать собственные.
Большинство стандартов и руководств выдают рекомендации, которые применимы на общем уровне. Зачастую будут требоваться управленческие решения для адаптации общих рекомендаций к конкретным проектам. Применение стандартов, распространяющихся на организацию документирования, облегчит руководителям проекта определение следующих вопросов:
- какие типы документов требуются?
- каков объем представляемой документации?
- что документы содержат?
- какой уровень качества будет достигнут?
- где документы будут созданы?
- как документы будут хранить, сопровождать и обращать?
Если возможен контракт на программное обеспечение, контракт должен требовать, чтобы документация удовлетворяла принятым стандартам. Он должен определять типы поставляемых документов, уровень качества каждого и процедуры их проверки и утверждения.
Определение типов и содержания документов
Ниже дана схема основных типов программных документов. Данная схема не является исчерпывающей или окончательной, но будет служить контрольной базой основных типов программных документов, которые руководители должны предусмотреть, когда определяют стандартные типы своих документов.
Программные документы можно представить разделенными на; три категории:
1) документация разработки;
2) документация продукции (эксплуатационная документация);
3) документация управления проектом.
Документация разработки
Документы, описывающие процесс разработки программного обеспечения, определяют требования, которым должно удовлетворять программное обеспечение, определяют проект программного обеспечения, определяют, как его контролируют и как обеспечивают его качество. Документация разработки, также включает в себя подробное техническое описание программного обеспечения (программную логику, программные взаимосвязи, форматы и хранение данных и т. д.).
Разработка документов преследует пять целей;
1) они являются средством связи между всеми вовлеченными в процесс разработки. Они описывают подробности решений, принятых относительно требований к программному обеспечению, проекту, программированию и тестированию;
2) они описывают обязанности группы разработки. Они определяют, кто, что и когда делает, учитывая роль программно обеспечения, предмета работ, документации, персонала, обеспечивающего качество, и каждого вовлеченного в процесс разработки;
3) они выступают как контрольные пункты, которые позволяют руководителям оценивать ход разработки. Если документы разработки отсутствуют, неполны или устарели, руководители теряют важное средство для отслеживания и контроля проекта программного обеспечения;
4) они образуют основу документации сопровождения программного обеспечения, требуемой сопровождающими программистами как часть документации продукции;
5) они описывают историю разработки программного обеспечения.
Типовыми документами разработки являются:
- анализы осуществимости и исходные заявки;
- спецификации требований;
- спецификации функций;
- проектные спецификации, включая спецификации программ и данных;
- планы разработки;
- планы сборки и тестирования программного обеспечения;
- планы обеспечения качества, стандарты графики;
- защитная и тестовая информация.
Документация продукции
Документация продукции обеспечивает информацию, необходимую для эксплуатации, сопровождения, модернизации, преобразования и передачи программной продукции.
Документация продукции преследует три цели:
1) она обеспечивает учебную и справочную информацию для любого использующего или эксплуатирующего программную продукцию;
2) она облегчает программистам, не разрабатывавшим программное обеспечение, его сопровождение и модернизацию;
3) она помогает продаже или приемке программной продукции.
Документация продукции должна включать в себя материалы для следующих типов читателей:
- пользователей, которые вводят данные, восстанавливают информацию и решают задачи с помощью программного обеспечения;
- операторов, которые «прогоняют» программное обеспечение на вычислительной системе;
- сопровождающих программистов, которые сопровождают, модернизируют или изменяют программное обеспечение.
Документация продукции может также включать в себя:
- руководства и материалы для руководителей, которые следят за - использованием программного обеспечения;
- вспомогательные материалы, освещающие возможности программной продукции и уточняющие ее функции, условия эксплуатации;
- общую информацию, описывающую программную продукцию для всех заинтересованных лиц.
Типовые документы продукции включают в себя:
- учебные руководства;
- справочные руководства и руководства пользователя;
- руководства то сопровождению программного обеспечения;
- брошюры и информационные листовки, посвященные продукции.
Документация управления проектом
Документы создают на основе информации управления проектом, такой как:
- графики для каждой стадии процесса разработки и отчеты об изменениях графиков;
- отчеты о согласованных изменениях программного обеспечения;
- отчеты о решениях, связанных с разработкой;
- распределение обязанностей.
Определение качества документов
Руководители должны выбирать стандарты, распространяющиеся на уровень качества, соответственно различным типам документов и различным типам проектов и должны определять, как это качество будет достигнуто и поддержано. Понятия качества, применимые к содержанию, структуре и представлению документации:
1) качество содержания можно измерять в элементах точности, полноты и ясности;
2) качество структуры можно измерять легкостью, с которой читатель имеет возможность определить местоположение информации;
3) качество представления должно соответствовать типу проекта. Например, руководство пользователя может иметь форму набора машинописных страниц, скрепленных вместе, или может быть типографской книгой с обширными иллюстрациями, созданной специалистом по графике.
Определение форматов документов
Стандартизованные форматы документов важны для контроля качества документов, для читаемости документов и для облегчения их сопровождения.
Информация может быть представлена в различных форматах. Проектные спецификации, например, могут быть записаны на установленных бланках. Обучение пользователя можно осуществить посредством учебных программ в классах или учебных конспектов. Форматы документов могут различаться от проекта к проекту. Они зависят от таких факторов, как объем проекта, аудитория, для которой предназначены документы, количество установленных стадий и бюджет документирования.
В проектируемых форматах должны быть учтены соображения о том, будут ли документы переводить для международного распространения.
Стандарты и руководства данной организации, распространяющиеся на форматы документов, должны быть установлены таким образом, чтобы допускать гибкость для руководителей в выборе форматов, подходящих для их проектов.
Определение системы обозначения документов
Стандартные обозначения документов необходимы для эффективного контроля документации. Обозначающая информация может включать в себя:
- заглавие документа;
- ссылочный номер документа;
- номер версии документа;
- дату выпуска и пересмотра;
- реквизиты автора;
- реквизиты утвердившего лица;
- обозначение защищенности (авторских прав);
- обозначение организации.
Если документы выпускают в виде разрозненных листов, каждая страница должна иметь индивидуальное обозначение (например, со ссылочным номером документа, номером страницы и номером издания).
Основными ресурсами, требуемыми для документирования, являются следующие: персонал; средства; финансирование.
Персонал
Для процесса разработки программного обеспечения необходимы люди со знанием:
программирования — для разработки программного кода;
сути предмета — для представления информации о применениях программного обеспечения;
документирования — для разработки документации продукции.
Важно, чтобы штат был полностью обучен методам документирования, и чтобы каждая группа полностью понимала и выполняла свою роль в документировании:
- проектировщики программного обеспечения и программисты создают документацию разработки, которая описывает продукцию или ее задачи; они также обеспечивают документацию сопровождения программной продукции;
- специалисты в предметной области обеспечивают информацию для (и могут разрабатывать) части стадий изучения, спецификаций требований, планов тестирования и обеспечения качества, планов сборки программного обеспечения в условиях эксплуатации;
- специалисты по изданию обычно подготовляют документацию по обучению пользователя, а также справочную, информационную о продукции.
Средства
Важно предусмотреть обеспечение задач документирования соответствующими и подходящими средствами. Инструментальные программные средства полезны для подготовки я контроля документации. Они могут быть применены для повышения эффективности многих процессов документирования и использования стандартов данной организации, распространяющихся на документирование.
Финансирование
Важно, чтобы стоимость документирования определяли как отдельные статьи бюджета, так как она нередко составляет значительную часть стоимости разработки программного обеспечения.
Процесс документирования является процессом формализованного описания информации, созданной в процессе или работе жизненного цикла. Данный процесс состоит из набора работ, при помощи которых планируют, проектируют, разрабатывают, выпускают, редактируют, распространяют и сопровождают те документы, в которых нуждаются все заинтересованные лица, такие как администраторы, инженеры и пользователи системы или программного продукта.
Список работ
Данный процесс состоит из следующих работ:
1) подготовка процесса;
2) проектирование и разработка;
3) выпуск документов;
4) сопровождение документов.
Подготовка процесса
Данная работа состоит из следующих задач:
- Должен быть разработан, документально оформлен и реализован план обозначения документов, выпускаемых в процессах жизненного цикла программного продукта. Для каждого обозначаемого документа должны быть определены:
а) заголовок или наименование;
b) назначение;
с) пользователи документа;
d) процедуры и обязанности по подготовке исходных материалов, разработке, проверке, изменению, утверждению, выпуску, хранению, распространению, сопровождению и управлению конфигурацией;
е) сроки выпуска промежуточных и окончательных редакций.
Проектирование и разработка
Данная работа состоит из следующих задач:
- Каждый конкретный документ должен быть спроектирован в соответствии с используемыми стандартами на документацию в части: формата; состава и содержания разделов; нумерации страниц; расположения и оформления рисунков и таблиц; отметок об авторских правах, правах доступа; брошюровки и других элементов представления информации.
- Должны быть подтверждены источник и соответствие исходных материалов для документов. При подготовке документов могут использоваться средства автоматизации документирования.
- Подготовленные документы должны быть проверены и отредактированы в части форматов, технического содержания и стиля представления в соответствии с используемыми стандартами на документацию. Документы перед выпуском должны быть утверждены (согласованы) компетентными лицами.
Выпуск
Данная работа состоит из следующих задач:
- Документы должны быть изданы и распространены в соответствии с планом. При издании и распространении документов могут использоваться бумажные, электронные или другие носители. Оригиналы документов должны храниться в соответствии с требованиями по учету, хранению, защите, обращению и дублированию.
- Средства управления документированием должны быть определены в соответствии с процессом управления конфигурацией.
ГОСТ Р ИСО/МЭК ТО 9294-93 «Руководство по управлению документированием программного обеспечения». Руководство предназначено для применения ко всем типам программного обеспечения — от простейших программ до наиболее сложного программного набора или системы программного обеспечения. Охвачены все типы программной документации, относящиеся ко всем стадиям жизненного цикла программного обеспечения.
Принципы управления документированием программного обеспечения одинаковы для любого объема проекта. Для небольших проектов значительную часть положений, приведенных в данном стандарте, можно не применять, но принципы остаются теми же. Руководители могут адаптировать данные рекомендации для своих конкретных потребностей.
Сопровождение
Данная работа состоит из следующей задачи:
- Должны быть решены задачи, связанные с внесением изменений в документацию. Изменения в документы, находящиеся под управлением конфигурацией, вносят в соответствии с процессом управления конфигурацией.
Особое значение для успешности ПС имеет документация пользователя, т.к. именно она в первую очередь связана с процессом его эксплуатации. Возрастающий масштаб применения программных средств и их сложность вызывает необходимость наличия полной, точной и понятной документации на эти средства, доступной пользователям. Документация пользователя часто рассматривает нечто, разрабатываемое после создания конкретного программного средства. Однако с точки зрения качества разработки программной документации она должна рассматриваться как неотъемлемая часть процесса создания данного программного средства. При надлежащем подходе к данной проблеме требуется достаточно сложная работа по планированию документирования. Целью стандарта ГОСТ Р ИСО/МЭК 15910 «Процесс создания документации пользователя программного средства» является стимулирование разработчиков программных средств к надлежащему использованию процесса документирования. Стандарт также представляет пользователям метод определения надлежащего применения процесса документирования при создании конкретного программного средства. Стандарт определяет минимально необходимый процесс создания документации пользователя всех видов для программного средства, имеющего интерфейс пользователя. Данные виды охватывают печатную документацию (например, руководства пользователя и краткие справочные карты), диалоговую (оперативную) документацию, справочный текст («хелпы») и системы диалоговой документации.
Стандарт по существу является стандартом на процесс. Стандарт не определяет компоновку конкретного документа, его содержание и другие аспекты комплектности документации, однако он устанавливает метод планирования и проведения процесса документирования.
Процесс документирования должен быть выполнен в два этапа в последовательности, представленной на рис.9.1. Цифровые индексы в блоках рисунка соответствуют номерам пунктов стандарта ГОСТ Р ИСО/МЭК 15910 их описывающих и приведены для удобства нахождения их полного описания.
Поэтапные работы не выполняются одновременно. На отдельных этапах работы могут проводиться параллельно. Возможные итерации работ показаны пунктирными линиями.
Заказчик должен обеспечивать документатору доступ:
а) ко всем соответствующим спецификациям, форматам записей, компоновкам экранов и отчетов, выходным результатам работы средств автоматизации программирования и другой информации, необходимой для подготовки документации;
b) к рабочей копии программного средства (при необходимости);
с) к аналитикам и программистам, включая своевременное правильное решение вопросов, возникающих у персонала разработчиков документации;
d) к типичным пользователям (по возможности) для анализа аудитории и тестирования на практичность.
В обязанности документатора входит обеспечение плодотворности контактов с разработчиками программных средств заказчика, гарантирующее как минимум понимание сути выпускаемой продукции и соответствующих ей аудиторий. Документатор не отвечает за разработку, проверку или корректировку исходных материалов, а только за их получение.
Рис. 9.1
Независимо от того, является ли документатор одновременно разработчиком программного средства, заказчик должен обеспечить его копиями всех применяемых стандартов, руководствами по стилям и форматам, а также соответствующими материалами (если они не являются общедоступными). Документатор должен обеспечить данными материалами соответствующий персонал разработчиков документации.
Обязанностью разработчика является обеспечение полноты, правильности и актуальности всех материалов, предъявляемых разработчику на момент их поставки.
Разработчик должен гарантировать, что представление документатору данных материалов не нарушает прав интеллектуальной собственности любой третьей стороны.
Документатор должен предпринять соответствующие шаги по сохранению материалов, представленных заказчиком, обеспечить защиту информации о требованиях заказчика и возвратить все материалы заказчику по завершении проекта документирования.
План документирования должен охватывать следующие вопросы (но не ограничиваться ими):
а) рабочее наименование, назначение, область применения и ограничения по использованию планируемой документации;
b) спецификацию стиля;
с) определение аудитории пользователей;
d) обоснование причин использования документации данной аудиторией и ее целевое назначение;
е) содержание (план-проспект) документации, с оценкой ее постраничного объема, и соответствующие уточнения для других машинных носителей документации;
f) номенклатуру поставки — число печатных копий, наличие электронных копий, форматы дисков и файлов (включая версии программных средств) и откуда они могут быть поставлены;
g) установление собственника авторских прав на документацию и любых других прав собственности. Вопрос прав собственности является сложным. Во всех договорах на документацию должны быть указаны собственники соответствующих прав. При этом может быть указана последующая возможность передачи авторских прав от документатора к заказчику. Передача авторских прав целесообразна при определении места и способа тиражирования документации;
h) методы и средства производства (тиражирования) и используемые версии данных средств;
l) структуру коллектива разработчиков документации и, возможно, плана выбора данной структуры. Конкретные лица привлекаются на различных этапах написания и производства (тиражирования) документации в зависимости от уровня своего опыта и знаний. Например, может быть необходимым хорошее знание автором документируемой системы и опыт в написании документации; для редактора может потребоваться только опыт редактирования, но не знание системы; от компоновщика (оформителя) может не требоваться других знаний кроме знания средств оформления;
m) взаимосвязи (подчиненности) проекта;
n) почасовую загрузку и зарплату персонала;
o) требования к проектным ресурсам, включая информационные и прочие ресурсы, представляемые заказчиком, и срокам их представления;
р) метод передачи документатору информации об изменениях программного средства в процессе его разработки;
r) планы контроля изменений и сопровождения документации (факультативно);
s) планы проверки документации после ее создания;
t) календарное планирование (графики) по контрольным точкам.
При необходимости каждый из пунктов плана должен быть описан для каждого элемента документации.
Полезно также включить в план документирования образцы аналогичной документации, выпускаемой документатором или другими сторонами, чтобы показать ее стили и компоновку.
План документирования должен быть подготовлен и утвержден до начала разработки документации, чтобы гарантировать согласование всеми сторонами поставленных задач и используемых методов. После утверждения плана он должен быть доведен до всех заинтересованных сторон, включая персонал разработчиков документации, а также заказчика и субподрядчиков (например, печатников, наборщиков, переводчиков).
Определение аудитории пользователей
План документирования должен включать определение аудитории(й) пользователей документации, уровня образования, способностей, подготовки, опыта данных пользователей и других характеристик, связанных с содержанием, структурой и использованием документации.
Обычно имеется ряд различных групп пользователей, преследующих различные цели при использовании конкретной документации. Каждый тип пользователей, включая их характеристики и задачи, решаемые ими при помощи документации, должен быть определен отдельно. По возможности персонал разработчиков документации должен организовать встречи с типовыми пользователями в их рабочей обстановке и обследовать их работу.
Первая редакция (проект) должна содержать основную часть документации в соответствии с планом документирования, а также содержание, приложения и словарь (словник, определения). При применении средств автоматического создания указателя каждая его предметная рубрика (индекс) должна ссылаться на конкретные пункты документации. Орфография, пунктуация, стиль и компоновка документации должны соответствовать указанным в плане документирования.
Первый проект документации должен быть проверен заказчиком. Данная проверка предназначена для контроля технической правильности и полноты документации и должна гарантировать соответствие данного проекта заданиям плана документирования. Также проверяют соответствие орфографии, пунктуации, стиля и компоновки документации требованиям плана документирования.
Проект должен быть проверен на соответствие выданным заданиям, указанной аудитории, содержанию и другим характеристикам, согласованным в плане документирования. Перед возвратом первого проекта с комментариями документатору заказчик должен быть уверен, что проект, включая все корректировки, соответствует плану документирования.
Во второй проект документации должны быть включены все изменения, согласованные с заказчиком при проверке первого проекта, а комплектность поставки второго проекта по возможности должна соответствовать номенклатуре поставки, оговоренной в плане документирования.
Минимально должно быть проведено одно тестирование на практичность документации, используемой для выпускаемой версии ПС.
Должно быть определено содержание спецификации стиля документов. В данную спецификацию могут быть включены конкретные стандарты и руководства или приведены ссылки на соответствующие разделы плана документирования. Спецификация должна содержать требования по элементам стиля, принятого разработчиком документации:
- Язык
Должен быть указан язык, на котором составлена документация для конкретной страны.
- Орфография
При необходимости для принятого языка должен быть указан соответствующий орфографический словарь и, по возможности, список исключений из него.
- Грамматика и ее применение
Должны быть приведены рекомендации по грамматике языка и стилю ее применения.
- Компоновка и кегли
- Ориентация (расположение)
Должна быть определена ориентация конкретной страницы документа как книжная (вертикальная) или альбомная (горизонтальная).
- Одно- или двусторонняя печать
- Ширина полей.
- Цвета красок и бумаги
- Разделители
- Схемы нумерации страниц, заголовков, рисунков, таблиц, рисунков и правила их оформления
- Использование сносок или концевых примечаний
- Правила пагинации и плотности документа. Должны быть определены правила пагинации (постраничного разбиения, например, чтобы заголовки не проставлялись в конце страницы) и плотности документа (например, регулирование количества чистых страниц, начальных и концевых висячих строк).
- Стиль текста
Должен быть определен стиль текста уведомлений и предостережений для используемых в документации языков (например, «Стиль основных предложений», «Все буквы заглавные»).
- Электронная документация. Типы справочной информации
В спецификации стиля документации могут быть указаны один или несколько из следующих типов справочной информации:
а) контекстная справка — информация о текущем поле, в котором находится курсор или высвечена программа, включая ее необходимое или целевое (предметное) содержание, ее назначение и потенциальное влияние на работу программного средства;
b) расширенная справка — информация о текущем экране или окне, включая ее назначение и требуемый режим использования;
с) справка о клавишах — информация о применении клавиатуры, функциональном назначении клавиш и их перенаименовании (обозначении);
d) справка о справках — информация об использовании справочной системы в целом;
е) справка о сообщении— информация о том, что пользователь должен или может сделать в ответ на конкретные системные сообщения, например сообщения об ошибках;
f) терминологическая справка— определения конкретных элементов, связей с конкретной тематикой и расшифровка обозначений и сокращений;
g) понятийная справка — справочная информация, выдаваемая системой для предупреждения пользователя об ошибках. Может быть структурирована, чтобы первоначально пользователь получал краткое справочное сообщение, а при повторении той же ошибки — более подробное сообщение, и наоборот, пользователь может получить развернутое сообщение при первой ошибке и краткое — при ее повторении.
- Типы диалоговой (оперативной) документации
В спецификации стиля электронной документации могут быть указаны один или несколько из следующих типов диалоговой документации:
а) руководства или рекомендации пользователя - описывают процедуры по применению продукта;
b) командные справки — определяют синтаксис, результаты и целевое назначение каждой команды (только для команд управления системой);
с) рекомендации по сообщению — определяют, что пользователь должен или может сделать в ответ на конкретные системные сообщения, например сообщения об ошибках;
d) административная информация — информация о конфигурации и защите системы, а при необходимости — о ее инсталляции, предназначенная для администратора системы.
- Подсветка и использование цвета
Должны быть установлены правила использования в электронной документации подсветок выделяемых элементов и использование цветового оформления.
- Правила навигации и использования клавиатуры.
Контрольные вопросы:
Перечислите вспомогательные процессы ЖЦПИ.
Каковы основные работы процесса документирования, и какова их последовательность?
Какие виды документации Вам известны?
В чем суть процесса совместного анализа, и какие работы во время его реализации выполняются?
В чем суть понятия «стиль документирования»?