І О Ушакова - Основи системного аналізу об'єктів і процесів комп'ютеризації - страница 10

Страницы:
1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17  18  19  20  21  22  23  24  25  26  27  28  29  30  31  32  33  34  35  36  37  38  39  40  41  42  43  44 

Недоліки моделі RAD:

якщо користувачі не можуть постійно брати участі в процесі розробки впродовж всього життєвого циклу, це може негативно позначитися на кін­цевому продукті;

використання моделі може виявитися невдалим у випадку, якщо від­сутні придатні для повторного використання компоненти;

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

Сфера застосування моделі RAD:

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

у системах, вимоги для яких достатньою мірою добре відомі;

у випадках, коли кінцевий користувач може брати участь у процесі розробки впродовж усього життєвого циклу;

коли команді, що працює над проектом, знайома предметна область;

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

коли можна отримати придатні до повторного використання частини програмних продуктів;

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

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

в інформаційних системах.9.3.6. Інкрементна (покрокова) модель

 

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

Інкрементна модель реалізується таким чином (рис. 22).

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

Другий крок. Вибирається перша група вимог і виконується повний прохід по каскадній моделі. Після того, як перший варіант системи, що виконує першу групу вимог, зданий замовнику, розробники переходять до наступного кроку (другого інкременту) з розробки варіанта, який виконує другу групу вимог, і т. д.

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

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

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

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

Переваги інкрементної моделі:

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

внаслідок виконання кожного інкременту виходить готовий продукт;

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

наприкінці постачання кожного інкременту існує можливість пере­глянути ризики, пов'язані з витратами і дотриманням встановленого графіка;

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

замовники можуть розпізнавати найважливіші й найкорисніші функціональні можливості продукту на більш ранніх етапах розробки;

ризик розподіляється на декілька менших за розміром інкрементів і не зосереджений в одному великому проекті розробки;

вимоги стабілізуються (за допомогою включення в процес користувачів) на момент створення певного інкременту, оскільки вимоги, що не є особливо важливими, відкладають до моменту створення наступних інкрементів;

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

Недоліки інкрементної моделі:

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

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

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

Сфера застосування інкрементної моделі:

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

якщо ринкове вікно надто вузьке і є потреба в швидкому постачанні на ринок продукту, що має функціональні базові властивості;

для проектів, на виконання яких передбачений великий період часу розробки, як правило, один рік;

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

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

коли однопрохідна розробка системи пов'язана з великим ступенем ризику.

 

9.3.7. Спіральна модель

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

помилки розробників, допущені на ранніх стадіях і виявлені на пізніших стадіях: помилки аналізу вимог, проектування, кодування, що виявляються, як правило, на стадії тестування;

помилки замовників, що викликають зміну вимог у процесі розробки.

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

аналіз ризиків, управління ними, а також процеси підтримки й управління;

розробка програмного продукту під час використання методу прототипування або швидкої розробки додатків за допомогою застосування мов програмування і розвинених засобів розробки.

Спіральна модель життєвого циклу ПЗ реалізується таким чином (рис. 23):

розробка варіантів продукту подається як набір циклів спіралі, що розкручується;

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

У кожному циклі моделі виділяються чотири базові фази:

визначення цілей, альтернативних варіантів і обмежень;

оцінка альтернативних варіантів, ідентифікація і вирішення ризиків;

розробка продукту наступного рівня;

планування наступної фази.

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

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

Другий цикл - аналіз вимог. Починається з планування вимог і деталей ЖЦ продукту для оцінки витрат. На фазі визначення цілей встановлюються альтернативні варіанти вимог, пов'язані з ранжуванням вимог за важливістю й вартістю їх виконання. На фазі оцінки встановлюються   ризики   варіантів   вимог.   На   фазі   розробки -специфікація вимог (із зазначенням ризиків і демоверсія ПЗ для аналізу вимог замовником.


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

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

Основні принципи спіральної моделі можна сформулювати таким чином:

розробка варіантів продукту, відповідних різним варіантам вимог, з можливістю повернутися до попередніх варіантів;

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

планування наступних варіантів з оцінкою альтернатив і аналізом ризиків, пов'язаних з переходом до наступного варіанта;

перехід до розробки наступного варіанта до завершення попереднього у разі, коли ризик завершення чергового варіанта (прототипу) стає невиправдано високим;

використання каскадної моделі як схеми розробки чергового ва­ріанта;

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

Переваги спіральної моделі:

спіральна модель дозволяє користувачеві побачити систему на ранніх етапах за рахунок швидкого прототипування;

забезпечується визначення нездоланних ризиків без додаткових витрат;

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

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

реалізовані переваги інкрементної моделі, а саме випуск інкрементів, скорочення графіка за допомогою перекривання інкрементів, розсортованих за версіями, і незмінність ресурсів при поступовому зростанні системи;

зворотний зв'язок у напрямі від користувачів до розробників виконується з високою частотою і на ранніх етапах моделі, що забезпечує створення потрібного продукту високої якості;

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

підвищується продуктивність завдяки використанню придатних для повторного використання властивостей;

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

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

можна виконувати часту оцінку сукупних витрат, а зменшення ризиків пов'язане з витратами.

Недоліки спіральної моделі:

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

складність структури моделі, що може ускладнити її застосування розробниками, менеджерами й замовниками;

складність підтримки версій продукту (зберігання версій, повернення до ранніх версій, комбінація версій, документування версій);

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

Сфера застосування спіральної моделі:

коли користувачі не впевнені у своїх потребах;

коли вимоги надто складні й можуть змінюватися в процесі виконання проекту і необхідне прототипування для аналізу та оцінки вимог;

у процесі розробки нової функції або нової серії продуктів;коли досягнення успіху не гарантоване і необхідна оцінка ризику продовження проекту;

коли проект є складним, дорогим і обґрунтування його фінансування можливе лише в процесі його виконання;

коли мова йде про застосування нових технологій, що пов'язане з ризиком їх освоєння і досягнення очікуваного результату;

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

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

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

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

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

9.4. Моделі життєвого циклу програмного продукту на основі

індустріальних технологій

9.4.1. Важкі та гнучкі технології' проектування

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

Індустріальні технології створення програмного продукту можна розділити на два види:

із важкими процесами розробки;

із гнучкими (agile) процесами розробки.

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

Страницы:
1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17  18  19  20  21  22  23  24  25  26  27  28  29  30  31  32  33  34  35  36  37  38  39  40  41  42  43  44 


Похожие статьи

І О Ушакова - Соціальні мережі як засіб впливу на взаємовідносини з клієнтами

І О Ушакова - Основи системного аналізу об'єктів і процесів комп'ютеризації

І О Ушакова - Практикум з навчальної дисципліни основи системного аналізу об'єктів і процесів комп'ютеризації

І О Ушакова - Робоча програма навчальної дисципліни Проектування інформаційних систем

І О Ушакова - Робоча програма навчальної дисципліни системний аналіз для студентів напряму підготовки 6 050101 комп'ютерні науки