Menu

Studium przypadku: jak wyeliminować wady kaskadowych i zwinnych procesów programistycznych za pomocą modelu hybrydowego

  • Główny
  • Testowanie Zwinne
  • Studium przypadku: jak wyeliminować wady kaskadowych i zwinnych procesów programistycznych za pomocą modelu hybrydowego

case study how eliminate flaws waterfall

Wypróbuj Nasz Instrument Do Eliminowania Problemów

Zwinny model hybrydowy wodospadu

Model wodospadu był idealnym wyborem do tworzenia oprogramowania. W tym modelu pomysł staje się użytecznym oprogramowaniem w sekwencyjnym procesie, który przechodzi przez etapy inicjowania, analizy, wdrażania, testowania i konserwacji.

Ale model Waterfall ma pewne wady.

Rozwój oprogramowania zwinnego ewoluował, aby wyeliminować problemy, które ma model Waterfall. Ma zupełnie nowe ramy. Podczas gdy model Waterfall ma konstrukcję sekwencyjną, model Agile opierał się na podejściu przyrostowym.

Kiedy klienci, którzy kiedyś stosowali model Waterfall, przeszli na Agile, przejście to przyniosło wiele problemów. Przyczyną jest niemożność dostosowania się do innego podejścia do tworzenia oprogramowania. Końcowy produkt okazał się katastrofą.

Zwinny model hybrydowy wodospadu

W ten sposób rozwinęła się nowa metodologia, którą można nazwać „hybrydową”, aby zapewnić solidny produkt końcowy, wybierając zalety zarówno modeli Agile, jak i Waterfall.

Najpierw dowiedzmy się o modelach rozwoju Waterfall i Agile, a następnie przejdźmy do „Agile Waterfall Hybrid Model” z zaletami i wadami każdego z nich.

Czego się nauczysz:

Model wodospadu

Model Waterfall to podejście do tworzenia oprogramowania, które dzieli projekt na skończone fazy. Do kolejnej fazy należy przejść dopiero po przejrzeniu i weryfikacji jej poprzedniej fazy.

W modelu kaskadowym etapy nie nakładają się.

=> Przeczytaj więcej o modelu wodospadu tutaj.

Rysunek 1 przedstawia model Waterfall:

Model wodospadu

Zalety modelu wodospadu:

  • Prosty i łatwy do zrozumienia i użytkowania.
  • Sztywny model - każda faza ma określone produkty i procesy przeglądu.
  • Dokumentacja i artefakty starannie utrzymane.
  • Nadaje się do projektów, w których wymagania są dobrze zrozumiane.

Wady modelu Waterfall:

  • Nie nadaje się do projektów, w których istnieje ryzyko zmiany wymagań.
  • Koszt naprawy usterek jest bardzo wysoki, jeśli zostaną wykryte na późniejszym etapie.
  • Nie jest to dobry model dla złożonych i długich projektów.
  • Żadne działające oprogramowanie nie jest produkowane do późnego końca cyklu życia.

Zwinny model

Wikipedia definiuje model Agile jako „grupę metod tworzenia oprogramowania opartych na iteracyjnym i przyrostowym rozwoju, w których wymagania i rozwiązania ewoluują poprzez współpracę między samoorganizującymi się, wielofunkcyjnymi zespołami”.

Model ma własne zasady, które mają tendencję do sprowadzania procesów na tylne siedzenie.

=> Przeczytaj więcej artykułów na temat metodologii Agile tutaj.

(Kliknij obraz, aby wyświetlić w powiększeniu)

Zwinny model

Zalety modelu Agile:

  • Zaangażowanie klienta w proces.
  • Wysoki zwrot z inwestycji, ponieważ działające oprogramowanie jest dostarczane często.
  • Nawet późne zmiany wymagań można łatwo dostosować.
  • Ciągłe ulepszanie zarówno produktu, jak i procesu.

Wady modelu Agile:

  • Brak nacisku na projektowanie i dokumentację.
  • Zespół powinien być stabilny i wykwalifikowany.

Model współpracujący (hybrydowy)

Model współpracy ma na celu połączenie obu modeli - Waterfall i Agile. Wykorzystanie zarówno podejścia Waterfall, jak i Agile zapewnia sukces projektu. Eliminuje wady obu modeli; łącząc zalety obu.

Model oparty na współpracy można zaimplementować w projekcie poprzez wykonanie:

Model współpracujący (hybrydowy)

Zatem model współpracy można przedstawić schematycznie, jak poniżej:

Model współpracujący (hybrydowy) 2

Zalety modelu Hybrid

  • Łączy zalety procesów Agile i Waterfall.
  • Projekt wysokiego poziomu jest przygotowany do zastosowania zasad kaskadowych.
  • Kodowanie i testowanie odbywa się za pomocą zwinnej metodologii.

Model hybrydowy Agile Waterfall - nauka na przykładzie -Studium przypadku

Firma programistyczna „ABC Software Service” świadczy usługi na rzecz klienta, uniwersytetu o nazwie „Uniwersytet XYZ”, w celu rozwijania, testowania i utrzymywania oprogramowania (wsparcie produkcyjne na żywo).

Główne cechy konta to:

  1. ABC Software Services musi zaktualizować aplikacje XYZ University. Baza danych wymaga aktualizacji, a wszystkie aplikacje muszą zostać ponownie opracowane do najnowszych technologii dostępnych na rynku.
  2. Do tej pory wszystkie projekty obsługiwane przez ABC Software były realizowane w modelu Waterfall.
  3. Zaplanowano ponowne opracowanie dwóch aplikacji o dużym natężeniu ruchu i o wysokim priorytecie. Pierwsza to „Rejestracja online”, druga to „Egzaminy online”.
  4. Klient XYZ University chciał teraz pracować nad tymi aplikacjami przy użyciu zwinnego modelu tworzenia oprogramowania.

Pierwszym projektem w modelu Agile dla ABC Software były rejestracje online. Po wykonaniu tego projektu, w ramach serii retrospektyw zdano sobie sprawę, że w procesach, które były realizowane, było wiele błędów.

Te wady zostały usunięte podczas realizacji drugiego projektu „egzaminów online” i dlatego został on wykonany w modelu hybrydowym.

Jak wyeliminować wady kaskadowych i zwinnych procesów programistycznych za pomocą modelu hybrydowego:

Omówmy je szczegółowo jeden po drugim.

# 1. Brak dokumentacji:

Jedna z zasad zwinnych w manifeście agile stwierdza, że: Agile nadaje większą wartość „Działającemu oprogramowaniu niż kompleksowej dokumentacji”. Metodologia zwinna uważa, że ​​dokumentacja powinna być „ledwo dostatecznie dobra”, a większy nacisk kładzie się na dostarczenie działającego oprogramowania. Niewiele wysiłku wkłada się w dokumentację, ale w przypadku kont takich jak Uniwersytet XYZ, z dedykowanym zespołem wsparcia do pracy nad defektami znalezionymi w projektach na żywo, ten nawyk może okazać się przeszkodą, jeśli przeanalizujemy go w perspektywie długoterminowej.

Przez lata, kiedy projekty były realizowane w modelu Waterfall, dokumenty były utrzymywane i aktualizowane, aby zespół wsparcia mógł je zrozumieć i odpowiednio pracować. Projekt rozwiązania, projekt techniczny, dokumentacja przejścia, itp. To tylko niektóre z przygotowanych dokumentów. Po zakończeniu projektu to samo zostało przeniesione do zespołu wsparcia.

Jednak w przypadku projektu „rejestracje online” nie przygotowano takich dokumentów, co okazało się kosztowne. Kiedy projekt ruszył, użytkownicy końcowi zgłosili wiele zgłoszeń, a zespół wsparcia nie miał pojęcia, jak nad nimi pracować. Zespół nie miał żadnego dokumentu do odniesienia.

To była ważna lekcja, a na potrzeby kolejnego projektu dokumenty „egzaminów online” zostały skutecznie napisane i przeniesione.

=> Przeczytaj więcej tutaj, dlaczego dokumentacja jest ważna.

#dwa. Brak testów UAT / od końca do końca:

W zwinnym trybie tworzenia oprogramowania testerzy otrzymują kompilacje do testowania w przyrostach. Te kompilacje są integrowane aż do całkowitego zbudowania ostatecznej wersji. Testerzy testują wymagania zawarte w każdym sprincie i kontynuują testy regresji kompilacji, która wciąż się sumuje.

Ale po zakończeniu wszystkich sprintów, a ostateczna wersja jest gotowa i zintegrowana, tester powinien przetestować cały system i przeprowadzić testy od początku do końca. Należy to zrobić w zupełnie nowym środowisku.

=> Testowanie od końca do końca w aktywnym projekcie.

Ma to swoje zalety:

  • Cały system jest wdrażany w nowym środowisku, a tester testuje cały przepływ.
  • Buduje zaufanie, ponieważ ostatecznie kompilacja musi zostać wdrożona jako całość w aktywnym środowisku.

Gdy projekt rejestracji online był testowany, odbywało się to w środowisku testowym. Po przetestowaniu systemu i ponownym przetestowaniu wszystkich usterek został zgłoszony do zatwierdzenia. W idealnym przypadku nie zostało to przeniesione do innego środowiska na kolejny cykl testowania systemu. (Idealnie, UAT następuje po przetestowaniu systemu , ale w tym przypadku członkowie zespołu UAT byli zaangażowani w pierwszy cykl testów, więc nie zaplanowano drugiego cyklu)

Kiedy rozpoczął się projekt egzaminacyjny online, SIT (Test Integration Testing) został ukończony, a kod został promowany do środowiska UAT, gdzie przeprowadzono drugi cykl testów. Wynik: wszystkie usterki o wysokim priorytecie zostały wychwycone i rozwiązane. Kompilacja była stabilna przed wydaniem na żywo.

# 3. Brak Scrum Mastera:

Plik Scrum Master jest odpowiedzialny za upewnienie się, że zespół żyje zgodnie z wartościami i praktykami Scruma. Scrum Master jest uważany za trenera zespołu, pomagając zespołowi wykonywać najlepszą możliwą pracę. Scrum Master można również traktować jako plik właściciel procesu dla drużyny.

Zespół rejestracji online powstał bez Scrum Mastera. Znaczenie posiadania dedykowanego Scrum Mastera nie było uważane za ważne. To powodowało, że wiele problemów nie było rozwiązywanych na czas, a czas na ukończenie projektu często przekraczał termin.

Jednak dedykowany Scrum Master był zaangażowany w projekt egzaminów online. Zadaniami i wyzwaniami projektu zajął się Scrum Master. Przygotowano raporty z projektu / sprintu, a zespół mógł zobaczyć ich postępy.

Ponadto dla każdego sprintu odbywały się odpowiednie spotkania dotyczące planowania sprintu i spotkania retrospektywne, które poprawiały wydajność zespołu. Zespół koncentrował się tylko na swojej pracy i wykonywaniu zadań przydzielonych do tego sprintu. Wszystkie dodatkowe czynności porządkowe były wykonywane przez Scrum Mastera.

# 4. Konwersja dokumentów projektowych do backlogu produktu:

Wstępne dokumenty projektowe, które są przygotowywane w modelu kaskadowym, to specyfikacja wymagań biznesowych (BRS), projekt wysokiego poziomu, projekt funkcjonalny itp. Dokumenty te muszą zostać przekształcone w backlog produktu w celu wykonania etapów kodowania, testowania i wdrażania. w trybie zwinnym. To bardzo ważny krok.

Backlog produktu jest punktem wyjścia dla projektu zwinnego. Rejestr produktu to uszeregowana pod względem ważności lista wymagań, które są utrzymywane dla produktu. Składa się z funkcji, poprawek błędów, wymagań niefunkcjonalnych itp. Jest to rosnący dokument, który staje się coraz większy i lepszy w oparciu o opinie klientów, zmieniające się wymagania itp.

oprogramowanie AI uczy się tworzyć oprogramowanie AI

Będąc pierwszym artefaktem w każdym projekcie, najważniejsze jest, aby wypisać wymagania i przypisać im priorytety. Konwersja dokumentów projektu kaskadowego w backlog produktu jest dużym zadaniem samo w sobie i wymaga burzy mózgów całego zespołu wraz z klientem / interesariuszem.

Gdy wszystkie wymagania zostaną wymienione i uzgodnione przez klienta, kolejnym zadaniem jest nadanie im priorytetu, aby można było je odebrać w sprintach.

# 5. Macierz identyfikowalności:

Innym ważnym artefaktem, który jest zwykle utrzymywany w modelu wodospadu, jest macierz identyfikowalności. Aby zapewnić, że żadne wymagania nie zostaną pominięte; należy również zaprojektować i utrzymywać macierz identyfikowalności . Zwykle w agile nie jest projektowana taka macierz.

To najlepsza praktyka w każdym projekcie. Macierz identyfikowalności powinna zostać przygotowana równolegle do rejestru produktu. I należy to porównać z przypadkami testowymi wykonanymi podczas testów akceptacyjnych użytkownika / testów od końca do końca (ten etap jest wyjaśniony w następnym punkcie). Nawet jeśli jakiekolwiek wymagania zostaną pominięte, można je łatwo wprowadzić nawet na późnych etapach rozwoju, ponieważ zwinność zapewnia dodatkową elastyczność i zdolność adaptacji.

Po uruchomieniu projektu Rejestracje online, dostęp do aplikacji uzyskali użytkownicy końcowi (studenci, którzy chcieli się zarejestrować). Napotkali wiele problemów w aplikacji. Zaowocowało to wieloma zgłoszeniami do zespołu wsparcia produkcji. Podniesione mandaty można zaklasyfikować jako incydenty, problemy lub zmiany. Rozwiązano wiele problemów, spodziewając się, że aplikacja będzie stabilna. Ale nawet wtedy w kolejnych wersjach zaplanowano kilkanaście żądań zmian / ulepszeń. Te ulepszenia miały na celu ustabilizowanie aplikacji i poprawę komfortu użytkowania.

Ostatecznie koszt projektu gwałtownie wzrósł. Dlatego, jeśli projekt nie zostanie prawidłowo przeniesiony na zwinny, może to spowodować przekroczenie budżetu. Jest to bardzo konieczne, aby zaplanować dokładne przejście projektu na Agile. Planowanie powinno być również wykonywane w zakresie wymaganym przez projekt, aby mógł być wykonywany w trybie zwinnym. Dla konkretnego projektu należy zaprojektować odpowiednie modele hybrydowe.

Przed rozpoczęciem projektu Zgłoszenia do Egzaminu ten aspekt był dobrze zadbany. Pomyślano o modelu hybrydowym i zdecydowano, że faza analizy wymagań i faza projektowania wysokiego poziomu mają być przeprowadzone w modelu kaskadowym, a pozostałe etapy w modelu zwinnym.

Przyjęty model hybrydowy można obrazowo przedstawić, jak poniżej:

Model współpracujący (hybrydowy) 3

Wniosek:

Jest oczywiste, że zarówno model Waterfall, jak i model Agile mają swoje wady. Więc jest całkiem realistyczne, aby wybrać model hybrydowy, do którego jest podejście wykorzystując to, co najlepsze z obu światów.

Najważniejszym aspektem rozpoczęcia każdego projektu jest podjęcie decyzji o modelu, który zespół przyjmie. Wymaga to obszernego planowania. Przy przyjmowaniu modelu oprogramowania należy wziąć pod uwagę takie czynniki, jak budżet, czas, wykorzystanie zasobów, złożoność wymagań itp.

Model hybrydowy jest wciąż w początkowej fazie. W miarę jak coraz więcej firm będzie go przyjmować, dowiemy się więcej o tej koncepcji.

Manifest Agile prosi nas o docenienie:

  • Jednostki i interakcje nad procesami i narzędziami
  • Działające oprogramowanie ponad obszerną dokumentację
  • Współpraca z klientami nad negocjacjami umów
  • Reagowanie na zmiany nad przestrzeganiem planu

Natomiast model hybrydowy nie spełnia tego 100%. Sugeruje, że wszystkie aspekty są równie ważne. Do klientów / kierowników projektów należy decyzja, które aspekty cenią bardziej, a które bezwartościowe.

O autorze: To jest artykuł gościnny autorstwa Harshpal Singha. Ma ponad 7 lat doświadczenia w ręcznym, baz danych, automatyzacji i testowaniu wydajności, a obecnie pracuje jako kierownik zespołu w wiodącej firmie MNC. Pracował przy wielu projektach QA w modelach Waterfall, Agile i hybrydowych.

Czy masz jakieś doświadczenie w pracy nad tym hybrydowym modelem rozwoju i testowania? Porozmawiajmy w komentarzach.

rekomendowane lektury

^