Моделі розробки додатків

Модель водоспаду

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

Універсальний процес

Етапи

Фази

Ітерації

Компромісний трикутник

Принципи моделі процесу розробки

Рекомендації з організації випуску версій продукту

Склад проектної команди та обов’язки її членів

Ролі членів групи в моделі процесу розробки

 

Процес розробки

Для успішного керування проектами розробки програмного забезпечення потрібні дві важливих якості. Перше – строгість – необхідно для постійного контролю стану проекту. Друге – гнучкість – потрібно для успішної адаптації до неминучих несподіванок. Більша частина цього розділу присвячена моделі процесу розробки додатків MSF(MSF Process Model for Application Development), або, коротше, моделі процесу розробки. Модель процесу MSF – це не детальна інструкція, а структурний каркас, на базі якого організації можуть створювати конкретні способи рішення своїх завдань. Модель процесу розробки – складова частина цієї структури, що описує життєвий цикл проекту розробки програмного забезпечення. Вона дозволяє проектній групі створювати продукт у постійному контакті із замовником і адаптувати процес відповідно до його побажань. Крім того, цей метод здатний забезпечувати найшвидшу реалізацію ключових складових проекту. Модель процесу розробки додатків MSF – гнучкий компонент загальної моделі процесу MSF. с успіхом застосовуваний в індустрії розробки програмного забезпечення для підвищення керованості проектів, мінімізації ризиків, підвищення якості продукції й прискорення розробки.

 

Моделі розробки додатків

 

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

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

 

Модель водоспаду

 

Як показано на рис. 1.1. модель водоспаду представляє процес розробки у вигляді строго впорядкованої послідовності етапів. До них відносяться:

– збір вимог до системи й програмного забезпечення;

– аналіз;

– проектування;

– кодування й тестування модулів;

– інтеграція системи;

– тестування додатка в цілому;

– передача в експлуатацію.

Інтегральне тестування

Кодування та тестування модулів

Збір вимог

Аналіз

Проектування

Інтеграція системи

Приймання

Рис. 1.1. Модель водоспаду

 

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

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

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

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

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

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

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

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

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

 

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

– дослідження – аналіз вимог і попереднє планування;

– пророблення – проектування додатків;

– перехідний період – оцінка й стабілізація додатка;

– створення – реалізація додатка.

Кожна із цих стадій звичайно підрозділяється на п'ять фаз:

– збір вимог;

– проектування;

– реалізація;

– розгортання;

– керування.

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

 

Оцінка та стабілізація

Планування та аналіз

Реалізація

Проектування

 

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

 

Як і модель водоспаду, спіральна модель породжує наступні проблем и:

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

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

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

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

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

Універсальний процес

 

Універсальний процес (Unified Process, UP) – широко розповсюджений метод аналізу, проектування й розробки додатків масштабу підприємства. Основні характеристики цього процесу, що базується універсальною мовою моделювання, такі:

– сценарії використання як основа проекту;

– пріоритет архітектури;

– ітераційний і інкрементний процес розробки;

– прогнозування ризиків;

– об’єктно- і сервісно-орієнтоване проектування;

– активне нагромадження й повторне використання об’єктно-орієнтованих шаблонів і об'єктів.

Етапи

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

– Вимоги – збір бізнес-, технічних і прикладних вимог до проекту.

– Аналіз – бізнес- і прикладне моделювання на основі зібраних вимог.

– Проектування – створення архітектури на основі об’єктно-ориентированного підходу.

– Реалізація – розробка спроектованого додатка (на ранніх стадіях – розробка прототипів).

– Тестування – перевірка зробленої роботи.

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

Вимоги

Основне завдання етапу «Вимоги» – направити ітерацію на розробку додатка відповідно до вимог замовника й користувачів. Для цього необхідно описати додаток з тим ступенем деталізації, що достатня для досягнення згоди між замовником, користувачами й проектною групою щодо того, що додаток повинне робити й чого воно робити не повинне. Інформація на цій стадії збирається з безлічі джерел: від учасників проекту, з існуючих систем і документів, підготовлених замовником. У міру збору інформації проектна група створює попередній список вимог. Вимоги зручно структурувати, постачивши кожне з них короткою назвою й описом, статусом (пропозиція, прийнято, включено в остаточний список і т.п.), оцінкою вартості реалізації й описом ризиків, сполучених з виконанням цієї вимоги. До компетенції цього етапу ставиться й контекст, у якому буде працювати додаток. Автори універсального процесу рекомендують описувати контекст за допомогою бізнес-моделей або моделювання предметної області. Функціональні вимоги, що описують взаємодію додатка із суб'єктами й об'єктами контексту, описуються схемами використання. У процесі збору вимог необхідно проаналізувати й нефункціональні вимоги, наприклад, продуктивність, розширюваність і надійність. Вони можуть бути пов'язані з конкретними схемами використання або додані до моделі схем використання як нефункціональні вимоги до системи. Схеми використання повинні бути зрозумілі замовникові й користувачеві. Крім списку вимог, проектна група може створити набір проектів користувальницького інтерфейсу або прототипи, що описують взаємодію різних типів користувачів додатка.

Результати роботи етапу «Вимоги»:

– бізнес-модель (або модель предметної області), що задає контекст проектованої системи;

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

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

– список додаткових вимог, що не відносяться до конкретних схем використання.

Аналіз

На цьому етапі вимоги до додатка аналізуються й формулюються мовою розробників. У результаті функціональні вимоги, виведені зі схем використання на етапі збору вимог, уточнюються й структуруються. Етап «Аналіз» – проміжний крок між збором вимог і проектуванням додатка. Уточнення й абстрагування вимог на цьому етапі є основою проектування.

Характеристики етапу «Аналіз» і його результати:

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

– аналітична модель формулюється мовою розробників, і тому на етапі «Аналіз» з'являється формалізм, що дозволяє судити про внутрішню структуру системи:

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

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

Основний результат етапу «Аналіз» – архітектурне подання аналітичної моделі. Це подання включає наступне:

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

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

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

Проектування

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

На етапі проектування виконуються наступні роботи:

– визначаються структури підсистем (проектна модель);

– підсистеми розподіляються між рівнями (проектна модель);

– визначаються інтерфейси класів і об'єктів (проектна модель);

– активні класи зв'язуються з вузлами розгортання (модель розгортання).

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

Реалізація

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

Етап «Реалізація» складається з:

– реалізації прототипу архітектури;

– реалізації компонентів (класів і об'єктів);

– тестування компонентів;

– інтеграції компонентів;

– складання додатка:

– створення тестів на основі схем використання;

– перевірки архітектури;

– планування наступного складання;

– переходу до наступної ітерації.

Тестування

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

Фази

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

– фаза «Дослідження» призначена для створення моделі предметної області;

– ітерації фази «Пророблення» відносять цілю створення базової архітектури;

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

– перехідний період для перевірки готовності продукту до експлуатації.

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

Дослідження

Число ітерацій цієї фази важко пророчити заздалегідь, однак звичайно воно не перевершує двох, а основна увага приділяється етапу «Збір вимог». Завдання фази «Дослідження» чітко визначені її цілями: опис основних характеристик додатка, зниження ймовірності реалізації основних ризиків і підготовка обґрунтування проекту з погляду його зв'язку з основними завданнями бізнесу. На цій стадії:

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

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

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

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

Фаза «Дослідження» завершується формулюванням цілей проекту.

Пророблення

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

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

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

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

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

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

Фаза «Пророблення» завершується створенням архітектури додатка.

Створення

Фаза «Створення» – основна за часом і споживанням ресурсів. Вона ж вимагає найбільшого числа ітерацій. Ціль цієї фази – створення додатка, а основне завдання – завершити розробку додатка й переконатися, що воно готово до перехідного періоду. До початку перехідного періоду треба переконатися, що додаток досяг первісної стабільності й готово до бета-тестування. Інкрементальний підхід до розробки рекомендує послідовно нарощувати функціональні можливості продукту. На стадії «Створення»:

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

– завершується виконання перших трьох етапів;

– починається тестування (звичайно на цій фазі виконується приблизно 15% етапу «Тестування»);

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

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

Фаза «Створення» завершується етапом «Готовність до досвідченої експлуатації».

Перехідний період

Перехідний період починається з подання першої бета-версії додатка замовникові й обмеженому колу користувачів. Основні завдання перехідного періоду – підготувати продукт до випуску й користувачів до його експлуатації. Для завершення цієї фази – етапу «Випуск продукту» – необхідно докладне тестування продукту користувачами саме в тому середовищі, де він буде експлуатуватися. У перехідний період проводиться:

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

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

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

– усунення проблем, виявлених при бета-тестуванні;

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

Ітерації

Ітерації кожної фази тривають доти, поки не досягнута мета цієї фази. У міру просування проекту від фази до фази ступінь важливості й витрати на окремі етапи змінюються.

Крім того, фази «Дослідження» і «Пророблення» вимагають підвищеної уваги до керування проектом і до організації середовища розробки.

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