Лекція 2. Елементи програмної інженерії.
•Аналіз нових перспективних розробок.
•Дослідницька робота в суміжних областях.
Допомога учених життєво необхідна в принаймні в двох ситуаціях:
•• Там, де в принципі не вирішити задачу своїми силами.
•• Там, де є фахівці, але немає часу і ресурсів для досліджень.
Цей підхід широко застосовується сучасними IT-компаниями: Intel, Microsoft, IBM та ін.
4.Складність програмної системи
Упростому випадку складність системи визначається як сума складності її модулів.
1. Складність модуля може обчислюватися різними способами. Наприклад, М. Холстед (1977) запропонував міру довжини модуля N [33]:
N ≈ n1log2 (n1) + n2log2(n2)
де n1 — число різних операторів, п2 — число різних операндів.
2. Як другу метрику М. Холстед розглядав об'єм V модуля (кількість символів для запису всіх операторів і операндів тексту програми):
V = N x log2 (n1 + n2).
Разом з тим відомо, що будь-яка складна система складається з елементів і системи зв'язків між елементами і що ігнорувати внутрісистемні зв'язки безрозсудно.
3.Том Маккейб (1976) при оцінці складності ПС запропонував виходити з топології внутрішніх зв'язків [49]. Для цієї мети він розробив метрику цикломатичної складності:
V(G)= E-N + 2
де Е — кількість дуг, a.N — кількість вершин в графові ПС, що управляє. Це був крок в потрібному напрямі. Подальше уточнення оцінок складності зажадало, щоб кожен модуль міг представлятися як локальна структура, що складається з елементів і зв'язків між ними.
Таким чином, при комплексній оцінці складності ПС необхідно розглядати міру складності модулів, міру складності зовнішніх зв'язків (між модулями) і міру складності внутрішніх зв'язків (усередині модулів) [28] [56]. Традиційно із зовнішніми зв'язками зіставляють характеристику «зчеплення», а з внутрішніми зв'язками — характеристику «зв'язність».
• Методи боротьби зі складністю
Відомо два загальні методи боротьби з складністю систем:
•забезпечення незалежності компонент системи;
•використання в системах ієрархічних структур.
Забезпечення незалежності компонент означає розбиття системи на такі частини, між якими повинні залишитися по можливості менше зв'язків. Одним з втілень цього методу є модульне програмування. Використання ієрархічних структур дозволяє локалізувати зв'язки між компонентами, допускаючи їх лише між компонентами, що належать суміжним рівням ієрархії. Цей метод, по-существу, означає розбиття великої системи на підсистеми, створюючих малу систему. Тут істотно використовується здібність людини до абстрагування.
5.Моделі якості процесів конструювання
Усучасних умовах жорсткої конкуренції, дуже важливо гарантувати високу якість процесу конструювання ПО. Таку гарантію дає сертифікат якості процесу, підтверджуючий
18
Лекція 2. Елементи програмної інженерії.
його відповідність прийнятим міжнародним стандартам. Кожен такий стандарт фіксує свою модель забезпечення якості. Найбільш авторитетні моделі стандартів ISO 9001:2000, ISO/ IEC 15504 і модель зрілості процесу конструювання ПЗ (Capability Maturity Model — СММ) Інституту програмної інженерії при американському університеті Карнеги-меллон.
Модель стандарту ISO 9001:2000 орієнтована на процеси розробки з будь-яких областей людської діяльності. Стандарт ISO/IEC 15504 спеціалізується на процесах програмної розробки і відрізняється вищим рівнем деталізації. Досить сказати, що об'єм цього стандарту перевищує 500 сторінок. Значна частина ідей ISO/IEC 15504 узята з моделі СММ.
Базовим поняттям моделі СММ вважається зрілість компанії. Незрілою називають компанію, де процес конструювання ПО і ухвалювані рішення залежать тільки від таланту конкретних розробників. Як наслідок, тут висока вірогідність перевищення бюджету або зриву термінів закінчення проекту.
Навпаки, в зрілій компанії працюють ясні процедури управління проектами і побудови програмних продуктів. В міру необхідності ці процедури уточнюються і розвиваються. Оцінки тривалості і витрат розробки точні, грунтуються на накопиченому досвіді. Крім того, в компанії є і діють корпоративні стандарти на процеси взаємодії із замовником, процеси аналізу, проектування, програмування, тестування і впровадження програмних продуктів. Все це створює середовище, що забезпечує якісну розробку програмного забезпечення.
Таким чином, модель СММ фіксує критерії для оцінки зрілості компанії і пропонує рецепти для поліпшення процесів, що існують в ній. Іншими словами, в ній не тільки сформульовані умови, необхідні для досягнення мінімальної організованості процесу, але і даються рекомендації по подальшому вдосконаленню процесів.
Дуже важливо відзначити, що модель СММ орієнтована на побудову системи постійного поліпшення процесів. У ній зафіксовано п'ять рівнів зрілості (мал. 1.9) і передбачений плавний, поетапний підхід до вдосконалення процесів — можна поетапно отримувати підтвердження про поліпшення процесів після кожного рівня зрілості.
Мал. 1.9. П'ять рівнів моделі зрілості (СММ)
Початковий рівень (рівень 1) означає, що процес в компанії не формалізований. Він не може строго плануватися і відстежуватися, його успіх носить випадковий характер.
19
Лекція 2. Елементи програмної інженерії.
Результат роботи цілком і повністю залежить від особистих якостей окремих співробітників. При звільненні таких співробітників проект зупиняється.
Для переходу на повторюваний рівень (рівень 2) необхідно упровадити формальні процедури для виконання основних елементів процесу конструювання. Результати виконання процесу відповідають заданим вимогам і стандартам. Основна відмінність від рівня 1 полягає в тому, що виконання процесу планується і контролюється. Вживані засоби планування і управління дають можливість повторення раніше досягнутих успіхів.
Наступний, визначений рівень (рівень 3) вимагає, щоб всі елементи процесу були визначені, стандартизованы і задокументовані. Основна відмінність від рівня 2 полягає в тому, що елементи процесу рівня 3 плануються і управляються на основі єдиного стандарту компанії. Якість що розробляється ПО вже не залежить від здібностей окремих осіб.
З переходом на керований рівень (рівень 4) в компанії приймаються кількісні показники якості як програмних продуктів, так і процесу. Це забезпечує точніше планування проекту і контроль якості його результатів. Основна відмінність від рівня 3 полягає в об'єктивнішій, кількісній оцінці продукту і процесу.
Вищий, оптимізуючий рівень (рівень 5) має на увазі, що головним завданням компанії стає постійне поліпшення і підвищення ефективності існуючих процесів, введення нових технологій. Основна відмінність від рівня 4 полягає в тому, що технологія створення і супроводу програмних продуктів планомірно і послідовно удосконалюється.
Кожен рівень СММ характеризується областю ключових процесів (ОКП), причому вважається, що кожен подальший рівень включає всі характеристики попередніх рівнів. Інакше кажучи, для 3-го рівня зрілості розглядаються ОКП 3-го рівня, ОКП 2-го рівня і ОКП 1-го рівня. Область ключових процесів утворюють процеси, які при сумісному виконанні приводять до досягнення певного набору цілей. Наприклад, ОКП 5-го рівня утворюють процеси:
запобігання дефектам;
управління змінами технології;
управління змінами процесу.
Якщо всі цілі ОКП досягнуті, компанії привласнюється сертифікат даного рівня зрілості. Якщо хоч би одна мета не досягнута, то компанія не може відповідати даному рівню СММ.
20