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łe
z wykorzystania informacji zawartych w książce.

Redaktor prowadzący: Barbara Gancarz-Wójcicka
Projekt okładki: Studio Gravite / Olsztyn
Obarek, Pokoński, Pazdrijowski, Zaprucki

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

Wydawnictwo HELION
ul. Kościuszki 1c, 44-100 GLIWICE
tel. [phone]
e-mail:

[e-mail]

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?sfomod
Moż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

13

Jaki to ma zwiîzek z systemem informatycznym?

14

3. System zarzëdzania informacjë

17

Dwie definicje

18

ĩaĬcuchy

21

4. Czym jest system CRM

25

Opis problemu

25

Czy dysk sieciowy rozwiîzuje problem?

29

Pora na system CRM

30

5. Zasoby IT a procesy przetwarzania informacji

35

6. A na grzyba mi to modelowanie

39

WiĂc jak to jest z tymi wymaganiami? Jak je wyspecyfikowað?

40

7. O bħÿdach w modelowaniu

43

Jak, co i po co modelowað

43

O analizie wymagaĬ dla systemu IT

45

8. Potrzeby informacyjne a zarzëdzanie wiedzë

47

Potrzeby informacyjne firmy

47

Definicje

48

Model pojĂciowy jako model rzeczywistoŁci

51

Zarzî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

63

Model komunikacji

63

Jak to siĂ ma do inšynierii oprogramowania

66

Na 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

77

Dygresja budowlana — pouczajîca przygoda

77

Diagram klas czy model dziedziny — co ma powstað?

78

Model dziedziny systemu zamówienia

79

Diagram klas a model dziedziny systemu

81

Czy takie analizy majî sens w przypadku gotowych ERP?

85

A 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?

91

Kupujemy buciki

91

Jak wykonað patyczek?

92

Co zawiera taki model?

93

16. Udziaħowcy projektu, czyli diagramy UML

95

Modelowanie zalešnoŁci pomiĂdzy udziaĪowcami

96

UML i diagramy przypadków ušycia jako model udziaĪowców

96

Analiza RACI

100

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

101

18. Plansza do gry w szachy, czyli analiza i projektowanie

103

Cel zamawiajîcego

103

Model pojĂciowy — zrozumieð problem i cel projektu

105

Model procesu biznesowego — zrozumieð, co i po co jest robione

107

Zarzîdzanie wymaganiami

117

Na 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óĪpracĂ
z wieloma moimi klientami byĪ ten:

Planujemy wdrošenie nowego oprogramowania, jednak chcemy tym razem uniknîð presji ze
strony dostawcy oprogramowania. Poprzednim razem dostawca oprogramowania upraszczaĪ
sobie pracĂ juš na etapie analizy, którî wykonywaĪ sam. Analiza wymagaĬ polegaĪa na
wywiadach i warsztatach grupowych, a skoĬczyĪa siĂ zwykĪym opisem, tabelkami i kilkoma
nieczytelnymi schematami. Podczas analizy i wdrošenia stale wmawiano nam, še „tego
nie 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 tym
razem 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Ătnego
zapisywania tego, czego oczekuje przyszĪy ušytkownik. Nic bardziej bĪĂdnego — ten
sposó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 na
staĪym aktywnym udziale zamawiajîcego w tworzeniu oprogramowania). Sama ich
istota 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 po
co 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 kilkaset
pozycji. 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šna

je zbierað metodami „rejestracyjnymi” (odpytywanie klientów) oraz „badawczymi”. Te drugie
to kolejno: analiza i model organizacji klienta, identyfikacja celów biznesowych i czynników
wpĪ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 mamy
gĪównî przyczynĂ problemu, to wĪaŁnie:

Procesy zwiîzane ze zbieraniem wymagaĬ sî şródĪem wiĂkszoŁci powašnych problemów
z 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Łci

i niesprzecznoŁci. Gdy dokument wymagaĬ jest niskiej jakoŁci, to typowym objawem jest tak
zwane odkrywanie wymagaĬ w trakcie trwania projektu, czyli zmiany zakresu projektu, a:

Zmiany zakresu sî jednym z najczĂstszych şródeĪ dodatkowych kosztów w projektach
i 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: weryfikacjĂ
spó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ów
ušycia. Czy tak siĂ zawsze postĂpuje? Ja z zasady, zgodnie z mojî metodykî opracowanî na
bazie 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 przeznaczony

dla niego, wiĂc Zamawiajîcy powinien umieð okreŁlið, czego potrzebuje. Hm… Kašdy z nas
potrafi 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 stosowanej
funkcjonalnoŁci, w zasadzie šaden analityk nie jest nam potrzebny. Ješeli jednak chcemy
coŁ, 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órym
wystartujemy w zawodach. Ten sport to wolny rynek i starcie z konkurencjî. Moše nie
zawsze 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îcego

pozwoliĪ 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 analityka
mówi: nie istniejî sztywne zasady analizy i projektowania. Po drobnych poprawkach
i dokonaniu uogólnieĬ model wyglîda tak (rysunek 12.1):

Kup książkę

Poleć książkę

72

Analiza biznesowa. Praktyczne modelowanie organizacji

Rysunek 1

2.1.

M

odel pr

ocesó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ówienie

oraz PĪatnoŁð (szczegóĪowe scenariusze staĪy siĂ procedurami z seriî czynnoŁci, a tego nie
chcemy, 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Ădzy
obiektami w modelach BPMN i UML).

Warto tu podað pewne wyjaŁnienie. Z teorii komunikacji wiadomo, še zasadniczo nie

mošna (niewprawiony i nieŁwiadomy zjawiska czĪowiek praktycznie nie jest w stanie) uniknîð
skaš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 po
co jest robione, gdyš metody analizy bazujîce na faktach zamiast na opisie Zamawiajîcego
sî wolne od tej przypadĪoŁci. Mošna je jednak stosowað tylko w pewnych warunkach (o
tym w dalszej czĂŁci ksiîški).

Po stronie Zamawiajîcego (ušytkownika, dalej zwanego takše aktorem) zastosowano

uogólnienie bazujîce na definicji procesu biznesowego: proces biznesowy to czynnoŁð lub
logicznie 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š system
ma wprowadzað automatyzacjĂ, wiĂc wdrošenie oprogramowania wyeliminuje z obsĪugi
Zamó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î przedmiotem
outsourcingu. 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 nie

odbiegaĪ przesadnie od rzeczywistoŁci ;)). Warto, aby wymagania byĪy sformuĪowane
zwiĂş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Ătrzny
system (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 zostað
udokumentowany 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î poprzedzane

i 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Łci
w modelu procesów, z której zostaĪ wyprowadzony. Nazwy te sî unikalne. Nie musimy takše
tworzyð diagramów scenariuszy nadrzĂdnych ĪaĬcuchów przypadków ušycia, bo zastĂpuje je
wĪ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 wykonania
jakiejŁ 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 dialogu

Aktor <—> 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 przekazuje
sterowanie.

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îpi
diagramu klas, sekwencji czy tym bardziej opisu procesu (tu byĪ BPMN). Jak nietrudno chyba
juš zauwašyð, dokumentacja zmierza w kierunku kilku prostych modeli (diagramów) zamiast
jednego spaghetti-modelu. CzĂsto spotykam siĂ z dokumentami, w których autor analizy
wymagaĬ wszystko udokumentowaĪ na diagramie przypadków ušycia (lub przynajmniej
staraĪ 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 sekwencji
dla przypadku ušycia. NadmieniĂ teš, še wciîš nie przedyskutowaliŁmy problemu wymagaĬ
niefunkcjonalnych!

Kup książkę

Poleć książkę