Model to mechanizm

Wstęp

Niedawno pisałem o regułach biznesowych i politykach postępowania w zarządzaniu:

…zamiast brać na siebie, jako prezes firmy, menedżer średniego szczebla itd. ogrom zdarzeń w postaci podejmowania decyzji za każdym razem, gdy jest taka wymagana, można stworzyć system polityk, zestawów reguł biznesowych, skutkiem czego firma będzie sprawnie funkcjonowała nie angażując, nawet do bardzo trywialnych zadań, wysokich rangą pracowników. Nie jest to delegowanie uprawnień, polityki i reguły biznesowe to rodzaj z góry podjętych decyzji. Owszem żadnej firmy nie da się zalgorytmizować, dlatego zawsze wyższe kadry będą potrzebne jednak ich kluczową rolą jest ustalanie zasad i zarządzanie nimi a bezpośrednie reagowanie powinno dotyczyć tego ?niezalgorytmizowanego? zakresu zdarzeń (op. 20% :), reguła Pareto). Zarządzanie zorientowane na reguły biznesowe to właśnie takie podejście: to czego można się spodziewać, opisujemy regułami, zdarzenia wyjątkowe obsługujemy osobiście. Reguły biznesowe warto zebrać w jedno miejsce, ?wyjąć? je z przerośniętych opisów zakresów obowiązków i kompetencji, uporządkować zarządzenia zarządu. (Reguły biznesowe i polityki jako mechanizm działania organizacji | | Jarosław Żeliński IT-Consulting)

W powyższym cytacie wytłuściłem klucz dzisiejszego wpisu: mechanizm (ale nie ma tego słowa w powyższym cytacie).

(więcej…)

Czytaj dalejModel to mechanizm

Wynagrodzenia i podatki, analiza systemowa

Wprowadzenie Temat wynagrodzeń i ich wysokości regularnie wraca do debaty publicznej. Dyskutowane są w przestrzeni publicznej wysokości wynagrodzeń, podatków, ustawowe wynagrodzenia minimalne itp. W artykule tym starałem się pokazać systemowe, oparte na faktach i dostępnych badaniach, podejście do tego tematu. Starałem się podać możliwe wyjaśnienie tego jakie to powinny być (mogły by być) kwoty, i dodać od siebie głos do tej debaty publicznej. Metoda W analizie tej bazuję tu na pojęciu wykonalności i idealizacji jako metody . W artykule na temat studium wykonalności pisałem: Studium wykonalności to analiza możliwości wykonania czegoś.…

Czytaj dalejWynagrodzenia i podatki, analiza systemowa

ECM i EOD czyli od mody do realiów

Obydwa te, spotykane często w prasie, skróty mają wiele wspólnego: oznaczają aplikacje zarządzające obiegiem informacji i jej magazynowaniem (ECM - Electronic Content Management czyli zarządzanie treścią w postaci elektronicznej oraz EOD - Elektroniczny Obieg Dokumentów). Cechą zawartą "nie wprost" w tych nazwach  jest zarządzanie także składowaniem i przepływem tej informacji. Osiem lat temu pisałem o kwestiach pojęciowych (czym jest wiedza, jej przetwarzanie, czym są dane): Problematyka informacji w firmach, jej kolekcjonowania i przetwarzania jest częstym tematem artykułów w prasie specjalistycznej jak i opisem zakresów projektów IT. Termin ten jest jednak…

Czytaj dalejECM i EOD czyli od mody do realiów

Documenting Software Architectures

Kolejna książka, tym razem coś w rodzaju podręcznika, zbioru metod. Jest to praca zbiorowa. Polecam wszystkim osobom, których rolą jest między innymi dokumentowanie architektury systemów IT. Wiele przykładów opartych o UML, SysML oraz planowany do upowszechnienia AADL (Architecture Analysis and Design Language). Ten ostatni jest w sferze planów, zobaczymy… (więcej…)

Czytaj dalejDocumenting Software Architectures

Visual Paradigm 13.0 Opublikowany

Narzędzie, którego używam od 2005 roku (rezygnując wtedy z MS Visio bo toporny i wyrzucając demo EA SPARX bo toporny i niezgodny z UML), staje się coraz lepsze. To co powoduje, że nadal nie planuję zmieniać narzędzia to mega ergonomia pracy, 100% zgodności ze specyfikacjami OMG, a przede wszystkim serwer pracy grupowej VPository, co razem daje mega platformę analityczno-komunikacyjną dla analityka i klienta.

W nowej wersji:

(więcej…)

Czytaj dalejVisual Paradigm 13.0 Opublikowany

ICONIX and Use Case Driven Object Modeling with UML

Tym razem recenzje dwóch książek w jednym wpisie:

  1. Agile Development with ICONIX Process. People, Process, and Pragmatism. By Doug Rosenberg , Mark Collins-Cope, Matt Stephens
  2. Use Case Driven Object Modeling with UML. Theory and Practice. 2nd Edition. By Doug Rosenberg , Matt Stephens

Pierwsza wydana w 2005 roku, druga 2013 r. Pierwsza metodę ICONIX opisuje na przykładach, w kontekście zwinnych metod, proces projektowania i tworzenia oprogramowania bazujący na modelach. Są to:

  1. Model przypadków użycia specyfikujący wymagane zachowania aplikacji.
  2. Dziedzinowy model pojęciowy
  3. Model dziedziny (architektura).
  4. “Robustness diagram” abstrakcyjny model zachowania bazujący na jednoznacznych tylko biznesowych pojęciach (diagram komunikacji).
  5. Diagram sekwencji obrazujący zachowania się elementów architektury systemu w toku realizacji scenariuszy przypadków użycia.
(więcej…)

Czytaj dalejICONIX and Use Case Driven Object Modeling with UML

Kopia treści czy dokumentu czyli co?

Niemalże w każdym projekcie spotykam się z dokumentami w różnych formach. Bardzo często spotykam się także z problemami związanymi z ich użyciem w “realu” i ich reprezentacją zarówno w dokumentacji papierowej jak i elektronicznej. Samo pojęcie “dokument” potrafi być trudne do jednoznacznej interpretacji. Najpierw jednak proszę przeczytać ten niedługi artykuł na temat problemów z fotokopią Dowodu Osobistego (można przeczytać na koniec, po przeczytaniu tego wpisu).

Jeśli sądy uznają za zgodne z prawem wykonywanie kserokopii dokumentów tożsamości, to być może należałoby zmienić przepisy ? to odpowiedź Generalnego Inspektora Ochrony Danych Osobowych (GIODO) na praktykę stosowaną przez dużą część przedsiębiorców zawierających umowy z konsumentami. (Źródło: GIODO ukróci kserowanie dowodów osobistych. Trzeba zmienić przepisy – Prawo i wymiar sprawiedliwości – GazetaPrawna.pl – wiadomości, notowania, kursy, praca, emerytury, podatki –)

(więcej…)

Czytaj dalejKopia treści czy dokumentu czyli co?

Metodologiczny dekalog naukowca

Tak więc czytając czyjekolwiek opracowania, w szczególności analizy biznesowe i modele systemów, sprawdzajcie, czy ktoś nie umieścił tam analitycznych krasnoludków, kosmitów, dżinów itp. Takie byty na diagramach jak "aktor czas" czy "systemowy przypadek użycia", świadczą wyłącznie o tym, że autor po prostu nie poradził sobie z analizą, nie do końca odkrył istotę tego co analizował i opisał, nie zrozumiał tego co modeluje. Dodawanie nowych bytów do notacji jak najbardziej jest możliwe, ale po pierwsze należy to robić poprawienie ale potrzeba taka jest bardzo rzadka. W obszarze analizy i modelowania obecna postać BPMN wystarczy aż nadto, do modelowanie oprogramowania zorientowanego obiektowo UML tym bardziej wystarczy. Takie upstrzone "wynalazkami" dokumenty być może są atrakcyjne ale kompletnie nieprzydatne.

Czytaj dalejMetodologiczny dekalog naukowca

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”

Wymiarowanie oprogramowania

Wprowadzenie Bardzo często spotykam się z metodami wymiarowania oprogramowania, czyli mówiąc ludzkim językiem: oceny pracochłonności jego wytworzenia. Typowym argumentem za stosowaniem tych metod jest potrzeba planowania. Nie raz spotykam się z porównaniami do pomiaru powierzchni np. w budownictwie (cytat celowo ze strony stosownego stowarzyszenia): Wymiarowanie oprogramowania, ma podobne znaczenie, co wymiarowanie w innych dziedzinach inżynierii. Określa wielkość, pozwala na porównywanie różnych przedsięwzięć, szacowanie kosztów wytwarzania i lepsze planowanie. Punkty funkcyjne ? najbardziej popularna i promowana przez specjalistów jednostka wielkości oprogramowania, to przykładowo odpowiednik metrów kwadratowych w budownictwie. Wyobraźmy sobie tę…

Czytaj dalejWymiarowanie oprogramowania

Wymagania ? Zarządzanie wersjami

Pomijając ich warianty, stosowane są dwie metody (grupy metod) dokumentowania wymagań i zarządzania nimi. Zakładamy, że są to wymagania wobec produktu (rozwiązania) jaki ma dostarczyć jego dostawca. W BABoK (Business Analysis Body of Knowledge), wymagania te musi spełnić dostarczony produkt, jednak oczywiście rozliczany jest dostawca rozwiązania. Stosowane są trzy metody (grupy metod) specyfikowania wymagań: Specyfikacja wymagań funkcjonalnych i poza-funkcjonalnych (i warianty tej metody). Specyfikowanie tak zwanej "czarnej skrzynki" (przypadki użycia). Specyfikowanie tak zwanej "białe skrzynki" (przypadki użycia + model dziedziny systemu). Pierwsza i najstarsza metoda bazuje na założeniu, że zamawiający i…

Czytaj dalejWymagania ? Zarządzanie wersjami

Koniec treści

Nie ma więcej stron do załadowania