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