
- •1.Правила розробки інтерфейсу
- •2.Елементи структурного підходу
- •3.Прапорці потоку даних (малюнки не витирати! Вони є ключовими у відповіді!)
- •4.Складові організації даних (можна просто перерахувати всі пункти без хнього опису)
- •5.Постійність бази даних
- •6.Обмеження бази даних
- •7.Послідовність бази даних
- •8.Зв’язок бази даних з реальністю
- •9.Контроль копіювання даних
- •10.Модель даних
- •11.Доступність даних
- •12.Безпека даних
- •13.Критерії вибору субд
- •14.В чому полягає оптимізація проекту
- •15.Методи оптимізації системи
- •16.Обмеження при переході до моделі розробки
- •17.Фізична структура системи
- •18.Правильність та якість системи
- •19.Верифікація діаграм класів
- •20.У чому полягає якість системи
- •21.Критерії декомпозиції системи
- •22.Рівні зв’язку компонентів системи
- •23. В чому полягає прозорість проекту
- •24.Не функціональні вимоги етапу проектування
- •25.Результати етапу проектування
- •26.Структура детального документу проекту
- •27.Модифікація, еволюція та відповідальність за документ, створений на етапі проектування
- •28. На стратегічному етапі виконуються наступні дії:
- •29. Співпраця з клієнтом
- •30. Область дії і контекст проекту
- •31.На цьому етапі існує декілька стратегічних рішень, які повинні бути прийняті:
- •32. Як правило, існують декілька можливих рішень по системі і ці варіанти рішень підпорядковані певним обмеженням. Обмеження можуть стосуватись:
- •33. Під вивченням досяжності розробки розуміють:
- •36. Оцінка вартості рішень
- •42.Чинники успіху стратегічного етапу?
- •43.Результати стратегічного етапу?
- •44.Причини складності формулювання вимог до системи?
- •45. Рівні опису вимог?
- •47.У чому полягає правильність формулювання вимог до системи користувачем?
- •49.Методи опису вимог?
- •50.Типи вимог?
- •51. У чому полягає функціональний опис вимог?
- •52.Що собою представляють нефункціональні вимоги?
- •53.Причини формулювання нефункціональні вимоги?
- •56.Чинники успіху при формуванні документу з вимогами?
- •57.Чинники успіху етапу формулювання вимог?
- •58.Що собою являє модель системи?
- •59.Що є метою побудови моделі?
- •60.Які існують моделі?
- •61.Коли необхідно будувати більш повну модель?
- •62 Аналітична модель
- •63.Що собою представляє логічна модель?
- •64.Які описи використовують під час побудови аналітичної моделі?
- •65.Основні дії під час аналізу системи?
- •66. Вимоги до системних функцій?
- •67.Чинники успіху етапу аналізу?
- •68.Результати етапу аналізу?
- •69.Мета етапу проектування системи?
- •70.Специфікація результатів етапу аналізу?
- •71.Специфікація асоціативного виконання?
- •72.Компоненти програмного забезпечення?
- •73.Поняття про методологію швидкої розробки програмних ужитків (rad)?
- •74.Розробка інтерфейсу?
- •75.Способи взаємодії програмного продукту з користувачем?
- •76. Проблеми, які виникають в процесі розробки програмного забезпечення?
- •77. Причини складності розробки програмного забезпечення?
- •78. Що розуміють під розробкою програмного забезпечення?
- •79.Причини виникнення кризи в розробці пз?
- •80. Як обмежують кризові явища в процесі розробки пз?
- •81. Що собою являє концептуальне моделювання?
- •82.Сутність моделі водоспаду?
- •83. Цикли розробки пз на основі каскадної моделі?
- •84. Переваги та недоліки моделі водоспаду?
- •85. Переваги і недоліки моделі водоспаду з зворотнім зв’язком?
- •86. Сутність моделі водоспаду з зворотнім зв’язком?
- •87. Сутність моделі документованого виконання?
- •88. Переваги та недоліки моделі документованого виконання?
- •89. Сутність прототипування?
- •90. Що включає в себе прототипування?
- •91. Мета побудови прототипу?
- •92. Переваги і недоліки прототипування?
- •93. Методи побудови прототипу?
- •94. Сутність покрокової розробки пз?
- •95. Переваги і недоліки покрокової розробки пз?
- •96. Сутність моделі збирання готових елементів?
- •97. Методи, які використовуються в моделі збирання готових елементів?
- •98. Переваги використання готових компонентів?
- •99. Сутність моделі спіралі розробки пз
- •100. Поняття про етап розробки програмного забезпечення?
- •101. Діаграма співвідношення життєвих циклів розробки пз?
- •102. Сутність стратегічного етапу розробки пз?
- •103. Дії на стратегічному етапі?
- •104. Рішення, які приймаються на стратегічному етапі?
- •105. Обмеження на стратегічному етапі?
- •106. Стандарти стратегічного етапу?
- •107. Чинники успіху стратегічного етапу?
- •108. Основні результати стратегічного етапу?
- •109. Сутність етапу визначення вимог?
- •110. Труднощі, які виникають на етапі формування вимог?
- •111. Абстрактний рівень описання вимог клієнта?
- •112. В чому полягає якісний опис вимог?
- •113. Типи вимог?
- •114. Що включає в себе документація по опису вимог?
- •115. Сутність функціональних вимог?
- •116. Сутність нефункціональних вимог?
- •117. Що необхідно для успішного формулювання не функціональних вимог?
- •118. Сутність етапу аналізу?
- •119. Чинники успіху етапу аналізу?
- •120. Що є результатом виконання етапу аналізу?
- •121. Сутність етапу проектування?
- •122 Завдання етапу проектування?
- •123. Чинники успіху етапу проектування?
- •124. Що є результатом етапу проектування?
- •125. Сутність етапу реалізації?
- •130. Що розуміють під тестуванням?
- •131. Види тестів?
- •132. Фази тестування?
94. Сутність покрокової розробки пз?
Покрокова розробка починається з формулювання вимог і розробки базового проекту всієї системи. На наступному кроці вибираються деякі функції. Вони реалізуються каскадною моделлю і відбувається опис їх реалізації. Протестувавши реалізовану частину її відправляють замовнику.
95. Переваги і недоліки покрокової розробки пз?
Переваги і недоліки моделі
Переваги:
менші часові розриви у взаємодії із замовником
можливість більш швидкого використання частин системи
гнучкість при затримках в роботі
якщо реалізація однієї частини затримується, це не зупиняє весь проект, це мотивує розробника працювати над іншими частинами швидше.
Недолік моделі - додаткова вартість, необхідна для незалежної реалізації частин системи. Практично неможливо зробити повністю незалежний набір функцій. При цьому може виникнути необхідність реалізувати скелети модулів, тобто моделі з інтерфейсами, що узгоджені зі всім системним інтерфейсом але не реалізовують їх функції до кінця. Реалізація цих модулів вимагає додаткового робочого навантаження і збільшує вірогідність помилок.
96. Сутність моделі збирання готових елементів?
Модель збірки готових елементів акцентує увагу на можливості зменшити капітал, що витрачається на розробку шляхом максимізації схожості створеного ПЗ із вже існуючим.
Вже існуючі елементи можуть використовуватися на різних стадіях розробки. Зазвичай це етап реалізації.
Приклади використовуваних елементів:
бібліотеки
мови четвертого покоління, в яких інструкції обробляються як посилання на вбудовані бібліотеки
повні програми, наприклад браузер допомоги в MS Windows
Останнім часом підвищився інтерес до використання готових елементів на етапах аналізу і дизайну. CASE -Інструменти полегшують використання елементів, створених в інших проектах. Деякі компанії стверджують, що вони можуть використовувати до 90% готових продуктів. Очевидно, що можливість повторного використання залежить від схожості системних компонентів. Деякі компанії пропонують так званий інструментарій дизайну. Це вже готові методи для банків, страхових компаній і інших підприємств. Моделі реалізовуються у вигляді CASE -інструментарію.
97. Методи, які використовуються в моделі збирання готових елементів?
Є два методи збірки готових компонентів:
придбання у зовнішніх постачальників
розробка біжучого проекту з розрахунком на його багатократне використання в наступних проектах
98. Переваги використання готових компонентів?
Переваги і недоліки моделі
Переваги використання готових компонентів:
висока надійність, - готові компоненти добре перевірені на практиці
зменшення ризику
ефективне використання експертів
стандартні вимоги. Готові компоненти реалізовувалися відповідно до деяких стандартів, які повинні бути задоволені в поточному проекті.
можливість зменшення ціни. Вартість нових компонентів зазвичай менша, ніж вартість розробки "з нуля".
Недоліками моделі є:
додаткова вартість створення компонентів для подальшого використання ( компоненти системи повинні бути розроблені для користування . Вартість інвестицій може не відшкодуватися в майбутньому).
Залежність від одного постачальника ( постачальник може перестати розробляти бібліотеку або не модифікувати її під нові вимоги ПЗ чи нову апаратуру).
Недолік інструментів, що підтримують роботу ( у разі CAD/CAM, які, як було згадано вище, служать в інших дисциплінах тієї ж мети, що і CASE, мають можливість використання бібліотек готових компонентів. Інструменти CASE підтримували в обмеженому об'ємі цей вид роботи до останнього часу. Сучасні інструменти кращі, але розробка нових все ще необхідна).