- •Базові поняття swebok
- •4. Назвати цілі і завдання програмної інженерії.
- •5. Назвати базові поняттями еr-моделі даних, з якою метою її будують?
- •Дати визначення життєвого циклу розробки програмного забезпечення . Які основсі процеси включають це поняття ?
- •Описати використання методу покрокової деталізації при розробці алгоритміів і структури програмного забезпечення. У чому , по вашому, полягає основка складність даного методу?
- •10 . Назвати міжнародний стандарт, який визначає перелік і зміст процесів жц програмного продукту та описати його зміст?
- •13. Дати визначення процесу життєвого циклу пз та описати склад процесів життєвого циклу, який регламентується міжнародним стандартом.
- •Обгрунтувати потребу в передпроектних дослідженнях для формування вимог до програмного забезпечення.
- •19 Назвати основні етапи розробки програмного забезпечення. Які основні завдання вирішуються на цих етапах?
- •20 Обгрунтувати, для чого використовують мову uml? Чому її називають мовою моделювання? Чим обумовлений вибір саме цієї мови як стандарту опису об'єктних розробок?
- •17. Обгрунтувати суть об'єктної декомпозиції?
- •21 Назвати основні моделі життєвого циклу програмного забезпечення. З чим пов'язана поява нових моделей?
- •23. Обгрунтуйте появу case-технологій.
- •28. Обгрунтувати, які відносини між основними поняттями наочної області відображають концептуальні моделі?
- •30.Описати, які діаграми uml застосовують для опису поведінки програмного забезпечення, що проектуємо?
- •31. Перерахувати дев’ять найкращих навиків, рекомендованих методикою spmn.
- •32. Обгрунтувати поняття «системні події» і « системні операції»? Що необхідно для побудови діаграми послідовностей системи?
- •33. Пояснити п’ять рівнів технологічної зрілості моделі смм.
- •35. Перерахувати основні положення технології rad? Які програмні системи не можна розробляти з використанням цієї технології?
- •Пояснити моделі якості процесів розробки програмного забезпечення? Для чого вони розроблені? Що гарантує сертифікація якості процесів? Чому?
- •39. Назвати дійових осіб процесу формування вимог.
- •40. Обгрунтувати, які стереотипи класів введені і чому?
- •41. Обгрунтувати, чому ми говоримо, що сучасний етап розвитку технології програмування характеризується переходом від ремісничого до промислового виробництва програмного забезпечення?
- •42.Пояснити, яку діаграму використовують при уточненні взаємодії об'єктів?
- •43.Пояснити, як називається фаза життєвого циклу розробки програмного забезпечення, на якій формується контракт між замовником і виконавцем розробки?
- •44.Перерахувати основні компоненти класів. Як описують ці компоненти?
- •45.Обгрунтувати, що повинно міститися в звіті щодо аналізу здійсненності створення пз.
- •46.Пояснити, у яких випадках використовують діаграми станів об'єкту?
- •47.Описати процес формування і аналізу вимог.
- •Описати підхід з використанням різних опорних точок зору для побудови і організації як процесу формування вимог, так і безпосередньо самих вимог.
- •Пояснити, яку інформацію містить діаграма розміщення? у яких випадках доцільно використовувати ці діаграми?
- •Виділити типи програмних продуктів?
- •Обгрунтувати. Метод uml пропонує різні нотації (графічні діаграми) для різних аспектів опису проблеми. Чому не єдину?
- •Назвати основні експлуатаційні вимоги до програмних продуктів. Якими засобами і прийомами забезпечується кожен з них? Для яких типів програмних систем доцільно вказувати кожен з них?
- •Пояснити, які значення можуть мати атрибути видимості класів та що вони означають?
- •55. Обгрунтувати, у яких ситуаціях необхідні передпроектні дослідження? Які питання при цьому вирішують? Що отримують в результаті таких досліджень?
- •56. Назвати, які відношення позначаються в діаграмі класів uml спеціальними графічними символами?
- •57. Назвати, який розділ технічного завдання можна вважати основним і чому? Яку інформацію повинна містити решта розділів? у чому основна складність розробки технічного завдання?
- •58. Обґрунтувати, які діаграми uml доцільно застосовувати для аналізу вимог? з якої діаграми доцільно починати?
- •59. Обґрунтуйте, які принципові рішення повинні бути прийняті на початкових етапах процесу проектування і чому?
- •60. Обгрунтувати, які діаграми відображають обмін повідомленнями як єдиний засіб взаємодії об’єктів?
- •61. Визначити суть структурного підходу до програмування? Які етапи охоплює даний підхід?
- •62. Обгрунтувати, чи можна застосувати ті самі діаграми для кількох стадій розроблення пз?
- •Пояснити, яка роль стереотипів у нотаціях uml?
- •65. Обгрунтуйте, у яких випадках доцільно використовувати діаграми переходів станів? Які умовні позначення використовуються для побудови цієї діаграми?
- •66. Пояснити, що таке прототип у спіральній моделі?
- •67. Обгрунтувати, у чому полягає основна відмінність між функціональними діаграмами і діаграмами потоків даних? у яких випадках використання діаграм потоків даних є домінуючим?
- •68. Пояснити термін «модель життєвого циклу пз».
- •71 Описати побудову sadt-моделі.
- •Вказати, який міжнародний стандарт визначає перелік і зміст процесів життєвого циклу програмного продукту?
61. Визначити суть структурного підходу до програмування? Які етапи охоплює даний підхід?
Суть структурного підходу до розробки ПЗ полягає в декомпозиції (розбитті) системи на автоматизовані функції, які в свою чергу діляться на підфункції, на завдання і так далі. Процес декомпозиції триває аж до визначення конкретних процедур. При цьому система зберігає цілісність, де всі складові компоненти взаємопов'язані.
В основу структурного підходу покладено такі загальні принципи: - Розбиття системи на безліч незалежних завдань, легких для розуміння і рішення;
- Ієрархічне впорядкування, тобто організація складових частин проблеми в деревоподібні структури з додаванням нових деталей на кожному рівні.
Основні етапи структурного підходу:
- конструювання алгоритму з використанням трьох базових алгоритмічних структур (лінійна, розгалужена, циклічна)
- використання методу покрокової деталізації, тобто подрібнення задачі на більш прості задачі, потім подрібнення цих задач на ще більш прості складові й т. д.
- аналіз алгоритму, тобто контроль правильності кожної структури алгоритму і взаємозв’язків структур.
Перевагою структурного підходу є його модульність. Модуль — це послідовність логічно пов’язаних команд, яка оформлена у вигляді окремого алгоритму. Структурний підхід застосовується при використанні процедурних мов програмування.
62. Обгрунтувати, чи можна застосувати ті самі діаграми для кількох стадій розроблення пз?
Автори не закріплювали діаграми жорстко за окремими етапами життєвого циклу розробки, більшість діаграм може відображатися з кількома ступенями деталізації об’єктів на кількох етапах: аналізу вимог, проектування, реалізації тощо. Для цього передбачено можливість вказувати або замовчувати (залежно від стадії) окремі подробиці визначення.
Є діаграми, які можна застосовувати лише на стадії аналізу вимог (наприклад, діаграма варіантів використання), інші можна використовувати лише на стадії проектування (наприклад, діаграма пакетів, кооперації, станів, компонентів і розміщення). Також є вид діаграм, які можна застосовувати як на стадії аналізу вимог, так і на стадії проектування. До таких діаграм належать діаграма класів, діаграма послідовностей дій та діаграма діяльності.
Широкий набір засобів і методів на різних стадіях розробки дозволяють виділити ті сторони поведінки об'єктів, які найкращим чином відображають їхні властивості.
63.Пояснити термін «специфікації»? У чому складність їх уточнення? У якому вигляді зазвичай представляють специфікації?
Специфікація вимог до програмного забезпечення (SRS) - це повний опис поведінки системи що розробляється. Він включає набір прецедентів, що описують всі взаємодії користувача з системою. Прецеденти також відомі як функціональні вимоги. На додачу до прецедентів, SRS також містить нефункціональні (чи додаткові вимоги). Нефункціональні вимоги є вимогами які накладають обмеження на проект, чи реалізацію (такі як вимоги інженерії продуктивності, стандарти якості, чи обмеження проектування).
Рекомендовані підходи до специфікації вимог до ПЗ описані в стандарті IEEE 830-1998. Цей стандарт описує можливі структури, бажаний вміст і якості специфікації вимог.