Cyfroteka.pl

klikaj i czytaj online

Cyfro
Czytomierz
00542 010814 7467180 na godz. na dobę w sumie
Analiza biznesowa. Praktyczne modelowanie organizacji - ebook/pdf
Analiza biznesowa. Praktyczne modelowanie organizacji - ebook/pdf
Autor: Liczba stron: 120
Wydawca: Onepress Język publikacji: polski
ISBN: 978-83-283-3296-6 Data wydania:
Lektor:
Kategoria: ebooki >> poradniki >> controlling
Porównaj ceny (książka, ebook (-20%), audiobook).

Zrozum, zanim zaproponujesz rozwiązanie

Analiza biznesowa, przeprowadzana przez wykonawcę rozwiązań IT dla biznesu, nie polega na zwykłym spisaniu problemów zgłaszanych przez klienta. Zapis przebiegu spotkań, wypunktowanie najważniejszych wymagań stawianych przed oprogramowaniem i prezentacja ich klientowi w formie tabeli to jeszcze nie analiza biznesowa! Wykonawca oprogramowania otrzymuje w ten sposób jedynie wnioski dotyczące efektów wadliwego działania aktualnego systemu zarządzania, ale dalej nie ma pojęcia o przyczynach tego stanu rzeczy. Jak zatem może zaproponować zleceniodawcy lepsze rozwiązanie?

Prawidłowo przeprowadzona analiza i modelowanie biznesowe opierają się na pewnych ściśle określonych zasadach i korzystają z przeznaczonych do tego celu notacji (języków). Na naszym rynku istnieje wiele podręczników szczegółowo opisujących teorię poszczególnych notacji: UML, BPMN, BMM, SysML itd. Ich autorzy skupiają się na definicji pojęć, słownictwie i powiązaniach występujących w poszczególnych metodach zapisu, a teorie uzupełniają prostymi przykładami. Autor tej książki postanowił podejść do tematu z całkiem innej strony wychodzi od faktycznych problemów, z jakimi spotkał się w swojej wieloletniej praktyce, i podaje przykłady ich poprawnego, analitycznego opisu z użyciem takiej notacji, która jest najwłaściwsza w danej sytuacji biznesowej. Dzięki temu masz szansę poznać i zrozumieć, kiedy, po co i jak stosować dany język analityczny.


Jarosław Żeliński -- niezależny ekspert. Ukończył Wydział Elektroniki Wojskowej Akademii Technicznej. Od 1991 roku pracuje w branży IT. Uczestniczy w projektach z zakresu wdrożeń systemów IT, analiz systemowych i doradztwa organizacyjnego. Od 1998 roku prowadzi niezależną działalność doradczą, publikuje eseje, autorskie prace analityczne i opracowania branżowe w prasie specjalistycznej i gospodarczej oraz na własnym portalu IT-Consulting.pl. Od 2003 roku jest członkiem Stowarzyszenia Doradców Gospodarczych, a od 2005 roku współpracownikiem i wykładowcą Katedry Systemów Informacyjnych na Wydziale Przedsiębiorczości i Towaroznawstwa Akademii Morskiej w Gdyni. Od 2008 roku pracuje także na Politechnice Warszawskiej. Prowadzi samodzielne studia i badania naukowe w zakresie zastosowań teorii poznania i języków formalnych w analizach systemowych organizacji. Jest członkiem International Institute of Business Analysis.

Znajdź podobne książki

Darmowy fragment publikacji:

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. 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?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(cid:318)ci Wst(cid:255)p 1. Po co nam pan analityk? 2. Jak opracowa(cid:237) wymagania dla systemu informatycznego Jaki to ma zwi(cid:238)zek z systemem informatycznym? 3. System zarz(cid:235)dzania informacj(cid:235) Dwie definicje (cid:297)a(cid:300)cuchy 4. Czym jest system CRM Opis problemu Czy dysk sieciowy rozwi(cid:238)zuje problem? Pora na system CRM 5. Zasoby IT a procesy przetwarzania informacji 6. A na grzyba mi to modelowanie Wi(cid:258)c jak to jest z tymi wymaganiami? Jak je wyspecyfikowa(cid:240)? 7. O b(cid:295)(cid:255)dach w modelowaniu Jak, co i po co modelowa(cid:240) O analizie wymaga(cid:300) dla systemu IT 8. Potrzeby informacyjne a zarz(cid:235)dzanie wiedz(cid:235) Potrzeby informacyjne firmy Definicje Model poj(cid:258)ciowy jako model rzeczywisto(cid:321)ci Zarz(cid:238)dzanie wiedz(cid:238) 9. Historyjka u(cid:350)ytkownika — k(cid:295)opoty 10. Regu(cid:295)y biznesowe — czym s(cid:235) 11. Komunikacja, czyli analiza i projektowanie, oraz jak to zostanie odebrane Model komunikacji Jak to si(cid:258) ma do in(cid:353)ynierii oprogramowania Na zako(cid:300)czenie 12. Przypadki u(cid:350)ycia i granice systemu 5 7 13 14 17 18 21 25 25 29 30 35 39 40 43 43 45 47 47 48 51 56 57 61 63 63 66 68 71 Kup książkęPoleć książkę 4 Analiza biznesowa. Praktyczne modelowanie organizacji 13. Diagram klas: model dziedziny Dygresja budowlana — pouczaj(cid:238)ca przygoda Diagram klas czy model dziedziny — co ma powsta(cid:240)? Model dziedziny systemu zamówienia Diagram klas a model dziedziny systemu Czy takie analizy maj(cid:238) sens w przypadku gotowych ERP? A gdzie si(cid:258) podzia(cid:298)y wymagania pozafunkcjonalne? 14. Klient nasz pan 15. Wymagania dla oprogramowania ERP a analiza przedwdro(cid:350)eniowa — gdzie jest ró(cid:350)nica? Kupujemy buciki Jak wykona(cid:240) patyczek? Co zawiera taki model? 16. Udzia(cid:295)owcy projektu, czyli diagramy UML Modelowanie zale(cid:353)no(cid:321)ci pomi(cid:258)dzy udzia(cid:298)owcami UML i diagramy przypadków u(cid:353)ycia jako model udzia(cid:298)owców Analiza RACI 17. Analityk biznesowy, czyli wypleni(cid:237) dwuznaczno(cid:318)(cid:237) z dokumentów 18. Plansza do gry w szachy, czyli analiza i projektowanie Cel zamawiaj(cid:238)cego Model poj(cid:258)ciowy — zrozumie(cid:240) problem i cel projektu Model procesu biznesowego — zrozumie(cid:240), co i po co jest robione Zarz(cid:238)dzanie wymaganiami Na zako(cid:300)czenie 77 77 78 79 81 85 85 87 91 91 92 93 95 96 96 100 101 103 103 105 107 117 119 Kup książkęPoleć książkę Rozdzia(cid:297) 1. Po co nam pan analityk? Przecie(cid:353) analiz(cid:258) zrobimy sami, a jak nie — to zrobi to dostawca. W ten sposób cz(cid:258)sto rozpo- czyna si(cid:258) tak zwana droga do kl(cid:258)ski. Jednym z typowych listów inicjuj(cid:238)cych wspó(cid:298)prac(cid:258) z wieloma moimi klientami by(cid:298) ten: Planujemy wdro(cid:353)enie nowego oprogramowania, jednak chcemy tym razem unikn(cid:238)(cid:240) presji ze strony dostawcy oprogramowania. Poprzednim razem dostawca oprogramowania upraszcza(cid:298) sobie prac(cid:258) ju(cid:353) na etapie analizy, któr(cid:238) wykonywa(cid:298) sam. Analiza wymaga(cid:300) polega(cid:298)a na wywiadach i warsztatach grupowych, a sko(cid:300)czy(cid:298)a si(cid:258) zwyk(cid:298)ym opisem, tabelkami i kilkoma nieczytelnymi schematami. Podczas analizy i wdro(cid:353)enia stale wmawiano nam, (cid:353)e „tego nie mo(cid:353)na”, „to nale(cid:353)y upro(cid:321)ci(cid:240)” albo „tak si(cid:258) nie robi”, my za(cid:321) nie potrafili(cid:321)my tego oceni(cid:240). Wiele naszych potrzeb odkrywali(cid:321)my dopiero podczas instalacji kolejnych prototypów, za(cid:321) do- stawca unika(cid:298) wprowadzania zmian i obiecanych dostosowa(cid:300). Dostali(cid:321)my w efekcie nieprzy- datne i niezgodne z biznesowymi potrzebami oprogramowanie. Czy mo(cid:353)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(cid:298)owania specyfikacji wymaga(cid:300). (cid:297)atwo powie- dzie(cid:240): zebra(cid:240) wymagania. Powszechnie uwa(cid:353)a si(cid:258), (cid:353)e analiza wymaga(cid:300) wobec oprogra- mowania to prosty, ale pracoch(cid:298)onny proces prowadzenia wywiadów i skrz(cid:258)tnego zapisywania tego, czego oczekuje przysz(cid:298)y u(cid:353)ytkownik. Nic bardziej b(cid:298)(cid:258)dnego — ten sposób jest najgorszy. W(cid:321)ród wielu tego typu metod s(cid:238) te najprostsze i najbardziej ryzykowne, a mianowi- cie: wywiady, ankiety, sesje JAD (Joint Application Development, metoda polegaj(cid:238)ca na sta(cid:298)ym aktywnym udziale zamawiaj(cid:238)cego w tworzeniu oprogramowania). Sama ich istota zak(cid:298)ada, (cid:353)e klient wie, czego chce, nale(cid:353)y to tylko z niego wyci(cid:238)gn(cid:238)(cid:240) i uporz(cid:238)dkowa(cid:240). Kup książkęPoleć książkę 8 Analiza biznesowa. Praktyczne modelowanie organizacji By(cid:240) mo(cid:353)e czasami tak jest, ale stosowanie tego rodzaju metod z regu(cid:298)y ko(cid:300)czy si(cid:258) kla- sycznym stwierdzeniem klienta, wyg(cid:298)aszanym na koniec projektu: Tak, dostarczyli nam pa(cid:300)stwo dok(cid:298)adnie to, co chcieli(cid:321)my, ale zupe(cid:298)nie nie to, czego po- trzebujemy. Dlaczego tak si(cid:258) dzieje, cho(cid:240) wielu (analityków) tak bardzo si(cid:258) stara? Ta ksi(cid:238)(cid:353)ka, zbiór ese- jów z mojego bloga, jest prób(cid:238) opisu tego, jak mo(cid:353)e wygl(cid:238)da(cid:240) skuteczna analiza i spe- cyfikacja wymaga(cid:300). Zebra(cid:298)em tu wybrane opisy sformalizowanych metod analizy. Ale po co tyle zachodu? Dlaczego upieram si(cid:258) przy tych (cid:321)miesznych formalizmach, skoro mo(cid:353)- na po ludzku zapisa(cid:240), co powiedzia(cid:298) zamawiaj(cid:238)cy, a potem zamieni(cid:240) to na wypunkto- wane listy lub wiersze (cid:298)adnej tabeli? Najlepiej jeszcze, gdy licz(cid:238) sobie najmniej kilkaset pozycji. Jednak tak w(cid:298)a(cid:321)nie pracuje „analityk dyktafon”. Dobra specyfikacja wymaga(cid:300) dla oprogramowania to wynik analizy i modelowania or- ganizacji, kompromis pomi(cid:258)dzy mo(cid:353)liwo(cid:321)ciami technologii a celami biznesowymi wdro(cid:353)e- nia. Nie ma tu znaczenia, czy b(cid:258)dzie to gotowy system ERP, czy dedykowane rozwi(cid:238)zanie. Czym grozi wykonywanie analizy w sposób, w jaki robi to „analityk dyktafon”? Poni(cid:353)ej kilka statystyk oraz mój komentarz co do przyczyn stwierdzonych problemów. A (cid:353)eby zda(cid:240) sobie spraw(cid:258), (cid:353)e sprawa jest powa(cid:353)na, wystarczy wiedzie(cid:240), (cid:353)e: B(cid:298)(cid:258)dy w wymaganiach to jedna trzecia wszystkich defektów w projektach. ((cid:350)ród(cid:298)o: Dean Leffingwell, Don Widrig, Managing Software Requirements, 1999) Produktem analizy wymaga(cid:300) jest specyfikacja wymaga(cid:300) i, jak ju(cid:353) wspomnia(cid:298)em, mo(cid:353)na je zbiera(cid:240) metodami „rejestracyjnymi” (odpytywanie klientów) oraz „badawczymi”. Te drugie to kolejno: analiza i model organizacji klienta, identyfikacja celów biznesowych i czynników wp(cid:298)ywaj(cid:238)cych na ich osi(cid:238)gni(cid:258)cie, projekt rozwi(cid:238)zania: co ma zosta(cid:240) dostarczone, opis pro- jektu, czyli specyfikacja produktu. Przeprowadzenie wywiadów jest (cid:298)atwe, a pe(cid:298)na anali- za trudna. Nietrudno si(cid:258) wi(cid:258)c domy(cid:321)li(cid:240), które metody stosuje si(cid:258) najcz(cid:258)(cid:321)ciej. I mamy g(cid:298)ówn(cid:238) przyczyn(cid:258) problemu, to w(cid:298)a(cid:321)nie: Procesy zwi(cid:238)zane ze zbieraniem wymaga(cid:300) s(cid:238) (cid:351)ród(cid:298)em wi(cid:258)kszo(cid:321)ci powa(cid:353)nych problemów z jako(cid:321)ci(cid:238). ((cid:350)ród(cid:298)o: Gerald Weinberg, Quality Software Management, 1997) Jako(cid:321)(cid:240) specyfikacji wymaga(cid:300) wyra(cid:353)a si(cid:258) mi(cid:258)dzy innymi w jej kompletno(cid:321)ci, spójno(cid:321)ci i niesprzeczno(cid:321)ci. Gdy dokument wymaga(cid:300) jest niskiej jako(cid:321)ci, to typowym objawem jest tak zwane odkrywanie wymaga(cid:300) w trakcie trwania projektu, czyli zmiany zakresu projektu, a: Zmiany zakresu s(cid:238) jednym z najcz(cid:258)stszych (cid:351)róde(cid:298) dodatkowych kosztów w projektach i cz(cid:258)sto prowadz(cid:238) do porzucenia projektu. ((cid:350)ród(cid:298)o: Capers Jones, Assessment and Control of Software Risks, 1994) Kup książkęPoleć książkę Rozdzia(cid:297) 12. Przypadki u(cid:350)ycia i granice systemu Pora opisa(cid:240) przypadki u(cid:353)ycia i granice systemu. Cz(cid:258)sto stosowane do opisu wymaga(cid:300) tak zwa- ne user story (w polskim pi(cid:321)miennictwie zwane historyjkami u(cid:353)ytkownika) stwarza ryzyko nie- jednoznaczno(cid:321)ci opisu. Narz(cid:258)dziem niweluj(cid:238)cym to ryzyko jest model procesu biznesowego (jaki opisa(cid:298) Zamawiaj(cid:238)cy metod(cid:238) user story). Tworzenie modelu ma dwa zadania: weryfikacj(cid:258) spójno(cid:321)ci i kompletno(cid:321)ci opisu Zamawiaj(cid:238)cego oraz stworzenie podstawy do okre(cid:321)lenia za- kresu projektu i wyspecyfikowania wymaga(cid:300) funkcjonalnych, czyli tak zwanych przypadków u(cid:353)ycia. Czy tak si(cid:258) zawsze post(cid:258)puje? Ja z zasady, zgodnie z moj(cid:238) metodyk(cid:238) opracowan(cid:238) na bazie do(cid:321)wiadcze(cid:300) i literatury, traktuj(cid:258) KA(cid:352)DY opis dostarczony przez Zamawiaj(cid:238)cego, nawet w postaci strukturalnej (tabele, listy itp.), jako takie w(cid:298)a(cid:321)nie ryzykowne user story. Czy to oznacza brak zaufania do Zamawiaj(cid:238)cego? Przecie(cid:353) ten system jest przeznaczony dla niego, wi(cid:258)c Zamawiaj(cid:238)cy powinien umie(cid:240) okre(cid:321)li(cid:240), czego potrzebuje. Hm… Ka(cid:353)dy z nas potrafi powiedzie(cid:240), jaki chce mie(cid:240) samochód i do czego jest mu potrzebny, ale czy to znaczy, (cid:353)e potrafi wyspecyfikowa(cid:240) konstrukcj(cid:258) tego samochodu? (Mój mechanik jest bardziej dosadny, zawsze mówi: nie ma nic gorszego od faceta, któremu wydaje si(cid:258), (cid:353)e zna si(cid:258) na samocho- dach). Je(cid:321)li chcemy kupi(cid:240) gotowe oprogramowanie o standardowej, powszechnie stosowanej funkcjonalno(cid:321)ci, w zasadzie (cid:353)aden analityk nie jest nam potrzebny. Je(cid:353)eli jednak chcemy co(cid:321), co cho(cid:240) troszk(cid:258) ma by(cid:240) dostosowane do specyfiki naszego biznesu i nie jest trywial- ne, nale(cid:353)y do tego podej(cid:321)(cid:240) z wi(cid:258)ksza rezerw(cid:238). Wracaj(cid:238)c do wcze(cid:321)niejszego przyk(cid:298)adu: nie mówimy ju(cid:353) bowiem o przeci(cid:258)tnym samochodzie, ale o samochodzie sportowym, którym wystartujemy w zawodach. Ten sport to wolny rynek i starcie z konkurencj(cid:238). Mo(cid:353)e nie zawsze jest to Formu(cid:298)a 1, ale te(cid:353) prawie nigdy nie jest to te(cid:353) jazda spacerowa. Wró(cid:240)my do naszego modelu procesów. Ten powsta(cid:298)y na bazie opisu Zamawiaj(cid:238)cego pozwoli(cid:298) znale(cid:351)(cid:240) luki i niespójno(cid:321)ci, jest jednak zbyt szczegó(cid:298)owy. To rzadki u mnie przypa- dek analizy bottom-up (od szczegó(cid:298)u do ogó(cid:298)u), jednak pierwsza sztywna zasada analityka mówi: nie istniej(cid:238) sztywne zasady analizy i projektowania. Po drobnych poprawkach i dokonaniu uogólnie(cid:300) model wygl(cid:238)da tak (rysunek 12.1): Kup książkęPoleć książkę 72 Analiza biznesowa. Praktyczne modelowanie organizacji w ó s e c o r p l e d o M . 1 . 2 1 k e n u s y R Kup książkęPoleć książkę Przypadki u(cid:352)ycia i granice systemu 73 Wprowadzone zmiany polegaj(cid:238) na dwóch uogólnieniach w obszarze klienta: Zamówienie oraz P(cid:298)atno(cid:321)(cid:240) (szczegó(cid:298)owe scenariusze sta(cid:298)y si(cid:258) procedurami z seri(cid:238) czynno(cid:321)ci, a tego nie chcemy, gdy(cid:353) ko(cid:300)czymy na zasadzie: jeden cel procesu — jeden proces). Dlaczego tak? Na poziomie opisu user story najcz(cid:258)(cid:321)ciej opisy zawieraj(cid:238) szczegó(cid:298)y zwi(cid:238)zane z aktualnym (znanym Zamawiaj(cid:238)cemu z autopsji) sposobem pracy. W zakresie projektu jednak pozo- stanie jeden proces (czynno(cid:321)(cid:240)): Zamówienie, oznaczony stereotypem przypadek u(cid:353)ycia (stereotypy nie s(cid:238) cz(cid:258)(cid:321)ci(cid:238) notacji BPMN, stosuj(cid:258) je do wskazywania powi(cid:238)za(cid:300) pomi(cid:258)dzy obiektami w modelach BPMN i UML). Warto tu poda(cid:240) pewne wyja(cid:321)nienie. Z teorii komunikacji wiadomo, (cid:353)e zasadniczo nie mo(cid:353)na (niewprawiony i nie(cid:321)wiadomy zjawiska cz(cid:298)owiek praktycznie nie jest w stanie) unikn(cid:238)(cid:240) ska(cid:353)enia ka(cid:353)dego swojego przekazu w(cid:298)asnym do(cid:321)wiadczeniem, czyli znan(cid:238) sobie histori(cid:238). Dlatego pierwszym krokiem jest uogólnienie tre(cid:321)ci user story do poziomu abstrakcji: co i po co jest robione, gdy(cid:353) metody analizy bazuj(cid:238)ce na faktach zamiast na opisie Zamawiaj(cid:238)cego s(cid:238) wolne od tej przypad(cid:298)o(cid:321)ci. Mo(cid:353)na je jednak stosowa(cid:240) tylko w pewnych warunkach (o tym w dalszej cz(cid:258)(cid:321)ci ksi(cid:238)(cid:353)ki). Po stronie Zamawiaj(cid:238)cego (u(cid:353)ytkownika, dalej zwanego tak(cid:353)e aktorem) zastosowano uogólnienie bazuj(cid:238)ce na definicji procesu biznesowego: proces biznesowy to czynno(cid:321)(cid:240) lub logicznie powi(cid:238)zany (cid:298)a(cid:300)cuch czynno(cid:321)ci przekszta(cid:298)caj(cid:238)cy produkt na swoim wej(cid:321)ciu w pro- dukt (jego stan) na wyj(cid:321)ciu. Ró(cid:353)nica pomi(cid:258)dzy tymi produktami stanowi warto(cid:321)(cid:240) bizne- sow(cid:238) wnoszon(cid:238) przez dany proces. Po stronie Klienta mamy teraz tylko dwa takie procesy (czynno(cid:321)ci): Zamówienie oraz P(cid:298)at- no(cid:321)(cid:240). Czynno(cid:321)ci po stronie dostawcy (Nasza Firma Sp. z o.o.) zaniedbujemy, gdy(cid:353) system ma wprowadza(cid:240) automatyzacj(cid:258), wi(cid:258)c wdro(cid:353)enie oprogramowania wyeliminuje z obs(cid:298)ugi Zamówie(cid:300) elektronicznych cz(cid:298)owieka. Kolejn(cid:238) spraw(cid:238) s(cid:238) granice systemu. Przyjmijmy dwa za(cid:298)o(cid:353)enia, które wydaj(cid:238) si(cid:258) bar- dzo rozs(cid:238)dne: firma posiada system ERP oraz p(cid:298)atno(cid:321)ci elektroniczne b(cid:258)d(cid:238) przedmiotem outsourcingu. Tak wi(cid:258)c wymagania funkcjonalne dla systemu to: 1) przyjmowanie zamówie(cid:300), 2) przyjmowanie p(cid:298)atno(cid:321)ci drog(cid:238) elektroniczn(cid:238), 3) integracja z ERP: system ten odpowiada za ksi(cid:258)gowanie faktur i zarz(cid:238)dzanie ma- gazynem, 4) wykorzystanie zewn(cid:258)trznego operatora p(cid:298)atno(cid:321)ci elektronicznych. Powy(cid:353)sze wydaje si(cid:258) rozs(cid:238)dne i bywa cz(cid:258)sto spotykane (staram si(cid:258), by ten przyk(cid:298)ad nie odbiega(cid:298) przesadnie od rzeczywisto(cid:321)ci ;)). Warto, aby wymagania by(cid:298)y sformu(cid:298)owane zwi(cid:258)(cid:351)le, ale i nie wykracza(cid:298)y poza opis dzia(cid:298)a(cid:300), które powinny by(cid:240) mo(cid:353)liwe dzi(cid:258)ki no- wemu systemowi. Tak wi(cid:258)c diagram przypadków u(cid:353)ycia, jaki utworzy(cid:298)em, wygl(cid:238)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(cid:353)y si(cid:258) kilka s(cid:298)ów na temat tego diagramu. W zasadzie mamy jeden przy- padek u(cid:353)ycia: Zamówienie. P(cid:298)atno(cid:321)(cid:240) jest realizowana w ramach outsourcingu przez zewn(cid:258)trzny system (aktor System obs(cid:298)ugi p(cid:298)atno(cid:321)ci, strza(cid:298)ka z pe(cid:298)nym grotem skierowana w stron(cid:258) przypad- ku u(cid:353)ycia: Operator p(cid:298)atno(cid:321)ci realizuje ten przypadek u(cid:353)ycia). P(cid:298)atno(cid:321)(cid:240) jest inicjowana (Extend) w Systemie. System ERP odpowiada za faktury i magazyn (Zamówienie zale(cid:353)y od tego ERP — strza(cid:298)ka przerywana skierowana do ERP). Przypadek u(cid:353)ycia P(cid:298)atno(cid:321)ci le(cid:353)y poza granicami na- szego systemu (czyli poza zakresem projektu!). Ka(cid:353)dy przypadek u(cid:353)ycia powinien zosta(cid:240) udokumentowany co najmniej trzema elementami: 1) opisem stanu pocz(cid:238)tkowego (warunków pocz(cid:238)tkowych), 2) scenariuszem, 3) opisem oczekiwanego stanu ko(cid:300)cowego. Kontekst stanowi model procesów, wi(cid:258)c nie musimy tu pisa(cid:240), czym s(cid:238) poprzedzane i jakich maj(cid:238) nast(cid:258)pców poszczególne przypadki u(cid:353)ycia (diagram ten nie s(cid:298)u(cid:353)y do modelo- wania procesów!). Wystarczy w modelach zachowa(cid:240) tak zwane traceability ((cid:321)ladowanie). Osobi(cid:321)cie stosuj(cid:258) prost(cid:238) zasad(cid:258): nazwa przypadku u(cid:353)ycia jest taka sama jak czynno(cid:321)ci w modelu procesów, z której zosta(cid:298) wyprowadzony. Nazwy te s(cid:238) unikalne. Nie musimy tak(cid:353)e tworzy(cid:240) diagramów scenariuszy nadrz(cid:258)dnych (cid:298)a(cid:300)cuchów przypadków u(cid:353)ycia, bo zast(cid:258)puje je w(cid:298)a(cid:321)nie model BPMN. Na koniec jedna uwaga: przypadek u(cid:353)ycia powinien by(cid:240) samowy- starczalny, innymi s(cid:298)owy, musi mie(cid:240) sens jako sam jeden (sam z siebie s(cid:298)u(cid:353)y do wykonania jakiej(cid:321) logicznej czynno(cid:321)ci daj(cid:238)cej przydatny produkt). Kup książkęPoleć książkę Przypadki u(cid:352)ycia i granice systemu 75 Scenariusz przypadku u(cid:353)ycia najpro(cid:321)ciej i najskuteczniej jest opisywa(cid:240) w postaci dialogu Aktor — System. Ja najcz(cid:258)(cid:321)ciej stosuj(cid:258) prost(cid:238) tabel(cid:258) z kolumnami Aktor i System: AKTOR Inicjuje prac(cid:258). Zaznacza wybrane produkty i zatwierdza przyciskiem „OK”. Potwierdza zamówienie. Wybiera system p(cid:298)atno(cid:321)ci i zatwierdza przyciskiem „OK”. SYSTEM Wy(cid:321)wietla list(cid:258) produktów. Wy(cid:321)wietla tre(cid:321)(cid:240) zamówienia. Wy(cid:321)wietla dane o p(cid:298)atno(cid:321)ci. Ko(cid:300)czy i ewentualnie przekazuje sterowanie. Coraz cz(cid:258)(cid:321)ciej spotykam (i sam stosuj(cid:258)) te(cid:353) nast(cid:258)puj(cid:238)c(cid:238) konwencj(cid:258): 1. Inicjacja pracy. 2. SYSTEM wy(cid:321)wietla list(cid:258) produktów. 3. Zaznaczenie wybranego produktu i klikni(cid:258)cie przycisku „OK”. 4. SYSTEM wy(cid:321)wietla tre(cid:321)(cid:240) zamówienia. 5. Potwierdzenie zamówienia. 6. SYSTEM wy(cid:321)wietla dane o p(cid:298)atno(cid:321)ci. 7. Wybór systemu p(cid:298)atno(cid:321)ci i zatwierdzenie przyciskiem „OK”. 8. SYSTEM ko(cid:300)czy i ewentualnie przekazuje sterowanie. Ostatni krok to ewentualne przekazanie sterowania do systemu obs(cid:298)ugi p(cid:298)atno(cid:321)ci elek- tronicznych, je(cid:321)li Aktor zaznaczy(cid:298) tak(cid:238) opcj(cid:258) (alternatyw(cid:238) jest tylko wydruk formularza i kla- syczny przelew bankowy). Tworzenie diagramów przypadków u(cid:353)ycia w zasadzie warto traktowa(cid:240) tylko jako specy- fikacj(cid:258) koncepcji, zachowuj(cid:238)c ich zrozumia(cid:298)o(cid:321)(cid:240) dla laika. „B(cid:238)belki” przypadków u(cid:353)ycia po- winny by(cid:240) tylko specyfikacj(cid:238) funkcjonaln(cid:238) i niczym ponadto. Ten diagram i tak nie zast(cid:238)pi diagramu klas, sekwencji czy tym bardziej opisu procesu (tu by(cid:298) BPMN). Jak nietrudno chyba ju(cid:353) zauwa(cid:353)y(cid:240), dokumentacja zmierza w kierunku kilku prostych modeli (diagramów) zamiast jednego spaghetti-modelu. Cz(cid:258)sto spotykam si(cid:258) z dokumentami, w których autor analizy wymaga(cid:300) wszystko udokumentowa(cid:298) na diagramie przypadków u(cid:353)ycia (lub przynajmniej stara(cid:298) si(cid:258) to zrobi(cid:240)). Takie dokumentacje bywaj(cid:238) straszne. Na zako(cid:300)czenie przedstawi(cid:258) diagram komponentów obrazuj(cid:238)cy nasz projektowany sys- tem oraz te systemy, z którymi b(cid:258)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(cid:353)e klasy interfejsów I_ERP i I_P(cid:298)atno(cid:321)ci, klasy te s(cid:238) wykorzystywane w diagramach interakcji. Przy okazji warto wspomnie(cid:240) o Cloud Computing: komponenty integrowane mog(cid:238) by(cid:240) do- st(cid:258)pne „w chmurze”. W kolejnym rozdziale opisz(cid:258) model dziedziny systemu i model sekwencji dla przypadku u(cid:353)ycia. Nadmieni(cid:258) te(cid:353), (cid:353)e wci(cid:238)(cid:353) nie przedyskutowali(cid:321)my problemu wymaga(cid:300) niefunkcjonalnych! Kup książkęPoleć książkę
Pobierz darmowy fragment (pdf)

Gdzie kupić całą publikację:

Analiza biznesowa. Praktyczne modelowanie organizacji
Autor:

Opinie na temat publikacji:


Inne popularne pozycje z tej kategorii:


Czytaj również:


Prowadzisz stronę lub blog? Wstaw link do fragmentu tej książki i współpracuj z Cyfroteką: