- •Інженерні основи програмного забезпечення
- •Поняття програмна інженерія. Що вивчає дисципліна «Програмна інженерія»?
- •Поняття системотехніка, бізнес-реінжиніринг.
- •Історія виникнення програмної інженерії.
- •Еволюційна модель розробки програмного забезпечення. Переваги та недоліки.
- •Формальна модель розробки програмного забезпечення. Переваги та недоліки.
- •Модель розробки програмного забезпечення на основі раніше створених компонентів. Переваги та недоліки.
- •Ітераційні моделі розробки програмного забезпечення. Переваги та недоліки.
- •Модель покрокової розробки програмного забезпечення. Переваги та недоліки.
- •Инструменты тестирования:
- •Мови моделювання програмного забезпечення.
- •Методи структурного аналізу.
- •Інформаційне моделювання Мартіна.
- •Структура та архітектура програмного забезпечення
- •Архітектура програмного забезпечення. Проектування архітектури.
- •Архітектурна модель клієнт-сервер.
- •Архітектурна модель абстрактної машини.
- •Архітектурні моделі управління (виклик-повернення та централізоване).
- •Проблемно-залежні архітектури програмного забезпечення.
- •Архітектура розподілених систем.
- •Багатопроцесорна архітектура програмного забезпечення.
- •Архітектура corba.
- •Моделі об’єктно-орієнтованого проектування програмного забезпечення.
- •Проектування систем реального часу.
- •Проектування з повторним використанням компонентів.
- •Проектування інтерфейсу програмного забезпечення.
- •Документування програмних продуктів.
- •Поняття документація на програмне забезпечення, програмний документ. Типи документації.
- •Організації що публікують стандарти.
- •Типовий набір документації проекту.
- •Основні стандарти розробки програмних систем і програмного забезпечення.
- •Стандарти вимог, архітектури, якості і тестування програмного забезпечення.
- •Стандарти серії гост 34.Ххх та гост 19.Ххх.
- •Процеси за стандартом iso/іec 12207.
- •Процеси за стандартом iso/іec 15288.
- •Поняття вимоги. Етапи формування вимог. Рівні вимог.
- •Які розділи містить звіт про виконану роботу та заявку на розробку програмного забезпечення?
- •Склад і зміст робіт на стадії «Опис програмного забезпечення».
- •Поняття ескізний проект. Склад і зміст робіт на стадії «Ескізний проект».
- •Що описує Технічне завдання (тз). З яких етапів складається розробка тз та на основі якого стандарту?
- •З яких розділів складається технічне завдання?
- •Що описує Технічний проект (тп)? з яких етапів складається розробка технічного проекту?
- •Види забезпечень.
- •Статичні і динамічні методи тестування.
- •Тестування «білої скриньки»
- •Тестування «чорної скриньки».
- •Метод "сірої скриньки".
- •Види тестування.
- •Рівні тестування.
- •Помилки на етапах життєвого циклу програмного забезпечення.
- •Поняття помилки, дефекту та відмови.
- •Класи помилок в програмному забезпеченні.
- •Тест план (Test Plan). Тестовий сценарій (Test Cases). Процедури тестування (Test Procedures). Баг Репорт (Bug Report).
- •Моделі якості та надійності програмних систем
- •Якість програмного забезпечення. Модель якості за рівнями.
- •Показники якості.
- •Атрибути функціональності, надійності та зручності застосування.
- •Атрибути ефективності, супроводу та переносимості.
- •Метрики програмного продукту.
- •Метрики процесу створення продукту та використання.
- •Методи оцінки значень показників якості.
- •Методи управління програмним проектом
- •Поняття надійності програмного забезпечення.
- •Класифікації моделей надійності за Гоєлем.
- •Класифікації моделей надійності за Хетчем.
- •Інженерія надійності програмного забезпечення та її складові.
- •На яких процесах жц здійснюється перевірка надіності?
- •Поняття сертифікація програмного забезпечення. Види сертифікації продукту.
- •Евристична модель надійності.
- •Модель надійності Нельсона.
- •Модель надійності Джелінскі-Моранді.
- •Статистична модель надійності Міллса.
- •Поняття Проект (Project). Менеджмент проекту (Project Management). Масштаб проекту (Project Scope).
- •Головні цілі менеджменту проекту.
- •Процес менеджменту проекту.
- •Модель процесу керування проектом.
- •Учасники проекту з розробки програмного забезпечення.
- •Ролі в групі розробників проекту.
- •Мережні методи планування і керування проектом.
- •Метод критичного шляху – срм.
- •Метод аналізу й оцінки проекту – pert.
- •Види планів організації проекту.
- •Моніторинг проекту.
- •Модель оцінки вартості проекту cocomo.
- •Модель оцінки вартості проекту cocomo іі.
- •Поняття ризику у проекті. Причини ризику в проекті.
- •Види ризиків. Моніторинг і контроль ризиків.
- •Поняття конфігурації. Елементи конфігурації.
- •Поняття супроводу програмного забезпечення. Хто здійснює супровід.
- •Поняття підтримки програмного забезпечення. Структура іт-супроводу.
- •Поняття програмна археологія. Інструменти і методи програмної археології.
Архітектурна модель клієнт-сервер.
Модель клієнт-сервер - це модель розподіленої системи, в якій показано розподіл даних і процесів між декількома процесорами. Модель включає три основних компоненти:
Набір серверів, що надають послуги іншим підсистемам;
Набір клієнтів, які викликають ці сервіси;
Мережа, за допомогою якої клієнти отримують доступ до сервісів.
Плюси:
Простота додавання нових серверів;
Простота поновлення сервісів.
Мінуси:
Високі вимоги до пропускної здатності мережі.
Архітектурна модель абстрактної машини.
Модель абстрактної машини організовує систему у вигляді набору рівнів, кожен з яких надає свої сервіси. Кожен рівень визначає абстрактну машину, машинний мову якої (послуги) використовується для реалізації наступного рівня абстрактної машини
Плюси:
Покрокове розвиток системи;
Крос-платформенность.
Мінуси:
Складна структура.
Архітектурні моделі управління (виклик-повернення та централізоване).
У моделі централізованого керування одна підсистема виділяється як системний контролер, її обов'язок - керувати роботою інших підсистем. Розрізняють два різновиди моделей централізованого керування: модель виклик-повернення і Модель диспетчера , що використовується в системах паралельної обробки.
Модель виклику-повернення - може бути застосована тільки в послідовних системах і реалізує передачу управління "зверху-вниз"
Проблемно-залежні архітектури програмного забезпечення.
Поряд з основними моделями, використовуються архітектурні моделі, характерні для конкретної предметної області додатки. Ці моделі називаються проблемно-зависмости архітектурою.
Моделі класів систем
Моделі класів систем відображають класи реальних систем, увібравши в себе основні характеристики цих класів. Як правило, моделі класів зустрічаються в системах реального часу. Модель компілятора - найбільш відомий приклад цієї моделі.
Базові моделі
Базові моделі являють собою ідеалізовану архітектуру, в якій відображені всі особливості, властиві системам, що працюють в даній предметній області. Прикладом такої архітектури може служити модель OSI.
Базові моделі зазвичай не розглядаються в якості методів реалізації; їх основне призначення - служити еталоном для порівняння різних систем в будь-якої предметної області.
Архітектура розподілених систем.
Розподілена система керування — автоматизована система керування технологічним процесом, що характеризується побудовою розподіленої системи введення-виведення та децентралізацією обробки даних.
Розподіленою називається така система, в якій обробка інформації зосереджена не на одній машині, а розподілена між декількома комп’ютерами. При проектуванні розподілених систем, які мають багато загального з проектуванням іншого довільного програмного продукту (ПП), але при цьому необхідно враховувати ряд специфічних особливостей.
Багатопроцесорна архітектура програмного забезпечення.
Самою простою розподіленою системою є багатопроцесорна система. Вона складається з множини різних процесів, які можуть (не обов’язково) виконуватись на різних процесорах. Дана модель часто використовується у великих системах реального часу. Дані системи збирають інформацію, приймають на її основі рішення і відправляють сигнали виконавчому механізму, який змінює системне оточення. В принципі всі процеси, пов’язані зі збором ін формації, прийняттям рішень і керуванням виконавчим механізмом, можуть виконуватися одним процесором під керуванням планувальника завдань. Використання декількох процесорів підвищує продуктивність системи і її здатність до відновлення. Розподіл процесів між процесорами може перевизначитися або ж знаходитись під керуванням диспетчера процесів.
