Рецензенты Семёнов Сергей Максимович, зав кафедрой искт, Стыцюра Людмила Фёдоровна, ст преп каф. Искт тесты

Вид материала

Тесты

Содержание Модели жизненного цикла разработки программных средств

Подобный материал:

• Семенов Сергей Максимович, канд техн наук, зав кафедрой информационных систем и компьютерных, 157.7kb.
• Самопальникова Юлия Николаевна Рецензенты: Зав кафедрой бухгалтерского учета и ахд, 682.3kb.
• Региональное Отделение Российского Философского Общества Саратовский государственный, 223.62kb.
• Лекции Минск бгму 2011, 1368.23kb.
• И. М. Губкина е. К. Муравьева С. М. Панферова Макроэкономика тесты, 1366.84kb.
• -, 666.3kb.
• Программа Всероссийской научно-методической конференции «studium: технологии и традиции, 170.74kb.
• Учебное пособие Волгоград 2005 удк 93: 008: (470+571) (07) ббк 63 (2), 2780.67kb.
• Учебно-методическое пособие. Волгоград 2004 удк 93: 008: (470+571) (07) ббк 63 (2), 1545.82kb.
• Разработчики программы повышения квалификации: Алиева Б. Ш. д пед н., профессор, каф, 274.72kb.

МЕТРОЛОГИЯ И КАЧЕСТВО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

(вопросы для тестов)


БУМК №

ИИТТС, кафедра ИСКТ


Автор: Гриняк В.М., доцент кафедры ИСКТ

Аннотация.

Данный тест предназначен для студентов, обучающихся по специальности 071900 «Информационные системы и технологии».

Автор теста – Гриняк В.М, доцент кафедры ИСКТ.

Тест разработан с 1.10.2005 по 20.02.2006

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

Содержательная экспертиза теста проводилась 25.02.06. Рецензенты Семёнов Сергей Максимович, зав. кафедрой ИСКТ, Стыцюра Людмила Фёдоровна, ст. преп. каф. ИСКТ.


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


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

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

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

3. Считается, что в программе имеется ошибка, если она
   
   1. не копируется в память машины;
      
   2. не запускается на каком-либо компьютере;
      
   3. не выполняет того, что разумно ожидать от нее пользователю.
      

4. Несогласованность между программами программного средства и документацией по их применению
   
   1. считается ошибкой в программном средстве;
      
   2. не считается ошибкой в программном средстве;
      
   3. может считаться, а может и не считаться ошибкой в программном средстве.
      

5. Дефектом программы (defect) называется
   
   1. частный случай ошибки в программном средстве, когда программа не соответствует своей функциональной спецификации;
      
   2. сбой программы при выполнении;
      
   3. окно, предупреждающее пользователей программы об ошибке.
      

6. Понятие правильной программы неконструктивно в том смысле, что
   
   1. нельзя дать определение правильной программы;
      
   2. нельзя доказать правильность программы;
      
   3. правильная программа – это то же самое, что и надёжная программа.
      

7. Понятие надёжной программы является альтернативой понятию правильной программы в том смысле, что
   
   1. надёжность программы можно доказать, а правильность - нельзя;
      
   2. правильная программа – это то же самое, что и надёжная программа;
      
   3. нельзя дать определение правильной программы;
      

8. Под надёжностью (reliability) программного средства подразумевается
   
   1. способность безотказно выполнять определенные функции при заданных условиях в течение заданного периода времени с достаточно большой вероятностью;
      
   2. полное отсутствие ошибок в программном средстве;
      
   3. полное отсутствие сбоев программы при выполнении.
      

9. Понятие надёжного программного средства
   
   1. полностью исключает наличие в нём ошибок;
      
   2. не исключает наличия в нем ошибок  важно лишь, чтобы эти ошибки при практическом применении программы заданных условиях проявлялись достаточно редко;
      
   3. подразумевает обязательное наличие в нём ошибок.
      

10. Принципиальная разница между понятиями надёжной и правильной программы состоит в том, что
    
    1. невозможно гарантированно создать правильную программу, возможно создать лишь надёжную программу;
       
    2. невозможно гарантированно создать надёжную программу, возможно создать лишь правильную программу;
       
    3. правильность и надёжность программы описываются в разных проектных документах.
       

11. Основным источником ошибок (из перечисленных) в программных средствах является
    
    1. несоответствие системных требований;
       
    2. некорректные действия пользователя;
       
    3. сложность программного средства как системы.
       

12. Основным источником ошибок (из перечисленных) в программных средствах является
    
    1. человеческий фактор;
       
    2. некорректные действия пользователя;
       
    3. несоответствие системных требований.
       

13. Основным путём борьбы с ошибками в программном средстве (из перечисленных) является
    
    1. сужение пространства перебора (упрощение создаваемых систем);
       
    2. правильное ведение документации;
       
    3. приведение в соответствие системных требований.
       

14. Основным путём борьбы с ошибками в программном средстве (из перечисленных) является
    
    1. обеспечение требуемого уровня подготовки разработчиков программных средств;
       
    2. правильное ведение документации;
       
    3. приведение в соответствие системных требований.
       

Основные принципы разработки программных средств. Критерии качества.

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

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

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

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

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

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

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

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

23. Одним из критериев качества программных средств является его эффективность. При этом под эффективностью программного средства понимается
    
    1. отношение уровня услуг, предоставляемых ПС пользователю при заданных условиях, к объему используемых ресурсов;
       
    2. способность ПС безотказно выполнять определенные функции при заданных условиях в течение заданного периода времени с достаточно большой вероятностью.
       
    3. набор характеристик ПС, которые позволяют минимизировать усилия пользователя по подготовке исходных данных, применению ПС и оценке полученных результатов, а также вызывать положительные эмоции определенного или подразумеваемого пользователя.
       

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

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

26. Обязательными критериями качества программных средств являются
    
    1. функциональность и надёжность;
       
    2. сопровождаемость и мобильность;
       
    3. эффективность и лёгкость применения.
       

27. Одним из подходов к обеспечению надёжности программных средств является предупреждение ошибок. Под ним понимается
    
    1. реализация комплекса мер, цель которых – минимизировать число ошибок в готовых программных продуктах;
       
    2. реализация средств обнаружения отказа в программе в процессе её выполнения;
       
    3. реализация средств обнаружения отказа в программе в процессе её выполнения и исправление последствий этого отказа.
       

28. Одним из подходов к обеспечению надёжности программных средств является самообнаружение ошибок. Под ним понимается
    
    1. реализация комплекса мер, цель которых – минимизировать число ошибок в готовых программных продуктах;
       
    2. реализация средств обнаружения отказа в программе в процессе её выполнения;
       
    3. реализация средств обнаружения отказа в программе в процессе её выполнения и исправление последствий этого отказа.
       

29. Одним из подходов к обеспечению надёжности программных средств является самоисправление ошибок. Под ним понимается
    
    1. реализация комплекса мер, цель которых – минимизировать число ошибок в готовых программных продуктах;
       
    2. реализация средств обнаружения отказа в программе в процессе её выполнения;
       
    3. реализация средств обнаружения отказа в программе в процессе её выполнения и исправление последствий этого отказа.
       

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

Модели жизненного цикла разработки программных средств


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

1. Дизайн, планирование, тестирование, разработка требований, кодирование
   
2. Кодирование, дизайн, разработка требований, планирование, тестирование
   
3. Планирование, разработка требований, дизайн, кодирование, тестирование
   

32. Проекты данного класса имеют в принципе неограниченное время жизни

1. Класс 0 – исправление незначительных ошибок
   
2. Класс 2 – существенная доработка продукта
   
3. Класс 4 – сопровождение продукта
   

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

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

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

1. Спиральная
   
2. Водопад
   
3. Водопад с возвратами
   
4. Инкрементная
   

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

1. Спиральная
   
2. Водопад
   
3. Водопад с возвратами
   
4. Инкрементная
   

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

1. Спиральная
   
2. Водопад
   
3. Водопад с возвратами
   
4. Инкрементная
   

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

1. Итеративно-инкрементная
   
2. Водопад
   
3. Водопад с возвратами
   
4. Инкрементная
   

38. К недостатку различных видов водопадной модели относится

1) необходимость выработки очень точных и неизменных требований

2) сложность определения контрольных фаз и этапов выполнения проекта

3) отсутствие наглядности и простоты в модели


39. К достоинствам инкрементной модели относится

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

40. К достоинствам итеративной модели относится

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

41. В основу спиральной модели положена идея

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

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

3) разделения по времени всех фаз жизненного цикла разработки ПО


42. К достоинствам спиральной модели относится

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

Внешнее описание программных средств и примитивы качества


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

3) IFD = Размер продукта / Общее время инспектирования


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

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

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

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

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

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

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

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

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

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

Архитектура программных средств


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


81. Каждый участник инспекции рабочих продуктов играет определённую роль. При этом автор инспекции (Author) - это

1. сотрудник, разработавший инспектируемый рабочий продукт, либо сделавший инспектируемые изменения в существующем рабочем продукте;
   
2. ответственный сотрудник, выполняющий роль председателя инспекции;
   
3. сотрудник, ответственный за создание и распространение документации по инспекции;
   

82. Каждый участник инспекции рабочих продуктов играет определённую роль. При этом председатель инспекции (Moderator) - это

1. сотрудник, разработавший инспектируемый рабочий продукт, либо сделавший инспектируемые изменения в существующем рабочем продукте;
   
2. ответственный сотрудник, выполняющий роль председателя инспекции;
   
3. сотрудник, ответственный за создание и распространение документации по инспекции;
   

83. Каждый участник инспекции рабочих продуктов играет определённую роль. При этом секретарь инспекции (Recorder) - это

1. сотрудник, разработавший инспектируемый рабочий продукт, либо сделавший инспектируемые изменения в существующем рабочем продукте;
   
2. ответственный сотрудник, выполняющий роль председателя инспекции;
   
3. сотрудник, ответственный за создание и распространение документации по инспекции;
   

84. Каждый участник инспекции рабочих продуктов играет определённую роль. При этом ведущий инспекции (Presenter) - это

1. сотрудник, разработавший инспектируемый рабочий продукт, либо сделавший инспектируемые изменения в существующем рабочем продукте;
   
2. ответственный сотрудник, выполняющий роль председателя инспекции;
   
3. сотрудник, представляющий рабочий продукт инспекторам;
   

85. Каждый участник инспекции рабочих продуктов играет определённую роль. При этом инспектор (Inspector) - это

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

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

1. не допустимо совмещение ролей Председатель (Moderator) и Автор (Author);
   
2. не допустимо совмещение ролей Председатель (Moderator) и Инспектор (Inspector);
   
3. не допустимо совмещение ролей Секретарь (Recorder) и Инспектор (Inspector);
   

87. Под реинспекцией понимается

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

88. Повторная формальная инспекция рабочего продукта (реинспекция) проводится в случае, если

1. в проинспектированном рабочем продукте было найдено слишком много ошибок, его качество признано неудовлетворительным;
   
2. в проинспектированном рабочем продукте найдены замечания, и для его принятия их необходимо исправить;
   
3. автор рабочего продукта не согласен с замечаниями инспекторов.
   

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

1. будет принято после его реинспекции;
   
2. будет принято сотрудником, специально назначенным во время инспекции на роль проверяющего (Verifier);
   
3. будет принято автором рабочего продукта.
   

90. Для замечаний к продукту, формулируемых во время его инспектирования, имеется несколько статусов. Если проблема, найденная в продукте, была найдена на фазе, отличной от той, на которой внесена, то такая проблема имеет статус

1. Дефект (Defect);
   
2. Ошибка (Error);
   
3. Комментарий (Comment);
   
4. Замечание для исследования (Investigate).
   

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

1. Дефект (Defect);
   
2. Ошибка (Error);
   
3. Комментарий (Comment);
   
4. Замечание для исследования (Investigate).
   

Тестирование и отладка программного средства


92. Первая задача тестирования состоит в том, чтобы

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

93. Вторая задача тестирования состоит в том, чтобы

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

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

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

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

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

96. Основной смысл тестирования программы состоит в том, чтобы

1. отыскать ошибку в программе;
   
2. доказать отсутствие ошибок в программе;
   
3. доказать правильность программы.
   

97. Под понятием модульного тестирования (Unit Test) понимается

1. автономное тестирование отдельного модуля программного средства;
   
2. тестирование на предмет корректной работы программного средства в конкретной операционной системе;
   
3. пробная работа пользователей с программным средством.
   

98. Под понятием системного тестирования (System Test) понимается

1. автономное тестирование отдельного модуля программного средства;
   
2. тестирование на предмет корректной работы программного средства в конкретной операционной системе;
   
3. пробная работа пользователей с программным средством.
   

99. Под понятием бета-тестирования (Beta Test) понимается

1. автономное тестирование отдельного модуля программного средства;
   
2. тестирование на предмет корректной работы программного средства в конкретной операционной системе;
   
3. пробная работа пользователей с программным средством.
   

100. Разница между тестированием и аттестацией программного средства состоит в том, что

1. целью тестирования является поиск ошибок в программном средстве, целью аттестации – подтверждение корректной работы программы;
   
2. целью аттестации является поиск ошибок в программном средстве, целью тестирования – подтверждение корректной работы программы;
   
3. целью тестирования является прохождение 100% тестов, целью аттестации – наличие непройденных тестов.
   

101. Целью тестирования архитектуры программного средства является

1) поиск несоответствия между описанием архитектуры и совокупностью программ программного средства;

2) поиск расхождений между функциональной спецификацией и совокупностью программ программного средства;

3) поиск несогласованности документации по применению и совокупностью программ программного средства;

4. выяснение, в какой мере программное средство не соответствует предъявленному определению требований к нему.
   

102. Целью тестирования внешних функций программного средства является

1. поиск несоответствия между описанием архитектуры и совокупностью программ программного средства;
   
2. поиск расхождений между функциональной спецификацией и совокупностью программ программного средства;
   
3. поиск несогласованности документации по применению и совокупностью программ программного средства;
   
4. выяснение, в какой мере программное средство не соответствует предъявленному определению требований к нему.
   

103. Целью тестирования документации по применению программного средства является

1. поиск несоответствия между описанием архитектуры и совокупностью программ программного средства;
   
2. поиск расхождений между функциональной спецификацией и совокупностью программ программного средства;
   
3. поиск несогласованности документации по применению и совокупностью программ программного средства;
   
4. выяснение, в какой мере программное средство не соответствует предъявленному определению требований к нему.
   

104. Целью тестирования определения требований к программному средству является

1. поиск несоответствия между описанием архитектуры и совокупностью программ программного средства;
   
2. поиск расхождений между функциональной спецификацией и совокупностью программ программного средства;
   
3. поиск несогласованности документации по применению и совокупностью программ программного средства;
   
4. выяснение, в какой мере программное средство не соответствует предъявленному определению требований к нему.