- •Лекція 0. Вступ. Цілі, завдання і місце курсу
- •1. Мета викладання курсу
- •2. Завдання вивчення курсу
- •3. Дисципліни, засвоєння яких необхідне при вивченні курсу
- •4. Характеристика курсу
- •5.1. Література
- •5.2. Інформаційні ресурси мережі Інтернет
- •Лекція 1. Введення у технологію програмування
- •1. Термінологія індустрії ПЗ
- •1.1. Програмування
- •1.2. IT-проекти
- •1.3. Програми і програмне забезпечення (програмні продукти)
- •2. Бізнес і IT-проекти. Ринок ПЗ.
- •3. Про предмет
- •5. Виникнення Технології розробки ПЗ
- •5.1. Коротка історія програмування
- •5.2. Терміни “Технологія”, “Методологія” і “Програмна інженерія”
- •5.3. Стратегії розробки ПЗ
- •6. Огляд технологій програмування
- •6.1. Структурне програмування
- •6.2. Модульне програмування
- •6.4. Компонентне програмування
- •6.5. Висновки з лекції
- •Лекція 2. Елементи програмної інженерії
- •1. Програмна інженерія, основні поняття
- •1.1. Інженери і програмні інженери
- •1.2. Програмна інженерія як інженерна дисципліна
- •1.3. Область дії програмної інженерії
- •2. Цілі програмних інженерів
- •2.1. Поняття “якості” програмного продукту
- •2.2. Створення ПЗ повинно вкладатися до бюджету
- •2.3. Створення ПЗ повинно вкладатися в терміни
- •3. Забезпечення надійності розробки ПЗ
- •3.1. Забезпечення точності інтерпретації
- •3.2. Подолання бар'єру між користувачем і розробником
- •3.3. Контроль ухвалюваних рішень
- •3.4. Програмні інженери і наукове середовище
- •4. Складність програмної системи
- •4.1. Методи боротьби зі складністю
- •5. Моделі якості процесів розроблення ПЗ
- •Лекція 3. Організація технологічного процесу розробки ПЗ
- •1. Процес створення програмного забезпечення
- •1.1. Основні стадії типового процесу створення ПП
- •2. Життєвий цикл та моделі процесу розробки ПЗ
- •2.1. Каскадна модель (Waterfall model)
- •2.2. Макетування (прототипіювання)
- •2.3. Інкрементна модель
- •2.4. Модель Швидкої Розробки (RAD)
- •2.5. Спіральна модель
- •3. “Важкі” і “полегшені” процеси
- •4. ХР-процесс
- •Лекція 4. Оцінка програмного проекту по СОСОМО
- •1. Процес управління проектом
- •1.1. Початок проекту
- •1.2. Оцінювання, заходи і метрики
- •1.3. Процес оцінки
- •1.4. Аналіз ризиків
- •1.5. Планування
- •1.6. Трасування і контроль
- •2. Планування проектних завдань
- •3. Розмірно-орієнтовані метрики
- •4. Функціонально-орієнтовані метрики
- •5. Оцінка проекту на основі LOC- і FP-метрик
- •Лекція 5. Проектування програмних систем
- •1. Особливості процесу синтезу програмних систем
- •2. Особливості етапу проектування
- •3. Структуризація системи
- •4. Моделювання управління
- •5. Декомпозиція підсистем на модулі
- •6. Модульність
- •7. Інформаційна закритість
- •8. Зв'язність модуля
- •8.1. Функціональна зв'язність
- •8.2. Інформаційна зв'язність
- •8.3. Комунікативна зв'язність
- •8.4. Процедурна зв'язність
- •8.5. Часова зв'язність
- •8.7. Випадкова Зв'язність
- •8.8. Визначення зв'язності модуля
- •9. Зчеплення модулів
- •10. Складність програмної системи
- •11. Характеристики ієрархічної структури програмної системи
- •Лекція 6. ПОБУДОВА АРХІТЕКТУРИ ПП
- •1. Поняття архітектури програмного засобу.
- •2. Основні принципи проектування архітектури
- •3. Основні питання архітектора ПП
- •4. Архітектурні стилі (шаблони) ПП
- •5. Поєднання архітектурних стилів
- •6. Основні класи архітектур ПП
- •6.1. Цілісна програма
- •6.2. Архітектура ППП
- •6.3. Архітектура, заснована на шині повідомлень
- •6.4. Архітектура клієнт/сервер
- •6.6. Багатошарова архітектура
- •6.8. Компонентна архітектура
- •6.10. Сервісно-орієнтована архітектура
- •7. 4. Контроль архітектури ПП
- •Лекція 7. Розробка Програм, Модульне Програмування
- •1. Поняття модульного програмування
- •1.1. Основні характеристики програмного модуля.
- •1.2. Методи розробки структури програми.
- •1.3. Контроль структури програми.
- •2. Розроблення програмних модулів
- •2.1. Порядок розробки програмного модуля
- •2.2. Структурне програмування модуля
- •2.3. Покрокова деталізація і поняття про псевдокод.
- •Лекція 8. Тестування і відлагодження ПЗ
- •1. Основні поняття тестування і відлагодження
- •2. Основні підходи і принципи відлагодження.
- •2.1. Заповіді відлагодження.
- •2.2. Автономна відладка модулів
- •2.3. Проміжна відладка програмного засобу
- •2.4. Комплексна відладка програмного засобу.
- •3. Організація процесу тестування ПЗ
- •3.1. Тестування елементів
- •3.2. Інтегральне Тестування ПП
- •3.3. Низхідне тестування інтеграції
- •3.4. Висхідне тестування інтеграції
- •3.5. Порівняння низхідного і висхідного тестування інтеграції
- •4. Види Тестування
- •4.1. Тестування правильності
- •4.2. Системне тестування
- •4.3. Тестування відновлення
- •4.4. Тестування безпеки
- •4.5. Стресове тестування
- •4.6. Тестування продуктивності
Лекція 2. Елементи програмної інженерії.
4.Складність програмної системи
Упростому випадку складність системи визначається як сума складності її модулів.
Складність модуля може обчислюватися різними способами. Наприклад, М. Холстед (1977) запропонував міру довжини модуля N [33]:
N ≈ n1log2 (n1) + n2log2(n2)
де n1 — число різних операторів, п2 — число різних операндів.
Як другу метрику М. Холстед розглядав об'єм V модуля (кількість символів для запису всіх операторів і операндів тексту програми):
V = N x log2 (n1 + n2).
Разом з тим відомо, що будь-яка складна система складається з елементів і системи зв'язків між елементами і що ігнорувати внутрісистемні зв'язки безрозсудно.
Том Маккейб (1976) при оцінці складності ПС запропонував виходити з топології внутрішніх зв'язків [49]. Для цієї мети він розробив метрику цикломатичної складності:
V(G)= E-N + 2
де Е — кількість дуг, a N — кількість вершин в графі ПС, що управляє. Це був крок в потрібному напрямі. Подальше уточнення оцінок складності зажадало, щоб кожен модуль міг представлятися як локальна структура, що складається з елементів і зв'язків між ними.
Таким чином, при комплексній оцінці складності ПС необхідно розглядати міру складності модулів, міру складності зовнішніх зв'язків (між модулями) і міру складності внутрішніх зв'язків (всередині модулів) [28] [56]. Традиційно із зовнішніми зв'язками зіставляють характеристику «зчеплення», а з внутрішніми зв'язками — характеристику «зв'язність».
4.1.Методи боротьби зі складністю
Відомо два загальні методи боротьби з складністю систем:
1.забезпечення незалежності компонент системи;
2.використання в системах ієрархічних структур.
Забезпечення незалежності компонент означає розбиття системи на такі частини, між якими повинні залишитися по можливості менше зв'язків. Одним з втілень цього методу є модульне програмування. Використання ієрархічних структур дозволяє локалізувати зв'язки між компонентами, допускаючи їх лише між компонентами, що належать суміжним рівням ієрархії. Цей метод, по-существу, означає розбиття великої системи на підсистеми, створюючих малу систему. Тут істотно використовується здібність людини до абстрагування.
5.Моделі якості процесів розроблення ПЗ
Усучасних умовах жорсткої конкуренції, дуже важливо гарантувати високу якість процесу конструювання ПЗ. Таку гарантію дає сертифікат якості процесу, підтверджуючий його відповідність прийнятим міжнародним стандартам. Кожен такий стандарт фіксує свою модель забезпечення якості. Найбільш авторитетні моделі стандартів ISO 9001:2000, ISO/ IEC 15504 і модель зрілості процесу конструювання ПЗ (Capability Maturity Model — СММ) Інституту програмної інженерії при американському університеті Карнеги-меллон.
Модель стандарту ISO 9001:2000 орієнтована на процеси розробки з будь-яких областей людської діяльності. Стандарт ISO/IEC 15504 спеціалізується на процесах програмної розробки і відрізняється вищим рівнем деталізації. Досить сказати, що об'єм цього стандарту перевищує 500 сторінок. Значна частина ідей ISO/IEC 15504 узята з моделі СММ.
Базовим поняттям моделі СММ вважається зрілість компанії. Незрілою називають компанію, де процес конструювання ПО і ухвалювані рішення залежать тільки від таланту конкретних розробників. Як наслідок, тут висока вірогідність перевищення бюджету або зриву термінів закінчення проекту.
Навпаки, в зрілій компанії працюють ясні процедури управління проектами і побудови програмних продуктів. В міру необхідності ці процедури уточнюються і розвиваються. Оцінки
18
Лекція 2. Елементи програмної інженерії.
тривалості і витрат розробки точні, грунтуються на накопиченому досвіді. Крім того, в компанії є і діють корпоративні стандарти на процеси взаємодії із замовником, процеси аналізу, проектування, програмування, тестування і впровадження програмних продуктів. Все це створює середовище, що забезпечує якісну розробку програмного забезпечення.
Таким чином, модель СММ фіксує критерії для оцінки зрілості компанії і пропонує рецепти для поліпшення процесів, що існують в ній. Іншими словами, в ній не тільки сформульовані умови, необхідні для досягнення мінімальної організованості процесу, але і даються рекомендації по подальшому вдосконаленню процесів.
Дуже важливо відзначити, що модель СММ орієнтована на побудову системи постійного поліпшення процесів. У ній зафіксовано п'ять рівнів зрілості (мал. 1.9) і передбачений плавний, поетапний підхід до вдосконалення процесів — можна поетапно отримувати підтвердження про поліпшення процесів після кожного рівня зрілості.
Мал. 1.9. П'ять рівнів моделі зрілості (СММ)
Початковий рівень (рівень 1) означає, що процес в компанії не формалізований. Він не може строго плануватися і відстежуватися, його успіх носить випадковий характер. Результат роботи цілком і повністю залежить від особистих якостей окремих співробітників. При звільненні таких співробітників проект зупиняється.
Для переходу на повторюваний рівень (рівень 2) необхідно упровадити формальні процедури для виконання основних елементів процесу конструювання. Результати виконання процесу відповідають заданим вимогам і стандартам. Основна відмінність від рівня 1 полягає в тому, що виконання процесу планується і контролюється. Вживані засоби планування і управління дають можливість повторення раніше досягнутих успіхів.
Наступний, визначений рівень (рівень 3) вимагає, щоб всі елементи процесу були визначені, стандартизованы і задокументовані. Основна відмінність від рівня 2 полягає в тому, що елементи процесу рівня 3 плануються і управляються на основі єдиного стандарту компанії. Якість що розробляється ПО вже не залежить від здібностей окремих осіб.
З переходом на керований рівень (рівень 4) в компанії приймаються кількісні показники якості як програмних продуктів, так і процесу. Це забезпечує точніше планування проекту і контроль якості його результатів. Основна відмінність від рівня 3 полягає в об'єктивнішій, кількісній оцінці продукту і процесу.
Вищий, оптимізуючий рівень (рівень 5) має на увазі, що головним завданням компанії стає постійне поліпшення і підвищення ефективності існуючих процесів, введення нових технологій. Основна відмінність від рівня 4 полягає в тому, що технологія створення і супроводу програмних продуктів планомірно і послідовно удосконалюється.
Кожен рівень СММ характеризується областю ключових процесів (ОКП), причому
19
Лекція 2. Елементи програмної інженерії.
вважається, що кожен подальший рівень включає всі характеристики попередніх рівнів. Інакше кажучи, для 3-го рівня зрілості розглядаються ОКП 3-го рівня, ОКП 2-го рівня і ОКП 1 -го рівня. Область ключових процесів утворюють процеси, які при сумісному виконанні приводять до досягнення певного набору цілей. Наприклад, ОКП 5-го рівня утворюють процеси:
o запобігання дефектам;
o управління змінами технології; o управління змінами процесу.
Якщо всі цілі ОКП досягнуті, компанії привласнюється сертифікат даного рівня зрілості. Якщо хоч би одна мета не досягнута, то компанія не може відповідати даному рівню СММ.
20
