Case Study – projekty

Przykłady prawdziwe i fikcyjne

„UML Process” czyli od biznesu do projektu logiki systemu

Proces projektowania UML

To co najczęściej wzbudza brak zaufania to teza, że można przeprowadzić analizę i projektowanie oprogramowania "na papierze". Programiści w większości uważają, że to nie możliwe (rok temu na stronach tego bloga burzliwa dyskusja z jednym z nich...). W większości przypadków podczas spotkań (konferencje, projekty itp.) z zespołami programistów słyszę: "czytamy wymagania, kodujemy od razu i tworzymy kolejne wersje aplikacji; inaczej się nie da". W przypadku szkoleń, ostatniego dnia warsztatów najczęściej słyszę: "ooo, w ciągu jednego dnia powstał kompletny projekt dziedziny systemu , przetestowany i oczyszczony z wątpliwości, braku logiki i niespójności, do tego łatwy w dalszym rozbudowywaniu; to co zrobiliśmy teraz na diagramach UML w ciągu dnia, jako zespół tradycyjną metodą robilibyśmy co najmniej tydzień, biorąc pod uwagę kodowanie każdego pomysłu by go dać użytkownikowi do testów". W zasadzie taki proces analizy i projektowania jest znany od lat jako ] (MDA). Larman w swojej książce opisuje niemalże identyczne podejście (tabela poniżej). Kluczową różnicą jest jednak źródło informacji pierwotnej. U Larman'a jest to model przypadków użycia i ich scenariusze. W porównaniu...

Czytaj »

Analiza biznesowa – skuteczne modelowanie a ryzyko projektu

Analiza biznesowa – skuteczne modelowanie a ryzyko projektu

Stosowanie opisanych tu formalizmów to uznanie, że dobre i sprawdzone standardy pozwalają zminimalizować ryzyko projektów analitycznych. Analiza to nie zbieranie danych o firmie i ich sortowanie, bo czy to nie brzmi jak ekologiczne zbieranie śmieci? Analiza to porządkowanie zebranej wiedzy o organizacji, korzystając z wypracowanych systemów pojęciowych, czyli przyporządkowywanie wszystkiego co wiemy do skończonej liczby pojęć, oraz uzupełnianie lub naprawianie wszystkiego czego zabranie w tak opracowanym modelu. Kluczem dobrej analizy jest uogólnianie czyli wychwytywanie rzeczy istotnych oraz odsiewanie informacji zbędnych, nie mających wpływu na cel projektu a zaciemniających go. Analiza to odkrywanie i rozumienie reguł, panowanie nad złożonością organizacji. Większość projektów takich jak np. wdrażanie nowych metod kontrolingu, zrównoważonej karty wyników, nowych systemów IT itp. cierpi głównie z powodu posiadania nadmiaru informacji z jednej strony i kompletnego jej niezrozumienia z drugiej. Sławne już w badaniach "złe i niekompletne wymagania" czy "zmiany zakresu projektu w trakcie jego trwania" to klasyczne skutki złej (a często pomijania!) analizy biznesowej. Koszty tych porażek wielokrotnie przewyższają koszt takich analiz.

Czytaj »

Czas nie jest aktorem dla Systemu c.d. czyli projekt

Przypadki użycia

Jak widać troszkę się, mam nadzieję, uporządkowało i mamy następujące wnioski: czas nie jest żadnym aktorem, aktorem jest beneficjent systemu, ktoś kto z niego korzysta lub z nim współpracuje, parametry takie jak godzina alarmu i czas jego trwania to nie aktor, a treść danych wprowadzanych do systemu (np. formularz konfiguracji alarmu), opracowanie samej specyfikacji wymagań funkcjonalnych absolutnie nie determinuje projektu, czyli tego co nam programiści dostarczą (a może to być kosztowne lub nie, ale to wynika z projektu), jedynym sposobem dokładnego postawienia zadania programistom (developerowi) jest opracowanie projektu tego co ma powstać (jego logiki), jest to już nie specyfikacja wymagań a specyfikacja systemu (albo jak kto woli, wymaganie jest projektem), nie liczcie na to, że dostawca zrobi wszystko by to kosztowało jak najmniej... (patrz druga wersja projektu, jest tańszy w wykonaniu), jakiekolwiek wymagania powiązane z czasem (programator) to co najwyżej parametry czasowe usług świadczonych przez system (to czego użytkownik oczekuje od systemu), jeżeli ktoś umieszcza na diagramie UC aktora Czas to najprawdopodobniej nie rozumie implementacji albo ukrywa ją, lub odkłada implementację, to znaczy, że odsuwa jedną z najważniejszych decyzji projektowych (koszty!) na później, zaletą...

Czytaj »

Audyt organizacji czy analiza?

Okladka_audyt

Bardzo często jestem pytany o to czy mogę wysłać jakiś przykładowy dokument. Jest to trudne pytanie bo projekty to zawsze tajemnica firmy, o czym chyba zapominają firmy doradcze i wdrożeniowe handlujące "modelami referencyjnymi, branżowymi" itp. W kuluarach konferencji nie raz słyszę, że niektóre firmy świadomie szukają dostawcy, który zna ich branże (czytaj konkurencje) z nadzieją, że wraz z usługą lub systemem ERP, przejmą choć część know-how jednego ze swoich konkurentów. Pomyślałem jednak, że okrojony przykład efektów audytu, analizy i modelowania mogę przygotować, przynajmniej by można było go porównać z produktami innych firma IT i doradczych. Poniżej ogólny opis tego co zawiera plik.

Czytaj »

Większa elastyczność i lepsza obsługa klienta na szczycie listy życzeń użytkowników systemów ERP

Plan rozwojowy - diagram BMM

Celem diagramów nie jest tylko rysowanie obrazków, to narzędzie analizy, które zmusza do zadawania właściwych pytań, właściwym osobom. Jako, że model BMM stanowi kompletny system pojęciowy, a przy okazji także ma swoją symboliczną wersję (notacja), pozwala tworzyć nieskomplikowane diagramy i skupić się na tym co ważne a po drugie pokazać system w sposób łatwy do weryfikacji i zrozumienia. Stworzenie spójnego tekstu na podstawie takiego diagramu jest już łatwe, w drugą stronę to niestety nie działa (łatwo jest słownie opisać skomplikowaną trasę wycieczki mając plan miasta w rękach, zrobienie tego na bazie wyobraźni jest dużo trudniejsze, jednak warto posiadać mapę).

Czytaj »

Czego najbardziej brakuje systemom klasy ERP?

Czego najbardziej brakuje systemom klasy ERP?

Tak zaprojektowany system staje się systemem otwartym, pozwalającym wymienić lub dodać funkcjonalności bez ingerencji w pozostałe. I niezależnie od tego jak "uniwersalny" jest system ERP zawsze będzie gorszy od kilku dobrze dobranych ale niezależnych komponentów. Gorszy nie dlatego, że "brzydszy" ale dlatego, że będzie kulą u nogi firmy, która powinna jednak reagować na zmiany na rynku w ciągu tygodni a nie lat... Po drugie modyfikacja jakiegokolwiek oprogramowania zawsze wymaga testowania całości, tak więc im mniejsze kawałki mamy tym szybciej i taniej wprowadza się do nich zmiany bo ich oddanie do użytku po modyfikacji jest łatwiejsze i szybsze zarazem. Pamiętajmy pewną starą reklamę: "Banki od wszystkiego są do niczego"....

Czytaj »

Diagram klas – czyli „reinżynieria” analizy biznesowej c.d. model dziedziny

model-dziedziny

Nowy system informatyczny to interakcja firmy i oprogramowania, musi być traktowana łącznie jako jeden system złożony z ludzi i narzędzi w ich otoczeniu. Dlatego decyzja biznesowa o outsourcingu płatności i integracji z ERP powinna być moim zdaniem integralną częścią i produktem analizy biznesowej w projekcie informatycznym.

Czytaj »

Diagram klas – czyli „reinżynieria” analizy biznesowej

Dlaczego podnoszę pracochłonność analizy wymagań i projektuję model koncepcyjny do testów? Ano po to by błędy i niespójności odkryć teraz, bo na etapie implementacji ich usuwanie będzie nawet 100 razy droższe. Czy takie błędy są w projektach o uproszczonych analizach biznesowych (lub wręcz pominiętych?) Ci co mają takie projekty za sobą wiedzą doskonale, że są i to prawie zawsze...

Czytaj »

Kto odpowiada za bezpieczeństwo danych?

metody dostepu do danych - notacja ArchiMate

Co wiec się robi? Łamiąc zasady "podpinamy" program analityczny bezpośrednio do danych (linia przerywana program analityczny Baza Danych). Na wszelki wypadek, żeby nie wieszał się, dajemy mu największe możliwe uprawnienia (dobrze gdy tylko do odczytu) i z głowy. Efekt? Po kilku latach w dużych firmach nikt nie wie kto i do czego ma dostęp.

Czytaj »

Używam i polecam…

Enterprise Architecture Tool
Zachman Framework
Business Motivation Model
ArchiMate

Czytałem i polecam...

Bestsellery Helion'a

Wersja mobilna

QR Code - scan to visit our mobile site

Bookshelf 2.0 developed by revood.com

Follow

Get every new post on this blog delivered to your Inbox.

Join other followers:

  • RSS
  • Newsletter
  • GoldenLine
  • LinkedIn

Switch to our mobile site

Please don't print this Website

Unnecessary printing not only means unnecessary cost of paper and inks, but also avoidable environmental impact on producing and shipping these supplies. Reducing printing can make a small but a significant impact.

Instead use the PDF download option, provided on the page you tried to print.

Powered by "Unprintable Blog" for Wordpress - www.greencp.de