Wszelkie prawa zastrzeżone. Nieautoryzowane rozpowszechnianie całości lub fragmentu niniejszej publikacji w jakiejkolwiek postaci jest zabronione. Wykonywanie kopii metodą kserograficzną, fotograficzną, a także kopiowanie książki na nośniku filmowym, magnetycznym lub innym powoduje naruszenie praw autorskich niniejszej publikacji.

Wszystkie znaki występujące w tekście są zastrzeżonymi znakami firmowymi bądź towarowymi ich właścicieli.

Autor oraz Wydawnictwo HELION dołożyli wszelkich starań, by zawarte w tej książce informacje były kompletne i rzetelne. Nie biorą jednak żadnej odpowiedzialności ani za ich wykorzystanie, ani za związane z tym ewentualne naruszenie praw patentowych lub autorskich. Autor oraz Wydawnictwo HELION nie ponoszą również żadnej odpowiedzialności za ewentualne szkody wynikłez wykorzystania informacji zawartych w książce.

Redaktor prowadzący: Barbara Gancarz-WójcickaProjekt okładki: Studio Gravite / OlsztynObarek, Pokoński, Pazdrijowski, Zaprucki

Fotografia na okładce została wykorzystana za zgodą shutterstock.

Wydawnictwo HELION ul. Kościuszki 1c, 44-100 GLIWICE tel. 32 231 22 19, 32 230 98 63 e-mail: onepress@onepress.pl WWW: http://onepress.pl (księgarnia internetowa, katalog książek)

Drogi Czytelniku! Jeżeli chcesz ocenić tę książkę, zajrzyj pod adres http://onepress.pl/user/opinie?sfomodMożesz tam wpisać swoje uwagi, spostrzeżenia, recenzję.

ISBN: 978-83-246-4880-1

Copyright © Jarosław Żeliński 2017

Printed in Poland.

• Kup książkę• Poleć książkę • Oceń książkę

• Księgarnia internetowa• Lubię to! » Nasza społeczność

Spis tre ci

Wst p 5

1. Po co nam pan analityk? 7

2. Jak opracowa wymagania dla systemu informatycznego 13Jaki to ma zwi zek z systemem informatycznym? 14

3. System zarz dzania informacj 17Dwie definicje 18

a cuchy 21

4. Czym jest system CRM 25Opis problemu 25Czy dysk sieciowy rozwi zuje problem? 29Pora na system CRM 30

5. Zasoby IT a procesy przetwarzania informacji 35

6. A na grzyba mi to modelowanie 39Wi c jak to jest z tymi wymaganiami? Jak je wyspecyfikowa ? 40

7. O b dach w modelowaniu 43Jak, co i po co modelowa 43O analizie wymaga dla systemu IT 45

8. Potrzeby informacyjne a zarz dzanie wiedz 47Potrzeby informacyjne firmy 47Definicje 48Model poj ciowy jako model rzeczywisto ci 51Zarz dzanie wiedz 56

9. Historyjka u ytkownika — k opoty 57

10. Regu y biznesowe — czym s 61

11. Komunikacja, czyli analiza i projektowanie, oraz jak to zostanie odebrane 63Model komunikacji 63Jak to si ma do in ynierii oprogramowania 66Na zako czenie 68

12. Przypadki u ycia i granice systemu 71

Kup książkę Poleć książkę

4 Analiza biznesowa. Praktyczne modelowanie organizacji

13. Diagram klas: model dziedziny 77Dygresja budowlana — pouczaj ca przygoda 77Diagram klas czy model dziedziny — co ma powsta ? 78Model dziedziny systemu zamówienia 79Diagram klas a model dziedziny systemu 81Czy takie analizy maj sens w przypadku gotowych ERP? 85A gdzie si podzia y wymagania pozafunkcjonalne? 85

14. Klient nasz pan 87

15. Wymagania dla oprogramowania ERP a analiza przedwdro eniowa— gdzie jest ró nica? 91Kupujemy buciki 91Jak wykona patyczek? 92Co zawiera taki model? 93

16. Udzia owcy projektu, czyli diagramy UML 95Modelowanie zale no ci pomi dzy udzia owcami 96UML i diagramy przypadków u ycia jako model udzia owców 96Analiza RACI 100

17. Analityk biznesowy, czyli wypleni dwuznaczno z dokumentów 101

18. Plansza do gry w szachy, czyli analiza i projektowanie 103Cel zamawiaj cego 103Model poj ciowy — zrozumie problem i cel projektu 105Model procesu biznesowego — zrozumie , co i po co jest robione 107Zarz dzanie wymaganiami 117Na zako czenie 119

Kup książkę Poleć książkę

Rozdzia 1.

Po co nam pan analityk?

Przecie analiz zrobimy sami, a jak nie — to zrobi to dostawca. W ten sposób cz sto rozpo-czyna si tak zwana droga do kl ski. Jednym z typowych listów inicjuj cych wspó pracz wieloma moimi klientami by ten:

Planujemy wdro enie nowego oprogramowania, jednak chcemy tym razem unikn presji zestrony dostawcy oprogramowania. Poprzednim razem dostawca oprogramowania upraszczasobie prac ju na etapie analizy, któr wykonywa sam. Analiza wymaga polega a nawywiadach i warsztatach grupowych, a sko czy a si zwyk ym opisem, tabelkami i kilkomanieczytelnymi schematami. Podczas analizy i wdro enia stale wmawiano nam, e „tegonie mo na”, „to nale y upro ci ” albo „tak si nie robi”, my za nie potrafili my tego oceni .Wiele naszych potrzeb odkrywali my dopiero podczas instalacji kolejnych prototypów, za do-stawca unika wprowadzania zmian i obiecanych dostosowa . Dostali my w efekcie nieprzy-datne i niezgodne z biznesowymi potrzebami oprogramowanie. Czy mo e nam Pan tymrazem pomóc?

Czy to propaganda? Niestety nie. W czym tkwi problem? A mianowicie w metodzie pro-wadzenia analizy i potem w sposobie formu owania specyfikacji wymaga . atwo powie-dzie : zebra wymagania. Powszechnie uwa a si , e analiza wymaga wobec oprogra-mowania to prosty, ale pracoch onny proces prowadzenia wywiadów i skrz tnegozapisywania tego, czego oczekuje przysz y u ytkownik. Nic bardziej b dnego — tensposób jest najgorszy.

W ród wielu tego typu metod s te najprostsze i najbardziej ryzykowne, a mianowi-cie: wywiady, ankiety, sesje JAD (Joint Application Development, metoda polegaj ca nasta ym aktywnym udziale zamawiaj cego w tworzeniu oprogramowania). Sama ichistota zak ada, e klient wie, czego chce, nale y to tylko z niego wyci gn i uporz dkowa .

Kup książkę Poleć książkę

8 Analiza biznesowa. Praktyczne modelowanie organizacji

By mo e czasami tak jest, ale stosowanie tego rodzaju metod z regu y ko czy si kla-sycznym stwierdzeniem klienta, wyg aszanym na koniec projektu:

Tak, dostarczyli nam pa stwo dok adnie to, co chcieli my, ale zupe nie nie to, czego po-trzebujemy.

Dlaczego tak si dzieje, cho wielu (analityków) tak bardzo si stara? Ta ksi ka, zbiór ese-jów z mojego bloga, jest prób opisu tego, jak mo e wygl da skuteczna analiza i spe-cyfikacja wymaga . Zebra em tu wybrane opisy sformalizowanych metod analizy. Ale poco tyle zachodu? Dlaczego upieram si przy tych miesznych formalizmach, skoro mo -na po ludzku zapisa , co powiedzia zamawiaj cy, a potem zamieni to na wypunkto-wane listy lub wiersze adnej tabeli? Najlepiej jeszcze, gdy licz sobie najmniej kilkasetpozycji. Jednak tak w a nie pracuje „analityk dyktafon”.

Dobra specyfikacja wymaga dla oprogramowania to wynik analizy i modelowania or-ganizacji, kompromis pomi dzy mo liwo ciami technologii a celami biznesowymi wdro e-nia. Nie ma tu znaczenia, czy b dzie to gotowy system ERP, czy dedykowane rozwi zanie.

Czym grozi wykonywanie analizy w sposób, w jaki robi to „analityk dyktafon”?

Poni ej kilka statystyk oraz mój komentarz co do przyczyn stwierdzonych problemów.A eby zda sobie spraw , e sprawa jest powa na, wystarczy wiedzie , e:

B dy w wymaganiach to jedna trzecia wszystkich defektów w projektach.

( ród o: Dean Leffingwell, Don Widrig, Managing Software Requirements, 1999)

Produktem analizy wymaga jest specyfikacja wymaga i, jak ju wspomnia em, mo naje zbiera metodami „rejestracyjnymi” (odpytywanie klientów) oraz „badawczymi”. Te drugieto kolejno: analiza i model organizacji klienta, identyfikacja celów biznesowych i czynnikówwp ywaj cych na ich osi gni cie, projekt rozwi zania: co ma zosta dostarczone, opis pro-jektu, czyli specyfikacja produktu. Przeprowadzenie wywiadów jest atwe, a pe na anali-za trudna. Nietrudno si wi c domy li , które metody stosuje si najcz ciej. I mamyg ówn przyczyn problemu, to w a nie:

Procesy zwi zane ze zbieraniem wymaga s ród em wi kszo ci powa nych problemówz jako ci .

( ród o: Gerald Weinberg, Quality Software Management, 1997)

Jako specyfikacji wymaga wyra a si mi dzy innymi w jej kompletno ci, spójno cii niesprzeczno ci. Gdy dokument wymaga jest niskiej jako ci, to typowym objawem jest takzwane odkrywanie wymaga w trakcie trwania projektu, czyli zmiany zakresu projektu, a:

Zmiany zakresu s jednym z najcz stszych róde dodatkowych kosztów w projektachi cz sto prowadz do porzucenia projektu.

( ród o: Capers Jones, Assessment and Control of Software Risks, 1994)

Kup książkę Poleć książkę

Rozdzia 12.

Przypadki u ycia i granice systemu

Pora opisa przypadki u ycia i granice systemu. Cz sto stosowane do opisu wymaga tak zwa-ne user story (w polskim pi miennictwie zwane historyjkami u ytkownika) stwarza ryzyko nie-jednoznaczno ci opisu. Narz dziem niweluj cym to ryzyko jest model procesu biznesowego(jaki opisa Zamawiaj cy metod user story). Tworzenie modelu ma dwa zadania: weryfikacjspójno ci i kompletno ci opisu Zamawiaj cego oraz stworzenie podstawy do okre lenia za-kresu projektu i wyspecyfikowania wymaga funkcjonalnych, czyli tak zwanych przypadkówu ycia. Czy tak si zawsze post puje? Ja z zasady, zgodnie z moj metodyk opracowan nabazie do wiadcze i literatury, traktuj KA DY opis dostarczony przez Zamawiaj cego,nawet w postaci strukturalnej (tabele, listy itp.), jako takie w a nie ryzykowne user story.

Czy to oznacza brak zaufania do Zamawiaj cego? Przecie ten system jest przeznaczonydla niego, wi c Zamawiaj cy powinien umie okre li , czego potrzebuje. Hm… Ka dy z naspotrafi powiedzie , jaki chce mie samochód i do czego jest mu potrzebny, ale czy to znaczy,e potrafi wyspecyfikowa konstrukcj tego samochodu? (Mój mechanik jest bardziej dosadny,

zawsze mówi: nie ma nic gorszego od faceta, któremu wydaje si , e zna si na samocho-dach). Je li chcemy kupi gotowe oprogramowanie o standardowej, powszechnie stosowanejfunkcjonalno ci, w zasadzie aden analityk nie jest nam potrzebny. Je eli jednak chcemyco , co cho troszk ma by dostosowane do specyfiki naszego biznesu i nie jest trywial-ne, nale y do tego podej z wi ksza rezerw . Wracaj c do wcze niejszego przyk adu:nie mówimy ju bowiem o przeci tnym samochodzie, ale o samochodzie sportowym, którymwystartujemy w zawodach. Ten sport to wolny rynek i starcie z konkurencj . Mo e niezawsze jest to Formu a 1, ale te prawie nigdy nie jest to te jazda spacerowa.

Wró my do naszego modelu procesów. Ten powsta y na bazie opisu Zamawiaj cegopozwoli znale luki i niespójno ci, jest jednak zbyt szczegó owy. To rzadki u mnie przypa-dek analizy bottom-up (od szczegó u do ogó u), jednak pierwsza sztywna zasada analitykamówi: nie istniej sztywne zasady analizy i projektowania. Po drobnych poprawkachi dokonaniu uogólnie model wygl da tak (rysunek 12.1):

Kup książkę Poleć książkę

72 Analiza biznesowa. Praktyczne modelowanie organizacji

Rysu

nek

12.1

. Mod

el p

roce

sów

Kup książkę Poleć książkę

Przypadki u ycia i granice systemu 73

Wprowadzone zmiany polegaj na dwóch uogólnieniach w obszarze klienta: Zamówienieoraz P atno (szczegó owe scenariusze sta y si procedurami z seri czynno ci, a tego niechcemy, gdy ko czymy na zasadzie: jeden cel procesu — jeden proces). Dlaczego tak?Na poziomie opisu user story najcz ciej opisy zawieraj szczegó y zwi zane z aktualnym(znanym Zamawiaj cemu z autopsji) sposobem pracy. W zakresie projektu jednak pozo-stanie jeden proces (czynno ): Zamówienie, oznaczony stereotypem przypadek u ycia(stereotypy nie s cz ci notacji BPMN, stosuj je do wskazywania powi za pomi dzyobiektami w modelach BPMN i UML).

Warto tu poda pewne wyja nienie. Z teorii komunikacji wiadomo, e zasadniczo niemo na (niewprawiony i nie wiadomy zjawiska cz owiek praktycznie nie jest w stanie) uniknska enia ka dego swojego przekazu w asnym do wiadczeniem, czyli znan sobie histori .Dlatego pierwszym krokiem jest uogólnienie tre ci user story do poziomu abstrakcji: co i poco jest robione, gdy metody analizy bazuj ce na faktach zamiast na opisie Zamawiaj cegos wolne od tej przypad o ci. Mo na je jednak stosowa tylko w pewnych warunkach (otym w dalszej cz ci ksi ki).

Po stronie Zamawiaj cego (u ytkownika, dalej zwanego tak e aktorem) zastosowanouogólnienie bazuj ce na definicji procesu biznesowego: proces biznesowy to czynno lublogicznie powi zany a cuch czynno ci przekszta caj cy produkt na swoim wej ciu w pro-dukt (jego stan) na wyj ciu. Ró nica pomi dzy tymi produktami stanowi warto bizne-sow wnoszon przez dany proces.

Po stronie Klienta mamy teraz tylko dwa takie procesy (czynno ci): Zamówienie oraz P at-no . Czynno ci po stronie dostawcy (Nasza Firma Sp. z o.o.) zaniedbujemy, gdy systemma wprowadza automatyzacj , wi c wdro enie oprogramowania wyeliminuje z obs ugiZamówie elektronicznych cz owieka.

Kolejn spraw s granice systemu. Przyjmijmy dwa za o enia, które wydaj si bar-dzo rozs dne: firma posiada system ERP oraz p atno ci elektroniczne b d przedmiotemoutsourcingu. Tak wi c wymagania funkcjonalne dla systemu to:

1) przyjmowanie zamówie ,

2) przyjmowanie p atno ci drog elektroniczn ,

3) integracja z ERP: system ten odpowiada za ksi gowanie faktur i zarz dzanie ma-gazynem,

4) wykorzystanie zewn trznego operatora p atno ci elektronicznych.

Powy sze wydaje si rozs dne i bywa cz sto spotykane (staram si , by ten przyk ad nieodbiega przesadnie od rzeczywisto ci ;)). Warto, aby wymagania by y sformu owanezwi le, ale i nie wykracza y poza opis dzia a , które powinny by mo liwe dzi ki no-wemu systemowi. Tak wi c diagram przypadków u ycia, jaki utworzy em, wygl da tak(rysunek 12.2):

Kup książkę Poleć książkę

74 Analiza biznesowa. Praktyczne modelowanie organizacji

Rysunek 12.2. Diagram przypadków

Czytelnikowi nale y si kilka s ów na temat tego diagramu. W zasadzie mamy jeden przy-padek u ycia: Zamówienie. P atno jest realizowana w ramach outsourcingu przez zewn trznysystem (aktor System obs ugi p atno ci, strza ka z pe nym grotem skierowana w stron przypad-ku u ycia: Operator p atno ci realizuje ten przypadek u ycia). P atno jest inicjowana (Extend)w Systemie. System ERP odpowiada za faktury i magazyn (Zamówienie zale y od tego ERP —strza ka przerywana skierowana do ERP). Przypadek u ycia P atno ci le y poza granicami na-szego systemu (czyli poza zakresem projektu!). Ka dy przypadek u ycia powinien zostaudokumentowany co najmniej trzema elementami:

1) opisem stanu pocz tkowego (warunków pocz tkowych),

2) scenariuszem,

3) opisem oczekiwanego stanu ko cowego.

Kontekst stanowi model procesów, wi c nie musimy tu pisa , czym s poprzedzanei jakich maj nast pców poszczególne przypadki u ycia (diagram ten nie s u y do modelo-wania procesów!). Wystarczy w modelach zachowa tak zwane traceability ( ladowanie).Osobi cie stosuj prost zasad : nazwa przypadku u ycia jest taka sama jak czynno ciw modelu procesów, z której zosta wyprowadzony. Nazwy te s unikalne. Nie musimy tak etworzy diagramów scenariuszy nadrz dnych a cuchów przypadków u ycia, bo zast puje jew a nie model BPMN. Na koniec jedna uwaga: przypadek u ycia powinien by samowy-starczalny, innymi s owy, musi mie sens jako sam jeden (sam z siebie s u y do wykonaniajakiej logicznej czynno ci daj cej przydatny produkt).

Kup książkę Poleć książkę

Przypadki u ycia i granice systemu 75

Scenariusz przypadku u ycia najpro ciej i najskuteczniej jest opisywa w postaci dialoguAktor <—> System. Ja najcz ciej stosuj prost tabel z kolumnami Aktor i System:

AKTOR SYSTEM

Inicjuje prac .

Zaznacza wybrane produkty i zatwierdza przyciskiem „OK”.

Potwierdza zamówienie.

Wybiera system p atno ci i zatwierdza przyciskiem „OK”.

Wy wietla list produktów.

Wy wietla tre zamówienia.

Wy wietla dane o p atno ci.

Ko czy i ewentualnie przekazujesterowanie.

Coraz cz ciej spotykam (i sam stosuj ) te nast puj c konwencj :

1. Inicjacja pracy.

2. SYSTEM wy wietla list produktów.

3. Zaznaczenie wybranego produktu i klikni cie przycisku „OK”.

4. SYSTEM wy wietla tre zamówienia.

5. Potwierdzenie zamówienia.

6. SYSTEM wy wietla dane o p atno ci.

7. Wybór systemu p atno ci i zatwierdzenie przyciskiem „OK”.

8. SYSTEM ko czy i ewentualnie przekazuje sterowanie.

Ostatni krok to ewentualne przekazanie sterowania do systemu obs ugi p atno ci elek-tronicznych, je li Aktor zaznaczy tak opcj (alternatyw jest tylko wydruk formularza i kla-syczny przelew bankowy).

Tworzenie diagramów przypadków u ycia w zasadzie warto traktowa tylko jako specy-fikacj koncepcji, zachowuj c ich zrozumia o dla laika. „B belki” przypadków u ycia po-winny by tylko specyfikacj funkcjonaln i niczym ponadto. Ten diagram i tak nie zast pidiagramu klas, sekwencji czy tym bardziej opisu procesu (tu by BPMN). Jak nietrudno chybaju zauwa y , dokumentacja zmierza w kierunku kilku prostych modeli (diagramów) zamiastjednego spaghetti-modelu. Cz sto spotykam si z dokumentami, w których autor analizywymaga wszystko udokumentowa na diagramie przypadków u ycia (lub przynajmniejstara si to zrobi ). Takie dokumentacje bywaj straszne.

Na zako czenie przedstawi diagram komponentów obrazuj cy nasz projektowany sys-tem oraz te systemy, z którymi b dzie zintegrowany (rysunek 12.3).

Kup książkę Poleć książkę

76 Analiza biznesowa. Praktyczne modelowanie organizacji

Rysunek 12.3. Diagram komponentów

Diagram ten zawiera poza komponentami tak e klasy interfejsów I_ERP i I_P atno ci,klasy te s wykorzystywane w diagramach interakcji.

Przy okazji warto wspomnie o Cloud Computing: komponenty integrowane mog by do-st pne „w chmurze”. W kolejnym rozdziale opisz model dziedziny systemu i model sekwencjidla przypadku u ycia. Nadmieni te , e wci nie przedyskutowali my problemu wymaganiefunkcjonalnych!

Kup książkę Poleć książkę

http://program-partnerski.helion.pl