Dokument a kumulacja faktów: OOAD i model dziedziny systemu

Tym razem o czymś co potrafi zabić ;) czyli czym jest dokument oraz fakt i obiekt. Czym się różni zakup kilku produktów, w tym samym sklepie, w np. godzinnych odstępach czasu, od zakupu wszystkich razem? Poza formą udokumentowania, niczym: w sklepie to samo i tyle samo zeszło ze stanu magazynu, a my wydaliśmy w obu przypadkach tyle samo pieniędzy (o promocjach później)! W pierwszym przypadku mamy kilka faktów zakupu, w drugim, jeden, ale zawsze tyle samo obiektów (produkt). Faktura (paragon) to dokument opisjący fakt, przedmiot sprzedaży jest obiektem. Tu obiektem…

Czytaj dalejDokument a kumulacja faktów: OOAD i model dziedziny systemu

V-model i iteracyjne budowanie systemów

Wprowadzenie Ten artykuł to krótki wpis o tak zwanym V-modelu. Jest to model wytwarzania oparty na pętli analizy, projektowania, testowania i przekazania do użytku. Oparty jest połączeniu dwóch cykli życia: projektowania i wytwarzania. jest stosowany w szeroko pojętej inżynierii systemów, nie koniecznie oprogramowania. W branży IT znana jego postać wygląda np. tak: V-Model is also referred to as the Verification and Validation Model. In this, each phase of SDLC must complete before the next phase starts. It follows a sequential design process the same as the waterfall model. The testing…

Czytaj dalejV-model i iteracyjne budowanie systemów

Model i dokumentowanie wdrożenia

Ten artykuł to próba przybliżenia czytelnikowi pojęcia metamodel i model. To także mała próbka tego co jest produktem nadzoru autorskiego. Nieco ponad pięć lat temu w artykule Diagram obiektów czyli bottom-up pisałem o pojęciu instancji obiektu i diagramie obiektów. Wtedy skupiłem się na jednym tylko wątku, jakim jest analiza zmierzająca do opracowania ... no właśnie, czego? Z reguły autorzy dokumentów zawierających "diagramy klas" mówią, że tworzą modele. Czy zawsze są to modele? Wprowadzenie Jednym z bardzo niedocenianych typów diagramów UML są diagram obiektów i diagram wdrożenia (który jest rodzajem diagramu…

Czytaj dalejModel i dokumentowanie wdrożenia

Kto winien porażki projektu? Zamawiający!

Wprowadzenie Od czasu do czasu jestem proszony o audyty dokumentacji projektów. Ma to miejsce, albo gdy jestem angażowany do projektu będącego kolejnym podejściem do wdrożenia, albo w sporach, także przedsądowych, między dostawcą oprogramowania i zamawiającym. Bywa, że jest to już etap pisania opinii dla sądu. Tu razem kilka spostrzeżeń z tych analiz. Na marginesie. W sporach przedsądowych i sądowych wynik ekspertyzy absolutnie nie może być "zamówiony", czego niestety często oczekują, nie raz wręcz żądają pod groźbą odmowy zapłaty za tę usługę, zamawiający takie ekspertyzy. Bywa to tym bardziej żenujące, że…

Czytaj dalejKto winien porażki projektu? Zamawiający!

Dylematy z aktorami

Wprowadzenie Pojęcie kontekstu projektu i diagram przypadków użycia jako narzędzie, nadal rodzi wiele pytań. Spowodowane jest to tym, że diagram przypadków użycia to najczęściej wykorzystywany diagram, najczęściej też "nielegalnie przeciążany" informacjami o architekturze wewnętrznej (związki 'include' i 'extend'). Jest to także najbardziej abstrakcyjny diagram w notacji UML. Postanowiłem odpowiedź "publicznie" na pytanie, które w różnych formach, często pada w projektach, na szkoleniach i w mailach do mnie kierowanych. Przykład jednego z nich: Mam pytanie, które dręczy mnie od jakiegoś czasu i teraz zmobilizowałam się by je zadać. W artykule Jarosław…

Czytaj dalejDylematy z aktorami

Generalizacja/Specjalizacja Przypadków Użycia

W artykule Ile przypadków użycia opisałem przypadki użycia jako narzędzie definiowania zakresu projektu, czyli sposób dokumentowania wymagań. Takie jego zastosowanie jest zdefiniowane w specyfikacji UML . Tym razem chcę ostrzec przed bezkrytycznym "uczeniem się" ze stron internetowych, nawet tych uznawanych powszechnie za "dobre i popularne". Sam niektóre z nich polecam, ale coraz częściej, nie całe serwisy jako takie, a tylko określone artykuły. Modernanalyst.com też do nich należy. Dziś będzie to artykuł, którego nie polecam, a opiszę go, bo autor powiela w nim dość powszechne błędy notacyjne, błędy które stały się…

Czytaj dalejGeneralizacja/Specjalizacja Przypadków Użycia

rfc2119 – Słowa kluczowe reguł

Od czasu do czasu spotykam się z zaskoczeniem, gdy mówię, że pewne słowa kluczowe w specyfikacjach są "standaryzowane". Otóż specyfikacje notacji na OMG.org mają narzucone pewne słownictwo. Przykładem niech będzie specyfikacja notacji BPMN v.2.0.2, zawiera ona taki oto rozdział : 3.2 Normative OMG UML ? OMG Unified Modeling Language (OMG UML), Superstructure, V2.1.2 - (jest już UML 2.5.) OMG MOF ? Object Management Group - Meta Object Facility (MOF) Core Specification, V2.0 https://www.omg.org/spec/MOF/2.0 RFC-2119 ? Key words for use in RFCs to Indicate Requirement Levels, S. Bradner, IETF RFC 2119,…

Czytaj dalejrfc2119 – Słowa kluczowe reguł
Read more about the article Dyrektorzy mówią Dość! Biznes wychodzi z objęć monolitycznego systemu ERP
11392158 - the great east japan earthquake

Dyrektorzy mówią Dość! Biznes wychodzi z objęć monolitycznego systemu ERP

Krótki wstęp

Od czasu do czasu są takie momenty, że świat podsuwa mi gotowe teksty do publikacji.  Każdy kto mnie zna i czyta wie, że od lat odradzam wdrażanie wielkich monolitów ERP, uzasadnienie tego z moich ust najczęściej jest jednak odbierane jako moje spekulacje (mimo, że zawsze uzasadniam swoje zdanie a przykładów nie brakuje). A o tym sądzą dyrektorzy firm?

(więcej…)

Czytaj dalejDyrektorzy mówią Dość! Biznes wychodzi z objęć monolitycznego systemu ERP

Mało który deweloper używa UMLa zgodnie ze specyfikacją…

Od czasu do czasu wpadają mi do skrzynki email “niuslettery”, które gdzieś tam czasem zamawiam, głównie z powodów poznawczych. Oto jeden z nich…

Nie jest tajemnicą, że na rynku mamy różne metody pracy i wszystkie mają swoich zwolenników i przeciwników czy może raczej krytyków. Tym razem przedmiotem “badania” był sposób opisania problemu i wnioski jakie autor wyciągnął.

(więcej…)

Czytaj dalejMało który deweloper używa UMLa zgodnie ze specyfikacją…

Urząd Zamówień Publicznych – Opinia i rekomendacje dotyczące opisu przedmiotu zamówienia

Tym razem kilka komentarzy do rekomendacji PZP. Najpierw to:  Art. 29 ust. 1 ustawy PZP nakłada na zamawiającego obowiązek opisania przedmiotu zamówienia w sposób jednoznaczny i wyczerpujący, za pomocą dostatecznie dokładnych i zrozumiałych określeń, uwzględnienia wszystkich wymagań i okoliczności mogących mieć wpływ na sporządzenie oferty. Zapis ten służy realizacji ustawowych zasad uczciwej konkurencji a co za tym idzie zasady równego dostępu do zamówienia, wyrażonych art. 7 ust. 1 ustawy Pzp. (Źródło: Urząd Zamówień Publicznych - Opinia dotycząca opisu przedmiotu zamówienia). Spotykam się z tezami, że nie można używać notacji UML, BPMN…

Czytaj dalejUrząd Zamówień Publicznych – Opinia i rekomendacje dotyczące opisu przedmiotu zamówienia

Opis Przedmiotu Zamówienia – instrukcja nie tylko dla prawników

Od lat stosuję w swoich analizach i projektach między innymi, diagramy takie jak powyższej. Pomagają one ustalić precyzyjnie wszelkie aspekty i prawne i projektowe w umowach, do czego gorąco zachęcam. Niestety wielu prawników przyjmuje za cel swojej pracy ?obudowanie? paragrafami tego czego żądają od nich w umowach, ich klienci ? dostawcy oprogramowania. Owszem firmy IT płacą prawnikom za to, że Ci chronią ich interes, ale wiele z tych umów to niestety manipulacje i korzystanie z niewiedzy nabywców oprogramowania? nie raz nieznajomość (niezrozumienie) prawa przez dostawców oprogramowania?

Czytaj dalejOpis Przedmiotu Zamówienia – instrukcja nie tylko dla prawników

Agile w PZP

Polecam lekturę ciekawej Opinii Prawnej kancelarii Maruta Wachta sp. j.. (dalej odpowiednio Opinia i Kancelaria) na temat MOŻLIWOŚCI I SPOSOBU WYKORZYSTANIA METODYKI AGILE W PROJEKTACH INFORMATYCZNYCH REALIZOWANYCH Z ZASTOSOWANIEM USTAWY ? PRAWO ZAMÓWIEŃ PUBLICZNYCH. Kluczowe pojęcia i definicje Zanim się odniosę do Opinii, najpierw klika słów na temat zwinnego realizowania projektów. Jak rzadko, posłużę się Wikipedią, gdyż pojęcie "metody zwinne" nie ma ścisłej definicji, Manifest Agile zaś jest na tyle ogólny, że nie jest możliwe użycie go jako definicji. Po drugie Wikipedia jest powszechnie przywoływana jako źródło w środowiskach związanych ze…

Czytaj dalejAgile w PZP

Koniec treści

Nie ma więcej stron do załadowania