Projektowanie systemów informatycznych
Elementy systemu CRM
(Customer Relationship Management)
Projekt zrealizowany na zajęciach:
Projektowanie Systemów Informatycznych
pod kierunkiem dr hab. prof. UW. Mirosławy Lasek
Aneta Dzik 219088
Anna Kalinowska
Informatyka i Ekonometria
IV rok, 2 semestr
6 czerwca 2006, Warszawa
1
Projektowanie systemów informatycznych
Spis treści.
1. Treść zadania projektowego.
2. Cel budowy systemu, zakres, przewidywane korzyści z wdrożenia.
3. Perspektywa przypadków użycia systemu.
3.1. Diagram przypadków użycia systemu.
3.2. Opisy tekstowe aktorów.
3.3. Opisy przypadków użycia i przykładowe diagramy czynności.
4. Diagramy interakcji/sekwencji.
5. Perspektywa logiczna.
5.1. Diagram klas.
5.2. Alfabetyczny wykaz wszystkich klas wraz z opisem,
zidentyfikowanymi atrybutami i operacjami.
5.3. Diagramy stanów dla wybranych klas.
6. Wymagania niefunkcjonalne dla systemu.
6.1. Oszacowanie wielkości bazy danych.
6.2. Wymagane czasy odpowiedzi dla systemu.
6.3. Oszacowanie ilości i typów potrzebnych stanowisk
użytkowników.
6.4. Inna wymagania
7. Propozycja technologii informatycznych.
8. Propozycja planu projektu.
8.1. Wyróżnione etapy i zadania, czas ich realizacji.
8.2. Zależności między etapami i analiza zadań ścieżki krytycznej.
9. Analiza ryzyka projektu.
10.Podsumowanie.
11.Literatura.
2
Projektowanie systemów informatycznych
1. Treść zadania projektowego.
Praca jest projektem systemu niezbędnego, jak się dziś wydaje, w firmie
telekomunikacyjnej, systemu CRM (Customer Relationship Management).
CRM- zarządzanie relacjami z klientami to ogół czynności polegających na
odnotowywaniu wszelkich kontaktów z każdym klientem z osobna i
podejmowaniu odpowiednich decyzji. Aplikacje CRM powinny dawać
możliwość efektywnego zarządzania kontaktami z klientami prowadząc do
nadrzędności tego podejścia w ramach ogólnej strategii firmy.
2. Cel budowy systemu, zakres, korzyści z wdrożenia.
System jest przeznaczony dla firmy telekomunikacyjnej która planuje
wprowadzić system CRM.
Umożliwia prowadzenie polityki ciągłego doskonalenia procesu
świadczonych usług i oferowanych produktów.
Celem systemu CRM jest umożliwienie organizacji go stosującej, dbania o
zadowolenie, zaufanie i utrzymanie oraz lojalność klientów. System
pozwala na możliwie najlepsze wykorzystanie potencjału nabywczego
klientów przez odpowiednie reagowanie na ich potrzeby, formowanie
produktów i oferty.
Przewidywaną korzyścią jest wzrost ilości nowych klientów firmy.
Podstawowym zakresem, który ma spełniać system jest obsługa klientów
dzwoniących lub wysyłających wiadomości e-mail z zapytaniami. Pytania
osób można pogrupować w następujące klasy problemów:
Dana osoba nie jest jeszcze abonentem, jednakże chciałaby
uzyskać informacje na temat produktów i usług świadczonych.
Osoba dzwoniąca jest już abonentem i ma problem natury
technicznej z aparatem lub wyposażeniem dodatkowym. Z jakiś
powodów sprzęt nie chce działać lub działa w sposób nieprawidłowy.
Abonent chce zmienić zakres usług mu świadczonych przez
zwiększenie / zmniejszenie ilości tych usług.
Dana osoba składa reklamację świadczonych jej usług: kwestionuje
kwotę którą ma do zapłacenia.
Osoba chce zmodyfikować swoje dane (między innymi: nazwisko,
miejsce zamieszkania, numer identyfikacyjny telefonu, z którego
korzysta, itp.)
Abonent chce zgłosić informacje o zgubieniu / kradzieży aparatu.
Chce aby numer telefonu został zablokowany.
Zadaniem systemu jest informowanie klientów o prowadzonej działalności
firmy. Informacja ta będzie dotyczyła: nowych modeli telefonów
dostępnych w ofercie, nowych opłat abonamentowych, nowych serwisach
3
Projektowanie systemów informatycznych
udostępnionych abonentom. Kanały komunikacyjne w tym przypadku to:
rozsyłanie SMSów, dzwonienie, korespondencja listowna oraz wysyłanie
maili.
System informuje osoby z nim pracujące o abonentach, którzy nie
uregulowali rachunków telefonicznych, ponadto system rozsyła SMS y do
osób zalegających z opłatami.
Operator obsługujący zlecenie klienta (czy to telefoniczne, czy też poprzez
e-mail) może wybrać jedną operację wykonać aktywność z ograniczonego
zbioru operacji.
Manager operatorów zarządza ich czasem pracy, monitoruje efektywność
pracy, kontroluje problemy z którymi mieli do czynienia i w jaki sposób
sobie z nimi poradzili. Wszystkie zgłaszania do systemu są rejestrowane
(czy to w przypadku rozmów telefonicznych czy też maili ). Manager może
konfigurować część z parametrów systemu, którymi tenże zarządza.
Manager może dodawać, usuwać, modyfikować zarówno pracowników jak
również operacje które oni mogą wykonywać. Operator może wybrać
rozwiązanie korzystając z  podpowiedzi , jednakże aby skorzystać z tej
opcji musi odpowiedzieć na kilka pytań, a system sam, używając modułu
eksperckiego podsunie kilka scenariuszy rozwiązania = kilka operacji,
które może wykonać operator. W podobny sposób może postąpić operator
doradzając wybór sprzętu lub usługi. Wszyscy abonenci, o których
informacje znajdują się w systemie, są posegmentowani. Na podstawie
odpowiedzi na kilka pytań potencjalny klient jest zaszeregowany do jednej
z kategorii klientów. Operator pracujący z systemem ma możliwość
podglądu danych klienta (o ile jest on abonentem), historii jego zgłoszeń,
problemów z którymi miał do tej pory do czynienia.
4
Projektowanie systemów informatycznych
3. Perspektywy przypadków użycia.
3.1. Diagram przypadków użycia systemu.
usuniecie operatora
zgloszenie kradziezy
dodanie operatora
klient
<>
manager
info o uslugach
wyloguj
<>
zaloguj rozmowa z klientem
<>
<>
pobranie informacji
<>
aktywacja/deaktywacja uslugi
info o sprzecie
operator
<>
<>
<>
WAP
zdanie raportu
internet
roaming
3.2. Aktorzy
Klient
Aktor na rzecz którego wykonywane są jakieś operacje w celu
obsłużenia jego zgłoszenia.
Manager
Pracownik firmy, który nadzoruje prace operatorów. Otrzymuje
statystyki odnośnie pracy wszystkich operatorów. Może dodawać,
usuwać, modyfikować dane o operatorach, a także o zadaniach.
Operator
Pracownik firmy podlegający managerowi, obsługuje zlecenia
klienta, posiada nadane mu przez managera uprawnienia dostępu
do systemu.
5
Projektowanie systemów informatycznych
3.3. Przypadki użycia
3.2.1. Aktywacja/deaktywacja usługi
Uczestnicy: klient, operator.
Jednym z powodów dla którego klienci dzwonią do Call-Center jest
aktywowanie lub deaktywowanie jakiejś usługi. Klient może
aktywować następujące rodzaje usług: dostęp do Internetu przez
komórkę, dostęp do Internetu za pośrednictwem WAP, wykupienie
Roamingu na dany kraj na świecie.
Zidentyfikowane sekwencje zdarzeń:
- autentykacja klienta
- wybór rodzaju zadania, aktywacja/ deaktywacja
- wybór usługi
- sprawdzenie czy realizacja usługi jest możliwa
- wykonanie zadania lub poinformowanie o niemożności jego
wykonania.
Częstość realizacji:
- prawdopodobnie wiele razy dziennie dla różnych klientów, w
zależności od ich potrzeb.
Czas realizacji:
- uzależniony od rodzaju usługi i cech klienta, typowy około
3minut, maksymalny 15minut.
Wyniki po zakończeniu przypadku użycia:
- klient, który chciał aktywować usługę i był do tego
uprawniony aktywował ją
- klient, który chciał deaktywować aktywną usługę
deaktywował ją.
6
Projektowanie systemów informatycznych
Aktywacja/deaktywacja usługi- diagram czynności.
autentykacja
klienta
[ aktywacja ]
[ deaktywacja ]
wybranie
wybranie rodzaju uslugi
rodzaju uslugi
do deaktywowania
sprawdzenie czy klient ma
sprawdzenie czy klient ma
juz aktywowana usluge
aktywowana usluge
[ nie ]
[ tak ]
sprawdzenie czy klient
poinformowanie o
deaktywowanie
moze aktywowac usluge
niemoznosci deaktywacji
[ tak ]
poinformowanie o niemoznosci
aktywowanie
aktywowania uslugi
uslugi
3.2.2. Dodanie operatora
Uczestnicy: manager.
Manager posiadający odpowiednie uprawnienia co się przekłada na
dostęp do odpowiednich fragmentów systemu, wprowadza do
systemu dane o nowym operatorze, wprowadzając jego potrzebne
dane personalne i kwalifikacje.
Zidentyfikowane sekwencje zdarzeń:
- otworzenie odpowiedniego okna
- podanie danych operatora
- sprawdzenie czy operator nie został już dodany
- dodanie operatora.
7
Projektowanie systemów informatycznych
Częstość realizacji:
- w zależności od potrzeby zatrudnienia nowego pracownika i
wielkości firmy, prawdopodobnie kilka/kilkanaście razy w
roku.
Czas realizacji:
- typowy:20 minut
Wyniki po zakończeniu przypadku użycia:
- operator znajduje się w bazie pracowników-operatorów,
uaktualniona baza operatorów
Dodanie operatora- diagram czynności.
zadanie dodania
operatora
podaj dane nowego
operatora
czy juz taki
[ tak ]
istnieje
[ nie ]
wyswietl komunikat o niemoznosci zapisz w systemie
dodania operatora informacje o operatorze
wyswietl komunikat
o dodaniu operatora
8
Projektowanie systemów informatycznych
3.2.3. Informacja na temat sprzętu
Uczestnicy: klient, operator.
Dzwoniący klient może dowiedzieć się na temat telefonów i
urządzeń oferowanych obecnie w sieci. Może także dowiedzieć się
na temat ich cen, promocji itd.
Zidentyfikowane sekwencje zdarzeń:
- uzyskanie przez klienta informacji na temat sprzętu.
Częstość realizacji:
- w zależności od wielkości firmy, liczby klientów, w średniej
wielkości firmach telekomunikacyjnych ponad 1000 razy
dziennie.
Czas realizacji:
- typowy około 3minut.
Wyniki po zakończeniu przypadku użycia:
- klient uzyskuje interesujące go informacje, co może
prowadzić do zakupu nowego sprzętu.
3.2.4. Informacja na temat usług.
Uczestnicy: klient, operator.
Tak jak w przypadku informacji na temat sprzętu, klient może także
się dowiedzieć jakie są obecnie świadczone przez operatora usługi.
Zidentyfikowane sekwencje zdarzeń:
- uzyskanie przez klienta informacji na temat usług.
Częstość realizacji:
- w zależności od wielkości firmy, liczby klientów, w średniej
wielkości firmach telekomunikacyjnych ponad 1000 razy
dziennie.
Czas realizacji:
- typowy około 3minut.
Wyniki po zakończeniu przypadku użycia:
- klient uzyskuje interesujące go informacje, co może
prowadzić do aktywowania nowej usługi.
3.2.5. Internet.
Uczestnicy: klient, operator.
Jest to wybór usługi związanej z dostępem do Internetu za
pośrednictwem telefonu komórkowego.
9
Projektowanie systemów informatycznych
Jest to szczegółowy przypadek przypadku użycia aktywowanie/
deaktywowanie usługi.
3.2.6. Pobranie informacji.
Uczestnicy: klient, operator.
Często do Call-Center dzwonią osoby, które jeszcze klientami firmy
nie są, a chcą się tylko dowiedzieć o dostępne telefony, bądz
o
świadczone w danej chwili usługi.
Jest to ogólny przypadek użycia obejmujący dwa szczegółowe: info
na temat usług, info na temat sprzętu.
3.2.7. Roaming.
Uczestnicy: klient, operator.
Jest to kolejna usługa, którą może zamówić klient.
Jest to szczegółowy przypadek przypadku użycia aktywowanie/
deaktywowanie usługi.
3.2.8. Rozmowa z klientem.
Uczestnicy: klient, operator.
Jest to podstawowy przypadek użycia, który można wyobrazić sobie
przy modelowaniu systemu CRM dla Call-Center. Operatorzy
znajdujący się w siedzibie firmy odbierają zgłoszenia telefoniczne
klientów i podejmują pewne reakcje na nie.
Zidentyfikowane sekwencje zdarzeń:
- automatyczne odebranie rozmowy
- wybór klienta jakich informacji potrzebuje
- ewentualna nagrywana rozmowa z operatorem
- zarejestrowanie zadania
- wykonanie zadania
- rozłączenie
Częstość realizacji:
- w zależności od wielkości firmy, liczby klientów, w średniej
wielkości firmach telekomunikacyjnych ponad 1000 razy
dziennie.
Czas realizacji:
- typowy około 3minut.
Wyniki po zakończeniu przypadku użycia:
- klient uzyskuje interesujące go informacje, co może
prowadzić do zakupu nowego sprzętu bądz
aktywowania/
deaktywowania usługi.
10
Projektowanie systemów informatycznych
Rozmowa z klientem- diagram czynności.
sygnalizacja nadejscia
nowego zgloszenia
automatyczne
odebranie roz mowy
wybor przez klienta
jakich info potrzebuje
zarejestrowanie
faktu polaczenia
operacja wymagajaca
kontaktu z czlowiek iem
[ tak ]
interakcja klienta z
zgloszenie sie
automatem
operatora
wlaczenie
nagrywania
jesli dlugi czas bezczy nnosci
[ tak ] lub rozlaczenie przez klienta
zarejestrowanie
zadania klienta
wykonanie
zadania
rozlaczenie
wylaczenie
nagrania
11
Projektowanie systemów informatycznych
3.2.9. Usuniecie operatora.
Uczestnicy: manager
Pracownik posiadający odpowiednie uprawnienia, co się przekłada
na dostęp do odpowiednich fragmentów systemu, usuwa
pracownika z systemu, wydając mu świadectwo pracy. Informacje o
pracach i odpowiedzialności użytkownika pozostają w systemie.
Zidentyfikowane sekwencje zdarzeń:
- otworzenie odpowiedniego okna
- wybranie odpowiedniego operatora
- usunięcie operatora= zapisanie jako byłego operatora.
Częstość realizacji:
- w zależności od potrzeby zwolnienia/ odejścia pracownika i
wielkości firmy, prawdopodobnie kilka/kilkanaście razy w
roku.
Czas realizacji:
- typowy:5 minut.
Wyniki po zakończeniu przypadku użycia:
- operator znajduje się w bazie byłych pracowników-
operatorów, uaktualniona baza operatorów.
Usuniecie operatora- diagram czynności.
zadanie usuniecia
operatora
wybierz operatora ktorego
chcesz usunac
usun z systemu info
o operatorze
12
Projektowanie systemów informatycznych
3.2.10. WAP
Uczestnicy: klient, operator.
Wybór usługi związanej z dostępem do Internetu poprzez WAP.
Jest to kolejna usługa, którą może zamówić klient.
Jest to szczegółowy przypadek przypadku użycia aktywowanie/
deaktywowanie usługi
3.2.11. Wyloguj
Uczestnicy: manager, operator.
Użytkownik wylogowany z systemu kończy prace.
Zidentyfikowane sekwencje zdarzeń:
- Wylogowanie użytkownika
Częstość realizacji:
- Każdego dnia pracy, każdy użytkownik systemu (operator,
manager)
Czas realizacji:
- typowy:<1minuta
3.2.12. Zaloguj
Uczestnicy: manager, operator.
Aktor, chcąc podjąć współpracę z systemem, musi być
zweryfikowany, ze może z tym systemem współpracować. Dalsze
działania aktora w systemie zakładają, ze system wie, z kim ma do
czynienia i na tej podstawie określa póz
niej uprawnienia do
podejmowania poszczególnych działań w systemie.
Zidentyfikowane sekwencje zdarzeń:
- Podaj dane
należy podać identyfikator i hasło
- Zweryfikuj dane
sprawdzenie poprawności wpisanych danych, jeśli są
one zgodne z tymi zapisanymi w systemie, wówczas
aktor może rozpocząć pracę i jest rozpoznawany w
13
Projektowanie systemów informatycznych
systemie. W przeciwnym przypadku należy ponowić
próbę.
Częstość realizacji:
- Każdego dnia pracy
Czas realizacji:
- typowy:<1minuta
Wyniki po zakończeniu przypadku użycia:
- aktor może wykonywać swoją pracę, jest rozpoznawany
przez system.
Podaj dane
Zweryfikuj dane
[ dane nieprawidlowe ]
[ dane poprawne ]
3.2.13 Zdanie raportu.
Uczestnicy: operator.
Operatorzy co pewien czas (np. co miesiąc ) zobowiązani są do
tworzenia i przesyłania raportów z działalności za ostatni okres i
przesyłanie to do kierowników wyższych szczebli.
Zidentyfikowane sekwencje zdarzeń:
14
Projektowanie systemów informatycznych
- Utwórz raport
- Przekaż do zatwierdzenia (manager musi zatwierdzić raport
przygotowany przez operatora, w razie braku akceptacji
operator tworzy nową wersje raportu)
- Prześlij i archiwizuj (gotowy raport jest przesyłany
zwierzchnikom i archiwizowany)
Wyniki po zakończeniu przypadku użycia:
- gotowy, wysłany raport, będący podstawą wielu decyzji.
Utwórz raport
Przekaz do
[ do poprawy ]
zatwierdzenia
[ zatwierdz ony ]
Przeslij Archiwizuj
3.2.14. Zgłoszenie kradzieży telefonu.
Uczestnicy: klient, operator.
Jest to dość szczególny przypadek użycia, gdyż wiąże się z utrata
przez klienta jakiejś wartości materialnej i w takim przypadku
15
Projektowanie systemów informatycznych
należy bardzo uważnie zająć się takim przypadkiem, odpowiednio
modelując go w systemie.
Zidentyfikowane sekwencje zdarzeń:
- Wprowadz
dane identyfikujące telefon i abonenta (klient
podaje swoje dane i numer telefonu)
- Uwierzytelnij abonenta
- Zablokuj kartę SIM
- Modyfikuj rekord w bazie abonentów
Częstość realizacji:
- Kilka, kilkanaście zgłoszeń dziennie
Czas realizacji:
- typowy:7 minut
- maksymalny:15 minut
Wprowadz dane
abonenta i telefonu
[ nieprawidlowe ]
Uwierzytelnij
abonenta
[ prawidlowe dane ]
Zablokuj karte
SIM
Modyfikuj rekord w
bazie abonentów
16
Projektowanie systemów informatycznych
4. Diagramy interakcji/sekwencji.
Diagramy interakcji to modele, które opisują w jaki sposób współpracują
ze sobą grupy obiektów. Zwykle diagram sekwencji przedstawia
zachowanie systemu dotyczące jednego przypadku użycia. Obrazuje
obiekty i komunikaty przez nie wymieniane w ramach przypadku użycia.
Poniżej przedstawiamy diagramy interakcji dla wybranych przypadków
użycia.
Aktywacja/ deaktywacja usługi
:konsola :sys tem :baza :abonent
:operator
operatora abonentow
zmien aktywnosc uslugi
zmien aktywnosc uslugi abonenta
znajdz abonenta
zmien aktywnosc uslugi
modyfikuj rekord
Pierwszym krokiem operatora jest wpisanie nazwy odpowiedniej usługi,
której aktywność ma być zmieniona. W wyniku tego wysyłana jest
informacja do systemu. Następnie odszukiwany jest odpowiedni abonent
w bazie abonentów. W kolejnym kroku system zmienia aktywność usługi o
czym abonent jest informowany.
17
Projektowanie systemów informatycznych
Rozmowa z klientem.
: konsola : system : baza
: operator
operatora abonentow
zarejetruj rozmowe
zarejestruj rozmowe
wpisz rekord zgloszenia
Każda rozmowa z klientem jest rejestrowana, a zgłoszenie jest
odnotowywane w bazie abonentów.
Usunięcie operatora.
: konsola : system : baza
: manager
managera uzytkownikow
usun operatora sprawdz czy istnieje uzytkownik
usun katalog operatora
usun rek ord uzytkownika
Na początku manager wyraża chęć usunięcia operatora. Następnie system
sprawdza czy dana osoba jest obecnie pracownikiem i usuwa operatora co
jest potem odnotowywane w bazie użytkowników.
18
Projektowanie systemów informatycznych
Wylogowanie.
: konsola : system : baza
: operator
uzytkownikow
wyloguj ( )
sprawdz
czy zalogowany ( )
zarejestruj wylogowanie ( )
Zalogowanie.
: konsola : system : baza
: operator
uzytkownikow
zaloguj ( )
sprawdz czy istnieje uzytkownik ( )
sprawdz login i haslo ( )
zarejestruj zalogowanie ( )
19
Projektowanie systemów informatycznych
Diagram współpracy odpowiadający diagramowi sekwencji
zalogowanie.
: ba z a
: operat or
uz y t k ownik ow
8: 1: zalog uj ( )
5: zarej est ruj zal ogow a6: e ( )
ni
2: s prawdz c z y is t nieje uz y t k ownik ( )
4: sprawdz login i haslo ( )
: konsola : s y s t em
3:
7:
Zgłoszenie kradzieży telefonu.
: konsola : system : baza
: operator
operatora abonentow
zablokuj karte SIM ( )
zablokuj karte SIM ( )
modyfikuj rekord ( )
W przypadku kradzieży operator na prośbę klienta zgłasza konieczność
zablokowania karty SIM, co jest wykonywane przez system oraz
odnotowywane w bazie abonentów.
20
Projektowanie systemów informatycznych
Diagram współpracy odpowiadający diagramowi sekwencji
zgłoszenie kradzieży telefonu.
1: z ablok uj k arte S IM ( )
: k ons ola
op erat ora
6:
: operator
5:
2: z ablok uj k arte S IM ( )
3: m ody fik uj rek ord ( )
: system : baz a
abonen tow
4:
5. Perspektywa logiczna.
Diagram klas opisuje typy obiektów w systemie i różne rodzaje
statystycznych relacji między nimi. Obrazuje również atrybuty i operacje
klas oraz ograniczenia tego w jaki sposób obiekty mogą być powiązane.
21
Projektowanie systemów informatycznych
usluga
nazwa uslugi
baza uslug
dostepna w systemie
znajdz usluge()
sprawdz czy dostepna()
1..n
1..n
1
1
wyswietl wszystkie uslugi()
uzytkownik zmien dostepnosc()
sprawdz czy istnieje()
ustaw nazwe()
imie
pobierz nazwe()
nazwisko
1
1
login
1..n
1..n
haslo
Sprzet
baza sprzetu
nazwa
zmien haslo()
cena dostepnosc uslugi
1..n 1
1..n 1
wyswietl nazwisko() podaj nazwe sprzetu()
promocja
aktywna
pokaz liste sprzetu()
1..n
1..n
pokaz promocje()
pokaz cene()
sprawdz czy aktywna()
podaj cene()
podaj nazwe()
zmien aktywnosc()
sprawdz czy istnieje()
sprawdz promocje()
1
1
1..n
1..n
1
1
1
1
abonent
system
imie
1
1
nazwisko
sprawdz loginn haslo()
baza uzytkownika
numer karty SIM
Przez klase abonent
zarejestruj uzytkownik a w systemie()
baza abonentow
numer telefonu
rozumiemy wykupina
wyrejestruj uzytkownika z systemu()
dodaj rekord uzytkownika()
przez klienta karte SIM,
sprawdz cz y istnieje uzytkownik()
1
usun rekord uzytkownika() 1 znajdz abonenta()
1
1 zmien aktywnosc uslugi()
podpisana przez niego
dodaj katalog operatora()
modyfikuj rekord uzytkownika() sprawdz czy istnieje()
zablokuj karte SIM()
umowe. Tak wiec czlowiek
ustaw login i haslo operatora()
1 1 1 1..n
sprawdz stan uzytkownika() 1 1 1 1..n
modyfikuj rekord()
podaj informacje o abonencie()
z realnego s wiata moze
ustaw katalog operatora()
zarejestruj zalogowanie() wpisz rekord zgloszenia()
zarejestruj zgloszenie()
wy stepowac jako wielu
sprawdz login i haslo()
zarejestruj wylogowanie()
uslugi aktywne()
abonetow
zarejestruj rozmowe()
uslugi dostepne()
zablokuj karte SIM()
zarejestruj zgloszenie()
zmien aktywnosc uslugi abonenta()
wyswietl wszystkie zgloszenia()
sprawdz cz y zalogowany()
1 1
1 1
1..n
1..n
konsola
1..n
1..n
wlasciciel konsoli
stan konsoli
zgloszenie
data zgloszenia
zaloguj()
nazwa zgloszenia
wys lij komunikat o bledz ie()
rezultat
konsola operatora
wyloguj() konsola managera
sprawdz rezultat()
zarejestruj rozmowe()
dodaj operatora() ustaw rezultat()
zablokuj karte SIM()
usun operatora() ustaw nazwe()
zmien aktywnosc uslugi()
zatwierdz raport() sprawdz nazwe()
przeszukaj baze()
pobierz date()
22
5.2. Wykaz i opis klas
Abonent
Klasa reprezentująca właściciela karty SIM, czyli osobę, która odpisała
umowę z operatorem. Jedna osoba może być właścicielem wielu kart SIM,
a tym samym odpowiadać wielu abonentom.
atrybuty:
o imię
o nazwisko
o numer karty SIM  numer karty SIM jednoznacznie
identyfikuje abonenta
o numer telefonu
operacje:
o zmień aktywność usługi  aktywuje/deaktywuje usługę dla
danego abonenta
o zablokuj kartę SIM
o podaj informacje o abonencie
o zarejestruj zgłoszenie  powoduje zachowanie informacji w
systemie o wystąpieniu zgłoszenia wykonanego przez danego
abonenta
o usługi aktywne- podaje aktywne usługi danego abonenta
o usługi dostępne-podaje jakie usługi są dostępne dla danego
abonenta
o wyświetl wszystkie zgłoszenia  wyświetla informacje o
wszystkich zgłoszeniach jakich dokonał dany abonent
Baza abonentów
Służy zarządzaniu bazą abonentów. Pozwala na wyszukiwanie, dodawanie
i usuwanie abonentów, rejestruje także informacje o zgłoszeniach.
operacje:
o znajdz
abonenta
o sprawdz
czy istnieje  sprawdza, czy dany klient figuruje w
systemie jako abonent
o modyfikuj rekord  modyfikuje rekordy w bazie abonentów
(usuwa lub dodaje nowych)
o wpisz rekord zgłoszenia-rejestracja podstawowych informacji
o zgłoszeniu w bazie
Baza sprzętu
Służy zarządzaniu bazą sprzętów, pozwala na przeglądaniu informacji o
sprzęcie, jego cenie oraz o istniejących promocjach.
operacje:
o podaj nazwę sprzętu
Projektowanie systemów informatycznych
o pokaż listę sprzętu
o pokaż promocje  pokazuje listę sprzętów objętych ofertą
promocyjną wraz z warunkami promocji
o podaj cenę
o sprawdz
czy istnieje
Baza usług
Pozwala na zarządzanie bazą usług. Umożliwia wyszukiwanie usług.
operacje:
o znajdz
usługę
o wyświetl wszystkie usługi
o sprawdz
czy istnieje
Baza użytkowników
Służy zarządzaniu bazą użytkowników (operatorów i managerów).
Umożliwia dodawanie, usuwanie i modyfikowanie rekordów użytkowników.
Rejestruje także każdorazowe zalogowanie i wylogowanie użytkownika w
systemie.
operacje:
o dodaj rekord użytkownika
o usuń rekord użytkownika
o modyfikuj rekord użytkownika
o sprawdz
stan użytkownika
o zarejestruj zalogowanie
o zarejestruj wylogowanie
Dostępność usługi
Klasa asocjacyjna opisująca relacje między abonentem a usługą.
atrybuty
o aktywna - atrybut wskazujący czy dana usługa jest aktywna
dla danego abonenta
Konsola
Umożliwia użytkownikom(operatorom i managerom) wykonywanie
obowiązków, przejmuje polecenia od użytkowników i kieruje je do
systemu.
atrybuty:
o właściciel konsoli  każdy użytkownik poprzez unikalny login i
hasło loguje się do własnej konsoli.
o stan konsoli  konsola może być w danej chwili używana
(zalogowany użytkownik) lub niewykorzystywana
24
Projektowanie systemów informatycznych
operacje:
o zaloguj
o wyświetl komunikat o błędzie  wyświetla komunikat o
wprowadzeniu błędnych danych
o wyloguj
Konsola managera
Rodzaj konsoli, której właścicielem jest manager.
operacje:
o dodaj operatora
o usuń operatora
o zatwierdz
raport  pozwala na przeczytanie i zatwierdzenie
(bądz
odesłanie operatorowi) comiesięcznego raportu
Konsola operatora
Rodzaj konsoli, której właścicielem jest operator.
operacje:
o zarejestruj rozmowę
o zablokuj kartę SIM
o zmień aktywność usługi
o przeszukaj bazę  umożliwia operatorowi wyszukanie
informacji o sprzęcie, abonentach i usługach (odpowiednie
bazy)
Sprzęt
Klasa reprezentujący sprzęt telefoniczny jaki ma do zaoferowania swoim
klientom firma.
atrybuty
o nazwa
o cena
o promocja  wskazuje, czy dany sprzęt jest aktualnie objęty
ofertą promocyjną
operacje:
o podaj nazwę
o pokaż cenę
o sprawdz
promocję
25
Projektowanie systemów informatycznych
System
Główna klasa w naszym systemie. Klasa ta jest warstwą pośrednicząca w
kontakcie pomiędzy poszczególnymi komponentami systemu, w
szczególności konsolą użytkownika, a różnymi bazami.
operacje:
o sprawdz
login i hasło
o zarejestruj użytkownika w systemie
o wyrejestruj użytkownika z systemu
o sprawdz
czy istnieje użytkownik
o dodaj katalog operatora  gdy manager dodaje nowego
operatora tworzony jest jego katalog
o ustaw login i hasło operatora - przy dodawaniu nowego
operatora ustala się jego login i hasło
o zarejestruj rozmowę
o zablokuj kartę SIM
o zmień aktywność usługi abonenta  aktywuje/deaktywuje
usługi dla poszczególnych abonentów
o sprawdz
czy zalogowany
Usługa
Klasa reprezentuje usługi świadczone przez operatora telefonii
komórkowej abonentowi.
atrybuty:
o nazwa usługi
o dostępna - atrybut wskazujący czy dana usługa jest dostępna
w systemie.
operacje
o sprawdz
czy dostępna  sprawdza czy usługa jest dostępna w
systemie
o zmień dostępność
o ustaw nazwę
o pobierz nazwę
Użytkownik
Klasa reprezentuje użytkowników systemu, czyli operatorów i managerów.
atrybuty:
o imię
o nazwisko
o login
o hasło
26
Projektowanie systemów informatycznych
operacje
o zmień hasło
o podaj nazwisko
Zgłoszenie
Klasa reprezentuje zgłoszenia napływające do systemu (wszystkie telefony
i wiadomości e-mail od klientów)
atrybuty:
o data zgłoszenia
o nazwa zgłoszenia
o rezultat  wskazuje na to czy problem abonenta został
pomyślnie rozwiązany, czy uzyskał potrzebne informacje
operacje
o sprawdz
rezultat
o ustaw rezultat
o ustaw nazwę
o sprawdz
nazwę
o pobierz datę
27
Projektowanie systemów informatycznych
5.3. Diagramy stanów dla wybranych klas.
Diagramy stanów są techniką opisu zachowania systemu. Opisują one
wszystkie możliwe stany, do których może przejść dany obiekt, oraz to,
jak zmienia się stan obiektu pod wpływem zdarzeń do niego
docierających. Zazwyczaj rysujemy je dla pojedynczych klas, by pokazać
cały cykl życia pojedynczego obiektu.
5.3.1 Abonent i jego możliwości w systemie
Abonent może skontaktować się z systemem na dwa sposoby  wysłać
e-mail lub zadzwonić na bezpłatną linie informacyjną.
skontaktuj sie
oczekiwanie
otrzymanie odpowiedzi
exit/ zapisz informacje o zgloszeniu
[ nie wszystko zalatwione ]
rozmowa
exit/ zapisz informacje o zgloszeniu
/ rozlacz
28
Projektowanie systemów informatycznych
5.3.2 Użytkownik i jego możliwości w systemie
W systemie użytkownik może być zalogowany jako operator lub manager,
co daje odmienne możliwości i uprawnienia.
zaloguj
Weryfikacja
[ nieprawidlowe ]
odrzucone
do/ sprawdz prawidlowosc danych
[ manager ] [ operator ]
Zalogowany / wyloguj / wyloguj Zalogowany
jako manager j ako operat or
[ raport niezatwierdzony ]
przygotowanie raportu
do/ napisz raport
exit/ przeslij raport
usuwanie
dodawanie
operatora
operatora
Rozmowa z klientem
entry/ weryfikacja uzyt kownika
zatwierdzanie
raportu
29
Projektowanie systemów informatycznych
5.3.3 Diagram stanów odpowiadający klasie usługa.
Nowa usługa zostaje wprowadzona do systemu i pojawia się jako usługa
dostępna w systemie. Usługi zostają przypisane do poszczególnych ofert i
planów taryfowych, wobec czego stają się dostępne danym abonentom.
Abonent może aktywować/deaktywować dostępną mu usługę. Dana
usługa może przestać być dostępna dla danego użytkownika, na przykład
gdy zmienia on swój plan taryfowy.
Usługa może także nie być dostępna w całym systemie, na przykład w
przypadku awarii technicznej. W takim przypadku można ją z powrotem
udostępnić, gdy awaria zostanie usunięta, lub też całkowicie usunąć
systemu, gdy firma rezygnuje z oferowania jej klientom
dodaj usluge
usluga dostepna w
systemie
udostepnij usluge
usluga dostepna
dla abonenta
aktywuj
deaktywuj
niedostepna
aktywna
abonentowi
niedostepna w
systemie
usun usluge
30
Projektowanie systemów informatycznych
6. Wymagania niefunkcjonalne dla systemu.
6.1.Oszacowanie wielkości bazy danych
W systemie będą cztery bazy: baza użytkowników przechowująca
informacje na temat pracowników firmy  operatorów i managerów, baza
sprzętu (dane o sprzęcie telefonicznym, jaki firma oferuje klientom), baza
usług, baza abonentów.
W firmie pracuje 100 operatorów i 5 managerów, na przechowywanie
danych na ich temat wystarczy ok. 60kB
użytkownicy: 100+5 = 105 x 512 B=-=60kB
Firma oferuje swym klientom ok. 1000 rożnych urządzeń (telefonów,
zestawów słuchawkowych i innych akcesoriów) Do przechowywania tych
danych potrzeba będzie ok. 500 kB
sprzęt 1000 x 512 B = 500kB
W ofercie firmy jest ponad 40 różnych usług, do przechowywania danych o
nich wystarczy 25kB.
usługi 50 =-=25kB
Najwięcej danych przechowywanych w bazie dotyczy abonentów. Do
przechowywania informacji na ich temat potrzeba aż 12GB! Same dane
personalne abonentów mogą zająć 4 GB (firma ma obecnie 6mln
abonentów, dodatkowo policzony jest zapas 2 mln)
abonenci 6 mln + 2 mln zapasu = 8 mln x 512B =-= 4GB
Przechowywane są także informacje na temat aktywności usług. W
systemie jest dostępne ponad 40 różnych usług, jednak w ofercie żadnego
abonenta nie ma dostępnych więcej niż 25 usług.
aktywność usług 8 mln x 25 = 200 mln x 16B =-= 3 GB
Kolejną dużą kategorią danych są informacje o zgłoszeniach, dziennie jest
około 5000 zgłoszeń, są one przechowane przez 5 lat  daje to ok. 10mln
zgłoszeń.
zgłoszenia 10 mln x 512B = 5GB
W sumie dane to około 15GB (z zapasem).
Kluczem do sprawnego działania systemu jest możliwość szybkiego
wyszukiwania informacji w bazie (klient ma jak najszybciej otrzymać
potrzebną informację), dlatego dodatkowo przechowywane będą indeksy
przyśpieszające wyszukiwanie informacji w bazach. Indeksy:10GB
31
Projektowanie systemów informatycznych
6.2.Propozycja wymaganych czasów odpowiedzi dla systemu
Czas odpowiedzi systemu w przypadku odwołań do bazy danych powinien
mieścić się w 7 sekundach. Przekroczenie czasu 15 sekund może być
traktowane jako niespełnienie wymagań.
Czas odpowiedzi systemu w przypadku braku odwołań do bazy danych
powinien mieścić się w 2 sekundach. Przekroczenie czasu 5 sekund będzie
sygnalizować konieczność wprowadzenia zmian.
6.3.Oszacowanie ilości i typów potrzebnych stanowisk pracy
użytkowników systemu:
liczba operatorów: 100
o stanowiska powinny być dodatkowo wyposażone w sprzęt
telefoniczny zintegrowany z systemem.
liczba managerów: 5
6.4. Inne wymagania:
Wydajność:
Istotny jest czas obsługi każdego zgłoszenia, zarówno czas obsługi klienta
dzwoniącego, gdzie zapisanie zgłoszenia musi się odbyć  on-line , jak
również jak najszybsze wykonanie tego zgłoszenia.
Dostępność:
System powinien być dostępny 24h na dobę, 7 dni w tygodniu.
Bezpieczeństwo: System powinien być zabezpieczony przed dostępem
osób niepowołanych z zewnątrz firmy. Rozwiązaniem wystarczającym
wydaje się być zablokowanie dostępu z zewnątrz firmy, zastosowanie
loginów oraz haseł. Aspektem także ważnym jest odpowiednia
strukturalizacja dostępu do danych wewnątrz firmy tak, by pracownicy
mieli tylko dostęp do danych związanych z ich zakresem obowiązków, co
zaowocuje przejrzystością odpowiedzialności. Dodatkowo utrudni
inwigilację firmy przez nieuczciwych pracowników.
7. Propozycje technologii
System musi być wydajny i szybki (ważny czas obsługi klienta).
" Programowanie w C++ zapewni niezawodną i szybką
reakcję systemu.
" Wsparcie międzymodułowej komunikacji technologią
CORBA.
System musi działać w oparciu o bazę danych o wysokiej
niezawodności (i z zapewnionym bezpieczeństwem danych,
najlepiej z możliwością mirrorowania danych)
32
Projektowanie systemów informatycznych
System składać się będzie z:
serwera nadzorującego całą pracę, obsługującego
przychodzące połączenia telefoniczne oraz pobierającego i
wysyłającego pocztę elektroniczną. Jest to jedyny
komputer posiadający dostęp do internetu.
serwera baz danych, na którym znajdować się będzie baza
danych
komputerów klienckich, na których pracować będą
użytkownicy.
System operacyjny:
Linux. W przypadku obu serwerów może być to
dystrybucja Debian albo Slackware (ze względu na
bezpieczeństwo), a dla komputerów klienckich np. Fedora
Core albo Mandriva.
Baza danych
- Oracle  wydajna komercyjna baza danych, kosztowna
- PostgreSQL  darmowa baza danych, może zostać
zastosowana w celu ograniczenia kosztów projektu.
Wymagania sprzętowe:
Serwer nadzorujący
o Serwer klasy PC z procesorem Intel Xeon, 1GB
RAM, dysk 120GB.
Serwer z bazą danych
o Dwuprocesorowy serwer klasy PC z procesorami
Intel Xeon, 2GB RAM, macierz dyskowa SCSI, 2x2
dyski 120 GB przeznaczone na przechowywanie
danych (2 dyski, w tym jeden służący do
przechowywania kopii danych  mirroring, na
potrzeby składowania danych i taka sama
konfiguracja służąca do przechowywania indeksów
w bazie danych).
Stacje klienckie
o Komputery klasy PC, procesor co najmniej Pentium
III 733MHz, 512MB RAM, dysk 40GB.
Wewnętrzna sieć:100Mb, okablowanie: skrętka UTP 5.
33
Projektowanie systemów informatycznych
8. Propozycja planu projektu
8.1.Wyróżnione etapy i zadania
L Etap Zadania Czas Realizacja
p. trwania
1. Projektowanie - projekt funkcjonalny 20 dni Analityk 1
systemu, roboczych Analityk 2
- identyfikacja potrzeb
użytkowników
- ustalenie sposobu
testowania,
- powstanie projektu
technicznego
2. Przygotowanie do - zakup niezbędnego 15 dni Technik 1
realizacji sprzętu i roboczych Technik 2
oprogramowania,
- instalacja systemu baz
danych
3. Oprogramowanie - zaprogramowanie 25 dni Programista1
(kodowanie) aplikacji klienckiej roboczych Programista2
- stworzenie
oprogramowania dla
serwera
nadzorującego
4 Stworzenie bazy - stworzenie bazy 10 dni Programista1
danych danych na potrzeby roboczych Wprowadzają
systemu (struktura), cy dane 1-5
- wprowadzenie danych
5 Testy wewnętrzne - wewnętrzne testy 5 dni Tester 1
systemu robocze
6 Poprawki po - poprawki po testach 7 dni Programista1
testach wewnętrznych roboczych Programista2
7 Wdrożenie - Instalacja systemu, 5 dni Technik1
- stworzenie roboczych Programista1
dokumentacji
systemu
8 - testy systemu 5 dni Odbiorca
Testy zewnętrzne realizowane przez roboczych
odbiorców systemu
9 Poprawki po - poprawki po testach 5 dni Programista1
testach zewnętrznych, roboczych Programista2
- oddanie systemu do
użytkowania
1 Utrzymanie - Utrzymanie systemu --- Technik 1
0 na warunkach
ustalonych w umowie
34
Projektowanie systemów informatycznych
8.2 Zależności pomiędzy etapami i analiza zadań ścieżki krytycznej
4.
2.
Stworzenie
Przygotowani bazy danych
10 dni
e do realizacji
7. 8. 9.
1.
(15dni) Wdrożenie Testy Poprawki
Projektowanie 5 dni zewn po testach
5dni 5dni
(20 dni
3.
roboczych)
Oprogramowanie
5. 6.
(25 dni roboczych)
Testy Poprawki
wewn po testach
5dni 7dni
Czas realizacji projektu - 72 dni
robocze
Etapy realizacji projektu powinny przebiegać w sposób przedstawiony na
rysunku. Przygotowanie do realizacji po stronie odbiorcy może przebiegać
równocześnie z oprogramowaniem, możliwe jest także zrównolegnienie
testów wewnętrznych i poprawek z tworzeniem bazy danych. Pozostałe
etapy muszą przebiegać po sobie.
Widać, że jest niewielka elastyczność projektu pod względem czasu
realizacji poszczególnych etapów, przesunięcia dopuszczalne są jedynie
w etapie 2 i 4. Pozostałe etapy leżą na ścieżce krytycznej (zaznaczona na
pomarańczowa), każde opóz
nienie w ich realizacji doprowadzi do
wydłużenia czasu realizacji projektu.
35
9. Analiza ryzyka projektu
Zagrożenie Szanse Stopień Zapobieganie zagrożeniu Postępowanie w przypadku
wystąpienia szkód wystąpienia zagrożenia
Niedoprecyzowanie Średnie Duży Jasne sprecyzowanie Wszelkie niejasności w wymaganiach
specyfikacji początkowych wymagań i stałe funkcjonalnych należy szczegółowo
konfrontowanie ich z wyjaśniać. Niezwłoczne dokonywanie
oczekiwaniami użytkowników. potrzebnych poprawek w przypadku
znacznej różnicy między oczekiwaniami
odbiorców a stanem rzeczywistym.
Brak doświadczenia Małe Średni Odpowiedni dobór osób Możliwość zwrócenia się do osoby
osób wykonujących realizujących, posiadających biegłej w danej dziedzinie, która w razie
system odpowiednie umiejętności. wystąpienia zagrożenia będzie w stanie
pomóc w realizacji projektu.
Awaria bazy danych Małe Średni Znalezienie doświadczonego Jak najszybsza diagnoza problemu i
administratora baz danych. usunięcie go (kopie zapasowe danych),
wykorzystanie serwera zapasowego.
Awaria serwera Małe Średni Przygotowanie zapasowego Przełączenie na zapasowy serwer i
zarządzającego serwera. usunięcie usterki.
Awarie sprzętowe Małe Mały Podpisanie z dostawcą sprzętu Wezwanie serwisu w celu usunięcia
(z wyłączeniem umowy na serwisowanie. problemu (naprawy sprzętu).
serwerów) Zatrudnienie technika.
Nieintuicyjna Średnie Mały Odbiór instrukcji obsługi przez Przeszkolenie użytkowników i
obsługa systemu użytkowników. póz
niejsze konsultacje w razie dalszych
niejasności
Błędy w Małe Mały Weryfikacja dokumentacji przez Zarezerwowanie czasu na ewentualne
dokumentacji odbiorców konsultacje, poprawienie dokumentacji
Bezpieczeństwo Małe Duży Stosowanie transmisji Zmiana haseł, aktualizacja
informacji szyfrowanej i uwierzytelniania, zabezpieczeń na serwerze.
aktualizacje systemu
10. Podsumowanie
System zarządzania relacjami z klientami (CRM) jest w dzisiejszych
czasach niezbędny w każdej instytucji, w której znaczącą role ma kontakt
z klientem. System taki umożliwia odnotowywanie wszelkich kontaktów z
każdym klientem z osobna i podejmowanie odpowiednich decyzji.
Aplikacje CRM powinny dawać możliwość efektywnego zarządzania
kontaktami z klientami prowadząc do nadrzędności tego podejścia w
ramach ogólnej strategii firmy. W naszym przykładzie umożliwiają one
zarejestrowanie rozmowy z klientem, a w przypadku standardowych spraw
także automatyczne uzyskanie informacji.
Operator jest potrzebny tylko w przypadku zgłoszeń niestandardowych.
Dzięki systemowi CRM może on skorzystać z automatycznych
podpowiedzi, wyszukać odpowiednie informacje i sprawnie pomóc
klientowi.
Nasz projekt stanowi jedynie zarys projektu, jaki mógłby być zrealizowany w
rzeczywistości. Aby uzyskać pełny obraz wymagań funkcjonalnych dla systemu
należałoby dokładnie uzgodnić z odbiorcami (a najlepiej także z użytkownikami) ich
oczekiwań i wymagań wobec systemu. W wymaganiach powinna być uchwycona
specyfika działania konkretnego odbiorcy i jego wyobrażenie co do systemu jako
całości i wszystkich jego elementów.
UML (Unified Modeling Language) jest obecnie najważniejszym
i najpowszechniej stosowanym językiem modelowania. Stosuje się go
przede wszystkim w analizie i projektowaniu systemów informatycznych,
modelowaniu biznesowym, analizie wymagań. UML stał się standardem de
facto wykorzystywanym w prawie każdym projekcie informatycznym.
Metoda rysowania diagramów obiektowych (UML) stanowi wspólny język
porozumienia język analityków biznesowych, projektantów i
programistów, ułatwiający porozumienie się osób uczestniczących w
realizacji projektu.
Solidny i przejrzysty projekt systemu, w tym notacja UML (zrozumiała dla
przeciętnego człowieka) może pomóc uniknąć wielu błędów i niedomówień, łatwych
do usunięcia na etapie projektowania, a bardzo kosztownych i czasochłonnych w
przypadku odkrycia na dalszych etapach tworzenia systemu.
Projektowanie systemów informatycznych
11. Literatura
1. Fowler, M., Scott, K., UML w kropelce, Oficyna Wydawnicza LTP,
Polish language edition, Warszawa 2002
2. Lasek Mirosława, Notatki do wykładu Projektowanie systemów
informatycznych, 2005
3. Szejko, S., Metody wytwarzania oprogramowania, Wydawnictwo
MIKOM, Warszawa, 2002; r.3.2. (ISBN 83-7279-283-6).
4. Śmiałek, M. Zrozumieć UML 2.0. Metody modelowania obiektowego,
Wydawnictwo HELION, Gliwice 2005 (ISBN 83-7361-918-6).
5. Booch, G., Rumbaugh, J., Jacobson, I., UML przewodnik
użytkownika, Wydawnictwa Naukowo-Techniczne, Warszawa 2001
38