МКиСПО вопросы к экзамену2011

ISO 8402 : 1986 «Качество. Словарь»

ISO 9000 : 1987 «Системы качества. Общее руководство качеством. Стандарты по обеспечению качества»

ISO 9001 : 1987 «Системы качества. Модель для обеспечения качества при проектировании и разработке в производстве, монтаже и обслуживании»

ISO 9002 : 1987 «Системы качества. Общие мероприятия по обеспечению качества при производстве и монтаже изделия»

ISO 9003 : 1987 «Системы качества. Общие мероприятия при окончательном контроле изделия»

ISO 9004 : 1987 «Системы качества. Общие мероприятия при внедрении и общем руководстве системой качества с целью производства конкурентоспособной продукции»

2.Формализующие показатели качества ПС.

ISO 9126 : 1991 «ИТ. Оценка программного продукта. Характеристики качества и руководство по их применению»

ГОСТ 28195 : 89 «Оценки качества ПС. Общие положения»

ГОСТ 28806 : 90 «Качество ПС. Термины и определения»

DOD-STD-2186 «Программообеспечение качества оборонных ПС»

13.Обеспечение качества ПС в процессе разработки.

Критерии этапа проектирования:

Сложность проектирования

Трудоемкость разработки

Корректность

14. Управление качеством ПС.

Впроцесс управления качеством ПС входит:

анализ системных требований к ПС, выделение и ранжирование обобщенных показателей качества конечного программного продукта

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

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

создание методов и средств объективного измерения качества программных компонентов на фиксированных этапах их создания

разработка методик и стандартов контроля, соблюдение правил и технологии проектирования и обеспечение всего ЖЦ ПС

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

Для определения качества прикладных ПС должны быть подготовлены исходные данные:

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

значения исходных и результирующих данных, в пределах которых должны удовлетворяться заданные показатели качества ПС

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

15. Основные понятия и виды корректности программ.

Корректность комплексов программ:

Корректность текстов программ o Синтаксическая

o Семантическая

Корректность программных модулей o Структурная

o Функциональная (Детерминированная, Стохастическая)

Корректность данных o Структурная

o Конкретных значений

Корректность групп и комплексов программ o Структурная и межмодульных связей

o Функциональная (Детерминированная, Стохастическая, Динамическая).

Корректность модулей:

КОНСТРУКТИВНАЯ

Заключается в соответствии их структуры общим правилам структурного программирования и конкретным правилам оформления и внутреннего построения программных модулей.

ФУНКЦИОНАЛЬНАЯ

Определяется корректностью обработки исходных данных и получения результатов.

Корректность данных:

КОНСТРУКТИВНАЯ

Определяется правилами их структурирования и упорядочения.

ФУНКЦИОНАЛЬНАЯ

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

Корректность групп программ:

КОНСТРУКТИВНАЯ

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

ФУНКЦИОНАЛЬНАЯ Можно разделить на:

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

определенными эталонными значениями устанавливается однозначное соответствие

o стохастическую корректность – результирующие и исходные данные соответствуют распределениям случайных величин

oдинамическую корректность – соответствие изменяющихся во времени результатов исполнения программ эталонным данным

16. Типы эталонов, методы измерений и проверки корректности программ.

Методы получения эталонных значений:

ручные или на ЭВМ расчеты по аналитическим формулам

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

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

разработка правдоподобных гипотез и постановка умозрительных экспериментов

1. Модель области определения исходных данных 2.1Эталоны:формализованные правила; программные спецификации; тесты. 2.2 Проверяемые программы: исходные тесты; результаты исполнения.

3.Средства сравнения программ и их результатов с эталонами

4.Отклонение от эталонов

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

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

17. Верификация программ.

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

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

Блок-схема системы верификации программных модулей: 1. Разработчик программы

1.1Текст программы на языке -> Автоматическая генерация инвариантов верификации

1.2Спецификации на программный модуль -> Синтаксический контроль корректности спецификаций

1.3Контроль исходных данных и дополнение условий верификации -> Группирование условий верификации по этапам доказательства корректности -> Доказательство корректности компонент программы -> Доказательство корректности взаимодействия компонент и программы в целом

18. Тестирование и отладка ПС.

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

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

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

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

19. Определение надежности ПС.

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

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

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

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

20. Показатели надежности ПС.

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

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

Количественные показатели надежности:

1. Вероятность безотказной работы – вероятность того, что в пределах заданной наработки отказ системы не наступит. Наработка – продолжительность или объем работы. P(tз)=P(t>tз), где P(tз) – вероятность безотказной работы, t – случайное время работы до отказа, tз – заданная наработка.

Внимание: время процессорное!

2.Вероятность отказа – вероятность того, что в пределах заданной наработки отказ системы наступит. Q(tз)=1-P(tз).

3.Интенсивность отказов – условная плотность вероятности возникновения отказа ПС в определенный момент времени при условии, что до этого времени отказ не возник. лямбда(tз)=f(t)/P(t), где f(t) - плотность вероятности отказа в момент времени, лямбда – число отказов в единицу времени.

4.Средняя наработка до отказа – математическое ожидание времени работы ПС до очередного отказа. T1=(t1+t2+…+tn)/n, где n – количество отказов.

5.Среднее время восстановления – математическое ожидание времени отказа.

Tв=(tв1+tв2+…+tвn)/n, где tвi=tлоj+tyoj+tnpj, где tлоj - время на локализацию отказа, tyoj – время на устранение отказа, tnpj – время на проверку работоспособности.

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

Kг=Т1/(Т1+Тв)

21. Факторы, определяющие надежность ПС.

Общие факторы:

процедуры управления разработкой ПО;

архитектура вычислительной системы;

подготовка и повышение квалификации персонала;

языки программирования.

Факторы, связанные с разработкой ПО:

конструктивные:

oразмеры и стоимость разрабатываемой системы

oстепень выполнения последовательности работ

oстепень сложности разработки системы

oструктурное построение

oналичие опыта разработки

технологические:

oкачество программирования

oпринятые конструктивные решения

oобъем программы

oлогическая сложность

oстепень выполнения требований на разработку

организационные:

oуправление надежностью

o степень обученности персонала

o степень информированности персонала o микроклимат в группе

o временные ограничения.

Эксплуатационные:

полнота и качество документации

степень адаптации документации

простота изучения и использования

защищенность информации

степень выполнения стандартов на эксплуатацию

качество обучения пользователей.

22.Общая характеристика моделей надежности ПС.

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

Модель надежности ПО (МНПО) – математическая модель, построенная для оценки зависимости надежности ПС от заранее известных или оцененных в ходе тестирования параметров.

Модели надежности делятся на:

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

o модель сложности;

o модель, определяющая время доводки программы.

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

o динамические:

дискретные (Модель Шумана, Модифицированная модель Шумана, Модель La Padula, Модель Шика-Волвертона);

непрерывные (Модель Джелинского-Моранды, Модель Муса, Модель переходных вероятностей, Модель Гоэл-Окимото);

oстатические:

по области ошибок (Модель Миллса, Модель Липова, Простая интуитивная модель, Модель Коркорэна);

по области данных (Модель Нельсона).

Статические модели (СМ):

Появление отказов не связано со временем.

СМ по области ошибок – учитывается связь количества ошибок и числа тестовых прогонов.

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

Динамические модели (ДМ):

Поведение отказов зависит от времени.

Для использования ДМ необходимо иметь данные о появлении отказов по времени.

В ДМ с непрерывным временем (ДНМ) фиксируются интервалы каждого отказа, т.е. получается непрерывная картина появления отказов по времени.

В ДМ с дискретным временем (ДДМ) фиксируются число отказов за некоторое время и поведение программы представлено в дискретных точках.

23. Ошибки ПС.

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

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

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

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

Если принять, что при длительности отладки (тао) величина P(1)k есть вероятность наличия в программе первичной ошибки k-го типа, которая при исполнении программы вносит в результирующую j-ю переменную дополнительную ошибку Dkj , то значение

вторичной ошибки у j-й переменной можно представить выражением: (q вверх ногами как б) j-тое от тао = (Сумма k от 1 до m) (P(1)k от тао)* Dkj, где m – полное количество типов,

не выявленных в программе, первичных ошибок.

Формальная оценка значений xj и Dkj затруднительна, в лучшем случае их можно оценить методами экспертного опроса при условии четкой предварительной классификации m типов первичных ошибок в программах (индекс k) и q выходных величин (индекс j). Тогда можно получить общую средневзвешенную ошибку функционирования системы вследствие не выявленных первичных ошибок: (q вверх ногами как б) от тао = (Сумма j от 1 до q) (xj) *((q вверх ногами как б) j-тое от тао).

Потеря эффективности программ за счет неполной отлаженности в первом приближении можно считать прямо пропорциональным (с коэффициентом (q вверх ногами как б)) среднеквадратическим вторичным ошибкам в выходных результатах: e(тао)=(б маленькая прописная)* (q вверх ногами как б(или как о с черточкой сверху) от тао)

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

24. Причины ошибок в ПС.

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

потенциальным пользователем. В краткой классификации выделяются следующие ошибки.

Ошибки пользовательского интерфейса. Функциональность.

Взаимодействие программы с пользователем. Организация программы.

Пропущенные команды. Производительность. Выходные данные. Обработка ошибок.

Ошибки, связанные с обработкой граничных условий. Ошибки вычислений.

Начальное и последующие состояния.

Ошибки управления потоком.

Ошибки передачи или интерпретации данных. Ситуация гонок.

Перегрузки. Аппаратное обеспечение. Контроль версий. Документация.

Ошибки тестирования.

Ошибки пользовательского интерфейса.

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

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

Ошибки функциональности.

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

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

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

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

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

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

Пропущенная функция. В программе не реализована функция, предусмотренная спецификацией.

Неверно работающая функция. Функция работает не так, как предусмотрено спецификацией.

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

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

Взаимодействия программы и пользователя. Их появление возможно как в интерактивном, так и в пакетном режимах.

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

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

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

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

Представляется целесообразным выделение рубрики «Ошибки документации и сообщений программы» в самостоятельный раздел. Этот раздел не

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

Ошибки отображения. Данные отражаются формально правильно, но в

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

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

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

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

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

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

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