• 1.1                      Вступ у технології програмування
  • 1.1.1                      Базові поняття, види програмного забезпечення
    • Види програмного забезпечення
    • Інтегроване середовище розроблення програмного забезпечення
    • Поняття технології програмування як процесу
  • 1.1.2                      Розвиток мов, стилів та технологій програмування
    • Ранні мови програмування
    • Імперативне програмування (Imperative programming)
    • Декларативне програмування (Declarative programming)
    • Об’єктно-орієнтоване програмування (Object-oriented programming)
    • Компонентне програмування (Component-based programming)
• 1.2                      Життєвий цикл програмного забезпечення
• 1.3                      Моделі життєвого циклу ПЗ
  • 1.3.1                      Каскадна модель ЖЦ (Waterfall model)
  • 1.3.2                      Ітеративна модель (Iterative model)
  • 1.3.3                      Еволюційна модель
  • 1.3.4                      Спіральна модель (Spiral model)
  • 1.3.5                      V-подібна модель
  • 1.3.6                      Адаптивний ЖЦ (Adaptive Life Cycle)

1.1                      Вступ у технології програмування

1.1.1                      Базові поняття, види програмного забезпечення

Технологія програмування (Programming technology), або технологія створення програмних продуктів  -  дисципліна, що вивчає технологічні процеси програмування та порядок їх проходження при виконання проекту зі створення програмного продукту.
 

Споріднені до технології програмування такі дисципліни:

• Комп'ютерні науки (Computer science) –  сукупність знань та практичних навичок, які використовують спеціалісти з інформаційних систем, обчислювальної техніки, інформатики.
• Системна інженерія (System engineering)  –  розділ науки, який вивчає питання розробки комп'ютерних  систем (архитектура, дизайн, інтеграція, ПЗ і т.ін.).
• Програмна інженерія (Software engineering) – дисципліна, спрямована на розробку й супроводження програмного забезпечення систем, що функціонують надійно та ефективно, можуть вдосконалюватися й еволюціонувати, та відповідають вимогам, визначеним замовником [1].

Програмування  (Programming) - процес підготовки задач для їх розв'язання за допомогою комп'ютера; ітераційний процес складання програм.

Програма – дані, призначені для управління конкретними компонентами системи обробки інформації з метою реалізації певного алгоритму [2], послідовність машинних команд, призначена для досягнення конкретного результату.

Програмне забезпечення (ПЗ/Software) – комп’ютерні програми, процедури, а також документація й дані, що з ними асоційовані, які стосуються функціонування комп’ютерної системи [3].

Уперше термін software увів відомий статистик Джон Т’юкей (John Tukey) у 1958 р. для позначення різниці апаратного забезпечення ЕОМ (hardware) від засобів обробки даних.

Б’ярне Страуструп (Bjarne Stroustrup) зазначив, що добре ПЗ не можна побачити, але можна відчути, коли воно працює із помилками [4].

Види програмного забезпечення

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

Системне ПЗ (System software) призначене для управління роботою комп'ютера, розподілу його ресурсів, підтримки діалогу з користувачами, а також для часткової автоматизації розроблення нових програм. Як правило, системні програми забезпечують взаємодію інших програм з апаратними складовими, організацію інтерфейсу користувача. Віділяють три типи системного ПЗ:

• операційна система (ОС) - програмне забезпечення, що забезпечує інфраструктуру, на якій можуть працювати прикладні програми. Найпоширеніші ОС - Microsoft Windows, Mac OS X та Linux;
• системи програмування - призначені для полегшення та часткової автоматизації процесу розроблення та відлагодження програм;
• сервісні програми (утиліти)  розширюють можливості ОС. До утиліт відносять архіватори, антивіруси, драйвери та ін.

Прикладне ПЗ (application, application software) -  комп'ютерна програма, що  вирішує конкретні задачі фахової діяльності користувача.

Інструментальне ПЗ - програма, призначена для розроблення всіх видів інформаційно-програмного забезпечення. До інструментального ПЗ відносять текстові редактори, системи керування базами даних, транслятори мов програмування.

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

Інтегроване середовище розроблення програмного забезпечення

Для розроблення програм використовуються спеціальні засоби ,які дозволяють писати програмний код і транслювати його в машинні команди.

Інтегроване середовище розроблення програмного забезпечення  (integrated development environment, IDE) – це система програмних засобів, що використовується програмістами для розроблення програмного забезпечення.

Як правило, IDE включає текстовий редактор, компілятор і/або інтерпретатор, засоби автоматизації складання, налагоджував та різноманітні інструменти для конструювання графічного інтерфейсу користувача. Значне поширення об’єктно-орієнтованого програмування привело до того, що сучасні інструменти розроблення включають браузер класів та інспектор об’єктів. На сьогодні до середовищ розроблення підключають систему керування версіями, засоби тестування та ін.

Раніше середовища розроблення переважно призначалися для однієї мови (Delphi, Turbo Pascal, Borland C++,Visual Basic), але на даний час широко застосовувані такі IDE, як Eclipse або Microsoft Visual Studio, призначені для мультимовного розроблення ПЗ.

Поняття технології програмування як процесу

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

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

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

Особливо багато проблем виникає із розумінням поставленої задачі. Тому обов’язково потрібно оформлювати технічне завдання за стандартними правилами. Неувага до формалізації завдання на розроблення ПЗ приводить до того, що створену систему неможливо здати в експлуатацію через величезну кількість зауважень, викликаних різночитаннями і незрозумілостями в постановці завдання.

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

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

Технологія програмування (ТП) - це сукупність методів і засобів розроблення (написання) програм та порядок застосування цих методів та засобів.

У англомовній літературі замість терміна «технологія програмування» використовується термін «методологія» (methodology) для позначення пов’язаних між собою методів та технік програмування [5].

Усі технології, які використовують програмісти, підпорядковуються основній меті:

• створити якісний продукт;
• вкластися в бюджет;
• дотриматися строків.

Ускладнення програмних систем та процесів розроблення викликало потребу створення механізмів керування та контролю процесів, тобто підключення технологічних підходів, що розпочалося із систематизації робіт. Наступними кроками стали встановлення технологічних маршрутів діяльності розробників ПЗ, визначення можливості їх автоматизації та виявлення ризиків, розроблення інструментів для автоматизації.

Перший етап автоматизації процесу створення програмного забезпечення був пов’язаний із підтримкою процесу програмування та систематизацією робіт. Розуміння, що інструменти підтримки процесу кодування є необхідною умовою підвищення продуктивності праці, але недостатньою для промислового розроблення програм. На цій стадії з’явились інструменти програмування із підтримкою написання коду. Після цього стали з’являтися засоби автоматизованого налагодження програм. У цей самий час (кінець 60-х рр. ХХ ст.) потреба створення великих за розміром програм із складними алгоритмами привела до розуміння необхідності розвитку теоретичної бази і запровадження поняття життєвого циклу ПЗ.

Відразу стали помітними проблемні місця виробництва програмних продуктів: нерозвиненість методології проектування та неможливість оцінити якість ПЗ лише у ході тестування. Фактично перша проблема викликає другу: нечітко поставлене завдання з програмування не дає параметрів для перевірки якості роботи. Однією з основних початкових вимог у процесі програмування стала вимога чіткої специфікації проекту. На основі даних із специфікації почали регламентувати процес проектування. Стали з’являтися певні технології розроблення програмних продуктів. Подальший розвиток методологій розроблення призвів до появи формалізованого менеджменту вимог у ході аналізу.

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

Щоб зрозуміти, які технології використовувати для певного проекту, розібратися з методикою програмування, необхідно в першу чергу вивчити розвиток мов та підходів до програмування.

1.1.2                      Розвиток мов, стилів та технологій програмування

Ранні мови програмування

Перші мови програмування виникли слідом за появою електронних обчислювальних машин (ЕОМ) у 40-ві роки XX століття. Вони були досить примітивні і орієнтовані на числові розрахунки. Це були і суто теоретичні наукові розрахунки (математичні й фізичні), і прикладні завдання, в першу чергу у галузі військової справи.

Програми, написані на ранніх мовах програмування, були лінійними послідовностями елементарних операцій з регістрами, в яких зберігалися дані. Тому будь-яка технологія програмування була відсутня. Перші кроки в розробленні технології полягали у представленні програми у вигляді послідовності операторів – операторний підхід. Написанню послідовності машинних команд передувало складання операторної схеми, що відбивала послідовність операторів і переходи між ними. У цей період почало зароджуватися поняття алгоритму.

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

Час появи:  1940 роки.

Стисла характеристика: лінійна послідовність елементарних інструкцій «низького рівня».

Переваги:  висока обчислювальна ефективність.

Недоліки:  істотна залежність від середовища обчислень.

Приклади:  машинні коди, асемблери.

Імперативне програмування (Imperative programming)

Приблизно у 50-ті роки XX століття з’явилися мови програмування так званого «високого рівня» порівняно з раніше розглянутими попередниками. Різниця від мов низького рівня полягає у підвищенні ефективності праці розробників за рахунок абстрагування від конкретного апаратного забезпечення. Один оператор мови високого рівня відповідав послідовності з кількох низькорівневих команд. Виходячи з того, що  программа фактично являла собою набір директив, звернених до комп’ютера, такий підхід до программування назвали імперативним.

Можна вважати що в цей період з’явились стилі, або парадигми, програмування. На рис.1. наведена схема їх розвитку.                                                                  

Наступним кроком розвитку програм стало підвищення їх структурованості – структурний підхід, при якому виділяли канонічні структури: лінійні ділянки, цикли та розгалуження. Завдяки цьому з’явилася можливість читати і перевіряти програму як текст, а це підвищило ефективність праці програмістів під час розроблення та відлагодження програм.

Розмір програм постійно збільшувався, тому програмісти почали об’єднувати окремі їх частини у підпрограми, які групували у бібліотеки. Бібліотеки підключалися до основної робочої програми, яка за необхідності викликала потрібну підпрограму. Фактично такий підхід збільшив структурність програм – велика програма стала сукупністю процедур-підпрограм. Одна підпрограма, головна, розпочинала роботу всієї програми. Тобто відбувся перехід до наступного етапу розвитку технологій – процедурного програмування  (Procedural programming).

При розробленні окремої процедури для використання інших процедур потрібно було знати лише їх призначення та спосіб. Процедурний підхід дозволив скоротити затрати праці і машинного часу на створення і модернізацію програм завдяки можливості зміни окремої процедури без втручання в інші. З’явилася можливість повторного використання раніше написаних програмних блоків завдяки їх ідентифікації і наступного звернення за цим ідентифікатором.

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

Окрім того, поява мов високого рівня значно зменшила залежність реалізації від апаратного забезпечення. Щоб це реалізувати, були створені спеціалізовані програми – транслятори, призначені для перетворення інструкції мови програмування у коди певної машини. Використання трансляторів привело до певної втрати швидкості обчислень, але цей недолік компенсувався значним виграшем у швидкості розроблення і модифікації програм.

Також у цей період розпочали розроблення спеціалізованих мов програмування для розв’язання конкретних класів задач: для систем керування базами даних, імітаційного моделювання та ін.

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

Практика програмування показала, що велика частина високорівневих мов, створених у період процедурного підходу, дуже вдало реалізована, тому вони або їх варіації використовуються до цього часу. Наприклад, до цього часу використовується мова Fortran для реалізації обчислювальних алгоритмів, мова COBOL для опису бізнес-процесів, мова Pascal (Паскаль), а мова APL поетапно трансформувалась у слабо типізовану мову С (Cі).

Час появи:  1950 роки.

Стисла характеристика: програма - послідовність інструкцій-операторів, у яку включені блоки типових дій – процедури або функції.

Переваги: 

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

Недоліки: 

• більші витрати на вивчення мов;
• менша обчислювальна ефективність.

Приклади:  Fortran, ALGOL, PL/1, APL, BPL, COBOL, Pascal, C, Basic.

Декларативне програмування (Declarative programming)

У 60-х рр. ХХ століття виникає  новий підхід до програмування, що до цього часу успішно конкурує з імперативним, а саме –декларативний підхід. При декларативному підході до програмування програма є не набором команд, а описом дій, які потрібно виконати. Цей підхід легко формалізується математичними засобами. У результаті програми легше перевіряти на помилки і відповідність технічним специфікаціям (верифікувати). Також даний підхід має високий ступінь абстракції. Фактично програміст оперує не набором інструкцій, а абстрактними поняттями, часто досить узагальненими.

На початку декларативним мовам програмування було важко конкурувати з імперативними у зв’язку із проблемами при створенні ефективних трансляторів. Програми працювали повільніше, однак вони вирішували більш абстрактні завдання із меншити затратами.

Функціональне програмування (Functional programming)

Одним із шляхів розвитку декларативного стилю програмування став функціональний підхід, що виник із появою і розвитком мови LISP.

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

При функціональному програмуванні повторне використання коду зводиться до виклику раніше описаної функції, структура якої, на відміну від процедури імперативної мови, прозора математично. Більш того, типи окремих функцій, що використовуються у функціональних мовах, можуть бути змінними. Тобто забезпечується можливість обробки різнорідних даних (наприклад, упорядкування елементів списку за зростанням для цілих чисел, окремих символів і рядків), або поліморфізм. Завдяки реалізації механізму зіставлення із зразком, такі мови, як ML та Haskell, які добре підходять для символьної обробки.

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

До недоліків мов функціонального програмування відносять нелінійну структуру програми і відносно невисоку ефективність реалізації. Однак перший недолік досить суб'єктивний, а другий успішно подоланий сучасними реалізаціями, зокрема низкою останніх трансляторів мови SML, включаючи і компілятор для середовища Microsoft. NET.

Час появи: 1960 роки.

Стисла характеристика: програма - функція, аргументи якої, можливо, також є функціями.

Переваги:

• повністю автоматичне управління пам'яттю комп'ютера («збирання сміття»);
• простота повторного використання фрагментів коду;
• розширена підтримка функцій з параметричними аргументами;
• простота верифікації і тестування програм;
• строгість математичної формалізації;
• високий ступінь абстракції, абстрагування від машинного представлення даних;
• прозорість реалізації рекурсивних функцій;
• зручність символьної обробки даних (списки, дерева).

Недоліки:

• складність ефективної реалізації;
• необхідність фундаментальних математичних знань;
• нелінійна структура програми;
• відносно низька ефективність.

Приклади: LISP (Interlisp, Common Lisp, Scheme), SML, Haskell, Prolog, Miranda, Hope.

Логічне програмування (Logic programming)

У 70-х рр. ХХ століття виникла ще одна гілка мов декларативного програмування, пов'язана з проектами у галузі штучного інтелекту – мови логічного програмування. Згідно з логічним підходом до програмування програма є сукупністю правил або логічних висловлювань. Мови логічного програмування базуються на класичній логіці і застосовні для систем логічного висновку, зокрема для так званих експертних систем. На мовах логічного програмування, природно, формалізується логіка поведінки, їх можна застосовувати для описів правил прийняття рішень, наприклад, у системах, орієнтованих на підтримку бізнесу.

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

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

Час появи: 1970 роки.

Стисла характеристика: програма - сукупність правил або логічних висловлювань з причиною і наслідком.

Переваги:

• високий рівень абстракції;
• зручність програмування логіки поведінки;
• зручність застосування для експертних систем;
• механізм відкотів (backtrack).

Недоліки:

• обмежене коло завдань;
• нелінійна структура програми;
• недостатньо ефективна реалізація.

Приклади: Prolog  (назва виникла від слів PROgramming in LOGic) , Mercury.

Об’єктно-орієнтоване програмування (Object-oriented programming)

Усі універсальні мови програмування, незважаючи на відмінності у синтаксисі і використовуваних ключових словах, реалізують одні й ті самі канонічні структури: оператори присвоювання, цикли і розгалуження. У всіх сучасних мовах наявні базові типи даних (цілі і дійсні арифметичні типи, символьний і, можливо, рядковий тип), є можливість використання агрегатів даних, у тому числі масивів і структур (записів). Разом з тим при розробленні програми для розв’язання конкретної прикладної задачі потрібна як можна більша близькість тексту програми до опису завдання. Одним із шляхів вирішення цієї проблеми було створення розширюваної мови, що містить невелике ядро і допускає розширення, доповнює мову типами даних і операторами, відбиває концептуальну сутність конкретного класу задач.

Розвитком цього підходу і стало об’єктно-орієнтоване програмування (ООП) – стиль програмування, що фіксує поведінку реального світу таким способом, при якому деталі його реалізації приховані. У рамках даного підходу програма є описом об'єктів, їх властивостей (або атрибутів), сукупностей (або класів), відносин між ними, способів їх взаємодії та операцій над об'єктами (або методів). Механізм успадкування атрибутів і методів дозволяє будувати похідні поняття на основі базових і таким чином створювати модель як завгодно складної предметної області із заданими властивостями. Ще однією важливою властивістю ООП є підтримка механізму обробки подій, які змінюють атрибути об'єктів і моделюють їх взаємодію у предметній області. Переміщаючись по ієрархії класів від більш загальних понять предметної області до більш конкретних і навпаки, програміст отримує можливість змінювати ступінь абстрактності погляду на модельований ним реальний світ. Об'єкти, класи і методи можуть бути поліморфними, що робить реалізоване програмне забезпечення більш гнучким і універсальним.

Використання раніше розроблених (можливо, іншими колективами програмістів) бібліотек об'єктів і методів дозволяє значно заощадити трудовитрати при виробництві програмного забезпечення, особливо типового. Складність адекватної (несуперечливої і повної) формалізації об'єктної теорії породжує труднощі тестування та верифікації створеного програмного забезпечення. Ця обставина є одним з найбільш істотних недоліків ООП.

Найбільш відомим прикладом об'єктно-орієнтованої мови програмування є мова C++, що виникла з імперативної мови С. Її логічним продовженням є мова С#.

Час появи: 1970 роки.

Стисла  характеристика: програма - опис об'єктів, їх сукупностей, відносин між ними і способів їх взаємодії.

Переваги:

• інтуїтивна близькість до довільної предметної області;
• моделювання як завгодно складних предметних областей;
• подієва орієнтованість;
• високий рівень абстракції;
• повторне використання описів;
• параметризація методів обробки об'єктів.

Недоліки:

• складність тестування та верифікації програм.

Приклади: C ++, Visual Basic, C #, Eiffel, Oberon.

Подієво-кероване програмування (Event-driven programming)

Розвитком об'єктно-орієнтованого підходу став перехід до подієво-керованої концепції у 90-х рр. ХХ століття і виникнення цілого класу мов програмування, які отримали назву мов сценаріїв або скриптів.

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

Час появи: 1990 роки.

Коротка характеристика: програма - сукупність описів можливих сценаріїв обробки даних.

Переваги:

• інтуїтивна зрозумілість;
• близькість до предметної області;
• високий ступінь абстракції;
• можливість повторного використання коду;
• сумісність з інструментальними засобами автоматизованого проектування (CASE) і швидкого розроблення (RAD) прикладного програмного забезпечення.

Недоліки:

• складність тестування та верифікації програм;
• множинні побічні ефекти.

Приклади: VBScript, PowerScript, LotusScript, JavaScript.

Паралельні обчислення (Parallel computing)

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

Час появи: 1980 роки.

Стисла характеристика: програма - сукупність описів процесів, які можуть виконуватися одночасно або псевдопаралельно.

Переваги:

• висока обчислювальна ефективність для великих програмних систем (тисячі одночасно працюючих користувачів або комп'ютерів);
• висока ефективність функціонування в системах реального часу (системи життєзабезпечення та прийняття рішень).

Недоліки:

• висока собівартість розроблення невеликих програм (сотні рядків коду);
• відносно вузький спектр застосування.

Приклади: Ada, Modula-2, Oz.

Компонентне програмування (Component-based programming)

Компонентне програмування – парадигма програмування, що виникла як набір певних обмежень, що накладаються на механізм об'єктно-орієнтованого програмування, коли стало зрозуміло, що безконтрольне застосування ООП приводить до виникнення проблем з надійністю великих програмних комплексів. Компонентне програмування визначає набір правил та обмежень, спрямованих на побудову великих програмних систем, здатних до розвитку впродовж тривалого життєвого циклу. При компонентному програмуванні програмна система складається із окремо створених елементів (компонентів), які викликають один одного через інтерфейси. Зміни в існуючу систему вносяться додаванням нових компонентів або заміною існуючих. При цьому нові компоненти, які заміняють раніше створені, повинні наслідувати інтерфейси базового.

Незважаючи на розвиток теоретичної бази, стадія комплексної автоматизації технологій програмування стала можливою лише при відповідному рівні розвитку техніки. Істотно вплинуло на перехід до комплексної автоматизації усвідомлення того, що не можна розвивати промислове програмування без підтримки технологічних функцій на всіх етапах життя програм. На початку 90-х рр. ХХ ст. з'явилася CASE-технологія (Computer Added Software Engineering – сукупність інструментів та методів програмної інженерії проектування ПЗ для забезпечення високої якості, мінімальної кількості помилок та спрощення проектування), що об’єднувала системи комплексної автоматизації підтримки розроблення і супроводу програм.

1.2                      Життєвий цикл програмного забезпечення

Перехід від ручних засобів розроблення ПЗ до  промислового виробництва програм потребував розвитку теоретичних основ розроблення ПЗ. Постійна необхідність внесення змін у програми як спричинена помилками, так і розвитком вимог до них, є принциповою властивістю програмного забезпечення. Діяльність, пов’язана з рішенням широкого ряду завдань для постійного розвитку, отримала назву супроводу програмного забезпечення. Якщо зусилля, спрямовані на модернізацію ПЗ, перевищуюють вигоду від його використання, говорять про моральне старіння програм. Спочатку з'явилися інструменти підтримки розроблення програмного коду та налагодження програм (60-ті рр. ХХ ст.). Після усвідомлення недостатності таких засобів для істотного підвищення якості програм та створення інструментів керування процесом розроблення виникло поняття життєвого циклу ПЗ.

Поняття ЖЦ виникло під впливом потреби у систематизації робіт у процесі розроблення ПЗ. Систематизація була першим етапом на шляху до автоматизації процесу розроблення ПЗ. Наступними кроками переходу до автоматизації процесу розроблення ПЗ були такі: встановлення технологічних маршрутів діяльності розробників ПЗ, визначення можливості їх автоматизації та виявлення ризиків, розроблення інструментів для автоматизації.

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

Оскільки розроблення та супровід ПЗ фактично є проектною діяльністю, частина ключових понять управління проектів  знайшла широке застосування у програмній інженерії. Таким є і поняття життєвого циклу проекту (Project Lifecycle Management, PLM), що в програмній інженерії трансформувалось у поняття життєвого циклу програмного забезпечення.

Життєвий цикл програмного забезпечення - період часу, що починається з моменту прийняття рішення про необхідність створення програмного продукту і закінчується в момент його повного вилучення з експлуатації [6]. Цей цикл - процес побудови і розвитку ПЗ.

ГОСТ 34.601-90 [7] визначає життєвий цикл автоматизованої системи (АС) як сукупність взаємозв'язаних процесів створення та послідовної зміни стану АС, від формування вхідних вимог до неї до закінчення експлуатації та утилізації комплексу засобів автоматизації.

Як і будь-що модель, модель ЖЦ є абстракцією реального процесу, в якій відсутні деталі, несуттєві з точки зору призначення моделі.

У процесі створення ПЗ можна виділити 4 базових етапи/стадії (рис.2):

• Специфікація – визначення основних вимог.
• Розроблення – створення  ПЗ відповідно до специфікацій.
• Тестування – перевірка ПЗ на відповідність вимогам клієнта.
• Супровід/Модернізація – розвиток ПЗ відповідно до змін потреб замовника.

Рисунок 1.2   — Схема життя програмного забезпечення

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

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

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

Розвиток методологій програмування у 70-х рр. XХ ст. привів до формування потреби вивчення життєвого циклу ПЗ. До цього часу моделі ЖЦ розвиваються і модифікуються, уточнюючи та доповнюючи дві базові моделі – каскадну та ітеративну. Ці зміни обумовлені потребою організаційної та технологічної підтримки проектів з розроблення ПЗ.

 

1.3                      Моделі життєвого циклу ПЗ

1.3.1                      Каскадна модель ЖЦ (Waterfall model)

Каскадна модель ЖЦ ПЗ виникла для задоволення потреби у систематизації робіт ще на ранніх етапах розроблення програм. Згідно з цією моделлю програмні системи проходять в своєму розвитку дві фази:

• розроблення;
• супровід.

Фази розбиваються на ряд етапів (рис. 3).

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

Розроблення починається з ідентифікації потреби в новому додатку, а закінчується передачею продукту розроблення в експлуатацію. Усі етапи розроблення програмного забезпечення регламентуються стандартами підприємства та державним стандартом ГОСТ 34.601-90 [7]. 

Першим етапом фази розроблення є специфікація (Requirements Speсification) – постановка завдання і визначення вимог. На етапі постановки завдання замовник спільно з розробниками приймають рішення про створення системи. Визначення вимог включає опис загального контексту задачі, очікуваних функцій системи та її обмежень. Особливо важливим є цей етап для нетрадиційних додатків. У разі позитивного рішення починається аналіз системи відповідно до вимог. Розробники програмного забезпечення намагаються осмислити висунуті замовником вимоги і зафіксувати їх у вигляді специфікацій системи. Призначення специфікацій – описувати зовнішню поведінку системи, а не її внутрішню організацію. Перш ніж розпочати створювати проект за специфікаціями, вимоги повинні бути ретельно перевірені на відповідність вихідним цілям, повноту, сумісність (несуперечність) та однозначність. Завдання етапу аналізу полягає в тому, щоб вибудувати опис програми у вигляді логічної системи, зрозумілої як для замовника, майбутніх користувачів, так і для виконавців проекту. На етапі специфікації обов’язково формується технічне завдання на розроблення ПЗ [8].

Рисунок 1.3   – Каскадна модель ЖЦ

Розроблення проектних рішень, що відповідають на питання, як повинна бути реалізована система, щоб вона могла задовольняти визначені вимоги, виконується на етапі проектування (Design). Оскільки складність системи в цілому може бути дуже великою, головним завданням цього етапу є послідовна декомпозиція системи до рівня очевидно реалізованих модулів або процедур. Результати виконання цього етапу оформлюютья як технічний проект, вимоги до документів якого встановлені стандартом ГОСТ 34.201-89 [9].

На наступному етапі реалізації (Construction), або кодування, кожен з цих модулів програмується на найбільш підходящій для даного застосування мові. З точки зору автоматизації цей етап традиційно є найбільш розвиненим.

У каскадній моделі фаза розроблення закінчується етапом тестування (Testing and debugging), автономного і комплексного, та передачею системи в експлуатацію (Installation).

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

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

Стисла характеристика:

• фіксований набір стадій;
• кожна стадія закінчується документованим результатом;
• наступна стадія починається лише після закінчення попередньої.

Недоліки:

• негнучкість;
• фаза повинна бути завершена до переходу до наступної;
• набір фаз фіксований;
• важко реагувати на зміни вимог.

Використання: там, де вимоги добре зрозумілі та стабільні.

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

1.3.2                      Ітеративна модель (Iterative model)

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

Класична ітераційна модель абсолютизує можливість повернень на попередні етапи (рис.4). Ця обставина відбиває істотний аспект програмних розробок: прагнення заздалегідь передбачати всі ситуації використання системи та неможливість у переважній більшості випадків досягти цього. Усі традиційні технології програмування спрямовані лише на те, щоб мінімізувати повернення. Але суть від цього не змінюється: при поверненні завжди доводиться повторювати побудову того, що вже вважалося готовим.

Мета кожної ітерації в розробленні ПЗ – отримання працюючої версії програмної системи, що включає функціональність, визначену інтегрованим змістом усіх попередніх і поточної ітерації. Результат фінальної ітерації містить усю необхідну функціональність продукту. Таким чином, із завершенням кожної ітерації продукт розвивається інкрементально (нарощує функціональність).

З точки зору структури життєвого циклу та процесу розроблення така модель є ітеративною (iterative) (рис.5). З точки зору розвитку продукту - інкрементальною (incremental). Досвід індустрії розроблення ПЗ показує, що неможливо розглядати кожен з цих поглядів ізольовано  [10]. Тому цю модель часто називають моделлю ітеративного та інкрементного розроблення (Iterative and incremental development, IID) [11].

Різні варіанти ітераційного підходу реалізовані в більшості сучасних методологій розроблення (RUP, MSF, XP).

Стисла характеристика:

• стадії повторюються неодноразово.

Недоліки:

• система часто погано структурована, проект «не прозорий»;
• після уточнення вимог відкидається частина раніше виконаної роботи;
• потрібні засоби для швидкого розроблення.

Використання: підходить для малих та середніх проектів.

1.3.3                      Еволюційна модель

При використанні еволюційної моделі інформаційна система розробляється у вигляді послідовності блоків структур. На відміну від инкрементної моделі ЖЦ при застосуванні еволюційної моделі вимоги встановлюються поступово із уточненням в кожному наступному блоці структури системи.

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

Розвитком цієї моделі є модель еволюційного прототипування в рамках всього ЖЦ розробки (рис.7). У літературі вона часто називається моделлю швидкої розробки додатків RAD (Rapid Application Development). У даній моделі наведені дії, які пов'язані з аналізом її застосовності для конкретного виду системи, а також обстеження замовника для визначення потреб користувача для розробки плану створення прототипу.

Рисунок 1.6   – Модель еволюційного прототипування

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

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

Ця модель застосовується для систем, в яких найбільш важливими є функціональні можливості, які необхідно швидко продемонструвати на CASE-засобах.

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

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

Стисла  характеристика:

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

Переваги:

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

Недоліки:

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

Використання: підходить для нескладних та некритичних систем із високим вимогами до швидкості реалізації.

1.3.4                      Спіральна модель (Spiral model)

Найбільш відомим і поширеним варіантом ітераційної моделі є спіральна модель (рис.6), що була вперше сформульована Баррі Боемом (Barry Boehm) у 1986 році [12]. Відмінною особливістю цієї моделі є спеціальна увага ризикам, що впливає на організацію життєвого циклу.

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

На кожному витку спіралі виконується створення чергової версії продукту, уточнюються вимоги проекту, визначається його якість і плануються роботи наступного витка. Особлива увага приділяється початковим етапам розроблення – аналізу і проектуванню, де реалізованість тих чи інших технічних рішень перевіряється і обґрунтовується за допомогою створення прототипів (макетування).

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

Спіральна модель розроблення ПЗ вимагає визначення ключових контрольних точок проекту - milestones. Виділяють такі основні контрольні точки [12]:

• Concept of Operations (COO) – концепція використання системи;
• Life Cycle Objectives (LCO) – цілі та зміст життєвого циклу;
• Life Cycle Architecture (LCA) – архітектура життєвого циклу;
• Initial Operational Capability (IOC) – перша версія ПЗ, що перевіряється у ході дослідницької експлуатації;
• Final Operational Capability (FOC) – готове ПЗ, що експлуатується в реальних умовах.

Аналіз у ключових точках особливо актуальний для менеджерів і лідерів проектів, які відстежують хід виконання проекту і планують подальші роботи.

Стисла  характеристика:

• проект має контрольні точки – milestones;
• на кожному витку спіралі створюється прототип На виході – продукт, що  відповідає вимогам користувачів.

Переваги:

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

Недоліки:

• після уточнення вимог відкидається частина раніше виконаної роботи;
• потрібні засоби для швидкого розроблення.

Використання: підходить для великих та середніх проектів, де контроль ризикив забезпечує збереження ресурсів.

 

1.3.5                      V-подібна модель

Наприкінці 1980-х років для вирішення проблеми забезпечення якості результатів ІТ-проектів була запропонована V-подібна модель ЖЦ, ідея якої виникла незалежно у американських  (розроблена Національною радою з системної інженерії) та у німеціких (розроблена аерокосмічною компанією IABG для Міністерства оборони Німеччини) розробників.

У 2005 р. була затверждена актуальна на даний час версія даної моделі -  V-Model XT, яка є державним стандартом Німеччини  для урядових проектів та виробників ПЗ і використовується німецькою федеральною адміністрацією для управління процесом розробки нового програмного забезпечення.

 

 

Стисла  характеристика:

• деталізація проекту зростає із рухом у часі зліва направо по етапах ЖЦ (рис.8).

Переваги:

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

Недоліки:

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

Використання: підходить для середніх та великих проектів.

 

1.3.6                      Адаптивний ЖЦ (Adaptive Life Cycle)

Дана модель ЖЦ ПЗ сфорувалась в практиці проджектменеджменту відповідно до гнучких підходів до розроблення ПЗ. Адаптивний життєвий цикл також називається гнучким або орієнтованим на зміну методом (інші назви: flexible method, change-focused method, agile method, change-driven method) тому, що він розроблений для швидкої реацкції на постійні зміни та вплив різних сторін. У процесі адаптивного життєвого циклу загальний обсяг проекту розбивається на набори вимог, які будуть реалізовуватись  у окремих ітераціях. Під час однієї ітерації функціональні вимоги аналізуються, реалізуються і, нарешті, надаються клієнту на розгляд.

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