także analiza przedwdrożeniowa

Prawo w IT. Praktycznie i po ludzku – Krótka recenzja książki

Wprowadzenie Ukazała się książka Prawo w IT. Praktycznie i po ludzku . Jako, że profesjonalnie zajmuję się tak zwanym IT, a z prawem dotyczącym IT mam ogromne doświadczenia jako biegły (ale prawnikiem nie jestem), ta książka od razu po wydaniu wylądowała się na moim biurku. Jak tylko zacząłem czytać zapadła decyzja: napisze recenzję. Czytam bardzo dużo, ale recenzuję (tu na blogu) książki bardzo dobre lub bardzo szkodliwe. Autor książki, Szymon Ciach (profil LinkedIn: "Attorney-at-law | Counsel @Osborne Clarke Poland | IT & Data".), profil na Cybergov.pl: Patron medialny książki ITwiz.…

Czytaj dalejPrawo w IT. Praktycznie i po ludzku – Krótka recenzja książki

Diagram Przypadków Użycia UML

Wprowadzenie Jest to diagram, który na równi z Diagramem Klas, budzi bardzo często ogromne problemy interpretacyjne (patrz: Diagram klas...). Bardzo wielu autorów przypisuje temu diagramowi role, których on nie pełni, a nie raz prezentowane w sieci i literaturze przykłady są niepoprawne. Znakomita większość autorów tych diagramów używa ich jako "zbioru możliwych kliknięć" co jest całkowitym niezrozumieniem celu użycia i idei tego diagramu. Nawet jeżeli ktoś potrzebuje takiej mapy klikania, to są do tego lepszych narzędzia i metody (przykład: Mapa ekranów aplikacji ? podstawa dobrego UX/UI design). Tworzenie niezgodnych z notacją…

Czytaj dalejDiagram Przypadków Użycia UML

Odpowiedzialność projektanta systemu

Wstęp

prawie 10 lat temu pisałem:

Często spo­ty­kam się z róż­ny­mi meto­da­mi uwzględ­nia­nia pra­wa w doku­men­ta­cji wyma­gań. Jakim wyma­ga­niem jest zgod­ność z obo­wią­zu­ją­cym pra­wem? I trud­niej­sze pyta­nie: czy zmia­na pra­wa to zmia­na wyma­gań? Inny aspekt pro­ble­mu to ana­li­za i defi­ni­cja (opis) tej zgod­no­ści z pra­wem. Spotkać moż­na się z meto­dą pole­ga­ją­cą na trak­to­wa­niu każ­de­go (mają­ce­go wpływ na sys­tem) para­gra­fu np. usta­wy jako wyma­ga­nia. Problem zgod­no­ści opro­gra­mo­wa­nia z pra­wem ma dwa aspekty. Zgodność opro­gra­mo­wa­nia z pra­wem pole­ga na tym, że ??opro­gra­mo­wa­nie nie może ogra­ni­czać sto­so­wa­nia pra­wa to jest nie może  wymu­szać swo­imi ogra­ni­cze­nia­mi dzia­łań nie­zgod­nych z prawem?. Ja oso­bi­ście reko­men­du­ję roz­cią­gnię­cie tej defi­ni­cji na ??ani nie powin­no pozwa­lać na łama­nie pra­wa?.  Tu jed­nak wie­lu uwa­ża, że ??zama­wiam narzę­dzie i uży­wam jak chcę, na swo­ja odpo­wie­dzial­ność?. Coś w tym jest, war­to jed­nak zosta­wić ??włącz­nik?.  (źr.: Prawo a wymagania … )

Dzisiaj czytam:

To administrator odpowiada za zabezpieczenia systemów, a więc także za to, że pracownik zdołał skopiować dane osobowe na zewnętrzny nośnik. […] W ocenie WSA w toku postępowania PUODO prawidłowo ustalił, iż w SGGW dopuszczono się licznych uchybień, w szczególności nie przeprowadzono właściwej analizy ryzyka i oceny zagrożeń już na etapie projektowania systemów (privacy by design) oraz nie wdrożono odpowiednich środków zapewniających bezpieczeństwo danych, w tym przed możliwością wyeksportowania danych z systemu na zewnątrz.(źr.: Odpowiedzialność administratora za naruszenie zasady privacy by design)

Rzecz w tym, że administrator, w rozumieniu prawa, to także podmiot zlecający powstanie oprogramowania, które go wspiera w realizacji jego obowiązków, a jednym z tych obowiązków jest egzekwowanie ustalonych zasad. Dzisiaj o tym, że zbieranie “podpisów pod oświadczeniami” to nie jest bezpieczeństwo.

(więcej…)

Czytaj dalejOdpowiedzialność projektanta systemu

Sam dostarczyłem sznur, na którym próbowano mnie powiesić

  Wpadł mi właśnie przed oczy ciekawy wpis na pewnym blogu: Historia o tym w jaki sposób prawie straciłem firmę i sam dostarczyłem (bo nawet nie sprzedałem) sznur, na którym próbowano mnie powiesić. [1] Zanim przejdę do sedna, przypomnę jeden z moich artykułów: Na czym więc polega skuteczne zarządzanie? Na zrozumieniu, posiadaniu planu działania i przemyślanym tworzeniu ograniczeń. Robi tak każda większa firma: powstają zakresy obowiązków, wewnętrzne zarządzenia i procedury. To wszystko to nic innego jak ograniczenia. Opracowanie modelu organizacji więc, to nie  tylko opisanie procesów bo te są jedynie efektem istniejących ograniczeń. Pełny model organizacji,…

Czytaj dalejSam dostarczyłem sznur, na którym próbowano mnie powiesić

MDA – Cztery produkty czyli dwa etapy: wymagania i produkt

Ten artykuł można czytać na dwa sposoby: analitycy czytają od dechy do dechy po kolei ;). Menedżerowie i tak zwany biznes czytają od razu koniec, to jest część Na zakończenie, gdy uznają, że nie wierzą w te wnioski (wyrok) to zaczynają od początku czyli czytają uzasadnienie :). Niedawno napisałem: Pomiędzy pojęciami abstrakcja i model jest pewna kluczowa różnica: abstrakcja to pojęcie zaś model to opis mechanizmu, jego konstrukcja, działanie, budowa. Prosty przykład: nazwane prostokąty na typowym diagramie struktury organizacyjnej to abstrakcje komórek organizacyjnych i osób w nich zatrudnionych, prostokąty te…

Czytaj dalejMDA – Cztery produkty czyli dwa etapy: wymagania i produkt
Read more about the article Produkt analizy jako twierdzenie naukowe
praca grupowa,

Produkt analizy jako twierdzenie naukowe

Znakomita większość programów zawiera ponad 10 krotnie więcej kodu niż mogła by mieć, bo programiści często implementują warianty zachowań a nie ich mechanizmy (co powoduje, że systemy te są tyleż razy droższe niż mogły by być). Prawie za każdym razem, gdy mówię (ale nie robię tego jednak zbyt często ;) ), że stosuję metody naukowe w analizie, spotykam się z zarzutem, że przesadzam. Zapewne nie ma sensu epatowanie w projektach biznesowych akademickim słownictwem, nie ma znaczenia dobór słownictwa w nazwaniu metody pracy, bo znaczenie ma skuteczność. Wprowadzenie Ludzie i ich praca…

Czytaj dalejProdukt analizy jako twierdzenie naukowe

Analiza wymagań metodą “na gotowca”

Od czasu do czasu spotykam się z analizami wymagań, powstałymi w dość spektakularny sposób. Jest to metoda zbierania wymagań "na procesy referencyjne" i nadal niestety ma wzięcie. Głównym powodem jest to, że nie wymaga żadnych umiejętności, może to zrobić każdy. W ostatnim roku spotkałem się z wynikami tego podejścia trzy razy. Wszystkie trzy spalone niestety... Dlaczego? Jednym z chyba najbardziej znanych zestawów procesów referencyjnych jest APQC. Tak piszą jego promotorzy o nim: APQC's Process Classification Framework?(PCF) is the most used process framework in the world. It creates a common language…

Czytaj dalejAnaliza wymagań metodą “na gotowca”

The Object Primer 3rd Ed: Agile Model Driven Development with UML 2 (i moje trzy grosze o UML)

Niestety i w literaturze i w materiałach szkoleniowych, czy nawet dydaktycznych na uczelniach (o zgrozo) można się spotkać z takimi "antywzorcami" jak wyżej. Jednym z najbardziej kuriozalnych jest obecnie modelowanie danych z użyciem diagramu klas, nanosząc na nie np. jeszcze klucze główne. Niestety bardzo często autorzy tych materiałów, wykładowcy i trenerzy, zamiast korzystać ze źródeł, przepisują jeden od drugiego pogłębiając marazm w tej dziedzinie, a pierwowzorem wielu tych herezji są niestety materiały publikowane przez firmę SPARX (producent oprogramowania Enterprise Architect) jak choćby mój ulubieniec: czas jako Aktor systemu

Czytaj dalejThe Object Primer 3rd Ed: Agile Model Driven Development with UML 2 (i moje trzy grosze o UML)

Dlaczego śladowanie wymagań jest istotne w projekcie?

Wymagania to niewyczerpany temat dyskusji, blogów i sporów w projektach. Ich śladowanie już rzadziej jest takim tematem, bo mało kto to robi, a to właśnie między innymi brak śladowania prowadzi do problemów w projekcie. Typowy problem to utrata panowania nad zakresem projektu, utrata panowania nad złożonością dokumentacji i ilości "wymagań" (cudzysłów celowo, później o powodach). W konsekwencji jakość całego projektu upada, zadowolenie sponsorów także (polecam krótki wpis: Why is requirements traceability important on a project?). Dlaczego? Bo skoro wymagania mają być FURPS i SMART, to jak to osiągnąć i jak skontrolować? Jak…

Czytaj dalejDlaczego śladowanie wymagań jest istotne w projekcie?

Warsztaty analityczne – czyli malowanie trawy

Jaki opis powstanie po przeprowadzeniu kilku dni warsztatów z graczami, którzy grają od lat, zasady gry znają na pamięć, bywa ze podejmują próby łamania zasad dla osiągnięcia doraźnych efektów? To będą długie, nie raz niespójne wywody. Każdą z wymienionych gier opisują jednak jednoznacznie dwa bardzo krótkie dokumenty: reguły gry oraz minimalne umiejętności i wiedza każdego z graczy. Z takim dokumentem każdy projektant oprogramowania sobie poradzi bez problemu.

Czytaj dalejWarsztaty analityczne – czyli malowanie trawy

Sekwencje a procesy

Warstwa procesów, usług aplikacyjnych/przypadków użycia i komponentów to odrębne warstwy i perspektywy. Nie mieszamy więc ani poziomów abstrakcji ani perspektyw modeli. W przeciwnym razie, ulegając sugestiom w rodzaju "ale ja chcę zobaczyć to wszystko na jednym diagramie" pchamy projekt w kierunku "utraty panowania nad złożonością"... To prosta droga do klęski projektu.

Czytaj dalejSekwencje a procesy

Process for System Architecture and Requirements Engineering

Warto tę książkę przeczytać, by poznać dobrze opisaną, spójną koncepcję analizy i modelowania systemów w rozumieniu organizacji. Dla kogoś mającego przywiązanie do analizy strukturalnej, opisany szkielet będzie zapewne dobrym narzędziem pracy. Przyznam jednak, że kojarzy mi się to z latami 90-tymi i pierwszymi narzędziami typu EJB ([[Enterprise Java Bean]]) i anemicznym modelem dziedziny.

Czytaj dalejProcess for System Architecture and Requirements Engineering

Koniec treści

Nie ma więcej stron do załadowania