- •Інженерні основи програмного забезпечення
- •Поняття програмна інженерія. Що вивчає дисципліна «Програмна інженерія»?
- •Поняття системотехніка, бізнес-реінжиніринг.
- •Історія виникнення програмної інженерії.
- •Еволюційна модель розробки програмного забезпечення. Переваги та недоліки.
- •Формальна модель розробки програмного забезпечення. Переваги та недоліки.
- •Модель розробки програмного забезпечення на основі раніше створених компонентів. Переваги та недоліки.
- •Ітераційні моделі розробки програмного забезпечення. Переваги та недоліки.
- •Модель покрокової розробки програмного забезпечення. Переваги та недоліки.
- •Инструменты тестирования:
- •Мови моделювання програмного забезпечення.
- •Методи структурного аналізу.
- •Інформаційне моделювання Мартіна.
- •Структура та архітектура програмного забезпечення
- •Архітектура програмного забезпечення. Проектування архітектури.
- •Архітектурна модель клієнт-сервер.
- •Архітектурна модель абстрактної машини.
- •Архітектурні моделі управління (виклик-повернення та централізоване).
- •Проблемно-залежні архітектури програмного забезпечення.
- •Архітектура розподілених систем.
- •Багатопроцесорна архітектура програмного забезпечення.
- •Архітектура 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 іі.
- •Поняття ризику у проекті. Причини ризику в проекті.
- •Види ризиків. Моніторинг і контроль ризиків.
- •Поняття конфігурації. Елементи конфігурації.
- •Поняття супроводу програмного забезпечення. Хто здійснює супровід.
- •Поняття підтримки програмного забезпечення. Структура іт-супроводу.
- •Поняття програмна археологія. Інструменти і методи програмної археології.
Мови моделювання програмного забезпечення.
Systems Modeling Language (SysML) — мова моделювання загального призначення для застосувань в системній інженерії. Підтримує специфікацію, аналіз, дизайн, верифікацію та валідацію широкого діапазону систем. SysML спочатку розроблялась проектом специфікації оупенсорсної системи, та включала відкриту ліцензію для поширення та використання.[1] SysML описана як розширення підмножини Unified Modeling Language (UML) з використанням механізму профілів UML.
UML (англ. Unified Modeling Language) — уніфікована мова моделювання, використовується у парадигмі об'єктно-орієнтованого програмування. Є невід'ємною частиною уніфікованого процесу розробки програмного забезпечення. UML є мовою широкого профілю, це відкритий стандарт, що використовує графічні позначення для створення абстрактної моделі системи, яка називається UML-моделлю. UML був створений для визначення, візуалізації, проектування й документування в основному програмних систем. UML не є мовою програмування, але в засобах виконання UML-моделей як інтерпретованого коду можлива кодогенерація.
Перша версія (1.0) UML вийшла 13 січня 1997, вона була створена за запитом Object Management Group (OMG) — організації, відповідальної за прийняття стандартів в галузі об'єктних технологій і баз даних. Після обговорення, у вересні 1997 року, версія 1.1 UML була представлена на голосування в OMG. Розробку UML підтримали і вже тоді використовували як стандарт такі гранди ринку інформаційних технологій, як Microsoft, IBM, Hewlett-Packard, Oracle, DEC, Sybase, Logic Works й інші.
Поточна версія — 2.0.
Методи структурного аналізу.
У структурному аналізі і проектуванні використовуються різні моделі, що описують функціональну структуру системи;
визначається як ієрархія діаграм потоків даних, що описують асинхронний процес перетворення інформації від її введення в систему до видачі споживачеві. Практично, будь-який клас систем успішно моделюється за допомогою DFD-орієнтованих методів. Вони із самого початку створювалися як засіб проектування інформаційних систем, тоді як SADT - як засіб моделювання систем взагалі, і мають багатший набір елементів, що адекватно відображають специфіку таких систем.
З іншого боку, ці різновиди засобів структурного аналізу приблизно однакові з погляду функціональних можливостей засобів моделювання. При цьому одним з основних критеріїв вибору того чи іншого методу є ступінь володіння ним з боку консультанта або аналітика.
Найбільш поширеним засобом моделювання даних є модель "сутність - зв'язок" (Entity-Relationship Model - ERM). Вона вперше була введена П. Ченом у 1976 р. Ця модель традиційно використовується у структурному аналізі і проектуванні, проте, по суті, це підмножина об'єктної моделі предметної області. Один з різновидів моделі "сутність - зв'язок" використовується в методі IDEF1-X, що належить сімейству стандартів IDEF, і реалізується у низці поширених CASE-засобів (зокрема, AH Fusion ERwin Data Modeler).
Функціональне моделювання SADT.
Модель IDEF0. Принцип побудови.
Діаграми моделі ІDEF0.
Контекстная диаграмма. Самая верхняя диаграмма, на которой объект моделирования представлен единственным блоком с граничными стрелками. Эта диаграмма называется A-0 (А минус нуль). Стрелки на этой диаграмме отображают связи объекта моделирования с окружающей средой. Диаграмма A-0 устанавливает область моделирования и ее границу.
Диаграмма декомпозиции.
Складові діаграми ІDEF0.
Діаграма потоків даних- DFD. Синтаксис.
Модель ІDEF3. Синтаксис.
Структурні карти Константайна.
Структурні карти Джексона.
Діаграма переходів станів STD. Синтаксис.
Діаграми переходів станів призначені для моделювання і документування аспектів систем, що залежать від часу або реакції на події. Вони дозволяють здійснити декомпозицію керуючих процесів, описують відносини між вхідними та вихідними керуючими потоками. За допомогою STD можна моделювати подальше функціонування системи на основі її попереднього і поточного функціонування.
STD складається з наступних об'єктів:
Стан - може розглядатися як умова стійкості для системи. Перебуваючи в певному стані, ми маємо достатньо інформації про минуле системи, щоб визначити чергове стан в залежності від поточних вхідних подій.
Початковий стан - це вузол, який є стартовою точкою для початкового системного переходу. STD має тільки одне початковий стан.
Перехід - визначає переміщення модельованої системи з одного стану в інший.
Слід зазначити, що не всі події викликають переходи з окремих станів, а також одне і те ж подія не завжди викликає перехід в той же стан. На діаграмі STD стану представлені вузлами, а переходи - дугами.
Існує два способи побудови STD:
Перший полягає в ідентифікації всіх можливих станів і аналізі всіх, хто має сенс переходів між ними;
За другим способом спочатку визначається початковий стан, потім наступне за ним і т.д.
У ситуаціях, коли число станів або переходів велике, при проектуванні специфікацій управління можуть використовуватися таблиці або матриці переходів станів. Ці нотації дозволяють зафіксувати ту ж саму інформацію, що і діаграми переходів станів.
Матриця переходів станів містить по вертикалі перелік станів системи, а по горизонталі список умов. Кожен її елемент містить список дій, а також ім'я стану, в яке здійснюється перехід. Використовується і інший варіант даної нотації: по вертикалі показуються стану, з яких здійснюється перехід, а по горизонталі - стану, в які здійснюється перехід. При цьому кожен елемент матриці містить відповідні умови і дії, що забезпечують перехід з "вертикального" стану в "горизонтальне".
