Требования | О критериях качества
Содержание
Понятие о показателях эргатической эффективности
Понятие о показателях технической эффективности
Возможны разные состав и структура критериев оценки решения той или иной задачи (в частности, в зависимости от того, является ли результатом решения материальное изделие или плоды умственного труда в виде документов, инфопрогов). Так, для инфопрогизделий пользуются, скажем, оценочной формой, представленной в этом инфордоке.
Мы будем здесь структурировать требования к предполагаемому результату использования данного веб-ресурса – инфопрограммно-методическому комплексу – следующим образом.
Прежде всего определяем системотехническое назначение — структурируемое в различных аспектах.
Далее устанавливаем группы показателей эффективности в корректном смысле — т.е. как отношения позитивных результатов пожицикла изделия (факторов, продуцируемых при его создании, применении, утилизации) к негативным.
Существуют различные профессиональные системы показателей оценки, но мы здесь введём краткую; после каждой группы критериев даются их качественные определения.
Назначение м.б. структурировано:
по сущности — на целевое (ЧТО делается) и функциональное (КАК делается);
по порядку реализации — на главное/вспомогательное;
по роли в пожицикле — на орудийное (как средства труда) и креативное (как предмета труда).
Последнее имеет в виду, что в ходе пожицикла любой искусственный объект обнаруживает несоответствие неким «идеальным», предельным требованиям, предъявляемым к нему. Грубо говоря эти требования можно выразить как «решать все возникающие проблемы как можно дольше без существенных усилий/вложений для замены или сопровождения». Как следствие, возникает желание усовершенствовать этот объект — и он начинает выступать уже и как предмет, отправная точка творческих усилий (причём не только — и часто не столько — разработчика и/или профессионального сервисника).
Эффективность можно структурировать на:
техническую — изделия как «вещи в себе»;
эргатическую — изделия как предмета и орудия труда персонала разработки, эксплуатации, утилизации.
Техническая эффективность изделия в корректном смысле понимается как способность функционировать в заданном окружении при нормальных условиях эксплуатации, выдавая качественный результат по назначению и при этом минимально (приемлемо) продуцируя негативные факторы для персонала и внешней среды;
Эргатическая эффективность изделия понимается как обеспечение за счёт его свойств максимальной (приемлемой) гарантоспособности совокупного работника, в реализации заявленного (установленного) назначения.
Среди критериев можно выделить общие для любого изделия (в нашем случае — программного приложения) и частные (специфические для конкретного назначения).
Важно понимать также, что требования даже к конкретному изделию невозможно установить «раз и навсегда». Выработка значений показателей эффективности, а часто — и их состава — процесс динамический, обычно итеративный.
Понятие о показателях эргатической эффективности
Общими показателями эргатической эффективности инфопрога м.б. такие, как:
Эргономическая эффективность интерфейса, т.е. диалогов и рабочих форм.
Типовые диалоги (для часто выполняемых техопераций) д.б. логично и просто организуемыми через ГИП, а рабочие формы (окна документа и диалога ГИП, форматы объектов) удобными и естественными для предметной области носителя знаний.
В случае широкого применения естественность относительна и часто может пониматься просто как следование общим правилам построения форм; плюсом будет предоставление наряду с этим пользователю удобных средств настройки символических форматов интерфейсных объектов.
Когнитивная эффективность как степень сокращения умственных усилий на освоение и эксплуатацию изделия за счёт его символически-информационных свойств (по /2, Гл.20/ - «знакового обеспечения»).
Для инфопрогизделий в основе когнитивной эффективности лежат наличие и продуманность справки, как обособленной (дополняющей, а часто заменяющей традиционное руководство по эксплуатации), так и оперативной (контекстной).
Качественная справка должна не просто отвечать на вопросы, возникающие у пользователя по ходу работы (это одна из основных функций для её контекстной компоненты), но способствовать быстрому формированию комплексных навыков эффективного применения изделий (примерно это ныне называют модным словечком «компетенции») и дальнейшему устойчивому развитию этих навыков по мере обновления характера и сложности задач, смены предметной области.
Для этого имеет смысл исходить из «правила братьев Стругацких»: инструкция – это для тех, кто ещё не умеет; иначе говоря, в рациональном описании должны отражаться законченные фрагменты работы с изделием и так, чтобы человек понял их внутреннюю логику и закономерности взаимосвязи в зависимости от характера работы и мог затем организовать её по своему усмотрению в изменяющейся обстановке применения.
Один из путей для этого – встраивание сценариев типичных операций в виде т.н. мастеров – часто применяется, но ограничивает пользователя, иногда чересчур укрупняя законченные техоперации и сужая их множество, тем самым усложняя «сборку» из них произвольного техпроцесса. Другой путь – рассмотрение в справке сквозных примеров работы с изделием от начала до конца; но кроме этого, надо ещё рационально составлять описание собственно возможностей изделия; простое перечисление команд уже недостаточно.
Возможный путь повышения когнитивного качества инфопрогизделий указывают нормативы СМК ИСО900Х. В них определены как вид НТД рабочие инструкции (РИ) по конкретным трудовым процессам. Подобную инструкцию можно составить для процесса применения изделия (инфопрога); по сути, в терминах /7/ она служит руководящим методическим материалом (РММ). Как правило, для подготовки необходима переработка справки инфопрога и эксперименты с ним для выявления умолчаний, косвенных определений, неявных связей материала и т.п. Для нашего случая можно рассматривать выполнение техопераций формализации знаний.
Функциональная гарантоспособность как выполнимость любой функции (команды) изделия при конкретных конфигурации и параметрах окружения, условиях внешней среды, считаемых нормальными.
Для массовых изделий вместо выполнимости часто задаются, наоборот, требованиями разработчика к окружению. Тем самым отчасти гарантоспособность подменяется технической эффективностью.
Целевая гарантоспособность как отсутствие трудно обнаруживаемых и устраняемых уязвимостей изделия (применительно к инфопрогам – программного кода и массивов данных) от несанкционированного доступа, ошибочного или стихийного внешнего воздействия (в т.ч. от неожиданных изменений внешних условий), внутренних отказов и сбоев, т.н. недекларированных (не соответствующих явно указанному назначению изделия) возможностей (НДВ) его использования, создающих угрозу обрабатываемым данным и иным средствам автоматизации (оборудованию, другим приложениям, системе в целом), а также человеку.
Уязвимости и НДВ инфопрогизделий широкого применения, как правило, связаны прежде всего с недостатками технологии программирования и несовершенством спецификаций (техзадания), а также с порочностью заложенной концепции построения программного кода. Подобные пороки отмечаются прежде всего у объектно-ориентированного подхода1 и обычно усугубляются его массовыми реализациями (коммерческими и учебно-демонстрационными средами программирования) так, что исправить их за счёт определённого написания (оптимизации) исходного текста чересчур сложно, а порой и невозможно.
Изделия спецназначения, конечно, проходят специальную проверку по установленным правилами силами специалистов (прежде всего – организаций, уполномоченных на деятельность в сфере информатической безопасности2), но поскольку их функционирование неотделимо от поддерживающей ОС, а для неё как изделия часто характерны те же недостатки, то должный уровень гарантоспособности в этих случаях достигается установкой также специально разработанных ОС (или приспособленных изданий массовых ОС), которые чаще всего широкому потребителю недоступны.
Тестирование массовых, тем более некоммерческих инфопрогов фактически возлагается на пользователей. Именно это мы должны полагать наиболее вероятным и для РДП-систем.
Поддержка как приложения, так и пользователей в процессе эксплуатации; подразделяется на встроенную в изделие и текущую — как услуги разработчика и/или сторонних лиц, организаций.
Поддержка требует решения как текущих проблем эксплуатации, так и задач развития изделия. При этом выделяются (как создателями, так и пользователями) более и менее настоятельные вопросы, первоочередные и перспективные задачи развития. Необходима также действенная обратная связь (через развитые инфокоммуникации); желательно и наличие среди участников процесса квалифицированных пользователей, способных ставить вопросы ближе к терминам ИТ-сферы, учитывая когнитивно-эргономический аспект.
В нашем случае эта задача облегчается тем, что сама цель РДП-систем включает развитие этого аспекта и поддержана необходимым уровнем знаний разработчиков. Это в идеале — реально достаточно, чтобы создатели РДП-изделий как можно быстрее и лучше учились на собственном опыте и воспринимали оценки результатов пользвания (в т.ч. и других аналогичных изделий).
Поддержка некоммерческого изделия определяется, конечно же, доброй волей разработчика, поэтому предложения по развитию вряд ли можно ставить ультимативно. Тем не менее и в этом случае ранжированные проблемы и задачи уместны, т.к. служат ориентиром для других разработчиков, в т.ч. потенциальных.
Степень поддержки процессв разработки/утилизации, в т.ч. открытости для независимого анализа и модернизации, повторного использования частей изделия и/или применённых в нём оригинальных решений.
При открытости исходного кода и форматов данных приложений облегчается поддержка и развитие изделия; фактически возможно образование широкого сообщества разработчиков и постановщиков задач (спецификаторов) изделия. Также лучше обнаруживаются и устраняются уязвимости исходного кода и/или структур данных.
Эта задача решается в случае РДП-изделий относительно просто — нужно лишь по мере готовности переводить разработку в среду самого изделия. Так разработчик может одновременно сам оценить удобство процесса и, предложив «описание инфопрогизделия в самом себе» другим, получить наиболее объективные (в идеале) внешние оценки.
Среди частных критериев эргатической эффективности инфопрога можно выделить:
сценарные языки (управления заданиями на выполнение) и показатели их реализации;
наличие модулей расширения для работы с нужными типами содержания, не поддержанными внутри, и качество их работы в сравнении с аналогичными внешними приложениями;
удобство интерфейса со внешними приложениями для отсутствующих функций (обычно через меню конфигурации должен настраиваться автоматический вызов для заданных типов файлов);
Для ИСП формализации знаний можно выделить такие специфические критерии, как:
Поддерживаемые стандарты ЯПЗ, глубина и корректность их реализации.
Вопрос о реализации ЯПЗ – это прежде всего вопрос, представляем мы только форму (символический вид) модели, или также её содержание. Если предполагается первое, то достаточен язык форматирования графики, текста и таблиц; если второе, то требуется определить состав и структуру языков по назначениям, а затем и требования к каждому языку. Об этом подробнее см. /3, п/р 5.3/.
Удобство отображения моделей как документов.
Возможны разные концепции отображения моделей в форме как видеограмм (на экране и иных сигнальных носителях), так и машинограмм (в твёрдых копиях и на иных знаковых носителях). На практике следует руководствоваться собственным опытом и мнением квалифицированных пользователей.
Возможности анализа моделей.
В отношении анализа предполагается, что РДП-система (среда) по крайней мере проверяет сочиняемые схемы на правильность.
Возможны более сложные виды анализа частных моделей; однако встаёт вопрос о теоретической основе такого анализа. Если для деклар-знания имеется аппарат реляционной алгебры, из которого следует система т.н. нормальных форм структуры данных как иерархия приближения структуры отношений между элементами данных к информатически реализуемой (содержащей только отношения вида 1:1 и/или 1:N/M:1), то применительно к импер-знанию, возможно, нужно ещё определить цели и методы анализа структур деятельности (маршрутов визуалов и дракон-моделей). Свои цели и критерии анализа возможны и для элементной компоненты частных моделей.
К общим показателям качества прогязыков высокого уровня как искусственных и предназначенных одновременно для человека и машины-исполнителя, можно отнести:
ясность для сочинителя (человека) механизмов языка, обеспечивающая когнитивность построения и описания программ;
«прозрачность» для исполнителя (информашины), позволяющая доказательно строить и формально верифицировать программы — т.е. ожидать от их исполнения формально определённых результатов;
«неизбыточная» (минимально необходимая) сложность языковых средств.
Один из базовых результатов этого - корректность использования ОП (прежде всего оперативного ЗУ для хранения модифицируемой/перемещаемой части данных - кода и/или операндов); в памяти при передаче между программными единицами и внутри них данные не должны меняться, а при переработке — не должны произвольно, «непрозрачно» передаваться.
В целом можно сказать — эргатическая эффективность — это когда изделие (инфопрограммное в частности) «неизбыточно сложно» для человека, который сталкивается с ним и/или с продуктами его производства.
Уровень эффективности инфопрога может считаться приемлемым, если он выполняется без перенастройки (доработки) на массовых конфигурациях платформ и м.б. связан по данным (входным и выходным файлам и/или массивам) с другими изделиями, обычно необходимыми по действующей технологии применения (в нашем случае – по той или иной разновидности ТФЗ); подразумевается, что запуск в работу осуществляется оператором, а окончание работы – как вручную, так и автоматически (по завершении детерминированной последовательности действий, т.н. сценария применения). При оптимальном уровне инфопрог должен допускать пользовательскую настройку конфигурации (способов и параметров выполнения функций, включая форматы данных) под окружение в достаточных пределах и расширение (замену) функций по заданию пользователя, иметь возможность определения сценариев применения как полноценных алгоритмов, связи по командам с другими изделиями (т.е. быть вызываем ими и вызывать их сам автоматически в рамках неких сценариев). Адаптивный уровень подразумевает, что инфопрог распознаёт ситуацию применения в динамике и, как правило, способен либо сам настраивать параметры имеющейся конфигурации, либо находить возможности её расширения (обновления).
Взаимодействие инфопрогов по данным реализуется различным образом. Одно направление – расширение круга форматов, как входных (открываемых файлов), так и выходных (сохраняемых файлов). Другое – возможность оперативного переноса данных (в первую очередь через карманы в ОП, т.н. буферы обмена) за счёт унификации определений форматов. Оптимизация часто реализуется путём введения возможности работы со внешними модулями (т.н. плагинами) переменного состава.
Очевидно, адаптивный уровень вряд ли достижим в ближайшее время в широко применяемых изделиях поддержки формализации знаний; примером достижения этого уровня среди массовых изделий, конечно, служат некоторые защитные средства (антивирусы, брандмауэры и т.п.).
Эргатическая эффективность зависит от технической; её показатели качества рассмотрим далее.
Понятие о показателях технической эффективности
Техническая эффективность изделия (инфопрограммного в частности) м.б. оценена по следующим родам показателей:
функциональность – выполнение конкретных функций, вытекающих из целевого назначения результата, с заданной производительностью как по объёмам, так и по типам результата;
экономичность – обеспечение минимальных затрат труда в полном жизненном цикле, как реального (живого и машинного), так и абстрактного в виде различных ценностных эквивалентов;
сбалансированность – согласованность характеристик взаимодействия компонентов изделия между собой и со внешней средой по объёмам (потокам вещества, энергии, данных), динамике и свойствам потоков;
Применительно к т.н. сенсорным, человеко-машинным каналам взаимодействия важен баланс по типам восприятия, а также поддержание психологически оптимальной/приемлемой динамики (времени ответа, как результирующего, так и промежуточного), сенсорной связи при превышении приемлемого времени ответа.
масштабируемость – возможность применять изделие для достижения различной (количественно) производительности без создания/совершенствования (м.б. переходом к другой конфигурации из числа уже реализованных).
Здесь важно понимать, что система формализации, в сущности, расширяет систему команд исполнителя средствами применяемых ЯПЗ. Причём на базе встроенных средств сочинитель строит пользовательские. Пример — написание библиотечных функций в среде программирования; каждую функцию можно рассматривать как новый оператор прогязыка среды. Тем самым и происходит масштабирование.
Поэтому базовый язык — это ещё не всё; большое значение имеет накопленный свод расширений, их системные показатели (совместимость, эффективность на тех или иных задачах, покрытие семантики предметных областей).
Каждый род, в свою очередь, подразделяется на виды и/или отдельные показатели. Подразделение зависит от рода и вида изделия.
Далее сформулируем конкретные требования, возможные для РДП-изделия (системы, среды).
Требования будут представлены в словесной формулировке; как правило, требованию сопутствует обоснование.
В начало страницы | Оглавление | Версия для печати
Copyright © Жаринов В.Н.
1 Напр., в /С.В. Черемных, И.О. Семенов, В.С. Ручкин, Финансы и статистика, 2001, с.162-163/.
2 У нас именуемой «защита информации».