Advertisement
Patasuss

ToDo-List SWP

Oct 14th, 2015
367
0
Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 4.78 KB | None | 0 0
  1. >> Name: UniCode <<
  2.  
  3. >> Git-Rep:
  4. unicode-swp2
  5. https://gitlab.informatik.uni-bremen.de/wilde/unicode-swp2.git
  6.  
  7. >> Nutzernamen:
  8. Bea: s_iswbaz ( ._. whhyyyy)
  9. Patrick: wilde
  10. Geni: babkin
  11. Mehmet: mehmet2
  12. Nikhil: nikhil
  13. ELias: elias1
  14.  
  15. >> Termine:
  16. o 19.10 13:00 MZH E0 - Gruppentreffen | Alle waren da
  17.  
  18.  
  19. ToDo-Liste:
  20. ===========
  21. o Gruppenaktion (unverbunden mit SWP2!)
  22. o 2 Leute für Kundengespräch (s.u.)
  23. o Fragenkatalog entwickeln (s.u.)
  24. o Termin für JGradebook
  25. o Herausfinden: Was kann JGradebook alles?
  26. o Datenstruktur studieren (um Adapter zu entwerfen)
  27. o Test-Datensatz von PABO-Daten studieren
  28. o Termin für Kundeninterview - Mittwoch / Freitag?
  29. o Bei MEMS eintragen - DONE!
  30. o Spezifikation studieren
  31. o Servermietung erkundigen und ggf. ausführen (mögl. Uni-angebot)
  32. o Google-Dokumente nutzen
  33.  
  34. (Zukunft)
  35. o GUI Prototyp, wer ist hier kreativ?
  36. o Wer macht hauptsächlich Planung (z.B. Anforderungsspez.)?
  37. o Macht jeder DB oder nur Spezis?
  38. o evolutionärer Prototyp?
  39.  
  40.  
  41. Notizen:
  42. ==========
  43. o 2x / Woche Treffen (nach Möglichkeit)
  44. Montags, Mittwochs sind freie Tage
  45. o Kundeninterview: Lydia und Geni
  46.  
  47. Grundsätze: (Köpfung bei Nicht-Einhaltung! *grr*)
  48. ==========
  49. o Modularisierung -> 2er Gruppen -> Rotation zur Überprüfung
  50. o Nur Eigner eines Code verändern diesen (z.B. auf Anforderung) | Kein Pfuschen!
  51. o Klar definierte Schnittstellen
  52. o Konstruktives, konkretes Feedback
  53. o Klar definierte Arbeitspaketbeschreibungen!
  54. o Fragen sind erwünscht und sollten gestellt werden!
  55. o Tests sollten nicht vergessen werden (JUnit oder per Hand?)
  56.  
  57. Dokumente:
  58. ==========
  59. o 19.12 Architekturbeschreibung
  60. o 4.3 Abgabe alles
  61.  
  62. Fragekatalog: (Version: 19.11.2015, Treffen U-01)
  63. ===========
  64. o Benutzergruppen und ihre Berechtigungen
  65. -Tutoren, Dozenten, was noch?
  66. -Was ist der Unterschied zwischen den Rechten?
  67. -Mehrere Dozenten pro Veranstaltung? Gibt es einen Master/Owner?
  68. -Falls es Master gibt: Was kann er mehr? "Kick"-Rechte
  69. -Mehrere Tutoren pro Tutorium?
  70. -Rechte für:
  71. -Studenten einfügen / kicken / verschieben
  72. -Noten eintragen (gruppenspezifisch, a la: Tutor1 kann nur für Tut1 Noten eintragen)
  73. -Neue Veranstaltung / Veranstaltung löschen
  74. -Neue Untergruppe / Tutorium
  75. -Erzeugen Tutoren ihre Tutorien selber oder werden 'reingezogen'?
  76. -Sind Studenten Nutzer?
  77. -Wenn ja: Was machen diese mit dem System?
  78. -Können Studenten sich selbst in Veranstaltung / Tutorien eintragen oder werden sie eingetragen
  79. o Eckdaten einer Veranstaltung / Note / Prüfung / Student was muss alles an Info gespeichert werden?
  80. -Wie werden diese importiert? (StudIP, manuelle Eintragung)
  81. -Welche Daten der Studenten sind vorhanden? (MatNr, Name, Benutzername)
  82. o Eckdaten von den Nutzern?
  83. -Namen, Status (Doz | (Stud) | Tut)
  84. o Wie läuft das Generieren von Scheinen ab?
  85. -Bevorzugtes Ausgabeformat? PDF, LaTeX-Datei, CSV, Text?
  86. o Wie lange werden Daten aufgehoben, externe oder interne Datensicherung?
  87. -Müssen diese verschlüsselt werden? (wegen Sicherheit)
  88. o Welche Verschlüsselung ist einzusetzen? (s. nächste Frage)
  89. -Wie wird verschlüsselt (SSL oder was das war)
  90. -Was wird alles verschlüsselt (Datenverkehr, gespeicherte Daten)
  91. o Was sind Grundzüge von Datenschutz / Datensicherheit? Vorstellungen?
  92. o Wie sollen Tutorien/Gruppen im System aufegführt sein? Untergruppe eines Kurses / Tutoriums?
  93. -Komische Frage, zu technisch, kann der wohl nicht beantworten
  94. o Struktur der Noten, wie sollen sie eingetragen werden?
  95. o Berechnungsvorschriften: Drag'n'Drop/Klicken oder Formel?
  96. o Sollen Gruppen benotet werden können (stellen wir diese Frage überhaupt)
  97. o Wie sollen die Termine geplant werden
  98. - pro Veranstaltung, wahrscheinlich
  99. - Überlagerungscheck?
  100. - müssen wohl verschoben werden können
  101. - Was kann sonst mit Terminen gemacht werden?
  102. - Sollen Benutzer mit eingeplant werden? (Tutoren müssen bei Prüfung anwesend sein z.B.)
  103. - Weitere wichtige Eckdaten?
  104. o Welche Daten liefert StudIP?
  105. -Format, Inhalt
  106. -Direkter Transfer? (unwahrscheinlich)
  107. o Kennen Tutoren Matrikelnummern?
  108. o Extrawünsche außerhalb der Anforderungen?
  109. o Wie wichtig ist Übersichtlichkeit, wie weit kann man Kompromisse machen?
  110. - wegen Tabellenübersichten
  111. - Terminkalender
  112. - Wünsche des Nutzers zur Benutzung
  113.  
  114. Psycho-Selbst-Einschätzung: (?)
  115. ============
  116. o Mehmet hat keine Probleme. Denkt Nikhil.
  117. o Geni ist manchmal zu komplex, sieht seinen Code als perfekt an. Unter Zeitdruck schlecht.
  118. o Patrick kann zwar gut programmieren, muss aber erst ins Laufen kommen. Nervt mit Projektmanagement.
  119. o Elias braucht etwas länger, bis er auf eine effiziente Lösung kommt, lange Researchzeit
  120. o Nikhil verfällt in Zustand von schlechter Kommunikation. (Prescht vorran?). Kann viel reden.
  121. o Lydia gibts nicht mehr.
  122. o http://www.psychomeda.de/online-tests/persoenlichkeitstest.html
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement