M.Okoniewski 2002
Analiza systemów
informatycznych
Cz. 3
Studium możliwości
M.Okoniewski 2002
Analiza systemów
informatycznych
Cz. 3
Studium możliwości
M.Okoniewski 2002
I. Cel i przeznaczenie
• 1.1. Ogólne sformułowanie dziedziny i celów
stawianych projektowi.
• 1.2. Zwięzła charakterystyka przedsięwzięcia (cel
systemu).
• 1.3. Kryteria i warunki powodzenia realizacji systemu.
• 1.4. Charakterystyka użytkowników, ich kategoryzacja,
ich wymagania oraz ich metody i tryby pracy.
• 1.5. Charakterystyka środowiska i warunków
(organizacyjnych, kadrowych, fizycznych) działania
systemu.
Uwaga: Ten rozdział do pewnego stopnia spełnia funkcje
założeń do systemu
M.Okoniewski 2002
I. Cel i przeznaczenie
• 1.1. System zapisów uczniów do gimnazjów i liceum w
woj. Warmińsko-Mazurskim
• 1.2. Stworzenie efektywnego systemu - przydatnego
dla kuratorium, przyjaznego dla użytkowników
• 1.3. Uczciwość - niepodatność na manipulacje,
kontrola, zaufanie, sprawność techniczna systemu,
automatyzacja procesu
• 1.4. Kuratorium, dyrekcje szkół ponadpodstawowych,
uczniowie, wychowawcy z podstawówek
• 1.5. Niski budżet, słabo wykształcone informatycznie
kadry, konieczna kontrola centralna w kuratorium,
powszechny dostęp w internecie do zapisów
M.Okoniewski 2002
II. Projekt funkcjonalny
• 2.1. Funkcjonalna charakterystyka systemu.
• 2.2. Analiza danych (typy i rodzaje danych i
wiążących je relacji) wraz z przepływem informacji.
• 2.3. Formalny (ścisły) opis funkcji systemu
zawierający model danych, przepływ danych i
poleceń oraz wyszczególnienie operacji
wykonywanych na danych (schematy E-R, DFD).
Opracowanie wzorów dokumentów systemu.
• 2.4. Ścisła specyfikacja procedur systemu, w tym
specyfikacja dialogu z poszczególnymi kategoriami
użytkowników (projektowanie szkiców "ekranów").
M.Okoniewski 2002
II. Projekt funkcjonalny
• 2.1. Funkcje: zbieranie wyników uczniów,
podpisywanie świadectwa, rozdzielanie ich wg
preferencji i wyników pomiędzy szkoły,
raportowanie, nadanie certyfikatu
• 2.2., 2.3 Baza: uczeń, szkoła podstawowa, szkoła
średnia, profil naboru, klasa, osiągnięcie
• Przepływy danych: złożenie świadectwa, nabór,
podział, informowanie
• 2.4. Wprowadź cenzurkę, Podpisz przez
wychowawcę, Przeglądaj uczniów, Przeglądaj szkoły,
Wykonaj nabór, Przeglądaj nabór, Poprawianie
danych, obsługa certyfikatów
M.Okoniewski 2002
II. Projekt funkcjonalny (2)
• 2.5. Specyfikacja praw dostępu i ochrony
danych.
• 2.6. Specyfikacja statystyk zbieranych
przez system w celu jego oceny i analizy
potrzeb użytkowników.
• 2.7. Specyfikacja jakości (łatwość
użytkowania, łatwość pielęgnacji,
niezawodność, możliwości rozwoju).
• 2.8. Współdziałanie z innymi systemami.
M.Okoniewski 2002
II. Projekt funkcjonalny (2)
• 2.5. Dostęp: uczeń, wychowawca klasy, dyrektor
szkoły średniej, administrator w kuratorium -
ścisła definicja praw dostępu ma zapewnić
uczciwość! Rola systemu certyfikacji.
• 2.6. Raporty dla kuratorium, statystyki
obciążenia systemu
• 2.7. Interface webowy dla uczniów,
wychowawców i dyrektorów, minimum obsługi
systemu centralnego
• 2.8. Eksport danych do systemów szkolnych (jeśli
istnieją) w formacie csv, xls, etc...
M.Okoniewski 2002
III. Prototyp
• 3.1.
Opis prototypu.
• 3.2.
Ocena prototypu przez
przyszłych użytkowników systemu.
Propozycje.
• 3.3.
Wnioski.
M.Okoniewski 2002
III. Prototyp
• 1 szkola - bez profilów - zapisy uczniów
generowane jako dane testowe
• Prototyp jako etap pośredni
implementacji.
• Badanie efektywności, przyjazności dla
użytkownika
M.Okoniewski 2002
IV. Architektura systemu.
• 4.1 Technologiczna podstawa działania systemu
(model klient-serwer, system otwarty,
przyjazność dla użytkownika, minimalizacja
nakładów na utrzymanie i administrację
systemu, podatność na zmiany otoczenia itd.).
• 4.2.
Ilościowa i jakościowa charakterystyka
parametrów wydajnościowych systemu, w tym
wskazanie parametrów krytycznych dla jakości
systemu oraz dopuszczalnych ograniczeń.
• 4.3.
Krótka analiza rynku oprogramowania
i sprzętu. Wnioski.
M.Okoniewski 2002
IV. Architektura systemu.
• 4.1 Cienki klient, silnik bazodanowy, aplikacja
webowa. Wymagana stabilność i
niezawodność. System certyfikacji i
weryfikacji podpisu elektronicznego.
• 4.2.
Ilość użytkowników (ok. 5000
uczniów, 40 szkol)
• 4.3.
Bazy : drogie, tanie. Brak
specjalizowanego oprogramowania - trzeba
zrobić własną aplikację. Problem: serwer
certyfikatów do podpisu elektronicznego.
M.Okoniewski 2002
IV. Zarządzanie realizacją
projektu
• 4.3. Specyfikacja oprogramowania i jego
konfiguracja.
• 4.4. Specyfikacja i konfiguracja sprzętu
komputerowego i sieciowego.
• 4.5. Metodyczne i narzędziowe zalecenia
w zakresie zarządzania realizacją
projektu.
M.Okoniewski 2002
IV. Zarządzanie realizacją
projektu
• 4.3. Np. Interbase + aplikacja w Delphi,
albo: MS SQL + system w C#, ew
MySQL + php. System do obsługi
podpisu elektronicznego i certyfikatów
• 4.4. Serwer za 3000 zł, mirroring dysku,
łącze 2MB
• 4.5. Zaprojektować strukturę bazy i
aplikacji i wyspecyfikować za pomocą
UML. Kontrolować z dokumentacją.
M.Okoniewski 2002
V. Nakłady/zasoby i
organizacja pracy
• 5.1. Harmonogram prac wraz z punktami
kontrolnymi etapowej oceny realizacji
systemu i wskazaniem ścieżki krytycznej.
• 5.2. Kosztorys implementacji systemu.
• 5.3 Zasoby ludzkie niezbędne do
realizacji systemu
• 5.4.
Zasady przyjmowania etapów
realizacji systemu.
M.Okoniewski 2002
V. Nakłady/zasoby i
organizacja pracy
• 5.1. Punkty kontrolne: projekt,
implementacja, prototyp, testy, pełne
wdrożenie, szkolenia. Krytyczne
czynniki: działanie aplikacji webowej z
bazą, działanie podpisu elektronicznego
i systemu certyfikacji
• 5.2. Kosztorys implementacji systemu:
M.Okoniewski 2002
V. Nakłady/zasoby i
organizacja pracy
Narzędzia
developerskie,
baza, certyfikaty
10000
Praca
programistów,
projektanów
i testerów
130000
Sprzęt (komputery,
łącze)
8000
Szkolenia
(trenerzy)
20000
Razem
168000
M.Okoniewski 2002
V. Nakłady/zasoby i
organizacja pracy
• 5.3 Zasoby ludzkie : projektanci 0,5
osoboroku programiści 2 osobolata,
testerzy 0,5 osoboroku
• 5.4.
Zasady przyjmowania etapów
realizacji systemu : raporty, kontrola i
zatwierdzenie przez osobę
odpowiedzialna w kuratorium i zespół
dyrektorów szkół
M.Okoniewski 2002
V. Nakłady/zasoby i
organizacja pracy
• 5.5 Opisy zadań (ang. terms of
reference) dla wszystkich członków
zespołu wykonawczego.
• 5.6.
Zasady współpracy
zleceniodawca - wykonawca.
• 5.7.
Ocena nakładów osobowych i
finansowych na utrzymanie systemu
(eksploatacja i rozwój).
M.Okoniewski 2002
V. Nakłady/zasoby i
organizacja pracy
• 5.5 Projektant, kierownik zespołu (zarządzanie i
kontakty ze zleceniodawcą), programista, tester
• 5.6.
Płatności następują po wykonaniu
poszczególnych etapów i podpisaniu protokołu
odbioru. Przekazanie następuje wraz z
dokumentacją
• 5.7.
Eksploatacja - 3 miesiące pracy w roku
jednej osoby : 1/4 etatu + 1/4 etatu przez cały
rok - certyfikaty. Rozwój i serwis - głównie koszt
pracy programisty. Należy podpisać korzystną
umowę serwisową.
M.Okoniewski 2002
VI. Analiza korzyści
(costs/benefits analysis)
• 6.1.
Oszacowanie
nakładów/kosztów.
• 6.2.
Oszacowanie korzyści.
• 6.3. Wnioski.
M.Okoniewski 2002
VI. Analiza korzyści
(costs/benefits analysis)
• 6.1.
Nakłady : 170000zł + pokój w
kuratorium
• 6.2.
Korzyści - redukcja etatów
sekretarek w szkołach? Etat mniej w
kuratorium? Mniej pracy dla
dyrektorów - finansowo prawie nic.
Likwidacja korupcji? Może EU się
dorzuci? Reklama?
• 6.3. Nie opłaca się?
M.Okoniewski 2002
VII. Zarządzanie jakością
• 7.1.
Wybór metod(y) zarządzania
jakością.
• 7.2.
Zalecenia.
M.Okoniewski 2002
VII. Zarządzanie jakością
• Kontrola twórców kolejnego etapu
przez tych co stworzyli założenia
następnego
• „komitet sterujący” - kuratorium i
dyrektorzy szkół
• kontrola postępu prac przez
niezależnych ekspertów
M.Okoniewski 2002
VIII. Programy szkoleń
• 8.1.
Szkolenia dla użytkowników.
• 8.2.
Szkolenia dla administratorów.
M.Okoniewski 2002
VIII. Programy szkoleń
• 8.1.
Szkolenia dla użytkowników -
dużo, kosztowne
• 8.2.
Szkolenia dla administratorów -
mało
M.Okoniewski 2002
IX. Układ rzeczowy i
struktura dokumentacji
• 9.1.
Dokumentacja dla użytkowników.
• 9.2.
Dokumentacja systemu
•
- dla administratora aplikacji
•
- dla administratora bazy danych
• 9.3.
Dokumentacja techniczna.
M.Okoniewski 2002
IX. Układ rzeczowy i
struktura dokumentacji
• 9.1.
Dokumentacja dla użytkowników -
dyrektorów, nauczycieli, broszurki dla
uczniów
• 9.2. Dokumentacja systemu
•
- dla administratora aplikacji
•
- dla administratora systemu certyfikacji
• 9.3.
Dokumentacja techniczna.
M.Okoniewski 2002
X. Scenariusz wdrożenia.
Zasady przyjęcia system
• 10.1. Reguły pilotowego wdrożenie
systemu
• 10.2. Testy systemu. Kryteria oceny.
• 10.3. Formularz i zasady oceny systemu
przez użytkowników.
• 10.4. Zasady wprowadzania poprawek.
• 10.5. Schemat sprawozdania
końcowego.
M.Okoniewski 2002
X. Scenariusz wdrożenia.
Zasady przyjęcia system
• 10.1. Pilotowo - do 1 szkoły średniej??? Musi
działać centrum certyfikacji nauczycieli
• 10.2. Testy : dużo pracy z generowaniem
danych testowych.
• 10.3. Badanie testowe wśród uczniów i
dyrektorów - po wdrożeniu - nacisk na
uczciwe zasady naboru
• 10.4. Zlecamy poprawki w ramach umowy
serwisowej
• 10.5. Protokoły odbioru, zbiór dokumentacji,
wyniki badania po wdrożeniu.
M.Okoniewski 2002
XI. Perspektywy rozwojowe
systemu.
• Forma końcowa
• projekt techniczny zgonie z podanym wyżej
konspektem,
• seminarium dla zainteresowanych środowisk.
M.Okoniewski 2002
XI. Perspektywy rozwojowe
systemu.
• Forma końcowa:
• projekt techniczny zgonie z podanym wyżej konspektem,
• seminarium dla zainteresowanych środowisk -
nauczycieli, dyrektorów, rodziców uczniów
• wyznaczenie administratora
• raport końcowy
• ogłoszenie w prasie lokalnej
• konferencja prasowa??
• bezusterkowe działanie systemu