Wunsch: Unterschied zwischen den Versionen

Aus TraiNexWiki
Wechseln zu:Navigation, Suche
(Allgemeines)
 
(62 dazwischenliegende Versionen von 7 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
  
 +
== Allgemeines ==
 +
Wir unterscheiden grob zwischen Fehlern und Anregungen.
 +
 +
Fehler mit [[Fehlermeldung|Fehlermeldungen]] werden von uns möglichst innerhalb von 36 Werktags-Stunden behoben.
 +
Senden Sie uns dazu einfach formlos die Fehlermeldung in einer Mail. Wir melden uns dann schnellstmöglich.
 +
 +
== Anregungen ==
 +
Sie haben einen dringenden Wunsch? Das TraiNex lebt auch von den Anregungen der Kunden. Wir freuen uns über jede Anregung. Bitte haben Sie aber Verständnis dafür, dass nur ausgewählte Wünsche Einzug finden können in das Produkt TraiNex. Ihren Wunsch müssen wir immer abgleichen mit der technologische Machbarkeit, der Passgenauigkeit zum Produkt und der Wirtschaftlichkeit von Entwicklung und Dauerbetrieb. Optimal sind Wünsche, die TraiNex funktional für alle Kunden verbessern, dabei allgemein die [[User Experience|Nutzerfreude]] erhöhen und technologisch machbar in wirtschaftlicher Form realisierbar sind
 +
 +
[[Datei:Wunsch2.JPG|thumb|right|Button für Feature-Request nach Zuordnung des Sonderrechts 201|350px]]
  
Sie haben einen dringenden Wunsch? Das TraiNex lebt auch von den Anregungen der Kunden. Wir freuen uns über Ihre Anregungen.
+
[[Datei:wunschseite.JPG|thumb|right|Teil des Feature-Wunsch-Formulars|350px]]
  
Wir unterscheiden grob zwischen Fehlern und Anregungen.  
+
Anregungen leiten Sie bitte nur strukturiert an uns weiter. Berechtigte Administratoren auf Kundenseite (mit Sonder[[Sonderfunktion|recht]] 201) haben unter Admin die Möglichkeit, einen Wunsch/FeatureRequest zu formulieren.
 +
<BR>Bitte geben Sie
 +
<UL>
 +
<LI>die Dringlichkeit,
 +
<LI>die Wichtigkeit und
 +
<LI>das vorhandene Budget an.
 +
</UL>
 +
Alternativ steht hier eine [[https://www.trainex22.de/campusmanagement/Projektvorschlag_TraiNex_kd.doc Word-Vorlage]] zur Verfügung. 
 +
 
 +
<BR> Ohne diese 3 Angaben kann die Anregung im Sinne einer [[Zusatzleistungen|Auftrags-Programmierung]] nicht geprüft werden.<BR>
 +
Wir werden danach zeitnah entscheiden, ob die Anregung geprüft werden kann und ob bzw. wann und mit welcher Priorität der Wunsch erfüllt werden kann.
 +
 
 +
== Umsetzung ==
  
Fehler mit Fehlermeldungen werden von uns möglichst innerhalb 36 Stunden behoben. Senden Sie uns dazu einfach formlos die Fehlermeldung in einer Mail. Wir melden uns dann schnellstmöglich.
 
  
Anregungen leiten Sie bitte nur strukturiert an uns weiter. Berechtigte Administratoren auf Kundenseite haben unter Admin/Logdatei die Möglichkeit, einen Wunsch/FeatureRequest zu formulieren. Bitte geben Sie die Dringlichkeit/Wichtigkeit und das vorhandene Budget an.
+
Für die Realisation eines Wunsches gehen Sie bitte von zwei bis neun Monaten Entwicklungszeit aus. Um eine qualitativ gute Umsetzung zu realisieren, halten wir uns intern dabei an die folgenden Arbeits- und Prüfschritte.
Wir werden danach entscheiden, ob und wann und mit welcher Priorität der Wunsch erfüllt werden. Bitte haben Sie Verständnis dafür, dass nicht jeder Wunsch Einzug finden kann in das Produkt TraiNex.  
 
  
Sobald wir begonnen haben mit der Wunschbearbeitung, werden folgende Schritte bei uns intern ausgeführt:
+
== Prüfung des Wunsches oder der Anregung ==
  
 
+
Durchführung einer ersten Grob-Prüfung:
rste Grob-Prüfung  
 
  
*ist es ein a. Code-Fehler, ein b. logischer Fehler oder ein c. funktionaler Wunsch
+
*Ist es ein a. Code-Fehler, ein b. logischer Fehler oder ein c. funktionaler Wunsch?
  
Falls a oder b:  
+
Falls es sich um einen a- oder b-Fehler handelt:  
Fehler innerhalb 36 Stunden reproduzieren und beheben
+
Fehler innerhalb von 36 Stunden reproduzieren und beheben
  
 
Falls c:  
 
Falls c:  
  
*Prüfung der erforderlichen Funktionalität
 
  
**ist die geforderte Funktionalität derzeit bereits verfügbar?
+
1.Prüfung der erforderlichen Funktionalität
**ist der Wunsch mit einem abgewandelten Prozess in TraiNex bereits verfügbar?  
+
 
**würde die Realisation die Bedienung für andere Nutzer erheblich erschweren?
+
:1.1 Ist die geforderte Funktionalität derzeit bereits verfügbar?
 +
:1.2 Ist der Wunsch mit einem abgewandelten Prozess in TraiNex bereits verfügbar?  
 +
:1.3 Würde die Realisation die Bedienung für andere Nutzer erheblich erschweren?
 +
:1.4 Prüfung von Dringlichkeit/Wichtigkeit aus Kundensicht / aus TraiNex-Sicht
 +
 
 +
2. Ist es ein allgemeines, ein kundenindividuelles oder ein nutzerindividuelles Problem?
 +
 
 +
3. Ist die Funktion bei anderen Kunden ebenfalls sinnvoll einsetzbar oder ggf. bereits gewünscht?
 +
 
 +
4. Prüfung der Auswirkungen auf Datenschutz 
 +
: 4.1 Wer darf diese Daten sehen oder nicht sehen? Wer darf schreiben?
 +
: 4.2 Prüfung der Auswirkungen auf das Rechtekonzept (Sind Sonderrechte betroffen?)
 +
: 4.3 Ist eine Dokumentation in der Logdatei erforderlich?
 +
5. Ist das Backup betroffen?
 +
 
 +
6. Prüfung der Auswirkung auf die Serversicherheit?
 +
 
 +
7. Prüfung der Auswirkung auf die Page-Performance? Performance-Änderung in Millisekunden?
 +
 
 +
8. Auswirkung(en) auf Haftungsrisiko/Schadenersatz?
 +
 
 +
9. Prüfung der Kompatibilität zu dem relationalen Datenmodell (Datenbankebene)
 +
: 9.1 Welche Tabellen sind betroffen?
 +
: 9.2 Welche Felder sind betroffen?
 +
: 9.3 Sind neue Felder erforderlich?
 +
: 9.4 Hätte die Änderung eine Auswirkung auf den Altbestand?
 +
: 9.5 Hätte die Änderung eine Auswirkung auf die zukünftige Fortentwicklung des Systems?
 +
 
 +
10. Prüfung der Auswirkungen auf Textbausteine
 +
 
 +
11. Mobile Web-App betroffen?
 +
 
 +
12. Navigationsmenüs betroffen? Haupt-/Sub-/Nebennavigation und Direktsprung? Englische Menüvariante?
 +
 
 +
13. Infoscreen betroffen?
 +
 
 +
14. Prüfung der Kompatibilität zu dem vorhandenen Code
 +
: 14.1 Welches Modul ist betroffen?
 +
: 14.2 Welche Nebenmodule sind nebenbei betroffen?
 +
: 14.3 Welche Dateien sind betroffen?
 +
: 14.4 Sind SQL-Abfragen betroffen?
 +
: 14.5 Sind Schreibvorgänge erforderlich?
 +
: 14.6 Sind physische Datei-Speichervorgänge erforderlich?
 +
 
 +
15. Realisation
 +
: 15.1 Ist der Antragsteller berechtigt zur Antragstellung?
 +
: 15.2 Welcher Rahmenvertrag liegt vor?
 +
: 15.3 Liegt ein Auftrag vor (Budget? Tagessätze nach [[Zusatzleistungen]])
 +
: 15.4 Sind die Rechte geklärt?
 +
: 15.5 Welcher Development-Slot ist verfügbar?
 +
: 15.6 Aufnahme inkl. Ticket?
 +
 
 +
16. Dokumentation des Wunsches (englisch/deutsch)
 +
: 16.1 Ggf. Erstellung eines ERM/EPK/UML-Modells
 +
: 16.2 Drei-Ebenen-Modell oder ARIS-Systemhaus notwendig?
 +
: 16.3 Formularlayout (Usability/Farben)
 +
: 16.4 Ggf. Erstellung einer Excel-Simulation
 +
: 16.5 Diskussion im Development-Meeting
 +
: 16.6 Abschätzung von Realisationskosten   
  
**ist es ein kundenindividuelles oder ein nutzerindividuelles Problem?
+
17. Überschneidung mit anderen Modulen, die sich in der Entwicklung befinden
**ist die Funktion bei anderen Kunden ebenfalls sinnvoll einsetzbar oder ggf. bereits gewünscht?
+
: 17.1 Interne Vergabe an zuständigen Developer
 +
: 17.2 Zwischenpräsentation Developer
 +
: 17.3 Endpräsentation Developer
 +
: 17.4 Nachbearbeitung/Vereinheitlichung 
  
*Prüfung der Auswirkungen auf Datenschutz
+
18. Debugging
**wer darf diese Daten sehen oder nicht sehen? Wer darf schreiben?
+
: 18.1 Erstellung eines Debugging-Möglichkeitenbaums
**Prüfung der Auswirkungen auf das Rechtekonzept (Sind Sonderrechte
+
: 18.2 Debugging aller Möglichkeiten mit allen Rechten (Stud/Admin/Lehrkraft)
betroffen?)
+
: 18.3 Debugging mit unterschiedlichen Browsern/Betriebssystemen/Mobil
**ist Dokumentation in Logdatei erforderlich
+
: 18.4 Dokumentation aufgetretener Fehler
*ist das Backup betroffen?
+
: 18.5 Ist die Nutzung aus Nutzersicht aufgabenangemessen? Erwartungskonform? Fehlertolerant? ([[Usability]])
*Prüfung der Auswirkung auf Serversicherheit?
+
: 18.6 Abschlussbesprechung intern
*Prüfung der Auswirkung auf Page-Performance? Performance-Änderung in Millisekunden?
+
: 18.7 Planung des Update-Prozesses (Umstellung DB/Code/Rechte)
*Auswirkung auf ISO 27001?
 
  
*Prüfung der Kompatibilität zu dem relationalen Datenmodell (Datenbankebene)
+
19. Information des Kunden/Rechnungsstellung
**welche Tabellen sind betroffen?
+
: 19.1 Schulung des Kunden/Präsentation
**welche Felder sind betroffen?
+
: 19.2 Änderung des Wikis
**sind neue Felder erforderlich?
+
: 19.3 Aufnahme in die Schulungen der TraiNex-Akademie
**hätte die Änderung eine Auswirkung auf den Altbestand?
 
**hätte die Änderung eine Auswirkung auf die zukünftige Fortenwicklung des Systems?
 
  
 +
20. Update
 +
: 20.1 Ggf. Absprache des Update-Datums mit Auftraggeber
 +
: 20.2 Update beim Auftraggeber-Kunden 
 +
: 20.3 Prüfung ggf. auftretender Fehler beim Auftraggeber-Kunden inkl. ggf. Nachbesserung
 +
: 20.4 Ggf. außerplanmäßiges Update bei den Kunden, die das Modul ebenfalls intensiv nutzen
 +
: 20.5 Aufnahme in den normalen Update-Zyklus
  
*Prüfung der Auswirkungen auf Textbausteine
+
== Kundenfeedback ==
 +
Bei Modulneuerungen/-verbesserungen beachten Sie bitte: Unser Ziel ist eine stetige Verbesserung der Qualität der Funktionen. Wir gehen davon aus, dass das funktionell erweiterte Modul fehlerfrei funktioniert. Trotz sorgfältiger Kontrollen und Prüfungen von Code und Funktion kann es aber immer vorkommen, dass eine neue Funktion zu Fehlern oder Problemen in anderen Bereichen des verbesserten Moduls oder sogar in anderen Modulen führt. Diese Fehler können technischer oder logischer Natur sein und tauchen teils erst durch die intensive "echte" praktische Anwendung auf. Der auftraggebende Kunde, der dieses verbesserte Modul ausgeliefert bekommt, wird gebeten, dieses Modul in den ersten Tagen besonders aufmerksam zu benutzen. Teilen Sie uns ggf. auftretende Fehler bitte umgehend und möglichst gut dokumentiert mit, damit wir diese dann beheben können.
  
*Prüfung der Kompatibilität zu dem vorhandenen Code
 
**welches Modul ist betroffen?
 
**welche Nebenmodule sind nebenbei betroffen?
 
**welche Dateien sind betroffen?
 
**sind SQL-Abfragen betroffen?
 
**sind Schreibvorgänge erforderlich?
 
**sind pyhsische Datei-Speichervorgänge erforderlich?
 
  
*Realisation
 
**ist der Antragsteller berechtigt zur Antragstellung?
 
**welcher Rahmenvertrag liegt vor?
 
**liegt ein Auftrag vor (Budget?)
 
**sind die Rechte geklärt?
 
**welcher Development-Slot ist verfügbar?
 
  
*Dokumentation des Wunsches (english/deutsch)
 
**ggf. Erstellung eines ERM/EPK/UML-Modells
 
**Formularlayout (Usability/Farben)
 
**ggf. Erstellung einer Excel-Simulation
 
**Diskussion im Development-Meeting
 
**Abschätzung von Realisationskosten   
 
  
**Überschneidung mit anderen Moduln, die sich in Entwicklung befinden
+
Übrigens versuchen wir die Vorteile der agilen Softwareentwicklung in Anlehnung an SCRUM zu nutzen.
**interne Vergabe an zuständigen Developer
+
Mehr dazu hier: https://de.wikipedia.org/wiki/Agile_Softwareentwicklung bzw. hier: https://de.wikipedia.org/wiki/Scrum
**Zwischenpräsentation Developer
+
Bitte beachten Sie auch die Preisliste für [[Zusatzleistungen]].
**Endpräsentation Developer
 
**Nachbearbeitung/Vereinheitlichung 
 
  
*Debugging
+
==Sonderfunktion==
**Erstellung eiens Debugging-Möglichkeitenbaums
+
Admins mit der [[Sonderfunktion]] 201 sind Ansprechpartner für TraiNex-Development / Zugriff auf FeatureRequest.
**Debugging aller Möglichkeiten mit allen Rechten (Stud/Admin/Dozent)
 
**Dokumentation aufgetretener Fehler
 
**Abschlußbesprechung intern
 
**Planung des Updates-Prozesses (Umstellung DB/Code/Rechte)
 
  
**Information des Kunden/Rechnungsstellung
+
==Letzte funktionale Änderungen==
**Schulung des Kunden
+
*Mai 2016: Einrichtung eines Ticket-Systems zur Verwaltung von Anregungen oder Fehlern <!-- in Hauptartikel integriert iHAi--->
**Änderung des Wiki
 
**Aufnahme in Schulung der TraiNex-Akademie
 

Aktuelle Version vom 18. Dezember 2023, 12:41 Uhr

Allgemeines

Wir unterscheiden grob zwischen Fehlern und Anregungen.

Fehler mit Fehlermeldungen werden von uns möglichst innerhalb von 36 Werktags-Stunden behoben. Senden Sie uns dazu einfach formlos die Fehlermeldung in einer Mail. Wir melden uns dann schnellstmöglich.

Anregungen

Sie haben einen dringenden Wunsch? Das TraiNex lebt auch von den Anregungen der Kunden. Wir freuen uns über jede Anregung. Bitte haben Sie aber Verständnis dafür, dass nur ausgewählte Wünsche Einzug finden können in das Produkt TraiNex. Ihren Wunsch müssen wir immer abgleichen mit der technologische Machbarkeit, der Passgenauigkeit zum Produkt und der Wirtschaftlichkeit von Entwicklung und Dauerbetrieb. Optimal sind Wünsche, die TraiNex funktional für alle Kunden verbessern, dabei allgemein die Nutzerfreude erhöhen und technologisch machbar in wirtschaftlicher Form realisierbar sind

Button für Feature-Request nach Zuordnung des Sonderrechts 201
Teil des Feature-Wunsch-Formulars

Anregungen leiten Sie bitte nur strukturiert an uns weiter. Berechtigte Administratoren auf Kundenseite (mit Sonderrecht 201) haben unter Admin die Möglichkeit, einen Wunsch/FeatureRequest zu formulieren.
Bitte geben Sie

  • die Dringlichkeit,
  • die Wichtigkeit und
  • das vorhandene Budget an.

Alternativ steht hier eine [Word-Vorlage] zur Verfügung.


Ohne diese 3 Angaben kann die Anregung im Sinne einer Auftrags-Programmierung nicht geprüft werden.
Wir werden danach zeitnah entscheiden, ob die Anregung geprüft werden kann und ob bzw. wann und mit welcher Priorität der Wunsch erfüllt werden kann.

Umsetzung

Für die Realisation eines Wunsches gehen Sie bitte von zwei bis neun Monaten Entwicklungszeit aus. Um eine qualitativ gute Umsetzung zu realisieren, halten wir uns intern dabei an die folgenden Arbeits- und Prüfschritte.

Prüfung des Wunsches oder der Anregung

Durchführung einer ersten Grob-Prüfung:

  • Ist es ein a. Code-Fehler, ein b. logischer Fehler oder ein c. funktionaler Wunsch?

Falls es sich um einen a- oder b-Fehler handelt: Fehler innerhalb von 36 Stunden reproduzieren und beheben

Falls c:


1.Prüfung der erforderlichen Funktionalität

1.1 Ist die geforderte Funktionalität derzeit bereits verfügbar?
1.2 Ist der Wunsch mit einem abgewandelten Prozess in TraiNex bereits verfügbar?
1.3 Würde die Realisation die Bedienung für andere Nutzer erheblich erschweren?
1.4 Prüfung von Dringlichkeit/Wichtigkeit aus Kundensicht / aus TraiNex-Sicht

2. Ist es ein allgemeines, ein kundenindividuelles oder ein nutzerindividuelles Problem?

3. Ist die Funktion bei anderen Kunden ebenfalls sinnvoll einsetzbar oder ggf. bereits gewünscht?

4. Prüfung der Auswirkungen auf Datenschutz

4.1 Wer darf diese Daten sehen oder nicht sehen? Wer darf schreiben?
4.2 Prüfung der Auswirkungen auf das Rechtekonzept (Sind Sonderrechte betroffen?)
4.3 Ist eine Dokumentation in der Logdatei erforderlich?

5. Ist das Backup betroffen?

6. Prüfung der Auswirkung auf die Serversicherheit?

7. Prüfung der Auswirkung auf die Page-Performance? Performance-Änderung in Millisekunden?

8. Auswirkung(en) auf Haftungsrisiko/Schadenersatz?

9. Prüfung der Kompatibilität zu dem relationalen Datenmodell (Datenbankebene)

9.1 Welche Tabellen sind betroffen?
9.2 Welche Felder sind betroffen?
9.3 Sind neue Felder erforderlich?
9.4 Hätte die Änderung eine Auswirkung auf den Altbestand?
9.5 Hätte die Änderung eine Auswirkung auf die zukünftige Fortentwicklung des Systems?

10. Prüfung der Auswirkungen auf Textbausteine

11. Mobile Web-App betroffen?

12. Navigationsmenüs betroffen? Haupt-/Sub-/Nebennavigation und Direktsprung? Englische Menüvariante?

13. Infoscreen betroffen?

14. Prüfung der Kompatibilität zu dem vorhandenen Code

14.1 Welches Modul ist betroffen?
14.2 Welche Nebenmodule sind nebenbei betroffen?
14.3 Welche Dateien sind betroffen?
14.4 Sind SQL-Abfragen betroffen?
14.5 Sind Schreibvorgänge erforderlich?
14.6 Sind physische Datei-Speichervorgänge erforderlich?

15. Realisation

15.1 Ist der Antragsteller berechtigt zur Antragstellung?
15.2 Welcher Rahmenvertrag liegt vor?
15.3 Liegt ein Auftrag vor (Budget? Tagessätze nach Zusatzleistungen)
15.4 Sind die Rechte geklärt?
15.5 Welcher Development-Slot ist verfügbar?
15.6 Aufnahme inkl. Ticket?

16. Dokumentation des Wunsches (englisch/deutsch)

16.1 Ggf. Erstellung eines ERM/EPK/UML-Modells
16.2 Drei-Ebenen-Modell oder ARIS-Systemhaus notwendig?
16.3 Formularlayout (Usability/Farben)
16.4 Ggf. Erstellung einer Excel-Simulation
16.5 Diskussion im Development-Meeting
16.6 Abschätzung von Realisationskosten

17. Überschneidung mit anderen Modulen, die sich in der Entwicklung befinden

17.1 Interne Vergabe an zuständigen Developer
17.2 Zwischenpräsentation Developer
17.3 Endpräsentation Developer
17.4 Nachbearbeitung/Vereinheitlichung

18. Debugging

18.1 Erstellung eines Debugging-Möglichkeitenbaums
18.2 Debugging aller Möglichkeiten mit allen Rechten (Stud/Admin/Lehrkraft)
18.3 Debugging mit unterschiedlichen Browsern/Betriebssystemen/Mobil
18.4 Dokumentation aufgetretener Fehler
18.5 Ist die Nutzung aus Nutzersicht aufgabenangemessen? Erwartungskonform? Fehlertolerant? (Usability)
18.6 Abschlussbesprechung intern
18.7 Planung des Update-Prozesses (Umstellung DB/Code/Rechte)

19. Information des Kunden/Rechnungsstellung

19.1 Schulung des Kunden/Präsentation
19.2 Änderung des Wikis
19.3 Aufnahme in die Schulungen der TraiNex-Akademie

20. Update

20.1 Ggf. Absprache des Update-Datums mit Auftraggeber
20.2 Update beim Auftraggeber-Kunden
20.3 Prüfung ggf. auftretender Fehler beim Auftraggeber-Kunden inkl. ggf. Nachbesserung
20.4 Ggf. außerplanmäßiges Update bei den Kunden, die das Modul ebenfalls intensiv nutzen
20.5 Aufnahme in den normalen Update-Zyklus

Kundenfeedback

Bei Modulneuerungen/-verbesserungen beachten Sie bitte: Unser Ziel ist eine stetige Verbesserung der Qualität der Funktionen. Wir gehen davon aus, dass das funktionell erweiterte Modul fehlerfrei funktioniert. Trotz sorgfältiger Kontrollen und Prüfungen von Code und Funktion kann es aber immer vorkommen, dass eine neue Funktion zu Fehlern oder Problemen in anderen Bereichen des verbesserten Moduls oder sogar in anderen Modulen führt. Diese Fehler können technischer oder logischer Natur sein und tauchen teils erst durch die intensive "echte" praktische Anwendung auf. Der auftraggebende Kunde, der dieses verbesserte Modul ausgeliefert bekommt, wird gebeten, dieses Modul in den ersten Tagen besonders aufmerksam zu benutzen. Teilen Sie uns ggf. auftretende Fehler bitte umgehend und möglichst gut dokumentiert mit, damit wir diese dann beheben können.



Übrigens versuchen wir die Vorteile der agilen Softwareentwicklung in Anlehnung an SCRUM zu nutzen. Mehr dazu hier: https://de.wikipedia.org/wiki/Agile_Softwareentwicklung bzw. hier: https://de.wikipedia.org/wiki/Scrum Bitte beachten Sie auch die Preisliste für Zusatzleistungen.

Sonderfunktion

Admins mit der Sonderfunktion 201 sind Ansprechpartner für TraiNex-Development / Zugriff auf FeatureRequest.

Letzte funktionale Änderungen

  • Mai 2016: Einrichtung eines Ticket-Systems zur Verwaltung von Anregungen oder Fehlern