Презентація на тему:
Основи програмної інженерії

Основи програмної інженерії 2003-2009 Основи програмної інженерії

Зміст Поняття програмної інженерії. SWEBOK – простір знань програмної інженерії Моделювання у програмній інженерії Життєвий цикл ПС. Моделі життєвого циклу ПС Ітеративно-інкрементні моделі життєвого циклу Керування ризиками Поняття програмної архітектури Основи програмної інженерії

Поняття програмної інженерії Термін програмна інженерія (Software Engineering) почав вживатись з 1968 року, що засвідчило перехід до розробки програмного забезпечення (ПЗ) чи програмних систем (ПС) на інженерній основі. Програмна інженерія вивчає питання, пов'язані з розробкою та використанням ПЗ на інженерній основі (систематичність, дисциплінованість, можливість деталізації), охоплюючи всі етапи життєвого циклу; узагальнює дослідження й досвід у вигляді комплексів знань та правил, що регламентують діяльність по створенню ПС. ____________________________________________________________ Naur, P. Randell, B, Software Engineering: Report on a conference sponsored by the NATO Science Committee, Garmisch, Germany, 7th to 11th October 1968, Naur, P., Randell, B., eds., 1969. Інженерний підхід + знання Основи програмної інженерії

SWEBOK – простір знань програмної інженерії SWEBOK - Software Engineering Body of Knowledge (Last Version 2007) - Проект IEEE Computer Society www.swebok.org WHAT IS SOFTWARE ENGINEERING? The IEEE Computer Society defines software engineering as “ (1) The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software. (2) The study of approaches as in (1).” The Body of Knowledge is subdivided into ten software engineering Knowledge Areas (KA) plus an additional chapter providing an overview of the KAs of strongly related disciplines. Institute of Electrical and Electronics Engineers - IEEE (read eye-triple-e) is an international non-profit, professional organization for the advancement of technology Основи програмної інженерії

SWEBOK – простір знань програмної інженерії www.swebok.org Основи програмної інженерії

Wikipedia - the free encyclopedia that anyone can edit Основи програмної інженерії

Википедия - свободная энциклопедия, которую может редактировать каждый Основи програмної інженерії

The SWEBOK Knowledge Areas (KAs) Software requirements Software design Software construction Software testing Software maintenance Software configuration management Software engineering management Software engineering process Software engineering tools and methods Software quality Основи програмної інженерії

Related disciplines Computer engineering Computer science Management Mathematics Project management Quality management Software ergonomics Systems engineering Основи програмної інженерії

Guide to the SWEBOK Основи програмної інженерії

Приклад Knowledge Area - Software design Основи програмної інженерії

Architectural styles (macroarchitectural patterns) An architectural style is “a set of constraints on an architecture [that] defines a set or family of architectures that satisfies them” [Bas03:c2]. An architectural style can thus be seen as a meta-model which can provide software’s high-level organization (its macroarchitecture). Various authors have identified a number of major architectural styles. [Bas03:c5; Boo99:c28; Bos00:c6; Bus96:c1,c6; Pfl01:c5] General structure (for example, layers, pipes, and filters, blackboard) Distributed systems (for example, client-server, three-tiers, broker) Interactive systems (for example, Model-View-Controller, Presentation-Abstraction-Control) Adaptable systems (for example, micro-kernel, reflection) Others (for example, batch, interpreters, process control, rule-based). Основи програмної інженерії

Design Patterns (microarchitectural patterns) Succinctly described, a pattern is “a common solution to a common problem in a given context.” (Jac99) While architectural styles can be viewed as patterns describing the high-level organization of software (their macroarchitecture), other design patterns can be used to describe details at a lower, more local level (their microarchitecture). [Bas98:c13; Boo99:c28; Bus96:c1; Mar02:DP] Creational patterns (for example, builder, factory, prototype, and singleton) Structural patterns (for example, adapter, bridge, composite, decorator, façade, flyweight, and proxy) Behavioral patterns (for example, command, inter-preter, iterator, mediator, memento, observer, state, strategy, template, visitor) Основи програмної інженерії

Моделювання у програмній інженерії Існує багато аспектів, пов'язаних з успішною розробкою програмних проектів, і одним з головних є моделювання. І не випадково, загалом, моделювання – загальноприйнята в інженерії методика. Модель – це спрощене представлення дійсності, але важливо, щоб модель M надавала певну уяву про об’єкт моделювання A: "M моделює A, якщо M дозволяє відповідати на запитання відносно A". Чим більша й складніша система, тим важче її "охопити" у цілому, а, отже, тим важливіше моделювання. Розвиток засобів CASE (Computer Aided Software Engineering), що підтримують моделювання ПС. Моделі програмних систем; архітектури ПС; життєвого циклу. Основи програмної інженерії

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

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

Життєвий цикл ПС Неоднорідність (та повторюваність із проекту в проект) робіт, виконуваних при розробці ПС, залежність цих робіт одна від одної, нарешті, колективний характер їх виконання — ось підстави для поетапної організації розвитку ПС, а отже, виділення окремих етапів у життєвому циклі (ЖЦ) ПС. Термін життєвий цикл ПС є фактично запозиченим із традиційних галузей промислового виробництва, де давно використовується поняття життєвого циклу матеріального продукту (не даремно фермери віддають перевагу більш дорогим канадським комбайнам). Життєвий цикл — це проекція поняття користувача “час життя” на поняття розробника “технологічний цикл (цикл розробки)”. Саме комбінацією цих понять пояснюється походження самого терміну “життєвий цикл”. Розвиток концепцій життєвого циклу пов'язаний з пошуком адекватних моделей для нього. Багатогранність призначень моделювання визначає різноманітність моделей. Основи програмної інженерії

Моделі життєвого циклу ПС Найчастіше виділяють наступні п'ять основних етапів ЖЦ: аналіз і формалізація вимог замовника; проектування; реалізація й тестування; упровадження; супровід. Іноді виділяють як етапи: аналіз вимог, проектування, кодування (програмування), тестування й налагодження, експлуатація й супровід. Часто можна зустріти виділену окремим етапом інтеграцію. Головна особливість індустрії ПЗ складається в концентрації уваги на початкових етапах ЖЦ (аналіз, проектування): невирішені питання й помилки, допущені на етапах аналізу й проектування, породжують на наступних етапах важкі, часто нерозв'язні проблеми і, у кінцевому рахунку, призводять до невдачі всього проекту. Основи програмної інженерії

Модель послідовного типу (каскадна, водоспад) Основи програмної інженерії

Модель послідовного типу (каскадна, водоспад) Основи програмної інженерії

Абстрактна схема ЖЦ Microsoft Solution Framework Основи програмної інженерії

Застосування послідовної моделі. Вимоги до ПС Послідовна модель може застосовуватись, коли: вимоги до продукту (1) чітко визначені; (2) надалі не змінюються; є досить великий досвід реалізації подібного роду систем. Реалізація проекту за даним типом моделі ЖЦ легко планується й контролюється. Про вимоги до програмних систем: (1) Теза-жарт: “Замовник щось хоче, але точно не знає, що саме він хоче”. (2) У житті є лише три речі, які людині не підвладні: неминучість смерті; необхідність сплачувати податки; змінюваність вимог до ПС. Основи програмної інженерії

Реалії розробки більшості ПС Основи програмної інженерії

Реалії розробки більшості ПС (каскадна модель) Основи програмної інженерії

Модифікована каскадна модель За рахунок жорсткості перевірок можна позбавитись прямих відкатів на кілька етапів. Основи програмної інженерії

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

Модель Гантера “фази — функції” Надзвичайно важливим мотивом розвитку моделей життєвого циклу програмного забезпечення є потреба в придатному засобі для керування проектом (зокрема, для підтримки функцій менеджера). Для цього використовується накладення на модель не тільки контрольних точок (вони задають організаційно-часові рамки проекту), але і так званих виробничих функцій, виконуваних протягом розвитку проекту. Найбільше послідовно таке доповнення класичної схеми реалізовано в моделі Гантера (1981) у вигляді двох вимірів (ще кажуть матриці) “фази - функції”: фазовий вимір, що відображає етапи виконання проекту і супутні їм події; функціональний вимір, що показує, які виробничі функції виконуються в ході розвитку проекту та яка їх інтенсивність на кожному з етапів. Основи програмної інженерії

Фазовий вимір моделі “фази – функції” Основи програмної інженерії

Функціональний вимір моделі “фази – функції” Перелік (варіантний!) функцій: Планування Розробка Обслуговування Випуск документації Випробування Підтримка використання робочих продуктів Супровід (для зовнішнього використання продуктів) Конкретний зміст того, що повинно виконуватись на кожному з етапів в межах обраної функції (діяльності), можна уявляти виходячи з назв контрольних точок. Поняття інтенсивності функції є принципово невіддільним від стратегії, прийнятої для кожної функції й у кожному специфічному випадку ведення проекту. (Як варіанти можливого розрахунку інтенсивності можна вказати на трудовитрати на виконання функції, питомі трудовитрати, трудовитрати з урахуванням кваліфікаційних вимог, кадрових потреб тощо. Можна, нарешті, використовувати різні показники одночасно). Основи програмної інженерії

Модель Гантера “фази — функції” Основи програмної інженерії

“Розробляйте ітеративно!”- одна з порад Г.Буча Урахування змінюваності вимог. (Зміни, “повзучість”, “дрейф” вимог є першоджерелами невдач проектів, оскільки призводять до порушень планів, запізнень і навіть повного “провалу” проектів.) Використання зворотного зв’язку з користувачами та замовниками з метою виявлення справжніх вимог. Неперервна інтеграція, а не “вибух” проблем інтеграції як при “водоспаді”. Загалом, компоненти ПС насправді інтегруються поступово, отже, тут просто доцільно використовувати ітераційний підхід. Пом’якшення наслідків від реалізації ризиків. Основи програмної інженерії

“Розробляйте ітеративно!”- одна з порад Г.Буча Можливість розробникам накопичувати досвід, навчатись. Сприяння виробленню стійкої архітектури (слабкі місця виявляються вже на ранніх ітераціях). Можливість тактичних маневрів (випуск версії з обмеженими функціональними можливостями, але значно раніше – захоплення ринку). Сприяння більш ранньому виявленню суперечливості вимог, проекту та реалізації. Неперервне ітеративне тестування дозволяє більш ефективно і точно оцінювати поточний стан розробки Основи програмної інженерії

Перехід до ітеративних (ітеративно-інкрементних) моделей ЖЦ Ілюстрація проста, але з'являються нові питання: Як визначати, що саме має реалізовуватись у кожній з ітерацій? Як гарантувати цілеспрямованість та, зокрема, завершуваність процесу створення ПС? Основи програмної інженерії

До проблеми ризиків інтеграції Основи програмної інженерії

Ітеративна модель ЖЦ Основи програмної інженерії

Ітеративна модель ЖЦ Основи програмної інженерії

Ітеративна модель ЖЦ Основи програмної інженерії

Моделі еволюційного типу. Інкрементність та ітераційність моделей ЖЦ (“спіраль охоплення предметної області” ) Основи програмної інженерії

Інструментальна спіраль Боема Основи програмної інженерії

“Модифікована” модель фази-функції Основи програмної інженерії

Технологічні аспекти у моделях ЖЦ (можливість одночасного виконання різних ітерацій) Основи програмної інженерії

Технологічні аспекти у моделях ЖЦ (можливість одно-часного виконання різних ітерацій). Спіраль розвитку Основи програмної інженерії

Застосування еволюційних моделей Даний тип моделей ЖЦ може застосовуватись у випадках, коли: вимоги до системи не цілком визначені або будуть змінюватися (“повзучість” вимог); відсутній достатній досвід розробки подібних систем; використовуються нові технології та/або інструментарії; у ході розробки ПС необхідно отримувати й використовувати її проміжні версії. Процес розробки, що є одночасно ітераційним та інкрементним, часто пов'язують із поняттям процесу, керованому ризиками (risk-driven), коли в кожній новій версії серйозна увага приділяється, по-перше, виявленню факторів, що представляють найбільший ризик для успішного завершення проекту, і, по-друге, зведенню ризиків до мінімуму. Основи програмної інженерії

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

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

Два виміри процесу розробки ПС із позицій Rational Unified Process Основи програмної інженерії

Динамічний аспект RUP. Чотири стадії (фази), чотири віхи RUP Перша фаза – фаза задуму (або початку) – завершується віхою “Вимоги життєвого циклу”. (Віха LCO – lifecycle objective). Друга фаза – фаза уточнення завершується віхою “Архітектура життєвого циклу”. (Віха LCA – lifecycle architecture). Третя фаза – фаза конструювання (або реалізації) завершується віхою “Початкова працездатність”. (Віха IOC – initial operational capabiliny). Четверта фаза – фаза переходу (або передачі, розгортання) завершується віхою “Випуск продукту”. (Віха PR – product release). Основи програмної інженерії

Два виміри процесу розробки ПС із позицій Rational Unified Process Основи програмної інженерії

Два виміри процесу розробки ПС із позицій Rational Unified Process Основи програмної інженерії

Підтримка потоків робіт CASE-засобами IBM Rational Software Основи програмної інженерії

Програмна архітектура (ПА) Архітектура – мистецький характер будівлі. Усі розуміють важливість ПА (архітектуру має будь-яка ПС, не залежно від того, чи розроблялась архітектура цілеспрямовано, чи ні!), та не завжди акцентують на неї увагу. Причини: мета ПА не завжди піддається чіткому формулюванню; концепція ПА не завжди чітка (це десь між керуванням вимогами та поняттям системи); не існує загального способу представлення ПА; не описано процес розробки ПА ("чорна магія"). Разом із тим, відсутність ПА чи неякісна ПА є основним технічним ризиком програмних проектів. Основи програмної інженерії

Поняття програмної архітектури Припустимо, треба описати систему таким чином, щоб зацікавлені особи (розробники, програмісти, користувачі, замовники) змогли б: зрозуміти, що робить система; зрозуміти, як працює система; попрацювати з частиною системи, зокрема, використати повторно; розширити систему. Якщо все це займає не більше 60 сторінок, то це і є опис ПА. Грубо – відповідний опис (ПА) робить систему зрозумілою (зрозуміло що і як вона робить). Іноді з опису вилучають частини. Архітектура – це коли вилучити більше нічого не можна, щоб система лишалася зрозумілою. Модель – не архітектура (моделі складних систем можуть бути дуже великими). Основи програмної інженерії

Термінологія ПА Більшість означень ПА ґрунтуються на поняттях: статична структура ПС (елементи ПС та відношення між ними); динамічна структура ПС (відношення, що представляють динамічні аспекти); композиція чи декомпозиція ПС (підсистеми, модулі); компоненти та їх взаємодія; рівні та їх взаємодія; організація фізичного розгортання елементів ПС; деякі обмеження на ПС (оточення, мова програмування, тип СУБД тощо); стиль, що визначає розробку та розвиток ПС; функціональні можливості ПС; інші аспекти (повторне використання, продуктивність, масштабованість); Основи програмної інженерії

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

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

Представлення архітектури. Що дає архітектура? Наведені різні означення ПА відображають складність та багатовимірність поняття ПА. Зрозуміло, що для різних зацікавлених сторін важливими є різні аспекти ПА. Як наслідок, використовуються різні представлення однієї й тієї ж ПА. Архітектура: спрощує розуміння ПС; дозволяє отримати повний інтелектуальний контроль на всіх етапах ЖЦ ПС, забезпечуючи гнучкість та адаптивність ПС, спрощуючи розробку та супровід; надає ефективну основу широкомасштабного повторного використання; надає можливість управління проектом (наприклад, організувати планування, кадрове забезпечення – за рівнями, підсистемами). Основи програмної інженерії

Модель архітектури “4+1” Представлення системи з точки зору проектування (структурні відношення, функціональність, словник) кінцевий користувач Представлення системи з точки зору процесів (продук-тивність, масштабування, про-пускна спроможність) системний інтегратор Представлення системи з точки зору розгортання (топологія системи) системний адміністратор Логічна складова Фізична складова Динамічна складова Статична складова Представлення системи з точки зору реалізації (складання, відношення між компонентами) програміст Представлення систе-ми з точки зору преце-дентів (функціональні можливості) Основи програмної інженерії

Модель архітектури “4+1” Основи програмної інженерії

Основні особливості (базові концепції) Rational Unified Process (RUP) Промені цієї зірки представляють основні ідеї, закладені у RUP Основи програмної інженерії