Технологія розробки програмного забезпечення

Технологія розробки програмного  забезпечення

 

1. Технології, моделі і процеси створення ПЗ.

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

Інженерія ПЗ - інженерна дисципліна, яка охоплює всі аспекти розробки ПЗ.

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

Процес  створення ПЗ - сукупність процесів, які приводять до створенню програмного продукту.

Фундаментальні  процеси, властиві будь-якому проекту  створення ПЗ:

• Розробка специфікації вимог на ПЗ (визначають функціональні характеристики системи і обов'язкові для виконання).
• Створення програмного забезпечення (створення ПЗ згідно специфікації).
• Атестація ПЗ (створене ПЗ повинно пройти атестацію для підтвердження відповідності вимогам замовника).
• Модернізація ПЗ (вдосконалення ПЗ згідно зміненим вимогам споживача).

Модель  процесу створення ПЗ - послідовність етапів необхідних для розробки створюваного ПЗ.

Моделі  процесу розробки ПЗ:

1. Каскадна модель
2. Еволюційна модель
3. Формальне перетворення
4. Збірка програмних продуктів з раніше створених компонентів (модель збірки)
5. Ітераційна (спіральна) модель

Методи  створення ПЗ є структурним підходом до створення ПЗ, який сприяє виробництву ПЗ ефективним, з економічної точки зору, способом.

Всі методи базуються на використанні моделей системи у якості специфікації її структури:

1. Функціонально-орієнтовані (структурний аналіз, JSD, 70-і роки) базуються на визначенні основних функціональних компонент системи.

2. Об'єктно-орієнтовані (Booch, Rumbaugh) використовують підходи, які базуються на використанні уніфікованої мови моделювання UML.

Computer-aided Software Engineering – автоматизована розробка ПЗ.

Процеси створення ПЗ

Базові  процеси створення ПЗ:

• Розробка специфікації.
• Проектування і реалізація.
• Атестація.
• Еволюція.

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

Достоїнства:

• Документування кожного етапу.

Недоліки:

• «Негнучке» розбиття процесу створення на окремі етапи.

Застосування:

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

 

 

2. Основи створення ПЗ

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

Результат процесу визначення вимог – документація, яка формалізує вимоги, що пред'являються до системи.

Два рівні деталізації:

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

Реалізація  ПЗ - процес переведення системної специфікації у працездатну систему. Включає процеси проектування і програмування.

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

Результат кожного етапу проектування - специфікація, потрібна для виконання наступного етапу.

Методи  проектування – сукупність формалізованих нотацій і нормативних документів для проектування ПЗ.

Структурні  методи підтримують моделі системи:

• Модель потоків даних;
• Модель «сутність-зв'язок»;
• Структурна модель;
• Об'єктно-орієнтована ієрархічна модель системи, модель відношень між об'єктами, модель взаємодії об'єктів;
• Діаграми переходів або сценарії життя сутностей.

Програмування і налагодження:

Тестування  - процес встановлення програмних помилок.

Налагодження  - встановлення місцеположення помилок і їх усунення.

Атестація і верифікація - процес встановлення відповідності ПЗ його специфікації, а також очікуванням і вимогам користувачів і замовника.

 

3. Розробка вимог до ПЗ

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

Розрізняють чотири основні етапи процесу  розробки вимог:

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

Процес  формування і аналізу вимог проходить  через низку етапів:

• Аналіз предметної області. Аналітики повинні вивчити предметну область, де експлуатуватиметься система.
• Збір вимог. Це процес взаємодії з особами, які формують вимоги. Під час цього процесу продовжується аналіз предметної області.
• Класифікація вимог. На цьому етапі безформний набір вимог перетвориться в логічно зв'язані групи вимог.
• Вирішення протиріч. Без сумніву, вимоги численних осіб, зайнятих у процесі формування вимог, будуть суперечливими. На цьому етапі визначаються і вирішуються суперечності такого роду.
• Призначення пріоритетів. У будь-якому наборі вимог одні з них будуть важливіші, ніж інші. На цьому етапі спільно з особами, які формують вимоги, визначаються найбільш важливі вимоги.
• Перевірка вимог. На цьому етапі визначається їх повнота, послідовність і несуперечність.

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

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

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

Метод опорних точок зору

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

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

Різні методи пропонують різні трактування виразу "точка зору". Точки зору можна трактувати таким чином:

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

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

Цей тип точок зору має низку переваг:

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

 

4. Реалізація ПЗ

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

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

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

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

Етапи, спільні для всіх процесів архітектурного проектування:

1. Структурування системи. Програмна система структурується у вигляді сукупності відносно незалежних підсистем. Також визначаються взаємодії між підсистемами.
2. Моделювання управління. Розробляється базова модель управління взаємовідносинами між частинами системи.
3. Модульна декомпозиція. Кожна визначена на першому етапі підсистема розбивається на окремі модулі. Тут визначаються типи модулів і типи їх взаємозв'язків.

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

Зазвичай, розробляється чотири архітектурні моделі:

1. Статична структурна модель, в якій представлені підсистеми або компоненти, які розробляються надалі незалежно.
2. Динамічна модель процесів, в якій представлена організація процесів під час роботи системи.
3. Інтерфейсна модель визначає сервіси, які надаються кожною підсистемою через спільний інтерфейс.
4. Моделі відношень, в яких показані взаємовідношення між частинами системи, наприклад потік даних між підсистемами.

Моделі  архітектури можуть залежати від нефункціональних системних вимог:

1. Продуктивність. Якщо критичною вимогою є продуктивність системи, слід розробити таку архітектуру, щоб за всі критичні операції відповідало як можна менше підсистем з максимально малою взаємодією між ними. Щоб зменшити взаємодію між компонентами, краще використовувати компоненти у вигляді великих модулів, а не дрібні структурні елементи.
2. Захищеність. У цьому випадку архітектура повинна мати багаторівневу структуру, в якій найбільш критичні системні елементи захищені на внутрішніх рівнях, а перевірка безпеки цих рівнів здійснюється на більш високому рівні.
3. Безпека. У цьому випадку архітектуру потрібно спроектувати так, щоб за всі операції, які впливають на безпеку системи, відповідали якомога менше підсистем. Такий підхід дозволяє понизити вартість розробки і вирішує проблему перевірки надійності.
4. Надійність. У цьому випадку потрібно розробити архітектуру з включенням надмірних компонентів, щоб можна було замінювати і оновлювати їх, не перериваючи роботу системи.
5. Зручність супроводу. У цьому випадку архітектуру системи потрібно проектувати на рівні дрібних структурних компонентів, які можна легко змінювати. Програми, які створюють дані, повинні бути відокремлені від програм, які використовують ці дані. Потрібно також уникати структури сумісного використання даних.