Практические приемы оценки и повышения качества техдокументации по оценочным элементам фактора «надежность» согласно ГОСТ 28195-89. Материал входит в цикл статей «Качество технической документации». Редакция от 29.04.2021.
Создан 21.12.2011 15:00:44
В первой, вводной части статьи «Качество технической документации. Часть I»:
- рассмотрены общие проблемы качества технической документации;
- определен круг специалистов, заинтересованных в четких и прозрачных инструкциях по оценке качества техдокументации;
- обосновано применение ГОСТ 2.105, ГОСТ 19.106-78, ГОСТ 28195-89 и ГОСТ 8.417-2002 при оценке качества техдокументации.
В настоящей и последующих статьях будут освещены практические приемы оценки качества техдокументации (проанализированы критерии оценки), показаны подходы к «автоматическому» повышению качества технической документации, т.е. как разрабатывать документацию таким образом, чтобы качество ее по умолчанию было предопределенным и буквально «зашкаливало» по подходящим оценочным критериям ГОСТ 28195-89, а также соответствовало требованиям ГОСТ 2.105, ГОСТ 19.106-78 и ГОСТ 8.417-2002.
Оценочные элементы фактора «надежность ПС»
Итак, обратимся к первоисточнику - ГОСТ 28195-89, а именно к таблице 5.
Таблица 5 - Оценочные элементы фактора «надежность ПС» (немного изменена)
Примечание - Здесь и далее требования в оценочных элементах будут применяться все больше к техническому заданию на автоматизированную систему, поскольку:
- ТЗ на АС наиболее востребованы на текущий момент, да и оценки часто касаются именно требований;
- на примере ТЗ можно с максимумом наглядности показать способы достижения того самого предопределенного качества документа, о котором упоминалось выше.
Всяческие «фазы» и «этапы» можно смело проигнорировать - в ходе дальнейшего повествования станет понятно, почему именно.
Средства восстановления при ошибках на входе
Наличие требований к программе по устойчивости функционирования при наличии ошибок во входных данных
«Наличие... при наличии...» 😉
Чтобы получить у эксперта заветный кол (единичку), достаточно прописать в подразделе «Требования к надежности программного обеспечения» технического задания что-то такое: «ПО (или программа) должно (должна) обеспечивать устойчивость функционирования при наличии ошибок во входных данных». Как это требование будет реализовано в ходе проектирования - дело стодвадцатьпятое. В данном случае руководствуемся только формальным требованием наличия требования - «...требованием... требования...» 🙄
Возможность обработки ошибочных ситуаций
Единичка зарабатывается способом, аналогичным предыдущему.
Полнота обработки ошибочных ситуаций
Полнота обработки ошибочных ситуаций - в документах должен быть приведен полный перечень ошибочных ситуаций. Если предусмотрена обработка всех ошибочных ситуаций, то полноту обработки можно считать 100-процентной.
Наличие тестов для проверки допустимых значений входных данных
Критерий звучит несколько старообразно. Сейчас, когда практически все программы оснащены графическим интерфейсом пользователя, допустимые значения входных данных, вводимых пользователем в диалоговом или интерактивном режиме, проходят форматно-логический контроль.
Контроль формата ввода данных: программа позволяет пользователю вводить дату только в формате ДД.ММ.ГГГГ, но не в ГГГГ/ММ/ДД и ни в каком ином. Логический контроль: дата окончания школы не может быть введена БОЛЕЕ ранней, нежели чем дата поступления в школу 😎
О форматно-логическом контроле следует упомянуть где-нибудь в подразделе Требования к лингвистическому обеспечению или создать дополнительный подраздел «Требования к интерфейсу пользователя» в техническом задании.
Наличие системы контроля полноты входных данных
Полнота входных данных достигается применением обязательных полей ввода данных в графическом интерфейсе пользователя. Обязательные поля отмечены звездочками, см. рисунок ниже.
Наличие средств контроля корректности входных данных
См. выше. Корректность входных данных, помимо применения форматно-логического контроля, можно обеспечить путем выбора пользователем данных из календарей, выпадающих списков, словарей и т.д., см. рисунок ниже.
Наличие средств контроля непротиворечивости входных данных
Опять-таки форматно-логический контроль, см. Наличие тестов для проверки допустимых значений входных данных. Повторимся: если дату поступления в ВУЗ можно ввести в соответствующее поле более ранней по сравнению с датой поступления в среднюю школу, то налицо логическое противоречие. Потому и необходимы средства контроля непротиворечивости.
Наличие проверки параметров и адресов по диапазону их значений
Требование по проверке параметров можно добавить в техническое задание, проверкой адресов, если речь идет об адресе команды или адресе в пространстве памяти, занимается любая операционная система.
Наличие обработки граничных результатов
Прокомментировать данное требование представляется пока затруднительным.
Наличие обработки неопределенностей (деление на 0, квадратный корень из отрицательного числа и т.д.)
В языках высокого уровня, применяемых повсеместно, присутствует встроенная обработка неопределенностей - поддержка исключительных ситуаций (Exception handling). В техническом задании на АС имеется подраздел Требования к лингвистическому обеспечению, в котором и задаются требования ко всевозможным языкам. В ТЗ на ПО для этого придуман подраздел Требования к информационной и программной совместимости.
Средства восстановления при сбоях оборудования
Наличие требований к программе по восстановлению процесса выполнения в случае сбоя операционной системы, процессора, внешних устройств
Наличие требований к программе по восстановлению процесса выполнения в случае сбоя операционной системы, процессора, внешних периферийных устройств - данные требования следует добавить в п. Перечень аварийных ситуаций, по которым должны быть регламентированы требования к надежности, значения соответствующих показателей технического задания.
Наличие требований к программе по восстановлению результатов при отказах процессора, ОС
По аналогии с предыдущим требованием. При отказах (зависаниях, а не крахах) операционной системы часто применяется интересная штука: на какой-нибудь из портов ПЭВМ или сервера «подвешивается» некое устройство, периодически опрашивающее порт. Если порт в течение некоторого времени не отзывается, устройство просто перезагружает компьютер с восстановлением ранее загруженных и выполнявшихся программ.
Наличие средств восстановления процесса в случае сбоев оборудования
То же. Только не оборудования, а технических средств.
Наличие возможности разделения по времени выполнения отдельных функций программ
Наличие возможности разделения по времени выполнения отдельных функций программ - в техническом задании на автоматизированную систему есть соответствующий подраздел Требования к функциям (задачам), выполняемым системой, в котором имеется соответствующий пункт. В ТЗ на ПО имеется подраздел Требования к функциональным характеристикам, содержащий пункт о характеристиках временных.
Наличие возможности повторного старта с точки останова
Хитрое требование. В стародавние времена применялся принцип мажоритарного резервирования, когда одну и ту же программу выполняли одновременно три микроконтроллера. В силу временных погрешностей (даже при применении одного кварцевого резонатора) каждый из микроконтроллеров выходил в точку останова в разное время (разница была незначительной - какие-нибудь наносекунды - но тем не менее). В момент времени, когда самый медленный контроллер попадал в точку останова, вся компания дружно обменивалась между собой некими данными и, если они были идентичны, выполнялся старт с точки останова. Таким образом обеспечивалась высочайшая надежность, а заодно и синхронизация.
Сейчас точкой останова можно считать момент времени, когда программа находится в режиме ожидания. К примеру, когда запускается тот же Microsoft™ Word, он завершает все свои инициализационные процедуры, после чего выходит на точку останова - ждет ввода данных пользователем.
Реализация управления средствами восстановления
Наличие централизованного управления процессами, конкурирующими из-за ресурсов
Централизованное управление процессами, конкурирующими из-за ресурсов, встроено во все применяемые ныне операционные системы. Требования к операционным системам, входящим в состав общего программного обеспечения, расписываются в подразделе Требования к программному обеспечению технического задания.
Наличие возможности автоматически обходить ошибочные ситуации в процессе вычисления
См. Наличие требований к программе по устойчивости функционирования при наличии ошибок во входных данных.
Наличие средств, обеспечивающих завершение процесса решения в случае помех
Не совсем ясно, что считать помехами? Если это какие-нибудь электромагнитные помехи или внешние воздействующие факторы по ГОСТ 26883-86, то следует озвучить заданное требование в техническом задании, а в подразделе Требования к защите от влияния внешних воздействий указать предельные их уровни, например «...соответствие нормам индустриальных помех для оборудования класса А согласно ГОСТ Р 51318.22 (СИСПР 22-97)».
Наличие средств, обеспечивающих выполнение программы в сокращенном объеме в случае ошибок или помех
По аналогии с предыдущим пунктом.
Показатель устойчивости к искажающим воздействиям
Не рассматривается, как экспериментальный.
Функционирование в заданных режимах
Смотрите: |
Вероятность безотказной работы
См. выше.
Обеспечение обработки заданного объема информации
Смотрите: |
Оценка по среднему времени восстановления
См. выше.
Оценка по продолжительности преобразования входного набора данных в выходной
См. выше.
Выводы по II части статьи
Примечание - Четыре крайних элемента таблицы не учитывались, поскольку речь в них идет об экспериментах, которые проведены быть не могут до испытаний.
Итак, казалось бы, оценочные факторы надежности должны применяться к программному средству, а фактически, причем вполне обоснованно и справедливо, они были применены к техническому заданию, т.е. к документу, и определили его качество. В сумме ТЗ (в части надежности) получило 17 баллов из 23-х возможных, что есть 73,9 %, если подходить формально. Если не учитывать четыре крайних элемента, то процентное соотношение будет составлять 94,4.
Мораль: при развернутой формулировке оценочных элементов в виде требований технического задания сам документ «автоматически» получит наивысшую экспертную оценку, что крайне важно при проведении конкурсных разработок.
