Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Экзамен. Вопросы. Майданюк.docx
Скачиваний:
0
Добавлен:
01.07.2025
Размер:
812.17 Кб
Скачать

Оглавление

1. Поняття технології конструювання програмного забезпечення. 4

2. Класичний життєвий цикл. 5

3. Макетування. 7

4. Характеристика стратегій конструювання ПЗ. 8

5. Інкрементна модель. 9

6. Спіральна модель. 10

7. Важковагові та полегшені процеси. XP – процес. 11

8. Швидка розробка додатків, RAD. 13

9. Компонентно-орієнтована модель. Моделі якості процесів конструювання. 14

10. Сторони зацікавлені в продукції. 16

11. Користувачі. Покупці. Інвестори. 18

12. Вимоги до ПЗ кожної з сторін. 19

13. Атрибути якості ПЗ: практичність, відмовостійкість, надійність, ремонтопридатність. 20

14. Визначення архітектури ПЗ. 21

15. Опис архітектури ПЗ. 22

16. Універсальна мова моделювання (UML). 23

17. Інші базові засоби для створення архітектури. 24

18. Основні компоненти мови. Призначення мови. Термінологія UML. 25

19. Процес керування проектом. Планування. 26

20. Планування проектних задач. 27

21. Розмірно-орієнтовані метрики. 28

22. Функціонально-орієнтовані метрики. 29

23. Виконання оцінки проекту на основі LOC- та FP-метрик. 30

24. Дослідження під моделей моделі COCOMO, COCOMO II. 32

25. Конструктивна модель вартості. 33

26. Модель композиції додатку. 34

27. Модель раннього етапу проектування. 35

28. Модель етапу пост архітектури. 36

29. Структурний аналіз. 38

30. Основи проектування програмних систем. 39

31. Класичні методи проектування. 40

32. Основні поняття та принципи тестування ПЗ. 42

33. Особливості тестування «білого ящику». 43

34. Способи тестування базового шляху. 44

35. Способи тестування умов. 45

36. Спосіб тестування потоків даних. 46

37. Тестування циклів. 47

38. Особливості тестування «чорного ящику». 48

39. Спосіб розбиття по еквівалентності. 50

40. Спосіб аналізу граничних значень. 51

41. Спосіб діаграм причин-наслідків. 52

42. Дослідження способів структурного та функціонального тестування на прикладах. 54

43. Методика тестування програмних систем. 57

44. Тестування правильності. 60

45. Системне тестування . 62

46. Мистецтво налагоджування. 65

47. Основні принципи об’єктна-орієнтованої методології розробки програмної системи (ООМ ПС). 67

48. ОО Аналіз. 70

49. Об’єкти та класи. 74

50. Діаграми в UML. 75

51. Механізми розширення в UML. 77

52. Діаграма варіантів використання. 79

53. Дослідження діаграми варіантів використання. 81

54. Діаграма класів. 82

55. Дослідження діаграми класів. 85

56. Діаграма станів. 86

57. Дослідження діаграми станів. 88

58. Діаграма діяльності. 89

59. Дослідження діаграми діяльності. 91

60. Діаграма послідовності. 92

61. Дослідження діаграми послідовності. 96

62. Діаграма кооперації. 97

63. Дослідження діаграми кооперації. 99

64. Діаграма компонентів. 100

65. Дослідження діаграми компонентів. 101

66. Діаграма розгортування. 102

67. Дослідження діаграми розгортування. 103

68. Загальні відомості CASE-засобів. 104

69. CASE-засоби. Класифікація CASE-засобів. 105

70. Порівняння життєвого циклу програмного забезпечення при традиційній розробці і розробці з використанням CASE-засобів. 106

71. Концептуальні основи CASE-технології. 107

72. Технологія впровадження –засобів. 108

73. Оцінка і вибір –засобів. 109

74. Засоби функціонального моделювання. 110

75. Характеристики CASE–засобів Silverrun. 111

76. Характеристики CASE–засобів JAM. 112

77. Характеристики CASE–засобів Vantage Team Builder (Westmount I-CASE) + Uniface. 114

78. Характеристики CASE–засобів Designer/2000 + Developer/2000. 115

79. Загальна характеристика CASE-системи Rational Rose. 117

80. Розробка діаграм у середовищі Rational Rose. 118

81. Початок роботи над проектом у середовищі Rational Rose. 120

  1. Поняття технології конструювання програмного забезпечення.

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

Различают методы, средства и процедуры ТКПО.

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

  • планирование и оценка проекта;

  • анализ системных и программных требований;

  • проектирование алгоритмов, структур данных и программных структур;

  • кодирование;

  • тестирование;

  • сопровождение.

Средства (утилиты) ТКПО обеспечивают автоматизированную или автоматическую поддержку методов. В целях совместного применения утилиты могут объединяться в системы автоматизированного конструирования ПО. Такие системы принято называть CASE-системами.

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

  • порядок применения методов и утилит;

  • формирование отчетов, форм по соответствующим требованиям;

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

  • формирование «вех», по которым руководители оценивают прогресс.

Процесс конструирования программного обеспечения состоит из последовательности шагов, использующих методы, утилиты и процедуры. Эти последовательности шагов часто называют парадигмами ТКПО.

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

  1. Класичний життєвий цикл.

Найстарішою парадигмою процесу розробки ПЗ є класичний життєвий цикл (автор Уїнстон Ройс, 1970)

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

Охарактеризуємо зміст основних етапів.

Мається на увазі, що розробка починається на системному рівні і проходить че­рез аналіз, проектування, кодування, тестування і супровід. При цьому моделюються дії стандартного інженерного циклу.

Системний аналіз задає роль кожного елемента в комп'ютерній системі, взаємодія елементів один з одним. Оскільки ПЗ є лише частиною великої системи, то аналіз починається з визначення вимог до всіх системних елементів і призначення підмножини цих вимог програмному «елементу». Необхідність системного підходу явно виявляється, коли формується інтерфейс ПЗ з іншими елементами (апаратурою, людьми, базами даних). На цьому ж етапі починається рішення задачі планування проекту ПЗ. В ході пла­нування проекту визначаються об'єм проектних робіт і їх ризик, необхідні трудовитрати, формуються робочі задачі і план-графік робіт.

Аналіз вимог відноситься до програмного елемента — програмному забезпе­чення. Уточнюються і деталізуються його функції, характеристики і інтерфейс.

Всі визначення документуються в специфікації аналізу. Тут же завершується рішення задачі планування проекту

Основні терміни життєвого циклу

Проектування полягає в створенні уявлень

1.Архітектуру ПЗ;

2.Модульної структури ПЗ

3.Алгоритмічної структури ПЗ

4.Структури даних

5. Вхідного і вихідного інтерфейсу (вхідних і вихідних форм даних).

Початкові дані для проектування містяться в специфікації аналізу, тобто в ході проектування виконується трансляція вимог до ПЗ в безліч проектних уявлень. При рішенні задач проектування основну увагу приділяють якості майбутнього програмного продукту.

Кодування полягає в перекладі результатів проектування в текст на мові програмування. Тестування — виконання програми для виявлення дефектів у функціях, логіці і формі реалізації програмного продукту. Супровід — це внесення змін в експлуатоване ПЗ. Мета змін:

1.Виправлення помилок;

2.Адаптація до змін зовнішнього для ПЗ середовища

3.Удосконалення ПЗ по вимогах замовника.

Супровід ПЗ полягає в повторному застосуванні кожного з попередніх кроків (етапів) життєвого циклу до існуючої програми, але не в розробці нової програми.

Переваги класичного життєвого циклу: дає план і часовий графік по всіх етапах проекту, упорядковує хід конструювання.

Недоліки класичного життєвого циклу:

1) реальні проекти часто вимагають відхилення від стандартної послідовності кроків;

2) цикл заснований на точному формулюванні початкових вимог до ПО (реально на початку проекту вимоги замовника визначені лише частково);

3) результати проекту доступні замовнику тільки в кінці роботи.