TUMonline: Von der Idee zum neuen Feature/vom Fehler zur ... · •Standardmäßig - via RMT •Wenn es inhaltlich knifflig oder kontrovers wird –per Telefon (E-Mail) •Wenn es

TUMonline: Von der Idee zum neuen Feature/vom Fehler zur Bereinigung

– die Rolle der KeyuserDr. Kathrin Dressel und Dr. Thomas Laßleben

SSZ/Prozessmanagement und Statistik

SSZ-InfoForum am 25.11.2014

TUMonline-Team

• Keyuser• Schnittstelle zwischen der Fachabteilung und dem Entwicklerteam in Graz

• Bündelung der fachlichen Expertise für ihren Keyuser-Bereich

• Koordination und Planung der fachliche Weiterentwicklung von TUMonline

• Ansprechpartner für ihre Themenbereiche

• Campus-Management-Team• Partner/Unterstützer der Keyuser

• Support der Anwender

• Beseitigung von Fehlern und Verbesserung von Funktionalitäten

Keyuserbereiche

• Bewerbermanagement(z.B. Pflege neuer Stg, Konfiguration der EVF, Dokumentenmanagement, Zulassungs- und Ablehnungsbescheide uvm)

• Identity Management

• Lehrveranstaltungsmanagement

• Modulmanagement

• Prüfungsverwaltung –zentral/-dezentral(z.B. Prüfungsbescheide, ENB, Abschlussdokumente, Leistungsnachweise uvm)

• Studierendenmanagement(z.B. Immatrikulation, Rückmeldung, Beurlaubung, Exmatrikulation, Stipendien uvm)

• Technik

Rückmeldung, Beiträge/

Stipendien

(Abschluss-) Prüfungen/Abschluss-dokumente

Exmatrikulation

Bewerbung, Zulassung,

Immatrikulation

Student Life

Cycle

1.) Fehler

#*?%

Fehlerobjektivierung durch Keyuser

Fehler kann nur an der TU Graz behoben werden

Bug-Request an Graz

RMT

…

……

Kommunikations-schleifen mit den Entwicklern der

TU Graz

Hot-Fix im laufenden P-System

Jetzt erst mal notwendig: Genaue und schriftliche Fehlerbeschreibung vom User

Geduld

Testen im Q-System interne Abstimmung, Einspielen ins P-System

Geduld

Einspielen mit neuem Release

4xim Jahr

Fehler behoben!

1. FALL

#*?%



Bug-Request an Graz

RMT

…

……


TU Graz


Geduld


Geduld


4xim Jahr

Fehler behoben!

1. FALL


#*?%

Fehler…was ist das eigentlich?

• TO tut nicht, was wir wollen• TO tut was wir mal wollten• TO tut was wir zwar verlangt

haben, aber nie wollten• TO tut was wir nie wollten

und auch nie verlangt haben

Am Anfang war…der Fehler…

Typische Fehler im Quartal IV 2014

• R 31690 „Automatische Weitermeldung trotz Rückmeldesperre“ (STM)

• R 31793 „R194 - Migration Studienstatus“ (STM)

• R 31895 „Fehlende Semester- und Heimatlandkreise“ (STM)

• R 31910 R194 – Exmatrikulationslauf (STM)

• R 31980 Termintyp: gelöscht - falsche Mail von TUMonline an Sachbearbeiter (PV)

• R 32310 Liste der Absolventinnen: Fehler (PV)

• R 31982 Infotext finish page (BW)

#*?%



Bug-Request an Graz

RMT

…

……


TU Graz


Geduld


Geduld


4xim Jahr

Fehler behoben!

1. FALL


Fehlerbeschreibung durch User

• Auf welchem TO System arbeite ich P, Q, Dev, Demo ?

• Was wollte ich in TO erreichen?

• Was habe ich genau der Reihe nach getan?

• Was ist jeweils passiert?

• Matrikel-Nr. Beispiele?

• Bin nur ich (mein Rechner) betroffen?

• Screenshots!

#*?%

Fehlerobjektivierungdurch Keyuser


Bug-Request an Graz

RMT

…

……


TU Graz


Geduld


Geduld


4xim Jahr

Fehler behoben!

1. FALL



Fehler kann vom Keyuser nicht reproduziert werden:Nochmal beim User nachfragen

Fehler kann vom Keyuser weiterhin nicht reproduziert werden:Spricht für Problem am Rechner des Users(Browser-, Java-Version?)oder User-Fehler(Beschreibung unvollständig?)

Fehler kann vom Keyuser reproduziert werden:Weitere Fälle (Matrikel-Nr.) sammelnVerhalten von TO schriftlich dokumentieren, Ursachen abwägenggf. CM-Kollegen konsultieren…interne Lösung?ggf. Frage-Request an Grazggf. Fehler(Bug)-Request an Graz

#*?%



Bug-Request an Graz

RMT

…

……


TU Graz via RMT


Geduld


Geduld


4xim Jahr

Fehler behoben!

1. FALL


Bug-RequestDas Request Management Tool (RMT) der TU Graz

https://www.campusonline.at/support/wbrmt.addRequest?pOrgNr=19507

Worauf es beim Bug-Regest ankommt

• Synthese aus Fehlerbeschreibung und –objektivierung

• Welches TO System (P, Q,…)

• Welche Applikation

• Fehlerbeschreibung + Fallbeispiele (Matrikel-Nummern)

• Bezug zu bekannten Fehlern herstellen

• Ursachenvermutung äußern

• Priorisierung gegenüber anderen Fehlern

• Deadline zur Behebung

https://www.campusonline.at/support/wbrmt.addRequest?pOrgNr=19507

#*?%



Bug-Request an Graz

RMT

…

……


TU Graz


Geduld


Geduld


4xim Jahr

Fehler behoben!

1. FALL


Kommunikation mit Graz

• Standardmäßig - via RMT

• Wenn es inhaltlich knifflig oder kontrovers wird – per Telefon (E-Mail)

• Wenn es gilt, viele Personen intensiv diskutieren zu lassen –über Videokonferenzen

• Wenn auch noch der persönliche Kontakt gefragt ist – durch gemeinsame auch mehrtägige Workshops in München oder Graz

#*?%



Bug-Request an Graz

RMT

…

……


TU Graz


Geduld


Geduld


4xim Jahr

Fehler behoben!

1. FALL


• Aktualisierung (Update)

• Bereitstellung durch Hersteller einer Software

• Ziel ist Fehlerkorrektur

• Fehler ist so gravierend, dass er schnell und gezielt behoben werden muss

• Wörtlich eine „heiße“ (hier im Sinne von schnelle, eilige) Reparatur.

• Abgrenzung zu anderen Aktualisierungen (z. B. Service Pack, Release):

reine Fehlerkorrektur, keine Erweiterungen

dringender Bedarf

nur stark reduzierte Tests durch Hersteller und User möglich

Hot-Fix Einspielen mit neuemRelease• Aktualisierung (Update)

• Behebung des Fehlers im Rahmen der Weiterentwicklung und Erweiterung des Systems

• Fehler ist für den Betrieb von TO nicht kritisch und die Fachabteilung kann arbeiten.

• Mit einem Release wird nicht nur eine sondern gleich eine ganze Reihe von Änderungen im System eingeführt

• Ein Releasewechsel findet in der Regel nur einmal pro Quartal statt.

#*?%



Bug-Request an Graz

RMT

…

……


TU Graz


Geduld


Geduld


4xim Jahr

Fehler behoben!

1. FALL


eilig nicht eilig

Testen, abstimmen und einspielen• Was wird getestet?

Der Erfolg der Fehlerbehebung durch Graz

• Wo wird getestet?

Auf TUMonline Q-, DEV- oder DEMO-System

• Wie wird getestet?

Anhand der zum jeweiligen Release gehörenden „Solv-Beschreibungen“ aus dem RMT (https://www.campusonline.at/support/webnav.ini)

Durchspielen der ursprünglich zum Fehler führenden Situation im System (Test-Scenario)

https://www.campusonline.at/support/webnav.ini

#*?%


Fehler kann an derbehoben

werden

…

……

TUM-interne Abstimmung

Fehler-behebung

Geduld

Testen im Q-System, Einspielen ins P-System

Geduld

Fehler behoben!

2. FALL


Welche Fehler können an der TUM behoben werden?

• Applikationen der Systemadministration

• Veränderung des Quellcodes

Wie kann modifiziert werden werden?

Was können wir also selber beheben?

TUMonline Systemadministration

https://campusquality.tum.de/QSYSTEM_TUM/webnav.ini

System- und Dokumenten-Texte anpassen(z.B. Bescheinigungen)Felder in TO hinzufügen(z.B. Anmerkungsfeld)Applikation-Name, -Icon, -Sichtbarkeit mod.Rechte verwaltenInformationen einblenden

https://campusquality.tum.de/QSYSTEM_TUM/webnav.ini

Welche Fehler können an der TUM behoben werden?

#*?%

Fehler…was ist das eigentlich?

• TO tut nicht, was wir wollen• TO tut was wir mal wollten• TO tut was wir zwar verlangt

haben, aber nie wollten• TO tut was wir nie wollten

und auch nie verlangt haben

• Applikationen der Systemadministration

• Modifikation des Quellcodes

Wie kann modifiziert werden werden?

Was können wir also selber beheben?

TUMonline Quellcode Modifikation

Die TUM kann in gewissem Umfang auch den TUMonline Quellcodeanpassen.

• Dabei dürfen nur neue Funktionen erzeugt werden

• Bestehende Funktionen dürfen nicht verändert werden

• Die neuen Funktionen dürfen nicht auf bereits bestehende rückwirken

#*?%


Fehler kann an derbehoben

werden

…

……

TUM-interne Abstimmung

Fehler-behebung

Geduld

Testen im Q-System, Einspielen ins P-System

Geduld

Fehler behoben!

2. FALL


2.) Neue Features

Ausarbeitung mit verschiedenen Akteuren

Spezifikation durch Keyuser/CM-Team

Feature- Request an Graz

RMT


Geduld


4xim Jahr

Neues Feature aktiv

Rückmeldung relevanterEck-daten

RMT

Woher kommt der Wunsch nach neuen Features ?• Veränderte gesetzliche Rahmenbedingungen

• Weiterentwicklung der Hochschule - Neue fachliche Anforderungen

• Verbesserungswünsche auf Grund von steigender Erfahrung mit dem System

• Korrektur ursprünglich unvollständig oder falsch spezifizierter Anforderungen




RMT


Geduld


4xim Jahr

Neues Feature aktiv


RMT

Wie und wo werden neuen Features ausgearbeitet?• Im Dialog zwischen zentralen und dezentralen Einrichtungen

(HSL, CIO, HSR S&L, ITSZ, IC, SSZ, Fakultäten, Keyuser…)

• In Fachausschüssen (FASM, FAST, FAPV, FA Statistik, FAMM,…)

• In temporären Arbeitsgruppen (AG Prozessmanagement Studienbewerber, AG Bologna, AG Prozessmanagement Prüfungsverwaltung…)

• In Workshops (SPO Workshop, LV Workshop,…)

• Keyuser Treffen

• Im Vorstand Lehre




RMT


Geduld


4xim Jahr

Neues Feature aktiv


RMT


• Priorisierung der Wichtigkeit des Features

• Abstimmung mit dem Gesamtzusammenhang der Applikation

• Definition eines möglichen Einspieldatums

• Beschreibung der Funktionalität des neuen Features

• Formular-(Masken-)Vorschlag

Beispiel: (Spezifikation Semesterticket)

//tuzvf01/Users$/Lassleben/H tlas Sprecher der Studiendekane/SSZ/Key-User-STM/Anforderungen/Semesterticket/Request_2.pdf




RMT


Geduld


4xim Jahr

Neues Feature aktiv


RMT

Der Feature-Request im RMT

• Feature Requests (Anfrage Angebot) müssen immer vom CIO ins RMT gestellt werden.

• CIO prüft vom Keyuser vorbereitetet fachliche Spezifikation

( Request Inhalt bzw. Anhang) sowie sonstige Request Daten wie:• Art (Fehler, Angebot, Frage, Idee/Vorschlag)

• Priorität (niedrig, mittel, hoch, kritisch, unbekannt)

• Lösungsdatum (Release-Nr. oder Termin)

• Thema (Bereich in TO)

• Betreff (Freitext Request-Titel)

• CIO gibt Feature Request frei und erstell diesen im RMT oder bittet zunächst um Überarbeitung.




RMT


Geduld


4xim Jahr

Neues Feature aktiv

Rückmeldung zu offenen Fragen, Angebot + Spez.

RMT

Email

Was beinhaltet die Rückmeldung der TUG• Request-Status

• Fachliche Rückfragen

• Ggf. Hinweise zu Anforderungen anderer Hochschulen

• Beurteilung des Features im Campus Online Kontext

• Angebot (Rückmeldung über Aufwand/Personentage) + inhaltliche Spezifikation zum Angebot

• Informationen zum Umsetzungszeitpunkt




RMT


Geduld


4xim Jahr

Neues Feature aktiv


RMT

Documents

TUMonline: Von der Idee zum neuen Feature/vom Fehler zur ... · •Standardmäßig - via RMT •Wenn es inhaltlich knifflig oder kontrovers wird –per Telefon (E-Mail) •Wenn es