Лекція 01
Проектування ПЗ процес створення проекту програмного забезпечення (ПЗ)
Ціль Проектування ПЗ
визначення внутрішніх властивостей системи й деталізації її зовнішніх( видимих) властивостей на основі виданих замовником вимог до ПЗ (вихідні умови завдання). Ці вимоги піддаються аналізу
Спочатку програма розглядається як чорний ящик. Хід процесу проектування і його результатів залежать не тільки від складу вимог, але й обраної моделі процесу, досвіду проектувальника
Модель предметної області накладає обмеження на бізнес-логіку й структури даних.
Залежно від класу створюваного ПЗ, процес проектування може забезпечуватися як "ручним" проектуванням, так і різними засобами його автоматизації. У процесі проектування ПЗ для вираження його характеристик використаються різні нотації - блок-схеми, ER-діаграми, UML-діаграми, DFD-діаграми, а також макети
Проектуванню підлягають
Архітектура ПЗ
Пристрій компонентів ПЗ
Користувальницькі інтерфейси
Проектування ПЗ
процес визначення архітектури, компонентів, інтерфейсів й інших характеристик системи або її компонентів
Дизайн
результат процесу проектування.
Розглянуте як процес, проектування є інженерною діяльністю у рамках життєвого циклу програмного забезпечення, у якій належним чином аналізуються вимоги для створення опису внутрішньої структури ПЗ, що є основою для конструювання програмного забезпечення як такого
Програмний дизайн (як результат діяльності проектування ПЗ) описує архітектуру програмного забезпечення, тобто представляє декомпозицію програмної системи у вигляді організованої структури компонент й інтерфейсів між компонентами. Найважливішою характеристикою готовності дизайну є той рівень деталізації компонентів, що дозволяє зайнятися їх конструюванням. Терміни дизайн й архітектура можуть використатися взаємозамінним чином, але частіше говорять про дизайн як про цілісний погляд на архітектуру системи
Проектування відіграє важливу роль у процесах життєвого циклу створення програмного забезпечення (Software Development Lіfe Cycle).
Види дизайну ПЗ
D-дизайн
decomposіtіon desіgn
декомпозиція структури програмного забезпечення у вигляді набору фрагментів або компонент
FP-дизайн
famіly pattern desіgn
сімейство архітектурних подань, що базуються на шаблонах
І-дизайн іnventіon
створення высоко-уровневой концепції, бачення того, що із себе буде представляти програмна система:; даний вид дизайну є результатом процесу аналізу вимог й їх трансформації в підходи до реалізації
Область знань ПЗ
Область знань проектування ПЗ подана у вигляді 6 секцій, структурованих по темах
Проектування ПЗ
в розумінні програмної інженерії має на увазі D- і FP-дизайн.
Проектування програмних систем
Архітектурний або високорівневий дизайн
software archіtectural desіgn, top-level desіgn
опис високорівневої структури і організації компонентів системи
Деталізована архітектура
software detaіled desіgn
описує кожний компонент у том обсязі, у якому необхідно для конструювання
Життєвий цикл ПЗ
період часу, що починається з моменту ухвалення рішення про необхідність створення програмного продукту й закінчується в момент його повного вилучення з експлуатації
Структура життєвого циклу
містить процеси, дії й завдання, які повинні бути виконані під час створення ПЗ.
Основні процеси життєвого циклу ПЗ
Придбання
дії й завдання замовника, що здобуває ПЗ
Поставка
дії й завдання постачальника, що постачає замовника програмним продуктом або послугою
Розробка
дії й завдання, виконувані розроблювачем: створення ПЗ, оформлення проектної й експлуатаційної документації, підготовка тестових і навчальних матеріалів і т.д.
Експлуатація
дії й завдання оператора - організації, що експлуатує систему
Супровід
дії та завдання, виконувані супровідною організацією, тобто службою супроводу
Супровід - внесень змін у ПЗ з метою виправлення помилок, підвищення продуктивності або адаптації до умов, що змінилися, роботи або вимогам
Допоміжні процеси життєвого циклу ПЗ
Документування
формалізований опис інформації, створеної протягом ЖЦ ПЗ
Керування конфігурацією
застосування адміністративних і технічних процедур на всьому протязі ЖЦ ПЗ для визначення стану компонентів ПЗ, керування його модифікаціями
Забезпечення якості
забезпечення гарантій того, що інформаційної системи (ІС) і процеси її ЖЦ відповідають заданим вимогам і затвердженим планам
Верифікація
визначення того, що програмні продукти, що є результатами деякої дії, повністю задовольняють вимогам або умовам, обумовленим попередніми діями
Атестація
визначення повноти відповідності заданих вимог і створеної системи їх конкретному функціональному призначенню
Спільна оцінка
оцінка стану робіт із проекту: контроль планування й керування ресурсами, персоналом, апаратурами, інструментальними засобами
Аудит визначення відповідності вимогам, планам й умовам договору
Вирішення проблем
аналіз і вирішення проблем, незалежно від їх походження або джерела, які виявлені в ході розробки, експлуатації, супроводу або інших процесів
Організаційні процеси життєвого циклу ПЗ
Керування
дії й завдання, які можуть виконуватися будь-якою стороною, що керує своїми процесами
Створення інфраструктури
вибір і супровід технології, стандартів й інструментальних засобів, вибір й установка апаратних і програмних засобів, використовуваних для розробки, експлуатації або супроводу ПЗ
Удосконалення
оцінка, вимір, контроль й удосконалення процесів ЖЦ
Навчання
первісне навчання й наступне постійне підвищення кваліфікації персоналу
Моделі життєвого циклу ПЗ
Модель водоспаду
(касакадна модель)
Водоспадна модель життєвого циклу (англ. waterfall model) була запропонована в 1970 р. Уінстоном Ройсом. Вона передбачає послідовне виконання всіх етапів проекту в строго фіксованому порядку. Перехід на наступний етап означає повне завершення робіт на попередньому етапі. Вимоги, певні на стадії формування вимог, строго документуються у вигляді технічного завдання і фіксуються на увесь час розробки проекту. Кожна стадія завершується випуском повного комплекту документації, достатньої для того, щоб розробка могла бути продовжена іншою командою розроблювачів.
Етапи проекту
Формування вимог
Проектування
Реалізація
Тестування
Впровадження
Експлуатація й супровід
Водоспадна схема включає кілька важливих операцій, застосовних до всіх проектів
Складання плану дій ПЗ при розробці системи
Планування робіт, пов'язаних з кожною дією
Застосування операції відстеження ходу виконання дій з контрольними етапами
Переваги
Повна й погоджена документація на кожному етапі
Легко визначити строки й витрати на проект
Недоліки
У водоспадній моделі перехід від однієї фази проекту до іншої припускає повну коректність результату (виходу) попередньої фази
На думку сучасних фахівців, основна помилка авторів водоспадної моделі складається в припущеннях, що проект проходить через весь процес один раз, спроектована архітектура гарна й проста у використанні, реалізація проекту розумна, а помилки в реалізації легко усуваються в ході тестування.
Ця модель виходить із того, що всі помилки будуть зосереджені в реалізації, а тому їх усунення відбуватисеться рівномірно під час тестування компонентів і системи.
Специфіка таких систем полягає в тому, що вимоги характеризуються високою динамікою коректування й уточнення, неможливістю чіткого й однозначного визначення вимог до початку робіт з реалізації (особливо, для нових систем) і швидкою мінливістю в процесі експлуатації системи
Крім того, ця модель не здатна гарантувати необхідну швидкість відгуку й внесення відповідних змін у відповідь на швидко мінливі потреби користувачів, для яких програмна система є одним з інструментів виконання бізнесів-функцій.
Водоспадна модель для великих проектів мало реалістична й може бути ефективно використана тільки для створення невеликих систем
Ітераційна модель
Ітераційна модель
припускає розбивку життєвого циклу проекту на послідовність ітерацій, кожна з яких нагадує "міні-проект", включаючи всі фази життєвого циклу в застосуванні до створення менших фрагментів функціональності, у порівнянні із проектом, у цілому
Ціль кожної ітерації
одержання працюючої версії програмної системи, що включає функціональність, певну інтегрованим змістом всіх попередні й поточні ітерації
Результати фінальної ітерації містять всю необхідну функціональність продукту
Таким чином, із завершенням кожної ітерації, продукт розвивається інкрементально
Еволюційна модель
З погляду структури життєвого циклу таку модель називають ітеративною (іteratіve). З погляду розвитку продукту - інкрементальною (іncremental). Досвід індустрії показує, що неможливо розглядати кожний із цих поглядів ізольовано. Тому таку змішану модель іще називають
має на увазі не тільки зборку працюючої (з погляду результатів тестування) версії системи, але і її розгортання в реальних операційних умовах з аналізом відгуків користувачів для визначення змісту й планування наступної ітерації.
"Чиста" інкрементальна модель не припускає розгортання проміжних зборок (релізів) системи і всі ітерації проводяться по заздалегідь визначеному плану нарощування функціональності, а користувачі (замовник) одержують лише результат фінальної ітерації, як повну версію системи.
Таким чином, значимість еволюційного підходу на основі організації ітерацій особливо проявляється в зниженні невизначеності із завершенням кожної ітерації. У свою чергу, зниження невизначеності дозволяє зменшити ризики.
Рисунок ілюструє деякі ідеї еволюційного підходу, припускаючи, що ітеративній розбивці може бути підданий не лише життєвий цикл у цілому, що включає фази, що перекриваються (формування вимог, проектування, конструювання й т.п.), але й кожна фаза може, у свою чергу, розбиватися на уточнюючі ітерації, зв'язані, наприклад, з деталізацією структури декомпозиції проекту - наприклад, архітектури модулів системи.
Найбільш відомим і розповсюдженим варіантом еволюційної моделі є спіральна модель, що стала вже по-суті самостійною моделлю, що має різні сценарії розвитку й деталізації
Спіральна модель
Вимоги до ПЗ
Розробка вимог до ПЗ
процес виявлення, формулювання, аналізу, документування й верифікації вимог, що підлягають виконанню в продукті
У його ході системний аналітик формує реєстр вимог, що лягає в документ або автоматизовану систему керування вимогами.
Вимоги до програмного забезпечення
сукупність тверджень щодо атрибутів, властивостей або якостей програмної системи, що підлягає реалізації. Створюються в процесі розробки вимог до програмного забезпечення, у результаті аналізу вимог
Вимоги можуть виражатися у вигляді текстових тверджень і графічних моделей.
У класичному технічному підході сукупність вимог використається на стадії проектування ПЗ.
Етапу розробки вимог, можливо, передувало техніко-економічне обґрунтування, або концептуальна фаза аналізу проекту
Фаза розробки вимог
Види вимог до ПО
Модулі та Інтерфейси
Модуль
функціонально закінчений фрагмент програми, оформлений у вигляді окремого файлу з вихідним кодом або пойменованої безперервної його частини, призначений для використання в інших програмах
Модулі дозволяють розбивати складні завдання на більше дрібні відповідно до принципу модульности. Зазвичай проектуються таким чином, щоб надавати зручну для багаторазового використання функціональність (інтерфейс) у вигляді набору функцій, класів, констант.
Модулі можуть поєднуватися в пакети й, далі, у бібліотеки.
Модулі можуть бути звичайними, тобто написаними на тій же мові, що й основна програма, у якій вони використовуються, або модулями розширення, які пишуться на іншій мові. Модулі розширення пишуться на більш низкорівневій мові, що дозволяє одержати виграш у швидкості виконання (продуктивності) програми.
Модульність
принцип, відповідно до якого програмний засіб (ПЗ, програма, бібліотека, web-додаток й ін.) розділяється на окремі іменовані сутності, що називаються модулями. Модульність часто є засобом спрощення завдання проектування ПЗ і розподілу процесу розробки ПЗ між групами розроблювачів. При розбивці ПЗ на модулі для кожного модуля вказується реалізована їм функціональність, а також зв'язок з іншими модулями.
Роль модулів можуть грати структури даних, бібліотеки функцій, класи, сервіси й ін. програмні одиниці, що реалізують деяку функціональність і надають інтерфейс до неї.
Програмний інтерфейс
функціональність, яку деякий програмний компонент надає іншим програмним компонентам
Інтерфейс програмування додатків - АРІ
mykolash@gmail.com
093-833-89-14