Analiza_biznesowa_Praktyczne_modelowanie_organizacji_sfomod.pdf

(833 KB) Pobierz
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 ci
Wst p
1. Po co nam pan analityk?
2. Jak opracowa wymagania dla systemu informatycznego
Jaki to ma zwi zek z systemem informatycznym?
5
7
13
14
3. System zarz dzania informacj
Dwie definicje
a cuchy
17
18
21
4. Czym jest system CRM
Opis problemu
Czy dysk sieciowy rozwi zuje problem?
Pora na system CRM
25
25
29
30
5. Zasoby IT a procesy przetwarzania informacji
6. A na grzyba mi to modelowanie
Wi c jak to jest z tymi wymaganiami? Jak je wyspecyfikowa ?
35
39
40
7. O b dach w modelowaniu
Jak, co i po co modelowa
O analizie wymaga dla systemu IT
43
43
45
8. Potrzeby informacyjne a zarz dzanie wiedz
Potrzeby informacyjne firmy
Definicje
Model poj ciowy jako model rzeczywisto ci
Zarz dzanie wiedz
47
47
48
51
56
9. Historyjka u ytkownika — k opoty
10. Regu y biznesowe — czym s
11. Komunikacja, czyli analiza i projektowanie, oraz jak to zostanie odebrane
Model komunikacji
Jak to si ma do in ynierii oprogramowania
Na zako czenie
57
61
63
63
66
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
Dygresja budowlana — pouczaj ca przygoda
Diagram klas czy model dziedziny — co ma powsta ?
Model dziedziny systemu zamówienia
Diagram klas a model dziedziny systemu
Czy takie analizy maj sens w przypadku gotowych ERP?
A gdzie si podzia y wymagania pozafunkcjonalne?
77
77
78
79
81
85
85
14. Klient nasz pan
15. Wymagania dla oprogramowania ERP a analiza przedwdro eniowa
— gdzie jest ró nica?
Kupujemy buciki
Jak wykona patyczek?
Co zawiera taki model?
87
91
91
92
93
16. Udzia owcy projektu, czyli diagramy UML
Modelowanie zale no ci pomi dzy udzia owcami
UML i diagramy przypadków u ycia jako model udzia owców
Analiza RACI
95
96
96
100
17. Analityk biznesowy, czyli wypleni dwuznaczno
z dokumentów
101
103
103
105
107
117
119
18. Plansza do gry w szachy, czyli analiza i projektowanie
Cel zamawiaj cego
Model poj ciowy — zrozumie problem i cel projektu
Model procesu biznesowego — zrozumie , co i po co jest robione
Zarz dzanie wymaganiami
Na zako czenie
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ę
Zgłoś jeśli naruszono regulamin