Dla obecnych i potencjalnych klientów

Artykuły opisujące podejście analityczne, korzyści, metody.

Czym jest to co modelujesz w oprogramowaniu? Model dziedziny systemu jako wymaganie.

models-physcal-entity-three-spaces

zły model to złe oprogramowanie.... Duży system ERP to setki i tysiące jego przypadków użycia, nie ma sensu ich specyfikowanie podobnie jak nie ma sensu pytanie o nie przyszłych użytkowników tego systemu bo nie są w stanie ich wyliczyć. Ma jednak sens zrozumienie tego jak firma działa. Po raz kolejny posłużę się metaforą ]: grę w snookera można opisać relacjonując (zapisując) setki kolejnych partii, ale i tak nigdy nie wyspecyfikujemy nawet ułamka możliwych zagrań. Zdecydowanie lepszą metodą jest przyjrzenie się kilku partiom i wychwycenie cech bili, ich ilości, wymiarów stołu oraz reguł gry, bo to będzie zgodne nie tylko z historią odegranych partii snookera ale z każda przyszłą partią. Dlatego zamiast prowadzenia żmudnych wywiadów i tworzenie nieskutecznej listy setek szczegółowych opisów możliwego użycia oprogramowania, lepiej jest zrozumieć organizację, stworzyć jej model (dziedziny) i wyspecyfikować jakie usługi ma to oprogramowanie świadczyć użytkowników teraz (bo tak należy rozumieć pojęcie przypadku użycia systemu). Poprawny model dziedziny pozwoli także na obsługę przyszłych wymagań mimo, że nie znamy ich teraz. Podobnie jak stół bilardowy: nie zna przyszłych uderzeń ale wiemy, że na pewno zostaną...

Czytaj »

Znaczenie ma nie wielkość projektu, a cykl jego życia…

Cykl życia aplikacji

Jak zaradzić dużym kosztom utrzymania oprogramowania? Jest tylko jeden sposób: planować rentowność i czas życia każdego projektu i jego produktu. Tu warto zwrócić uwagę, że pojawia się tu ]). Aplikacje zaplanowane jako efemerydy, to produkty projektów, bez litości wyrzucać jak "zrobią swoje". Zmiana planów z ich wyrzucenia na dalszy rozwój to najczęściej krach finansowy projektu. W takich wypadkach, na bazie doświadczeń z eksploatacji efemerydy, najlepiej zaprojektować nowy system z planem na kilka lat eksploatacji. Aplikacje planowane jako narzędzia pracy na lata, bezwzględnie dobrze projektować i poprzedzać analizą biznesowa, przed ich wytwarzaniem bo wtedy mamy już do czynienia nie z projektem a z programem. Podstawowym błędem, moim zdaniem, jest traktowanie zakupu lub wytworzenia oprogramowania planowanego na "długie używanie" jako projektu programistycznego. To nie projekt, to program! Projektem jest wytworzenie pierwotnej wersji, potem projektami są kolejno wprowadzane nowe funkcjonalności lub zmiany. Całość to program.

Czytaj »

„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 »

Analityk biznesowy czyli wyplenić dwuznaczność z dokumentów analitycznych!

usuwanie dwuznaczosci i niejasnosci

"Im większa niejednoznaczność dokumentu wymagań tym większe ryzyko, że projekt będzie miał kłopoty". Powyższe nie stanowi żadnego odkrycia co nie zmienia faktu, że jakość większości dokumentów wymagań (owe 70%) jest słaba, na co wskazują sami ankietowani. Rola Kierownika Projektu to między innymi zarządzanie ryzykiem. Statystyki są nieubłagane, więc brak dobrego analityka i dobrej analizy wymagań spycha projekt w kierunku kłopotów. No to mamy kolejne badanie: Znaczenie i zapotrzebowanie na specjalistów wg. Forrestera: 70% badanych decydentów uważa, że Analityk Biznesowy to kluczowa postać w projekcie. Jednak nie dlatego, że jest ważniejszy od np. kierownika projektu, bo nie jest ważniejszy. Dlatego, że od jakości jego produktu (analiza i specyfikacja wymagań) zależy właśnie ryzyko całego projektu. Co jest wadą większości analiz biznesowych? To, że są one tak na prawdę uporządkowanym zapisem wywiadów z klientem a nie faktyczną analizą organizacji, jej potrzeb (bo raczej nie koniecznie jej pracowników!) i celów biznesowych. Jakie są treści tekstowego lub tabelarycznego zapisu wywiadów? NIEJEDNOZNACZNE! Jakie są niesformalizowane, swobodnie tworzone diagramy procesów? NIEJEDNOZNACZNE! Jakie są słowne opisy struktury oprogramowania jakie ma powstać? NIEJEDNOZNACZNE! Co zrobić? Używać już na...

Czytaj »

RACI, SIPOC i inne czyli modelowanie organizacji c.d.

RACI Chart 2

Modelując jakąkolwiek firmę jakąkolwiek notacją warto projekt modelowania uzupełnić o jego pragmatykę, to jest o specyfikację wszelkich warunków tworzenia modeli. Opracowanie takiej dokumentacji wymaga ustalenia tych zasad, a także zdefiniowania słownika, skończonej przestrzeni nazw i definicji, która pozwoli jednoznacznie zaklasyfikować każde pojęcie z życia firmy do właściwego, i tylko jednego, elementu modelu. Projekt modelowania procesów to nie jest proste rysowanie tego co się dzieje. Tak powstają najczęściej nieprzydatne i kosztowne zarazem dokumenty. Projekt modelowania procesów biznesowych to wnikliwa analiza całej organizacji, sposobu zarządzania nią i udokumentowania tego jak faktycznie powstaje w niej wartość dla klienta. Nie raz niestety odnoszę wrażenie, że w wielu projektach tego rodzaju duża wartość analizy i modeli biznesowych zostaje zastąpiona skomplikowanymi i nic nie wartymi diagramami.

Czytaj »

Kilka słów o kosztach analizy przedwdrożeniowej i prawie autorskim

Kilka słów o kosztach analizy przedwdrożeniowej i prawie autorskim

Tak więc na zakończenie zwrócę uwagę: analiza wymagań i projekt oprogramowania jest złożona, niezależnie od tego ilu użytkowników go będzie używało. Jednak koszt wdrożenia oprogramowania w firmie 10 osobowej będzie nieporównywalnie mniejszy niż w korporacji zatrudniającej 1000 osób. Tu jednak problemy leżą już gdzie indziej. Ale ktoś powie: duży ERP wymaga przewidzenia wielu ról w systemie i w związku z tym obsługi wielu etapów jakie pokonują tam dokumenty. Owszem, dlatego uważam, że należy osobno wybrać system, który wchłonie te dokumenty (np. finanse itp.) i osobno system, które je tam doprowadzi czyli "jakiś workflow". To dużo bezpieczniejsze i mniej ryzykowne. (na diagramie poniżej (dan z IBM) wdrożenie to etap instalacji i oddania do użytku. Dlatego dobrą praktyką jest raczej oddzielenie projektowania od wykonania. Zlecenie analizy i opracowania rozwiązania i przejęcie praw majątkowych do opracowania (projektu systemu) i na tej podstawie dopiero wskazanie wykonawcy daje gwarancje, że dostawca oprogramowania nie nabędzie żadnych praw do Państwa pomysłu. Daje gwarancję, że Wasz unikalny pomysł nie stanie się "modelem referencyjnym dla branży..." lub co gorsza "gotowym produktem z pudełka"...

Czytaj »

Ach ten wstrętny, wścibski analityk

Paradygmat obiektowy i procesowy, proces analizy

Cóż, zastąpienie procesu analizy i projektowania werbalną komunikacją to droga na skróty: czerwona strzałka. Czy to zła droga? Droga na skróty to wspomniane na początku ryzyko, ogromne bo statystyki wskazują stale, że ok. 70-80% projektów programistycznych ma poważne kłopoty. Statystyki te są takie same od lat. Od lat znany jest powyższy proces i mimo to zawsze jest te 80% klientów i ich dostawców, którzy dogadują się, że analiza i projektowania żadnemu z nich nie służy... tak jak to napisano na początku. Po co to napisałem? By każdy z Państwa sam, świadomie, oceniał ryzyko swoich projektów. Rezygnacja z analizy i projektowania to podjęcie pewnego ryzyka, przez klienta. Niestety rezygnacja z analizy i projektowania ze strony dewelopera to czasem dodatkowo skutek uznania, że analiza i projektowanie leży poza kompetencjami programistów (Ci obiektowo kodują) wiec wybierają jest droga na skróty.

Czytaj »

Czy wymagania opisują tylko to „co” system ma robić?

agile_d

Bardzo często tak właśnie definiuje się produkt analizy wymagań: wymagania funkcjonalne opisują to co ma system robić. W dyskusjach (ile mam ich za sobą :)) z programistami przebija się teza, że analityk specyfikuje to "co" system ma robić, a oni już załatwia sprawę tego "jak" ma to robić. W czym problem? W tym, że funkcjonalności to test rozwiązania a nie wymagania! Przypadki użycia stanowią bardzo mierne przybliżenie rzeczywistości. Tak więc dokument wymagań to nie tylko przypadki użycia. Te są raczej testem poprawności rozwiązania, czy model jest poprawny (przypominam, że przypadki użycia, poza ich scenariuszami, zawierają stan początkowy i stan końcowy akcji użytkownika). Programiści, proszę, nie udawajcie, że znacie się na zarządzaniu, marketingu, biznesie, sprzedaży, rynku, produkcji itp. bo to (poza pewnie istniejącymi wyjątkami) nie prawda, a projektowanie na zasadzie "wydaje mi się że rozumiem" to droga do porażki. System ERP można wybrać na bazie projektu na wyższym poziomie abstrakcji. Analizy firmy także polega tu na opracowaniu modeli procesów. Jednak w tym wypadku ich celem jest stworzenie raczej "modelu filozofii działania" firmy a nie projektowanie...

Czytaj »

A na grzyba nam Pan Analityk?

analiza uklad geocentryczny

Przecież analizę zrobimy sami, a jak nie - to zrobi to dostawca. Tak często rozpoczyna się tak zwana "Droga do klęski". Rzemieślnicy produkujący „przed Kopernikiem” skomplikowane i kosztowne przyrządy do określania położenia planet i gwiazd z wiadomych powodów nie byli zainteresowani upraszczaniem modelu geocentrycznego i swoich skomplikowanych przyrządów. Dlatego zapewne nie raz jeszcze usłyszę, że dobra analiza to setki stron, tysiące wymagań, miesiące pracy. Jednak dobra analiza to tylko: dziesiątki stron i wymagań, tygodnie pracy ale nie dyktafon a zaawansowane metody, takie jak formalna analiza systemowa oparta na modelach i ich testowaniu.

Czytaj »

Używam i polecam…

Business Process Designer
BPMN 2.0 Support
Conversation Diagram
Procedure Editor

Czytałem i polecam...

UML i wzorce projektowe. Analiza i projektowanie obiektowe oraz iteracyjny model wytwarzania aplikacji. Wydanie III
kup teraz

Bestsellery Helion'a

Podręcznik projektantów LOGO. Smashing Magazine
kup teraz

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