7.Модель спіралі
Модель спіралі запропонував Boem в 1998.
Модель містить в собі чотири первинні циклічні етапи:
аналіз
розробка
оцінювання
планування
Малюнок 2.8.1 Модель спіралі.
На першому етапі формулюються основні складові елементи нової системи. Вони аналізуються, з врахуванням ризику. Проблеми аналізу складових елементів обговорюються на наступному кроці стратегічного етапу проекту. Етап також може передбачати прототипування.
На другому етапі створюється версія системи, грунтуючись на каскадній моделі. На етапі оцінювання версію оцінює клієнт. Якщо оцінка не задовільна, починається новий цикл.
На етапі планування формулюються головні цілі виробництва.
Детальніше модель спіралі можна розглянути на мал. 2.8.2.
Мал.2.8.2.
III. Етапи розробки програмного забезпечення
Етап - це період між основними пунктами в процесі, в якому формуються добре описані завдання, презентуються готові робочі продукти і приймаються рішення про перехід на наступний етап. На малюнку нижче показані всі етапи в методі RUP.
Малюнок 3.2.1. Життєві цикли ПЗ RUP.
1. Стратегічний етап
Мета стратегічного етапу полягає в тому, щоб описати проект з точки зору клієнта. Всі цілі можуть здаватися іноді очевидними. Проте, спроба визначити їх зазвичай дозволяє уникати можливого непорозуміння між клієнтом і виробником. Крім того, навіть якщо цілі ясні для всіх людей, залучених до стратегічного етапу, вони не будуть очевидні для людей, які працюють на подальших стадіях і людям, які не мають прямого контакту з клієнтом. Метою проекту повинен бути докладний опис вимог на випадок, якщо виникають будь-які сумніви в подальших етапах.
Наступне завдання, яке виконується на стратегічному етапі полягає в тому, щоб описати можливості проекту. Зазвичай розвинена система підтримуватиме певні аспекти діяльності клієнта. Відповідний опис можливостей необхідний для хоршої вартісної оцінки проекту. Проте, клієнт не знає можливостей проекту на даному етапі. Може бути незрозумілим, які функції будуть здійснені в ПЗ і які функції будуть здійснені користувачами, іншими системами і апаратними засобами.
Визначення можливостей проекту призводить до контекстного опису, тобто до опису зовнішніх систем, з якими взаємодіяла б система. У багатьох випадках система використовується одним або декількома користувачами. Цих користувачів розглядають як зовнішню систему.
Визначення мети, можливостей і контексту проекту недостатньо для вартісної оцінки виробництва і складних систем. Точна оцінка можлива тільки якщо всі етапи, такі як формулювання вимог, аналіз і проектування, були виконані. Практично фінансові ресурси доступні в стратегічному етапі, обмежені, тому рекомендується робити тільки загальну оцінку. Важливо враховувати всі можливості описаної системи.
Стратегічний етап називають також етапом проектування. Він виконується перш, ніж ухвалені остаточні рішення. У випадку компанії, яка виробляє ПЗ для клієнта, це етап ведення переговорів про продукт з клієнтом. У випадку, коли компанія розробляє ПЗ для ринку, це - етап обговорення і планування продукту.
Стратегічний етап також називають техніко-економічним вивченням. На цьому етапі виконуються наступні дії:
обговорення проекту з представниками клієнта
визначення мети проекту з точки зору клієнта
визначення можливостей і контексту проекту
приблизне формулювання вимог, аналіз і проект системи
формулювання альтернативних рішень
аналіз
представлення результатів представникам клієнта і здійснення виправлень
попереднє планування і вибір структури команди
стандартні визначення
У випадку розробки системи ПЗ для клієнта ми повинні розрізняти людину-замовника і людей, які використовуватимуть і застосовуватимуть систему. В загальному наш проект повинен відповідати вимогам замовників, так як продукт буде оцінюватися ними. Дуже часто вони не є користувачами системи.
На цьому етапі існує декілька стратегічних рішень, які повинні бути прийняті:
вибір моделі проекту
вибір методів, що будуть використовуютися для аналізу і проектування
вибір програмного середовища
вибір CASE-інструментів
рішення про використання наборів інструментів
рішення про можливу співпрацю
Як правило, існують декілька можливих рішень по системі і ці варіанти рішень підпорядковані певним обмеженням. Обмеження можуть стосуватись:
максимальна допустима вартість
доступні професіонали і персонал
доступні інструменти
обмеження в часі
На стратегічному етапі виконується попереднє планування ( визначаються підзадачі і оцінюється час, необхідний для їх виконання). Тому деталі проекту ще не визначені і графік роботи є дуже загальним.
На стратегічному етапі повинні бути визначені стандарти. Вони включають:
використання інструментів і понять
методи документування
Оцінка рішення може бути заснована на таких критеріях, як вартість, затрати часу на проект, надійність, повторне використання компонентів системи, мобільності і спосіб виконання.
До ключових чинників успіху на стратегічному етапі належить:
Ефективність роботи ( особливо для компаній, що працюють на конкретного клієнта на ринку конкуруючих компаній, будь-які затримки можуть призвести до низьких шансів на нові замовлення).
Незалежно від системи, що розробляється, компанія не може витратити значні кошти на стратегічному етапі ( таким чином, етап повинен бути організований невеликою групою людей і в короткі терміни).
Нерозуміння ключових моментів клієнтом ( цей чинник робить успіх проекту неможливим).
Осмислення всієї системи ( більшість невдач, викликані в результаті приділення дуже великої уваги деяким фрагментам системи, тобто відсутнє розуміння частин, які можуть бути найважчими в розробці).
До основних результатів стратегічного етапу відносять:
складання звіту, який охоплює
визначення мети
опис можливостей
опис зовнішніх систем
опис загальних вимог
загальна модель системи
запропоноване рішення по системі
вартісна оцінка
попереднє планування
звіт про відносну оцінку рішення, що містить інформацію про всі можливі рішення і обгрунтування ухвалених рішень
представлення необхідних ресурсів - штату, апаратних засобів, програмного забезпечення і т.д.
стандартні визначення
планування аналізу
Етап визначення вимог
Мета цього етапу полягає в тому, щоб описати детально вимоги клієнта. На цьому етапі ми описуємо всі вимоги, які ведуть до досягнення мети. Ми повинні мати на увазі, що клієнт може не зрозуміти їх технічної точки зору. Таким чином формулювання вимог - процес комунікації з клієнтом, в якому клієнт і розробник встановлюють ряд відповідних вимог.
У компанії, що створює ПЗ для клієнта, аналітики мають прямий контакт з представниками клієнта. Постійне обговорення з представниками клієнта, які в більшості випадків є користувачами системи, призводять до формулювання всіх деталей вимог. Рекомендується, щоб одна людина з боку клієнта була відповідальна за комунікацію представників клієнта з аналітиками.
Труднощі на цьому етапі виникають з наступних причин:
клієнт не знає, як цілі можуть бути досягнуті ( існує багато способів досягнення цілей)
великі системи використовуються багатьма користувачами. Можуть бути протиріччя в підходах до їх використання. Різні користувачі можуть володіти різною термінологію
люди, що організовують замовлення і користувачі – це різні люди. Думка замовників може бути критичною на цьому етапі, але вони, можливо, не враховують деяких потреб користувачів.
Вимоги клієнта можна описати на різних абстрактних рівнях:
визначення вимог ( загальний опис, який проводиться після обговорення деталей з представниками клієнта)
специфікація вимог. Опис, який використовує структуровану і природню мову і вводить деякі прості формальні примітки
специфікація ПЗ - завершений формальний опис вимог
Опис вимог повинен:
бути повним і послідовним;
описувати, як поводиться система, як вона організована;
розглядати будь-які обмеження системи;
бути легким у розвитку;
брати до уваги можливі майбутні зміни;
описувати виключення.
Основна помилка на цьому етапі полягає в зосередженості на типових ситуаціях і нехтування виключеннями. І користувачі, і аналітики мають таку схильність.
Вимоги до ПЗ можуть бути розділені на два типи:
Функціональні вимоги. Вони описують функції (операції, дії), що виконуються системою;
Нефункціональні вимоги. Вони описують обмеження функціональності.
Вимоги повинні міститися в відповідному документі, який повинен містити в собі наступні розділи:
вступ - цілі, можливості і контекст системи. Ця частина містить результати стратегічного етапу
опис розвитку системи - опис можливих змін
опис функціональних вимог
опис атрофованих вимог
модель системи
словник
Крім того цей документ може містити додаткову інформацію:
специфікація функціональних вимог
специфікація нефункціональних вимог
вимоги до устаткування
вимоги до баз даних
індекс
плани тестування
2.1. Функціональні вимоги
Функціональні вимоги описують функції, що виконуються системою. Вони можуть включати в себе вимоги дозовнішніх систем.
Часто для опису вимог використовується неспеціалізована мова, при цьому виникають деякі незручності:
двозначність неспеціалізованої мови, робить опис важким до сприйняття і може призвести до різного його розуміння людьми
гнучкість неспеціалізованої мови, яка дозволяє виражати той же самий вміст в різних формах. Це може призвести до упущення суперечливих вимог, сформульованих в різноманітних формах одних і тих самих функцій.
Формальна примітка може усунути двозначність, але при цьому може виявитись важкою для сприйняття клієнтом. Таким чином, формальна примітка може тільки підсумовувати неспеціалізований опис.
Зазвичай функціональні вимоги подаються у формі очікуваного результату, а не у формі алгоритму. Цей опис є декларативним, але в деяких специфічних випадках необхідним є і викладення алгоритму.
Функціональні вимоги сформульовані, щоб визначити зовнішні зв'язки. Функції системи повинні бути відомі користувачам і іншим взаємодіючим системам. Під функціями системи ми не повинні розуміти тільки функції програми.
Методика декомпозиції функцій передбачає, що найзагальніші функціональні вимоги формулюються і поділяються по назві функцій.
Практично клієнти не завжди розуміють або цікавляться загальними функціональними можливостями системи і обговорюють специфічні функції, які потім об’єднані аналітиком системи. Таку методику називають знизу-вверх.
Більшість розробників використовує обидва методи. Аналітик системи повинен розглянути спочатку загальні функції, а потім інформацію, зібрану у користувачів. Таким чином розділення і об’єднання опису застосовується в процесі формулювання вимог.