Swego czasu przewalała się w środowisku IT fala głosów za "certyfikacją zawodu informatyka". Po pierwsze pojawił się kłopot z definicją kim jest ów "informatyk", po drugie pojawił się kłopot z wykazaniem korzyści dla ogółu klientów, bo korzyść dla środowiska "informatyków" (co by to słowo nie miało tu oznaczać) jest prosta: ograniczenie dostępu do zawodu czyli jego monopolizacja. Zalety w rodzaju "podniesie się jakość usług" do mnie, i nie tylko do mnie, nie przemawiają. Nie wierzy w to nikt, kto ma w praktyce do czynienia z "certyfikowanymi" specjalnościami. Certyfikat (czyli po portu zdany test) to nic innego jak "wiem jak to robić" co nie ma nic wspólnego z "umiem to zrobić". Każdy (prawie) wie jak się biega, jak się robi zdjęcia, jak się śpiewa, wie (w końcu uczą tego w szkole podstawowej i średniej) jak się pisze książki i wiersze, wie .... większość z nas wie jak siw robi większość tego co mamy wokół siebie, czy jednak potrafimy?Certyfikaty itp. to w większości przypadków żadna gwarancja a nie raz wręcz odwrotnie.
To co najczęściej wzbudza brak zaufania to teza, że można przeprowadzić analizę i projektowanie oprogramowania "na papierze". Programiści w większości uważają, że to nie możliwe (rok temu na stronach tego bloga burzliwa dyskusja z jednym z nich...). W większości przypadków podczas spotkań (konferencje, projekty itp.) z zespołami programistów słyszę: "czytamy wymagania, kodujemy od razu i tworzymy kolejne wersje aplikacji; inaczej się nie da". W przypadku szkoleń, ostatniego dnia warsztatów najczęściej słyszę: "ooo, w ciągu jednego dnia [teraz] powstał kompletny projekt dziedziny systemu [chodziło o komponent], przetestowany i oczyszczony z wątpliwości, braku logiki i niespójności, do tego łatwy w dalszym rozbudowywaniu; to co zrobiliśmy teraz na diagramach UML w ciągu dnia, jako zespół tradycyjną metodą robilibyśmy co najmniej tydzień, biorąc pod uwagę kodowanie każdego pomysłu by go dać użytkownikowi do testów". W zasadzie taki proces analizy i projektowania jest znany od lat jako [[Model Driven Architecture]] (MDA). [...] Larman w swojej książce opisuje niemalże identyczne podejście (tabela poniżej). Kluczową różnicą jest jednak źródło informacji pierwotnej. U Larman'a jest to model przypadków użycia i ich scenariusze. W porównaniu z modelem biznesowym, podlegającym testowaniu czy walidacji, całe ryzyko projektu spoczywa na jakości modelu przypadków użycia. Jeżeli powstały one jako efekt np. burzy mózgów, ankietowania pracowników zamawiającego czy tak zwanych sesji JAD (Joint Application Development) to jest bardzo prawdopodobne, że całe ryzyko złej jakości takiego modelu (a jest ono bardzo duże jak pokazuje praktyka) zostanie przeniesione na projekt.To jest właśnie problem nazywany "użytkownik nie wie czego chce". Po to się robi analizy biznesowe by w końcu wiedział. Nie zmienia to faktu, że książkę Larman'a gorąco polecam każdemu projektantowi i programiście z ambicjami na metody obiektowe i wzorce projektowe.
