Та за характером:

1. Функціональний характер — вимоги до поведінки системи

   1. Бізнес-вимоги

   2. Вимоги користувача

   3. Функціональні вимоги

2. Нефункціональний характер — вимоги до характеру поведінки системи

   1. Бізнес-правила — визначають обмеження, що витікають з предметної області.

   2. Системні вимоги — вимоги до програмних інтерфейсів, надійності, обладнанню.

   3. Атрибути якості

   4. Зовнішні системи та інтерфейси

   5. Обмеження

Білет 20

Завдання: Організація розробки вимог до складних програмним засобів. Концепція вимог до проекту. Коректно (правильна) система.

В складній системі такий список вимог може розтягуватись на сотні сторінок. Відповідною метафорою може бути надзвичайно довгий список покупок. Такі списки не дуже цінуються в сучасному аналізі, так як вони показали малу успішність в досягненні своїх цілей. Тим не менш, Їх іноді можна побачити і сьогодні. Як альтернатива до великих, попередньо-описаних списків вимог гнучка розробка програмного забезпечення використовує історії користувачів щоб описати вимогу в повсякденних термінах.

Концепція вимог до проекту:

1. 1995 — Парне програмування. Дана концепція стала складовою частиною методології Extreme Programming. Незалежно від того, що було виконано кілька досліджень, що демонструють ефективність програмування в парах, дана концепція не знайшла реального відображення в Agile-маніфесті.

2. 1997 —Процес розробки ПЗ за методологією FDD був представлений світу за допомогою публікації книги "Java Modeling in Color with UML: Enterprise Components and Process".

3. 1999 — Adaptive Software Development. Методологія швидкого створення додатків (RAD). Три фази життєвого циклу: 1) Speculation; 2) Collaboration; 3) Learning. Розроблено концепця екстремального програмування (Extreme Programming). Дана методологія описує найкращі практики у сфері планування, управління, проектування, кодування і тестування. Ward Cunningham і Ron Jeffries також привнесли свої ідеї, так що всі троє вважаються засновниками методу XP.

Коректно (правильна система):

Предметом постійного інтересу і дослідження є побудова систем докази коректності, або правильності програм. Найбільш розробленими виявилися системи докази для випадку коректності функціональних програм, які сходять до системи LCF Робіна Мілнера і системі Р. Бойєра (R. Boyer) і Дж. Мура (J. Moore).

Білет 21

Завдання: Вимоги з точки зору клієнта. Права і обов’язки клієнта.

Вимоги з точки зору клієнта:

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

Права і обов’язки клієнта:

Технічне завдання (ТЗ) - зобов'язаний надавати замовник. Якщо у Вас немає ТЗ, Ви можете звернутися за допомогою до виконавця, але знайте, що це платна послуга.

Білет 22

Завдання: Організація документування програмних засобів. Управління документацією. Помилки та дефекти.

Організація документування програмних засобів:

Кожна стадія розробки програмного продукту завершується складанням відповідних документів.

1. Специфікація вимог – це вимоги до програмного продукту і до усіх файлів ПЗ.

2. Лістинг програми – код програми та коментарі.

//Приклад:

//Лістинг 1.3 документований код

/* Цей метод реалізує вимогу 4.3:

*Встановлення податку

*Автор І. Гребенюк.

*Версія 2.3.4

*параметр «z» - означає zoom

*/

< деякий код з коментарями >

3. Технічне завдання – містить інформацію про призначення і область застосувань ПЗ.

4. Документація по тестуванню ПЗ – містить план налаштування результату.

5. План управління програмним проектом – складає керівник проекту.

6. Керівництво для користувача «справка», може бути паперовою і електронною.

7. Проектна документація ПЗ – має представлення про архітектуру (діаграми модулів, об’єктів, потоків даних).

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

Зазвичай, для користувача документація являє собою керівництво користувача, яке описує кожну функцію програми, а також кроки, які потрібно виконати для використання цієї функції. Хороша користувача документація йде ще далі і надає інструкції про те що робити у разі виникнення проблем. Дуже важливо, щоб документацію не вводила в оману і була актуальною. Керівництво повинно мати чітку структуру; дуже корисно, якщо є наскрізною предметний покажчик. Логічна зв'язність і простота також мають велике значення.

Білет 22

Завдання: Організація документування програмних засобів. Управління документацією. Помилки та дефекти.

Організація документування програмних засобів:

Кожна стадія розробки програмного продукту завершується складанням відповідних документів.

8. Специфікація вимог – це вимоги до програмного продукту і до усіх файлів ПЗ.

9. Лістинг програми – код програми та коментарі.

//Приклад:

//Лістинг 1.3 документований код

/* Цей метод реалізує вимогу 4.3:

*Встановлення податку

*Автор І. Гребенюк.

*Версія 2.3.4

*параметр «z» - означає zoom

*/

< деякий код з коментарями >

10. Технічне завдання – містить інформацію про призначення і область застосувань ПЗ.

11. Документація по тестуванню ПЗ – містить план налаштування результату.

12. План управління програмним проектом – складає керівник проекту.

13. Керівництво для користувача «справка», може бути паперовою і електронною.

14. Проектна документація ПЗ – має представлення про архітектуру (діаграми модулів, об’єктів, потоків даних).

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

Зазвичай, для користувача документація являє собою керівництво користувача, яке описує кожну функцію програми, а також кроки, які потрібно виконати для використання цієї функції. Хороша користувача документація йде ще далі і надає інструкції про те що робити у разі виникнення проблем. Дуже важливо, щоб документацію не вводила в оману і була актуальною. Керівництво повинно мати чітку структуру; дуже корисно, якщо є наскрізною предметний покажчик. Логічна зв'язність і простота також мають велике значення.

Білет 24

Завдання: Шаблон специфікації вимог до ПЗ. Принципи створення вимог.

Шаблон специфікації вимог до ПЗ:

1. Вступ.

   • Призначення, мета. Визначаються вимоги до документа. Межі продукту, якщо це частина системи чи підсистема.

   • Продукти аналоги. Наводяться у вигляді таблиці порівняння функціональних і не функціональних характеристик продуктів аналогів. Ще сюди включають зв’язки інтерфейсів, web – посилань.

2. Загальний опис.

   • Характеристики продукту (описуємо узагальнені функції продукту).

   • Класи користувачів та їх характеристики. Визначають різні користувачі, які користуються продуктом, їх фізичні характеристики).

   • Середовище функціонування. Описується середовище, апаратна платформа, операційна система.

3. Характеристики системи. (Описується організація до функціональних вимог продукту). Цей розділ можна показувати варіантами використання класами.

   • Функціональні вимоги. Перелічуються детально функціональні вимоги. Вимоги повинні бути повними, короткими, не двозначними, кожна вимога повинна бути унікально пронумерована. Наприклад: REQ – 1.1:..; 1.2.. і т.д.

4. Вимоги зовнішніх інтерфейсів.

   • Користувацькі інтерфейси. Тут описуються взаємодія користувача і інтерфейсу. (Може бути прінтскрінено).

   • Апаратні інтерфейси. Описується взаємодія з пристроями програмного продукту. Наприклад: з принтером, камерами.

   • Програмні інтерфейси. Взаємодія з програмними засобами. Якщо не взаємодіє - цей пункт опускається.

   • Комунікаційні інтерфейси. (Браузери і т. д.).

5. Інші не функціональні вимоги.

   • Вимоги продуктивності.

   • Вимоги безпеки (паролі, секретні дані, ідентифікація користувачів).

   • Атрибути якості (додаткове).

6. Юридичні вимоги та інші.

Принципи створення специфікації вимог:

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

• принцип системної єдності, який полягає в тому, що на всіх стадіях створення, функціонування та розвитку ПЗ його цілісність буде забезпечуватися зв'язками між підсистемами, а також функціонуванням підсистеми управління;

• принцип розвитку, який передбачає в ПЗ можливість його нарощування та вдосконалення компонентів і зв'язків між ними;

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

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

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

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

Білет 25

Завдання: Поняття архітектури програмного забезпечення. Класифікація та вибір архітектури ПЗ.

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

Класифікація та вибір архітектури ПЗ:

1. Архітектура, яка базується на потоках даних ( суть архітектури в тому, що дані проходять між процесами обробки ).

Приклад:

2. Незалежні компоненти. Складається з компонентів, які працюють паралельно. Прикладом є архітектури у середовищі інтернет.

3. Клієнт – серверна архітектура. Обслуговує клієнтів за допомогою запитів, має багато переваг, тому що компоненти не залежать один від одного. Одним із компонентів може бути сервер. Другий компонент це браузер користувача. Клієнт – серверні архітектури є 2х видів:

   • Дворівнева архітектура. Складається із клієнта і сервера;

   • Трьох рівнева. Складається із клієнт – сервер і рівень між клієнтом і сервером, який відповідає за пере направлення даних.

4. Архітектура паралельних взаємодіючих процесів. Характеризується тим, що одночасно запускає декілька процесів.

5. Репозиторна архітектура. Побудована навколо даних. Більшість таких систем призначені для обробки транзакцій до БД.

6. Рівнева – це логічно зв’язана колекція властивостей програмного забезпечення (Зазвичай пакет класів. Наприклад: ігри).

7. Віртуальні машини архітектура. Архітектура, яка розглядає програму написану на спеціальній мові, тому повинен бути реалізований інтерпретатор цієї мови.