Практические соображения (Practical Considerations)
Далее приведем некоторые практические соображения.
Требования к качеству программного обеспечения (Software Quality Requirements)
Начнем с факторов влияющих на результат.
Факторы влияния (Influence factors)
На планирование, управление и выбор SQM-действий и техник оказывают влияние различные факторы, среди которых:
· Область применения системы, в которой будет работать программное обеспечение (критичное для безопасности людей, критичное для бизнеса и т.п.).
· Системные и программные требования.
· Какие компоненты используются в системе – коммерческие (внешние) или стандартные (внутренние).
· Какие стандарты программной инженерии применимы в заданном контексте.
· Каковы методы и программные инструменты, применяемые для разработки и сопровождения, а также для обеспечения качества и совершенствования (продукта и процессов).
· Бюджет, персонал, организация проектной деятельности, планы и расписания для всех процессов.
· Кто целевые пользователи и каково назначение системы.
· Уровень целостности системы.
Информация об этих факторах влияет на то, как именно будут организованы и документированы процессы SQM, какие SQM-работы будут отобраны, какие необходимы ресурсы и каковы ограничения, накладываемые в отношении усилий, направляемых на обеспечение качества.
Гарантоспособность (Dependability)
Гарантоспособность – гарантия высокой надежности, защищенности от сбоев в случаях, когда сбой системы может привести к крайне тяжелым последствиям (такие системы называют «системы повышенной надежности», «высокой доступности» и т.п.).
|
|
|
Общая (совокупная) гарантоспособность системы (как сочетания аппаратной части, программного обеспечения и человеческого фактора) является главным и приоритетным требованием качества, по отношению к основной функциональности системы.
Гарантоспособность программного обеспечения включает следующие характеристики:
· защищенность от сбоев (fault-tolerance);
· безопасность использования (в смысле приемлемого риска для здоровья людей, бизнеса, имущества);
· информационная безопасность – защита информации от несанкционированных операций;
· доступ на чтение авторизованным пользователям (в объеме заданных для них прав);
· удобство и простота использования (usability).
Надежность (reliability) также является критерием, который может быть определен в терминах гарантоспособности (см. стандарт ISO/ IEC 9126-1:2001 «Software Engineering - Product
Quality, Part 1: Quality Model»).
В обсуждении данного вопроса применяется терминология, пришедшая из области традиционных механических и электрических систем (в т.ч. не включающих программное обеспечение) и описывающая концепции опасности, рисков, целостности систем и т.п.
|
|
|
Уровни целостности программного обеспечения (Integrity levels of software)
Уровень целостности программного обеспечения определяется на основании возможных последствий сбоя программного обеспечения и вероятности возникновения сбоя.
Когда важны различные аспекты безопасности (применения и информационной безопасности), при разработке планов работ в области идентификации возможных очагов аварий могут использоваться техники анализа опасностей и угроз (в информационной безопасности, security).
История сбоев аналогичных систем может также помочь в идентификации наиболее полезных техник, направленных на обнаружение сбоев и всесторонней оценки качества программного обеспечения.
Уровни целостности (например, градации целостности) предлагаются, в частности, стандартом IEEE 1012-98 «IEEE
Standard for Software Reviews».
При более детальном рассмотрении целостности программного обеспечения необходимо уделять особое внимание (выделяя соответствующие ресурсы и проводя необходимые работы) не только SQM-процессам (аудит, аттестация), но и аспектам управления требованиями.
Весьма важны вопросы:
· управления рисками (включая планирование рисков как на этапе разработки, так и на этапе эксплуатации и сопровождения системы);
|
|
|
· проектирования (которое, для повышения гарантоспособности, в обязательном порядке предполагает глубокий анализ и проверку планируемых к применению архитектурных и технологических решений, часто, посредством создания пилотных проектов, демонстрационных стендов и т.п.);
· тестирования (для обеспечения всестороннего исследования поведенческих характеристик системы, в том числе с эмуляцией рабочего окружения, в котором система должна использоваться в процессе эксплуатации).
Дата добавления: 2018-10-26; просмотров: 202; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!