Przejdź do głównej zawartości

Wdrażaj i testuj

Na czym polega model V ?  

Nie wiem czy gdzieś wcześniej o tym pisałam, ale jestem słuchaczką na studiach „ Analityk, profesjonalista na styku IT i biznesu” gdzie uczę się o swoim wymarzonym zawodzie w super wyidealizowanym środowisku akademickim😉

 W programie przewidziany został przedmiot o wdzięcznej nazwie „Role Analityka” prowadzone przez pana Jerzego Leyka (cudowny człowiek, od którego czerpie mnóstwo inspiracji). To właśnie on ciągle nam kładzie do głowy, że te wszystkie BPMNy, UMLe to jest pikuś w porównaniu do zarządzania ludźmi i próby budowania z nim poprawnych relacji, ale dziś nie o tym 😉
Na dzisiejszym wykładzie omawialiśmy planowanie podejścia analizy biznesowej z wykorzystaniem „metodyk ciężkich”, ja wcześniej spotkałam się z nazwą „metodyki tradycyjne”, ale te „ciężkie” dużo bardziej do mnie przemawiają 😉

Czym, że jest ta „ciężka metodyka” ?

A no niczym innym jak dobrze wszystkim znany wodospad, watterfall, kaskada czy jak tam chcecie ją sobie nazwać. 😉

Nastawiona jest głównie na planowanie, dokładne przewidywanie kolejnych kroków każdego przedsięwzięcia, opracowywanie poszczególnych iteracji z uwzględnieniem szczegółowego harmonogramu, zasobów i kosztów itd., itp. Takie podejście jest bliskie ludziom kultury „pogreckiej”. Planowanie jest wpisane w ludzką naturę. Tylko otworzymy jedno oko i już zaczynamy planować, pójdziemy pod prysznic, ubierzemy się, zjemy śniadanie, wypijemy kawę, łykniemy magnez, bo przecież kawa wypłukała to i owo, później wskoczymy do auta/ pociągu/autobusu/tramwaju dotrzemy do pracy, posiedzimy 8h, wyjdziemy, wsiądziemy w auto/pociąg/autobus/tramwaj, zjemy obiadokolacje, przebierzemy się, umyjemy, pójdziemy spać, ale zanim się położymy, to zaplanujemy sobie kolejny dzień i tak w kółko. Taką mamy naturę i dlatego ten model tak dobrze wpisywał się w potrzeby organizacji i zespołów.

Tylko z tym wodospadem jest taki jeden mały, tyci problem. Sprawdzenie poprawności działania funkcjonalności odbywa się dłuuuuuuuuuuugo po rozpoczęciu projektu, no bo startujemy od wymagań, zbieramy je, analizujemy, projektujemy system, implementujemy i dopiero po implementacji odbywają się testy. I jeśli wpadnie jakiś gruby błąd -a to, że wpadnie jest prawie pewne – (staram się nie używać twardych kwantyfikatorów, takich jak zawsze, na pewno, nigdy, ponieważ obarczone są sporą odpowiedzialnością, dlatego też wykorzystałam przedrostek prawie, ale nie czuje się z tym komfortowo, bo w moich projektach ZAWSZE coś się wysypało w trakcie wrzucania dużych „klocków” na proda 😉) to narazimy siebie i zespół na szereg nikomu niepotrzebnych nerwów.

Dlatego postanowiono wprowadzić model V ( uff, wreszcie do niego dotarłam)

Model V, czym jest ?


A no wg Inżynierii Wymagań jest rozwinięciem modelu kaskadowego. Rozwinięcie polega na rozróżnieniu kroków związanych z wytwarzaniem i weryfikacją, oraz wprowadzeniu zasady, że KAŻDY krok wdrożeniowy ma swój odpowiednik w kroku weryfikacji. Model V, lub ( Metodyka V ) nie jest realizowana liniowo w dół, jak to miało miejsce w Kaskadzie. Jego przebieg, sekwencja, droga wygląda jak litera V (stąd też ta jakże porywająca nazwa).

A no i V- to pierwsza litera słowa Victoria…. Tak dosadnego przesłania nie można lekceważyć! 😊





Jak interpretować powyższy diagram?
Już spieszę z wyjaśnieniami :)

Lewa gałąź pokazuje etap projektowania systemu, podobnie jak w kaskadzie startujemy od wymagań, przechodzimy przez analizę, architekturę, modelujemy poszczególne moduły i implementujemy. Normalnie w modeli kaskadowym zeszlibyśmy liniowo w dół pokazując testy modułów (komponentów), architektury, weryfikacje poprawności analizy i na koniec potwierdzilibyśmy wszystko testami akceptacyjnymi. Niemniej model V prezentuje inne podejście. Faza weryfikacji "unosi" diagram liniowo w górę, tak, aby poszczególne "klocki" testów znajdowały się na jednym poziomie z odpowiadającymi im elementami z projektowania. To ma sugerować, że każdy fragment lewej "łapki" naszego V ma swój odpowiednik na prawej "łapce". Te przejścia oczywiście działają w obie strony (co pokazują groty na obu końcach strzałek).
Np.: po zaimplementowaniu modułu systemu, sprawdzamy ten kawałek, prosimy testerów o wsparcie, oni niczym snajperzy wyszukują wszystko to co może się wywalić, wracają do developerów co należy poprawić, developerzy poprawiają, wrzucają poprawki, proszą testerów o weryfikację, tester sprawdza itd. Taki sam proces odbywa się na każdym poziomie diagramu V.

No i trzeba przyznać, że jest to dużo sensowniejsze podejście do wdrażania nowych systemów. A dlaczego ? 😉 bo jesteśmy w stanie dużo wcześniej wykryć jakieś większe „babole” przez co nie narażamy projektu na spektakularną klęskę.  Oczywiście, jak wszystko, model V nie jest idealny, wymaga przygotowania dużo większej ilości testów, wymusza wcześniejsze rozpoczęcie weryfikacji rozwiązania, za tym idą kolejne kwity, papiery przeglądy, ale wg mnie gra jest warta świeczki. Bo lepiej jest poprawić 5 małych błędów niż jednego, wielkiego faulta😊. Można śmiało uznać go za jeden z najlepszych modeli wspierających zarówno procesy opracowywania wymagań jak i zarządzania wymaganiami dla dobrze zdefiniowanych i stabilnych obszarów.


Komentarze

Popularne posty z tego bloga

Jak Pani przeprowadza analizę? Pytania rekrutacyjne na Analityka Biznesowego

Na moim ulubionym blogu o analizie znajduje się post z 99 pytaniami, które mogą pojawić się na rozmowie kwalifikacyjnej na stanowisko analityka biznesowo/systemowego.
Przejdź do pytań
Od dziś będę opracowywać pytania znajdujące się na tej liście, co w konsekwencji pozwoli mi na sporządzenie obszernego materiału, który ułatwi przygotowanie się do skomplikowanego procesu rekrutacyjnego.  
Oczywiście zdaje sobie sprawę z tego, że ile firm tyle różnych procesów i pytań kwalifikacyjnych, ale zagadnienia znajdujące się na liście „99 pytań” są na tyle uniwersalne, że można z dużym prawdopodobieństwem założyć, że część z nich zostanie użyta w trakcie rozmów wstępnych.
No to lecimy :) pytanie na dziś to 
Jak Pani przeprowadza analizę?
Pierwsze co mi się nasunęło na myśl: „To zależy” 😉 , ale żeby na tym nie kończyć, to może napiszę od czego to tak naprawdę zależy.
Ostatnio miałam przyjemność być na warsztatach Przewodnik po analizie dla zdezorientowanych- Jak właściwie zabrać się za analizę i…

Jakie znasz rodzaje diagramów UML – lista 99

Dziś post krótki ale treściwy!
Takie podobno cieszą się największym zainteresowaniem 😊
Jakie Pani zna rodzaje diagramów UML ?
No i może ktoś się zdziwi, ale wszystkich diagramów UML jest 13😉 ale oczywiście korzystanie ze wszystkich na raz często mija się z celem, bo projekt np.: nie zakładał tworzenia diagramu rozlokowania, albo wymagane były tylko diagramy przypadków użycia, klas i sekwencji.

 Ale ! ale! ale ! to nie jest do końca tak, że jak czegoś na co dzień nie używamy to jest nieistotne i mało ważne.  
Bo jeśli np.: okaże się, że w ramach dokumentacji ma powstać jakiś „rysunek” obrazujący relacje pomiędzy odpowiednimi częściami systemu to nie zaczniemy tworzyć nowego typu diagramu tylko skorzystamy z diagramu Struktur Połączonych (bo na kiego grzyba koło na nowo wymyślać). A dlaczego z niego skorzystamy ? bo wiemy, że istnieje i do tego właśnie powinien zostać użyty. A gdybyśmy o nim nigdy nie słyszeli to prawdopodobnie tworzylibyśmy nowe, nikomu niepotrzebne struktury i di…

User Stories i Przypadki Użycia na liście 99

Dziś połączymy odpowiedź do trzech pytań z listy 99 😊
Proszę napisać wymganie w formie user stories. 
Proszę zapisać wymaganie w formie przypadku użycia.
Czym są sytuacje wyjątkowe w opisie przypadków użycia ?
No to może zanim zabierzemy się za konkretną odpowiedź, musimy wiedzieć (chociaż tak pokrótce), czym jest User Stories, a czym Use Case.

User Stories (US) – inaczej historyjki użytkownika (po angielsku zawsze lepiej to brzmi), są krótką notatką z konwersacji/wywiadu na temat działania systemu. Dzięki User Stories doprecyzowujemy wymagania z rozmowy z klientem. Tylko pamiętajmy, że nie są one po to, aby szukać winnych w razie ewentualnych niedomówień i nie powinny stanowić dowodów w „kwitach” na naszych klientów 😉. [2]
User Stories mają w sposób syntetyczny opisywać warunki, jakie powinny zostać spełnione z perspektywy użytkownika i cel, w jakim ta funkcja ma zostać przygotowana.  (definicję tę znalazłam w kursie Specjalistów Analizy)[3].
Ważne jest to, aby User Stories przedsta…