Temat: Analityk IT vs Projektant IT
Ten temat jest popularny na kilku grupach, niemniej jednak postaram się podsumować moje spojrzenie na ten temat. Osobiście reprezentuję stronę wykonawcy - tzn. zajmujemy się realizacją dedykowanych systemów IT.
Proces wytwarzania oprogramowania w naszej organizacji czerpie najwięcej z podejścia nazywanego przez Craiga Larmana "zwinnym podejściem do Unified Process". Zwinność tą odnajdujemy jednak w adaptacyjnej analizie i modelowaniu wymagań oraz iteracyjnym cyklu życia nie zaś w tzw. "kodowaniu ad hoc".
Odwołując się do zaleceń OMG najbardziej zasadną metodą tworzenia systemu jest wykonywanie kolejnych modeli czyli - świat rzeczywisty -> CIM -> PIM -> PSM -> implementacja systemu. Życie jednak zmusza nas zwykle do poszukiwania drogi na skróty - jak każda wiąże się ona z pewnym ryzykiem, a motywacją jej podjęcia jest próba oszczędności (czasu i/lub budżetu, najchętniej bez straty na jakości). W związku z powyższym zwykle powstają nie 4, a 2, fragmentami 3 modele.
Model wymagań - który odpowiada na pytanie co ma być wykonane?
Oprogramowanie wraz z elementami projektu obiektowego - które realizuje jak (projekt) dla nietrywialnych elementów oraz kod aplikacji.
Ponieważ pracujemy zarówno jako wykonawcy projektów "od A do Z" jak jako podwykonawcy w większych projektach spotykamy się z dokumentacją wymagań na bardzo różnym poziomie. Idealna sytuacja to dostarczenie kompletu CIM i PIM jako wymagań - czyli najchętniej
- kontekst biznesowy (BMM)
- model procesów (BPMN)
- model dziedziny, przypadków użycia wraz z diagramami sekwencji i stanów dla nietrywialnych elementów systemu
Przy takiej konstrukcji wymagań w zasadzie od razu może powstawać kod aplikacji - wyłącznie dla wyjątkowo specyficznych części wykonujemy wtedy szczegółowe projektowanie - ponieważ nasi inżynierowie znają dobrze zarówno wzorce projektowe, jak frameworki z których korzystamy i szczegółowy projekt praktycznie nic nie wnosi. Niestety taka sytuacja zdarza się niezwykle żadko - praktycznie nigdy.
Dlatego zwykle potrzebne są kompetencje z zakresu analizy po naszej stronie. Nawet jeśli otrzymujemy "jakieś przypadki użycia" - wykonujemy własną dokumentację analizy, która jest weryfikowana ze sponsorem projektu - to dobry sposób na sprawdzenie, czy dobrze się rozumiemy. Dodatkowo - ponieważ dzisiaj bardzo duża część wymagań nie tyle dotyczy realizacji założeń biznesowych co interfejsów - wykonujemy ich prototypy - które są testowane z klientem w trakcie kodowania architektury systemu i backendu.
W ostatnim roku rozdzieliliśmy zupełnie interfejsy od backendu - również technologicznie - i ta decyzja była bardzo trafiona. Pozwoliła zrównoleglić prace, w gratisie powstaje zawsze system gotowy do wszelkich integracji, a same interfejsy ponieważ trafiły w ręce specjalistów od UX/UI są dużo bardziej efektywne.
Wracając do problemu Analityk IT vs Projektant IT - wystarczy spojrzeć na wykres zaangarzowania poszczególnych kompetencji w procesie RUP, aby zobaczyć, że pewne role oraz modele posiadają części wspólne - to specyfika projektu oraz kompetencje zespołów zleceniodawcy i wykonawcy odpowiada na pytanie gdzie jest stosowna granica wyznaczająca zakres i szczegółowość dokumentacji wymagań, pracy analityka, projektanta czy developera.
I tutaj pojawia się właśnie kluczowa sprawa - doświadczenie - to ono pozwala skutecznie prowadzić projekt. Przypomniał mi się pewien wiersz Norwida "Za wstęp (ogólniki)"
1
Gdy z wiosną życia duch Artysta
Poi się jej tchem jak motyle,
Wolno mu mówić tylko tyle:
"Ziemia jest krągła -- jest kulista!"
2
Lecz gdy późniejszych chłodów dreszcze
Drzewem wzruszą -- i kwiatki zlecą --
Wtedy dodawać trzeba jeszcze:
"U biegunów -- spłaszczona nieco..."
3
Ponad wszystkie wasze uroki --
Ty! poezjo, i ty, wymowo --
Jeden wiecznie będzie wysoki:
* * * * * * * * * * * * * * * *
Odpowiednie dać rzeczy słowo!
Mateusz Kurleto edytował(a) ten post dnia 21.06.12 o godzinie 10:19
пропозиції роботи
