ICONIX jako obiektowo zorientowany, zwinny proces projektowania oprogramowania z użyciem notacji UML

Wprowadzenie "The Unified Modeling Language User Guide" autorstwa Grady'ego Boocha, Jamesa Rumbaugha i Ivara Jacobsona (Addison-Wesley, 1998) mówi nam, że "możesz wykonać 80% modelowania za pomocą 20% UML" gdzieś po stronie 400. Zaoszczędziliby branży wiele milionów (miliardów?) dolarów i przerażających przypadków paraliżu analitycznego [?], gdyby powiedzieli to we Wstępie, ale tego nie zrobili. Aby spotęgować przestępstwo, nigdy nie mówią nam, które 20% UML jest użyteczną częścią". Głównym wyróżnikiem ICONIX jest wypełnienie luki pomiędzy analizą potrzeb a implementacją. Lukę tę wypełniamy od razu modelując mechanizm realizacji przypadków użycia. Proces ten sprawia,…

Czytaj dalejICONIX jako obiektowo zorientowany, zwinny proces projektowania oprogramowania z użyciem notacji UML

Paradygmat obiektowy i Przypadki Użycia

Przypadki użycia w notacji UML1 to jedna z najstarszych metod dokumentowania wymagań i nadal budzi wiele kontrowersji w kwestii ich poprawnego użycia. Obiektowy paradygmat i pojęcie systemu Słownik j.polskiego mówi: paradygmat ?przyjęty sposób widzenia rzeczywistości w danej dziedzinie, doktrynie itp.? obiekt ?rzecz abstrakcyjna, np. cecha lub pojęcie?, ?przedmiot, który można zobaczyć lub dotknąć? system ?układ elementów mający określoną strukturę i stanowiący logicznie uporządkowaną całość?, ?zespół wielu urządzeń, dróg, przewodów itp., funkcjonujących jako całość? Ludwig von Bertalanffy w swojej Ogólnej Teorii Systemów?2? określa system: stanowiący określoną całość byt, złożony z mających interakcje elementów. Pojęciami powiązanymi są tu…

Czytaj dalejParadygmat obiektowy i Przypadki Użycia

Frameworks Introduction – czyli jak się psuje dobre ERP

Systemy zintegrowane ERP będą pewnymi zestawami gotowych funkcjonalności, zbudowanymi w oparciu o szkielety oprogramowania zaś integracja będzie bazowania nie na współdzieleniu danych a na wymianie ich pomiędzy modułami i zewnętrznymi systemami na równych prawach. Rozwój systemu w takim przypadku polega na tworzeniu nowych modułów tym środowisku a nie na modyfikacji już istniejących. Tak więc co mogę poradzić? Bardzo dokładne przyglądanie się rozdziałom oferty pod tytułem Dostosowanie systemu, Koncepcja wdrożenia oraz ile oczekiwanych przez Państwa funkcjonalności to te, których system w swej wersji standardowej nie oferuje. Powinny one być po dokładnej analizie, zaprojektowane i zaimplementowane. Jeżeli Konsultanci zaczynają negocjować rezygnację z części oczekiwań lub oferują coś podobnego w systemie, to pierwszy sygnał, że powinien ktoś im zacząć patrzeć na ręce, i nie mam tu na myśli ich przełożonego.

Czytaj dalejFrameworks Introduction – czyli jak się psuje dobre ERP

Projektowanie czegoś dla gotowego ERP nie ma sensu…czy aby na pewno?

celem dostawcy gotowego systemu ERP jest wdrożyć go bez żadnych modyfikacji bo (jej koszty) zjadają marżę dostawcy. Celem kupującego oprogramowanie ERP, jest wsparcie swoich procesów biznesowych a nie kopia cudzych. To dwa sprzeczne interesy. Silna firma wymusi na dostawcy ERP zmiany, słaba nie raz poddaje się wierząc tezom dostawcy, że nowy system uporządkuje stan ich organizacji i da przewagę nad konkurencją. Kto tu ma rację?

Czytaj dalejProjektowanie czegoś dla gotowego ERP nie ma sensu…czy aby na pewno?

Informacja to skarb, trudny w pożyciu skarb

Przetwarzanie informacji to tabele te zaś są prozą życia menedżerów :). Podczas wielu projektów związanych z kolekcjonowaniem wymagań na system IT wielokrotnie pojawiał się problem raportów i podobnych działań. Bardzo często wymagania tego typu są specyfikowane za pomocą wzorów raportów. Ma to jednak poważną wadę: zamyka lub utrudnia drogę rozwoju tej funkcjonalności (nie licząc usług płatnego definiowania kolejnych typów raportów świadczonych przez wykonawców systemów). Raporty jednak to tylko wierzchołek góry lodowej, "pod wodą" są dane i ich model czyli sposób zarządzania nimi i ich postać.

Czytaj dalejInformacja to skarb, trudny w pożyciu skarb

Centralne przetwarzania, co na najbliższe lata?

Wydaje się, że idea systemów rozproszonych ustępuje systemom centralnym od czasu gdy pojawiły się możliwości budowania ich dla środowiska graficznego (język JAVA, wielodostępny WindowsNT). Technika pisania aplikacji jaką udostępnia JAVA pozwala na tworzenie ich zarówno dla serwerów jak i dla komputerów JAVA i komputerów sieciowych. Mogą być uruchamiane z pomocą przeglądarki WWW tak więc dostępne są z dowolnego typu stanowisk pracy. Mogą być też być partycjonowane pomiędzy serwer i stanowisko pracy (część aplikacji wykonuje się na serwerze a część w postaci np. apletu na stanowisku pracy użytkownika). Tak więc system informatyczny zawsze będzie można zaprojektować do pracy w środowisku scentralizowanym i rozproszonym. O wyborze zdecydują projektanci systemu, przyzwyczajenia, konfiguracja posiadanej już sieci oraz oczywiście koszty. Który z tych czynników będzie decydujący zobaczymy.

Czytaj dalejCentralne przetwarzania, co na najbliższe lata?

Koniec treści

Nie ma więcej stron do załadowania