Temat: A ja się dziwię programistom, przepraszam Was...
Jak architektura może się ‘zachowywać’ ?
Architektura systemu to nie tylko infrastruktura. Sam system informatyczny składa się z komponentów i warstw.
Pisząc 'architektura' mam na myśli przede wszystkim organizację (warstwy, interfejsy, przepływy) kodu.
W ramach warstwy występują połączenia pomiędzy komponentami, a warstwy komunikują się między sobą. Tu również stabilność pojedynczych komponentu z osobna nie daje gwarancji stabilności całej architektury.
Czy 'tak po prostu jest i nic na to nie poradzimy' czy może taka sytuacja jest winą złych testów lub kodu ?
Ja myślałem, że 'oddzielne' warstwy projektuje się właśnie po to, żeby ich współpraca była 'stabilna'.
Jak należy tworzyć testy kolejnych warstw kodu ?
Ja uważam, że nie zależy nam na stabilności totalnej. Chcemy tylko, żeby nasz kod przechodził testy 'biznesowe'.
Zwalamy odpowiedzialność na klienta / analityka... :)
Po to właśnie modeluje się architekturę systemu (raczej wizualnie), by wszystkie powiązania i połączenia prześledzić.
Ale co daje prześledzenie kresek i strzałek na diagramie (zakładam, że UML) ?
http://en.wikipedia.org/wiki/Model_checking
Większość modeli może weryfikować 'maszynowo / automatycznie' pod względem spójności i kompletności.
Oczywiście tylko pod warunkiem, że istnieje jego formalna specyfikacja.
Z tego co widzę, to ten model i jego narzędzia są zbudowane, by testować integrację systemu.
można wszystko weryfikować pod warunkiem że się to formalnie opisze.
Mamy zaimplementowany system wedle zaprojektowanego modelu i automatycznie testujemy wszystkie stany systemu.
... sprawdzamy, czy istnieje ciąg wywołań funkcji biznesowych, który wprowadzi system w 'stan niedozwolony'. (np. w systemie do obsługi biblioteki pojawi się książka której nie można wypożyczyć).
Pytanie moje jest cały czas takie same: jak zweryfikować, czy system jest tym, co użytkownik chciał?
Klient wraz z analitykiem powinni zaprojektować testy tego systemu. Jeśli system przechodzi testy to znaczy że jest tym, co chciał klient (i analityk ;).
To co tu opisujesz, z pewnością jest zasadne, gdy klient ma swój ośrodek kompetencji analitycznych.
Może takie analizy u kogoś zamówić... Nie musi robić tego sam.
Ale wtedy jedynie przenosimy to ryzyko z siebie na klienta.
I tak właśnie powinno być. To klient, a nie 'my', powinien ponosić konsekwencje 'głupich funkcjonalności'.
Patrząc na przedsięwzięcie całościowo, nadal mamy analityka (wyoutsource'owanego), którego model sprawdzamy, a nie wymagania słowno-ustne klienta.
Sprawdzenie modelu jest zadaniem wyoutsource'owanego analityka a nie 'naszym'.
'My' dostajemy (wg. mojej metody) warstwę logiki biznesowej systemu i naszym zadaniem jest osadzenie jej w jakiejś technologii.
Mam nadzieję, że kiedyś ‘akceptacja klienta’ będzie polegać na weryfikacji modelu analityka i wywołaniu na nim testów. IMHO wszystkim zaangażowanym w projekt powinno na tym zależeć... ale to tylko tak na marginesie
Tu trzeba pokonać opór klienta przed technikalicznym myśleniem (nie wiem skąd się wzięło słowo technikalia, ale często występuje) ;)
Pewnie jest on większy niż opór przed zawaleniem projektu ;)
Dla klienta zmieni się tylko to, że będzie musiał odpowiedzieć analitykowi na większą ilość pytań.
GUI nie jest do tego potrzebne.. architektura systemu tym bardziej.
Jeśli projektant ma: interface serwisu (fasadę), typy (klasy) parametrów to czego więcej potrzebuje do stworzenia GUI które będzie wywoływać metody z serwisu przekazując do nich parametry z kontrolek ?
Czy projektant GUI musi znać interface warstwy DAL?
Każdy system ma architekturę, chyba że jest jedna klasa (program), jeśli dodamy do tego jedną tabelę w bazie, dostaniemy już typową (chociaż ułomną) architekturę. Kiedyś odbyłem podobną rozmowę, ktoś mi próbował wmówić, że jego system nie ma żadnej architektury.
No i pewnie tak było. ;)
Architektura to sposób organizacji kodu.
Architektura to powiązania elementów systemu. Czyli co? Nie ma elementów czy elementy nie mają powiązań?
Nie ma organizacji kodu. tzn. wszystko jest wszystkim :D
To znaczy, brak organizacji to też organizacja, tylko że niezorganizowana
IMHO takie kwestie programista / tester powinien mieć w nosie. Zadaniem programisty jest zaimplementowanie jakiejś części (warstwy) funkcjonalności. Jeśli ta funkcjonalność przechodzi zadane testy - to na tym odpowiedzialność programisty się kończy. Jeśli kolejne warstwy kodu ' nie kleją się ' to znaczy, że architekt skopał sprawę.
Oprócz programisty i architekta mamy integratora (często jest to starszy programista), jeśli integrator nie sprawdził wyniku swoje pracy, to sorry, ale to programista skopał sprawę.
Integracja warstw w mojej architekturze to jedna linijka kodu.
Ok. Poddaje się w kwestii integratora ;)
Z pewnością odpowiedzialność programisty kończy się na wyklepaniu swoje części kodu. Ale na pewno nie odpowiedzialność dostawcy. Programista, architekt, tester itp., wchodzą w skład zespołu dostawcy. Jak dostawca przetestuje integrację to jego sprawa, ale jedno jest pewne: powinien przetestować. Czy nie masz przypadkiem luki w swoim podejściu?
Pewnie są; Dla mnie najważniejsze jest to, że taka organizacja pracy będzie po prostu 'działać'.
Projektant ma informację o tym, co w tym polu będzie się znajdować (parametry funkcji biznesowych + definicje typów tych parametrów). Na tej podstawie będzie umiał dobrać typ i wygląd ‘pól tekstowych’.
A ponieważ zna się na ergonomii - elegancko rozmieści te pola na formularzu.
Klient nie burzy się, że pokazujecie najpierw coś, co zatwierdza, a potem dostaje produkt z poprzestawianymi polami?
A dlaczego pola miałyby być przestawiane ?
Metodyka odnosi się do sposobu realizacji projektu a nie do szacowania jego kosztów.
Niektóre metodyki mają w sobie wpisane modele estymacji kosztów projektu.
Te metodyki 'nie działają' także ich modele estymacji są mało użyteczne.
Poza tym, nie przewiduje problemów z tworzeniem takich estymacji dla 'mojej metodyki' - dało się dla niedziałających, można i dla działającej ;)
Jakub Wojt edytował(a) ten post dnia 30.08.11 o godzinie 08:04
пропозиції роботи
