Меню

Тематичне дослідження: Як усунути вади водоспадів та спритні процеси розвитку за допомогою гібридної моделі

  • Головна
  • Швидке Тестування
  • Тематичне дослідження: Як усунути вади водоспадів та спритні процеси розвитку за допомогою гібридної моделі

case study how eliminate flaws waterfall

Спробуйте Наш Інструмент Для Усунення Проблем

Гібридна модель Agile Waterfall

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

Але модель Waterfall має деякі недоліки.

Швидка розробка програмного забезпечення еволюціонувала, щоб усунути проблеми, що виникають у моделі Waterfall. Він має абсолютно нові рамки. Хоча модель водоспаду має послідовний дизайн, модель Agile використовувала поступовий підхід.

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

Гібридна модель Agile Waterfall

Таким чином, розроблена нова методологія, яку можна назвати «гібридною», щоб забезпечити надійний кінцевий продукт, вибравши плюси як Agile, так і Waterfall.

Давайте спочатку дізнаємося про моделі розвитку Waterfall та Agile, а потім перейдемо до «Гібридної моделі Agile Waterfall» із плюсами та мінусами кожної з них.

Що ви дізнаєтесь:

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

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

У моделі водоспаду фази не перекриваються.

=> Детальніше про модель водоспаду читайте тут.

Малюнок 1 демонструє модель водоспаду:

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

Переваги моделі водоспаду:

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

Недоліки моделі Водоспад:

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

Спритна модель

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

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

=> Детальніше про методику Agile читайте тут.

(Клацніть на зображення, щоб переглянути збільшене)

Спритна модель

Переваги моделі Agile:

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

Недоліки Agile Model:

  • Відсутність акценту на проектуванні та документації.
  • Команда повинна бути стабільною та кваліфікованою.

Спільна (гібридна) модель

Модель спільної роботи має на меті поєднати обидві моделі - Водоспад та Спритний. Використання підходу «Водоспад» та «Agile» забезпечує успіх проекту. Це усуває недоліки обох моделей; водночас поєднуючи переваги обох.

Модель співпраці може бути реалізована в проекті, виконавши:

Спільна (гібридна) модель

Тож модель співпраці може бути представлена ​​схематично, як показано нижче:

Спільна (гібридна) модель 2

Переваги гібридної моделі

  • Поєднує переваги як процесів Agile, так і Waterfall.
  • Дизайн високого рівня готовий застосовувати принципи водоспаду.
  • Кодування та тестування виконуються з використанням гнучкої методології.

Гібридна модель Agile Waterfall - Навчіться на прикладі -Тематичне дослідження

Фірма програмного забезпечення «ABC Software Service» надає послуги клієнту, університету під назвою «XYZ University», для розробки, тестування та обслуговування їх програмного забезпечення (підтримка поточного виробництва).

Основними особливостями облікового запису є:

  1. Служби програмного забезпечення ABC повинні оновити програми університету XYZ. Базу даних потрібно оновити, а всі додатки переробити до новітніх технологій, доступних на ринку.
  2. До цього часу всі проекти, якими займалася програма ABC Software, виконувались у моделі Waterfall.
  3. Зараз було заплановано повторне розроблення двох інтенсивних програм та пріоритетних програм. Перший - «Інтернет-реєстрації», другий - «Інтернет-іспити».
  4. Клієнт XYZ University тепер хотів, щоб над цими додатками працювали за допомогою Agile моделі розробки програмного забезпечення.

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

Ці недоліки були усунені під час виконання другого проекту «онлайн-іспити», і, отже, він був виконаний у гібридній моделі.

Як усунути вади водоспадів та спритних процесів розвитку за допомогою гібридної моделі:

Давайте обговоримо їх детально по одному.

№1. Немає документації:

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

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

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

Це було важливим уроком, який було засвоєно, і для наступного проекту документи «онлайн-іспити» були написані та ефективно передані.

=> Детальніше читайте тут, чому документація важлива.

# два. Відсутність UAT / наскрізне тестування:

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

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

=> Наскрізне тестування на живому проекті.

Це має свої переваги:

  • Повна система розгортається в новому середовищі, і тестер перевіряє весь потік.
  • Це формує впевненість, тому що в кінцевому підсумку збірка повинна бути розгорнута як єдине ціле в живому середовищі.

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

Коли стартував проект онлайн-іспитів, було проведено SIT (тестування системної інтеграції) і код просунутий до середовища UAT, де проводився другий цикл тестування. Результат: Усі дефекти високого пріоритету були захоплені та вирішені. Збірка була стабільною до випуску.

№3. Немає Scrum Master:

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

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

Однак спеціальний Scrum Master був залучений до проекту Інтернет-іспитів. Питаннями та проблемами проекту опікувався Scrum Master. Були підготовлені звіти про проект / спринт, і команда могла побачити їхній прогрес.

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

No4. Перетворення проектних документів у відставання продукту:

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

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

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

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

№5. Матриця простежуваності:

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

хороший безкоштовно завантажувач mp3 для андроїд

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

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

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

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

Прийняту гібридну модель можна зобразити наочно, як показано нижче:

Спільна (гібридна) модель 3

Висновок:

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

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

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

Маніфест Agile просить нас оцінити:

  • Особи та взаємодії над процесами та інструментами
  • Працююче програмне забезпечення над вичерпною документацією
  • Співпраця з клієнтами над переговорами про контракт
  • Відповідаючи на зміни над дотриманням плану

Тоді як гібридна модель не дотримується цих 100%. Це передбачає, що всі аспекти мають однакове значення. Клієнти / керівники проектів вирішують, які аспекти оцінювати більше, а які - безцінні.

Про автора: Це гостьова стаття Харшпала Сінгха. Він має 7+ років досвіду ручного, баз даних, автоматизації та тестування продуктивності, і в даний час працює керівником команди у провідному MNC. Він працював над багатьма проектами з контролю якості, дотримуючись моделей розвитку водоспаду, спритних та гібридних.

Чи є у вас досвід роботи над цією гібридною моделлю розробки та тестування? Давайте обговоримо в коментарях.

Рекомендована література

^