💙💛 Класика💙💛 Зарубіжна література💙💛 Дитячі книги💙💛 Сучасна проза💙💛 Фантастика💙💛 Детективи💙💛 Поезія💙💛 Наука, Освіта💙💛 Бойовики💙💛 Публіцистика💙💛 Шкільні підручники💙💛 Фентезі💙💛 Блог💙💛 Любовні романи💙💛 Пригодницькі книги💙💛 Біографії💙💛 Драматургія💙💛 Бізнес-книги💙💛 Еротика💙💛 Романтична еротика💙💛 Легке чтиво💙💛 Бойовик💙💛 Бойове фентезі💙💛 Детектив💙💛 Гумор💙💛 Езотерика💙💛 Саморозвиток, Самовдосконалення💙💛 Психологія💙💛 Дім, Сім'я💙💛 Еротичне фентезі💙💛 Жіночий роман💙💛 Сучасний любовний роман💙💛 Любовна фантастика💙💛 Історичний роман💙💛 Короткий любовний роман💙💛 Детектив/Трилер💙💛 Підліткова проза💙💛 Історичний любовний роман💙💛 Молодіжна проза💙💛 Бойова фантастика💙💛 Любовні романи💙💛 Любовне фентезі💙💛 Інше💙💛 Містика/Жахи💙💛 Різне
всі жанри
Свіжі відгуки
Гість Тетяна
9 листопада 2024 18:08
Інтригуючий детектив. Дуже сподобалася книга
Червона Офелія - Лариса Підгірна
Олена
31 жовтня 2024 19:00
Cучасне українське любовне фентезі - обожнюю 👍 дякую авторці
Неідеальна потраплянка - Ліра Куміра
Таміла
29 вересня 2024 17:14
Любовна фантастика - це топ!
Моя всупереч - Алекса Адлер
Василь
23 вересня 2024 12:17
Батько наш Бандера, Україна Мати…
...коли один скаже: Слава Україні! - Степан Бандера
Сайт україномовних книжок » 💙💛 Інше » Вступ до інженерії програмного забезпечення - Микола Олександрович Сидоров

Вступ до інженерії програмного забезпечення - Микола Олександрович Сидоров

Читаємо онлайн Вступ до інженерії програмного забезпечення - Микола Олександрович Сидоров
залежності визначає лінія регресії. 5.3.2. Засоби емпіричної інженерії програмного забезпечений

Для реалізації емпіричних методів в інженерії програмного за­безпечення створюються спеціальні середовища - Computer Aided Empirical Software Engineering (CAESE) (рис. 5.10). Як видно, CAESE забезпечує вивчення проблем, пов'язаних з програмним за­безпеченням на основі емпіричних даних, отриманих шляхом про­ведення експериментів.

Рис. 5.10 Структура САЕSЕ

5.4. Взаємозв'язок інженерій

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

Рис. 5.11. Обіг програмного забезпечення

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

Розділ 6. ЖИТТЄВИЙ ЦИКЛ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ. МОДЕЛЮВАННЯ

Стандарт ISO/ІЕС 12207:1995 визначає модель життєвого циклу як схему, що відображає процеси, дії і завдання, які залучаються до розробки, експлуатації і супроводу програмного продукту, почи­наючи з визначення вимог і закінчуючи зняттям з експлуатації.

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

Першими моделями життєвого циклу були такі: «кодуй і вип­равляй (code-and-fix); «крокова» (stage wise); «водоспад» (waterfall).

6.1. Базові моделі

Модель «кодуй і виправляй» містила дві фази (рис. 6.1):

— написання коду;

- встановлення помилок у коді.

Недоліки моделі: після безлічі змін код ставав погано структурований; навіть добре спроектоване програмне забезпечення не відповідало вимогам; супровід коду був дорогим, оскільки код по­гано пристосований для тестування і модифікації.

Рис. 6.1. Модель «кодуй і виправляй»

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

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

Рис. 6.2. Крокова модель

- зворотні зв'язки між стадіями (тим самим зменшувалася переробка програмних продуктів окремих стадій);

- прототипування як спосіб розробки програмного забезпечення двічі;

- введені фази проектування;

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

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

Рис. 6.3. Каскадна модель

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

6.2. Типи моделей життєвого циклу

Натепер моделі життєвого циклу можна поділити на три групи. Основою моделей усіх груп є каскадна модель.

Першу групу утворюють «послідовні» моделі - модифікації каскад­ної моделі орієнтування на розробку «з нуля». До цієї групи входять:

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

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

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

6.2.1. Моделі, орієнтовані на розробку «з нуля»

Класична модель водоспаду - це узагальнення моделі водоспаду Райса, Модель містить п'ять фаз і, зазвичай, використовується в теоретичних побудовах (рис. 6.4).

Рис. 6.4. Класична модель водоспаду

Спіральна модель запропонована Боемом, як уточнення моделі водоспаду в результаті виконання ряду проектів, Процес розробки пред­ставлений у вигляді спіралі. Кожен виток спіралі - фаза (рис. 6.5).

Рис. 6.5. Спіральна модель

Спіраль розташована в чотирьох квадратах. У кожному квадраті виконуються певні дії: 

- квадрат 1 - визначаються цілі альтернативи і обмеження - визна­чення вимог і специфікація для критичних частин системи з погляду продуктивності, функціональних властивостей, здібності до акомодації змін, програмного/апаратного інтерфейсу, критичних чинників успіху;

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

- квадрат 3 — розробляється продукт;

- квадрат 4 - планується така фаза: застосування Інформації, що належить до фази розробки продукту на наступному рівні, до планування на наступному кроці фази проекту.

Таким чином, у відповідному квадраті відбуваються такі дії:

Відгуки про книгу Вступ до інженерії програмного забезпечення - Микола Олександрович Сидоров (0)
Ваше ім'я:
Ваш E-Mail: