Анализ функционирования, верификация и аттестация

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

Верификация и аттестация не одно и то же, хотя их легко перепутать. Кратко различие между ними можно определить следующим образом:

Верификация ПО отвечает на вопрос, правильно ли создана система.

Аттестация ПО отвечает на вопрос, правильно ли работает система.

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

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

В процессах верификации и аттестации используются две основные методики проверки и анализа систем:

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

2. Тестирование ПО. Запуск исполняемого кода с тестовыми данными и исследование выходных данных и рабочих характеристик программного продукта. Тестирование — это динамический метод верификации и аттестации, так как применяется к исполняемой системе.

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

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

На разных этапах процесса разработки ПО применяют различные виды тестирования:

1. Тестирование дефектов проводится для обнаружения несоответствий между программой и ее спецификацией, которые обусловлены ошибками или дефектами в программах. Такие тесты разрабатываются для выявления ошибок в системе, а не для имитации ее работы.

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

Конечно, между этими методами не существует жестких, четко установленных границ. Во время тестирования дефектов испытатель может получить интуитивное представление о надежности ПО, а во время статистического тестирования есть возможность выявления программных дефектов.

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

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

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

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

Как правило, в ходе верификации и аттестации в системе обнаруживаются ошибки. Для исправления ошибок в систему вносятся изменения. Этот процесс отладки обычно интегрирован с другими процессами верификации и аттестации. Вместе с тем тестирование
(или более обобщенно — верификация и аттестация) и отладка являются разными процессами, которые имеют различные цели.

1. Верификация и аттестация — процесс обнаружения дефектов в программной системе.

2. Отладка — процесс локализации дефектов (ошибок) и их исправления.

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

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

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

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

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

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

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

Инспектирование программ не требует их исполнения, поэтому данный метод можно использовать до завершения полной реализации программ. Во время инспектирования проверяется исходное представление системы. Это может быть модель системы, спецификация или программа, написанная на языке высокого уровня. Для обнаружения ошибок используется знание разрабатываемой системы и семантика ее исходного представления. Каждую ошибку можно рассматривать отдельно, не обращая внимания на то, как она влияет на поведение системы.

Доказано, что инспектирование является эффективным методом обнаружения ошибок. Также немаловажно, что инспектирование значительно дешевле экстенсивного тестирования программ. В экспериментах сравнивалась эффективность инспектирования и тестирования. Инспектирование программного кода оказалось более эффективным и менее дорогостоящим, чем тестирование.

В системных компонентах и подсистемах выявление ошибок путем просмотра и инспектирования обычно более эффективно, чем с помощью тестирования, по двум причинам:

1. За один сеанс инспектирования можно выявить множество разнообразных программных дефектов. Недостатком тестирования является то, что обычно за один сеанс тестирования можно обнаружить только одну ошибку, поскольку ошибки могут привести к отказу системы или их эффекты могут накладываться друг на друга.

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

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

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

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

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

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

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

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

Координатор составляет план инспектирований, подбирает инспекционную группу, организует собрание и убеждается, что программа и ее спецификация закончены. Программа, предназначенная для инспектирования, передается на рассмотрение инспекционной группе, где автор программы описывает ее назначение (этап предварительного просмотра). После этого следует этап индивидуальной подготовки, на котором каждый член инспекционной группы изучает программу и ее спецификацию и выявляет дефекты в программном коде.

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

После инспектирования автор изменяет программу, исправляя обнаруженные ошибки. На этапе доработки координатор принимает решение о том, необходимо ли повторно проводить инспектирование. Если повторного инспектирования не требуется, все обнаруженные дефекты документально фиксируются и документ с результатами инспектирования утверждается председателем.

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

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

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

Количество кода, проверяемого за определенное время, зависит от опыта группы инспектирования, языка программирования и предметной области приложения. На основе опыта проведения инспектирования в компании IBM сделаны следующие оценки:

1. На этапе предварительного просмотра за один час можно просмотреть приблизительно
500 операторов исходного кода.

2. Во время индивидуальной подготовки за один час можно проверить примерно
125 операторов исходного кода.

3. При групповом обсуждении за один час можно проверить от 90 до 125 операторов.

Принято считать, что максимальная длительность инспектирования не должна превышать двух часов, поскольку потом эффективность обнаружения дефектов снижается. Поэтому в процессе разработки ПО инспектирование относительно малых системных компонентов должно выполняться достаточно часто.

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

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

Статические анализаторы программ — это инструментальные программные средства, которые сканируют исходный текст программы и выявляют возможные ошибки и противоречия. Для анализаторов не требуется исполняемая программа. Они выполняют синтаксический разбор текста программы и опознают различные типы операторов. Таким образом, с помощью анализаторов можно проверить, правильно ли составлены операторы, сделать выводы относительно потока управления в программе и во многих случаях вычислить множество значений данных, используемых программой. Анализаторы дополняют средства обнаружения ошибок, предоставляемых компилятором языка.

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

Статистический анализ состоит из нескольких этапов:

1. Анализ потока управления. На этом этапе идентифицируются и выделяются циклы, их точки входа и выхода, а также неиспользуемый код. Это код, окруженный безусловными операторами перехода, или код одной из ветвей условного оператора, условие перехода к которой никогда не будет истинным.

2. Анализ использования данных. На этом этапе проверяется использование переменных в программе. Анализ позволяет обнаружить переменные, которые используются без предварительной инициализации, переменные, которые описаны дважды без промежуточного присвоения, а также объявленные, но нигде не используемые переменные. На этом этапе также можно выявить условные операторы с избыточными условиями. Это такие условия, значения которых никогда не изменяются: они либо всегда истинны, либо всегда ложны.

3. Анализ интерфейса. На этом этапе проверяется согласованность различных частей программы, правильность объявления процедур и их использования. Данный этап оказывается лишним, если используется язык со строгим контролем типов, например Java, так как подобный анализ выполняет компилятор этого языка. Анализ интерфейса помогает выявить ошибки в программах, написанных на языках со слабым контролем типов, например FORTRAN или С. В процессе анализа интерфейса можно также выявить объявленные функции и процедуры, которые нигде не вызываются, и функции, результаты которых не используются.

4. Анализ потоков данных. На этом этапе анализа определяются зависимости между исходными (входными) и результирующими (выходными) переменными. Хотя такой анализ не выявляет конкретных ошибок, он дает полный список значений, используемых в программе, благодаря чему легче обнаружить ошибочный вывод данных. На этом этапе также можно явно определить условия, которые влияют на значения переменных.

5. Анализ ветвей программы. На этом этапе семантического анализа определяются все ветви программы и выделяются операторы, исполняемые в каждой ветви. Анализ ветвей программы существенно помогает разобраться в управлении программой и позволяет проанализировать каждую ветвь отдельно. Анализ потока данных и анализ ветвей генерируют огромное количество информации. Эта информация не выявляет конкретных ошибок, а представляет программу в разных аспектах. Из-за огромного количества генерируемой информации эти этапы статического анализа иногда исключают из процесса анализа и используют только на ранних стадиях для обнаружения аномалий в разрабатываемой программе. Статические анализаторы особенно полезны в тех случаях, когда используются языки программирования, подобные С. В языке С нет строгого контроля типов, и потому проверка, осуществляемая компилятором языка С, ограниченна. В этом случае средствами статического анализа можно автоматически выявить широкий спектр ошибок программирования. Данный анализ особенно важен при разработке критических систем. В этом случае статический анализ позволяет значительно сократить расходы на тестирование.

В системах Unix и Linux есть статический анализатор LINT для программ, написанных на С. Он обеспечивает статическую проверку, эквивалентную проверке компилятором в языках со строгим контролем типов, например Java.

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

Подведем теперь итоги.

Цель работ, выполняемых на стадии "Анализ функционирования", состоит в получении объективных и систематизированных данных о качестве созданной системы, текущем состоянии и реальном эффекте от использования системы на основании опыта ее промышленной и опытной эксплуатации.

Исходными данными для проведения работ этой стадии являются:

- эксплуатационная документация, содержащая все сведения о системе, необходимые для освоения АСОИУ и ее эксплуатации;

- формуляр системы (отражающий работы системы и ее комплекса технических средств с фиксацией всех видов неисправностей и способов устранения);

- известные методики по определению экономической эффективности и эксплуатационной надежности АСОИУ.

Исследования, проводимые на стадии "Анализ функционирования", включают следующие этапы:

- предварительное обследование состояния АСОИУ;

- экспериментально-статистические исследования;

- анализ полученных результатов;

- разработка рекомендаций и заключительных материалов обследования.

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

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

Эксплуатация АСОИУ

Широкое применение АСОИУ в промышленности делает весьма актуальной задачу рациональной эксплуатации этих систем. Перечислим некоторые важнейшие особенности АСОИУ:

- большое количество сложных и разнообразных технических средств, входящих в состав АСОИУ;

- наличие развитого программного и организационного обеспечения; большое количество пользователей информации, вырабатываемой в системе;

- существенная взаимосвязь между эффективностью АСОИУ, ее надежностью и способами эксплуатации;

- необходимость в продуманной эволюции каждой АСОИУ.

Перечисленные особенности приводят к тому, что организация и проведение эксплуатации АСОИУ становится сложной и разносторонней проблемой. Она требует для своего решения проведения ряда работ на всех стадиях ее создания, значительных средств и большого количества людей. Так, например, в настоящее время цехи тепловой автоматики и измерений на тепловых электростанциях, в состав которых входит персонал, ведущий эксплуатацию АСОИУ, являются одними из самых больших на электростанциях. Численность этих цехов на крупных тепловых станциях достигает 200 человек и более, а в переводе на 1 МВт установленной мощности составляет около 0,4 чел/МВт.

Основные задачи, решаемые при подготовке и проведении эксплуатации АСОИУ, таковы:

1. Обеспечение потребителей разнообразной информацией, вырабатываемой системой.

2. Выбор организационной структуры подразделения, осуществляющего эксплуатацию АСОИУ.

3. Проведение оптимального технического обслуживания комплекса технических средств.

4. Снабжение запасными частями и материалами и др.

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

Эксплуатационная надежность

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

Функциональную надежность компьютерных систем можно определить степенью доверия к ним, т.е. уверенностью, что система будет работать так, как предполагается, и что сбоев не будет. Это свойство нельзя оценить количественно. Для этого используются такие относительные термины, как "ненадежные", "очень надежные" или "сверхнадежные", отражающие различную степень доверия к системе.

Существует четыре основные составляющие функциональной надежности программных систем, неформальные определения которых приведены ниже.

1. Работоспособность - свойство системы выполнять свои функции в любое время эксплуатации.

2. Безотказность - свойство системы корректно (так, как ожидает пользователь) работать весь заданный период эксплуатации.

3. Безопасность — свойство системы, гарантирующее, что она безопасна для людей и окружающей среды.

4. Защищенность — свойство системы противостоять случайным или намеренным вторжениям в нее.

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

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

 

Рис. 3.1. Зависимость между стоимостью разработки и ее надежностью

 

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

Высокие уровни функциональной надежности могут быть достигнуты только за счет уменьшения эффективности работы системы. Например, надежное программное обеспечение предусматривает дополнительные, часто избыточные, коды для проверки нештатных состояний системы. Это усложняет систему и увеличивает объем памяти, необходимый для ее эффективной работы. Но в ряде случаев надежность более важна, чем эффективность системы. Аспекты надежности систем таковы:

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

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

3. Трудно модернизировать ненадежную сис