Практические приемы оценки и повышения качества техдокументации по оценочным элементам фактора «удобство применения» согласно ГОСТ 28195–89. Материал входит в цикл статей «Качество технической документации». Редакция от 11.12.2024.
Создан 27.01.2012 21:43:15
Об удобстве применения:
Совокупность свойств программного средства, характеризующая усилия, необходимые для его использования, и индивидуальную оценку результатов его использования заданным или подразумеваемым кругом пользователей программного средства [из 15 разд. 2 ГОСТ 28806–90]
Следует отметить, что качество технической документации в плане удобства ее применения во многом зависит от качества технического перевода.
Освоение работы ПС
Далее: |
Возможность освоения программных средств по документации
Оценочный элемент возможности освоения программных средств по документации следовало бы разместить в самым последним в метрике, поскольку данный элемент выглядит обобщающим, итоговым, характеризующим возможность освоения ПС в целом.
Возможность освоения ПС на контрольном примере при помощи ЭВМ
Возможность освоения ПС на контрольном примере при помощи ЭВМ... Нынешним программным средствам свойственна широчайшая функциональность, поэтому контрольных примеров для их освоения попросту не напасешься. Сравнительно недавно в моду вошли видеоуроки: разработчик программного средства организовывает себе канал где–нибудь на YouTube, размещает (физически — закачивает) там видеоролики, а в страницы собственного сайта внедряет коды видеообъектов. Пользователю (посетителю) остается только нажать кнопочку вопроизведения.
Такое решение представляется весьма толковым, поскольку изрядное количество публики, в силу особенностей восприятия информации, предпочитает один раз увидеть, нежели сто раз прочесть. Клиповое сознание, как говаривает тащ Задорнов. Автор сказал бы, что скорее скетчевое...
Возможность поэтапного освоения ПС
Чтобы освоить все сразу, надо быть гением, или, в крайнем случае, великим. Кажется, Моцарт, прослушав трехчасовую оперу или симфонию, вернулся домой и тут же полностью воспроизвел ее в нотной записи...
Желающие убедиться в гениальности или величии могут проверить себя, попытавшись перечислить, к примеру, компоненты автоматизированной системы. Автор, хоть и имеет дело с АС почти ежедневно в течение многих лет, спотыкается обычно на 7 или 8–й позиции. Следовательно, не велик 😁
Поэтапность освоения должна подразумеваться по умолчанию, поскольку мало кто может похвастаться совокупностью психологических, психофизиологических, антропометрических, физиологических характеристик и возможностей, требуемых для того, чтобы охватить «все, много и сразу». Закладывать данный оценочный элемент в ГОСТ 28195–89 не имело никакого смысла.
Документация для освоения
Далее: |
Полнота и понятность документации для освоения
См. Полнота пользовательской документации и Понятность пользовательской документации.
Точность документации для освоения
См. Точность пользовательской документации.
Техническое исполнение документации
См. Техническое исполнение пользовательской документации.
Полнота пользовательской документации
Наличие краткой аннотации
Конкретный, но формальный оценочный элемент. Аннотация предусмотрена:
- в типовых проектных решениях по ГОСТ 24.703;
- в программных документах, см. Общие требования к программным документам по ГОСТ 19.105–78;
- в отчете о научно–исследовательской работе по ГОСТ 7.32–2001, только называется в нем рефератом;
- наверняка и еще где–то предусмотрена...
Аннотация может нравиться или не нравиться (с позиции эмоциональной), быть хорошей или плохой (с позиции оценки ее полноты, точности, достаточности, соответствия, краткости — обо всем этом ниже), но если она имеется — получаем единичку, нет — получаем ноль.
Наличие описания решаемых задач
Та же история, что и выше: наличие описания решаемых задач проверяется в описании программы, описании применения и в ряде иных программных документов, но описание может быть как хорошим, так и плохим, может нравиться или не нравиться.
Наличие описания структуры функций ПС
Что понимать под структурой функций? Схему функциональной структуры или что–то иное? Или исходить из того, что функции бывают простые, составные — т.е. обладают определенной иерархией? Непонятно...
Наличие описания основных функций ПС
Трудно себе представить, что в руководстве, инструкции или ином документе возможно отсутствие описания основных функций... Налицо логическое противоречие, поскольку любое изделие, включая программные изделия, для чего–нибудь да предназначено. А коль скоро есть назначение, то есть решаемые задачи и выполняемые функции, которые должны быть детально расписаны.
Другое дело, когда из–за лени или неопытности исполнителя некоторая часть основных функций не упоминается, но это уже вопрос полноты реализации ПС и достаточности описания основных функций.
Но не следует забывать и о том, что исполнитель может оказаться ВРАГОМ НАРОДА или НАЦИОНАЛ–ПРЕДАТЕЛЕМ, а враг, как известно, не дремлет, а еще он хитер и коварен. Поэтому не следует забывать о том, что существуют:
- Недекларированные возможности (программного обеспечения) по Р 50.1.056–2005;
- Недекларированные возможности по ГОСТ Р 53114–2008;
- Недекларированные возможности по РД ГТК Защита от НСД. ПО СЗИ. Классификация по уровню контроля отсутствия недекларированных возможностей;
- Программные закладки по РД ГТК Защита от НСД. ПО СЗИ. Классификация по уровню контроля отсутствия недекларированных возможностей;
- и еще много различных тайных подлостей.
Даже если речь не идет о защите информации от (иностранной) разведки по ГОСТ Р 50922–2006, то надо помнить о вирусописателях и вирусологах (есть мнение, что это одни и те же люди — и тоже враги народа). Все они обогащаются на публике, которая по недоумию или лени не перешла еще на операционные системы, разрабатываемые как свободное программное обеспечение.
Наличие описания частных функций
См. выше.
Наличие описания алгоритмов
Пункт правильный, наличие проверяется в документах:
- описание алгоритма (проектной процедуры) по РД 50–34.698–90;
- описание программы по ГОСТ 19.402–78;
- и в ряде других документов.
Наличие описания межмодульных интерфейсов
Необходимо, если заказчику интересно самому заниматься сопровождением программы. Если программа является товаром народного потребления, то описание межмодульных интерфейсов представляется избыточным.
Наличие описания пользовательских интерфейсов
Наука выделяет два основных вида пользовательских интерфейсов:
- графический интерфейс пользователя;
- интерфейс командной строки.
Графический интерфейс пользователя представлен на рисунке ниже.
В данном варианте интерфейса, представленном в виде мегаменю, описывать нечего, поскольку меню развернуто на все три уровня вложенности, все видно и так. Если речь идет об интерфейсе какой–либо прикладной программы, то придется изрядно потрудиться. Чтобы не перегружать без того большущую статью, сошлемся на книжку «Автоматизация разработки технической документации с применением AuthorIT. Учебное пособие», в которой пользовательский интерфейс программы AuthorIT расписан очень подробно.
Ниже показан интерфейс командной строки с описанием синтаксиса команд и их параметров. Комментарии, наверное, излишни.
Поскольку название оценочного элемента сформулировано неоднозначно, стоит подстраховаться. А вдруг разработчики ГОСТ 28195–89 имели в виду не столько описание функционала программы, привязанного к интерфейсу, а описание элементов интерфейса, т.е. всяких кнопочек, флажков, текстовых полей и т.д.? Тогда, наверное, имеет смысл заглянуть по ссылкам:
- microsoft.com/Language/ru–ru/Terminology.aspx;
- microsoft.com/Language/ru–ru/StyleGuides.aspx.
Наличие описания входных и выходных данных
Во время оно, когда программы были преимущественно расчетными, вводились данные, являющиеся исходными для какой–либо задачи, а выводились результаты. В настоящее время данные вводятся в элементы графического интерфейса пользователя, в котором метки (названия) полей ввода представляют собой краткое описание входных данных, см. Наличие системы контроля полноты входных данных.
Примеры с поисковой системой Яндекс показаны на рисунках. Входными данными является информационный запрос, выходными — результат поиска.
С выходными данными ситуация аналогичная. Описания входных и выходных данных (программы) должны быть в документах:
- описание программы;
- описание применения;
- и в ряде других документов.
Наличие описания диагностических сообщений
Наличие описания диагностических сообщений... Диагностические сообщения программы формируются в ходе технического диагностирования встроенными средствами технической диагностики согласно алгоритму диагностирования в рамках диагностической модели. Диагностические сообщения должны быть описаны в:
Наличие описания основных характеристик ПС
Поиск по заголовкам документов обнаружил лишь характеристики качества программного средства. Полнотекстовой поиск по содержимому документов обнаружил множество других характеристик программы, упомянутых в техническом задании, в описании применения и в ряде других программных документов. Вот в них и придется задавать требования и проверять наличие описаний основных характеристик ПС.
Наличие описания программной среды функционирования ПС
Поиском в двух используемых совместно ГОСТах обнаружено целых две среды:
Какая именно из сред имеется в виду в данном оценочном элементе – науке неизвестно, поэтому придется рассмотреть «обе две».
Определение среды функционирования по ГОСТ 28195–89 ввело автора в ступор. Было просмотрено множество сетевых ресурсов, найдена официальная бумажная версия ГОСТ 28195–89 — текст оказался аутентичным... Попутно выяснилось, что одним из заместителей руководителя Росстандарта является Евгений Петросян 😁 За разъяснениями пришлось обратиться к филологу, приговор был таков:
«Здесь можно указать на две ошибки.
Первая (или вторая) — стилистическая:
Неправильное использование предложной конструкции, искажающее смысл фразы. «При сохранении» означает: «если они сохраняют», «при условии, что они сохраняют», «когда они сохраняют».
Вторая (или первая) — семантическая:
Использование слова без учета его семантики. Глагол «сохранять», от которого образовано отглагольное существительное «сохранение», означает «продолжать оставаться в каком–либо состоянии, положении; не утрачивать, не лишаться каких–либо свойств, качеств» (Современный толковый словарь русского языка Т.Ф. Ефремовой).
В данной фразе, исходя из контекста, должен использоваться глагол со значением «пребывать», «находиться».
Поэтому необходимо (следует, уместно, целесообразно) заменить указанную конструкцию «при сохранении ими работоспособного состояния» на «находящихся (пребывающих) в работоспособном состоянии»».
Определение среды функционирования программного средства по ГОСТ 28806–90 прозрачно. Задавать требования по наличию описания программной среды функционирования следует в техническом задании, искать описания — в описании программы и в ряде других документов. А еще лучше воспользоваться материалами статьи Как писать руководство пользователя? Часть I, создать единый, не входящий в ГОСТ 19–й системы, интегрированный документ «Руководство пользователя», чтобы нигде и никогда ничего больше не искать.
Достаточность документации для ввода ПС в эксплуатацию
Достаточность документации для ввода ПС в эксплуатацию определяется, в первую очередь, испытаниями, в частности, приемосдаточными испытаниями, после проведения которых принимается решение о вводе в эксплуатацию, вводе в действие, если речь идет об АС, или внедрении (если речь идет о программе). Состав документации регламентируется требованиями к программной документации, изложенными в программе и методике испытаний, решение принимает приемочная комиссия, которая может быть, как и испытания, государственной, ведомственной и межведомственной.
Наличие информации технологии переноса для мобильных программ
Наличие информации (о?) технологии переноса для мобильных программ: в настоящее время практически все языки высокого уровня оснащены возможностями компиляции исходных модулей программ как для работы их под управлением различных операционных систем, так и на различных аппаратных (корректнее — технических) платформах.
ПО с открытым кодом можно скачать в виде исходников, а затем скомпилировать его на локальном компьютере. Можно установить уже готовые (скомпилированные) исполняемые программы для Linux, Mac, Windows и иных операционных систем. Кроме того, в Linux имеются программы–эмуляторы VirtualBox, Wine, PlayOnLinux и множество других, реализующих мобильность «на лету», в режиме реального времени. Данные программы обеспечивают возможность инсталляции и выполнения windows–программ в операционной среде Linux.
Таким образом, информация о технологии переноса для мобильных программ во многом утратила свою актуальность.
Точность пользовательской документации
Соответствие оглавления содержанию документации
Налицо очередная нестыковка с ГОСТ 2.105: оглавление в нем именуется содержанием, что не есть хорошо, поскольку под содержанием понимают еще и информационное наполнение документа — текст, графику, таблицы и проч. — все то, что размещается внутри разделов, подразделов, пунктов и подпунктов документа. С ГОСТ 19.106 нестыковка тоже есть, см. здесь. Содержание неплохо было бы заменить содержимым.
Как уже упоминалось в подразделе Навигация в электронных документах одной из предшествующих статей цикла, содержание гарантированно будет соответствовать структуре разделов и проч. документа в том случае, когда оно собирается из них автоматически. Многие, зная об этом, продолжают собирать содержание вручную 😉 Поэтому при малейшем несоответствии следует ставить нулевую оценку.
Оценка оформления документации
Оформление может нравиться или не нравиться — дело вкуса, если воспринимать оценочный элемент не слишком буквально. Если подойти вдумчиво, то элемент является обобщающим и итоговым. Т.е. если оформление документации по всем прочим оценочным элементам оформления зарабатывает единицы, то и итоговый потянет на единичку. Но лучше было бы просуммировать баллы...
А вообще это задача нормоконтролера.
Грамматическая правильность изложения документации
Оценка — задача литературных редакторов и корректоров, но никак не всяческих «чекеров». Опять же нет ясности, как оценивать? Разработчики ГОСТ 28195 могли бы придумать формулу для оценки, например в виде отношения числа грамматических ошибок к общему числу слов (состоящих более чем из двух букв) в документе... И, если это отношение не выходило бы за определенные пределы, можно было бы смело ставить единичку.
Отсутствие противоречий
Противоречие — несогласованность, антоним согласованности. См. также Отсутствие ненужных повторений. Было бы неплохо применить расчетный метод оценки, поскольку одно или несколько противоречий погоды не делают, но когда их десятки и сотни...
Случай из жизни: в 2007 году некая организация, расположенная в т.н. «хаммеровском центре», выставила подрядным организациям методику проведения предпроектного обследования неких энергообъектов. Представитель подрядчика — метролог по образованию, очень грамотный и дотошный — выдал на пятидесятистраничный документ свыше трехсот замечаний по существу! Надо было видеть лица разработчиков методики... Это было такое позорище...
Отсутствие неправильных ссылок
Под неправильными ссылками, судя по всему, следует понимать ссылки, ведущие не туда, куда надо, а то и вовсе в никуда... Предпочтителен расчетный метод.
Ясность формулировок и описаний
«Ясность — характеристика термина (понятия) с точки зрения определенности, отчетливости его смысла. Понимание термина, успешная его интерпретация предполагают знание его смысла и его денотации, т. е. класса тех объектов, к которым он отсылает. Если этот класс является четко очерченным и слагается из хорошо специфицированных объектов, о термине говорят, что он точен (см. Точность). Если смысл термина определен отчетливо и однозначно, термин называется содержательно ясным или просто ясным...
Я. противостоит неясность. В случае неясного термина трудно решить, какие именно признаки мыслятся в его содержании и какие из них являются существенными...
Я., наряду с однозначностью и точностью, является одним из основных требований к научному языку. Но хотя наука и представляется сферой наиболее прозрачного и осмысленного употребления языка, абсолютная прозрачность смысла недостижима даже здесь. Это связано прежде всего с постоянным развитием и углублением научного знания, его изменчивостью и незавершенностью.
Словарь по логике. — М.: Туманит, изд. центр ВЛАДОС. А.А.Ивин, А.Л.Никифоров. 1997»
Все гладко у господ логиков, только вот словечко отсылает слегка смущает. Что звучит благопристойнее, послать по электронной почте или отправить электронной почтой? Виды переменных или типы переменных? Мрачный тип, скользкий тип...
Формулировка (описание) становится ясной, если... Пожалуй, имеет смысл сослаться на Как писать «прозрачный» и понимаемый текст технической документации вообще?, чтобы полностью определиться с ясностью. И применять расчетный метод оценки по отношению числа неясных формулировок и описаний к их общему числу.
Отсутствие неоднозначных формулировок и описаний
Правильность использования терминов
Использование тоже какое–то нехорошее слово, см. Ясность формулировок и описаний. «Я тебя любила, а ты меня использовал!» Есть же синоним применение, наиболее применимый применительно к стилю изложения...
Термины желательно не просто применять, но еще и раскрывать. Ведь от обычной ссылки на ГОСТы (что–то такое по ГОСТ такому–то) положительных эмоций ожидать не приходится. Скорее наоборот: читающему придется перелопатить кучу стандартов, разыскать термин, прочесть его определение... Зачем издеваться над людьми?
Пример правильного применения терминов приведен здесь.
Краткость, отсутствие лишней детализации
Краткость, как известно, сестра таланта, но враг гонорара... Лишней детализации не бывает, детализация должна проводиться вплоть до атомарного уровня, см. здесь.
Другое дело, когда в самых первых общих разделах документа стремятся рассказать о предмете все, свалить информацию в одну кучу, напрочь забывая о том, что существует дедукция как подход к изложению материала от общего к частному. Не следует в подразделе о назначении программы или автоматизированной системы расписывать их полный функционал, достаточно ограничиться кратким перечнем задач, решаемых программой или АС, а для полного описания функционала специально предусмотрен п. Требования к функциям (задачам), выполняемым системой.
Единство формулировок
Единство формулировок сродни единству терминологии, см. Наличие описания программной среды функционирования ПС, а также Проверка терминологии и обозначений физических величин.
Единство обозначений
Единство обозначений: речь, судя по всему, идет об исключении применения синонимов для одного и того же понятия, как требует п. 4.2.3 ГОСТ 2.105.
Отсутствие ненужных повторений
Стилистика хромает, но смысл понятен.
«4.2.2 Текст документа должен быть кратким, четким и не допускать различных толкований.
При изложении обязательных требований в тексте должны применяться слова «должен», «следует», «необходимо», «требуется, чтобы», «разрешается только», «не допускается», «запрещается», «не следует». При изложении других положений следует применять слова — «могут быть», «как правило», «при необходимости», «может быть», «в случае» и т.д.
При этом допускается использовать повествовательную форму изложения текста документа, например «применяют», «указывают» и т.п.
В документах должны применяться научно–технические термины, обозначения и определения, установленные соответствующими стандартами, а при их отсутствии — общепринятые в научно–технической литературе.
Если в документе принята специфическая терминология, то в конце его (перед списком литературы) должен быть перечень принятых терминов с соответствующими разъяснениями. Перечень включают в содержание документа [из 4.2.2 ГОСТ 2.105–95]»
Слово ненужных следовало бы заменить на излишних, избыточных и т.п.
Повторения часто предусмотрены самой структурой документа. Так, к примеру, одной из подхарактеристик качества программного средства является его защищенность от несанкционированного доступа. Требования к качеству ПС формулируются в п. Требования к программному обеспечению технического задания, а требования к защищенности — в п. Требования к защите информации от несанкционированного доступа. Вот и повторение, только необходимое или вынужденное.
Наличие нужных объяснений
Слово нужных следовало бы заменить на необходимых, требуемых.
Понятность пользовательской документации
Оценка стиля изложения
«Возвращаясь к напечатанному» — см. Отсутствие ненужных повторений. Тут, пожалуй, пригоден только экспертный метод.
Дидактическая разделенность
Автор, благодаря литературному редактору, знает, о чем идет речь, но ни за что никому не расскажет, поскольку параллельно с подготовкой цикла статей О качестве... проводится разработка методики оценки качества технической документации, которая будет стоить немалых денег.
Формальная разделенность
Что понимать под формальной разделенностью? Разделенность текста на структурные элементы, как здесь?
Ясность логической структуры
Логическая структура определяется требованиями ГОСТов к структурам и содержанию соответствующих документов и может считаться ясной по умолчанию. Т.е. проверять надо структуру и содержание на соответствие требованиям ГОСТов.
Соблюдение стандартов и правил изложения в документации
Данный оценочный элемент, как Возможность освоения программных средств по документации, Достаточность документации для ввода ПС в эксплуатацию и Оценка оформления документации, следует считать обобщающим.
Оценка по числу ссылок вперед в тексте документов
Ух... Ссылка вперед — это хорошо или плохо? В понимании автора — роскошно, если ссылка вперед содержит текст вида «детальные сведения о том–то приведены в подразделе таком–то». Строго соблюдается Краткость, отсутствие лишней детализации, а как улучшается навигация в документах, особенно бумажных! См. Пути улучшения навигации в бумажных документах.
Техническое исполнение пользовательской документации
Наличие оглавления
Очередной повтор, см. Соответствие оглавления содержанию документации.
Наличие предметного указателя
Комментировать нечего — либо наличие, либо отсутствие. Отсутствие, наверное, плохо, наличие — хорошо.
Наличие перекрестных ссылок
По аналогии с п. Оценка по числу ссылок вперед в тексте документов, только оценка пусть остается экспертной.
Наличие всех требуемых разделов
Наличие всех требуемых разделов определяется разработчиком, см. здесь, здесь, руководство оператора, руководство программиста, руководство системного программиста... Достаточно, наверное.
Нюанс состоит в том, что разработчик себе не хозяин в полном смысле слова, см. здесь... Состав требуемых разделов разумнее согласовать с заказчиком. Тогда проверять их наличие и «требуемость» будет легко и просто.
Соблюдение непрерывности нумерации страниц документов
Обеспечивается элементарно любыми текстовыми процессорами. Но пролистать документ не помешает, поскольку порой бывают и сбои нумерации. Автор пару раз сталкивался с подобным при конвертировании документа ворд в формат pdf.
Отсутствие незаконченных разделов абзацев, предложений
Точно, ибо нельзя безжалостно наступать на горло собственной песне, да еще и на полуслове. Проверять следует обязательно, поскольку автор, трудясь несколько лет тому назад главным экспертом в одной из электроэнергетических компаний, и не такого насмотрелся, проверяя документы, поступающие от субподрядных организаций (субчиков) 😁
«Мастеров художественного слова» великое множество. Вроде технически грамотные люди, но умудряются киловатты делить на часы, автоматизировать автоматизированные системы, указывать целью работы подписание акта завершения работ заказчиком... Не зря говорят: «Цирк уехал, клоуны остались...».
Наличие всех рисунков, чертежей, формул, таблиц
Наличие всех рисунков, чертежей, формул, таблиц проверяются по перечням, которые генерируются автоматически, см. pdf–версию статьи Улучшение навигации в бумажных документах.
Наличие всех строк и примечаний
Строк чего? Примечаний каких?
Логический порядок частей внутри главы
О каких частях и главах идет речь? И о каком порядке? Главы и части глав ни ГОСТ 2.105, ни ГОСТ 19.106 не предусмотрены, предусмотрены разделы, подразделы, пункты, подпункты и перечисления, а логический их порядок регламентируется стандартами, определяющими требования к структуре (составу) и содержанию конкретных документов.
Прослеживание вариантов пользовательской документации
Наличие полного перечня документации
Для проверки полного перечня документации существуют ведомости.
Эксплуатация
Уровень языка общения пользователя с программой
Уровень языка общения пользователя с программой. Если тайный замысел разработчика ГОСТ 28195 понят автором правильно, то наивысшим уровнем языка взаимодействия пользователя с программой или техническими средствами является естественный для пользователя язык... Требование может быть сформулировано в подразделе Требования к лингвистическому обеспечению технического задания.
Легкость и быстрота загрузки и запуска программы
Современные программы загружаются быстро (с шустрых носителей данных, а не с магнитных лент (последовательный доступ к данным), и при наличии достаточного объема оперативной памяти), запускаются легко двойным (а то и одинарным) нажатием левой кнопки мыши.
Легкость и быстрота завершения работы программы
См. выше.
Возможность распечатки содержимого программы
Если исходный код программы является открытым, то какие могут быть проблемы с распечаткой? Если программа заказная, то содержимое ее может иметь место в тексте программы.
Возможность приостанова и повторного запуска работы без потерь информации
Практически все прикладные программы периодически приостанавливаются, ожидая продолжения диалога с пользователем. Перестали набирать текст — Microsoft™ Word приостановился и ждет.
Большинство клиентов ftp при обрыве связи приостанавливаются, а при восстановлении связи продолжают скачку данных с точки приостанова, разумеется, без потерь.
Управление меню
Далее: |
Соответствие меню требованиям пользователя
Кто ж спросит пользователя, если он не является заказчиком или представителем заказчика? А вообще любые соотвествия проверяются при проведении испытаний приемочной комиссией, см. Достаточность документации для ввода ПС в эксплуатацию.
Возможность прямого перехода вверх и вниз по многоуровнему меню (пропуск уровней)
В графическом интерфейсе пользователя подобные переходы осуществляются легким движением мыши, поскольку большинство современных меню построено с применением jscript, позволяющим обходиться без лишних перезагрузок страниц, см. Наличие описания пользовательских интерфейсов. С интерфейсом командной строки несколько сложнее, но и в нем предусмотены возвраты кнопками вверх и вниз клавиатуры.
Функции HELP
Далее: |
Возможность управления подробностью получаемых выходных данных
Примером может служить простой и расширенный поиск информации, см. рисунок ниже.
Достаточность полученной информации для продолжения работы
Тут все очевидно.
Управление данными
Обеспечение удобства ввода данных
См. Наличие описания пользовательских интерфейсов и Наличие описания входных и выходных данных.
Легкость восприятия
См. Полнота и понятность документации для освоения.
Рабочие процедуры
Далее: |
Обеспечение программой выполнения предусмотренных рабочих процедур
Без комментариев...
Достаточность информации, выдаваемой программой для составления дополнительных процедур
То же.
Выводы по IV части
Наблюдается некоторое нарушение иерархии: как метрика Документация для освоения оказалась на одном уровне с метриками полноты, точности, понятности и технического исполнения? Это первое. Второе — для большого количества элементов целесообразно применение расчетных, а не экспертных методов.
Продолжение следует.