III. Етапи розробки програмного забезпечення

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

Малюнок 3.2.1. Життєві цикли ПЗ RUP.

Стратегічний етап

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

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

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

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

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

Стратегічний етап також називають техніко-економічним вивченням. На цьому етапі виконуються наступні дії:

· обговорення проекту з представниками клієнта

· визначення мети проекту з точки зору клієнта

· визначення можливостей і контексту проекту

· приблизне формулювання вимог, аналіз і проект системи

· формулювання альтернативних рішень

· аналіз

· представлення результатів представникам клієнта і здійснення виправлень

· попереднє планування і вибір структури команди

· стандартні визначення

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

На цьому етапі існує декілька стратегічних рішень, які повинні бути прийняті:

· вибір моделі проекту

· вибір методів, що будуть використовуютися для аналізу і проектування

· вибір програмного середовища

· вибір CASE-інструментів

· рішення про використання наборів інструментів

· рішення про можливу співпрацю

Як правило, існують декілька можливих рішень по системі і ці варіанти рішень підпорядковані певним обмеженням. Обмеження можуть стосуватись:

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

· доступні професіонали і персонал

· доступні інструменти

· обмеження в часі

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

На стратегічному етапі повинні бути визначені стандарти. Вони включають:

· використання інструментів і понять

· методи документування

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

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

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

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

· Нерозуміння ключових моментів клієнтом (цей чинник робить успіх проекту неможливим).

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

До основних результатів стратегічного етапу відносять:

· складання звіту, який охоплює

o визначення мети

o опис можливостей

o опис зовнішніх систем

o опис загальних вимог

o загальна модель системи

o запропоноване рішення по системі

o вартісна оцінка

o попереднє планування

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

· представлення необхідних ресурсів - штату, апаратних засобів, програмного забезпечення і т.д.

· стандартні визначення

· планування аналізу

2. Етап визначення вимог

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

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

Труднощі на цьому етапі виникають з наступних причин:

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

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

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

Вимоги клієнта можна описати на різних абстрактних рівнях:

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

· специфікація вимог. Опис, який використовує структуровану і природню мову і вводить деякі прості формальні примітки

· специфікація ПЗ - завершений формальний опис вимог

Опис вимог повинен:

· бути повним і послідовним;

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

· розглядати будь-які обмеження системи;

· бути легким у розвитку;

· брати до уваги можливі майбутні зміни;

· описувати виключення.

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

Вимоги до ПЗ можуть бути розділені на два типи:

· Функціональні вимоги. Вони описують функції (операції, дії), що виконуються системою;

· Нефункціональні вимоги. Вони описують обмеження функціональності.

Вимоги повинні міститися в відповідному документі, який повинен містити в собі наступні розділи:

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

· опис розвитку системи - опис можливих змін

· опис функціональних вимог

· опис атрофованих вимог

· модель системи

· словник

Крім того цей документ може містити додаткову інформацію:

· специфікація функціональних вимог

· специфікація нефункціональних вимог

· вимоги до устаткування

· вимоги до баз даних

· індекс

· плани тестування

2.1. Функціональні вимоги

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

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

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

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

Формальна примітка може усунути двозначність, але при цьому може виявитись важкою для сприйняття клієнтом. Таким чином, формальна примітка може тільки підсумовувати неспеціалізований опис.

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

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

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

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

Більшість розробників використовує обидва методи. Аналітик системи повинен розглянути спочатку загальні функції, а потім інформацію, зібрану у користувачів. Таким чином розділення і об’єднання опису застосовується в процесі формулювання вимог.

Нефункціональні вимоги

Нефункціональні вимоги описують обмеження, в яких виконуються функції. Вимоги можуть бути поділені на:

· вимоги продукту, наприклад "можуть використовуватися тільки клавіатура і миша "

· вимоги процесу, наприклад "система повинна виконувати за стандартом XXA/2002"

· зовнішні вимоги, наприклад "система повинна працювати з базою даних, описаною в документі YYYB/2001, і ніякі зміни в базі даних недопустимі"

Ці вимоги повинні бути зрозумілими, тобто повинен бути метод перевірки виконання умов. Такі вимоги як: "зручний", "надійний", "ефективний" не можуть бути перевірені, отже, вони не відповідають формулюванню.

Для успішного формулювання функціональних вимог необхідно:

· постійна співпраця з відповідними представниками клієнта

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

· перевірка завершеності і послідовності вимог

· невеликий опис нефункціональних вимог

Аналіз

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

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

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

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

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

Чинники успіху при аналізі є:

· залучення професіоналів;

· підтримка необхідних стандартів, наприклад, в примітці;

· правильність і перевірка концепції;

· прозорість, логічність і послідовність документації;

· глобальне розуміння системи без деталізації особливостей.

За результатами аналізу отримують:

· покращений документ по вимогам;

· словник даних;

· документ, що описує створену модель:

o діаграми класу

o діаграма випадків використання

o діаграма дій

o діаграми станів

o звіт, що описує визначення класів, ознак, відносин, методів і т.д.;

· графік етапу проектування;

· попереднє призначення людей і команд.

Етап проектування

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

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

На цьому етапі виконується перетворення абстрактних понять, що використовувалися в аналізі.

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

На етапі проектування також виконується оптимізація моделі.

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

На етапі проектування також повинна бути визначена фізична структура моделі. Таким чином, на етапі проектування виконуються наступні завдання:

· специфікація результатів аналізу,

· проектування компонентів, які не належать області проблеми,

· оптимізація системи

· підлаштування моделі до обмежень і варіантів програмного середовища,

· визначення фізичної структури.

Детальна модель приводить до можливості вибору варіфнтів реалізації конструкцій моделі.

Основні конструкції повинні підтримуватися допоміжними:

· інтерфейс для роботи з користувачем,

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

· компонент управління пам'яті,

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

Основними чинниками успіху етапу проектування є:

· висока якість моделі,

· хороше знання середовища розробки,

· узгодженість із стандартами,

· перевірка системи,

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

До основних результатів етапу проектування належить:

· відкоректований документ формулювання вимог,

· відкоректована модель,

· детальна специфікація,

· документ, що описує проект:

o діаграми класів,

o діаграми взаємодій,

o діаграми станів,

o діаграми діяльності,

o діаграми компонентів,

o визначення ознак класів, складних і елементарних даних, методів.

· ресурси інтерфейсу користувача,

· проектування баз даних,

· фізичний проект структури системи,

· виправлений тестовий проект,

· планування виконання.

Етап реалізації

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

На практиці всі помилки не можуть бути усунені. Але існує можливість зменшити ймовірність їх виникнення, застосовуючи наступне:

· відхід від ризикованих методів (наприклад, використання вказівників),

· обмежені принципи доступу (розділення пам'яті, інкапсуляція),

· використання типізованих мов і компіляторів,

· використання мов високого рівня,

· послідовність у використанні інтерфейсів між модулями,

· врахування надзвичайних ситуацій (порожні множини, цикли, невизначеності),

· використання існуючих компонентів,

· мінімум відмінностей між концептуальною моделлю і моделлю реалізації.

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

Функції механізму:

· виявлення помилок,

· опрацювання помилок,

· виправлення помилок.

Опрацювання помилок можлива, якщо виконана відповідна діагностика.

Існує два методи опрацювання помилок:

· перевірка даних (наприклад, виконання тестованих формул),

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

Ключові чинники успіху:

· високоякісна і детальна специфікація,

· хороше знання середовища розробки,

· дотримання стандартів,

· опрацювання помилок.

Основні результати етапу реалізації полягають в наступному:

· покращений документ, що описує вимоги,

· покращена аналітична модель,

· покращений проект,

· код з перевіреними модулями,

· звіт про перевірені модулі,

· розроблена база даних,

· планування етапу тестування.

Етап тестування

Під тестуванням розуміють:

· сертифікацію - перевірка відповідності системи вимогам клієнта;

· перевірка - перевірка відповідності системи вимогам етапу формулювання вимог.

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

Тести розрізнять по деяких критеріях.

Тести можуть бути наццлені на:

· виявлення максимальнко кількості помилок,

· статистики помилок - їх частоти і оцінки надійності.

Розрізняються такі тести:

· динамічні - які порівнюють результати роботи програми з правильними результатами

· статичні - засновані на аналізі коду.

Фази тестування:

· тестування модулів (виконується після їх конструювання і реалізації).

· тестування системи (виконується після її інтеграції. Воно охоплює тестування системи і всіх модулів).

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

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

В результаті виконання етапу тестування отримуємо:

· покращені код, проект, модель і специфікація вимог,

· звіт про тести,

· оцінка надійності.

Етап установки

На етапі установки продукт передають користувачеві, який стає власником системи.

Етап установки передбачає:

· навчання користувача і адміністратора

· установка програмного і апаратного забезпечення

· установку баз даних

· контрольоване використання системи

· передача системи клієнтові.

Чинники успіху етапу установки:

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

· позитивна оцінка проекту.

Основні результати етапу:

· покращений код, проект, модель і специфікація вимог

· встановлення ПЗ у клієнта.

Етап підтримки

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

Під підтримкою ми розуміємо змінення системи. Існує три класи модифікацій ПЗ:

· усунення помилок,

· поліпшення якості ПЗ,

· оновлення ПЗ для сумісності із зовнішніми системами, які тут модифікуються.

Кожна зміна повинна бути проаналізована раніше її введення, і повинне бути прийнято рішення, чи має зміна сенс.

Аналіз повинен охопити:

· дія зміни на експлуатацію,

· вартість зміни,

· дія зміни на специфічні компоненти системи,

· дія зміни на специфічні компоненти документа.

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

Чинники успіху етапу підтримки:

· Висока якість вимог, моделі і проектних визначень

· Хороше знання середовища виконання

· Мотивована команда, яка підтримує систему

· Хороша вартісна оцінка обслуговування.

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

IV. Стратегічний етап

Малюнок 4.1.1.

Дії на стратегічному етапі

Стратегічний етап – це етап попереднього планування проекту. Його також називають стратегічним планом комп'ютеризації або визначенням досяжних меж.

Головними діями в етапі є:

· взяття інтерв'ю у клієнтів,

· визначення мети проекту з точки зору клієнта,

· визначення меж і контексту проекту,

· попереднє визначення вимог, загальний аналіз і дизайн системи,

· розгляд альтернативних шляхів рішення,

· оцінка витрат на програмне забезпечення,

· аналіз прийннятих рішень,

· презентація рішень стратегічного етапу клієнтові і врахування його поправок,

· попереднє планування проекту,

· визначення стандартів, яким проект повинен відповідати.

Співпраця з клієнтом

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

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

Мал. 4.3.1