Тесты по дисциплине «Метрология и качество программного обеспечения»

Скачать 297.85 Kb.

Название	Тесты по дисциплине «Метрология и качество программного обеспечения»
страница	2/3
Дата публикации	12.08.2013
Размер	297.85 Kb.
Тип	Тесты

100-bal.ru > Информатика > Тесты

1 2 3

Внешнее описание программных средств и примитивы качества
43. Основными и неотъемлемыми частями внешнего описания программного средства являются

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

44. Одним из способов разработки определения требований к программному средству является управляемая пользователем разработка. Она характеризуется тем, что

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

45. Одним из способов разработки определения требований к программному средству является контролируемая пользователем разработка. Она характеризуется тем, что

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

46. Одним из способов разработки определения требований к программному средству является независимая от пользователя разработка. Она характеризуется тем, что

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

47. С точки зрения обеспечения надёжности ПС, как показывает практика, наиболее предпочтительной является

контролируемая пользователем разработка ПС;
независимая от пользователя разработка ПС;
управляемая пользователем разработка ПС.

48. Одним из примитивов качества ПС является его автономность (self-containedness). Под этим примитивом понимается

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

49. Одним из примитивов качества ПС является его устойчивость (robustness). Под этим примитивом понимается

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

50. Одним из примитивов качества ПС является его защищённость (defensiveness). Под этим примитивом понимается

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

51. Одним из примитивов качества ПС является его модифицируемость (modifiability). Под этим примитивом понимается

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

52. Одним из примитивов качества ПС является его модульность (modularity). Под этим примитивом понимается

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

53. Одним из примитивов качества ПС является его независимость от устройств (device independence). Под этим примитивом понимается

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

54. Одним из примитивов качества ПС является его коммуникабельность (communicativeness). Под этим примитивом понимается

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

55. Одним из примитивов качества ПС является его расширяемость (augmentability). Под этим примитивом понимается

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

56. Разработка внешнего описания ПС обязательно должна завершаться проведением тщательного и разнообразного контроля правильности внешнего описания. Одним из методов такого контроля является статический просмотр (инспекция). Под ним понимается

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

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

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

Измерения при разработке и сопровождении программного продукта
58. Программой измерений компании называется

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

59. С измерениями связано понятие индикатора – формы представления набора значений метрики, удобной для анализа. При этом тип индикатора, называемый «индикатор-цель» (Success) характеризуется тем, что

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

60. С измерениями связано понятие индикатора – формы представления набора значений метрики, удобной для анализа. При этом тип индикатора, называемый «индикатор-прогресс» (Progress) характеризуется тем, что

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

61. С измерениями связано понятие индикатора – формы представления набора значений метрики, удобной для анализа. При этом тип индикатора, называемый «индикатор-анализ» (Analysis) характеризуется тем, что

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

62. Метрика On project % time (OPPT) (процент времени, затрачиваемый на работу по проектам) рассчитывается по формуле

OPPT = (Рабочее время, затраченное на проект / Общее рабочее время)*100%
OPPT = Размер продукта / Общее время инспектирования;
OPPT = (Количество найденных ошибок / Размер рабочего продукта).

63. Метрика Inspection Fault Density (IFD) (плотность обнаруженных ошибок) рассчитывается по формуле

1) IFD = (Рабочее время, затраченное на проект / Общее рабочее время)*100%

2) IFD = (Количество найденных ошибок / Размер рабочего продукта)

3) IFD = Размер продукта / Общее время инспектирования
64. Метрика Inspection Preparation Rate (IPR) (производительность подготовки к инспекциям) рассчитывается по формуле

IPR = (Количество инспекторов * Размер продукта) / Общее время подготовки;
IPR = (Рабочее время, затраченное на проект / Общее рабочее время)*100%
IPR = Размер продукта / Общее время инспектирования

65. Существует метрика эффективности производственного процесса компании Phase Containment Effectiveness (PCE) (эффективность обнаружения ошибок). Целью компании является

уменьшение этой метрики;
увеличение этой метрики;
неизменность этой метрики.

66. Существует метрика эффективности производственного процесса компании Problem Resolution Rate (PRR) (число отработанных задач за единицу времени). Целью компании является

уменьшение этой метрики;
увеличение этой метрики;
неизменность этой метрики.

67. Существует метрика качества программного продукта In Process Faults (IPF) (плотность ошибок в продукте). Целью компании является

уменьшение этой метрики;
увеличение этой метрики;
неизменность этой метрики.

68. Существует метрика качества программного продукта Product Fault Density (PFD) (плотность ошибок, внесённых на каком-либо этапе проекта). Целью компании является

уменьшение этой метрики;
увеличение этой метрики;
неизменность этой метрики.

Архитектура программных средств
69. Класс архитектуры программных средств «цельная программа» характеризуется тем, что

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

70. Класс архитектуры программных средств «комплекс автономно выполняемых программ» характеризуется тем, что

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

71. Класс архитектуры программных средств «слоистая программная система» характеризуется тем, что

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

72. Класс архитектуры программных средств «коллектив параллельно действующих программ» характеризуется тем, что

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

73. Архитектурными функциями программного средства называются

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

74. Под понятием рутинности модуля понимается

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

75. Современная технология программирования

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

76. Метод восходящей разработки структуры программ состоит в том, что

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

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

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

78. Метод контроля модульной структуры программы, называемый «смежный контроль сверху» состоит в том, что

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

79. Метод контроля модульной структуры программы, называемый «смежный контроль снизу» состоит в том, что

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

80. Метод контроля модульной структуры программы, называемый «сквозной контроль» состоит в том, что

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

1 2 3

	Методические рекомендации к самостоятельной работе студентов по дисциплине... Содержание внеаудиторной самостоятельной работы студентов по дисциплине ««Автоматизация бухгалтерского учета с использованием программного...		2 2 Ключевые вопросы сопровождения программного обеспечения 152 Программная инженерия и сущность инженерного подхода к созданию программного обеспечения 9
	Тесты по русскому языку. Егэ. Русский язык Обучающий курс. Технология быстрого восстановления программного обеспечения в оу		Рабочая программа учебной дисциплины технологии разработки программного обеспечения Охватывает данный подход? Какие модели используются в качестве функциональных спецификаций при структурном подходе? Какие характеристики...
	Понятие программы, программного обеспечения. Классификация программного... Понятие программы, программного обеспечения. Классификация программного обеспечения		Методические рекомендации по организации внеаудиторной самостоятельной... Пм 01 Разработка программных модулей программного обеспечения для компьютерных систем
	Самарский государственный технический университет утверждаю Целью данного курса является: обновление теоретических и практических знаний педагогических работников образовательных учреждений...		Программа дисциплины двм 02 05. 01 "Верификация, аттестация и качество... Омский институт водного транспорта (филиал) фбоу впо «Новосибирская государственная академия водного транспорта»
	Методические рекомендации по установке и использованию стандартного... Успешное внедрение и эффективное использование сбппо в образовательной деятельности общеобразовательного учреждения зависит от создания...		Рабочая программа по дисциплине «стандартизация, метрология и сертификация» Программа курса по дисциплине Стандартизация, метрология и сертификация составлена в соответствии с требованиями основной образовательной...
	Программа дисциплины «Конструирование программного обеспечения» Программа предназначена для преподавателей, ведущих данную дисциплину, учебных ассистентов и студентов направлений подготовки 231000....		Программа по дисциплине «Метрология, стандартизация и сертификация» Учебная программа по дисциплине «Метрология, стандартизация и сертификация» разработана в соответствии с требованиями Государственного...
	Тематический план Введение. Предмет курса и его связь со смежными... Целью изучения дисциплины является получение общих представлений о содержании и тенденциях развития базовых информационных технологий...		Программа по формированию навыков безопасного поведения на дорогах... Способностей средствами информационно-коммуникативных технологий и прикладного программного обеспечения. Воспитание ответственного...
	О доступе к информационным ресурсам и информационно – телекоммуникационным... Программное обеспечение: «Первая помощь. 0 + пакет свободного программного обеспечения»		Рабочая программа учебной практики профессионального модуля уп. 02.... Рабочая программа учебной практики «Разработка программного обеспечения» разработана в соответствии с требованиями федерального государственного...

Тесты по дисциплине «Метрология и качество программного обеспечения»

Похожие: