Jak gotować aby nie spalić Andrzej Bobak, PCSS Piotr Grzybowski, PCSS
Agenda Wprowadzenie Początki systemu Nabór Szkic funkcjonalności Instalacje systemu Użytkownicy systemu Dane liczbowe Przebieg wdrożenia Garść danych technicznych Jak nadążyć za wymaganiami Jak reagować na awarie
Wprowadzenie Skąd wziął się system Nabór? Dlaczego rekrutacja elektroniczna? Brak blokowania miejsc Kompleksowe rozwiązanie problemu Zmniejszenie nakładu organizacyjnego Mniejszy stres kandydatów i rodziców Natychmiastowy dostęp do danych statystycznych Pierwszy cel projektu rekrutacja elektroniczna
Początki rozwoju 2002/2003 szkoły ponadgimnazjalne Poznań Oprogramowanie tworzone wspólnie z klientem Pierwsze wdrożenie w Polsce Najważniejsze pierwsze wdrożenie projektu duże zaangażowanie klienta zgoda ministerstwa przeprowadzenie testów rozpracowanie planów awaryjnych oprawa medialna ogromny sukces
Dalszy rozwój Jak nie spalić sukcesu? wiedza merytoryczna nastawienie na rozwój poligon doświadczalny wizja wybiegająca daleko w przyszłość realizacja zadań niemożliwych do realizacji wcześniej przeniesienie sukcesu na kolejnego klienta 2004 kolejne instalacje: Białystok, Kalisz, Szczecin, Zielona-Góra
Dalszy rozwój c.d. 2005 wprowadzenie kolejnego modułu gimnazjum, przedszkola, praca bieżąca, kolejne instalacje 2007 wprowadzenie modułu szkoła podstawowa, kolejne instalacje 2008 kolejny moduł - szkoły policealne oraz ponadgimnazjalne dla dorosłych Kontrola obowiązków Instalacja kolejnych modułów w miastach Rozwój na całe województwa
Szkic funkcjonalności Rekrutacja Praca bieżąca Część operatorska oraz publiczna
Sukces Naboru od kuchni Instalacje
Użytkownicy systemu Inspektor - pracownik samorządu, który odpowiada organizacyjnie za podległe mu placówki w regionie. Zarządza on przebiegiem całego procesu rekrutacji, rozpoczyna i kończy jego poszczególne etapy, ma dostęp do wszelkich danych. Zazwyczaj funkcję Inspektora pełni jedna lub dwie osoby w całym regionie. Operator - pracownik przedszkola, szkoły podstawowej, gimnazjum lub szkoły ponadgimnazjalnej, który odpowiada za wprowadzenie do systemu danych placówki oraz kandydatów, którzy ubiegają się o przyjęcie do danej placówki. System umożliwia funkcjonowanie kilku Operatorów w jednej placówce.
Użytkownicy systemu c.d. Kandydat - dziecko zapisywane do przedszkola, szkoły podstawowej, gimnazjum lub szkoły ponadgimnazjalnej, który ubiega się o przyjęcie przynajmniej do jednej z placówek w regionie. Kurator - kurator lub jego pełnomocnik, który odpowiada za kwestie merytoryczne związane z rekrutacją. Osoba ta ma dostęp do wszelkich danych przechowywanych w systemie, w tym raportów statystycznych.
Dane liczbowe Rynek w Polsce ~3mln PLN (tylko rekrutacje elektroniczne) duża możliwość rozwoju Wdrożenia PCSS 2008 rok 17 miast Placówki 233 zespołach szkół ponadgimnazjalnych 153 szkołach gimnazjalnych 168 szkołach podstawowych 545 przedszkolach i oddziałach zerowych w szkołach podstawowych
Dane liczbowe c.d. Liczba rekordów w bazach 350k około 170 tys. uczniów i kandydatów w szkołach ponadgimnazjalnych, około 69 tys. uczniów i kandydatów w gimnazjach, około 38 tys. uczniów i kandydatów w szkołach podstawowych, około 73 tys. dzieci i uczniów szkołach podstawowych (klasa 0 ) oraz przedszkolach
Dane liczbowe c.d. 1.5M odwiedzin rocznie
Przebieg wdrożenia Korzystanie ze sprawdzonych na poligonie doświadczeń oraz schematów Ujednolicenie procesu dla wszystkich klientów Ustalenie dokładnego harmonogramu z określeniem ról użytkowników systemu Przygotowanie informacji dla mediów i przekazanie ich odpowiednio wcześniej Szkolenia koniecznie praktyczne cały proces pokazany na szkoleniach (duża szczegółowość) odpowiedni termin szkoleń (nie zbyt wcześnie) przekazanie dokładnego harmonogramu im więcej pracy włożonej w szkolenia tym mniej później telefonów z pytaniami
Przebieg wdrożenia c.d. Ustalenie zasad pomocy technicznej dla 350k osób nie ma możliwości świadczenia pomocy Stworzenie FAQ Wcześniejsze określenie gorących okresów i przygotowanie się do nich Zadowolenie klienta przekłada się na kolejne wdrożenia Reklamy w mediach nie odnoszą oczekiwanego skutku
Zapraszamy do zadawania pytań
Garść danych technicznych Obiektowe podejście do bazy danych MVC Warstwa View zbudowana z komponentów (przykład w dalszej części prezentacji)
Sezonowość projektu (1) listopad czerwiec intensywne prace nad systemem, dostosowywanie do nowych wymagań lipiec listopad konserwacja, pielęgnacja kodu, ujednolicanie wersji
Sezonowość projektu (2) Odwiedziny luty czerwiec - liczne odwiedziny kandydatów, operatorów szkół, kuratorów, tolerancja błędów - znikoma lipiec styczeń głównie praca bieżąca, system używany głównie przez operatorów szkół, ograniczona tolerancja błędów
Wymagania Sukces Naboru od kuchni Aktualnie obowiązujące rozporządzenia dot. rekrutacji Ustawa o ochronie danych osobowych Wymagania precyzowane przez kuratorów, a w szczególnych przypadkach również dyrektorów szkół
Jak nadążyć za zmieniającymi się wymaganiami? (1) implementacja zmian zaproponowanych przez operatorów/kuratora/zamawiającego system [czerwiec-grudzień]
Jak nadążyć za zmieniającymi się wymaganiami? (2) przygotowanie systemu rekrutacji tak, by był zgodny z aktualnymi wytycznymi
Jak nadążyć za zmieniającymi się wymaganiami? (3) dostosowanie systemu do specyficznych wymagań (np. Szczecin gimnazja bezrejonowe, specyficzne warunki rekrutacji)
Jak nadążyć za zmieniającymi się wymaganiami? (4) śledzenie na bieżąco przepisów publikowanych przez Ministra Edukacji i dostosowywanie systemu do ewentualnych zmian stała współpraca z członkami zespołu odpowiedzialnymi za kontakt z klientem spotkania z kuratorami, dyrektorami szkół, itp.
Jak przygotować system, by kolejni klienci nie równali się kompletnej przebudowie systemu? (1) klasy oraz formatki specyficzne dla klienta formatki złożone z komponentów ogólnego przeznaczenia komponenty maksymalnie możliwie sparametryzowane im więcej parametrów opcjonalnych z domyślnymi wartościami tym lepiej
Jak przygotować system, by kolejni klienci nie równali się kompletnej przebudowie systemu? (2) Klasy specyficzne dla danego klienta (mniej niż 1% klas w systemie) dziedziczą po klasach ogólnych, uściślają wybrane elementy Formatki budowane wyłącznie z komponentów ogólnego przeznaczenia Struktura bazy danych identyczna w każdym mieście
Przykład
Przykład ten sam komponent, różni się wyłącznie opcjonalnym parametrem Szczecin <span jwcid="@commonform" registrationrequest="ognl:registrationrequest" preschoolpreferencesblock="ognl:components.preferences" primeschoolsattheend="ognl:false" /> Olsztyn <span jwcid="@commonform" registrationrequest="ognl:registrationrequest" preschoolpreferencesblock="ognl:components.preferences" companystamp="ognl:true" primeschoolsattheend="ognl:false" />
Jedna wersja systemu dla wielu klientów Zalety rozwiązania Zmiany wprowadzane w jednej instancji ogólnego przeznaczenia Scentralizowane zarządzanie grafiką Scentralizowane eliminowanie błędów Uproszczony proces budowania projektu
Jedna wersja systemu dla wielu klientów Wady rozwiązania Instancja dla miasta x zawiera w sobie nieużywane klasy i grafiki dla miast y, z
Pozornie błahe detale. Jak je postrzegają użytkownicy? Zmiana grafik na obowiązujące w danym roku Różnice w wyglądzie w różnych wersjach systemu Każdy detal przeczytany na stronie jest prawdą obowiązującą
Pozornie błahe detale Co znaczy zapis w razie pomyłki zgłoszenie może zostać ponownie wypełnione Co się stanie z moim starym zgłoszeniem? Kogo mam poinformować o błędzie? Czy system nie pomyli moich zgłoszeń? Jak się mam upewnić, że to właściwe zgłoszenie będzie brane pod uwagę? Czy moje zgłoszenie pojawi się we właściwej szkole?
Spokojnie, to tylko awaria (1) Pierwsze zgłoszenia potrafią się pojawić kilka minut po północy w dniu rozpoczęcia rekrutacji Każda przerwa w działaniu = telefony i maile od zaniepokojonych rodziców czy moje zgłoszenie nie zniknie, czy skoro system miał awarię muszę wypełnić podanie jeszcze raz?
Spokojnie, to tylko awaria (2) Niedopuszczalne opóźnienia w rozpoczęciu rekrutacji opóźnienia w terminie rozpoczęcia wprowadzania zgłoszeń przez szkoły opóźnienia w ogłoszeniu wyników dłuższe niż kilkuminutowe przerwy w działaniu systemu
Spokojnie, to tylko awaria (3) Bieżące poprawki Opracowywane w tempie ekspresowym (nadgodziny) Intensywnie i dogłębnie testowane (nadgodziny + angażowanie członków zespołu nie zaangażowanych w proces programowania) Wdrażane w godzinach niskiej aktywności użytkowników w systemie (nadgodziny)
Spokojnie, to tylko awaria (4) Gdy brakuje czasu Szybkie poprawki nie nadające się do włączenia do wersji stable release Klonowanie komponentów i szybkie przerabianie tak, by realizowały założone zadanie (ujednolicanie i optymalizacja później, dzisiaj musi działać)
Zapraszamy do zadawania pytań