Обеспечение качества функционирования компьютерных систем

МДК 04.02

Обеспечение качества функционирования компьютерных систем

Основные методы обеспечения

качества функционирования

ЦЕЛЬ:

изучить характеристики качества программного обеспечения, надёжности технических средств и свойств КС, особенность решения задач по расчёту надёжности ПО

РАССМАТРИВАЕМЫЕ ВОПРОСЫ:

1. Качество ПО и его характеристики

2. Надежность Компьютерных систем, свойства

3. Риски оценок возможных негативных последствий функционирования или внедрения ИС, метрики оценок возникновения рисков.

4. План работ по оценке надежности Компьютерных систем, рисков по внедрению ИС

Оценка качества ПО

Качество ПО по ГОСТ 9126 – это весь объем признаков и характеристик ПО для удовлетворения установленным потребностям.

Оценка качества ПО проводится с позиций:

Положительной эффективности – адекватности характеристик по назначению, целям создания и применения

Негативной позиции - возможного ущерба – риска от применения ПО

Характеристики качества ПО

Функциональность ( Functionality ). Функции, которые реализуют установленные или предполагаемые потребности

Надежность ( Reliability ). Способность ПО сохранять свой уровень функционирования при установленных условиях за установленный период времени

Практичность ( Usability ). Объем работ для использования предполагаемыми пользователями

Эффективность ( Efficiencies ). Соотношение между качеством функционирования и используемыми ресурсами

Сопровождаемость ( Maintainability ). Работы для проведения модификации

Мобильность ( Portability ). Способность ПО быть перенесенным из одного окружения в другое

Надежность ПО

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

Надежность ПО включает:

Безотказность – сохранение работоспособности в течении некоторого времени

Долговечность - сохранение работоспособности до наступления несоответствия параметров ПО современным условиям эксплуатации

Ремонтопригодность – приспособленность к восстановлению работоспособности после отказа или повреждения

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

Риски

- характеризуют возможные негативные последствия (ущерб) при функционировании ПО или при его внедрении

Существует национальный стандарт РФ «Менеджмент риска, Метод анализа видов и последствий отказов» ГОСТ 51901.12 2007 и является модифицированным по отношению к международному стандарту МЭК 60812:2006 «Методы анализа надежности систем» ( FMEA - Failure Mode and Effects Analysis )

* ГОСТ – это аббревиатура от термина « государственный общесоюзный стандарт », а с 1992 года по наши дни  « ГОСТ » обозначает «межгосударственный стандарт»

*МЭК - Международная электротехническая комиссия  (International Electrotechnical Commission) - международная организация по стандартизации электрических, электрон-ных и смежных технологий.

Метрики,

используемые при оценке рисков

Последствия отказа ( failure effect ) – Следствие вида отказа (риска): деньги, время, статус

Характер возникновения ( failure mode ): внешний, внутренний

Тяжесть отказа (последствий) – значимость или серьёзность последствий вида отказа

Частота появления (вероятность)

Критичность отказа ( failure criticality ) – сочетание тяжести последствий и частоты появления. Расчет согласуется участниками проекта

Пример метрики тяжести ошибки ПО, которые могут привести к катастрофе

Пример метрики тяжести ошибки ПО, которые не приводят к катастрофе

Последствия ошибок в программах

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

Печально известная ошибка в линейном ускорителе Therac-25 стала причиной гибели нескольких больных, получивших смертельные дозы радиации во время лечения, проводимого с июня 1985-го по январь 1987 года в нескольких онкологических клиниках в США и Канаде. Эти дозы, как было оценено позже, более чем в 100 раз превышали те, что обычно применяются при лечении. Частично причиной этих несчастий стала ошибка типа race condition.

Последствия ошибок в программах

Авария при запуске французской ракеты

«Ариан-5» (1996)

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

Последствия ошибок в программах

Неудача при запуске первого американского спутника к Венере

Единственная ошибка в программе на Фортране – вместо требуемой в операторе запятой программист поставил точку.

Ошибка не учета отрицательной высоты

При полетах над Мертвым морем американских самолетов произошла ошибка деления на ноль что привело к перезагрузке системы

Последствия ошибок в программах

Падение спутников системы ГЛОНАСС

Три спутника навигационной системы ГЛОНАСС упали в Тихий океан недалеко от Гавайских островов вскоре после их запуска. Причина аварии была признана ошибка в программировании, которая привела к тому, что в ракету залили неправильное количество топлива.

Резюме по выбору метрик

Шкалу качественной оценки влияния ошибки/риска на ПО или проект внедрения определяют исходя из конкретной предметной области и целей системы

Шкалу количественной оценки рекомендуется выбирать из нормирования влияния от 0 до 1 (как вероятностная характеристика)

Шкалу частоты появления (вероятность) ошибки/риска рекомендуется выбирать также из нормирования влияния от 0 до 1 (как вероятностная характеристика)

При выполнении выше указанных рекомендаций шкала тяжести последствий может быть определена как произведение тяжести ошибки на вероятность её появления и окажется нормированной от 0 до1.

Нормирование шкалы тяжести последствий удобно для мониторинга ошибок и своевременного реагирования на их появление

План работ

по надежности работы или внедрения ИС

План должен включать:

Информацию о структуре системы

Идентификацию рисков

Необходимый объем участия в анализе экспертов и их состав

Корректирующие действия (набор), предусмотренные заранее

Шкалу качественных и количественных метрик возникновения рисков

Алгоритм определения тяжести последствий возникновения риска

Порядок мониторинга рисков

Вопросы

1. Что такое Качество ПО?

2. Какие сущестуют характеристики качества ПО?

3. Что такое Надежность ПО?

4. Что такое Риски и что используется при их оценке?

5. Что включает в себя План работ по оценке надежности?

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

Качество программного обеспечения (Software Quality) является постоянным объектом заботы программной инженерии и обсуждается во многих областях знаний.

• Компания IBM: ввела в оборот фразу «качество, управляемое рыночными потребностями ( market-driven quality )».
• Система менеджмента качества ISO 9001: Качество — это степень соответствия присущих характеристик требованиям.
• Приемлемое качество — это желаемая степень совершенства создаваемого продукта (услуги), способная удовлетворить пользователей и достижимая в рамках заданных проектных ограничений.

Рассмотрим определение "качества ПО" в контексте международных стандартов:

[1061-1998 IEEE Standard for Software Quality Metrics Methodology] Качество программного обеспечения - это степень, в которой ПО обладает требуемой комбинацией свойств.

[ISO 8402:1994 Quality management and quality assurance]

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

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

Важными характеристиками являются:

• Читаемость кода
• Лёгкость поддержки, тестирования, отладки, исправления ошибок
• Низкая сложность кода
• Низкое использование ресурсов: памяти и процессорного времени
• Корректная обработка исключительных ситуаций
• Малое число предупреждений при компиляции и линковании

Факторы качества

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

Некоторые из факторов качества:

Полнота .   Все необходимые части программы должны быть представлены и полностью реализованы.

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

Тестируемость .   Позволяет ли программа выполнить проверку приёмочных характеристик, поддерживается ли возможность измерения производительности.

Надёжность .   Отсутствие отказов и сбоев в работе программ, а также простота исправления дефектов и ошибок

Эффективность .   Насколько рационально программа относится к ресурсам (память, процессор) при выполнении своих задач.

Безопасность .   Поддержка внештатной ситуации.

Оценка качества с точки зрения пользователя

Помимо технического взгляда на качество ПО, существует и оценка качества с позиции пользователя. Для этого аспекта качества иногда используют термин «юзабилити»   (от английского usability — "удобство использования) .

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

Наиболее важные из вопросов,

влияющие на оценку usability:

• Является ли пользовательский интерфейс интуитивно понятным?
• Насколько просто выполнять простые, частые операции?
• Насколько легко выполняются сложные операции?
• Выдаёт ли программа понятные сообщения об ошибках?
• Всегда ли программа ведёт себя так как ожидается?
• Имеется ли документация и насколько она полна?
• Является ли интерфейс пользователя самоописательным /самодокументирующим?
• Всегда ли задержки с ответом программы являются приемлемыми?

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

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

Оценочные характеристики качества

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

Путем  непосредственного измерения определяются опорные свойства .

Остальные свойства оцениваются путем вычисления функций от опорных значений. Такие функции

называются метриками.

Размерно-ориентированные метрики

Размерно-ориентированные метрики основаны на  LOC-оценках , т.е. на  количестве строк в текстах программ  ( Lines Of Code (LOC) ).

К числу размерно-ориентированных метрик относятся:

производительность

качество

удельная стоимость

документированность

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

Метрики производительности и качества рассчитываются в виде следующих отношений:

Качество =

[число ошибок] / [число строк кода (тыс.LOC)]

Производительность = 

[число строк кода (тыс.LOC)] / [Затраты]

где затраты измеряются в человеко-месяцах  (работа одного человека в течении месяца)

Метрики стоимости и документированности

Удельная Стоимость =

[Стоимость в тыс. рублей] / [число строк кода (тыс.LOC)]

Документированность =

[число страниц документации] / [число строк кода (тыс.LOC)]

Достоинства и недостатки

Размерно-ориентированные метрик

Достоинства:

• основаны на объективных данных
• просты и легко вычислимы

Недостатки:

• зависят от языка программирования
• трудновыполнимы на начальной стадии проекта
• не приспособлены к непроцедурным языкам программирования *

*Это декларативные языки. То есть когда в языке описывается не как получить, а что получить, а уж как получать - программа решает самостоятельно. Классический язык такого типа - Prolog.

Вычисление размерно-ориентированных метрик

для каждого из проектов:

Проект

Затраты,

чел.- мес.

Стоимо-сть, тыс. р

АИС

«Продажи»

«Банк-онлайн»

24

тыс. LOC

62

«Отчеты»

Прогр. док-ты, страниц

168

43

Ошибки

12,1

440

27,2

314

Люди

365

1224

20,2

29

86

3

1050

5

64

6

Оформление расчета размерно-ориентированных метрик:

Проект

«Продажи»

Затраты, чел.- мес.

Стоимо-сть, тыс. р

24

«Банк-онлайн»

тыс. LOC

168

«Отчеты»

62

Прогр. док-ты, страниц

12,1

43

440

Ошибки

365

27,2

314

Люди

29

1224

20,2

3

ИСХОДНЫЕ ДАННЫЕ

1050

86

64

5

6

Проект

«Продажи»

Качество

«Банк-онлайн»

2,40

Производи- тельность

3,16

Удельная Стоимость, тыс. р

«Отчеты»

0,50

13,88

Документи- рованность

0,44

3,17

30,17

16,18

0,47

РЕЗУЛЬТАТЫ

45,00

15,54

51,98

Анализ результатов расчета размерно-ориентированных метрик:

Качество

Лучшее

2,40

Производительность

Проект

«Продажи»

Лучшая

0,50

Проект

Удельная Стоимость, тыс. р

Лучшая

«Продажи»

13,88

Проект

Документи- рованность

Лучшая

«Продажи»

Проект

АНАЛИЗ РЕЗУЛЬТАТОВ (позитив)

51,98

«Отчеты»

Качество

Худшее

3,17

Производительность

Проект

Худшая

«Отчеты»

Удельная Стоимость, тыс. р

Проект

0,44

«Банк-онлайн»

Худшая

16,18

Проект

Документи- рованность

Худшая

«Банк-онлайн»

30,17

АНАЛИЗ РЕЗУЛЬТАТОВ (негатив)

Проект

«Продажи»

Самостоятельно вычислите

размерно-ориентированные метрики

и проведите анализ результатов

для каждого проекта:

Проект

Затраты,

чел.- мес.

«Texter»

Стоимо-сть, тыс. р

тыс. LOC

21

«Magictext»

34

«Protext»

Прогр. док-ты, страниц

100

«TurboText»

33

Ошибки

250

12,2

24,3

26

310

Люди

278

22

160

560

22,6

15,5

40

420

2

330

6

54

29

5

3

Функционально-ориентированные метрики

(FP-оценки)

Исходят  не из размера программного продукта, а из его функциональности .

Оценивают:

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

FP (Function Points) -оценки

Вместо количества строк в текстах используется количество функциональных указателей (Function Points)

FP = UI * ( 0.65 + 0.01 * E [ F(i) ] )

UI  - оценка сложности пользовательского интерфейса,

F(i)  ("эф итое") – коэффициенты регулировки сложности, основанные на эмпирической оценке ряда системных параметров и принимающие целые значения в диапазоне от 0 до 5.

E[F(i)]   - сумма всех коэффициентов по i параметру.

К числу параметров, учитываемых коэффициентами регулирования сложности относятся:

объем используемых средств передачи данных

степень распределенности обработки

степень распространенности используемой аппаратной платформы

степень жесткости требований к производительности

частота выполнения транзакций

При расчетах параметров коэффициента регулирования сложности учитывают:

процент информации, вводимой в режиме on-line

сложность обработки данных, наличие значительной логической и математической обработки

легкость инсталляции

степень переносимости

степень модифицируемости

Достоинства и недостатки

Функционально-ориентированных метрик

Достоинства:

• не зависят от выбора языка программирования
• вычисляются на любой стадии проекта

Недостатки:

• используют не прямые, а косвенные измерения
• основаны на субъективных оценках