Основи програмної ніженерії. Умови виникнення інженерії програмного забезпечення
 Скачать 215.87 Kb.
|
19 Культура інженерії програмного забезпечення. Модель Константіноса.Чотири організаційні парадигми:
20 Культура інженерії програмного забезпечення. Модель де ГракаМодель Де Грака розглядає дві організаційні парадигми, які називаються римським і грецьким шляхами розвитку організацій , Де Грак вказує, що римський шлях характерний для старих, крупних і консервативних організацій, а грецький - для нових, середніх і малих мобільних організацій .
21 Зв’язок культури з організацією,яка розроблює пз.Будь-яка «здорова» культура повинна включати три наступні істотні компоненти: персональне зобов'язання кожного розробника створювати якісні продукти шляхом систематичного застосування передового досвіду інженерії програмного забезпечення; зобов'язання менеджерів всіх рівнів забезпечувати середовище, в якому якість програмного забезпечення (у всіх його аспектах) бути фундаментальною концепцією і кожен розробник може реалізовувати цю концепцію; зобов'язання всіх членів організації постійне удосконалювати процеси, в яких вони беруть участь, і продукти які вони створюють. 22 Життє́вий цикл програ́много забезпе́чення — сукупність окремих етапів робіт, що проводяться у заданому порядку протягом періоду часу, який починається з вирішення питання про розроблення програмного забезпечення і закінчується припиненням використання програмного забезпечення. Поняття життєвого циклу програмного забезпечення відносять до дисципліни «Програмна інженерія». В загальному випадку, життєвий цикл визначається моделлю й описується у формі методології (методу). Модель або парадигма життєвого циклу визначає загальну організацію і, як правило, основні його фази та принципи переходу між ними. Методологія (метод) визначає комплекс робіт, їх детальний зміст і рольову відповідальність спеціалістів на всіх етапах вибраної моделі. Життєвий цикл програмного забезпечення супроводжується розробленням, обігом та використанням програмної документації. Програмна документація — сукупність документів, що містять відомості, необхідні для розробки, виготовлення, супроводу та експлуатації програм. Програмна документація є одним з видів технічної документації. Комплекс державних стандартів, що встановлюють взаємопов'язані правила розробки, оформлення та обігу програм і програмної документації називається «Єдина система програмної документації» (ЄСПД). 23- Домен ПЗ: Дві точки зору 1)З погляду комп'ютерних наук-конструювання комп'ютерних програм – це математичні дії подібні до вирішення, наприклад, диференціальних рівнянь. 2) З точки зору І ПЗ-програмне забезпечення набуває рис конструктивного інженерного домена, а конструювання комп'ютерних програм – стає частиною відповідної індустрії 24. Каскадная модель (она же “водопадная” - waterfall) Итерационные модели Инкрементная модель Спиральная модель Тема 5_Моделі ЖЦ (Moodle) 25. "кодуй і виправляй" code-and-fixu "крокова" stage wise "водоспад" waterfall Тема 5_Моделі ЖЦ (Moodle) 26. Моделі які орієнтовані на розробку "з нуля" Моделі які орієнтовані на використання готових компонентів Моделі орієнтовані на автоматичне виконання фаз життєвого циклу Тема 5_Моделі ЖЦ (Moodle) 27. Здійсненність системи / валідація Планування опису вимог / валідація Архітектурнк проектування / веріфікація Детальне проектування / веріфікація Кодування Тестування модулей Інтеграція веріфікація продукту Реалізація Системне тестування Експлуатація і супроводження / ревалідація Тема 5_Моделі ЖЦ (Moodle) стр 27 28. Тема 5_Моделі ЖЦ (Moodle) стр 62 29. Тема 5_Моделі ЖЦ (Moodle) стр 46 30. Тема 5_Моделі ЖЦ (Moodle) стр 56 31. Тема 5_Моделі ЖЦ (Moodle) стр 54 32. Тема 5_Моделі ЖЦ (Moodle) стр 72 33.Модель швидкої розробки. Швидка розробка застосунків (RAD) - концепція створення засобів розробки застосунків, програмних продуктів, що приділяє особливу увагу швидкості й зручності програмування, створенню технологічного процесу, що дозволяє програмістові максимально швидко створювати комп'ютерні програми. З кінця XX століття RAD одержала широке поширення й схвалення. Концепцію RAD також часто зв'язують із концепцією візуального програмування. Основними принципами RAD, є: Інструментарій має бути націлений на мінімізацію часу розробки. Створення прототипу для уточнення вимог замовника. Циклічність розробки: кожна нова версія продукту ґрунтується на оцінці результату роботи попередньої версії замовником. Мінімізація часу розробки версії, за рахунок перенесення вже готових модулів і додавання функціональності в нову версію. Команда розробників повинна тісно співпрацювати, кожен учасник повинен бути готовий виконувати декілька обов'язків. Управління проектом повинне мінімізувати тривалість циклу розробки. Дана модель містить 4 етапи розробки: планування, користувацьке панування, конструювання, перемикання. 34.V, W – моделі. V-Model є моделлю розробки інформаційних систем, спрямованої на спрощення розуміння складнощів, пов'язаних з розробкою систем. Вона використовується для визначення єдиної процедури розробки програмного забезпечення, апаратного забезпечення та людино-машинного інтерфейсу. Концепція V-подібної моделі була розроблена Німеччиною та США в кінці 1980-х років незалежно один від одного. Сучасною версією V-Model є V-Model XT, яка була затверджена в лютому 2005 року. Основний принцип V-подібної моделі полягає в тому, що деталізація проекту зростає при русі зліва направо, одночасно з плином часу, і ні те, ні інше не може повернути назад. Ітерації в проекті виробляються по горизонталі, між лівою і правою сторонами літери. Стосовно до розробки інформаційних систем V-Model — варіація каскадної моделі, в якій завдання розробки йдуть зверху вниз по лівій стороні букви V, а завдання тестування — вгору по правій стороні букви V. Усередині V проводяться горизонтальні лінії, що показують, як результати кожної з фаз розробки впливають на розвиток системи тестування на кожній із фаз тестування. Модель базується на тому, що приймально-здавальні випробування ґрунтуються, насамперед, на вимогах, системне тестування — на вимогах та архітектури, комплексне тестування — на вимогах, архітектурі та інтерфейсах, а компонентне тестування — на вимогах, архітектурі, інтерфейсах та алгоритмах. Модель W складається з двох V-подібних моделей, які являють собою процес тестування та розробки відповідно. Тут тестовим об'єктом є не лише програма. Вимоги та дизайн також повинні бути протестовані, а тестування та розробка йдуть пліч-о-пліч. Це сприяє ранньому виявленню проблем. Наприклад, після завершення аналізу вимог після тестування ми можемо якнайшвидше знайти необґрунтовані або неправильні вимоги, а також можемо протестувати. прогрес проекту. 35.Моделі з повторним використанням. Однією з характерних ознак інженерної діяльності є використання готових рішень або деталей. Однак промислове використання готових рішень у програмній інженерії ще не стало повсякденною практикою. Приблизно 80% програмістів працюють над створенням програм обліку й організаційного управління на кількох рівнях: окремого підрозділу фірми, окремого аспекту діяльності фірми, фірми в цілому, корпорації, галузі і, нарешті, держави. Це, переважно, задачі розрахунків, статистики, допомоги у прийнятті рішень при управлінні різноманітними ресурсами - кадровими, фінансовими тощо. За оцінками експертів, 75% таких робіт дублюють одна одну: на тисячах підприємств створюються програми складського обліку, нарахування зарплати, розрахунку витрат на виробництво продукції, складання маршрутів деталей на виробничому конвеєрі тощо. Хоч більшість із цих програм типові, але кожного разу знаходяться особливості, що не дозволяють застосувати розроблену раніше програму. Тому нині активно розвивається напрямок водночас і науковий, і інженерний, який названо повторним використанням або компонентним розробленням програм. Компонентне розроблення - це метод побудови ПЗ як композицій готових компонент з конструкцій за каталогом. Повторне використання - це використання для нових розроблень будь-яких фрагментів інформації, здобутих у процесі розроблення інших інформаційних систем. Повторно використовувані компоненти - елементи знань про минулий досвід розроблення систем програмування, які можна використовувати для створення нових інформаційних систем без участі їх розробників. 36.Огляд процесів стандарт IEEE 1074. Стандарт IEEE 1074 охоплює повний життєвий цикл ПС, де виділяються шість великих базових процесів. Ці процеси деталізуються 16 приватними процесами. В останніх є ще дрібніша деталізація в сукупності на 65 процесів-робіт. Зміст кожного приватного процесу починається з опису загальних його функцій та завдань та переліку дій - робіт при подальшій деталізації. Для кожного процесу в стандарті представлені вхідна та результуюча інформація про його виконання та короткий опис сутності процесу. Увага зосереджена переважно на безпосередньому створенні ПС та на процесах попереднього проектування. У додатку представлено чотири варіанти адаптації максимального складу компонентів життєвого циклу програмного забезпечення до конкретних особливостей типових проектів. 37.Rational Unified Process як приклад стандартного процесу. Rational Unified Process (RUP) є ітеративним процесом розробки програмного забезпечення створеним Rational Software — підрозділом IBM з 2003. RUP не є єдиним, конкретним розпорядчим процесом, а скоріше фреймворком процесу, що має бути адаптованим організаціями які займаються розробкою та командами розробників які оберуть елементи процесу, які підходять під їх потреби. RUP визначає життєвий цикл проекту, що складається з чотирьох фаз. |