Wunsch: Unterschied zwischen den Versionen
Tberg (Diskussion | Beiträge) (→Allgemeines) |
GinaW (Diskussion | Beiträge) (→Letzte funktionale Änderungen) |
||
Zeile 128: | Zeile 128: | ||
Mehr dazu hier: https://de.wikipedia.org/wiki/Agile_Softwareentwicklung | Mehr dazu hier: https://de.wikipedia.org/wiki/Agile_Softwareentwicklung | ||
Bitte beachten Sie auch die Preisliste für [[Zusatzleistungen]] | 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== | ==Letzte funktionale Änderungen== | ||
*Mai 2016: Einrichtung eines Ticket-Systems zur Verwaltung von Anregungen oder Fehlern <!-- in Hauptartikel integriert iHAi---> | *Mai 2016: Einrichtung eines Ticket-Systems zur Verwaltung von Anregungen oder Fehlern <!-- in Hauptartikel integriert iHAi---> |
Version vom 4. September 2018, 14:19 Uhr
Inhaltsverzeichnis
Allgemeines
Sie haben einen dringenden Wunsch? Das TraiNex lebt auch von den Anregungen der Kunden. Wir freuen uns über Ihre Anregungen.
Wir unterscheiden grob zwischen Fehlern und Anregungen.
Fehler mit Fehlermeldungen werden von uns möglichst innerhalb von 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 (mit Sonderrecht 201 ) haben unter Admin die Möglichkeit, einen Wunsch/FeatureRequest zu formulieren. Bitte geben Sie die Dringlichkeit/Wichtigkeit und das vorhandene Budget an.
Wir werden danach entscheiden, ob und wann und mit welcher Priorität der Wunsch erfüllt werden kann. Bitte haben Sie Verständnis dafür, dass nicht jeder Wunsch Einzug finden kann in das Produkt TraiNex.
Umsetzung
Für die Realisation eines Wunsches gehen Sie bitte von zwei bis neun Monaten Entwicklungszeit aus. Bei einfachen Wünschen nutzen wir das 3-Ebenen-Modell und unterscheiden zwischen Präsentationsschicht, Applikationsschicht und Datenbankschicht. Bei komplexeren Wünschen nutzen wir das ARIS-Systemhaus, das in Fachkonzept, DV-Konzept und Implementierungskonzept bei Daten-, Funktionen-, Organisations- und Steuerungsicht unterscheidet. 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 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 die ISO 27001?
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 Fortenwicklung 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 pyhsische 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 (english/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/Dozent)
- 18.3 Debugging mit unterschiedlichen Browsern/Betriebssystemen/Mobil
- 18.4 Dokumentation aufgetretener Fehler
- 18.5 Ist die Nutzung aus Nutzersicht aufgabenangemessen? erwartungskonform? fehlertolerant?
- 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 Wiki
- 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. ausserplanmässiges Update bei den 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 Moduln 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, dies 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 zu nutzen.
Mehr dazu hier: https://de.wikipedia.org/wiki/Agile_Softwareentwicklung
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