source: main/waeup.sirp/branches/ulif-extimgstore/docs/source/developerdocs/german/applicants.rst @ 6999

Applicants
***********

Das Applicants Package dient der Anmeldung einer großen Zahl von Personen (bis 50.000) zur Teilnahme an einem hochschulinternen Screening-Verfahren, welche die Zulassung zum Studium an der Hochschule regeln. Es gibt zur Zeit acht verschiedene Screening-Verfahren mit zum Teil mehreren unterschiedlichen Anmeldeformularen. Ein Screening wird in der Regel durch einen Massentest ('Exercise') begleitet. Manchmal spielt auch nur die Herkunft (z.B. aus dem armen Norden) oder das Geschlecht eine Rolle bei der Vergabe von Studienplätzen. Hier die verschiedenen Screening-Verfahren:

**1. Universities**

PUME: Post University Matriculation Examination 
 Die UME-Daten werden von JAMB übermittelt. Diese Studenten haben schon eine JAMB-Prüfung absolviert, die sich UME nennt. JAMB ist die zentrale nigerianische Zulassungsstelle, über die die Zuweisung der Applikanten an die verschiedenen Hochschulen gesteuert wird.
    
PUDE: Post University Direct Entrance
 Die UDE-Daten werden von JAMB übermittelt. Diese Studenten haben keine JAMB-Prüfung absolvieren müssen, ihre Daten werden nur weitergeleitet.
    
DP: Screening für Diploma Students

CT: Screening für Certificate Students (einige Certificates tragen den offiziellen Namen 'Certificate'')
    
SANDWICH: Screening für Sanwich Programme Students (= Part-Time Degree in Education)
    
PT: Screening für Part-Time Degree Students (das sind ältere Studenten, die ein Abendstudium absolvieren)
    
(CEST: Common Entrance Screening Test) 
 Obwohl hier aufgeführt, ist CEST **kein** eigenständiges Screeningverfahren. Es ist ein Test, der bei verschiedenen Screening-Verfahren zum Einsatz kommt. Das hat mich anfangs auch sehr verwirrt, auch dass oft nur von Screening gesprochen wird und automatisch ein Test gemeint ist. So gibt es z.B. ein Screening Venue. Ich habe aber gelernt, dass ein Screening auch ganz ohne Test auskommen kann.    

**2. (Federal) Colleges of Education**

PCE: (Post-) Polytechnics and Colleges of Education Matriculation Examination
 Die PCE-Daten werden von JAMB übermittelt. Diese Studenten haben schon eine JAMB-Prüfung absolviert, die sich PCE nennt. Eigentlich müsste das Screening-Verfahren PPCE heißen, denn es ist das Pendent zu PUME. PCE-Applikanten streben als Abschluss das NCE =  Nigerian Certificate in Education an, welches drei Jahre dauert.
    
PRENCE: Preliminary-NCE = Screening für Vorstudium des Nigerian Certificate in Education
 Ich habe nicht ganz verstanden, welche Studenten so ein einjähriges Vorstudium absolvieren müssen. Vermutlich ist die Schulvorbildung entscheident (s. http://www.nasarawastate.org/articles/56/1/-College-of-Education-Akwanga/Page1.html). Die Pre-NCE Absolventen machen dann automatisch mit dem NCE-Programm weiter. Im SRP starten diese Studenten im Level 000 und gehen dann automatisch in das Level 100 über, ein Trick, der sich bewährt hat.
    
Darüber hinaus bieten die FCEs auch noch Sandwich und Diploma-Programme an. Die Formulare der Universitäten können benutzt werden.

Die Frage tauchte auf, wie wir mit Screeningverfahren umgehen, für die es mehrere Anmeldeformulare gibt (z.B. PUME und PUME 2nd Choice). Ich schlage vor, jedes Anmeldeformular als eigenständigen Container für Applicant Records zu implementieren. Das Screening interessiert uns recht wenig, nur das Formular ist für uns interessant. An dem formularspezifischen Applicants-Container hängen dann die Informationen: Start Date, End Date (= Deadline) und Title (Liste kann erweitert werden). Wir benötigen somit nur zwei Container-Ebenen, wobei die Id des Applicants-Containers sich zusammensetzen muss aus dem Kürzel des Screeningverfahrens (+ evtl. Kennung unterschiedlicher Anmeldeformulare) + Sessionkennung. Der Pfad für eine PUME-Application könnte somit wie folgt aussehen: ``applicants/pume_11/123456``. Innerhalb eines Applicants-Containers ist die Id eindeutig. Beim Export der Daten über Sessiongrenzen hinweg müsste die Kennung, in diesem Fall ``pume_11``, der Id noch vorangestellt werden. In einer CSV-Datei würde die Id des Records dann ``pume_11_123456`` lauten.

Bei den Certificates gibt as das Attribut application_category. Dieses Attribut hilft bei der Gruppierung von Certificates, die den Antragstellern zur Auswahl gestellt werden. Hier werden die Screening-Typen DP, CT und PT noch einmal zusammengefasst, da sie anscheinend alle zu den gleichen Abschlüsse führen. Auch kommt bei all diesen Studenten der CEST zum Einsatz.

Für den Worksflow müssen zwei Gruppen unterschieden werden. PUME, PUDE und PCE durchlaufen vorher das JAMB-Screening, d.h. JAMB liefert den Basisdatensatz, der inkl. der Passfotos über das Data Center importiert werden muss. Bei der Anmeldung im Portal müssen sich die Applikanten erst durch ihre JAMB Registration Number identifizieren. Zusätzlich geben sie noch eine Application PIN ein, mit der sie die Berechtigung gekauft haben, das Formular weiter auszufüllen zu dürfen. Alle anderen Applikanten geben nur die PIN ein. Ihr Datensatz wird in diesem Moment erzeugt. Als Registration Number wird dann (anstatt die JAMB RegNo) die Batch- und die Seriennummer der Scratch Card verwendet (Bauweise s.u.).

Die Vorgehensweise und der Workflow ist wie folgt:

- JAMB-Datensätze werden im Status 'created' importiert.

- Applikanten öffnen die entsprechende Eingabemaske für die PIN und ggf. der JAMB Registration Number. Der PIN Prefix entspricht dem obigen Screeining-Kürzel. Nach dem ersten Zugriff auf einen Datensatz ändert sich dessen Status nach 'edited'.

- Das Formular öffnet sich, das Passbild wird hochgeladen (falls noch nicht vorhanden) und die Felder werden ausgefüllt. Etwas komplizierter sind die Eingabefelder für Zeugnisnoten. Das müsste man sich mal im alten SRP anschauen.Das Passbild wird in einem separaten Verzeichnis mit der Registration Number als Name abgespeichert. Nur jpg-Bilder mit einer begrenzten  Bytegröße werden erlaubt. 

- Es gibt nur ein einziges Select-Feld, das sich Daten aus der Academic Section holt: das Auswahlfeld des gewünschten Study Course (=Certificate). Die Auswahl möglicher Certificates geschieht dynamisch. Das Feld application_category der Certificates dient als Filter.

- Wenn alle Pflichtfelder ausgefüllt sind, kann der Datensatz vom Applikant submitted werden. Der Status des Datensatzes ändert sich entsprechend. Nach der Einreichung erscheint ein Drucksymbol zum Ausdrucken eines Slips. Der Slip öffnet sich in einem separaten Fenster und zeigt nur eine Auswahl der Felder aus dem Datensatz an. Der Slip dient zur Vorlage bei der Vorprüfung an der Universität.

- Nach der Massenprüfung an der Universität werden die Ergebnisse der Prüfung importiert und der Datensatz entweder auf 'non admitted' oder 'admitted' gesetzt. In den admitted Datensätzen wird zudem der certificate code importiert, des Kurses für den die Applikanten vorläufig zugelassen wurden. 

- Ein paar Tage später werden die admitted Datensätze in das Portal kopiert (ca. 5000 bis 7000 Stück), d.h. in Studentenobjekte umgewandelt. Die Applicants-Tabelle wird nach einem Jahr geleert. Sehr bürokratisch ist die Verwaltung der Registration Number. CEST und Sandwich Applikanten bekommen eine eigene Registration Number verpasst (siehe WAeUPTool.py)::

    if brain.screening_type in ('dp','pt','ct','cest','sandwich','sandwich2008') and brain.serial and brain.entry_session:
        if brain.course1:
            reg_no = "%s%s/%s" % (brain.course1[:3],brain.serial,brain.entry_session)
        else:
            reg_no = "%s%s/%s" % (brain.course_admitted[:3],brain.serial,brain.entry_session)
    elif brain.screening_type in ('pume2','pde2'):  #second choice Uniben applicants
        reg_no = brain.jamb_reg_no.upper()
    else:
        reg_no = brain.reg_no

 Deswegen ist zu überlegen, ob wir nicht grundsätztlich zwei Registration Numbers verwalten: Einmal die portaleigene, die sich aus der Session, des Screening-Typen und einer fortlaufenden Nummer zusammensetzt und die den Datensatz identifiziert, und zum anderen die vorgegebene aus Nigeria, die auf dem Slip erscheint und bei der Datenverarbeitung keine weitere Rolle mehr spielt. Nur beim Import oder beim Transformieren der Daten muss aufgepasst werden, dass eine Registration Number  nicht zweimal vergeben werden darf, sie muss eindeutig sein. Studenten müssen hinterher über ihre Registration Number und Matriculation Number eindeutig identifizierbar sein. Das ist erfahrungsgemäß nicht immer der Fall. SIRP kann der Hochschule behilflich sein, Mehrfachzuordnungen zu identifizieren.