Powszechnym błędem jest więc "zamawianie" oprogramowania metodą specyfikowania wymagań, jako wielu przypadkowo, lub nawet systematycznie, opisanych reakcji na bodźce, bez zrozumienia mechanizmu ich powstawania. Implementacja tak opisanych wymagań bardzo często jest realizowana jako bardzo rozbudowany system pokazujący co sekundę kolejny obraz tarczy zegara zamiast implementacji prostego mechanizmu zmieniającego położenie wskazówek na nieruchomej tarczy zegara. Większość znanego mi oprogramowania jest bardziej złożona niż mogła by być...
Skutek jest taki, że dostawca oprogramowania na podstawy prawne do ochrony kodu jaki dostarczył, jednak kupujący nie ma żadnych podstaw (dokumenty, projekt itp.) by chronić swoje know-how i by nie płacić za swoje własne know-how "włożone" w toku wdrożenia, do wdrażanego oprogramowania. Dlatego warto restrykcyjnie prowadzić proces analizy i projektowania, to jest umiejętnie udokumentować projekt tak, by granica pomiędzy wartościami intelektualnymi dostawcy i nabywcy oprogramowania była jasno określona. I nie jest to rola prawnika a architekta całości systemu, który musi także znać i rozumieć prawne aspekty tej architektury.
Na wstępnie należy się czytelnikowi pewne wyjaśnienie: kim jest prawnik? Słownik języka polskiego podaje: prawo 1. ?ogół przepisów i norm prawnych regulujących stosunki między ludźmi danej społeczności? 2. ?norma prawna? 3. ?nauka o prawie, studia nad prawodawstwem? 4. ?uprawnienia przysługujące komuś zgodnie z obowiązującymi przepisami? 5. ?zasada rządząca procesami przyrodniczymi i społecznymi, stanowiąca cel badań naukowych? 6. ?kierunek studiów związanych z nauką o prawie, z prawoznawstwem? Pojęcie "prawnik" jest używane generalnie w dwóch znaczeniach: (1) osoba znająca prawo w rozumieniu przepisów i norm prawnych np. danego kraju oraz (2) osoba zajmująca sie nauką jaką jest prawo, studiami…
Bardzo często spotykam się z projektami inicjowanymi przez średnie kadry kierownicze dużych firm i urzędów, często mają one pewną wspólną cechę: "nie możemy nic zmieniać w strategii organizacji ale chcemy usprawnić pracę w naszym wydziale". To z reguły bardzo cenna inicjatywa ale także dobra droga do porażki projektu. W urzędach często na granicy łamania prawa... a nie raz z jego łamaniem. Projekty w administracji publicznej mają dodatkową specyfikę: zasady ustala prawodawca a nie menedżer organizacji. Bardzo dobrze opisał to zjawisko prof. Bolesław Szafrański wskazując przyczynę wielu porażek wdrożeń w administracji.…
Niedawno pisałem (Instrukcja dla prawników...) o tym, że prawnicy to nie inżynierowie. Nie był to przytyk, a zwykłe wskazanie na fakt, że to po prostu rożne kompetencje. Problem prawa autorskiego w obszarze szeroko pojętej inżynierii jest bardzo trudny, nie jest to "wiedza humanistyczna". Podejście prawników z reguły jednak bazuje na humanistycznej wiedzy tychże. Poniżej cytat pewnego bloga: Utwór architektoniczny należy moim zdaniem zakwalifikować (albo traktować analogicznie w tej kwestii) do szeroko rozumianych dzieł plastycznych. Te ostatnie bowiem, w przeciwieństwie np. do utworów muzycznych lub wyrażonych słowem, dużo ściślej związane są…
Dwa lata temu pisałem o mikroserwisach: Obecnie mamy już dość dobrze wypracowane wzorce projektowe ale nadal jest problem ze zrozumieniem ?kiedy i jak?. Ładnie to opisał swego czasu E.Evans przy okazji wzorca DDD, Tu poprzestanę jedynie na pojęciu bounded context czyli ?granica kontekstu?. Granica ta ma podwójne znaczenie: kontekst nadaje (zmienia) znaczenia w modelu pojęciowym (bałwan w kontekście zimy to co innego niż bałwan w kontekście członków zespołu projektowego) oraz kontekst (bardzo często) wyznacza zakres projektu (inne aspekty wzorca DDD tu pominę). Pierwsza uwaga: kontekst dziedzinowy (pojęciowy) jest ważniejszy (powinien…
Jako partner merytoryczny Raportu zapraszam do lektury... PERSPEKTYWY ERP 2017Wzorem ubiegłego roku oddajemy do Państwa dyspozycji materiał stanowiący podsumowanie działań kluczowych dostawców rozwiązań wspomagających zarządzanie przedsiębiorstwem w 2016 r. oraz prezentację kierunków rozwoju oferowanych systemów ERP w roku bieżącym. Mamy nadzieję, iż zaprezentowane wypowiedzi będą dodatkowym argumentem przy wyborze partnera w działaniach zmierzających do optymalizacji i podniesienia efektywności posiadanych zasobów IT w roku 2017. Źródło: PERSPEKTYWY 2017 - ERP-view.pl - ERP, CRM, MRP, Business Intelligence, MRP
Krótki wpis o literaturze dla studentów. Te trzy pozycje, niestety chyba już tylko biblioteki i antykwariaty, polecam uczącym się. W zasadzie drobnych poprawek wymagały wybrane diagramy ale książki te są napisane przez programistów, wiec ich treść ma uzasadnienie i książki te bronią się. Same. Są to: Martin Fowler, UML w kropelce, P.Graessle, H.Baumann, P.Baumann, UML 2.0 w akcji, Joseph Schmuler, UML dla każdego. Do tego zestawu warto dodać UML i wzorce projektowe, C.Larrmana.
Kolejna książka z cyklu "ta wiedza się nie starzeje" a nie starzeje się architektura i wzorce. Tym razem: Component Software: Beyond Object-Oriented Programming (ACM Press), Clemens Szyperski, Published by Addison-Wesley Professional (1998), ISBN 10: 0201178885 ISBN 13: 9780201178883 Autor doskonale opisuje kwestie komponentów, interfejsów, polimorfizm. Zwraca uwagę na często błędne pojmowanie i używanie dziedziczenia w architekturze (!), nie raz wręcz szkodliwe. Zwraca uwagę na aspekty rynkowe koponentowej architektury. jej dużej podatności na zmiany rynkowe. Opisuje rynkowe standardy różnych dostawców, w tym Microsoft, Oracle, OMG. Najciekawsze są prognozy rynkowe, drugie wydanie (reprint) pochodzi z…
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?
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…
