Microsoft Word - psi.doc

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

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.

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

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.

Projektowanie systemów informatycznych

3. Perspektywy przypadków użycia.

3.1. Diagram przypadków użycia systemu.

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.

klient

rozmowa z klientem

zaloguj

wyloguj

usuniecie operatora

dodanie operatora

operator

zdanie raportu

zgloszenie kradziezy

pobranie informacji

aktywacja/deaktywacja uslugi

<<extend>>

internet

roaming

W AP

<<ex tend>>

<<extend>>

info o sprzecie

info o uslugach

<<extend>>

manager

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ą.

Projektowanie systemów informatycznych

Aktywacja/deaktywacja usługi- diagram czynności.

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.

autentykacja

klienta

wybranie

rodzaju uslugi

[ aktywacja ]

wybranie rodzaju uslugi

do deaktywowania

[ deaktywacja ]

sprawdzenie czy klient ma
juz aktywowana usluge

sprawdzenie czy klient
moze aktywowac usluge

poinformowanie o niemoznosci

aktywowania uslugi

aktywowanie

uslugi

[ tak ]

sprawdzenie czy klient ma
aktywowana usluge

deaktywowanie

[ tak ]

poinformowanie o

niemoznosci deaktywacji

[ nie ]

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
istnieje

wyswietl komunikat o niemoznosci

dodania operatora

zapisz w systemie

informacje o operatorze

wyswietl komunikat

o dodaniu operatora

[ tak ]

[ nie ]

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.

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ądź 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ądź aktywowania/
deaktywowania usługi.

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

zgloszenie sie

operatora

interakcja klienta z

automatem

operacja wymagajaca
kontaktu z czlowiek iem

[ tak ]

wlaczenie

nagrywania

zarejestrowanie

zadania klienta

wykonanie

zadania

jesli dlugi czas bezczy nnosci
lub rozlaczenie przez klienta

rozlaczenie

[ tak ]

wylaczenie

nagrania

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

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óź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

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 poprawne ]

[ dane nieprawidlowe ]

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ń:

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

zatwierdzenia

Przeslij

Archiwizuj

[ zatwierdz ony ]

[ do poprawy ]

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

Projektowanie systemów informatycznych

należy bardzo uważnie zająć się takim przypadkiem, odpowiednio
modelując go w systemie.

Zidentyfikowane sekwencje zdarzeń:

Wprowadź 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

Uwierzytelnij

abonenta

Modyfikuj rekord w

bazie abonentów

Zablokuj karte

SIM

[ prawidlowe dane ]

[ nieprawidlowe ]

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

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

:operator

:konsola

operatora

:sys tem

:baza

abonentow

:abonent

zmien aktywnosc uslugi

zmien aktywnosc uslugi abonenta

znajdz abonenta

zmien aktywnosc uslugi

modyfikuj rekord

Projektowanie systemów informatycznych

Rozmowa z klientem.

Każda rozmowa z klientem jest rejestrowana, a zgłoszenie jest
odnotowywane w bazie abonentów.

Usunięcie operatora.

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.

: manager

: konsola

managera

: system

: baza

uzytkownikow

usun operatora

sprawdz czy istnieje uzytkownik

usun katalog operatora

usun rek ord uzytkownika

: operator

: konsola

operatora

: system

: baz a

abonentow

z arejetruj rozmowe

zarejes truj roz mowe

wpisz rekord zgloszenia

Projektowanie systemów informatycznych

Wylogowanie.

: operator

: konsola

: sy stem

: baza

uzytkownikow

wyloguj ( )

sprawdź czy zalogowany ( )

zarejest ruj wylogowanie ( )

Zalogowanie.

: operator

: baza

uzytkownikow

: konsola

: system

zaloguj ( )

sprawdz czy ist nieje uzytkownik ( )

sprawdz login i haslo ( )

zarejestruj zalogowanie ( )

Projektowanie systemów informatycznych

Diagram współpracy odpowiadający diagramowi sekwencji
zalogowanie.

Zgłoszenie kradzieży telefonu.

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.

: operator

: konsola

operatora

: system

: baza

abonentow

zablokuj karte SIM ( )

mody fikuj rekord ( )

: o p e ra t o r

: ba z a

u z y t k o w n ik o w

: k o n s o la

: s y s t e m

1 : z a lo g u j ( )

2 : s p ra w d z c z y is t n ie je u z y t k o w n ik ( )

3 :

4 : s p ra w d z lo g in i h a s lo ( )

5 : z a re j e s t ruj z a l o go w an i e ( )

6 :

7 :

8 :

Projektowanie systemów informatycznych

Diagram współpracy odpowiadający diagramowi sekwencji

zgłoszenie kradzieży telefonu.

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.

: o perator

: k on s ola

o p e rat ora

: s y s te m

: baz a

ab onen to w

1: z ablok uj k arte S IM ( )

2: z ab lok uj k arte S IM ( )

3: m ody fik uj rek ord ( )

6 :

Projektowanie systemów informatycznych

konsola operatora

zarejestruj rozmowe()
zablokuj karte SIM()
zmien aktywnosc uslugi()
przeszukaj baze()

konsola managera

dodaj operatora()
usun operatora()
zatwierdz raport()

Przez klase abonent
rozumiemy wykupina
przez klienta karte SIM,
podpisana przez niego
umowe. Tak wiec czlowiek
z realnego s wiata moze
wy stepowac jako wielu
abonetow

konsola

wlasciciel konsoli
stan konsoli

zaloguj()
wys lij komunikat o bledz ie()
wyloguj()

system

sprawdz loginn haslo()
zarejestruj uzytkownik a w systemie()
wyrejestruj uzytkownika z systemu()
sprawdz cz y istnieje uzytkownik()
dodaj katalog operatora()
ustaw login i haslo operatora()
ustaw katalog operatora()
sprawdz login i haslo()
zarejestruj rozmowe()
zablokuj karte SIM()
zmien aktywnosc uslugi abonenta()
sprawdz cz y zalogowany ()

1..n

baza abonentow

znajdz abonenta()
sprawdz czy istnieje()
modyfikuj rekord()
wpisz rekord zgloszenia()

zgloszenie

data zgloszenia
nazwa zgloszenia
rezultat

sprawdz rezultat()
ustaw rezultat()
ustaw nazwe()
sprawdz nazwe()
pobierz date()

baza uslug

znajdz usluge()
wyswietl wszystkie uslugi()
sprawdz czy istnieje()

abonent

imie
nazwisko
numer karty SIM
numer telefonu

zmien aktywnosc uslugi()
zablokuj karte SIM()
podaj informacje o abonencie()
zarejestruj zgloszenie()
uslugi aktywne()
uslugi dostepne()
zarejestruj zgloszenie()
wyswietl wszystkie zgloszenia()

1..n

usluga

nazwa uslugi
dostepna w systemie

sprawdz czy dostepna()
zmien dostepnosc()
ustaw nazwe()
pobierz nazwe()

1..n

dostepnosc uslugi

aktywna

sprawdz czy aktywna()
zmien aktywnosc()

baza uzytkownika

dodaj rekord uzytkownika()
usun rekord uzytkownika()
modyfikuj rekord uzytkownika()
sprawdz stan uzytkownika()
zarejestruj zalogowanie()
zarejestruj wylogowanie()

uz ytkownik

imie
nazwisko
login
haslo

zmien haslo()
wyswietl nazwisko()

1..n

baza sprzetu

podaj nazwe sprzetu()
pokaz liste sprzetu()
pokaz promocje()
podaj cene()
sprawdz czy istnieje()

Sprzet

nazwa
cena
promocja

pokaz cene()
podaj nazwe()
sprawdz promocje()

1..n

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:

imię

nazwisko

numer karty SIM – numer karty SIM jednoznacznie
identyfikuje abonenta

numer telefonu

operacje:

zmień aktywność usługi – aktywuje/deaktywuje usługę dla
danego abonenta

zablokuj kartę SIM

podaj informacje o abonencie

zarejestruj zgłoszenie – powoduje zachowanie informacji w
systemie o wystąpieniu zgłoszenia wykonanego przez danego
abonenta

usługi aktywne- podaje aktywne usługi danego abonenta

usługi dostępne-podaje jakie usługi są dostępne dla danego

abonenta

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:

znajdź abonenta

sprawdź czy istnieje – sprawdza, czy dany klient figuruje w

systemie jako abonent

modyfikuj rekord – modyfikuje rekordy w bazie abonentów
(usuwa lub dodaje nowych)

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:

podaj nazwę sprzętu

Projektowanie systemów informatycznych

pokaż listę sprzętu

pokaż promocje – pokazuje listę sprzętów objętych ofertą

promocyjną wraz z warunkami promocji

podaj cenę

sprawdź czy istnieje

Baza usług

Pozwala na zarządzanie bazą usług. Umożliwia wyszukiwanie usług.

operacje:

znajdź usługę

wyświetl wszystkie usługi

sprawdź 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:

dodaj rekord użytkownika

usuń rekord użytkownika

modyfikuj rekord użytkownika

sprawdź stan użytkownika

zarejestruj zalogowanie

zarejestruj wylogowanie

Dostępność usługi

Klasa asocjacyjna opisująca relacje między abonentem a usługą.

atrybuty

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:

właściciel konsoli – każdy użytkownik poprzez unikalny login i
hasło loguje się do własnej konsoli.

stan konsoli – konsola może być w danej chwili używana

(zalogowany użytkownik) lub niewykorzystywana

Projektowanie systemów informatycznych

operacje:

zaloguj

wyświetl komunikat o błędzie – wyświetla komunikat o
wprowadzeniu błędnych danych

wyloguj

Konsola managera

Rodzaj konsoli, której właścicielem jest manager.

operacje:

dodaj operatora

usuń operatora

zatwierdź raport – pozwala na przeczytanie i zatwierdzenie

(bądź odesłanie operatorowi) comiesięcznego raportu

Konsola operatora

Rodzaj konsoli, której właścicielem jest operator.

operacje:

zarejestruj rozmowę

zablokuj kartę SIM

zmień aktywność usługi

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

nazwa

cena

promocja – wskazuje, czy dany sprzęt jest aktualnie objęty

ofertą promocyjną

operacje:

podaj nazwę

pokaż cenę

sprawdź promocję

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:

sprawdź login i hasło

zarejestruj użytkownika w systemie

wyrejestruj użytkownika z systemu

sprawdź czy istnieje użytkownik

dodaj katalog operatora – gdy manager dodaje nowego
operatora tworzony jest jego katalog

ustaw login i hasło operatora - przy dodawaniu nowego
operatora ustala się jego login i hasło

zarejestruj rozmowę

zablokuj kartę SIM

zmień aktywność usługi abonenta – aktywuje/deaktywuje

usługi dla poszczególnych abonentów

sprawdź czy zalogowany

Usługa

Klasa reprezentuje usługi świadczone przez operatora telefonii
komórkowej abonentowi.

atrybuty:

nazwa usługi

dostępna - atrybut wskazujący czy dana usługa jest dostępna

w systemie.

operacje

sprawdź czy dostępna – sprawdza czy usługa jest dostępna w

systemie

zmień dostępność

ustaw nazwę

pobierz nazwę

Użytkownik

Klasa reprezentuje użytkowników systemu, czyli operatorów i managerów.

atrybuty:

imię

nazwisko

hasło

Projektowanie systemów informatycznych

operacje

zmień hasł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:

data zgłoszenia

nazwa zgłoszenia

rezultat – wskazuje na to czy problem abonenta został
pomyślnie rozwiązany, czy uzyskał potrzebne informacje

operacje

sprawdź rezultat

ustaw rezultat

ustaw nazwę

sprawdź nazwę

pobierz datę

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ą.

oczekiwanie

sk ontak tuj sie

rozmowa

ex it / zapisz informacje o zgloszeniu

otrzymanie odpowiedzi

exit/ zapisz informacje o zgloszeniu

[ nie wszystko zalatwione ]

/ rozlacz

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.

Weryfikacja

do/ sprawdz prawidlowosc danych

Zalogowany

j ako operat or

Zalogowany

jako manager

odrzucone

[ operator ]

[ manager ]

[ nieprawidlowe ]

Rozmowa z klientem

entry/ weryfikacja uzyt kownika

dodawanie

operatora

usuwanie

operatora

zatwierdzanie

raportu

przygotowanie raportu

do/ napisz raport
exit/ przeslij raport

[ raport niezatwierdzony ]

zalogu j

/ wyloguj

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

usluga dostepna w

systemie

usluga dostepna

dla abonenta

niedostepna

abonentowi

aktywna

niedostepna w

systemie

dodaj usluge

udostepnij usluge

aktywuj

deaktywuj

usun usluge

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

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

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)

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

Serwer klasy PC z procesorem Intel Xeon, 1GB

RAM, dysk 120GB.

Serwer z bazą danych

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

Komputery klasy PC, procesor co najmniej Pentium

III 733MHz, 512MB RAM, dysk 40GB.

Wewnętrzna sieć:100Mb, okablowanie: skrętka UTP 5.

Projektowanie systemów informatycznych

8. Propozycja planu projektu

8.1.Wyróżnione etapy i zadania

L
p.

Etap Zadania Czas

trwania

Realizacja

1. Projektowanie

− projekt funkcjonalny

systemu,

− identyfikacja potrzeb

użytkowników

− ustalenie sposobu

testowania,

− powstanie projektu

technicznego

20 dni
roboczych

Analityk 1
Analityk 2

2. Przygotowanie do

realizacji

− zakup niezbędnego

sprzętu i
oprogramowania,

− instalacja systemu baz

danych

15 dni
roboczych

Technik 1
Technik 2

3. Oprogramowanie

(kodowanie)

− zaprogramowanie

aplikacji klienckiej

− stworzenie

oprogramowania dla
serwera
nadzorującego

25 dni
roboczych

Programista1
Programista2

4 Stworzenie bazy

danych

− stworzenie bazy

danych na potrzeby

systemu (struktura),

− wprowadzenie danych

10 dni
roboczych

Programista1
Wprowadzają

cy dane 1-5

5 Testy wewnętrzne − wewnętrzne testy

systemu

5 dni
robocze

Tester 1

6 Poprawki po

testach

− poprawki po testach

wewnętrznych

7 dni
roboczych

Programista1
Programista2

7 Wdrożenie

− Instalacja systemu,

− stworzenie

dokumentacji

systemu

5 dni
roboczych

Technik1
Programista1

Testy zewnętrzne

− testy systemu

realizowane przez
odbiorców systemu

5 dni

roboczych

Odbiorca

9 Poprawki po

testach

− poprawki po testach

zewnętrznych,

− oddanie systemu do

użytkowania

5 dni
roboczych

Programista1
Programista2

1
0

Utrzymanie

− Utrzymanie systemu

na warunkach
ustalonych w umowie

--- Technik

Projektowanie systemów informatycznych

8.2 Zależności pomiędzy etapami i analiza zadań ścieżki krytycznej

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óźnienie w ich realizacji doprowadzi do
wydłużenia czasu realizacji projektu.

Projektowanie

(20 dni

roboczych)

Przygotowani

e do realizacji

(15dni)

Oprogramowanie

(25 dni roboczych

)

Stworzenie

bazy danych

10 dni

Testy

wewn

5dni

Poprawki

po testach

7dni

Wdrożenie

5 dni

Testy

zewn

5dni

Poprawki

po testach

5dni

Czas realizacji projektu - 72 dni

robocze

9. Analiza ryzyka projektu

Zagrożenie Szanse

wystąpienia

Stopień
szkód

Zapobieganie zagrożeniu Postępowanie w przypadku

wystąpienia zagrożenia

Niedoprecyzowanie
specyfikacji

Średnie Duży Jasne

sprecyzowanie

początkowych wymagań i stałe

konfrontowanie ich z
oczekiwaniami użytkowników.

Wszelkie niejasności w wymaganiach
funkcjonalnych należy szczegółowo

wyjaśniać. Niezwłoczne dokonywanie
potrzebnych poprawek w przypadku
znacznej różnicy między oczekiwaniami
odbiorców a stanem rzeczywistym.

Brak doświadczenia
osób wykonujących
system

Małe

Średni Odpowiedni

dobór

osób

realizujących, posiadających
odpowiednie umiejętności.

Możliwość zwrócenia się do osoby
biegłej w danej dziedzinie, która w razie
wystąpienia zagrożenia będzie w stanie

pomóc w realizacji projektu.

Awaria bazy danych Małe

Średni Znalezienie

doświadczonego

administratora baz danych.

Jak najszybsza diagnoza problemu i

usunięcie go (kopie zapasowe danych),
wykorzystanie serwera zapasowego.

Awaria serwera
zarządzającego

Małe

Średni Przygotowanie

zapasowego

serwera.

Przełączenie na zapasowy serwer i
usunięcie usterki.

Awarie sprzętowe
(z wyłączeniem
serwerów)

Małe Mały

Podpisanie z dostawcą sprzętu
umowy na serwisowanie.
Zatrudnienie technika.

Wezwanie serwisu w celu usunięcia
problemu (naprawy sprzętu).

Nieintuicyjna
obsługa systemu

Średnie Mały

Odbiór instrukcji obsługi przez
użytkowników.

Przeszkolenie użytkowników i
późniejsze konsultacje w razie dalszych
niejasności

Błędy w
dokumentacji

Małe Mały

Weryfikacja dokumentacji przez
odbiorców

Zarezerwowanie czasu na ewentualne
konsultacje, poprawienie dokumentacji

Bezpieczeństwo
informacji

Małe Duży Stosowanie

transmisji

szyfrowanej i uwierzytelniania,

aktualizacje systemu

Zmiana haseł, aktualizacja
zabezpieczeń na serwerze.

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).

Booch, G., Rumbaugh, J., Jacobson, I., UML przewodnik

użytkownika, Wydawnictwa Naukowo-Techniczne, Warszawa 2001