38. Обеспечение эргономического качества асоИиУ

Под качеством АСОИУ понимается совокупность характеристик системы (или объектов управления), имеющая отношение к ее спо­собности удовлетворять установленные и предполагаемые требова­ния по реализации функций управления. При этом человеку-опера­тору отводится решающая роль в реализации функций управления. Качество автоматизированной системы напрямую связано с ее эргономическим качеством, обеспечивающим оптимальные условия работы оператора.

В связи с вышесказанным требование обеспечения эргономического качества должно закладываться в автоматизированную систему уже на этапе ее проектирования. Затем созданный образец системы должен пройти эргономическую экспертизу на удовлетворение задан­ных требований по качеству.

Для реализации этапов эргономического проектирования современных АСОИУ используется специальное эргономическое обеспечение процесса разработки автоматизированных систем.

Эргономическое обеспечение разработки АСОИУ представляет собой совокупность методов и средств, предназначенных для создания условий высокоэффективной и безошибочной деятельности специалистов-разработчиков в процессе создания, отладки, внедрения и функционирования системы.

Основу эргономического обеспечения составляют методы решения оптимизационных задач эргономики, позволяющие осуществлять согласование эргономических характеристик аппаратно-программной среды АСОИУ и инженерно-психологических характеристик операторов системы. Сюда также входят способы расположения дис­плейных пультов или автоматизированных рабочих мест в помеще­ниях центров АСОИУ или командных пунктов, устройств коллектив­ного пользования; методы расчета общего освещения и освещения на рабочем месте и др.

В последние годы, в связи с широкими масштабами использования АСОИУ, появилось множество нормативных документов, в том числе и ГОСТов, содержащих рекомендации по эргономическому про­ектированию человеко-машинных комплексов, включая АСОИУ об­щего назначения.

Таким образом, для обеспечения эргономического качества АСОИУ необходимо знать психофизические показатели человека-оператора и учитывать нормативные требования к техническим средствам и окружающей среде, а также к создаваемым и функционирующим программно-информационным компонентам АСОИУ, ориентированным на обработку информации и (или) управление объектами.

При эргономическом проектировании в качестве нормативно-технической документации используются государственные стандарты (в том числе стандарты ССБТ и ССЭТО — системы стандартов эргоно­мических требований и эргономического обеспечения), отраслевые стандарты (ОСТ), стандарты предприятий (СТП), руководящие нормативные или организационные документы (РД).

39. Верификация, валидация программных средств.

Верификация (verification), или контроль, проводится с целью нахождения ошибки в процессе выполнения программы в тестовой или моделируемой среде. В процессе верификации, согласно стандарту ISO 9000-2000, осуществляется проверка программного продукта на соответствие входным данным, в том числе требованиям и спецификациям.

В общем случае верификация удостоверяет, что объект внутренне непротиворечив и соответствует стандартам. Основное достоинство верификации состоит в обнаружении ошибок на ранних этапах разработки, до того как они попадут на следующую стадию. Это уменьшает временные и экономические затраты на разработку программного обеспечения. Верификация применима ко всем объектам (как к тестовым моделям, так и к спецификациям). Методы верификации включают экспертные оценки, формальный контроль, формальное доказательство (formal verification) свойств ПО и проверки на непротиворечивость.

Сегодня используются два подхода к верификации программного обеспечения. Первый подход, дедуктивный, представлен такими направлениями исследований, как автоматическое доказательство теорем, использование мультимножеств и графов, а также разнообразных специализированных алгебр. Программная система описывается в рамках некоего формализма, после чего выполняется строгое математическое доказательство обладания данной системой тех или иных свойств. Второй подход—модельный; его последователи не стремятся вписать систему в рамки теории, а вместо этого строят модель системы, которую можно рассматривать как машину или автомат. Любое требование к системе проверяется для каждого возможного состояния автомата.

Валидация.

Валидация (validation), или испытание, является важнейшим элементом управления качеством продукции. В соответствии с ГОСТ 16504-81 под испытанием программной продукции понимают экспериментальное определение количественных и (или) качественных характеристик свойств продукции при ее функционировании в реальной среде и (или) моделировании среды функционирования. При валидации используют способы поиска ошибок в процессе выполнения разработанной программы в заданной реальной среде.

Цель испытания — экспериментальное определение фактических (достигнутых) характеристик свойств испытываемого программного изделия. Эти характеристики могут быть количественными и качественными. Важно, чтобы на их основе можно было сделать вывод о пригодности данного ПИ к использованию по назначению. Если вывод отрицательный, то образец ПИ возвращается на доработку. Таким образом, перекрывается доступ недоброкачественной продукции к пользователю. Непосредственно в ходе испытаний качество ПИ может и не измениться, так как локализация ошибок не является целью испытания. Вместе с тем некоторые дефекты в программах и документации могут устраняться по ходу испытания.

Испытание является завершающим этапом разработки. Ему предшествует этап статической и динамической отладки программ. Основным методом динамической отладки служит тестирование. В узком смысле цель тестирования состоит в обнаружении ошибок, цель же отладки — не только в обнаружении, но и в устранении ошибок. Однако ограничиться лишь отладкой программы, если есть уверенность в том, что все ошибки в ней устранены, нельзя. Цели у отладки и испытания разные. Полностью отлаженная программа может не обладать определенными потребительскими свойствами и быть непригодной к использованию по своему назначению. Не может служить альтернативой испытанию и проверка работоспособности программы на контрольном примере, так как программа, работоспособная в условиях контрольного примера, может оказаться неработоспособной в других условиях применения. Попытки охватить контрольным примером все предполагаемые условия функционирования сводятся в конечном счете к тем же испытаниям.