Wielu właścicieli firm, ich zarządy, pomija ten etap w projektach z uwagi na swoje przekonanie, że ich dotychczasowe działania i chęć ich kontynuacji, nie wymagają żadnej korekty, oczekują podania na tacy opisu narzędzia, którego - jak sądzą - potrzebują. Zachowują się jak pacjenci, którzy mimo, że ostatnie badania robili wiele lat temu, nie dopuszczają myśli, że lekarz może im przepisać na gorączkę coś innego niż kolejną aspiryną. Bywa, że zbyt późno odkrywają, że tym razem to nie było kolejne przeziębienie.
Wymagania na złożone systemy, zdefiniowane jako zestaw testów są znacznie efektywniejsze i bezpieczniejsze, niż detaliczna specyfikacja prostych funkcji. Tworzenie testów wymaga jednak określenia biznesowego celu wdrożenia i zrozumienia tego jak organizacja funkcjonuje (opracowanie modeli).Praktyka pokazuje, że koszt analizy i opracowania takich testów jest znacznie niższy niż nieplanowany dodatkowy koszt projektów (średnie przekroczenie budżetu to ponad 60%).
Autor w kilku miejscach Silver sam przyznaje, że "nagina" semantykę notacji, nie licząc kilku "drobnych" nagięć (odsyłam do lektury), "poważnym" nagięciem jest praktycznie zmiana znaczenia pojęcia pool z "biznes" na "proces". Dziwi mnie to, gdyż proces to "diagram" w BPMN (definicja pojęcia proces biznesowy to pragmatyka a nie element tej notacji). Prowadzi to niezgodności z modelem współpracy. Jednak zainteresowanym proponuje jednak przeczytanie uzasadnienia w treści książki i samodzielna ocenę.
Ciekawe strony: Modeling diagrams help you understand, clarify, and communicate ideas about your code and the user requirements that your software system must support. For example, to describe and communicate user requirements, you can use Unified Modeling Language (UML) use case, activity, class, and sequence diagrams. To describe and communicate the functionality of your system, you can use UML component, class, activity, and sequence diagrams. (Developing Models for Software Design).
Rok temu pisałem o wzorcu CQRS, tamten wpis bazował głównie na artykule M.Fowlera i stanowił raczej zajawkę tematu. Teraz mam troszkę własnych doświadczeń, także w dyskusjach z programistami, i przytoczę tu moja konkluzję, nieco chyba odbiegającą od opisu M.Fowlera, którego albo nie zrozumiałem ale on uprościł swój wpis (dzięki czemu ja wtedy nie zrozumiałem). Mamy problem polegający na tym, że firma ma ogromną ofertę pewnych bardzo złożonych podzespołów, żeby nie psuć ich opisu i możliwości rozbudowy, model dziedziny odwzorowuje strukturę tych części. Jednak bardzo duża liczba użytkowników sklepu internetowego…
...analiza i specyfikowanie wymagań na systemy przepływu dokumentów czy po protu poprawy procesów biznesowych to przygotowanie firmy do zmian organizacyjnych a nie spisywanie oczekiwań pracowników z nadzieją, że dział HR nie odczuje tej zmiany. Nie zarządzamy procesami, kształtujemy je.
(źr. http://www.bptrendsassociates.com/)
Bez tej formalizacji (ścisłe stosowanie zdefiniowanych pojęć, także tych z użytej notacji) próby modelowania procesów prowadzą najczęściej do powstawania monstrualnych ilości nieczytelnych diagramów (widywałem dokumentacje, gdzie było dla jednej firmy powstałe blisko tysiąc stron! Masakra). To kompletnie nieprzydatne dokumenty.
Co jeszcze nam daje stosowanie powyższych definicji? Możliwość jednoznacznego "przejścia" (śladowanie) z modeli procesów biznesowych na modele przypadków użycia bo atomowy proces, zakwalifikowany do zakresu projektu jako wymagana usługa oprogramowania, to przypadek użycia, zaś procedura tego procesu to nic innego jak scenariusz tego przypadku użycia lub jak ktoś woli: user story. Z innej strony: jeżeli mamy wdrożona normę ISO9000, to modelując procesy biznesowe i "podpinając" do nich procedury z księgi jakości, szybko się przekonamy, czy nasze ISO to nie jest przypadkiem fikcja.
"Zrobienie zdjęcia człowiekowi odbiera mu dusze", tak przynajmniej nadal uważają przedstawiciele wielu kultur nazywanych "pierwotnymi", którzy boją się fotografów, ale to ludy pierwotne i mogą tak myśleć. Dzisiaj, jak co dzień, zaliczam przegląd prasy czyli przeglądam swoje subskrypcje RSS i co czytam: Ceną za rozwój nowych technologii komunikacyjnych nie może być handel danymi osobowymi, który jest nowoczesną formą handlu ludźmi - mówi w rozmowie z PAP Generalny Inspektor Ochrony Danych Osobowych Wojciech Wiewiórowski. Zdaniem GIODO Unia Europejska powinna w ciągu trzech lat wypracować nowe przepisy o ochronie danych osobowych, bo…
Jest dość liczna grupa ludzi uważająca, że w Internecie nie obowiązują ani prawa fizyki, ani prawa ekonomii ani nawet zdrowy rozsądek. W kwestii inżynierii oprogramowania ludzie Ci straszą świat projektów "mitycznym wodospadem" jak kiedyś dzieci straszone były Babą Jagą. [dzień po napisaniu: po dyskusji - patrz treść pod tym wpisem - a autorem cytowanego tu artykułu, doszliśmy do wniosku, że nie różnimy się zbytnio w poglądach, jednak zbytnie uproszczenie treści miało prawo wprowadzić mnie w błąd, jednak mój artykuł pozostanie w pierwotnej treści bo polemizuje głównie z pewnym mitem a…
Dwa lata temu w artykule W sądach i urzędach giną dokumenty, nie musi tak być pisałem o ginących dokumentach w urzędach i o tym jak tego unikać, podstawą był artykuł www.PortalSamorzadowy.pl gdzie pisano między innymi o zaginięciu w sądach i urzędach 321 akt spraw w 2010 roku. Osobiście uważałem i nadal uważam, że problem tkwi w niewiedzy i niechęci urzędników do stosowania instrukcji kancelaryjnej, która - w wielu urzędach - często jest dokumentem wręcz nie znanym urzędnikom, mimo, że formalnie wszyscy są z nim zaznajomieni. Potwierdza to niestety ministerstwo: MAC…
Zadano mi niedawno po raz kolejny dość trudne pytane: Czy Pan to robi lepiej od dużych firm doradczych? Po pierwsze zapytałem "co". I tu pojawił się problem. Z zamiarem napisania tego artykułu nosze się od pewnego czasu, i w końcu rosnąca częstotliwość zadawania tych pytań skłoniła mnie do tego aktu "odwagi". Ja sam zadaję to pytanie spotykanym przedstawicielom dużych firm doradczych a także w kuluarach konferencji, na których nie raz ich spotykam. Zawsze dostaję tę sama odpowiedź: Jarek, Ty i my oferujemy zupełnie inny produkt. Przekopałem się przez oferty "wielkiej…
W większości chyba firm, z powodów historycznych, niemalże każdy kierownik i dyrektor ma nieco inny próg kwotowy samodzielnej akceptacji poniesionego koszu. Zapisanie w postaci wymagań a potem implementacja, takiego systemu przepływu dokumentów kosztowych, bywa koszmarem. Koszmar ten jest bardzo kosztowny z uwagi na swoją złożoność i brak ogólnych zasad. Powoduje to, że zamiast uzyskania automatyzacji i znacznego wzrostu efektywności uzyskuje się bardzo złożony i pracochłonny (kosztowny) system zamrażający zastany stan rzeczy, jedyną korzyścią czasami bywa to, że z raportów wiemy, że to na prawdę długo trwa. A to tylko jeden aspekt opisu organizacji i wymagań na oprogramowanie.
