Jak korzystać z nTask do zarządzania projektami wodospadu – praktyczny przewodnik dla początkujących

Przeprowadziliśmy obszerną analizę różnych czynników, które wpływają na zarządzanie projektami kaskadowymi. Pomogło nam to uprościć sposób wykorzystania oprogramowania do zarządzania projektami nTask do rozwiązywania takich problemów. Waterfall to popularny model zarządzania projektami SDLC.

Jednak w różnych momentach jest to skomplikowana sprawa. Ten opis szczegółowo opisuje, w jaki sposób można używać nTask, aby osiągnąć maksymalną produktywność we wszystkich modelach biznesowych zorientowanych na kaskadę. Poszliśmy o krok dalej, aby zilustrować różne rzeczywiste przypadki użycia i przykłady implementacji wodospadu oraz tego, jak można użyć nTask, aby jeszcze bardziej uprościć ten proces – tak dalej i tak dalej.

Co musisz wiedzieć o zarządzaniu projektami wodospadu?

Metodologia Waterfall jest tradycyjną i najczęściej stosowaną metodologią zarządzania projektami. Podąża za sekwencyjnym, liniowym procesem, dlatego często jest określany jako „liniowo-sekwencyjny model cyklu życia”. Jak sama nazwa wskazuje, Waterfall koncentruje się na planowaniu cyklu życia projektu, dzieląc projekt na odrębne, oddzielne i ekskluzywne części: W modelu Waterfall każda faza musi zostać zakończona przed rozpoczęciem kolejnej fazy.

Zakończenie każdego charakterystycznego kroku w metodologii Wodospadu prowadzi do kolejnego etapu projektu, tak jak w przypadku rzeczywistego wodospadu. Po zakończeniu segmentu projektu nie można w nim wprowadzać żadnych innych zmian ani nie można pominąć kroku w celu ukończenia następnego. Każdy etap jest zatem zależny od ukończenia poprzednich kroków lub poziomów. To sprawia, że ​​model wodospadu jest najbardziej przydatny w przypadku mniejszych projektów o dobrze zdefiniowanych wymaganiach i mniejszej liczbie niepewności. Jego prostota i łatwość wdrożenia sprawiła, że ​​jest najpopularniejszą wersją cyklu życia systemów (SDLC) dla inżynierii oprogramowania i projektów informatycznych.

Podczas korzystania z modelu wodospadu nacisk kładzie się na upewnienie się, że wymagania i projekt odpowiadają potrzebom projektu przed przejściem do dalszych etapów rozwoju.

Tło zarządzania projektami wodospadowymi

Źródło – Codeacademy.com

Geneza Modelu Wodospadu jest często przypisywana przemysłowi wytwórczemu i budowlanemu. Metodologia Waterfall była idealna dla tych branż, ponieważ stosują one wysoce ustrukturyzowany proces produkcyjny: wymagania są jasno określone i nakreślone na początkowym etapie procesu, a pozostałe etapy są opracowywane w oparciu o wymagania. Podobnie jak w metodologii Waterfall, późniejsze zmiany na dowolnym etapie cyklu zarządzania projektem są nie tylko zbyt kosztowne, ale w niektórych przypadkach niemożliwe.

Dr Winston W. Royce, często, ale błędnie nazywany „ojcem wodospadu”, jest uznawany za pierwszy formalny opis procesu w artykule, który napisał w 1970 roku. To, co opisał dr Royce, było wadliwym modelem rozwoju oprogramowania, ponieważ argumentował za modelem z wieloma iteracjami lub przebiegami. Twierdził, że bez wielu iteracji projektu, z których pierwsza byłaby prototypem, projekt byłby zbyt ryzykowny, a nawet groziłby niepowodzeniem. Jego zdaniem iteracja prototypu była niezbędna do lepszego zrozumienia wymagań i technologii zaangażowanych w projekt oraz do zapewnienia, że ​​produkt końcowy spełni wymagania klienta.

Dodatkowe czytanie:

7 najważniejszych funkcji, których należy szukać w bezpłatnych narzędziach do zarządzania projektami

Podczas gdy dr Royce przypisuje się pierwszemu znanemu opisowi procesu, pierwszą znaną prezentację przypisuje się Herbertowi D. Beningtonowi. W dniu 29 czerwca 1956 r. Herbert D. Benington wygłosił prezentację na temat rozwoju oprogramowania dla SAGE na Sympozjum poświęconym zaawansowanym metodom programowania komputerów cyfrowych. W swojej prezentacji opisał zastosowanie takich faz w inżynierii oprogramowania. Jednak termin „wodospad” nie został użyty do opisania tego procesu.

Według Wikipedii Bell i Thayer jako pierwsi użyli terminu „wodospad” w artykule z 1976 roku.

W latach 80. Model Wodospadu został poddany intensywnej krytyce ze względu na jego sztywny charakter.

Ze względu na zmieniające się potrzeby branży programistycznej i niepowodzenie liniowości Modelu Wodospadu w dostarczaniu wczesnych informacji zwrotnych, pojawiło się wiele wersji Modelu Wodospadu. Wersje te są często zbiorczo określane jako Zmodyfikowane Modele Wodospadu.

Bardziej nowoczesny model wodospadu ma pętle sprzężenia zwrotnego do poprzednich faz, aby umożliwić modyfikacje. Inne wersje modelu Waterfall to „model sashimi” Petera DeGrace'a (wodospad z nakładającymi się fazami), model V lub model wodospadu Bent itp.

Metodologia wodospadu i jej ewolucja – tradycyjny model wodospadu

Od lat 70. firmy i projekty stosują metodologię Waterfall do zarządzania projektami. Wykorzystanie prostego schematu blokowego, który zaczynał się od punktu A i następował po kolejnych krokach, aby dotrzeć do jego końca, było nie tylko łatwe do zrozumienia, ale także do wdrożenia. Etapy metodologii Waterfall zostały opracowane przez dr Royce'a z myślą o zapobieganiu kosztownym zmianom w dalszej części cyklu rozwoju projektu. Dr Royce próbował wyjaśnić, w jaki sposób według jego doświadczenia Model Wodospadu wiąże się z ryzykiem niepowodzenia.

W oryginalnym modelu wodospadowym Royce nakreślił te etapy, aby podkreślić znaczenie tych kroków dla dużych i złożonych projektów rozwoju oprogramowania. Chciał również zwrócić uwagę, że ponieważ kroki są planowane i wykonywane w różny sposób, jak najlepsze wykorzystanie zasobów wymaga, aby w zespole znalazły się osoby, które najlepiej potrafią te kroki wykonać.

Typowe etapy modelu wodospadu

Poszczególne etapy modelu wodospadu można modyfikować, eliminować lub rozszerzać w zależności od ram projektu i wymagań.

Kolejne kroki w typowym modelu Waterfall są następujące:

1. Koncepcja : W tej fazie kiełkuje pomysł na projekt. Ta faza obejmuje zgrubną ocenę procesu, np. czy projekt jest korzystny, jakie byłyby związane z tym koszty itp.
2. Inicjacja : Po opracowaniu koncepcji, projekt jest inicjowany poprzez zatrudnienie zespołu projektowego, określającego cele, zakres, cel i rezultaty. Ten etap jest krytyczny, ponieważ model wodospadu kładzie nacisk na upewnienie się, że wymagania i projekt odpowiadają potrzebom projektu.
3. Zbieranie i analiza wymagań : Wszystkie możliwe wymagania projektu są gromadzone i analizowane przez zespół, aby zobaczyć wykonalność projektu. Może to również wymagać zrozumienia przez zespół modelu biznesowego klienta i przeanalizowania potencjalnego ryzyka związanego z projektem. Wszystkie informacje utworzone w tej fazie są następnie dokumentowane w dokumencie specyfikacji wymagań.
4. Projektowanie : W tej fazie specyfikacja wymagań jest badana, oceniana i przygotowywany jest projekt systemu do zakończenia projektu. Zidentyfikowano wymagania sprzętowe i programowe oraz zdefiniowano ogólną architekturę systemu. Specyfikacje projektowe wykonane w tej fazie są wykorzystywane w fazie kodowania.
5. Implementacja/kodowanie : jest to faza, w której faktycznie rozpoczyna się rozwój/kodowanie zgodnie ze specyfikacją projektu. Kierownik projektu deleguje zadania między członków zespołu składającego się zwykle z programistów, projektantów interfejsów i innych specjalistów, korzystając z narzędzi takich jak kompilatory, debugery, interpretery i edytory multimediów. W zależności od charakteru projektu i wielkości zespołu, zespół dzieli się na mniejsze jednostki.
6. W większości przypadków system jest najpierw rozwijany w małych programach zwanych jednostkami i są one włączane do następnej fazy. W miarę rozwoju każdej jednostki jest ona testowana pod kątem funkcjonalności, określana jako testowanie jednostkowe. Ostatecznym wynikiem tego kroku może być jeden lub więcej komponentów produktu, które są budowane zgodnie ze wstępnie zdefiniowanym standardem kodowania i debugowane, testowane i integrowane w celu spełnienia wymagań architektury systemu. Bez względu na wielkość zespołu, współpraca i koordynacja mają kluczowe znaczenie dla spełnienia wszystkich wymagań.
7. Testowanie : Po zintegrowaniu wszystkich opracowanych jednostek cały opracowany system jest następnie testowany pod kątem ewentualnych błędów. W tej fazie weryfikowana jest również zgodność z oczekiwaniami klienta.
8. Wdrożenie : Po zakończeniu wszystkich testów produkt lub proces jest dostarczany do klienta, wprowadzany na rynek lub wdrażany. Podczas tego procesu należy ściśle przestrzegać wszystkich obowiązujących wytycznych branżowych, przepisów i/lub wytycznych organizacyjnych. Ponadto należy przeprowadzić weryfikację i testy powdrożeniowe w celu potwierdzenia powodzenia końcowego wdrożenia.
9. Konserwacja : W przypadku zidentyfikowania jakichkolwiek problemów przez użytkownika końcowego, zespół programistów jest zobowiązany do rozwiązania, zmiany lub modyfikacji produktu w celu zapewnienia jego skuteczności. Okres utrzymywania to zazwyczaj określony i wcześniej uzgodniony okres czasu.

Diagram 2: Podstawowa reprezentacja typowego modelu wodospadu do tworzenia oprogramowania

Popularność modelu wodospadu PM

Dlaczego model wodospadu zyskał tak wszechobecną popularność pomimo próby dr. Royce'a ostrzegania ludzi przed pułapkami tego modelu?

Metodologia Waterfall jest najczęściej stosowaną metodyką do zarządzania projektami. Model ten był używany w różnych gałęziach przemysłu jeszcze zanim nadano mu nazwę „wodospad”. Główne powody popularności i powszechnego stosowania Modelu Wodospadu są następujące:

• Łatwy do zrozumienia, użytkowania i zarządzania

Większość kierowników projektów uważa, że ​​struktura Modelu Wodospadu jest łatwa do zrozumienia i wdrożenia, ponieważ jest ona zgodna z cyklem życia projektu. Ponadto nie ma potrzeby szkolenia zespołu i zapoznawania go z metodologią Waterfall. Sztywność całego procesu nie tylko ułatwia jego wdrożenie i kontrolę, ale także zmniejsza obciążenie związane z zarządzaniem projektem.

• Zdyscyplinowany

Jasno ustrukturyzowane podejście modelu wodospadu ułatwia monitorowanie, a po zakończeniu każdego etapu kierownik projektu i klient widzą widoczne postępy. Ponieważ maksymalna ilość czasu poświęcana jest na fazę wymagań i projektowania, szanse zespołu na niedotrzymanie terminu są drastycznie zmniejszone.

• Jakość i szczegółowa dokumentacja

Dokumentacja jest utrzymywana i aktualizowana od początkowych etapów. Rygorystyczny sposób aktualizacji dokumentów zapewnia pełne zrozumienie między zespołem a klientem co do tego, co zostanie dostarczone. To nie tylko ułatwia planowanie i projektowanie, ale także pomaga zainteresowanym stronom, jeśli muszą zobaczyć więcej szczegółów na temat określonej fazy.

• Minimalne zaangażowanie klienta

Model Wodospadu został zaprojektowany w taki sposób, że po jasnym zdefiniowaniu i zrozumieniu wymagania obecność klienta nie jest bezwzględnie wymagana. Odciąża to zespół i zapobiega wprowadzaniu jakichkolwiek nowych zmian w późniejszej fazie projektu, co z kolei zapewnia terminową realizację projektu.

• Departamentalizacja

Elastyczność Waterfall Model pozwala różnym członkom zespołu na zaangażowanie lub kontynuację pracy nad innymi projektami, w zależności od fazy projektu. Przy zaplanowanych terminach ustalonych dla każdego etapu rozwoju, projekt przechodzi przez proces rozwoju sekwencyjnie, uwalniając zasoby .

• Ubezpieczenie jakości

Model ten jest idealny dla projektów, których wymagania są jasno i ściśle określone i gdzie późniejsze zmiany wymagań nie byłyby możliwe. Co więcej, model wodospadu jest idealny do projektów, w których jakość produktu ma pierwszeństwo przed kwestiami czasu lub kosztów.

Dlaczego nie więcej projektów korzysta z modelu zarządzania projektami wodospadu?

Niektóre z największych zalet modelu wodospadu zmieniają się w jego wady w zależności od charakteru projektu.

Największym ograniczeniem metodologii Waterfall w projektach rozwoju oprogramowania jest to, że nie nadaje się ona do długich lub dużych projektów. Inne wady to: (6)

• Niewiele lub brak zmian lub poprawek:

Nacisk Modelu Wodospadu na jasne i dobrze zdefiniowane wymagania oznacza, że ​​po sfinalizowaniu wszelkie zmiany w wymaganiach byłyby nie tylko trudne, ale także kosztowne. Dlatego model wodospadu nie nadaje się do projektów o niejasnych wymaganiach. Oznacza to również, że każda zmiana oprogramowania i sprzętu w projektach długoterminowych byłaby trudna do rozwiązania. Oznacza to również, że za pomocą tej metody nie można rozwiązać wszelkich nieoczekiwanych wystąpień projektu.

• Późna dostawa produktu:

Ponieważ wcześniejsze etapy modelu poświęcone są zrozumieniu wymagań, tworzenie oprogramowania rozpoczyna się później w cyklu życia projektu. Oznacza to, że interesariusze nie będą mogli zobaczyć oprogramowania na późniejszym etapie cyklu życia projektu.

• Niepraktyczność zbierania dokładnych i kompletnych wymagań :

Zebranie jasnych, dobrze zdefiniowanych i kompletnych wymagań w początkowej fazie jest nie tylko trudne, ale w przypadku niektórych projektów może być również niepraktyczne. Często klienci nie mają jasnego obrazu wszystkich wymagań na wczesnym etapie cyklu życia projektu, zamiast tego uczą się i wyjaśniają wymagania w miarę postępu projektu.

Współczesne przedstawienie modelu wodospadu

Pomimo różnych wad, nowoczesny model wodospadu jest jednym z najpopularniejszych modeli cyklu życia oprogramowania (SDLC). Nowoczesna wersja modelu wodospadu zawiera pętle sprzężenia zwrotnego przez cały cykl życia projektu, w tym konserwację po dostawie.

W tym modelu testowanie nie jest odrębną fazą, lecz jest wykonywane w sposób ciągły w całym procesie tworzenia oprogramowania. Jest to szczególnie ważne na etapie konserwacji, aby zapewnić, że nie tylko oprogramowanie działa zgodnie z wymaganiami, ale także wszelkie dodatkowe wymagania zostaną uwzględnione w projekcie.

Model nowoczesnego wodospadu wyraźnie przedstawia drogę, jaką należy obrać podczas tworzenia i konserwacji, aż do wycofania oprogramowania. Nowoczesny model wodospadu usuwa wiele problemów z tradycyjnym modelem wodospadu, jednak ma swoje własne problemy. Na przykład, ukończenie każdej fazy obejmuje kompletną i jakościową dokumentację tych faz oraz zatwierdzenie przez grupę zapewnienia jakości oprogramowania (SQA) i musi to być również zrobione w przypadku jakichkolwiek modyfikacji. Naleganie na prowadzenie pełnej dokumentacji może skutkować opóźnieniami i niepotrzebną papierkową robotą.

Model przypadku użycia bankomatu ACME do wypłaty gotówki

Krótki opis:

Ten przypadek użycia opisuje, w jaki sposób Klient Banku korzysta z bankomatu, aby wypłacić pieniądze z konta bankowego.

Aktorzy:

Poniższy rysunek przedstawia wszystkich aktorów w modelu przypadków użycia ACME Super ATM.

Aktorzy to klienci, system bankowy, administrator usług i administrator bezpieczeństwa.

Warunki wstępne:

• Klient banku musi posiadać kartę bankową.
• Połączenie sieciowe z systemem bankowym musi być aktywne.
• System musi mieć przynajmniej trochę gotówki, którą można wydać.
• Musi być dostępna opcja usługi wypłaty gotówki.

Zobacz także:

5 typowych wyzwań związanych z zarządzaniem projektami i rozwiązań, aby stawić im czoła jak profesjonalista

Podstawowy przepływ:

• Włóż kartę
• Przeczytaj kartę
• Uwierzytelnij klienta
• Wybierz Wypłata
• System wyświetla różne opcje serwisowe, które są aktualnie dostępne w maszynie
• Wybierz kwotę
• System monituje o kwotę do wypłaty wyświetlając listę standardowych kwot wypłaty
• Potwierdź wypłatę
• Wykonaj ocenę funduszy pod ręką
• Przeprowadź transakcję
• Wysuń kartę
• Klient pobiera kartę bankową z automatu
• Wydaj gotówkę
• System dozuje Klientowi żądaną kwotę
• System rejestruje wpis w dzienniku transakcji do wypłaty
• Koniec przypadku użycia

Alternatywne przepływy:

Przepływy alternatywne obejmują przepływy dla następujących scenariuszy:

• Obsługa wypłaty kwoty niestandardowej
• Obsługa nieczytelnej karty bankowej
• Obsługa paragonów
• Obsługa błędów
• Obsługuj system bankowy przestając odpowiadać

Przepływy wyjątków:

Przepływy wyjątków obejmują przepływy dla następujących scenariuszy:

• Oceń fundusze w kasie
• Przeprowadź wypłatę
• Wyłączenie usługi
• Obsługa korekt transakcji

Warunki pocztowe:

• Bankomat zwrócił kartę i wydał gotówkę Klientowi, a wypłata jest rejestrowana na koncie Klienta.
• Bankomat zwrócił kartę Klientowi, a na koncie Klienta nie jest rejestrowana wypłata.
• Bankomat zwrócił kartę, ale nie dostarczył kwoty gotówki zarejestrowanej jako pobrana z rachunku Klienta; rozbieżność jest rejestrowana w logach bankomatu.
• Bankomat zachował kartę, na koncie Klienta nie zarejestrowano wypłaty, a Klient został powiadomiony, gdzie należy się skontaktować w celu uzyskania dalszych informacji.

Punkty rozszerzenia publicznego:

Nic

Specjalne wymagania

• Niezawodne wydawanie gotówki

W modelu ACME Super ATM do wypłaty gotówki wszystkie wymagania są stałe i jasno określone, dlatego model wodospadu jest idealny do tego przykładu. Po odnotowaniu wymagań od klienta wymagana była bardzo niewielka ilość informacji zwrotnych, a etapy rozwoju i projektowania można było ukończyć zgodnie z sekwencyjnym wzorcem liniowym. Projektem można łatwo zarządzać za pomocą oprogramowania do zarządzania projektami, takiego jak nTask, a każdy etap jest jasno zdefiniowany i podzielony zgodnie z wymaganiami.

Model przypadków użycia ACME Super ATM do uwierzytelniania klienta

Krótki opis:

Ten przypadek użycia służy do potwierdzenia, że ​​osoba korzystająca z bankomatu (Klient) jest upoważniona do korzystania z włożonej karty bankowej oraz że konto powiązane z kartą bankową jest aktywne.

Aktorzy:

Aktorzy to klient, system bankowy, administrator usług i administrator bezpieczeństwa.

Warunki wstępne:

• Karta bankowa została włożona do bankomatu.
• Informacje o karcie bankowej zostały pomyślnie odczytane.
• Klient prowadzi dialog z dołączonym przypadkiem użycia.
• Utworzono identyfikator sesji bankomatu.

Podstawowy przepływ

• Sprawdź poprawność informacji o karcie
• System wysyła informacje o karcie bankowej do Systemu Bankowego
• System wysyła również identyfikator bankomatu i identyfikator sesji bankomatu do systemu bankowego
• System Bankowy potwierdza, że ​​dane karty bankowej są ważne i można z niej korzystać
• Sprawdź tożsamość użytkownika
• System poprosi Klienta o PIN
• Klient wprowadza PIN
• System sprawdza, czy wprowadzony PIN jest identyczny z PIN-em odczytanym z karty bankowej
• Zatwierdzono kod PIN
• Kończy się przypadek użycia

Alternatywne przepływy:

Przepływy alternatywne obejmują przepływy dla następujących scenariuszy:

• Nie obsługuj komunikacji z systemem bankowym
• Brak komunikacji z bankiem klienta
• Obsługa nieaktywnej karty lub konta
• Obsługa skradzionej karty bankowej
• Obsługa nieprawidłowych informacji o karcie bankowej
• Nie wprowadzono prawidłowego kodu PIN
• Obsługa błędów
• Obsługuj system bankowy przestając odpowiadać

Przepływy wyjątków:

Przepływy wyjątków obejmują przepływy dla następujących scenariuszy:

• Oceń fundusze w kasie
• Przeprowadź wypłatę
• Wyłączenie usługi
• Obsługa korekt transakcji

Warunki pocztowe:

• Klient został upoważniony do posługiwania się kartą.
• Klientowi zabroniono korzystania z karty, a karta została skonfiskowana.
• Klientowi zakazano korzystania z karty, a karta nie została skonfiskowana.

Punkty rozszerzenia publicznego

Nic

Specjalne wymagania

Nic

W modelu przypadków użycia ACME Super ATM do uwierzytelniania klienta wszystkie wymagania są stałe i jasno określone. Rozmiar projektu jest niewielki i można go łatwo zrealizować za pomocą sztywnego procesu. Po odnotowaniu wymagań etapy rozwoju i projektowania można było zakończyć w procesie liniowym. Projektem można łatwo zarządzać za pomocą oprogramowania do zarządzania projektami, takiego jak nTask, a każdy etap jest jasno zdefiniowany i podzielony zgodnie z wymaganiami.

Zastosowanie branżowe – Departament Obrony Stanów Zjednoczonych

Powszechnie przytaczanym przykładem zastosowania metodologii Wodospadu jest metoda Departamentu Obrony Stanów Zjednoczonych. W 1985 roku Departament Obrony Stanów Zjednoczonych zastosował podejście Waterfall w DOD-STD-2167A, swoich standardach pracy z wykonawcami oprogramowania. Chociaż nie określili swojej metodologii jako „wodospadu”, Departament Obrony Stanów Zjednoczonych (DOD) nadal stosuje podstawowe zasady modelu wodospadu.

Rząd Stanów Zjednoczonych zdecydował się na Model Wodospadu, ponieważ zalety tego modelu doskonale spełniały jego wymagania. Rząd federalny nalegał na rygor inżynieryjny i produkt najwyższej jakości, zachowując jednocześnie dużą kontrolę nad produktem końcowym. To wraz z włączeniem sześciu faz - projektu wstępnego, projektu szczegółowego, kodowania i testowania jednostkowego, integracji i testowania - w połączeniu z obszerną dokumentacją, silną preferencją dla jednoprzebiegowej, sekwencyjnej metody rozwoju i ciężkim nadzorem sprawia, że ​​DOD -STD-2167 najlepszy przykład metody wodospadu.

W 1986 roku pojawiła się wersja robocza wersji A do MIL-STD 2167, która usunęła nacisk na projektowanie odgórne i zaproponowała użycie szybkiego prototypowania jako alternatywy dla wodospadu. Stało się tak, ponieważ model wodospadu był w tym czasie przedmiotem ostrej krytyki. Pomimo faktu, że DOD dystansuje się od metodologii wodospadu, rozwój i przejęcie oprogramowania federalnego USA nadal zachowuje silne podejście zorientowane na sprzęt i kaskadę.

W raporcie National Research Council z 2010 r. podkreślono, jak wiele terminologii używanej do opisywania faz rozwoju inżynieryjnego i produkcyjnego koncentruje się na elementach modelu wodospadu, takich jak wstępne przeglądy projektu i krytyczne przeglądy projektu. Ten nacisk na metodologię zarządzania projektami wodospadu może wynikać ze zwiększonego nacisku na jakość i poufność. Poszczególne fazy Modelu Wodospadu zapewniają, że nie każdy członek zespołu jest zaangażowany w cały projekt.

W 2000 roku instrukcja DOD (DODI) 5000.2 zidentyfikowała ewolucyjne przejmowanie jako preferowane podejście do przejmowania. Jednak przepisy serii 5000 pozostają zdominowane przez terminologię specyficzną dla modelu wodospadu. Wstępne przeglądy projektu (PDR) i krytyczne przeglądy projektu (CDR), znaki towarowe modelu wodospadu, są zalecane dla każdego programu.

Czy model zarządzania projektami Waterfall jest dla Ciebie?

Pomimo wielu wad i ograniczeń model wodospadu jest nadal używany. Jednak żadna metoda zarządzania projektami nie odpowiada potrzebom wszystkich firm, nawet nie wszystkie projekty obsługiwane przez tę samą firmę. Tak więc, czy jest to idealny model dla potrzeb twojego projektu, zależy od wielu czynników.

Ponieważ biznes różni się w zależności od rodzaju, wielkości, branży i wielu innych czynników, tak samo zmieniają się projekty. Zamiast szukać najlepszej metodologii, firmy powinny poznać te metodologie, ich zastosowania i zastosowania oraz zdecydować się na najlepszą dla nich metodologię zgodnie z następującymi zmiennymi:

• Cele organizacyjne
• Podstawowe wartości
• Ograniczenia projektu
• Interesariusze projektu
• Rozmiar projektu
• Koszt projektu
• Zdolność do podejmowania ryzyka
• Potrzeba elastyczności

Model Wodospadu jest stosowany przez firmy, których wymagania dotyczące produktu końcowego są stałe, ale czas i pieniądze są zmienne. Model wodospadu umożliwia kierownikom projektów wielokrotne uruchamianie tego samego projektu, aż do osiągnięcia pożądanego rezultatu. Niewiele firm uznałoby wbudowany mechanizm metodologii Waterfall do dostosowania i ponownego przemyślenia swojego podejścia, aż do osiągnięcia pożądanego optymalnego rezultatu.

Metodologia Waterfall jest idealna dla projektów o jasno zrozumianych, stałych i udokumentowanych wymaganiach, dobrze zrozumianych narzędziach technicznych, architekturach i infrastrukturze, dostępie do obszernych zasobów z wymaganą wiedzą fachową, stabilnym, dobrze zdefiniowanym produkcie i krótkim cyklu życia. Liniowe podejście Modelu Wodospadu nie pozwala na odkrycie ani jakiekolwiek zmiany w początkowych wymaganiach dotyczących produktu. Wszelkie zmiany wymagań wymagałyby powrotu projektu do etapu pierwszego i rozpoczęcia całego procesu od nowa. Może to stanowić poważny problem w wielu branżach, z których większość pracuje na ściśle określonych ramach czasowych.

Poniższa tabela jest bardzo pomocna. Spójrz.

Tabela 1: Wymagania dotyczące modelu wodospadu

Metodologia zarządzania projektami ma kluczowe znaczenie dla dzisiejszego biznesu. Używając stylu odpowiedniego dla Twojej firmy, możesz zmienić sposób, w jaki Twój zespół współpracuje, pracuje nad zadaniami i osiąga kamienie milowe projektu.

Zastosowanie w branży oprogramowania

Model Wodospadu jest szeroko stosowany w branży oprogramowania, gdy wymagania produktu są jasno określone. Według Royce’a najprostszy program można wykonać w zaledwie dwóch krokach: Analiza i Kodowanie. Jednak w przypadku programów, które są bardziej złożone, może być wymagane większe planowanie.

Pierwszym krokiem w rozwoju dowolnego oprogramowania byłoby stworzenie specyfikacji funkcjonalnej. Aby model wodospadu był skuteczny, ważne jest, aby specyfikacje te były dobrze zaplanowane i jasno określone. Wymagałoby to rozmów z ekspertami biznesowymi i zbadania procesów biznesowych, które są obecnie obsługiwane przez ręczne lub starsze systemy komputerowe, aby lepiej zrozumieć proces biznesowy.

Zobacz także : Czy JIRA jest oprogramowaniem do zarządzania projektami, które przynosi efekt przeciwny do zamierzonego na dzisiejszym rynku?

Gdy wymagania są zauważone, muszą zostać potwierdzone przez ekspertów biznesowych i klientów. Kiedy specyfikacja funkcjonalna jest sfinalizowana, ostateczna kopia wymagań jest projektowana i blokowana.

Następnie powstaje niedziałająca prototypowa aplikacja wraz z interfejsem użytkownika. Pomaga to zarówno klientowi, jak i programistom zrozumieć, jak produkt będzie działał. Po zakończeniu tego etapu rozpoczyna się tworzenie oprogramowania.

Gdy aplikacja jest kompletna i przetestowana, publikowana jest wersja beta i udostępniana do testów. Wszelkie znalezione błędy są szybko naprawiane. Gdy nie ma znaczących błędów, aplikacja może zostać uruchomiona w wersji 1.0.

Aplikacja dla przemysłu motoryzacyjnego

Branże takie jak budownictwo i produkcja stosują model wodospadu od czasu, gdy dr Royce opublikował swoją pracę w 1970 roku. Proces montażu i produkcji w przemyśle samochodowym jest sztywny i wymaga niewielkich dostosowań po utworzeniu zakładu. W ten sposób główne wymagania są omawiane i ustalane jeszcze przed uruchomieniem zakładu, a proces projektowania i produkcji jest ustalany z uwzględnieniem wymagań.

Sam proces montażu jest zgodny z szeregiem zadań, które należy wykonać, w przeciwnym razie cały proces się zawali. Dopiero po zakończeniu etapu proces może przejść do następnego etapu. Wszelkie zmiany w wymaganiach mogą wymagać całkowitego przeglądu procesu oraz dodatkowego czasu i pieniędzy.

nTask vs Waterfall w SDLC

Po ustaleniu, że model wodospadu jest modelem najbardziej odpowiadającym Twoim potrzebom, musisz rozważyć użycie opartego na chmurze systemu zarządzania projektami opartego na współpracy, takiego jak nTask. Narzędzia do współpracy, takie jak nTask, są specjalnie zaprojektowane, aby zwiększyć produktywność i wydajność Twojego zespołu, bez względu na używaną metodologię zarządzania projektami.

Za pomocą nTask możesz łatwo zarządzać projektami o różnej wielkości, przydzielać i delegować zadania, udostępniać pliki i informacje w czasie rzeczywistym oraz spełniać wszystkie potrzeby związane z zarządzaniem projektami.

Zdecydowałeś się wypróbować metodologię kaskadową? Teraz, gdy wiesz już, jak ważna jest dokumentacja w ramach tej metody, wiesz, że pierwszym krokiem jest znalezienie platformy do śledzenia wszystkich niezbędnych zadań i udostępnienia ich zespołowi.

nTask może pomóc od momentu zebrania wymagań do fazy testowania:

• Zarządzaj i jasno określaj czas trwania i zaangażowanych interesariuszy na każdym etapie.
• Zbierz, omów i udokumentuj wszystkie wymagania w czasie rzeczywistym ze wszystkimi odpowiednimi interesariuszami. Z nTask kolejny etap rozpocznie się dopiero po zakończeniu poprzedniego etapu, po którym nastąpi kompletna dokumentacja i zatwierdzenie.
• Utwórz przepływ pracy dla swojego zespołu na podstawie sfinalizowanych wymagań. nTask pozwala na jasny wgląd w postępy projektu i pozwala na przekazywanie informacji zwrotnych na temat każdego zadania na każdym etapie Modelu Wodospadu.
• nTask ułatwia współpracę i komunikację z całym zespołem lub tylko częścią zespołu.
• Tworzenie, utrzymywanie i udostępnianie pełnej dokumentacji dla każdego etapu Modelu Wodospadu jest łatwe dzięki nTask. Możesz kontrolować, kto może wyświetlać dokumentację, aby tylko istotne informacje były udostępniane członkom zespołu.

Chociaż w tym momencie nie lubimy się odcinać, jest to post dwuczęściowy. Aby uzyskać dalsze aktualizacje, dodaj tę stronę do zakładek i nie zapomnij śledzić jej po tygodniu lub dwóch. Do tej pory, jeśli masz coś do udostępnienia, możesz to zrobić w sekcji komentarzy poniżej. Alternatywnie możesz wysłać do nas e-mail na adres [email protected]. Chętnie do Ciebie oddzwonimy.

Przeczytaj także:

• 21 najlepszych darmowych aplikacji zwiększających produktywność w 2022 r
• 23 najlepsze aplikacje z listą rzeczy do zrobienia w 2022 roku do osobistego zarządzania zadaniami
• 10 niezbędnych umiejętności zarządzania projektami dla kierowników projektów w 2022 r
• Metoda Getting Things Done (GTD) i 14 najlepszych aplikacji i narzędzi GTD
• 19 najlepszych programów do śledzenia czasu, które poprawiają produktywność zespołu
• 27 najlepszych programów do zarządzania zadaniami dla startupów w 2022 r.
• 36 najlepszych darmowych aplikacji biurowych 2022
• 30 najlepszych aplikacji z listą rzeczy do zrobienia 2022 do osobistego zarządzania zadaniami
• 22 najlepsze bezpłatne narzędzia do zarządzania projektami dla zespołów zwinnych w 2022 r.
• Zarządzanie wirtualnymi zespołami: wyzwania, wskazówki i narzędzia do zarządzania wirtualnymi zespołami
• 47 najlepszych cytatów o pracy zespołowej, aby uczcić współpracę i motywację