пропозиції роботи
Wypowiedzi
-
Jako absolwent - również wystawiam 5 dziekanatowi za posatwę "prostudencką".
-
Ja ze swojej strony mogę dorzucić: "UML 2.0 w akcji - przewodnik oparty na projektach", Helion (P. Graessle, H. Baumann, P. Baumann)- uważam że dosyć ciekawa pozycja opisująca nie sam język (nie jest podręcznikiem) ale w jaki sposób można modelować - godna polecenia na początek zabawy z UML-em.
Druga to: "Język UML 2.0 w modelowaniu systemów informatycznych", Helion (S. Wrycza, B. Marcinkowski, K. Wyrzykowski)- jako uzupełnienie do pozycji wyżej wymienionej.
Przychylam się do opini kolegi bez analizy obiektowej ani rusz - polecam więc książke - "Analiza obiektowa i projektowanie", WNT (E. Yourdon, C.Argila) -
A moge wiedziec w jakiej cenie ?
-
[author]Jarosław
-
Dodam jeszcze jedno - żeby stworzyć poprawny projekt niskopoziomowy (zwany często perpesktywą wewnętrzną) niezbędna jest wiedza programistyczna. Projektant nie jest w stanie stworzyć diagramu klas nie mając pojęcia czym jest klasa.
-
Po pierwsze - nie ma co się łudzić - cudowne automaty nie zrobią wszystkiego za programistę. Tak jak przy wielu innych dziedzinach nic nie zastąpi myślenia. A pamietajmy, że proces wytwarzania oprogramowania to proces niesamowicie twórczy. Oczywiście możemy i powinnniśmy automatyzować pewne procesy - generatory kodu umożliwiają np. stworzyć, spójny, zwięzły i bardziej przejrzysty szkielet kodu. Ale nie wierze, że uda się tak zautomatyzować proces tworzenia oprogramowania ażeby wyeliminować z tego procesu programistów.
Po drugie - jeśli mówimy o poważnym podejściu do zagadnienia wytwarzania oprogramowania - to nie zapominajmy że tworzenie systemu to nie tylko programista - klient. To również analitycy biznesowi, analitycy systemowi, projektanci czy architekci. Niestety w naszej krajowej rzeczywistości zbyt czesto wszystkie te role skupiają sie na jednym czlowieku - programiscie. -
Jeśli chodzi o samą metodyke (ICONIX) z powodzeniem stosujemy ją w naszym projekcie. Z tym że nie nazwałbym ją zwinną (w polskiej publikacji znalazłem chyba najbardziej odpowiednią nazwę "pośrednią") - raczej zdroworozsądkową - chociażby z tego powodu, że jednak tworzy się model a co za tym idzie dokumentację. Po prostu nie ma tu zbytniej nadmiarowości. Ale uwaga - po ponad rocznym okresie pracy z metodyką - uważam, że nie będzie się nadawała dla dużych zespołów projektowych.
-
W wersji 2.0 pojawiły się diagramy klas analitycznych (Robustness Diagrams). W projekcie w którym aktualnie uczestnicze z powodzeniem stosujemy je. Choć na początku mieliśmy z nimi sporo kłopotów. Ciekawy jestem jakie macie doświadczenia czy spostrzeżenia z ta "perspektywą modelu". Zapraszam do dyskusji.
-
Jeśli mogę wtrącić swoje 5 groszy ... bo widze ze dyskusja zaczyna schodzic na personalne i kasliwe uwagi. A do tej pory byla rzeczowa. Panie Jerzy stety/niestety trudno sie nie zgodzic z argumentami Pana Jarka - ale to jest moja subiektywne odczucie wynikajace z problemow przy modelowaniu z jakimi sie do tej pory borykalem. Warto sluchac, czytac, myslec, wyciagac wnioski - nie warto tracic cennych uwag na rzecz personalnych pyskowek.
Jerzy N.:
Panie Jarku,
czy mógłby Pan wymienić jakikolwiek system informatyczny, w tworzeniu którego brał Pan udział ?
Moje pytanie wynika z tego, że z Pańskich uwag wnioskuję, że jest Pan jak ten łoś z tego tak popularnego kawału wśród konsultantów.
Dołącz do GoldenLine
Oferty pracy
Sprawdź aktualne oferty pracy
Aplikuj w łatwy sposób
Aplikuj jednym kliknięciem
