Для прямых количественных измерений атрибутов надежности необходимы инструментальные средства, встроенные в операционную систему или в соответствующие компоненты ПС. Эти средства должны в динамике реального функционирования ПС автоматически выбирать и регистрировать аномальные ситуации, дефекты и искажения вычислительного процесса, программ и данных, выявляемые аппаратным, программно-алгоритмическим контролем или пользователями. Накопление и систематизация проявлений дефектов при исполнении программ позволяет оценивать основные показатели надежности, помогает определять причины сбоев и отказов и подготавливать данные для улучшения надежности ПС.
Прямые экспериментальные методы оценивания интегральных характеристик надежности ПС – завершенности, устойчивости и готовности – в ряде случаев трудно реализовать при нормальных условиях функционирования сложных комплексов программ из–за больших значений требуемого времени наработки на отказ (сотни и тысячи часов). Сложность выявления и регистрации редких отказов, высокая стоимость экспериментов при длительном многосуточном функционировании сложных ПС приводят к тому, что на испытаниях получаются малые выборки зарегистрированных отказов и низка достоверность оценки показателей надежности.
При испытаниях надежности ПС в первую очередь обнаруживаются отказы – потери работоспособности. Для выявления фактора, вызвавшего отказ, и устранения его причины необходимо определить, каким компонентом информационной системы стимулирован данный отказ. Наиболее крупными источниками отказов являются частичные физические неисправности или сбои аппаратуры ЭВМ, а также дефекты и ошибки ПС. Стабильные неисправности аппаратуры диагностируются достаточно просто соответствующими аппаратными тестами.
Для повышения надежности ПС при высокой наработке на отказ необходима тщательная, систематическая работа специалистов, накапливающих, регистрирующих и анализирующих все ситуации отказов при функционировании комплекса программ. Эти специалисты должны также регистрировать все проведенные корректировки для прогнозирования причин появления возможных дополнительных источников отказов, вызванных дефектами корректировок.
При заключительных приемо–сдаточных и сертификационных испытаниях для достаточно достоверного определения надежности ПС организуются многочасовые и многосуточные прогоны функционирования комплекса программ в реальной или имитированной внешней среде в условиях широкого варьирования исходных данных с акцентом на критические ситуации проявления угроз надежности. Такие прогоны позволяют измерить достигнутые характеристики надежности и определить степень их соответствия требованиям ТЗ, а также закрепить их в технических условиях и документации на ПС.
Экспериментальное исследование характеристик сложных ПС позволило оценить темп обнаружения дефектов, при котором сложные комплексы программ передаются на регулярную эксплуатацию: 0,002–0,005 ошибок в день на человека, т.е. специалисты по испытаниям или пользователи в совокупности выявляют только около одной ошибки или дефекта каждые 2–3 месяца использования ПС.
Интенсивность обнаружения ошибок ниже 0,001 ошибок в день на человека, т.е. меньше одной ошибки в год на 3–4 специалистов, непосредственно выполняющих тестирование и эксплуатацию ПС, по–видимому, может служить эталоном высокой надежности для ПС обработки информации. Если функционирование программ происходит непрерывно, то эти показатели соответствуют очень высокой наработке на обнаружение дефекта или отказа порядка 5000–10000 часов и коэффициенту готовности выше 0,99.
Форсированные испытания для оценки надежности ПС значительно отличаются от традиционных методов испытаний аппаратуры. Форсирование испытаний осуществляется повышением интенсивности искажений исходных данных и расширением варьирования их значений, а также специальным увеличением интенсивности потоков информации и загрузки ПС выше нормальной. На надежности функционирования сложных критических ПС весьма существенно отражаются перегрузки по памяти и производительности при исполнении программ. Эти виды угроз стимулируют отказы, которые трудно выявляются при испытаниях в режимах нормальной загрузки.
Планирование форсированных испытаний должно предусматривать последующий пересчет полученных показателей надежности на условия нормального функционирования. Для этого необходимо оценивать надежность испытываемых программ в зависимости от интенсивности искажений данных или от характера перегрузки ЭВМ и способы корректного пересчета получаемых показателей на нормальные условия эксплуатации. При форсированных испытаниях целесообразно выделять следующие режимы тестирования:
· при полном искажении, предельных и критических значениях ключевых параметров каждого типа внешней информации и воздействий пользователей;
· при предельных и критических сочетаниях значений различных воздействующих параметров эксплуатации ПС;
· при предельно больших и малых интенсивностях суммарного потока и каждого типа внешней информации;
· при умышленных нарушениях пользователями определенных положений инструкций и рекомендаций эксплуатационной документации.
Как вид форсированных испытаний можно рассматривать тестирование и контроль результатов функционирования одних и тех же ПС при увеличении числа испытываемых экземпляров и нормальных исходных данных – бета–тестирование (п.5.4.3). На этапе опытной эксплуатации пользователями некоторого предварительного тиража ПС происходит естественное расширение вариантов исходных данных. Это позволяет увеличивать наборы тестов, и тем самым дает возможность оценивать наработки на отказ в сотни и тысячи часов.
Особым видом форсированных испытаний является целенаправленное тестирование эффективности средств оперативного контроля и восстановления программ, данных и вычислительного процесса для оценивания субхарактеристики восстанавливаемости. Для этого имитируются запланированные условия функционирования программ, при которых в наибольшей степени стимулируется срабатывание средств программного рестарта и оперативного автоматического восстановления работоспособности.
Для достижения особо высокой надежности функционирования ПС активно применяются различные методы программной защиты от сбоев и отказов программ – методы оперативного рестарта. Они позволяют замедлить рост затрат на разработку при повышении требований к их надежности. По экспертным оценкам для получения наработки на отказ в сотню часов затраты возрастают в среднем в 1,5 раза, а для наработки в тысячу часов – в 2 раза.
7.3. Оценивание эффективности использования ресурсов ЭВМ
Оценивание ресурсной эффективности состоит в измерении количественных субхарактеристик и их атрибутов (табл.4.2): временной эффективности (метрик поведения ПС во времени); используемости ресурсов ЭВМ комплексом программ.
При этом предполагается, что в контракте, ТЗ или спецификации требований зафиксированы и утверждены требуемые значения атрибутов стандартизированных субхарактеристик.
При подготовке ТЗ и спецификаций требований на ПС также следует согласовывать с заказчиком модель и характеристики внешней среды, в которой будет применяться комплекс программ, динамики приема и передачи данных (п.7.1.3). Эти условия следует детализировать до уровня, позволяющего однозначно определять требуемые значения интенсивностей решения задач:
· в среднем нормальном режиме работы ПС с наибольшим качеством функциональной пригодности;
· в режиме предельной загрузки, реализующемся с определенной вероятностью и с допустимым снижением функциональной пригодности и некоторых характеристик качества;
· в режиме кратковременной аварийной перегрузки, способной критически отражаться на функциональной пригодности, надежности и безопасности применения ПС.
Для измерения атрибутов временной эффективности необходимы инструментальные средства, встроенные в операционную систему или в соответствующее прикладное ПС. Эти средства должны в динамике реального функционирования программ регистрировать:
· загрузку вычислительной системы;
· значения интенсивности потоков данных от внешних абонентов;
· длительность исполнения заданий;
· характеристики функционирования устройств ввода/вывода;
· время ожидания результатов (отклика) на задания пользователей;
· заполнение памяти обмена с внешними абонентами в различных режимах применения комплекса программ и т.п.
Значения этих характеристик зависят не только от свойств и функций ПС, но и от особенностей архитектуры и операционной системы ЭВМ.
Потребность в ресурсах памяти и производительности ЭВМ в процессе решения задач может значительно изменяться в зависимости от их свойств, а также от потока, состава и объема исходных данных. Степень использования памяти и производительности ЭВМ в некоторых пределах не влияет на качество решения функциональных задач комплексом программ.
При излишне высокой интенсивности поступления исходных данных может нарушаться временной баланс между длительностью решения полной совокупности задач ПС в реальном масштабе времени и производительностью ЭВМ при решении этих задач. Также возможно нарушение баланса между имеющейся в ЭВМ памятью и памятью, необходимой для хранения всей поступившей и обрабатываемой информацией. Для выявления подобных ситуаций и определения характеристик ПС в условиях недостаточности ресурсов ЭВМ проводятся испытания при допустимо высокой интенсивности поступления исходных данных.
При использовании комплексом программ производительности и память реализующей ЭВМ менее чем на 50%, разработчик может практически не учитывать эти ограничения. Поэтому закономерным является стремление разработчиков программ применять, особенно для систем реального времени, ЭВМ с предельным использованием технических характеристик. Опыт создания ПС реального времени показывает, что практически невозможно использовать производительность объектной ЭВМ более чем на 95%, и почти всегда целесообразно ограничиваться на уровне 90%. Подобная зависимость обусловлена сложностью оптимального распределения в динамике ограниченных ресурсов ЭВМ (особенно производительности) по многим функциональным задачам, необходимостью проектирования программ с учетом этих ограничений и неоднократными переделками программ для соблюдения всех ресурсных ограничений.
Наиболее сложным является оценивание эффективности использования ресурсов производительности ЭВМ в реальном времени. При этом должна быть определена зависимость качества решения задач от интенсивности поступающей информации различных типов. Основная задача испытаний состоит в определении вероятностей, с которыми будет нарушаться соответствие между потребностями в производительности для решения всей требуемой совокупности задач и реальными возможностями ЭВМ. Если эта вероятность невелика и можно считать допустимым эпизодическое снижение качества за счет получающихся задержек и пропусков в обработке сообщений или заданий, то делается вывод о соответствии производительности ЭВМ функциям данного ПС.
Для оценивания использования ресурсов производительности должны быть измерены:
· реальные значения интенсивностей поступающих исходных данных и заданий на вызов функциональных программ, а также распределения вероятностей этих интенсивностей для различных источников и типов сообщений;
· длительности автономного решения отдельно каждой из функциональных задач, обрабатывающей исходные данные или включаемой внешними заданиями;
· загрузка ЭВМ в нормальном режиме поступления сообщений и заданий, а также вероятность перегрузки заданиями различных типов и распределения длительностей перегрузки в реальных условиях;
· влияние пропуска в обработке заданий или сообщений каждого типа и снижения темпа решения определенных задач на функциональную пригодность и другие характеристики качества ПС.
Перечисленные задачи могут быть решены экспериментально в процессе тестирования завершенной информационной системы, однако при этом велик риск, что производительность ЭВМ окажется недостаточной для решения заданной совокупности задач в реальном времени.
Для корректного оценивания предельной пропускной способности информационной системы с данным ПС необходимо измерять следующие характеристики функциональных групп программ:
· экстремальные значения длительностей их исполнения и маршруты, на которых эти значения достигаются;
· среднее значение длительности исполнения каждой функциональной группы программ на всем возможном множестве маршрутов ПС и его дисперсию;
· распределение вероятностей, значений длительности исполнения функциональных групп программ.
В общем случае для оценивания длительностей исполнения и определения качества функционирования программ в зависимости от загрузки, необходимо задавать вероятность каждой комбинации тестовых данных и измерять соответствующую ей длительность. Однако для сложных групп программ весьма трудно определить вероятность каждой комбинации исходных данных. Поэтому на практике ограничиваются некоторыми средними или наиболее вероятными значениями тестовых данных, а также одним или несколькими сочетаниями исходных данных, при которых ожидаются предельные значения потоков заданий и длительностей исполнения программ. Влияние таких ситуаций перегрузки по производительности может быть ослаблено применением приоритетных дисциплин оперативной диспетчеризации исполнения заданий на решение функциональных задач. В зависимости от характеристики потоков заданий и предполагаемых длительностей их реализации могут распределяться приоритеты на их решение.
По результатам испытаний могут быть решены перечисленные задачи оценивания ресурсной эффективности ПС. Это позволяет анализировать факторы, определяющие необходимую пропускную способность ЭВМ, и разрабатывать меры для приведения ее в соответствие с потребностями.
7.4. Оценивание практичности
Оценивание практичности – применимости ПС включает определение атрибутов удобства и комфортности для пользователей при его освоении, подготовке комплекса программ к эксплуатации и при использовании по назначению.
Субхарактеристики практичности содержат (табл.4.3): понятность; простоту использования; изучаемость; привлекательность ПС.
Оценки практичности зависят не только от собственных характеристик ПС, но также от организации и адекватности документирования процессов их эксплуатации. При этом предполагается, что в контракте, ТЗ или спецификации зафиксированы и утверждены требования к основным параметрам и качеству организационных методов и средств поддержки использования ПС.
Атрибуты субхарактеристик понятность и привлекательность близки по содержанию и субъективному восприятию оценщиками–испытателями. Их можно оценивать только качественно, экспертно категориями отлично, хорошо, удовлетворительно и плохо. Дальнейшее увеличение числа градаций при оценивании таких атрибутов как демонстрационные возможности, четкость концепции и наглядность документации нецелесообразно.
Для обеспечения объективности оценивание целесообразно проводить группой экспертов–пользователей при типовом и экстремальном применении ПС
Субхарактеристики простота использования и изучаемость также могут обобщенно оцениваться качественно теми же шкалами с двумя – четырьмя категориями. Такой же метод наиболее адекватен для оценивания комфортности эксплуатации и простоты управления функциями ПС.
Однако некоторые атрибуты этих субхарактеристик доступны для более полной количественной оценки путем измерения трудоемкости и длительности соответствующих процессов подготовки и обучения пользователей к эффективной эксплуатации ПС.
Наиболее удобно этими мерами определять качество изучаемости ПС. Этот показатель зависит не только от внутренних свойств и сложности комплекса программ, но и от метрик качества в использовании, от субъективных характеристик квалификации конкретных пользователей. На значения изучаемости существенно влияют демонстрационные возможности справочных средств обучения, качество и объем эксплуатационной документации, электронных учебников, которые можно оценивать соответственно по числу сопровождающих страниц документов или килобайт памяти (см. п.7.7).
7.5. Оценивание сопровождаемости
Оценивание сопровождаемости заключается в определении мер и атрибутов процессов сопровождения и конфигурационного управления изменениями и версиями в ЖЦ комплексов программ. Субхарактеристики сопровождаемости включают (табл.4.3): анализируемость; изменяемость; стабильность; тестируемость программ.
При этом предполагается, что в контракте, ТЗ или спецификации зафиксированы и утверждены требования к основным параметрам и качеству реализации процессов сопровождения ПС.
Для обеспечения возможности оценивания оценивания полноты и эффективности реализации этих функций в процессе проектирования ПС должна быть формализована и документально зафиксирована концепция организации процесса сопровождения, параметры которого являются исходными для определения его качества:
· ожидаемую длительность поддержки сопровождением развития проекта ПС;
· объем, сложность и уровень предполагаемых изменений;
· возможное число и периодичность выпуска версий со значительными модификациями;
· организационные основы процессов сопровождения и конфигурационного управления;
· требования к документированию, изменений и версий;
· кто будет осуществлять сопровождение – покупатель, разработчик первичной версии или специальный персонал поддержки развития и адаптации версий ПС.
В стратегии сопровождения следует учесть характеристики системы:
· количество компонентов ПС;
· типы, размер и критичность создаваемых и модифицируемых программных продуктов;
· унифицированность внутренних и внешних интерфейсов.
Управление конфигурацией следует организовать так, чтобы персонал знал свои обязанности и имел достаточно независимости и полномочий для выполнения поставленных задач и требований сопровождения.
Требуемые характеристики и методы оценивания сопровождаемости должны определяться специальным договором (или разделом договора на разработку первичной версии ПС) между разработчиком и заказчиком. В ТЗ и в контракте следует определять порядок квалификации видов и причин изменений в программах и данных, а также распределение ответственности за их инициализацию, реализацию и финансирование. Выявленные ошибки в программах и данных, которые искажают реализацию функций, согласованных с заказчиком в контракте и требованиях ТЗ, а также отраженные в документации на версию ПС, должны устраняться в основном за счет разработчика. Модификацию и расширение функций компонентов или версии комплекса программ, ранее не отраженных в ТЗ и контракте с заказчиком, следует квалифицировать как дополнительную работу с соответствующим финансированием заказчиком.
После передачи версии в эксплуатацию затраты на обнаружение и первичную квалификацию дефектов несут в основном непосредственные пользователи. На разработчиков (поставщиков) ПС возлагается анализ и локализация причин дефектов и их устранение. Эти затраты зависят:
· от характеристик выявляемых дефектов,
· от объема и сложности комплекса программ,
· организации и технологии его разработки,
· инструментальной оснащенности сопровождения,
· квалификации специалистов,
· тиража и активности применения данного ПС.
Априори перечисленные факторы оценивать трудно, и оценивание этой составляющей качества ПС целесообразно проводить по начальным результатам сопровождения версий.
Сопровождаемость следует также оценивать полнотой и достоверностью документации о состояниях ПС и его компонентов, всех предполагаемых и выполненных изменениях. Она должна определять стратегию, стандарты, процедуры, распределение ресурсов и планы создания, изменения и применения документов на программы и данные информационных систем. Структура документации и формы отдельных документов, используемых для сопровождения программ, должны позволять:
· точно документально описывать и идентифицировать каждую оформленную версию программных компонентов и ПС в целом в любое время на всем протяжении их ЖЦ;
· надежно учитывать и регистрировать все анализируемые, подготавливаемые и реализованные изменения в версиях ПС;
· снабжать руководителей проекта обобщенной и детальной информацией для принятия решений на изменения программ;
· обеспечивать заказчиков и пользователей сведениями о наиболее существенных корректировках программ и о новых версиях ПС.
Особое значение при оценивании сопровождаемости имеет тестируемость компонентов ПС и качество документации на реализованные изменения и тесты. На базе всего комплекса использованных тестов создается и документируется для каждой версии ПС эталонная тестовая (контрольная) задача и контрольные результаты ее решения. В течение этого времени возможны отдельные уточнения изменений в документации версии. В результате документация должна непрерывно «догонять» реальное состояние программного продукта. Для упорядочения этого процесса стандартами установлена возможность оперативного выпуска предварительных извещений на частные изменения.
По истечении некоторого времени сопровождение конкретного ПС прекращается. Это может быть обусловлено разработкой более современных ПС или нерентабельным возрастанием затрат на сопровождение. Чтобы со временем прийти к обоснованному решению о прекращении сопровождения необходимо периодически оценивать эффективность эксплуатации версий ПС у пользователей и возможный экономический ущерб у них от отмены сопровождения конкретной версии.
7.6. Оценивание мобильности
Оценивание мобильности ПС состоит в определении атрибутов субхарактеристик качества переноса программ и данных на иные аппаратные и операционные платформы. Эта субхарактеристика включает (табл.4.3): адаптируемость; простоту установки; сосуществование; замещаемость программ. При этом предполагается, что в контракте, ТЗ или спецификации требований зафиксированы и утверждены требования к основным затратам и качеству процессов и результатов переноса ПС.
Следует учитывать, что любой перенос связан с затратами, которые требуются для:
· системного анализа рентабельности переноса на иную или ту же платформу и оценки технико-экономических показателей этого процесса;
· реализации самого процесса переноса и интеграции с операционной и внешней средой новой аппаратной платформы;
· испытаний и минимально необходимой проверки функционирования ПС в новом окружении или на новой платформе;
· сертификации перенесенных на новую платформу ПС и БД и функционирующих в иной операционной и внешней среде;
· корректировки или дополнения эксплуатационной и технологической документации.
При оценивании мобильности ПС, а также технологии и инструментальных средств обеспечения их переноса целесообразно учитывать практические методы создания программ и данных, обладающих свойством рентабельной переносимости в заданных пределах. Следует анализировать методики переноса в новую систему существующих программ и данных, которые первоначально создавались, возможно, без учета всего комплекса факторов, влияющих на эффективность переноса.
Целесообразность выбора и выделения компонентов для повторного использования и/или переноса на другие платформы зависит, прежде всего, от их объема и от кратности возможного применения. Существует некоторый диапазон объемов программ и информации БД, для которых нецелесообразно применять ранее созданные программы и массивы данных, а проще разработать новые.
Эффективность переноса программ и данных следует оценивать при планировании и управлении проектом, учитывая экономическую эффективность (выигрыш от переноса повторно используемых программ данных и затраты на перенос) и техническую эффективность (выигрыш или потери в функциональных возможностях ПС за счет их переноса с исходных на новые платформы).
В зависимости от степени программной совместимости между исходной и новой платформами возможны варианты оценивания исходных условий мобильности:
· при полной несовместимости платформ, когда может потребоваться переписывание всего ПС или компонентов заново (возможно с применением имеющихся спецификаций требований);
· при несовместимости языков программирования или диалектов одного языка может потребоваться переписывание программ на том языке, который принят для проекта нового ПС (возможно с применением имеющихся проектных спецификаций повторно используемых компонентов);
· при несовместимости аппаратно–программных платформ, поддерживающих один и тот же язык программирования, требуется перекомпиляция программ на новой платформе (возможно с автоматической оптимизацией, обеспечиваемой применяемой системой программирования).
Задачи оценивания мобильности программ и данных охватывают:
· встраивание готового программного комплекса в создаваемую информационную систему при условии, что поставщики этого ПС гарантируют его функционирование на выбранной платформе;
· перенос программ и данных с платформ, в среде которых они ранее были реализованы, на выбранную новую платформу.
Задачи и объекты, связанные с мобильностью ПС в информационных системах и подлежащие рассмотрению при оценивании адаптируемости и замещаемости, включают:
· унифицированные протоколы и интерфейсы взаимодействия функциональных программных компонентов между собой, со средой информационной системы, с пользователями, с внешней средой, включающие интерфейсы операционных систем, сетевые протоколы, спецификации служб организации процессов;
· языки программирования и инструментальные средства, поддерживающие создание переносимых ПС и средства программной инженерии;
· языки баз данных и системы управления базами данных (СУБД);
· форматы переносимых электронных документов.
Значительная часть этих задач решается путем применения соответствующих стандартов информационных технологий, действующих как международные или национальные нормативные документы, или открытых спецификаций, отражающих сложившиеся промышленные стандарты де-факто.
7.7. Оценивание качества эксплуатационной и технологической документации
Цель оценивания качества документации ПС – определение степени ее соответствия программному продукту и его компонентам, возможности обеспечивать эффективную эксплуатацию, длительный ЖЦ, мобильность и повторное применение программных и информационных компонентов.
Качество документации на комплексы программ можно характеризовать затратами трудовых и временных ресурсов на ее создание, а также затратами на освоение для возможности эффективного применения ПС, Эти атрибуты качества документов доступны обобщенным количественным измерениям и сравнению с требованиями заказчика и пользователей.
7.7.1. Документирование в процессах жизненного цикла
Документирование в процессах ЖЦ ПС определяется стандартами ГОСТ серий 19 и 34, ISO/IEC 8631, ISO 9127, ISO/IEC 9294, ISO 15910, ISO 18019 (рис.2.2).
ЖЦ ПС должен отражаться набором отчетных и результирующих документов в последовательности выполнения и взаимосвязи работ, обеспечивающих регламентированное ведение разработки и применения комплекса программ на всех стадиях от подготовки ТЗ до завершения испытаний ряда версий и окончания эксплуатации ПС. Выполнение этих требований следует контролировать путем оценивания соответствия качества всего комплекта документов программным компонентам, процессам и стандартам ЖЦ ПС. Эти оценивания должны сводиться к регулярной поэтапной регистрации характеристик и атрибутов их качества, к сопоставлению содержания документов с заданными требованиями.
Организация работ по документированию ПС и ее оценивание в значительной степени определяют достигаемое качество документов, самих комплексов программ, трудоемкость и длительность их создания. Она должна определять стратегию, стандарты, процедуры, распределение ресурсов и планы создания, изменения и применения документов на программы и данные информационных систем.
В процессе установления стратегии, стандартов и руководств по документированию необходимо осуществить и оценить:
· выбор модели ЖЦ ПС, состава и назначения его документов;
· типы, содержание и степень детализации каждого документа;
· необходимое качество и технологию создания и оформления документов;
· содержание форматов и системы обозначения документов;
· распределение ресурсов: персонала; технических средств; финансов; на планирование документирования.
Официальная, описанная и утвержденная стратегия документирования должна устанавливать дисциплину для эффективного создания высококачественных документов на объекты и процессы в ЖЦ ПС. Для этого организаторы документирования должны обеспечить специалистов, создающих ПС:
· официальными отчетами и руководствами по принятой стратегии документирования конкретного проекта ПС;
· стандартами и нормативными документами, определяющими все аспекты документирования программ и данных;
· опубликованными описаниями инструментальных средств и рекомендуемыми процедурами автоматизированного документирования ПС, его компонентов и процессов;
· вычислительными, трудовыми и временными ресурсами для реализации документирования программ и данных;
· планами документирования как органической части всего ЖЦ конкретного ПС.
