ЛЕКЦИЯ 9. УРОВНИ КАЧЕСТВА ПРОГРАММНОЙ ПРОДУКЦИИ

1.     Основы качества программного обеспечения

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

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

Основой регламентирования показателей качества систем является меж- дународный стандарт ISO:

ISO 9126:1-4 «Характеристики и метрики качества программного обеспе- чения»;

ISO 14598-1-6:1998-2000 «Оценивание программного продукта».

Разработанный комплекс стандартов ISO 9126-1-4 состоит из четырех частей под общим заголовком «Информационная технология — качество про- граммных средств»:

Часть 1: Модель качества; Часть 2: Внешние метрики; Часть 3: Внутренние метрики;

Часть 4: Метрики качества в использовании.

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

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

Внутренние метрики — применяются в ходе проектирования и про- граммирования к неисполняемым компонентам системы, таким как специфика- ция или исходный программный текст.

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

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

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

Рис. 13

Качество программного обеспечения

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

Качество ПО является предметом стандартизации. Согласно ГОСТ 2844-94

качество ПО — совокупность свойств (показателей качества) ПО, которые

обеспечивают его способность удовлетворять потребности заказчика в соответ- ствии с его назначением. Этот стандарт регламентирует базовую модель качест- ва и показатели, главным среди которых является надежность. Стандарт 180/1ЕС12207 определил не только основные процессы ЖЦ разработки ПО, но и организационные и дополнительные процессы, которые регламентируют инже- нерию, планирование и управление качеством ПО.

Согласно этому стандарту на всех этапах ЖЦ разработки ПО должен проводиться следующий контроль качества ПО:

–           проверка соответствия требований проектируемому программному продукту и критериев их достижения;

–           верификация и аттестация (валидация) промежуточных результатов ПО на этапах ЖЦ и измерение степени удовлетворения достигаемых показателей;

–           тестирование готового ПО, сбор данных об отказах, дефектах и других ошибках, обнаруженных в системе;

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

–           оценка показателей качества, заданных в требованиях на разработку ПО.

Инспектирование качества — это процесс проверки качества, ориенти- рованный на команду разработчиков. Он применяется на всех этапах разработ- ки ПП.

Доказательство правильности — это математическая или логическая ме- тодика, используемая для убеждения себя и других в том, что программа делает то, что должна делать. Такое доказательство является формальным (строгим) методом.

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

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

ниматься на протяжении всего ЖЦ ПО. Не существует каких-то «стандартных» правил того, как именно необходимо принимать такие решения. Однако инже- неры должны быть способны представить различные альтернативы способов достижения различного уровня качества и их стоимость.

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

Качество ПО характеризуется тремя аспектами: качеством ПП, качеством процессов ЖЦ и качеством сопровождения или внедрения (рис. 14).

Рис. 14

Основные аспекты качества ПО

Аспект, связанный с процессами ЖЦ ПО, определяет степень формализа- ции, достоверности самих процессов ЖЦ разработки ПО, а также верификацию и валидацию (кратко — V&V) промежуточных результатов этих процессов. Поиск и устранение ошибок в готовом ПО проводятся методами тестирования, которые снижают количество ошибок и повышают качество этого продукта.

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

2.     Модель качества программного обеспечения

Модель качества ПО имеет четыре уровня представления.

Первый уровень соответствует определению характеристик (показателей) качества ПО, каждая из которых отражает отдельную точку зрения пользовате- ля на качество. Согласно существующим стандартам (ISO/IEC9126, ДСТУ 2844-1994, ДСТУ 2850-1994, ДСТУ 3230-1995) в модель качества входит шесть характеристик или шесть показателей качества (рис. 15): функциональность (functionality), надежность (realibility), удобство (usability), эффективность (efficiency), сопровождаемость (maitainnability), переносимость (portability).

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

Третий уровень предназначен для измерения качества с помощью мет- рик, каждая из которых, согласно стандарту 1SO/IEC9126, определяется как комбинация метода измерения атрибута и шкалы измерения его значений. Для оценки атрибутов качества на этапах ЖЦ ПО (при просмотре документации и программ, а также результатов тестирования программ) используются метрики

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

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

Рис. 15

Модель характеристик качества

Выбранные атрибуты и их приоритеты отражаются в требованиях на раз- работку системы, либо используются соответствующие приоритеты эталона класса ПО, к которому это ПО относится.

Показатели качества ПО:

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

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

Правильность (точность) — атрибут, который показывает степень дос- тижения правильных результатов.

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

щать несанкционированный доступ (случайный или умышленный) к програм- мам и данным.

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

К подхарактеристикам (субхарактеристикам) надежности ПО относятся следующие.

Безотказность — атрибут, который определяет способность ПО функ- ционировать без отказов (как программы, так и оборудования).

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

Восстанавливаемость — атрибут, который показывает способность ПО к перезапуску для повторного выполнения и восстановления данных после отка- зов.

К некоторым типам «критических систем» (реального времени, радарных, систем безопасности, коммуникаций и др.) предъявляются требования по обес- печению высокой надежности (недопустимость ошибок, точность, достовер- ность, удобство применения и др.). Надежность ПО в значительной степени за- висит от числа оставшихся и неустраненных ошибок в процессе его разработки на этапах ЖЦ. В ходе эксплуатации ошибки обнаруживаются и устраняются. Если при исправлении ошибок не вносятся новые или, по крайней мере, новых ошибок вносится меньше, чем устраняется, то в ходе эксплуатации надежность ПО непрерывно возрастает. Чем интенсивнее проводится эксплуатация, тем ин- тенсивнее выявляются ошибки и быстрее растет надежность ПО.

На надежность ПО влияют следующие факторы:

–           совокупность угроз, приводящих к неблагоприятным последствиям и к ущербу системы или среды ее функционирования;

–           угроза как проявление нарушения безопасности системы;

–           целостность как способность системы сохранять устойчивость работы и не иметь риска.

Обнаруженные ошибки могут быть результатом угрозы извне или отказов, они повышают риск и уменьшают некоторые свойства надежности системы.

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

–           измерение надежности, т. е. проведение ее количественной оценки с помощью предсказаний, сбора данных о поведении системы в процессе экс- плуатации, а также современных моделей надежности;

–           стратегии и метрики конструирования и выбора готовых компонентов, процесса разработки компонентной системы, а также среды функционирования, влияющей на надежность работы системы;

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

системы требованиям пользователя, которые были предъявлены заказчиком.

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

–           готовностью к использованию (availability);

–           готовностью к непрерывному функционированию (reliability);

–           езопасностью для окружающей среды, т. е. способностью системы не вызывать катастрофических последствий в случае отказа (safety);

–           секретностью и сохранностью информации (confidential);

–           способностью к сохранению системы и устойчивости к самопроизволь- ному ее изменению (integrity);

–           способностью к эксплуатации ПО, простотой выполнения операций об- служивания, а также устранения ошибок, восстановлением системы после их устранения (maintainability);

–           готовностью и сохранностью информации (security) и др. Достижение надежности системы обеспечивается предотвращением отказа (fault prevention) или его устранением (removal fault), а также оценкой возможности появления новых отказов и мер борьбы с ними.

Для численной оценки надежности используются методы теории вероят- ностей.

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

Удобство применения. Этот показатель характеризуется множеством ат- рибутов, определяющих необходимые пригодные условия использования ПО (например, диалоговое, недиалоговое) заданным кругом пользователей для по- лучения соответствующих результатов. В стандарте ДСТУ 2850-1994 удобство применения определено как множество атрибутов ПП, характеризующих его эргономичность:

–           понимаемость — атрибут, который определяет усилия, затрачиваемые на распознавание логических концепций и условий применения ПО;

–           изучаемость (легкость изучения) — атрибут, который определяет уси- лия пользователей, затрачиваемые на определение применимости ПО путем использования операционного контроля, диагностики, а также установленных процедур, правил, изложенных в документации;

–           оперативность — атрибут, который определяет реакцию системы при выполнении операций и операционного контроля;

–           согласованность — атрибут, который показывает соответствие разра- ботки требованиям стандартов, соглашений, правил, законов и предписаний.

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

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

–           эффективность ресурсов — атрибут, показывающий количество и про- должительность используемых ресурсов при выполнении функций ПО;

–           согласованность — атрибут, который показывает соответствие данного атрибута заданным стандартам, правилам и предписаниям.

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

–           анализируемостъ — атрибут, определяющий необходимые усилия для диагностики отказов или идентификации частей, которые будут модифициро- ваться;

–           изменяемость — атрибут, который определяет возможность удаления ошибок в ПО или внесение изменений для их устранения, а также введение но- вых возможностей в ПО или в среду функционирования;

–           стабильность — атрибут, указывающий на постоянство структуры и риск ее модификации;

–           тестируемость — атрибут, определяющий усилия при проведении ва- лидации и верификации ПО с целью обнаружения несоответствий требованиям, а также необходимость проведения модификации ПО и его сертификации;

–           согласованность — атрибут, который показывает соответствие данного атрибута соглашениям, правилам и предписаниям стандарта.

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

–           адаптивность — атрибут, определяющий усилия, затрачиваемые на адаптацию к различным средам;

–           настраиваемость (простота инсталляции) — атрибут, который опреде- ляет необходимые усилия для запуска данного ПО в специальной среде;

–           сосуществование — атрибут, который определяет возможность исполь- зования специального ПО в среде действующей системы;

–           заменяемость — атрибут, который обеспечивает возможность интер- операбельности при совместной работе с другими программами с необходимой инсталляцией или адаптацией ПО;

–           согласованность — атрибут, который определяет соответствие стандар- там или соглашениям по обеспечению переноса ПО.

КОНТРОЛЬНЫЕ ВОПРОСЫ

1.    Дайте определение термину «качество» в контексте программного обеспечения.

2.    Что такое «система качества»?

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

4.    Из скольких частей состоит стандарт ISO 9126 и как они называются?

5.    Что такое «метрики» в информационных технологиях и для чего они применяются?

6.    Чем отличаются внешние метрики от внутренних?

7.    Что измеряют «метрики качества в использовании»?

8.    Назовите три составляющие «метрики качества в использовании» (результативность, продуктивность, удовлетворенность) и кратко охарактеризуйте каждую из них.

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

10. Что такое «инспектирование качества» и на кого оно ориентировано?

11. Что подразумевается под «доказательством правильности» программы?

12. На какие категории может быть дифференцирована «стоимость качества»?

13. Назовите три основных аспекта, характеризующих качество ПО.

14. Сколько уровней представления имеет модель качества ПО и что представляет собой каждый уровень?

15. Перечислите шесть основных характеристик (показателей) качества ПО согласно стандарту ISO/IEC 9126.

16. Дайте определение характеристике «Функциональность».

17. Какие атрибуты входят в характеристику «Функциональность»? (Назовите не менее трёх).

18. Что такое «интероперабельность»?

19. Дайте определение характеристике «Надежность» ПО.

20. Какие субхарактеристики (подхарактеристики) относятся к надежности ПО?

21. Что такое «пригодноспособность» (dependability) в инженерии надежности и какие атрибуты она включает?

22. Как обеспечивается достижение надежности системы?

23. Охарактеризуйте показатель качества «Удобство применения». Какие атрибуты ему соответствуют?

24. Что понимается под «Эффективностью» программного обеспечения? Приведите примеры её атрибутов.

25. Дайте определение характеристике «Сопровождаемость».

26. Какие атрибуты определяют сопровождаемость ПО? (Назовите не менее трёх).

27. Что означает «Переносимость» программного обеспечения?

28. Какие атрибуты характеризуют переносимость ПО?

29. Какова связь между интенсивностью эксплуатации ПО и его надежностью?

30. Почему качество ПО считается относительным понятием?

31.   Что понимается под «объектом качества» в широком смысле, согласно лекции?

32.   Какой международный стандарт является основой для регламентирования показателей качества систем?

33.   Сколько частей включает комплекс стандартов ISO 14598 и каково его общее название?

34.   К каким типам программных систем применимы метрики в информационных технологиях?

35.   Что является объектом измерения для внутренних метрик?

36.   Что подразумевается под «результативностью» в контексте метрик качества в использовании?

37.   Как «продуктивность» соотносится с результативностью в метриках качества в использовании?

38.   Что измеряет «удовлетворенность» как составляющая качества в использовании?

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

40.   Что, согласно лекции, составляет основу инженерных методов в программировании?

41.   С какими техниками оценки качества ПО связаны динамические техники?

42.   Как программные требования влияют на критерии приемки ПО?

43.   Какой показатель качества считается главным в ГОСТ 2844-94?

44.   Какие процессы, помимо основных, регламентирует стандарт 180/1ЕС12207?

45.   Какой процесс контроля качества проверяет соответствие требований проектируемому продукту?

46.   В чем заключается цель подбора моделей надежности по результатам тестирования?

47.   На кого ориентирован процесс инспектирования качества?

48.   К какому типу методов относится доказательство правильности программы?

49.   Что может отражать результат компромисса при определении показателей качества?

50.   На какие две категории подразделяется стоимость сбоев в модели стоимости качества?

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

52.   На каком этапе жизненного цикла в идеале должно приниматься большинство решений о качестве?

53.   Какую роль играют инженеры в процессе принятия решений о качестве ПО?

54.   Что подразумевается под аспектом «качество сопровождения или внедрения»?

55.   Как методы тестирования влияют на качество программного продукта?

56.   От чего в значительной степени зависит эффект от внедрения программного средства?

57.   Что отражает каждая характеристика качества на первом уровне модели?

58.   Для чего используется набор атрибутов на втором уровне модели качества?

59.   Что такое «метрика» согласно стандарту ISO/IEC 9126?

60.   Для чего используются метрики с заданным оценочным весом?

61.   Что используется на четвертом уровне модели для оценки значения атрибута?

62.   Как выбираются характеристики и атрибуты качества для конкретного ПО?

63.   Что понимается под «функцией» программного обеспечения?

64.   Какие два типа функций упоминаются в лекции?

65.   Что измеряет атрибут «Функциональная полнота»?

66.   На что указывает атрибут «Правильность (точность)»?

67.   Что способность ПО предотвращать, согласно атрибуту «Защищенность»?

68.   Что не учитывается при определении надежности ПО в зависимости от времени?

69.   Из-за чего происходит снижение надежности ПО?

70.   Что такое «критические системы» и каковы к ним требования?

71.   От чего в значительной степени зависит надежность ПО на момент начала эксплуатации?

72.   Как влияет исправление ошибок на надежность ПО в ходе эксплуатации?

73.   Что такое «угроза» с точки зрения надежности системы?

74.   Что изучает инженерия программной надежности (Software reliability engineering)?

75.   Что включает в себя аспект «измерение надежности»?

76.   Для чего применяется верификация в инженерии надежности?

77.   Для чего применяется валидация в инженерии надежности?

78.   Что обозначает термин «пригодноспособность» (dependability)?

79.   Что означает атрибут «готовность к использованию» (availability)?

80.   Что означает атрибут «безопасность для окружающей среды» (safety)?

ЗАДАНИЯ К ЛЕКЦИИ

1.         Соотнесите вид метрики (1-3) с её определением (А-В):

1.         Внешние метрики

2.         Внутренние метрики

3.         Метрики качества в использовании

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

2.         Установите соответствие между этапом модели качества (1-4) и его описанием (А-Г):

1.         Первый уровень

2.         Второй уровень

3.         Третий уровень

4.         Четвертый уровень

А. Измерение качества с помощью метрик.
Б. Определение характеристик (показателей) качества.
В. Использование оценочного элемента метрики — веса.
Г. Определение атрибутов для каждой характеристики.

3.         Сопоставьте характеристику качества (1-6) с её ключевым атрибутом (А-Е):

1.         Функциональность

2.         Надежность

3.         Удобство применения

4.         Эффективность

5.         Сопровождаемость

6.         Переносимость

А. Восстанавливаемость
Б. Функциональная полнота
В. Анализируемость
Г. Адаптивность
Д. Реактивность
Е. Изучаемость

4.         Объясните разницу между верификацией и валидацией (V&V) в контексте процессов жизненного цикла ПО.

5.         Проанализируйте фразу: "Чем интенсивнее проводится эксплуатация, тем быстрее растет надежность ПО". Объясните, при каком условии это утверждение верно.

6.         В чем заключается относительность понятия "качество ПО"? Приведите гипотетический пример.

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

8.         Почему "инспектирование качества" ориентировано именно на команду разработчиков, а не на заказчика?

9.         Проанализируйте три аспекта качества ПО (качество продукта, процессов и внедрения). Какой из них, на ваш взгляд, является фундаментом для двух других? Обоснуйте свой ответ.

10.     Что общего у атрибутов "Согласованность" в разных характеристиках качества (например, в "Удобстве" и "Эффективности")?

11.     Восстановите пропуски в схеме обеспечения надежности: "Достижение надежности системы обеспечивается предотвращением отказа или его ______, а также ______ возможности появления новых отказов".

12.     Заполните таблицу, указав, к каким характеристикам качества (Функциональность, Надежность, Эффективность) относятся следующие атрибуты:

o     Защищенность

o     Безотказность

o     Эффективность ресурсов

o     Устойчивость к ошибкам

o     Правильность

o     Реактивность

13.     Закончите фразу: "Метрика качества определяется как комбинация метода измерения атрибута и ______ измерения его значений".

14.     Впишите недостающие элементы в модель характеристик качества по стандарту ISO 9126 (помимо Функциональности и Надежности):

o     Функциональность

o     Надежность

_

_____

o     Сопровождаемость

o     Переносимость

15.     Компания разрабатывает мобильное приложение для онлайн-банкинга. Какая характеристика качества будет для него приоритетной и почему? Назовите не менее трёх атрибутов этой характеристики, важных для данного приложения.

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

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

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

19.     Вам нужно выбрать одну из двух библиотек для использования в проекте. Одна хорошо документирована и легко интегрируется, но немного медленнее. Другая — очень быстрая, но её код сложен для понимания. О каких характеристиках качества идёт речь? Какие компромиссы (trade-offs) вам придется учесть?

20.     Предложите, какие виды контроля качества (из перечисленных в лекции) должны применяться на этапе написания исходного кода, а какие — на этапе приемочных испытаний.

21.     Дайте развернутое определение "Качества в использовании". Почему оно измеряется в терминах результатов, а не внутренних свойств ПС?

22.     Что такое "инженерные методы в программировании" и какова их основная цель, согласно лекции?

23.     Раскройте смысл термина "пригодноспособность" (dependability), перечислив не менее четырех входящих в него атрибутов.

24.     Опишите, как связаны между собой "стоимость оценки" качества и "стоимость внешних сбоев".

25.     В чем разница между "изменяемостью" и "стабильностью" в контексте сопровождаемости ПО?

26.     Чем атрибут "Сосуществование" (переносимость) отличается от "Интероперабельности" (функциональность)?

27.     Какие факторы, согласно лекции, влияют на надежность ПО?

28.     Объясните, что означает "доказательство правильности" программы и почему оно относится к формальным методам.

29.     Как атрибут "Тестируемость" (сопровождаемость) влияет на процесс валидации и верификации ПО?

30.     Сравните атрибуты "Настраиваемость" (переносимость) и "Адаптивность" (переносимость). Приведите пример для каждого.

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

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

33. Разработка MVP для стартапа

Стартап разрабатывает MVP (минимально жизнеспособный продукт) для быстрого выхода на рынок и проверки гипотезы. Руководство настаивает на максимальном упрощении и скорости разработки в ущерб всему остальному. Какие характеристики качества, согласно лекции, являются наиболее приемлемыми для "жертвования" на этом этапе, а какие — категорически нельзя игнорировать, даже в MVP? Аргументируйте свой ответ.

34. Проблемы с переносом системы в "облако"

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

35. Сравнение двух библиотек для шифрования

Разработчик выбирает между двумя библиотеками для реализации функции шифрования. Библиотека "А" имеет сертификат соответствия стандартам и отличную документацию по безопасному использованию, но медленнее. Библиотека "Б" — чрезвычайно быстрая, но ее код сложен для аудита, а документация скудна. Для проекта важны и производительность, и безопасность. О каких двух характеристиках качества идет речь? Какой компромисс (trade-off) приходится делать разработчику и какую библиотеку, исходя из приоритета безопасности, следует выбрать?

36. Планирование тестирования для системы "Умный дом"

Вы являетесь тест-менеджером проекта по разработке системы управления "Умным домом" (отопление, освещение, безопасность). Система должна работать 24/7. Составьте перечень из 3-4 характеристик качества (из модели ISO 9126), которые будут иметь наивысший приоритет при тестировании. Для каждой характеристики обоснуйте ее важность и предложите один пример тестового сценария для ее проверки.

37. Анализ провала запуска онлайн-игры

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

38. Приоритизация доработок для мобильного приложения

По результатам сбора обратной связи от пользователей мобильного приложения выявлены три основные претензии:

1.         "Приложение постоянно вылетает при переходе в определенный раздел."

2.         "Очень неудобный и запутанный интерфейс, чтобы найти нужную функцию."

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

39. Обоснование инвестиций в качество кода

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

40. Разработка требований для медицинского ПО

Формируется техническое задание на разработку программного обеспечения для аппарата МРТ. Какие характеристики качества должны быть признаны "критическими" в данном контексте? Для каждой выбранной критической характеристики назовите не менее двух атрибутов из лекции, на которые необходимо сделать особый акцент, и обоснуйте, почему именно они важны для безопасности пациентов и эффективности работы медперсонала.

41. Выбор методологии разработки для FinTech-стартапа
Стартап в области финансовых технологий выбирает между гибкой методологией (Agile) и каскадной моделью (Waterfall). Какие аспекты качества ПО (из трех основных: продукт, процесс, внедрение) будут наиболее сильно затронуты этим выбором? Обоснуйте, как каждый аспект качества может выиграть или проиграть в зависимости от выбора.

42. Аудит кода открытой библиотеки
Ваша команда рассматривает возможность использования сторонней open-source библиотеки. Какие внутренние метрики качества вы могли бы попытаться оценить, просто изучая ее исходный код и документацию? Назовите не менее трех и объясните, что именно вы будете оценивать.

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

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

45. Команда не рефакторит код
Разработчики боятся вносить изменения в старый код, так как он плохо документирован, а модульные тесты отсутствуют. Они предпочитают писать "костыли" вокруг проблемных мест. Критическое падение каких двух атрибутов из характеристики "Сопровождаемость" наблюдается в данной ситуации?

46. Деплой в продакшен каждый день
Компания внедрила практику непрерывной поставки ПО (Continuous Deployment), выкатывая новые версии в продакшен по несколько раз в день. Как эта практика, при правильной организации, влияет на надежность ПО в долгосрочной перспективе? Объясните, ссылаясь на механизм роста надежности, описанный в лекции.

47. Разработка прототипа для демонстрации инвестору
Команда создает "демку" продукта для показа инвесторам. Прототип должен эффектно выглядеть, но его внутренняя реализация не важна. На какие виды контроля качества (из перечисленных в лекции) можно сознательно закрыть глаза на этом этапе, а какие — все же необходимо провести?

48. Сравнение двух моделей обеспечения надежности
В лекции упоминаются два подхода к обеспечению надежности: предотвращение отказа (fault prevention) и устранение отказа (fault removal). Сравните эти подходы с точки зрения "стоимости качества". Какой подход, вероятно, обойдется дороже на ранних этапах, а какой — может привести к высоким затратам на поздних?

49. Процесс "Согласованности"
Атрибут "Согласованность" встречается в описании нескольких характеристик качества (Удобство, Эффективность, Сопровождаемость, Переносимость). Что общего в его значении для всех этих случаев? Почему этот атрибут так важен для системного подхода к качеству?

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

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

52. Проблемы с локализацией продукта
При переводе интерфейса программы на арабский язык (который читается справа налево) весь пользовательский интерфейс "поломался". Недостаток какого атрибута переносимости проявился в этой ситуации?

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

54. Документирование API
Ваш проект предоставляет API для интеграции с другими системами. Качество документации на это API напрямую влияет на атрибут "Интероперабельность". Объясните, как именно хорошая документация способствует улучшению этого атрибута.

55. "Золотая мастер-версия"
В игровой индустрии существует понятие "gold master" — финальная версия продукта, которая уходит на тиражирование. Почему процесс инспектирования качества и верификации на этапе создания этой версии имеет критически важное значение, даже если игра уже extensively тестировалась?

56. Унаследованная система и новые регулятивы
Государственное учреждение вынуждено адаптировать свое старое, но жизненно важное ПО под новые требования законодательства. Процесс адаптации крайне сложен. О низком уровне какого атрибута сопровождаемости это свидетельствует в первую очередь?

57. A/B тестирование дизайна интерфейса
Компания проводит A/B тестирование двух вариантов пользовательского интерфейса, измеряя скорость выполнения задач и количество ошибок пользователей. Оценку каких метрик качества в использовании она по сути проводит?

58. Принцип "Не навреди" в медицине и в ПО
В лекции упоминается, что для критических систем безопасность (safety) — это способность не вызывать катастрофических последствий. Является ли атрибут "Безопасность" (safety) частью характеристики "Надежность" в модели ISO 9126? Если нет, то в рамках какого более широкого понятия (из лекции) он рассматривается?

59. Миграция с Windows на Linux
Компания решила перевести весь парк рабочих компьютеров с Windows на Linux. Какие атрибуты характеристики "Переносимость" их корпоративного ПО будут затронуты в первую очередь? Назовите не менее двух.

60. Расчет Return on Investment (ROI) в качество
Менеджер проекта требует обосновать затраты на внедрение статического анализатора кода. С помощью какой категории "стоимости качества" (из лекции) можно аргументировать, что эти затраты помогут сэкономить деньги в будущем? Приведите логическую цепочку.

61. Система сбора Big Data
Разрабатывается система для сбора и первичной обработки огромных массивов данных в реальном времени. Ее основная задача — не потерять входящие данные. Какая субхарактеристика надежности является абсолютным приоритетом? Обоснуйте.

62. Программа для обучения детей
Создается интерактивное образовательное приложение для детей младшего школьного возраста. Какие атрибуты характеристики "Удобство применения" выйдут на первый план и почему?

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

64. Отказоустойчивый кластер
Для обеспечения высокой доступности (availability) система развернута в виде кластера с автоматическим переключением при отказе одного из узлов. Реализация какой субхарактеристики надежности лежит в основе этого решения?

65. Сравнение двух моделей лицензирования
Компания выбирает между двумя библиотеками: одна — платная с полной технической поддержкой, вторая — бесплатная, но с сообществом в качестве поддержки. С точки зрения сопровождаемости будущего продукта, какой фактор, помимо технических атрибутов, необходимо учесть?

66. Процесс "непрерывной интеграции" (Continuous Integration)
Постоянное автоматизированное тестирование каждого изменения в коде (CI) напрямую способствует улучшению нескольких характеристик качества. Назовите две из них и объясните, как CI на это влияет.

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

68. Система с "вечным" циклом работы
Разрабатывается ПО для метеорологического спутника, которое не может быть обновлено или перезапущено после запуска. Какие атрибуты надежности и сопровождаемости имеют для него уникальное значение, отличное от обычного десктопного приложения?

69. Рефакторинг vs. Новая функциональность
Тимлид спорит с продакт-менеджером о выделении времени на рефакторинг. Продакт-менеджер говорит: "Мы не можем измерить отдачу от рефакторинга для пользователя". Прав ли он с точки зрения качества в использовании? Дайте развернутый ответ.

70. Пост-релизный анализ дефектов
После выхода крупного обновления команда анализирует статистику обнаруженных дефектов: 70% ошибок были связаны с изменениями в старом коде. О чем это свидетельствует с точки зрения атрибутов сопровождаемости и какой вывод должна сделать команда?

71. Решение о «ручном» управлении качеством
Небольшая команда из 3-х человек разрабатывает нишевый продукт. Тимлид утверждает, что им не нужны формальные процедуры и метрики качества, так как «все всё видят в коде». С какими рисками в долгосрочной перспективе они столкнутся, особенно в аспекте качества процессов и сопровождаемости?

72. Проблема «исчезающего» бага
Пользователь сообщил о критическом баге. Разработчики не могут его воспроизвести на своих тестовых стендах, но он периодически возникает у заказчика. Нехватка какого атрибута надежности (субхарактеристики) мешает локализовать и устранить проблему?

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

74. Система, которая «не стареет»
Заказчик хочет, чтобы ПО для промышленного станка работало без изменений 20 лет. Какие атрибуты переносимости становятся критически важными с учетом того, что за это время сменится несколько поколений операционных систем и аппаратного обеспечения?

75. «Слепое» тестирование производительности
Тестировщики получили задание проверить «Эффективность» системы, но не имеют доступа к внутренним метрикам (потребление CPU, памяти). Какие внешние метрики они могут использовать для оценки атрибутов «Реактивность» и «Эффективность ресурсов»?

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

77. Разработка API для мобильных приложений
Создается бэкенд для мобильного приложения, которое будет работать в условиях нестабильного и медленного интернета. Помимо Функциональности, какие две характеристики качества бэкенд-API должны быть приоритетными? Назовите по одному ключевому атрибуту для каждой и обоснуйте их важность.

78. «Качество» как инструмент маркетинга
Отдел маркетинга хочет использовать фразу «Наше ПО — самое качественное на рынке» в рекламной кампании. Какие шесть характеристик модели ISO 9126 они должны быть готовы детально проиллюстрировать и доказать, чтобы это заявление не было голословным?

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

80. Катастрофический отказ и расследование
Произошел сбой системы, приведший к значительным финансовым потерям. Расследование показало, что ошибка была в требовании, которое никто не проверил на корректность на ранней стадии. Какой из видов контроля качества на этапах ЖЦ, указанный в лекции, не был выполнен, и к какой категории «стоимости качества» относятся последовавшие убытки?

3. Формирование требований к характеристикам и качеству программных продуктов

3.1 Общие требования к качеству функционирования программных продуктов

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

·         формирование функциональных и конструктивных требова- ний к программным продуктам, требования к допустимым рискам и проверку их корректности;

·         организацию сертификационных испытаний программных продуктов на соответствие требованиям, предварительный выбор стратегии, планирование и оценки затрат на испытания;

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

·         Программы, методики и процессы испытаний программных продуктов, а также эксплуатационной документации на соответствие требованиям к программным продуктам;

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

Для сертификации программных продуктов, прежде всего, необходимо понимать их основные свойства, уметь выделить и фор- мализовать требуемые характеристики. Базовые международные стандарты определяют основные требования к качеству комплексов программ для их сертификации (см. Приложение). Непосредственно к характеристикам качества программных средств относится группа стандартов, в которую входят нормативные документы, регламен- тирующие формализацию требований к метрикам качества комплек- сов программ, методы и процессы их выбора и измерения. Эта группа является важнейшей для достижения и гарантирования высокого ка- чества программного продукта. Тщательное специфицирование требований к качеству программного продукта  ключевой фак- тор обеспечения их сертификации и адекватного применения. Это может быть достигнуто на основе выделения и определения подхо- дящих характеристик качества с учетом целей использования и функ- циональных задач комплекса программ [3, 9, 12].

Основой для формирования требований к характеристикам ком-

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

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

При выборе минимума стандартизируемых показателей качества целесообразно учитывать следующие принципы:

·         ясность и измеряемость значений показателей;

·         соответствие установившимся понятиям и терминологии;

·         возможность последующего уточнения и детализации;

·         отсутствие перекрытия между используемыми показателями;

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

Для сертификации качества функционирования рекомендуется следующая  система  основных  функциональных  показателей  для обеспечения функциональной адекватности программного средст- ва:

·         соответствие реальных функциональных возможностей ПС декларируемым в программной документации;

·         соответствие реальных функциональных возможностей аппа- ратных средств декларируемым в технической и эксплуатационной документации;

·         обеспечение точности обработки безошибочной и актуальной исходной информации с помощью ПС для получения в итоге доста- точно достоверной используемой информации;

·         соответствие требованиям функциональных стандартов в об- ласти взаимодействия, сопровождаемости и переносимости ПС на различные вычислительные платформы в его жизненном цикле;

·         соответствие требованиям нормативных документов по вы- полнению мер обеспечения защищенности информационных и про- граммных ресурсов ПС от несанкционированного доступа.

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

·         средняя наработка на отказ программно-технических средств системы;

·         среднее время восстановления ПС и системы после отказа;

·         коэффициент готовности ПС и системы;

·         среднее время реакции ПС на запрос и/или на выполнение технологических операций;

·         вероятность своевременного представления запрашиваемой информации и/или выполнения технологических операций;

·         вероятность  сохранения     актуальности  информации    в          базе данных на момент ее использования в системе;

·         вероятность предотвращения несанкционированного доступа к программным и информационным ресурсам системы;

·         вероятность сохранения конфиденциальности выходной ин- формации системы.

Системная эффективность целевого применения программ- ных продуктов в стандарте ISO 9126 определяется степенью удовле- творения потребностей определенных лиц – заказчиков и/или пользо- вателей, которые, в ряде случаев, желательно измерять экономиче- скими категориями: прибылью, стоимостью, трудоемкостью, предот- вращенным ущербом, длительностью применения и т.п. В стандартах эта эффективность отражается основной, обобщенной характеристи- кой качества – функциональная пригодность.

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

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

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

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

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

В результате совокупности требо- ваний к тестам могут применяться как эталоны и вторая адек- ватная форма описания требований к комплексу программ для сквозной верификации спецификаций требований к тестам сверху вниз, а также сами подвергаться верификации на корректность соот ветствия исходным требованиям к функциям и характеристикам ком- понентов программ разного уровня.

Функциональные требования – определяют поведение про- граммного продукта, который должен быть создан разработчиками для предоставления возможности выполнения заказчиком и/или пользователями своих обязанностей в контексте пользовательских требований. Выбор требований к характеристикам при проектирова- нии программных средств начинается с определения исходных дан- ных. Для корректного выбора и установления требований к характеистикам качества, прежде всего, необходимо определить основные особенности программного продукта (Рис. 7.3).

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

·         цели создания программного продукта и назначение комплек- са функциональных задач;

·         общие требования к функциям и характеристикам комплекса задач программного средства;

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

•     периодичность и продолжительность решения комплекса за-

дач;

•     связи и взаимодействие комплекса задач с внешней средой и

другими компонентами системы;

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

Проекты, как правило, инициируются заказчиком с объемом функциональных возможностей, превышающим тот, который раз- работчик может реализовать, обеспечив приемлемое качество при за- данных ресурсах. Тем не менее, необходимо ограничиваться, чтобы иметь возможность предоставить в срок достаточно целостный и качественный программный продукт. Существуют различные ме- тоды задания очередности выполнения (приоритеты) требований и понятие базового уровня - совместно согласованного представления о том, в чем будут состоять ключевые функции системы, как продук- та проекта - понятие состава требований, задающих ориентир для принятия решений и их оценки [1, 9, 17].

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

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

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

Время или допустимая длительность разработки является невос- полнимым ресурсом. Этот ресурс все больше определяет требования к ка- честву комплексов программ в процессе их разработки и сопровождения. Жесткие требования заказчиков к срокам реализации проектов, естествен- но, ограничивают разработчиков и испытателей. Увеличение числа при- влекаемых для этого специалистов только в некоторых пределах позволяет ускорять разработку. Радикальный способ увеличения реальных затрат на разработку и испытания в ограниченное время состоит в систематизации, планировании и автоматизации на всех этапах жизненного цикла комплек- са программ.

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

Особые классы функциональных задач решаются динамиче- скими системами и программными продуктами реального време- ни. Такие современные функциональные задачи и системы быстро растут по сложности, по размеру комплексов программ и потребной производительности вычислительных машин. Они широко применя- ются во всех отраслях промышленности, в управлении народным хо- зяйством и в оборонной технике. Для динамического решения таких задач необходима разработка и применение специального класса программных средств для управления вычислительными процессами – операционных систем реального времени. Они должны оптимизи- ровать динамическое использование различных ресурсов и произво- дительности ЭВМ при интенсивных потоках информации из внешней среды от различных объектов, при разнообразии последовательно- стей и длительностей динамического решения отдельных функцио- нальных задач.

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

Требования к операционным системам реального времени для автоматизации управления и обработки информации о динамических объектах состоят в следующем:

в процессах управления и решения функциональных задач в ЭВМ должно использоваться единое реальное время систем управле- ния и обработки информации динамических объектов, а также внеш- ней среды;

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

·         информация в сообщениях от источников и объектов внеш- ней среды должна содержать реальное время, к которому относятся сообщения, их координаты и характеристики состояния;

·         реальное время решения различных функциональных задач должно эффективно упорядочиваться в соответствии с установленной дисциплиной диспетчеризации, определенной при производстве сис- темы, и реальным временем приема информации из внешней среды;

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

·         для эффективного использования ограниченных ресурсов производительности и оперативной памяти ЭВМ целесообразно при- менять приоритеты и временное прерывание исполнения некоторых программ в соответствии с выбранными дисциплинами последова- тельности решения различных функциональных задач;

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

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

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

·         требования к количественным, измеряемым характери- стикам, непосредственно влияющим на оперативное функциониро- вание и возможность применения программного продукта в системе, в которые входят требования к надежности, безопасности, произво- дительности, допустимым рискам применения;

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

Формализация требований к качеству программных продуктов могут проводиться с двух позиций: с позиции положительной, обеспечения эффективности и непосредственной адекватности их ха- рактеристик качества – назначению, целям создания и применения программного продукта, а также с негативной позиции возможного при этом ущерба – допустимого риска от дефектов и недостатков при применении комплекса программ или системы. Характеристики качества и риски объектов и процессов обычно тесно связаны, на них влияют подобные внутренние и внешние факторы, которые с разных сторон отражаются на свойствах систем или комплексов программ. Требуемые и реальные характеристики качества влияют на риски, а остающиеся риски влияют на характеристики качества программного продукта. Повышению характеристик качества проек- та обычно сопутствует снижение его рисков и наоборот, сокраще- ние рисков способствует улучшению характеристик качества и по- вышению функциональной пригодности. Их сбалансированное взаимовлияние должно обеспечивать требуемую функциональную пригодность программного продукта [3, 10, 12].

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

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

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

Чтобы протестировать требования на значимость, следует со- поставить требования и сформулированные цели разработки про- граммного продукта:

·         способствует ли требование достижению целей проекта;

·         если исключить требование, помешает ли это достижению це-

лей;

·         существуют ли другие требования, которые зависят от дан-

ного.

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

3.2 Особенности требований заинтересованных лиц к  программному продукту

При разработке требований к комплексу программ необходи- мо выделять и ранжировать по приоритетам заинтересованных лиц, которым необходимы определенные функции и показатели каче- ства программного продукта с учетом их специализации и профес- сиональных интересов. Широкая номенклатура характеристик, пред- ставленная в стандарте ISO 9126, определяет разнообразные требова- ния, из которых следует селектировать и выбирать те, которые необ- ходимы с позиции потребителей этих данных [7, 17]:

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

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

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

·         специалистов сопровождающих и модифицирующих ком- плекс программ, которые отдают приоритет характеристикам, под- держивающим сопровождение и конфигурационное управление вер- сиями комплекса и его компонентов;

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

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

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

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

Команда разработчиков должна применить методы и процессы для того, чтобы понять решаемую проблему заказчика до начала разработки программного комплекса. Для этого следует использо- вать анализ, выявление и освоение проблемы и интересов заказчи- ка:

·         достигнуть соглашения между заказчиком и разработчиком по определению проблемы, целей и задач проекта;

·         выделить основные причины - проблемы, являющиеся их ис- точниками и стоящие за основной проблемой проекта системы и ПС;

·         выявить заинтересованных лиц и пользователей, чье коллек- тивное мнение и оценка в конечном итоге определяет успех или не- удачу проекта;

·         определить, где приблизительно находятся область и границы возможных решений проблем;

·         понять ограничения, которые будут наложены на проект, ко- манду и решения проблем.

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

·         интервьюирования и анкетирования - создание структуриро- ванного интервью;

·         проведение интервью с пользователями и/или заинтересован- ными лицами;

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

·         совещания, посвященные анализу и синтезу требований - формулирование и определение целей программного продукта; озна- комление с ними всех участников проекта и установление, что они с ними согласны; если это не так, следует остановиться и уточнениями добиться согласия;

·         анализ иллюстративных прецедентов в приложении к кон- цепции требований, чтобы их функции были наглядны и понятны;

·         по возможности выявление или создание прототипов на осно- ве первичных требований.

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

3.3 Требования к надежности функционирования программных продуктов

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

При применении понятий надежности к программным комплек- сам следует учитывать особенности и отличия этих объектов от традиционных технических систем, для которых первоначально разрабатывалась теория надежности:

·         не для всех видов программ применимы понятия и методы те- ории надежности - их можно использовать только к программным продуктам, функционирующим в реальном времени и непосредст- венно взаимодействующим с внешней средой;

·         при разработке и оценке качества программных компонентов к ним не применимы понятия надежности функционирования, если при обработке информации они не используют значения реального времени;

·         доминирующими факторами, определяющими значения на- дежности программ, являются дефекты и ошибки проектирования и разработки, и второстепенное значение имеет физическое разрушение программных компонентов при внешних воздействиях;

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

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

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

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

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

Завершенность: свойство комплекса программ не попадать в состояния отказов вследствие ошибок и дефектов в программах, дан- ных и внешней среде.

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

  Восстанавливаемость: свойство комплекса программ в случае отказа возобновлять требуемый уровень качества функционирования, а также поврежденные программы и данные. После отказа, про- граммный продукт иногда может быть неработоспособен в течение некоторого времени, продолжительность которого определяется его восстанавливаемостью в процессе перезапуска - рестарта. Переза- пуск должен обеспечивать возобновления нормального функциони- рования ПС, на что требуются ресурсы ЭВМ и время. Поэтому пол- нота и длительность восстановления функционирования после сбоев отражают качество и надежность программного продукта, и возмож- ность его использования по прямому назначению.

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

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

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

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

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

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

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

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

3.4. Требования к функциональной безопасности программных продуктов

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

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

·         дефекты методов, алгоритмов и функционального содержа- ния процессов, принятых для решения задач обеспечения безопасно- сти для корректного применения системы по ее назначению;

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

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

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

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

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

Требования к обеспечению функциональной безопасности программных продуктов - установлены в международном стандарте IEC 61508:3. В нем представлен общий подход к видам деятельности на протяжении цикла обеспечения безопасности для систем, содер- жащих программируемые электронные компоненты систем (ПЭС), которые используются для выполнения различных функций и, в част- ности, для обеспечения безопасности систем. Стандарт IEC 61508-3 содержит:

·         метод разработки спецификаций требований по безопасности ПЭС, необходимых для достижения заданной функциональной безо- пасности;

·         основанный на рисках подход, для определения требований к уровням соответствия комплексу требований на функциональную безопасность;

·         устанавливаются количественные меры отказов для систем безопасности ПЭС, связанные с уровнями соответствия комплексу требований систем по функциональной безопасности;

·         требования для этапов жизненного цикла обеспечения безо- пасности и деятельности, которая должна проводиться при проекти- ровании и разработке программного продукта, обеспечивающего безопасность;

·         требования для информации, относящейся к аттестации про- граммных продуктов, которая должна передаваться организациям, производящим компоновку ПЭС в составе системы;

·         требования, которые должны выполнять организации, произ- водящие модификацию программного продукта, обеспечивающего безопасность;

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

Цикл обеспечения требований безопасности при разработке комплекса программ должен быть выбран и задан при планировании безопасности для практических нужд проекта или предприятия. Вдеятельность, связанную с циклом обеспечения безопасности, долж- ны быть включены процедуры гарантирования качества и безопасно- сти. Рекомендуется использовать основные положения, комплекс этапов и работ, представленный в стандарте ISO 12207. Специфика- ция требований по безопасности программного продукта должна быть достаточно подробной для того, чтобы конструкция и ее выпол- нение достигали требуемого соответствия комплексу требований по безопасности, и можно было произвести оценку функциональной безопасности. В спецификации должны быть требования к функци- ям безопасности:

·         обеспечивающие достижение и поддержание безопасного со- стояния программного продукта или системы;

·         относящиеся к выявлению отказов; извещения об их наличии и управление отказами в аппаратуре; отказами исполнительных ме- ханизмов, а также в программном продукте;

·         относящиеся к периодической проверке функций обеспечения безопасности в оперативном режиме и в отключенном состоянии.

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

Требования к информационной безопасности комплексов про- грамм формализует стандарт ISO 15408:1-3 [17]. Он состоит из трех частей, отражающих требования и рекомендации по обеспечению безопасности систем, содержащих программные средства. Первая часть определяет концепцию всего стандарта, а вторая самая большая часть формализует методы обеспечения безопасности. Его третья часть полностью посвящена требованиям и процессам обеспечения доверия – (качества) компонентов систем, реализующих функции их безопасности. Положения этой части стандарта трактуются с по- зиции обеспечения функциональной безопасности, а термин – дове- рие применяется как понятие качество или уверенность выполне- ния методических и технологических требований безопасности. Рекомендуется ряд шагов для предотвращения уязвимостей, возни- кающих в продуктах и системах, которые могут проявляться вслед- ствие недостатков:

·         требований - программный продукт или система могут обла- дать требуемыми от них функциями и свойствами, но содержать ме- тодические или алгоритмические уязвимости, которые делают их не- пригодными или неэффективными в части безопасности применения;

·         проектирования - программный продукт или система не от- вечают спецификации, и/или уязвимости, являются следствием нека- чественных процессов проектирования и производства или непра- вильных проектных решений;

·         эксплуатации - программный продукт или система разрабо- таны в полном соответствии с корректными спецификациями требо- ваний, но уязвимости возникают как результат неадекватного приме- нения и/или управления при эксплуатации.

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

Активное исследование доверия – это оценка процесса функ- ционирования системы для определения свойств безопасности. В стандарте применяется иерархия детализации требований к безо- пасности и качеству систем и комплексов программ с использовани- ем специфических терминов: класс – наиболее общая характеристика качества, которая структурируется семейством. Каждое семейство может иметь несколько компонентов – атрибутов, состоящих из элементов качества. Семейство доверия (качества) в стандарте мо- жет содержать один или несколько компонентов доверия и требова- ний для выполнения.

Класс руководства по безопасности определяет требования, направленные на обеспечение понятности, достаточности и закон- ченности эксплуатационной документации, представляемой разра- ботчиком. Руководство администратора – основной документ, имею-

щийся в распоряжении разработчика, для предоставления админист- раторам объекта, детальной и точной информации о том, как осуще- ствлять администрирование безопасным способом и эффективно ис- пользовать доступные процедуры обеспечения безопасности. Требо- вания к руководству пользователя должны обеспечивать возможность эксплуатировать объект безопасным способом.

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

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

Для систематичного применения классов и семейств требо- ваний, в стандарте ведено понятие профиль защиты (ПЗ) – незави- симая от реализации совокупность требований безопасности для не- которой категории объектов, отвечающая специфическим требовани- ям проекта и потребителя. Цель разработки и оценки ПЗ – показать, что он является полным, непротиворечивым, технически правильным и поэтому пригоден для изложения конкретных требований к одному или нескольким типам объектов. Задание по безопасности (ЗБ) – со-вокупность требований и спецификаций, предназначенная для ис- пользования в качестве основы для оценки конкретного объекта, что оно является полным, непротиворечивым, технически правильным и поэтому пригодно для использования в качестве основы при оценке уровня безопасности соответствующей системы.

3.5 Требования к производительности и эффективности динамического использования ресурсов ЭВМ программным продуктом в реальном времени

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

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

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

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

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

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

·         в режиме кратковременной, аварийной перегрузки, способной критически отражаться на функциональной пригодности, надежности и безопасности применения программного продукта.

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

3.6 Требования к допустимым рискам динамического применения программных продуктов

В предыдущих разделах рассматривались требования к характе- ристикам качества, которые отражают положительные свойства про- граммных комплексов и их следует улучшать. Однако, не смотря на их реализацию в проектах комплексов программ, могут проявляться негативные свойства, которые проявляются ущербом – риском при разработке и/или применении программного продукта. К таким свой- ствам – рискам при создании программных продуктов должны фор- мироваться требования, ограничивающие их до допустимых за- данных пределов (стандарт ISO 16085). Для обеспечения требуемых

характеристик качества функционирования программного продукта необходима организация контрмер процесса управления рисками под руководством менеджера управления рисками – координатора взаимодействия заказчика и разработчиков, прежде всего, при обес- печении функциональной пригодности и обосновании проекта [14, 16, 18].

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

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

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

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

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

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

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

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

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

·         определение ценности (приоритета) и выделение каждой требуемой характеристики для реализации необходимой функ- циональной пригодности программного продукта и системы;

·         определение приоритетов характеристик качества, компонен- тов и этапов ЖЦ проекта, которые имеют потенциальные техниче- ские, стоимостные или плановые риски;

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

·         оценивание уязвимости и последствий дефектов каждой ха- рактеристики и затрат ресурсов для восстановления требуемой функ- циональной пригодности системы и программного продукта при про- явлении рисков;систематизацию, документирование и оценивание эффектив- ности доступных методов, средств и ресурсов контрмер для сокра- щения рисков функциональной пригодности и выделенных характе- ристик комплекса программ;

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

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

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

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

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

·         экономические риски – превышение разработчиком обос- нованных, допустимых по контракту размеров стоимости, трудоемко- сти и эксплуатационных затрат на программные компоненты и про- дукт в целом, которые могут также отражаться на их функциональной пригодности и других характеристиках качества;

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

·         кадровые риски – недостаточная квалификация и число спе- циалистов, отражающаяся на рисках качества разработки, совершен- ствования и/или применения комплекса программ;

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

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

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

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

·         выявление и идентификация, относящихся к проекту ком- плекса программ, рисков, как в исходном состоянии и требованиях к проекту, так и на последовательных этапах его выполнения: по харак- теристикам качества, графикам, трудоемкости, ресурсам и техниче- ским рискам;

·         анализ вероятности проявления, причин, взаимозависимости видов и последствий рисков, чтобы сбалансировать и распределить их приоритеты, на основании которых будут отводиться ресурсы на различные контрмеры для снижения этих рисков;

КОНТРОЛЬНЫЕ ВОПРОСЫ

3.1 Общие требования к качеству функционирования программных продуктов

1.      Что должны обеспечивать цели, методы и схема процессов сертификации программного продукта?

2.      Назовите основные этапы процесса сертификации программного продукта.

3.      Что является важнейшей группой стандартов для достижения и гарантирования высокого качества ПО?

4.      Что понимается под «качеством функционирования» программного продукта?

5.      На основе чего формируется номенклатура и значения показателей качества программного продукта?

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

7.      Какие группы лиц должны быть охвачены при оценке комплекса программ?

8.      Какой стандарт определяет системную эффективность целевого применения программных продуктов?

9.      Что такое «функциональная пригодность» программного продукта?

10.  В чем разница между требованиями «что» должен делать продукт и «как» он это должен делать?

11.  Что является основными исходными данными для установления значений всех остальных стандартизированных показателей качества?

12.  Что имеет наибольшее значение для реального обеспечения качества при сертификации?

13.  Как могут применяться требования к тестам, помимо их прямого назначения?

14.  Что определяют функциональные требования?

15.  С чего начинается выбор требований к характеристикам при проектировании ПО?

16.  Что должно формироваться на основе анализа основных особенностей программного продукта?

17.  Почему важно ограничивать объем функциональных возможностей на начальном этапе проекта?

18.  Как привлечение заказчика к управлению масштабом проекта влияет на collaboration?

19.  Как улучшение конструктивных характеристик качества связано с функциональной пригодностью?

20.  Почему время считается невозобновляемым ресурсом в разработке?

21.  К чему может привести установка требований к характеристикам без учета относительных затрат?

22.  Каков радикальный способ увеличения реальных затрат в ограниченное время?

3.2 Особенности требований заинтересованных лиц к программному продукту

23.  Какие группы заинтересованных лиц необходимо выделять и ранжировать при разработке требований?

24.  Какие требования наиболее важны для заказчиков программного продукта?

25.  На что ориентируются пользователи при оценке программного продукта?

26.  Какие аспекты важны для разработчиков в описании требований?

27.  Какие характеристики являются приоритетными для специалистов, сопровождающих и модифицирующих комплекс программ?

28.  Что наиболее важно для лиц, ответственных за инсталляцию и внедрение ПО?

29.  Какие характеристики интересуют первые две группы потребителей (заказчиков и пользователей)?

30.  Какими характеристиками интересуются последние три группы потребителей (разработчики, сопровождающие, внедренцы)?

31.  На что влияют приоритеты потребителей при формировании требований?

32.  Что должна сделать команда разработчиков до начала разработки программного комплекса?

33.  Каковы цели анализа и выявления проблемы заказчика?

34.  Почему процесс понимания потребностей пользователей называется «выявлением требований»?

35.  Перечислите методы, используемые для выявления и анализа требований.

36.  Какова цель проведения совещаний, посвященных анализу и синтезу требований?

3.3 Требования к надежности функционирования программных продуктов

37.  Дайте определение надежности программного продукта согласно стандарту ISO 9126.

38.  В чем заключаются особенности программных комплексов по сравнению с традиционными техническими системами с точки зрения надежности?

39.  Каковы доминирующие факторы, определяющие надежность программ?

40.  Что такое «Завершенность» (как атрибут надежности)?

41.  Что такое «Устойчивость к дефектам и ошибкам»?

42.  Дайте определение «Восстанавливаемости» программного продукта.

43.  Что такое «Доступность» или «Готовность» программного продукта?

44.  В чем состоит различие между понятиями «корректная программа» и «надежная программа»?

45.  Почему надежность функционирования программ является динамическим понятием?

46.  Что регистрируется при оценке реализации требований надежности?

47.  Для чего предназначены системы оперативной защиты?

48.  Какой принцип лежит в основе классификации сбоев и отказов в программных продуктах?

49.  Чем отличается сбой от отказа?

50.  Какой критерий надежности наиболее широко используется?

51.  Что является основным требованием к процессу восстановления?

52.  Что отражает коэффициент готовности?

53.  С чем должна быть соизмерима наработка на отказ программного продукта в реальных системах?

54.  Что требуется использовать для получения высокой надежности программ?

3.4. Требования к функциональной безопасности программных продуктов

55.  Чем характеризуется наиболее полно функциональная безопасность комплексов программ?

56.  Что сближает понятия безопасности и надежности?

57.  В чем состоит различие между показателями надежности и функциональной безопасности?

58.  Какие особенности источников нарушения корректности функционирования следует учитывать при формировании требований к безопасности?

59.  Что такое «опасная отказовая ситуация»?

60.  Как можно предотвратить превращение отказовой ситуации в катастрофическую?

61.  Что позволяет компенсировать введение в программы средств контроля и оперативной защиты?

62.  Какой международный стандарт устанавливает требования к обеспечению функциональной безопасности?

63.  Что содержит стандарт IEC 61508-3?

64.  Какой цикл рекомендуется использовать для обеспечения требований безопасности?

65.  Какие требования к функциям безопасности должны быть в спецификации?

66.  Для чего используется аттестация программного продукта?

67.  Какой стандарт формализует требования к информационной безопасности?

68.  На предотвращение каких типов недостатков направлены шаги в стандарте ISO 15408?

69.  Что такое «доверие» (trust) в контексте стандарта по безопасности?

70.  Что определяет класс «руководство по безопасности»?

71.  Что определяет класс «поддержка жизненного цикла»?

72.  Что определяет класс «оценка уязвимости комплекса программ»?

73.  Что такое «Профиль защиты» (ПЗ)?

74.  Что такое «Задание по безопасности» (ЗБ)?

3.5 Требования к производительности и эффективности

75.  Какие две динамические характеристики эффективности отражены в стандарте ISO 9126?

76.  Что такое «временная эффективность»?

77.  Что такое «пропускная способность»?

78.  Что характеризует «используемость ресурсов»?

79.  Что может нарушаться при излишне высокой интенсивности поступления исходных данных?

80.  Что следует согласовывать с заказчиком при подготовке технического задания?

81.  Для каких режимов работы необходимо формализовать требования к интенсивности решения задач?

82.  В чем состоит основная задача при задании требований к эффективности динамического использования ресурсов?

3.6 Требования к допустимым рискам динамического применения программных продуктов

83.  Какова цель формирования требований к рискам при создании ПО?

84.  Кто координирует процесс управления рисками?

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

86.  Какие три группы характеристик проектов определяют классы потенциальных рисков?

87.  Какие требования имеют доминирующее значение при анализе рисков?

88.  Какие два вида рисков проявляются вследствие ошибок функциональных требований?

89.  Что является важнейшим риском в жизненном цикле программного продукта?

90.  Что является одним из важных составляющих при определении функциональной пригодности и сокращения рисков?

91.  Какую роль в управлении рисками играет менеджер рисков?

92.  На каких этапах жизненного цикла достигается основной эффект по снижению рисков?

93.  Какие методы должны быть включены в технологический процесс разработки для управления рисками?

94.  Что позволяет избежать качественное сравнение эффекта и затрат на улучшение характеристик?

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

96.  Перечислите виды рисков ограничений доступных и используемых ресурсов.

97.  К чему может привести завышение стоимости проекта заказчиком?

98.  Какой стандарт регламентирует управление рисками в ЖЦ программных комплексов?

99.  На базе анализа и сокращения рисков каких процессов строится обеспечение качества и безопасности по стандарту ISO 16085?

100.                      Назовите последовательные процедуры управления рисками, рекомендуемые стандартом.