Тестування. Фундаментальна теорія. Частина 2 — Методології розробки ПЗ

Нарешті я дістався до другої шпори. Перша знаходиться тут. Ця присвячена методологіям розробки і також буде корисною для початківців у тестуванні, оскільки це також часто запитують на співбесідах.
І, як завжди, критика, уточнення, доповнення are extremely welcome.

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

• Каскадна або поетапна розробка (іноді її називають «водоспадною моделлю») — це процес створення програмного забезпечення, який передбачає послідовне пройдення фаз аналізу, проектування, реалізації, тестування, інтеграції та підтримки. Цей підхід часто використовується при роботі над великими проєктами з тривалим терміном впровадження.
• Ітеративна або інкрементна (еволюційна) модель дозволяє паралельно виконувати кілька завдань з постійним аналізом результатів і коригуванням попередніх етапів роботи. Це більш «швидкісний» підхід до розробки для великого числа кваліфікованих програмістів.
• Спіральна методика характеризується пройденням проектом повторюваного циклу на кожному етапі розвитку: планування — виконання — перевірка — оцінка (англ. plan-do-check-act cycle). Цей підхід зазвичай використовується для проєктів з неокончательно сформованою візією результату або для проєктів, які потребують швидкого впровадження поетапно.
• Гнучка методологія Agile-розробки — це так звана швидка розробка без втрати якості, коли головною метою є працездатний продукт, а не його документація. Це найсучасніший неформальний підхід до створення програмного забезпечення, у якому реагування на зміни вважається важливішим, ніж жорстке дотримання плану. Використовується для молодих швидкозростаючих проектів, які з кожною ітерацією програмного забезпечення фактично готові до його релізу.

SCRUM

Графік, що демонструє кількість виконаної та залишеної роботи. Його оновлюють щодня для простого відображення прогресу роботи над спринтом. Графік повинен бути доступним для всіх.
Існують різні типи діаграм:
• діаграма спалювання робіт для спринту — відображає, скільки задач вже виконано і скільки ще залишилося виконати в поточному спринті.
• діаграма спалювання робіт для релізу проекту — відображає, скільки задач вже виконано і скільки ще залишилося до випуску продукту (зазвичай побудована на основі кількох спринтів).
Ретроспектива
У кінці кожного спринту Скрам-команда збирається на Ретроспективу. Мета Ретроспективи — переглянути якість існуючих процесів, взаємини між людьми та застосовувані інструменти. Команда визначає, що пройшло добре, а що — не дуже, а також виявляє потенційні можливості для поліпшень. Вони розробляють план поліпшень на майбутнє.

Канбан

Стовпці зліва направо:
Цілі проекту:
Необов’язковий, але корисний стовпчик. Сюди можна помістити високорівневі цілі проекту, щоб команда їх бачила і всі про них знали. Наприклад, «Збільшити швидкість роботи на 20%» або «Додати підтримку Windows 7».
Черга завдань:
Тут зберігаються завдання, які готові бути розпочатими. Завжди для виконання вибирається верхнє, найпріоритетніше завдання, і його картка переміщується до наступного стовпчика.
Розробка дизайну:
Цей та інші стовпці до «Закінчено» можуть змінюватися, оскільки саме команда вирішує, які кроки проходить завдання до стану «Закінчено».
Наприклад, в цьому стовпці можуть знаходитися завдання, для яких дизайн коду або інтерфейсу ще не визначені і обговорюються. Коли обговорення завершені, завдання переміщується до наступного стовпця.
Розробка:
Тут завдання знаходиться до тих пір, поки розробка фічі не буде завершена. Після завершення воно переміщується до наступного стовпця.
Або, якщо архітектура неправильна або недостатньо точна, завдання можна повернути до попереднього стовпця.
Тестування:
У цьому стовпчику завдання знаходиться, поки воно проходить тестування. Якщо знайдено помилки, воно повертається до Розробки. Якщо немає помилок, воно переходить далі.
Деплоймент:
У кожного проекту свій спосіб деплойменту. Для деяких це означає розміщення нової версії продукту на сервері, а для інших це просто коміт коду до репозиторію.
Закінчено:
Сюди картка потрапляє тільки тоді, коли всі роботи з завданням повністю завершені.

Каскадна модель (waterfall)

— високий рівень формалізації процесів;
— велика кількість документації;
— жорстка послідовність етапів життєвого циклу без можливості повернення до попереднього етапу.
Недоліки
• Каскадний проект повинен постійно мати актуальну документацію. Обов’язкове оновлення проектної документації. Надлишкова документація.
• Дуже негнучка методологія.
• Може створити хибне враження про роботу над проектом (наприклад, фраза «45% виконано» не несе корисної інформації, а є просто інструментом для керівника проекту).
• Замовник не має можливості заздалегідь ознайомитися з системою навіть з прототипом системи.
• Користувач не має можливості поступово звикати до продукту.
• Всі вимоги повинні бути відомі на початку життєвого циклу проекту.
• Виникає потреба в жорсткому управлінні і регулярному контролі, інакше проект швидко виходить з графіків.
• Відсутня можливість врахувати переробку, весь проект реалізується за один раз.
Переваги
• Висока прозорість розробки і фаз проєкту.
• Чітка послідовність.
• Стабільність вимог.
• Суворий контроль менеджменту проекту.
• Сприяє складанню плану проекту та формуванню проектної команди.
• Добре визначає процедуру контролю якості.

«Водоворот» або каскадна модель з проміжним контролем

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

Ітеративна модель

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

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

Переваги моделі:
1. Результат досягається в найкоротший термін.
2. Конкурентоспроможність є достатньо високою.
3. При зміні вимог не доведеться починати все з «нуля».
Проте у цій моделі є один суттєвий недолік: неможливість регламентування етапів виконання.

V модель — розробка через тестування

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

Модель на основі розробки прототипу

Модель Хаосу

Экстримальне програмування (XP)

RATIONAL UNIFIED PROCESS (RUP)

В основі методології лежать 6 основних принципів:

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

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

MICROSOFT SOLUTIONS FRAMEWORK

Базові концепції та принципи моделі процесів MSF: