Методології SDLC, які часто використовуються

Більше половини ІТ-проектів закінчуються провалом. Одні з найпоширеніших причин невдач ІТ-проектів – неправильна інтерпретація бізнес-цілей, ігнорування клієнтів, неправильне розміщення пріоритетів. Але всі вони мають загальний корінь проблеми: неправильний підхід до розробки програмного забезпечення.

Основні методології розробки ПЗ

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

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

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

• Дослідження. Група розробників збирає вимоги до проекту та включає їх у документ «Специфікація вимог до програмного забезпечення» (SRS).

• Дизайн. Команда аналізує всі вимоги та демонструє прототип системи.

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

• Тестування. Команда QA запускає кожен модуль через різні сценарії тестування та інтегрує їх у систему. Щойно всі компоненти готові, вони тестують систему в цілому.

• Розгортання. Рішення доставляється замовнику повністю робочому стані.

• Обслуговування. Команда розробників стежить за проектом та за необхідності вносить оновлення.

Плюси та мінуси підходу

+Проста у використанні модель. - З цією моделлю надто складно та дорого адаптуватися до змін вимог.

+Кожен етап добре задокументовано. 

- Документування кожної фази проекту займає багато часу.

+Результат проекту абсолютно передбачуваний.

- Ви не можете нічого надати замовнику, доки не завершите весь проект.

+Етапи та ролі чітко визначені із самого початку. 

-Різні команди (дизайн, розробка, контроль якості тощо) ізольовані, а взаємодія між ними обмежена.

+Мінімальне втручання клієнта. 

-Без зворотного зв'язку клієнта результат ризикує не виправдати очікування.

Каскадна модель – адекватний варіант, якщо виконуються ці умови:

Проект короткий та з нульовим ризиком. Вимоги фіксовані. Технології є стабільними.

Доступні усі необхідні ресурси.

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

V-подібна модель SDLC

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

Плюси Мінуси

+ Легко реалізовувати 

- У V-подібної моделі внести зміни в середині проекту вкрай складно.

+Тест-кейси створюються заздалегідь. 

-За такої великої кількості процедур тестування залишається менше часу на код.

+Бюджет та тривалість проекту передбачувані. 

-У порівнянні з каскадною ця модель потребує більше фахівців.

+У кожного етапу є свої результати, і все добре задокументовано. 

-Модель не підходить для проектів із вимогами, що швидко змінюються.

+Це структурований підхід з чітко визначеними ролями та функціями. 

- Не підходить для великих та складних проектів.

Яким проектам підходить:

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

Модель еволюційного прототипування

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

Плюси Мінуси

+Отримати відгуки користувачів на ранніх етапах.

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

+Високі шанси успіху проекту. 

-Розробляти кілька прототипів дорого.

+Легко адаптуватися до вимог, що швидко змінюються.

Яким проектам підходить

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

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

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

Планування. Збираються всі вимоги до проекту та поділяються на складові.

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

Плюси Мінуси

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

-Під час інтеграції модуля можуть бути архітектурні проблеми.

+Легше та дешевше врахувати зміни у вимогах проекту. 

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

+Зворотній зв'язок клієнта на ранній стадії. 

-Участь клієнтів може бути проблематичною.

+Невеликі частини програмного забезпечення легше тестувати та виправляти. 

-Не завжди можна розбити систему на сегменти.

+Економія з витрат. 

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

Ітеративна або інкрементна модель буде ефективна у таких випадках: 

• Якщо система складається з кількох сегментів із чіткими вимогами. 

• Обмежені ресурси на проекті або є обмеження часу виходу рішення на ринок.

• Для стартапів, які проходять інвестиційні раунди.

• Масштабні проекти. Проекти, основу яких нові технології.

•  Проекти, які потрібно буде розвивати після випуску.

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

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

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

Збір вимог. Він включає виявлення та аналіз потреб зацікавлених сторін та бізнес-цілей.

Аналіз ризиків та прототипування. Команда оцінює всі можливі способи задоволення потреб клієнтів та вибирає найкраще рішення. Потім вони виявляють та усувають ризики, пов'язані з рішенням, та створюють прототип, який розвивається з кожним наступним циклом.

Інжиніринг. Команда інженерів продовжує розробку та тестування того, що було заплановано на двох попередніх етапах.

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

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

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

Плюси Мінуси

+Аналіз ризиків кожної ітерації збільшує шанси проекту успіх. 

-Потрібний досвід управління ризиками.

+Цей метод дозволяє створювати стабільні та надійні системи, оскільки вони ретельно тестуються у кожному циклі. 

-Модель має роботу з великим обсягом документації.

+Можна міняти вимоги між циклами. 

-Не можна змінити вимоги у середині циклу.

+Раннє залучення розробників допомагає узгодити бізнес-вимоги та технічні можливості.

- Кожен гурток у спіралі розвитку є «міні-каскад», а це означає, що ви не можете пропускати фази.

+Часті випуски дають змогу отримувати регулярний зворотний зв'язок від клієнтів навіть на ранніх етапах циклу. 

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

Спіральна модель підходить для:

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

• Проектів із частими релізами.

• Проектів середнього та високого ступеня ризику.

• Проектів із неясними вимогами.

• Microsoft, IBM та Tata Consultancy використовують спіральну модель.

Моделі гнучкої розробки програмного забезпечення

Усупереч поширеній думці Agile не є ні структурою, ні методологією. до наступних цінностей:

Люди та взаємодія важливіші за процеси та інструменти.

Робоче програмне забезпечення над великою документацією.

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

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

Цінності Agile породили понад 50 методологій, з яких Scrum є найпопулярнішою.

Scrum

Скрам-проекти розбиті на спринти - це невеликий обсяг роботи, який необхідно виконати протягом певного періоду часу. співробітництво між усіма учасниками проекту. Поряд із щоденними 15-хвилинними. зустрічами розробників, є також:

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

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

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

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

Але чи дійсно все так гладко і красиво в Agile? Подивимося на його основні варіанти використання, а також на плюси та мінуси.

Плюси Мінуси

+Не потрібно чекати на завершення проекту, щоб впровадити основні функції продукту.

- Гнучкі методології розробки програмного забезпечення складно впровадити.

+Крос-функціональні команди регулярно спілкуються та обмінюються знаннями між собою та власниками проектів. 

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

+Можливість адаптуватись до змін на будь-якій стадії проекту.

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

+Регулярний зворотний зв'язок від користувачів, що дозволяє задовольнити усі потреби. 

-Збір відгуків користувачів може бути складним завданням.

Приклади використання:  Більшість сучасних проектів вимагають певного рівня «маневреності», особливо коли:

• Вимоги до проекту недостатньо зрозумілі.

• Вимоги до проекту постійно змінюються.

• Проект включає безліч взаємодій з користувачем.

• Проект має багато зацікавлених сторін.

Загалом Agile здається саме тим, що потрібно більшості проектів у часи невизначеності. Не дивно, що понад 70% компаній застосовують Agile, включаючи Microsoft, IBM, Procter & Gamble та інші. І EPAM не є винятком.

Висновки:

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

Ось кілька порад як підходити до розробки на прикладі реального проекту EPAM:

Чи не обмежуйте свій проект однією методологією. Ми комбінуємо декілька підходів SDLC залежно від поточних потреб та типу процесу. Для розробки ми використовуємо деякі практики Scrum, а Kanban добре підходить для здійснення подальшої підтримки.

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

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

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

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

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

Джерело: https://stfalcon.com/uk/blog/post/SDLC-meaning