Все про SDLC

Колись давно почали створювати програмні продукти на рівні бізнесу. А бізнес же непростий, для нього треба розробити якісь процеси, все розпланувати і підрахувати та мінімізувати ризики. Розробка ПЗ - не виключення, тож так і зʼявився SDLC - Software Development Life Cycle.

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

Отже, існує кілька моделей цього циклу, деякі менш популярні, деякі - найбільш. Зараз коротко пройдемося по ним.

Waterfall

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

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

Плюси моделі Водоспаду такі:

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

Але, мінуси все ж переважають:

• Не передбачає повернення до попередніх етапів, тобто, після зміни вимог вже під час розробки модель просто ламається.
• Передбачена лише для маленьких і "одноразових" проектів, де розробка робиться лише once and forever.
• Не передбачає жодних прототипів на старті - працюючий продукт виходить лише ближче до кінця процесу.
• Якщо при розробці виявили проблеми, їх можна починати фіксити лише на наступному етапі - Testing.

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

V-Model

Ця лінійна модель (ще називають Verification and Validation Model) є невеликим розширенням Водоспаду: для кожного етапу до кодування передбачається окремий етап дизайну відповідних тестів:

Таким чином, вже одразу після етапів збору вимог, дизайну системи, архітектурного дизайну ми робимо дизайн відповідних тестів: User Acceptance tests, Functional tests, Integration tests і Unit tests відповідно.

В принципі, переваги і недоліки у V-Model такі ж, як і у Водоспада. Також рекомендується використовувати лише для маленьких і "зрозумілих" проектів.

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

Ця модель вже дещо популярніша від попередніх, дехто навіть може використовувати її сьогодні.

Суть моделі полягає у тому, щоб розбити розробку продукту на ітерації, кроки в яких - однакові:

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

Отже, плюси такі:

• Для початку роботи не вимагається наявність всіх вимог до продукту.
• Досить швидко зʼявляється прототип.
• Тестування і відладка в маленьких ітераціях набагато легші.
• Модель підтримує зміну вимог.
• Можемо виміряти прогрес.
• Підходить для великих проектів.
• Дозволяє засетапити кілька команд для паралельної розробки.

І мінуси:

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

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

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

Отже, модель має 4 фази:

1. Identification. Саме з цієї фази починається кожна спіраль. Включає збір вимог до продукту, а також багато комунікації, метою якої є повна зрозумілість вимог всім сторонам. У другій і наступних спіралях включає збір вимог для систем, підсистем, модулів і т.д.
2. Design. На першій спіралі у цій фазі створюється концептуальний дизайн продукту. На наступних спіралях - архітектурний дизайн, дизайн підсистем, модулів і т.д.
3. Construction. У цій фазі проводиться розробка і тестування продукту. На першій спіралі ж розробляється POC (Proof of Concept).
4. Evaluation. І нарешті - оцінка зробленого самим замовником, що включає також оцінку ризиків - як саме варто продовжувати розробку, чи взагалі варто, що треба врахувати у майбутньому і т.д.

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

Agile

І, нарешті, найсучасніша методологія - Agile. Хоча, насправді, Agile - це набір практик, який успадковують його фреймворки: Scrum, Kanban, XP...

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

Роком народження Agile вважають 2001, коли у мережі опублікували так-званий The Agile Manifesto, хоча його імплементації зʼявились раніше. Цей маніфест каже, що треба більше цінувати:

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

Також Agile вводить такі ролі:

• Product Owner (ще називають "голос клієнта") - є "власником" вимог до продукту і відповідальною за їх узгодження і валідацію особою. Постійно комунікує з командою розробки, працюючи над так-званими User Stories - тасками з точки зору бізнесу.
• Scrum Master - це по суті роль менеджера, який наглядає за проектом і перевіряє, чи всі Agile принципи, процеси і цінності дотримуються командою розробки.
• Team Member - всі інші члени команди, як-от девелопер, куа, бізнес аналітик, дизайнер і т.д.

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

Scrum

Scrum - це один з найвідоміших фреймворків Agile.

По суті, все те ж саме, що і диктує Agile, але конкретніше. За Скрамом, ітерації поділяються на такі етапи:

• Planning: визначаються пріоритети спринта і формується скоуп тасок на цей спринт.
• Daily standup: всім нам знайомий дейлік, де кожен має відповісти на питання "що робили вчора", "що будете робити сьогодні" і "які є блокери".
• Demo meeting: демо з кастомером, на якому демонструється робота, зроблена за спринт, і кастомер ділиться фідбеком.
• Retrospective meeting: є багато форматів, але в загальному тут команда підводить підсумки спринта і кожен має можливість поділитись тим, що йому сподобалось і не сподобалось протягом роботи над цим спринтом, щоб у наступному спринті це покращити.

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

Kanban

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

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

До речі, Канбан вийшов з компанії Toyota, а сам цей термін з японської перекладається як "вивіска з лого компанії".

Саме Канбан завжди асоціюється з цими дошками з колонками, що відповідають статусу тікетів, які рухаються з колонки до колонки. Така модель ідеально підходить проектам, де непросто оцінити складність тікетів і, відповідно, проестімейтити їх у сторіпоінтах - як на моєму проекті раніше: коли два однакових тікети можуть важити як 2 сторіпоінти, так і 20.

Extreme Programming (XP)

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

По суті, модель фокусується на кількох речах:

• Парне програмування: вся девелопмент робота виконується у парах, як кажуть "один - driver, інший - navigator". Передбачається, що якщо писати код у парі, багів буде значно менше, а процес код ревью взагалі не потрібен. Також обовʼязково має бути зміна ролей у процесі розробки (ну тобто спочатку один пише код а інший "навігує", через деякий час ролі змінюються).
• Тести: весь код має бути покритий надійними юніт- і функціональними тестами, щоб ще більше зменшити імовірність появи багів, а також забезпечити можливість перевикористання коду.
• Комунікація: знову ж, посилена комунікація між членами команди і стейкхолдерами, ледь не до сумісного написання коду.

У цієї методології також є свій офіційний сайт, де можна почитати про неї детальніше.

Висновки

Software Development Life Cycle - цикл розробки ПЗ, який потрібен бізнесу для планування і керування процесом розробки, а також для оцінки продуктивності і ризиків. Етапи SDLC найчастіше включають збір і валідацію вимог, планування, дизайн, кодування, тестування і підтримку (або deployment).

Існує багато моделей (методологій) SDLC, найбільш відомі з яких: Waterfall, V-модель, Ітеративна, Спіральна, а також Agile.

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

V-модель - невелике покращення Водоспаду, яке полягає у тому, що розробка тест-кейсів відбувається одразу ж після відповідних етапів: User-Acceptance, Functional, Integrational, Unit.

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

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

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

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

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

Extreme Programming - фреймворк Agile, що фокусується на парному програмуванні і якісних тестах.

Джерела

https://www.tutorialspoint.com/sdlc/index.htm

https://www.roberthalf.com/blog/salaries-and-skills/6-basic-sdlc-methodologies-which-one-is-best

https://www.virtasant.com/blog/sdlc-methodologies

https://www.javatpoint.com/software-engineering-software-development-life-cycle