Качество технической документации. Часть II - оценочные элементы надежности

Рассмотрены практические приемы оценки и повышения качества техдокументации по оценочным элементам фактора «надежность» согласно ГОСТ 28195-89. Материал входит в цикл статей «Качество технической документации»

Качество технической документации. Часть II - оценочные элементы надежности

В первой, вводной части статьи «Качество технической документации. Часть 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). В техническом задании на АС имеется подраздел Требования к лингвистическому обеспечению, в котором и задаются требования ко всевозможным языкам. В ТЗ на ПО для этого придуман подраздел Требования к информационной и программной совместимости.

Средства восстановления при сбоях оборудования

Наличие требований к программе по восстановлению процесса выполнения в случае сбоя операционной системы, процессора, внешних устройств

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

Наличие требований к программе по восстановлению результатов при отказах процессора, ОС

По аналогии с предыдущим требованием. При отказах (зависаниях, а не крахах) операционной системы часто применяется интересная штука: на какой-нибудь из портов ПЭВМ или сервера «подвешивается» некое устройство, периодически опрашивающее порт. Если порт в течение некоторого времени не отзывается, устройство просто перезагружает компьютер с восстановлением ранее загруженных и выполнявшихся программ.

Наличие средств восстановления процесса в случае сбоев оборудования

То же. Только не оборудования, а технических средств.

Наличие возможности разделения по времени выполнения отдельных функций программ

Наличие возможности разделения по времени выполнения отдельных функций программ - в техническом задании на автоматизированную систему есть соответствующий подраздел Требования к функциям (задачам), выполняемым системой, в котором имеется соответствующий пункт. В ТЗ на ПО имеется подраздел Требования к функциональным характеристикам, содержащий пункт о характеристиках временных.

Наличие возможности повторного старта с точки останова

Хитрое требование. В стародавние времена применялся принцип мажоритарного резервирования, когда одну и ту же программу выполняли одновременно три микроконтроллера. В силу временных погрешностей (даже при применении одного кварцевого резонатора) каждый из микроконтроллеров выходил в точку останова в разное время (разница была незначительной - какие-нибудь наносекунды - но тем не менее). В момент времени, когда самый медленный контроллер попадал в точку останова, все компания обменивалась некими данными и, если они были идентичны, стартовали с точки останова. Таким образом обеспечивалась высочайшая надежность, а заодно и синхронизация.

Сейчас точкой останова можно считать момент времени, когда программа находится в режиме ожидания. К примеру, когда запускается тот же ворд, он завершает все свои инициализационные процедуры, после чего выходит на точку останова - ждет ввода данных пользователем.

Реализация управления средствами восстановления

Наличие централизованного управления процессами, конкурирующими из-за ресурсов

Централизованное управление процессами, конкурирующими из-за ресурсов, встроено во все применяемые ныне операционные системы. Требования к операционным системам, входящим в состав общего программного обеспечения, расписываются в подразделе Требования к программному обеспечению технического задания.

Наличие возможности автоматически обходить ошибочные ситуации в процессе вычисления

См. Наличие требований к программе по устойчивости функционирования при наличии ошибок во входных данных.

Наличие средств, обеспечивающих завершение процесса решения в случае помех

Не совсем ясно, что считать помехами? Если это какие-нибудь электромагнитные помехи или внешние воздействующие факторы по ГОСТ 26883-86, то следует озвучить заданное требование в техническом задании, а в подразделе Требования к защите от влияния внешних воздействий указать предельные их уровни, например «...соответствие нормам индустриальных помех для оборудования класса А согласно ГОСТ Р 51318.22 (СИСПР 22-97)».

Наличие средств, обеспечивающих выполнение программы в сокращенном объеме в случае ошибок или помех

По аналогии с предыдущим пунктом.

Показатель устойчивости к искажающим воздействиям

Не рассматривается, как экспериментальный.

Функционирование в заданных режимах

Вероятность безотказной работы

См. выше.

Обеспечение обработки заданного объема информации

Оценка по среднему времени восстановления

См. выше.

Оценка по продолжительности преобразования входного набора данных в выходной

См. выше.

Выводы по II части статьи

Примечание - Четыре крайних элемента таблицы не учитывались, поскольку речь в них идет об экспериментах, которые проведены быть не могут до испытаний.

Итак, казалось бы, оценочные факторы надежности должны применяться к программному средству, а фактически, причем вполне обоснованно и справедливо, они были применены к техническому заданию, т.е. к документу, и определили его качество. В сумме ТЗ (в части надежности) получило 17 баллов из 23-х возможных, что есть 73,9 %, если подходить формально. Если не учитывать четыре крайних элемента, то процентное соотношение будет составлять 94,4.

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

Заказать услуги, установить контакты со специалистами компании можно по электронной почте admin собака tdocs точка su, по ICQ UIN 481-726-610 или с помощью формы «Контакты». Вопросы некоммерческого характера могут быть заданы в Форуме проектировщиков и разработчиков технической документации.