Вопросы Модуль 3. Вопросы Модуль №3 (2). Этапы жизненного цикла

• Название: Этапы жизненного цикла
• Анкор: Вопросы Модуль 3
• Дата: 25.11.2019
• Размер: 34.43 Kb.
• Имя файла: Вопросы Модуль №3 (2).docx
• Тип: Документы; #96959

"Этапы жизненного цикла"

1. 
   Требования к ПО состоят из:
   

• 
  системных требований;
  
• 
  функциональных требований;
  
• 
  нефункциональных требований;
  
• 
  несистемных требований.
  

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

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

3. 
   Нефункциональные требования определяют:
   

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

4. 
   Требования пользователей определяют:
   

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

5. 
   Функциональные требования определяют:
   

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

6. 
   Системные требования определяют:
   

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

7. 
   В обсуждении требований на систему принимают участие:
   

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

8. 
   Спецификация требований к ПО - это:
   

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

9. 
   Инструментальные средства разработки ПО  это:
   

• 
  организационные средства планирования и отбора тестов для программ;
  
• 
  метрики измерения (Холстеда, цикломатичная сложность Маккейба и др.);
  
• 
  средства поддержки кодирования и тестирования (компиляторы, генераторы программ, отладчики и др.).
  

10. 
    Цель процесса валидации:
    

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

11. 
    Отладка - это:
    

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

12. 
    Инспекция ПО - это:
    

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

13. 
    Динамические методы тестирования используются:
    

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

14. 
    Систематические методы тестирования делятся на следующие методы:
    

• 
  метод "черного ящика";
  
• 
  метод "серого ящика";
  
• 
  метод "белого ящика".
  

15. 
    Функциональные тесты создаются по:
    

• 
  внешним спецификациям функций;
  
• 
  проектной информации;
  
• 
  результатам работы функций;
  
• 
  тексту на языке программирования.
  

16. 
    Все ошибки, которые возникают в программах, принято подразделять на следующие классы:
    

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

17. 
    В соответствии с международным стандартом ANSI/IEEE-729-83 Ошибка (error) - это:
    

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

18. 
    В соответствии с международным стандартом ANSI/IEEE-729-83 дефект (fault) - это:
    

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

19. 
    В соответствии с международным стандартом ANSI/IEEE-729-83 Отказ (failure) - это:
    

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

20. 
    В обязанности инженера-тестировщика входят:
    

• 
  оценка тестов;
  
• 
  создание тестовых сценариев;
  
• 
  исправление ошибок, выявленных на этапе тестирования;
  
• 
  составление плана теста.
  

21. 
    В обязанности инженера-тестировщика не входят:
    

• 
  оценка тестов;
  
• 
  создание тестовых сценариев;
  
• 
  исправление ошибок, выявленных на этапе тестирования;
  
• 
  составление плана теста.
  

22. 
    Требования - это:
    

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

23. 
    Проектирование ПО - это:
    

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

24. 
    Задачи проектирования - это:
    

• 
  построение архитектуры системы;
  
• 
  анализ и формирование требований;
  
• 
  преобразование требований к системе в требования к ПО.
  

25. 
    Архитектура системы - это:
    

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

26. 
    Условия построения архитектуры системы включают в себя:
    

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

1. 
   Примеры моделей ПО
   
2. 
   CASE – это (Дайте определение)
   
3. 
   Свойства хорошей программы:
   
4. 
   Метод – это (Дайте определение)
   
5. 
   Бизнес-процесс – это (Дайте определение)
   
6. 
   Требования – это (Дайте определение)
   
7. 
   3 уровня требований.
   
8. 
   Классификация системных требований
   
9. 
   Приведите пример функциональных требований
   
10. 
    Приведите пример нефункциональных требований
    
11. 
    Кто является источником требований?
    
12. 
    Какие мероприятия применяются для сбора требований
    
13. 
    Для чего нужен словарь предметной области?
    
14. 
    Перечислите общие рекомендации по формулировке требований
    
15. 
    Какими свойствами должны обладать хорошие требования?
    
16. 
    Какие существуют графические нотации для представления требований?
    
17. 
    Какие виды проектирования существуют?
    
18. 
    Что является результатом детального проектирования?
    
19. 
    Что является результатом архитектурного проектирования?
    
20. 
    Какие требования предъявляются к интерфейсу пользователя?
    
21. 
    Приведите 2-3 примера хорошего и плохого имени в программе. Объясните, почему Вы так считаете
    
22. 
    Перечислите правила выбора имен
    
23. 
    Перечислите правила хорошего оформления кода
    
24. 
    Что такое «Венгерская нотация»?
    
25. 
    Что такое ошибка в ПО?
    
26. 
    Отладка – это ?
    
27. 
    Дайте классификацию ошибок в ПО
    
28. 
    Методы «грубой силы» в отладке
    
29. 
    Методы отладки, возможные в Visual Studio
    
30. 
    Методы индукции и дедукции в отладке
    
31. 
    Тестирование ПО – это (дайте определение)
    
32. 
    Верификация ПО – это (дайте определение)
    
33. 
    Валидация ПО – это (дайте определение)
    
34. 
    Сопровождение ПО – это (дайте определение)
    
35. 
    Виды сопровождения
    
36. 
    В чем разница между тестированием и верификацией
    
37. 
    В чем разница между верификацией и валидацией
    
38. 
    Что включает в себя среда тестирования?