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

Страницы:
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 

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

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

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

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

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

системного й приймального тестування, в ході якого виконується перевірка функціонування програмної системи в цілому (повністю інтегрованої системи) після розміщення її в апаратному середовищі відповідно до специфікації вимог до ПЗ;

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

Переваги V-подібної моделі:

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

визначення вимог виконується перед розробкою проекту системи, а

проектування ПЗ - перед розробкою компонентів;

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

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

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

Недоліки V-подібної моделі:

труднощі під час роботи з паралельними подіями;

не враховані ітерації між фазами;

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

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

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

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

 

9.3.4. Модель швидкого прототипування

 

У 1975 р. Фред Брукс (Fred Brooks) у своїй книзі "Легендарна людина-місяць" ("The Mythical Man-Month") написав: "У більшості проектів перша побудована система навряд чи придатна до використання. Вона може бути занадто повільною, надто об'ємною,незручною у використанні або мати всі три перераховані недоліки. Але немає іншого вибору, окрім як почати із самого початку, доклавши всіх зусиль, і побудувати модернізовану версію, в якій розв'язувалися б усі три проблеми...". Саме ця концепція побудови експериментальної, або прототипної системи привела до виникнення "структурної", "еволюційної" моделі швидкого прототипування (RAD) і спіральної моделі.

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

Модель швидкого прототипування (рис. 20) призначена для швидкого створення прототипів продукту з метою уточнення вимог і поетапного розвитку прототипів у кінцевий продукт. Швидкість (висока продуктивність) виконання проекту забезпечується плануванням розробки прототипів і участю замовника в процесі розробки.

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

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

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

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

Переваги моделі швидкого прототипування:

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

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

у процес розробки можна внести нові або неочікувані вимоги користувача;

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

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

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

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

завдяки меншому обсягу доробок зменшуються витрати на розробку;

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

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

документація сконцентрована на кінцевому продукті, а не на його розробці.

Недоліки моделі швидкого прототипування:

швидко створені прототипи страждають від неадекватної документації або її браку;

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

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

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

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

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

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

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

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

Сфера застосування структурної еволюційної моделі швидкого про-тотипування:

вимоги невідомі заздалегідь;

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

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

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

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

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

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

алгоритми або системні інтерфейси ускладнені;

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

Швидке прототипування особливо добре підходить для розробки інтенсивно використовуваних систем призначеного для користувача інтерфейсу, таких як інтерактивні системи, нові у своєму роді продукти, а також системи забезпечення ухвалення рішень, наприклад, управління, медична діагностика.9.3.5. Модель швидкої розробки ПЗ (RAD)

Метод швидкої розробки додатків (Rapid Application Development, RAD) був використаний у 80-х роках XX століття фірмою IBM. Цей метод був уперше запропонований до уваги розробників ПЗ у книзі Джеймса Мартіна. Завдяки методу RAD користувач задіяний на всіх фазах життєвого циклу розробки проекту не лише під час визначення вимог, але й у процесі проектування, розробки, тестування, а також кінцевого постачання програмного продукту. Участь користувача в процесі розробки стає такою активною завдяки використанню засобів розробки та середовища, що дозволяє дати оцінку продукту на всіх стадіях його розробки. Це забезпечується наявністю засобів розробки графічного, призначеного для користувача інтерфейсу і кодогенераторів.

Характерною рисою RAD є короткий час переходу від визначення вимог до створення цілісної системи. Метод ґрунтується на послідовній ітерації еволюційної системи або прототипів, критичний аналіз яких обговорюється із замовником. У процесі такого аналізу формуються вимоги до продукту. Розробка кожного інтегрованого продукту обмежується чітко окресленим періодом часу, який, як правило, становить 60 днів і називається часовим блоком.

Чинники, що дозволяють створити систему за 60 днів без шкоди для якості, включають:

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

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

осмислені й виділені ресурси.

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

Фази моделі ЖЦ RAD і участь користувача на всіх фазах процесу проектування наведені на рис. 21:

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

призначений для користувача опис - спільне проектування додатка (Joint application design, JAD) використовується з метою залучення користувачів; на цій фазі проектування системи, яка не є промисловою, команда, яка працює над проектом, часто використовуєінструментальні засоби, що забезпечують збирання призначеної для користувача інформації;

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

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

 

 

 

 

 

Користувач"

 

 

\

\

/


\


 

\


 

 

 

\КонструюванняПланування вимог

Призначений для користувача опис

 

Переведення на нову систему

експлуатаціїЧас

Рис. 21. Модель швидкої розробки додатків

 

Переваги моделі RAD:

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

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

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

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

основна увага переноситься з документації на код, при цьому справедливий принцип "отримуєте те, що бачите" (What you see is what you get, WYSIWYG);

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

Страницы:
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 комп'ютерні науки