M318 Moduldokumentation

Projekt

Online Arbeitsjournal

Autor: Datum:

Patrik Marxer Dezember 2012, Januar 2013

Inhaltsverzeichnis
Inhaltsverzeichnis.................................................................................................................................2 Modul 318, Kompetenzen und Handlungsziele ..................................................................................3 Einfhrung / bersicht.........................................................................................................................4 Einfhrung ......................................................................................................................................4 Ziel...................................................................................................................................................4 Lizenzen und Quellenangaben.........................................................................................................4 Ablauf in Kurzform und Benotung.......................................................................................................6 Vorbereitungsarbeiten......................................................................................................................6 1. Analyse und Konzept...................................................................................................................6 2. Planung........................................................................................................................................6 3. Umsetzung...................................................................................................................................6 4. Prsentation und Reflexion..........................................................................................................7 Benotung...............................................................................................................................................8 Abzugebende Dokumente und Daten..............................................................................................8 Produkt-Anforderungen........................................................................................................................9 Anforderungsliste.............................................................................................................................9 Tipps...................................................................................................................................................13 Anhang, Beschreibung der Dokumente, Beispiele.............................................................................14 Arbeitsjournal................................................................................................................................14 Beispiel......................................................................................................................................14 Eigene Anforderungsliste...............................................................................................................14 Beispiel......................................................................................................................................15 Milestones......................................................................................................................................15 Beispiel......................................................................................................................................16 Programmdokumentation...............................................................................................................16 Beispiel: Code-Smells...............................................................................................................17 Testdokumentation.........................................................................................................................17 Beispiel: Vorschlge fr die Checkliste....................................................................................17 Handbuch.......................................................................................................................................18 Reflexion........................................................................................................................................18 Gruppenteil................................................................................................................................18 Individueller Teil.......................................................................................................................19

Patrik Marxer

Modul 318, Online-Arbeitsjournal

2 / 19

Modul 318, Kompetenzen und Handlungsziele

(Quelle I-CH) Modulnummer Titel Kompetenz 318 Analysieren und objektbasiert programmieren mit Komponenten Eine Aufgabe analysieren, mit einer auf RAD-Technologie (Rapid Application Development) basierenden Programmiersprache mit strukturierten und objektbasierten Methoden implementieren, dokumentieren und testen. 1. 2. 3. Problemstellung analysieren, Benutzerschnittstelle entwerfen und Ablufe mit strukturierten Methoden darstellen. Grafische Benutzerschnittstelle gestalten und realisieren. Erarbeitete Programmvorgabe mit einer objektbasierten ereignisorientierten Programmiersprache mit Einsatz von Ablaufstrukturelementen, eigenen Prozeduren und Funktionen implementieren. Beim Programmieren vorgegebene Codekonventionen einhalten, das Programm in Line dokumentieren und dabei auf Wartbarkeit und Nachvollziehbarkeit achten. Ausgehend von der Aufgabenstellung Testflle erstellen, das Programm testen und Fehler beheben.

Handlungsziele

4.

5.

Patrik Marxer

Modul 318, Online-Arbeitsjournal

3 / 19

Einfhrung / bersicht
Einfhrung
Sptestens am Ende der Lehre mssen Sie im Rahmen der Individuellen Prfungsarbeit (IPA) ein Projekt mit einem Umfang von 80 bis 120 Stunden Arbeitszeit selber planen und fachgerecht durchzufhren knnen. Erfahrungen mit IPA Arbeiten haben gezeigt, dass die Phasen Analyse und Konzeption, sowie die Dokumentation mit Fhren des Arbeitsjournals, Projektplanung und fortlaufende Beschreibung des Projektfortschrittes immer wieder zu Schwierigkeiten gefhrt haben, weil es in der beruflichen Praxis und in der Schule zu wenig gebt wurde. Dieser Umstand wird in diesem Modul bercksichtigt. Ein Projekt ist definiert durch Starttermin, Endtermin und einer Aufgabenstellung mit unbekanntem Lsungsweg. Wie bei der IPA werden Sie im Modul 318 mit diesem Projekt eine Aufgabenstellung mit einem unbekannten, neuartigen Anteil lsen. Es ist voraussichtlich das erste komplexere Projekt, welches Sie in einem Team selbststndig lsen knnen. Deshalb ist die Aufgabenstellung in Vorgehensschritten so aufgebaut, dass Sie beim Lsen in die richtige Richtung fr die Problemlsung gefhrt werden. (In spteren Projekten wird auch das Finden der richtigen Vorgehensschritte Teil der Aufgabenstellung sein).

Ziel
Sie sollen ein Online-Arbeitsjournal realisieren. Sie sollen das Arbeitsjournal selbst programmieren und nutzen, um Ihre eigene Arbeit an diesem Projekt zu dokumentieren. Die Rolle der Lehrperson ist die eines Kunden, der an Sie, als Firma, mit einem Auftrag herantritt, den es in der gegebenen Zeit umzusetzen gilt. Die Lehrperson korrigiert im Speziellen keinen Code fr Sie, dies ist Ihre Aufgabe als auftragnehmende Firma. Er hilft bei kundenspezifischen Problemen, um festzustellen, was berhaupt gewnscht wird und bei wichtigen Entscheidungen (DB-Design, Arbeitsablufe usw.) Das Projekt soll mit einem LAMP-Stack (Linux, MySQL, Apache und PHP) umgesetzt werden.

Lizenzen und Quellenangaben

Sie nennen alle Quellen, die Sie fr die Programmumsetzung heranziehen. Das beinhaltet nichttrivialen Code aus dem Internet, Bibliotheken, Bcher (mit Kapitel und Seitenangaben) und Personen, die Sie untersttzen. Verbindlichkeit Sie unterschreiben am Schluss ebenfalls eine Vereinbarung ber die Selbststndigkeit der Arbeit und Vollstndigkeit der Quellenangaben. Sie unterschreiben auch eine Vereinbarung, den Code unter die folgenden Lizenzen zu stellen.

Patrik Marxer

Modul 318, Online-Arbeitsjournal

4 / 19

Das Projekt untersteht diesen zwei Lizenzen, damit eine Weiterentwicklung durch andere Klassen ohne Probleme mglich ist. Der Source-Code des Programms muss unter die GPL 2.0 oder hher gestellt werden, um nachfolgende Weiterentwicklungen des Programms (z.B. eines darauf folgenden Kurses) zu erlauben. Die von Ihnen erstellte Dokumentation muss unter der Creative-Commons Lizenz CC-BY-SA stehen. Dies erlaubt Modifikationen und Weitergabe der Dokumente, sofern diese wieder unter derselben Lizenz zur Verfgung gestellt werden. Ausserdem muss Ihr Name als Urheber im Dokument erhalten bleiben.

Source-Code

Dokumentation

Patrik Marxer

Modul 318, Online-Arbeitsjournal

5 / 19

Ablauf in Kurzform und Benotung

Dies ist eine Gruppenarbeit. Die Gruppengrsse ist normalerweise 2 Personen, es knnen in begrndeten Fllen andere Gruppengrssen gebildet werden. Bei mehr Personen kann die Anforderung fr die Gruppe entsprechend erhht werden, da mehr Personen mitarbeiten.

Vorbereitungsarbeiten
Erstellen Sie ein Google-Tabellendokument fr die Mitglieder der Gruppe und tragen Sie den Link in das Dokument der Lehrperson ein, damit diese Lesezugriff darauf hat Sie machen sich mit der Problemstellung vertraut. Lesen Sie die Aufgabenstellung, notieren Sie sich Fragen fr die Lehrperson. Machen Sie Skizzen: Oberflchen-Design und Ablufe (auf Papier oder als Wire-Frame) Schauen Sie sich eventuell nach Konkurrenzprodukten um, informieren Sie sich ber Arbeitsablufe und Features dieser Produkte. Welche knnen Sie fr Ihr Produkt nutzen?

1. Analyse und Konzept

Sie haben nun eine Idee der Anforderung und machen sich an die Realisierung des Programmes Dies beinhaltet einen Prototypen des Programms mit folgenden Teilen Datenbank-Schema mit korrekten Primr-/Fremdschlsseln in grafischer Form (Programmvorschlag: MySQL Workbench) Wire-Frame Abbilder der Oberflchen des Programms (Programmvorschlag: FirefoxExtension Pencil) ein Quick-and-Dirty programmierter zentraler Teil des Programms (Sie mssen keinerlei Code-Konventionen einhalten, es soll nicht schn aussehen - dieser Teil dient nur dazu Ihnen eine Vorstellung des noch zu leistenden Arbeitsaufwandes zu vermitteln)

2. Planung
Die Planung beinhaltet eine Vorher- und eine Nachher-Version der folgenden Dokumente Eigene Anforderungsliste (Google-Tabellen-Dokument) Sie definieren Milestones mit konkret definierten Zielen, welche zusammengehrenden Teile fertig sein sollen (mit Nummern aus der Anforderungsliste) mit konkreten Daten, wann es fertig sein soll. Lassen Sie grosszgig Platz - es dauert fast alles lnger als geplant

3. Umsetzung
Den programmierten Prototypen knnen Sie als Inspiration weiterverwenden. Es ist jedoch am Besten, wenn Sie von vorne beginnen, der Code wird dabei sauberer. Sie dokumentieren Ihren Arbeitsfortschritt konkret und detailliert und halten sich dabei an
Modul 318, Online-Arbeitsjournal 6 / 19

Patrik Marxer

die Milestones. Eine Abweichung im Datum oder Ablauf ist immer begrndet und wird vermerkt. Notenrelevante Kriterien Benutzbarkeit: Nutzen Sie Ihr Produkt mglichst bald selbst, um Erfahrungen aus Benutzerperspektive zu sammeln. Dokumentieren Sie die Probleme, und verbessern Sie Ihr Programm. Achten Sie auf gute Programmumsetzung: Duplikate, lange Methoden, globale Variablen, unbersichtlicher Code mit schlechten Kommentaren im Code sind Merkmale von schlechter Umsetzung (siehe Seite 17: Beispiel: Code-Smells). Testen Sie die die Umsetzung: es ist ganz schlecht, wenn Ihr Programm abstrzt, stecken bleibt oder Eingaben akzeptiert, die keinen Sinn ergeben. Dokumentieren Sie die Tests und deren Ergebnisse (siehe Seite 17: Testdokumentation)

4. Prsentation und Reflexion

Prsentation Prsentieren Sie Ihr Programm vor dem Kunden, also der Lehrperson, aber auch den anderen Klassenmitgliedern. Gestalten Sie dies wie eine Verkaufsprsentation. Es soll mglichst alle geforderten Programmteile einthalten, zeigen Sie auch, was Ihr Programm besser kann, als das der anderen. Seien Sie bereit Fragen ber das Programm oder die Umsetzung zu beantworten. Reflexion Jeder Gruppenteilnehme schildert auf mindestens einer A4 Seite Ihre persnliche Reflexion ber den Ablauf des Projekts: Teamarbeit und Umgang miteinander, Arbeitsaufteilung, Hhepunkte und Tiefpunkte/rger, Zufriedenheit ber das Erreichte, Verbesserungsvorschlge fr die Zukunft...

Patrik Marxer

Modul 318, Online-Arbeitsjournal

7 / 19

Benotung
Diese Arbeit wird mit einer Semsternote und einer Modulnote bewertet. Die Noten gelten fr alle Gruppenteilnehmer1. Zur Benotung werden die Dokumente fr die Vertiefungsarbeit (VA) und die Individuellen Produktivarbeit herangezogen 1 Analyse und Konzept Datenbank-Schema Wire-Frame, oder gleichwertige Visualisierung Prototyp (lauffhig) 2 Planung und Dokumentation Arbeitsplanung anhand der eigenen Anforderungsliste Milestones (Planung mit Daten) in zwei Versionen (vorher und nachher) Dokumentation im Arbeitsjournal (zu diesem Zeitpunkt) 3 Realisation Benutzbarkeit (anhand Handbuch und Live-Test der Lehrperson) Programmumsetzung (anhand Programmdokumentation [siehe S.16] und Code-Review durch Lehrperson) Test und Testdokumentation [siehe S.17] und Test des laufenden Programms durch Lehrperson) 4 Live-Prsentation des Programms, Powerpoint und Projektverlauf Prsentation des eigenen Projekts, live vor der Klasse die Reflexion Arbeitsjournal 50% der Zeugnis note 50% der Zeugnis note 50% der Modul prfungs note

50% der Modul prfungs note

Abzugebende Dokumente und Daten

Die Daten, sowie weitere Hilfsdokumente finden sich unter http://tinyurl.com/m3182013 . Die Abgaben lassen sich aber in folgende Schritte mit zugehrigen Dokumenten gruppieren: 1. Analyse und Konzept (1/2 Note fr das Zeugnis) Datenbank-Schema Wire-Frame, oder gleichwertige Visualisierung der Programmoberflche Prototyp (lauffhig und der Lehrperson demonstrierbar) als Datenbank-Dump mit PHPCode 2. Planung und Dokumentation werden zwei Mal abgegeben, vor der Realisierungsphase und am kurz vor Ende und ergeben zusammen 1/2 Note, jedes Mal werden folgende Dokumente abgegeben (Vorher- / Nachher-Version), also zweimal jedes der folgenden Dokumente: Eigene Anforderungsliste Milestones (mit konkreten Daten) Ihr Arbeitsjournal (bis zu diesem Zeitpunkt)

Wenn jemand nicht mitarbeitet so ist dies im Vorfeld der Lehrperson zu melden. Es kann jedoch auch am Ende eine Notenreduktion fr einzelne Mitglieder vergeben werden, wenn ein begrndeter Verdacht besteht, dass dieses Mitglied sich nicht angemessen beteiligt hat (Aussagen der anderen Gruppenteilnehmer und das Arbeitsjournal sind hier wichtige Hinweise)
Modul 318, Online-Arbeitsjournal 8 / 19

Patrik Marxer

3. Realisation Programmdokumentation Testdokumentation Handbuch 4. Prsentation Powerpoint/Openoffice Prsentation Dokumentation Ihrer Arbeit im Arbeitsjournal (bis zum Schluss) Programm mit Source-Code als virtuelle Maschine, lauffhig mit dynamischer IP ungezippt in einem Ordner als Installations-Paket (Source-Code mit Datenbank-Dump mit Inhalt, getestete Beschreibung wie das Programm in einer neuen LAMP Umgebung zum Laufen gebracht wird) Reflexion (Gruppen- und individuelle Reflexion)

Produkt-Anforderungen
Sie sollen ein Online-Arbeitsjournal realisieren. Die folgenden Anforderungen (und die Benotung) gliedern sich in drei Prioritten: 1. Notwendige Anforderungen: ohne diese ist das Programm nicht funktionsfhig und einsatzfhig fr den gesetzten Zweck als Arbeitsjournal 2. Praktisch sinnvolle Anforderungen: wenn diese Anforderungen nicht erfllt werden, so kann das Programm nur eingeschrnkt verwendet werden - bleibt aber im Grundsatz nutzbar 3. Zustzliche Anforderungen: diese runden die Benutzung des Programms ab (hufige Arbeitsablufe sind fr Benutzer einfach gestaltet, das Programm ist sicher..)

Anforderungsliste
Dies ist eine Vorlage der Anforderungen des Programms, Sie sollen eine eigene Liste erstellen, wo Sie die Eintrge in mglichst kleine Einzelteile unterteilen, fr sich selbst priorisieren, zuteilen und auch Dinge wie Dokumentation, Tests ... als einzelne Eintrge mit Nummer und geschtztem Zeitaufwand eintragen. Dies soll von Ihnen als Google-Dokument (Tabelle) umgesetzt werden. Jeder Eintrag (ToDo) soll eine eindeutige Nummer bekommen, die auch nicht gendert wird, sodass aus dem Arbeitsjournal und anderen Dokumenten auf genau diesen Eintrag/Todo per Nummer referenziert werden kann. Nr. Anforderung / Userstory Prioritt 1 1 1 1

100 Der Zugang zum Programm ist Benutzername/Passwort basiert geschtzt ... .. . Mehrere Benutzer knnen das Programm gleichzeitig bedienen Benutzer knnen inaktiv gesetzt werden, sodass diese sich nicht mehr einloggen knnen, aber intern noch als Benutzer existieren. Es wird zwischen Benutzergruppen/Rollen unterschieden Administratoren (die z.B. neue Lehrer anlegen knnen) Lehrer (die z.B. neue Benutzer und Projekte anlegen knnen usw.) Schler/Benutzer (die nur Eintrge vornehmen knnen)
Modul 318, Online-Arbeitsjournal

Patrik Marxer

9 / 19

Administratoren knnen beliebige neue Lehrer erfassen, beliebige Lehrer / Benutzer / Projekte / Teams / Eintrge verndern oder lschen Lehrer knnen neue Projekte erfassen, Teams aus Schlern bilden und Schler mit Passworten hinzufgen. Sehen aber nur die eigenen Teams und Projekte, nicht die der anderen Lehrer Schler knnen Arbeitsjournaleintrge machen fr sich in ihrem Team und sehen die eigenen und die anderen Eintrge ihres Teams und knnen aber nur die eigenen Eintrge verndern Benutzer/Schler knnen in Gruppen organisiert werden Eine Klasse / Projekt hat beliebig viele Teams Teams mit beliebig vielen Personen, die zum selben Team gehren (es sind damit auch einzel-Arbeiten mglich, wo 1 Team = 1 Benutzer Es lassen sich pro Schler und Arbeitsjournaleintrag eingeben: Datum Uhrzeit (von/bis) der geleisteten Arbeit (daraus wird die geleistete Stundenanzahl berechnet) Kurzzusammenfassung der geleisteten Arbeit fr bersichtsdialoge Langversion der dann ausgefhrten Arbeiten und Probleme ohne Grsseneinschrnkungen Zielerreichung in Prozent seit letztem Eintrag Ziel fr nchsten Eintrag (fr die Zielerreichung) Teambersicht: in der Teambersicht, die auch allen Teammitgliedern offen steht, ist sichtbar: Jede Person des Teams nebeneinander, geordnet nach Datum dabei pro Eintrag einer Person: aktuelles Ziel, Kurzzusammenfassung der geleisteten Arbeit, an diesem Tag geleistete Stunden, Summe der Stunden bis zu diesem Datum Klassenbersicht, die nur der Lehrperson offen steht ist sichtbar: Jedes Team nebeneinander, geordnet nach Datum/Wochen dabei pro Datum: Die Eintrge bilden Summen ber die Arbeitszeit (Gesamtarbeitszeit bisher und diese Woche, letzte x-Wochen..) Es ist pro Team eine bersicht vorhanden mit Hilfe derer zu den jeweiligen detaillierten Eintrgen der Mitglieder gesprungen werden kann die eine Kurzform der Inhalte prsentiert und so einen groben berblick ber die Arbeit des Teams gestattet, sowie den Beitrag der einzelnen Mitglieder Lehrpersonen (und eventuell andere Gruppenteilnehmer) knnen Kommentare / Bewertungen zu Eintrgen hinzufgen, die nur von der Lehrperson verndert werden kann

1 1

1 1

Patrik Marxer

Modul 318, Online-Arbeitsjournal

10 / 19

bersichtstabellen fr konkrete Anwendungszenarien existieren, z.B. tabellarische Ansicht aller Teams, mit geleisteten Stunden und nchsten Zielen aller Personen in nur einem Team - sortiert nach Datum mit Datum, Uhrzeiten (von/bis), Name d. Person, Kurzzusammenfassung des Eintrags und Stunden (aus von/bis berechnet) ... andere sinnvolle bersichtsdialoge Es knnen pro Projekt Einstellungen vorgenommen werden: Arbeitsjournal-Eintrge werden gesperrt nach einer frei einstellbaren Zeit und knnen auch von den Besitzern nicht mehr verndert werden Teams sehen die Eintrge der anderen Teams in einem Projekt oder bersichtsdialoge von anderen Teams (oder nur die eigenen) Pro Kommentar zu einem Journaleintrag, kann bestimmt werden, ob dieser privat ist, oder vom Team mitgelesen werden kann, oder ffentlich ist - also fr die ganze Klasse sichtbar Weitere Filtermglichkeiten von bersichtsdialogen: nach Datum / Wochen nach beliebigen Teams, die miteinander verglichen werden sollen Benutzer knnen aus einer einfachen CSV Textdatei eingelesen werden, die diese auch automatisch zu Gruppen und Projekten/Klassen zuordnet, mit Passwort und allen Notwendigkeiten. So dass der Administrationsaufwand fr ein neues Projekt minimiert wird. Benachrichtigungen fr Teams oder Personen knnen von Lehrern oder Teammitgliedern erfasst werden. Diese wird sichtbar, wenn sich die Person / Team das nchste Mal einlogged Die bersichtstabellen lassen sich filtern nach frei auswhlbaren Teams nach Datumsbereichen Die bersichtseintrge lassen sich sortieren nach Spalten Es existiert eine Excel/Openoffice Vorlage, mit deren Hilfe eine CSV Datei fr ein Projekt erzeugt werden kann - zum Einlesen als Textdatei Die Eintrge bilden weitere Summen ber die Arbeitzeit (Durchschnitt und Vergleich zum Teamdurchschnitt ber alle Teams hinweg) Zu einzelnen Arbeitsjournal-Eintrgen knnen Dokumente angehngt werden, die die Arbeit und deren Fortschritt dokumentieren Ein https Zugang verschlsselt die Verbindung der Benutzer mit dem System bersichtstabellen lassen sich nach mehr als einem Kriterium sortieren (z.B. Team und Datum oder innerhalb eines Teams nach geleisteter Arbeit und dann Datum..) Detail-Eintrge in Arbeitsjournalen knnen formatiert werden (in HTML) Grafische Darstellung (Balken- Kuchendiagramm) geleisteter Arbeit pro Person pro Gruppe (also aller Gruppenteilnehmer im Team) Teams im Vergleich

3 3 3 3 3 3 3 3

Patrik Marxer

Modul 318, Online-Arbeitsjournal

11 / 19

Export als Tabelle (CSV) aller Mitglieder eines Teams (Datumssortiert, mit Stundenangaben und Summen)

Patrik Marxer

Modul 318, Online-Arbeitsjournal

12 / 19

Tipps
Mit diesem Projekt werden Sie erfahren, dass Sie auch Aufgaben mit vielen Unbekannten lsen knnen, wenn Sie strukturiert und (auf bekannte Elemente aufbauend) schrittweise vorgehen. Die Aufgabenstellung (Anforderungsliste) ist gleichzeitig auch Teil des Korrekturschemas. Fehlende Elemente gehen deshalb in die Bewertung ein, unabhngig wie gut das Endprodukt ist. berlegen Sie sich immer, ob ihre Wunschlsung auch in der zur Verfgung stehenden Zeit machbar ist. Ideal sind Lsungskonzepte, die bei Bedarf erweitert oder abgespeckt werden knnen. In jedem Projekt kommt der Endtermin schneller als man denkt, auch wenn man sich in der Planung Mhe gibt. Versuchen sie immer, sich einen berblick ber die noch zu erledigenden Arbeiten zu verschaffen. Denken Sie daran, dass die Arbeit erst erledigt ist, wenn die Dokumentation dazu auch fertig ist. Sie arbeiten in einem Team: Sprechen Sie sich immer wieder ab: wer, was, wie und bis wann machen wird. Organisieren Sie sich so, dass Sie die Arbeiten unabhngig voneinander, zeitlich parallel machen knnen. Bringen Sie ihre Unterlagen zum Ende der Schulstunden wieder auf den aktuellen Stand und besprechen Sie das weitere Vorgehen bis zum Beginn der nchsten Schulwoche miteinander. Projektplanung und Arbeitsjournal sind die Arbeitsmittel dazu.

Patrik Marxer

Modul 318, Online-Arbeitsjournal

13 / 19

Anhang, Beschreibung der Dokumente, Beispiele

Arbeitsjournal
Da Sie ja ein Online-Arbeitsjournal programmieren, dies aber bis zur Fertigstellung noch nicht konkret nutzbar sein wird, sollen Sie ein Google-Tabellendokument erstellen und dem Lehrer LeseRechte dazu einrumen. In jeder Schulstunde sollte als erstes das Arbeitsjournal auf den neuesten Stand gebracht werden. Die Lehrperson kann zu beliebigen Zeiten das Arbeitsjournal einfordern, Sie mssen es dann vorweisen knnen und die Lehrperson bewertet es nach Vollstndigkeit, Ausfhrlichkeit, Detailgenauigkeit und Wahrscheinlichkeit/Echtheit. Es soll mindestens folgende Kategorien/Einteilungen erlauben: Name der Person, die den Eintrag macht Datum, des Eintrags Anzahl geleisteter Stunden Kurze Zusammenfassung der ausgefhrten Arbeit Platz fr ausfhrliche Beschreibung der ausgefhrten Arbeit Nummer der ausgefhrten Arbeit in der eigenen Anforderungsliste Ziel oder Milestone zu dem die ausgefhrte Arbeit gehrt

Es sollen ausserdem immer aktuelle Summen der geleisteten Stunden jeder Person und des Teams ganz oben im Dokument ersichtlich sein.

Beispiel
Datum Arbeitszeit Person Zusammenfassung Tasks Detailbeschreibung 2.3.2013 1.5h Peter Muster Arbeit an Benutzerverwaltung, Milestone 1 102, 108, 109 Bei der Benutzerverwaltung kann man nun einen Benutzer anlegen und wieder lschen. Die Tasks 102, 108 wurden erledigt und knnen getestet werden. Das Editieren klappt noch nicht ganz (Taks 109): die Editier-Buttons fhren noch nicht zu einem Update des Eintrags in der Datenbank Task 109 fertigstellen und damit den Milestone 1 dem Test bergeben

nchstes Ziel

Eigene Anforderungsliste
Schauen Sie sich dazu die Anforderungsliste auf Seite 9 an. Erstellen Sie daraus ein eigenes Dokument (Google-Tabellen-Doc).
Patrik Marxer Modul 318, Online-Arbeitsjournal 14 / 19

Die Anforderungsliste ist ein Dokument, das der Kunde verfasst hat - aus seiner Sicht. Sie als Programmierer und Tester erstellen nun ein eigenes Dokument, wo Sie genauer festlegen, was gemacht werden muss.

Beispiel
Zum Beispiel, aus dem Punkt "Benutzername/Passwort basiert einloggen" machen Sie so etwas wie: Nr 101 102 103 Task Eine globale Funktion bauen: is_logged_in(), die berprft, ob der Benutzer eingeloggt ist. Die Funktion gibt true/false zurck Die Funktion is_logged_in() in die bestehenden 3 PHP Seiten einbauen. Wenn der Benutzer nicht eingeloggt ist, so wird er umgeleitet zur Seite login.php Eine globale Funktion bauen: get_user_right(), die berprft, welche RechteStufe ein Benutzer hat. Die Funktion gibt 1-3 zurck (1: Schler, 2: Lehrer, 3: Admin) Auf der Benutzer-Editieren Seite (user_edit.php) wird die Berechtigung des Benutzers geprft: wenn der Benutzer keine Admin-Rechte hat, so wird er zu main.php umgeleitet Prio 1 2 3

104

Konkret heisst das also Nehmen Sie die vorgegebene Anforderungsliste/Userstory und Sie formulieren die Anforderungen genauer aus Programmierer- und Testersicht, sodass der Lsungsweg klar wird Setzen Sie sich mit dem Problem auseinander, und wie sie es lsen knnten (welche Seiten mssen angepasst werden, welche Funktionen hinzugefgt, welche Variablen..) Priorisieren Sie das Todo (1-n) Vergessen Sie auch die anderen Todos nicht, wie Test, Dokumentation...

Vergeben Sie fr jeden Eintrag (ToDo) eine eindeutige Nummer, die auch nicht mehr gendert wird.

Milestones
Ein Milestone (Meilenstein) ist ein konkreter Teil des Programms, das messbar, sichtbar fertiggestellt wurde. Zum Beispiel: "Benutzerverwaltung funktioniert". Alle zwei/drei Wochen ist ein Milestone fllig. Teilen Sie die Eigene Anforderungsliste in zusammengehrende, unabhngie Bereiche/Milestones auf, Milestones sollten dem Benutzer demonstrierbar neue Funktionalitt zeigen (Sie knnen den neuen Teil des Programms der Lehrperson/anderen Teams zeigen und beschreiben) sie sind testbar und wurden anhand der Test-Checkliste getestet (siehe Testdokumentation) Ein Milestone ist mit konkretem Datum versehen. Schtzen Sie den erwarteten Zeitaufwand fr jeden Milestone und planen Sie konkrete Daten, an denen die Milestones erledigt sein
Modul 318, Online-Arbeitsjournal 15 / 19

Patrik Marxer

sollen. Verteilen Sie die Arbeiten auf die Gruppenmitglieder, stellen Sie sicher, dass jede Person weiss, was sie konkret zu tun hat und diese Arbeit auch unabhngig erledigen kann. Niemand ist also je unttig. Haken Sie die Anforderungen (ToDos) nach und nach als erledigt ab, wenn sie ausprogrammiert/erledigt sind.

Beispiel
Zum Beispiel knnten Milestones so aussehen: Datum 4.2.2013 Milestone ToDos Benutzerverwaltung funktioniert grundstzlich. Jeder Benutzer 101, 102, 104, bekommt eine passende Login-Seite. Benutzer knnen angelegt 105, 131, 141 werden, gendert und gelscht. Das HTML-Layout und CSS fr die Seite stehen grundstzlich fest. Benutzer knnen einen einfachen Arbeitsjournaleintrag anlegen, den die anderen Teammitglieder auch sehen 133, 134, 141

18.2.2013 4.3.2013

Der bersichtsdialog des Teams ist fertig. Alle Arbeitsjournal201, 203, 222, eintrge der Mitglieder werden nebeneinander dargestellt, mit 109, 151, 172 Summen der geleisteten Stunden und Kurzzusammenfassung (nicht Detaileintrgen) ... alle Eintrge der Prioritt 1 aus der Anforderungsliste wurden erledigt und sind als Gesamtes benutzbar ... ...

... 20.4.

Programmdokumentation
Die Dokumentation Ihres Programms besteht aus zwei Dingen: einem Textdokument (der Programmdokumentation mit berlegungen, Beispiele vorher/nachher mit konkretem Beispiel-Code aus dem Projekt) den Kommentaren im Source-Code selbst

Sie geben am Schluss beides ab, die Programmdokumentation (Textdokument) zusammen mit dem Source-Code des Programms. Generell gilt fr die Benotung als um so besser wenn... 1. ein schlechter Programmbereich von Ihnen identifiziert wurde (statt erst bei der Benotung durch die Lehrperson) 2. ein Verbesserungsvorschlag wurde gemacht, aber noch nicht umgesetzt (Eintrag als ToDo) 3. der Verbesserungsvorschlag wurde umgesetzt (erledigtes ToDo, neues ToDo: Testen) 4. und das Programm wieder getestet wurde (Eintrag der nderung und dessen Test im Testdokument) Notieren Sie alle diese berlegungen in der Programmdokumentation kurz, sodass die Lehrperson dies nachvollziehen kann - mit Code-Beispielen und Lsungen. Am Schluss berarbeiten Sie das Dokument und geben Empfehlungen ab, als wie gut Sie das
Patrik Marxer Modul 318, Online-Arbeitsjournal 16 / 19

Programm und einzelne Teile einstufen, was verbessert werden kann und wann Sie das gemacht haben oder warum nicht. Fgen Sie hier auch am Ende ein aktuelles Datenbankmodell mit kurzer Beschreibung hinzu.

Beispiel: Code-Smells
Folgendes sind einige Merkmale von schlecht umgesetzten Programmen (siehe Code-Smells) und soll Ihnen helfen bei der Dokumentation des Programms und der Identifikation von Problemen. Die Liste ist nicht vollstndig und kann es auch nicht sein. Finden Sie Dinge, die Sie an Ihrem Code stren, erklren Sie, warum dies strend ist, und was Sie dagegen tun knnten. Code, der sich wiederholt (dupliziert oder in leicht unterschiedlichen Varianten, die etwas hnliches tun) - dies sollte sinnvollerweise in gemeinsamen Funktionen umgesetzt werden Lange Methoden. Wenn eine Funktion versucht zu viel auf einmal zu tun. Spalten Sie die Funktion in mglichst unabhngige Teile auf, mit klaren Parametern und Rckgabewerten Lange Parameterlisten an Funktionen. Versuchen Sie nur das Ntigste zu bergeben. Globale Variablen. Diese sind mglichst ganz zu vermeiden. Aussagekrftige Funktionsnamen Kommentare fehlen im Programm. Das Programm sollte intuitiv verstndlich sein fr jeden, der minimale PHP-Kenntnisse besitzt (auf der anderen Seite, wenn sie zu viel an einer Funktion dokumentieren mssen, so ist sie vielleicht zu kompliziert und knnte vereinfacht werden)

Testdokumentation
Die Testdokumentation besteht aus mindestens zwei Dokumenten. Einer bersicht ber alle gemachten Tests und einer Checkliste (mit nummerierten Eintrgen fr jeden Test). Dokumentieren Sie, wann Sie was geprft haben, wie Ihr Programm reagiert hat und was fr ToDos oder Konsequenzen daraus resultierten ber den gesamten Projektverlauf in der bersicht. Bauen Sie hier ruhig auch Verbesserungsvorschlge ein. Zum Beispiel aus Benutzersicht (z.B. "Beim Erfassen eines Journaleintrags knnten Datum und Uhrzeit mit dem aktuellen Datum vorausgefllt werden, so spart sich der Benutzer in den meisten Fllen Zeit") und besprechen Sie dies mit dem Programmierer. Danach fgen Sie einen Eintrag in die Eigene Anforderungsliste mit neuer Nummer ein. Diese Testdokumentation (Testbersicht und Checkliste) wird am Schluss abgegeben und wird benotet.

Beispiel: Vorschlge fr die Checkliste

Diese Liste ist nur ein Vorschlag, um daraus Ihre Checkliste zu erstellen. Finden Sie weitere Testflle und -mglichkeiten. Geben Sie in Felder etwas ein, was viel zu lang ist Fgen Sie spezielle Characters ein wie: *?\/<>();"'#%... die eine Bedeutung beim Programmieren haben. Probieren Sie auch andere spezielle Characters wie ..

Patrik Marxer

Modul 318, Online-Arbeitsjournal

17 / 19

Lassen Sie Felder leer, die ausgefllt werden mssen Unsinnige Daten: geben Sie falsche oder unsinnige Daten in Datumsfelder ein riesige/negative Zahlen in Zahlenfelder Generell: spielen Sie Hacker und versuchen Sie das Programm zu sabotieren (Javascript in HTML-Eingabefelder, HTML einbauen in Felder, wo das nicht gedacht war) Fgen Sie Dinge zusammen, die nicht zusammen gehren (Teams mit 0 Mitgliedern, Teams mit allen Personen) - prfen Sie wie sich die bersichtdialoge verhalten

Bsartiges Umgehen mit dem Programm Schliessen Sie mittendrin den Browser, whren sie zusammengehrende Daten eingeben Schalten Sie Apache/MySQL aus, whrend jemand Daten eingibt Lschen Sie Benutzer, die Eintrge haben. Lschen Sie Teams, die am Arbeiten sind und Arbeitsjournaleintrge haben - wird hier nachgefragt vor dem Lschen, ob wirklich alles gelscht werden soll? Loggen Sie sich zweimal ein (auch als unterschiedliche Nutzer) und lschen einen Benutzer, an dem sie im zweiten Fenster gerade etwas editieren

Testen Sie verschiedene Filter und Sortierungen in bersichtsdialogen Springen Sie wild zwischen nicht zusammengehrenden Teilen des Programms hin und her

Handbuch
Schreiben Sie ein Handbuch zu Ihrem Programm. Orientieren Sie sich am gelieferten Beispiel und anderen Ihnen bekannten Handbchern. Das Handbuch sollte 10-20 Seiten umfassen und mit Screenshots und klaren Beispielen fr Nichtinformatiker, also die Benutzer Ihres Programms verstndlich sein.

Reflexion
Die Reflexion besteht aus zwei Teilen, einem Gruppenteil und einem individuellen Teil.

Gruppenteil
Der Gruppenteil, in dem Sie gemeinsam Ihre Zusammenarbeit beurteilen (2-3 Seiten): Wer, warum welche Rolle und Aufgaben bernahm, warum diese Milestones und diese Daten gewhlt wurden. Geben Sie eine schriftliche Beurteilung ab, indem Sie unter anderem die beiden Versionen der Programmdokumentation vergleichen, also die Vorher-/Nachher-Versionen der Milestones und der eigenen Anforderungsliste). Wenn Daten verschoben wurden, dann erklren Sie hier unbedingt warum. Sie formulieren Verbesserungsvorschlge (Effizienzsteigerung: Planung/Arbeit/Zeit, Leerlufe..) und was Sie daraus lernen und nchstes Mal besser machen werden. Denn Sie werden noch mehrere grssere Projekte in der Schule verwirklichen mssen
Modul 318, Online-Arbeitsjournal 18 / 19

Patrik Marxer

Individueller Teil
Im individuellen Teil, den Sie auch nicht den anderen Gruppenmitgliedern zeigen sollen2, dokumentiert jede Person fr sich die gelernten Erfahrungen (1 Seite). Den eigenen Umgang in der Gruppe, Arbeitshaltung und Effizienz, Ihre Strken und Schwchen und wie Sie im Projekt mitgearbeitet haben (Selbstbeurteilung). Sie beurteilen dieselben Kriterien auch bei dem/den anderen Gruppenmitgliedern (Fremdbeurteilung). Sie beurteilen die Ntzlichkeit des Moduls, den Arbeitsauftrag durch die Lehrperson, den Ablauf des Moduls und bringen Verbesserungsvorschlge an. Was htte durch die Lehrperson besser/genauer formuliert werden knnen, wo wre ein Theorieteil zur Repetition sinnvoll gewesen usw.

Dieser Teil wird, wie gesagt, nur von der Lehrperson gelesen, nicht von den anderen Gruppenmitgliedern, also versuchen Sie ehrlich und fair zu sein in Ihrer Beurteilung.

Die getrennte Abgabe soll nur dazu dienen eine ehrlichere eigene Sichtweise beschreiben zu knnen. Sie ist kein Dokument um den anderen anzuschwrzen oder schlecht zu machen.
Modul 318, Online-Arbeitsjournal 19 / 19

Patrik Marxer