Moduldokumentation M318 (Arbeitsjournal)

M318 Moduldokumentation

Projekt

Online Arbeitsjournal

Autor: Patrik Marxer

Datum: Dezember 2012, Januar 2013

InhaltsverzeichnisInhaltsverzeichnis.................................................................................................................................2Modul 318, Kompetenzen und Handlungsziele ..................................................................................3Einführung / Übersicht.........................................................................................................................4

Einführung ......................................................................................................................................4Ziel...................................................................................................................................................4Lizenzen und Quellenangaben.........................................................................................................4

Ablauf in Kurzform und Benotung.......................................................................................................6Vorbereitungsarbeiten......................................................................................................................61. Analyse und Konzept...................................................................................................................62. Planung........................................................................................................................................63. Umsetzung...................................................................................................................................64. Präsentation und Reflexion..........................................................................................................7

Benotung...............................................................................................................................................8Abzugebende Dokumente und Daten..............................................................................................8

Produkt-Anforderungen........................................................................................................................9Anforderungsliste.............................................................................................................................9

Tipps...................................................................................................................................................13Anhang, Beschreibung der Dokumente, Beispiele.............................................................................14

Arbeitsjournal................................................................................................................................14Beispiel......................................................................................................................................14

Eigene Anforderungsliste...............................................................................................................14Beispiel......................................................................................................................................15

Milestones......................................................................................................................................15Beispiel......................................................................................................................................16

Programmdokumentation...............................................................................................................16Beispiel: Code-Smells...............................................................................................................17

Testdokumentation.........................................................................................................................17Beispiel: Vorschläge für die Checkliste....................................................................................17

Handbuch.......................................................................................................................................18Reflexion........................................................................................................................................18

Gruppenteil................................................................................................................................18Individueller Teil.......................................................................................................................19

Patrik Marxer Modul 318, Online-Arbeitsjournal 2 / 19

Modul 318, Kompetenzen und Handlungsziele (Quelle I-CH)Modulnummer 318

Titel Analysieren und objektbasiert programmieren mit Komponenten

Kompetenz Eine Aufgabe analysieren, mit einer auf RAD-Technologie (Rapid Application Development) basierenden Programmiersprache mit strukturierten und objektbasierten Methoden implementieren, dokumentieren und testen.

Handlungsziele 1. Problemstellung analysieren, Benutzerschnittstelle entwerfen und Abläufe mit strukturierten Methoden darstellen.

2. Grafische Benutzerschnittstelle gestalten und realisieren.

3. Erarbeitete Programmvorgabe mit einer objektbasierten ereignisorientierten Programmiersprache mit Einsatz von Ablaufstrukturelementen, eigenen Prozeduren und Funktionen implementieren.

4. Beim Programmieren vorgegebene Codekonventionen einhalten, das Programm in Line dokumentieren und dabei auf Wartbarkeit und Nachvollziehbarkeit achten.

5. Ausgehend von der Aufgabenstellung Testfälle erstellen, das Programm testen und Fehler beheben.


Einführung / Übersicht

Einführung Spätestens am Ende der Lehre müssen Sie im Rahmen der Individuellen Prüfungsarbeit (IPA) ein Projekt mit einem Umfang von 80 bis 120 Stunden Arbeitszeit selber planen und fachgerecht durchzuführen können. Erfahrungen mit IPA Arbeiten haben gezeigt, dass die Phasen Analyse und Konzeption, sowie die Dokumentation mit Führen des Arbeitsjournals, Projektplanung und fortlaufende Beschreibung des Projektfortschrittes immer wieder zu Schwierigkeiten geführt haben, weil es in der beruflichen Praxis und in der Schule zu wenig geübt wurde. Dieser Umstand wird in diesem Modul berücksichtigt.

Ein Projekt ist definiert durch Starttermin, Endtermin und einer Aufgabenstellung mit unbekanntem Lösungsweg. Wie bei der IPA werden Sie im Modul 318 mit diesem Projekt eine Aufgabenstellung mit einem unbekannten, neuartigen Anteil lösen. Es ist voraussichtlich das erste komplexere Projekt, welches Sie in einem Team selbstständig lösen können. Deshalb ist die Aufgabenstellung in Vorgehensschritten so aufgebaut, dass Sie beim Lösen in die richtige Richtung für die Problemlösung geführt werden. (In späteren Projekten wird auch das Finden der richtigen Vorgehensschritte Teil der Aufgabenstellung sein).

ZielSie 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 für Sie, dies ist Ihre Aufgabe als auftragnehmende Firma. Er hilft bei kundenspezifischen Problemen, um festzustellen, was überhaupt gewünscht wird und bei wichtigen Entscheidungen (DB-Design, Arbeitsabläufe usw.)

Das Projekt soll mit einem LAMP-Stack (Linux, MySQL, Apache und PHP) umgesetzt werden.

Lizenzen und QuellenangabenSie nennen alle Quellen, die Sie für die Programmumsetzung heranziehen. Das beinhaltet nicht-trivialen Code aus dem Internet, Bibliotheken, Bücher (mit Kapitel und Seitenangaben) und Personen, die Sie unterstützen.

Verbindlichkeit

• Sie unterschreiben am Schluss ebenfalls eine Vereinbarung über die Selbstständigkeit der Arbeit und Vollständigkeit der Quellenangaben.

• Sie unterschreiben auch eine Vereinbarung, den Code unter die folgenden Lizenzen zu stellen.


Das Projekt untersteht diesen zwei Lizenzen, damit eine Weiterentwicklung durch andere Klassen ohne Probleme möglich ist.

Source-Code

Der Source-Code des Programms muss unter die GPL 2.0 oder höher gestellt werden, um nachfolgende Weiterentwicklungen des Programms (z.B. eines darauf folgenden Kurses) zu erlauben.

Dokumentation

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 Verfügung gestellt werden. Ausserdem muss Ihr Name als Urheber im Dokument erhalten bleiben.


http://creativecommons.org/licenses/by-sa/3.0/legalcode

http://de.wikipedia.org/wiki/Creative_Commons

http://de.wikipedia.org/wiki/Gpl

Ablauf in Kurzform und BenotungDies ist eine Gruppenarbeit. Die Gruppengrösse ist normalerweise 2 Personen, es können in begründeten Fällen andere Gruppengrössen gebildet werden. Bei mehr Personen kann die Anforderung für die Gruppe entsprechend erhöht werden, da mehr Personen mitarbeiten.

Vorbereitungsarbeiten• Erstellen Sie ein Google-Tabellendokument für 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 für die Lehrperson.

• Machen Sie Skizzen: Oberflächen-Design und Abläufe (auf Papier oder als Wire-Frame)

• Schauen Sie sich eventuell nach Konkurrenzprodukten um, informieren Sie sich über Arbeitsabläufe und Features dieser Produkte. Welche können Sie für Ihr Produkt nutzen?

1. Analyse und KonzeptSie 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 Primär-/Fremdschlüsseln in grafischer Form (Programmvorschlag: MySQL Workbench)

◦ Wire-Frame Abbilder der Oberflächen des Programms (Programmvorschlag: Firefox-Extension Pencil)

◦ ein Quick-and-Dirty programmierter zentraler Teil des Programms (Sie müssen keinerlei Code-Konventionen einhalten, es soll nicht schön aussehen - dieser Teil dient nur dazu Ihnen eine Vorstellung des noch zu leistenden Arbeitsaufwandes zu vermitteln)

2. PlanungDie Planung beinhaltet eine Vorher- und eine Nachher-Version der folgenden Dokumente

• Eigene Anforderungsliste (Google-Tabellen-Dokument)

• Sie definieren Milestones

◦ mit konkret definierten Zielen, welche zusammengehörenden Teile fertig sein sollen (mit Nummern aus der Anforderungsliste)

◦ mit konkreten Daten, wann es fertig sein soll. Lassen Sie grosszügig Platz - es dauert fast alles länger als geplant

3. UmsetzungDen programmierten Prototypen können 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


http://pencil.evolus.vn/

http://dev.mysql.com/downloads/workbench/

die Milestones. Eine Abweichung im Datum oder Ablauf ist immer begründet und wird vermerkt.

• Notenrelevante Kriterien

◦ Benutzbarkeit: Nutzen Sie Ihr Produkt möglichst 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, unübersichtlicher 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 abstürzt, stecken bleibt oder Eingaben akzeptiert, die keinen Sinn ergeben. Dokumentieren Sie die Tests und deren Ergebnisse (siehe Seite 17: Testdokumentation)

4. Präsentation und ReflexionPräsentation

Präsentieren Sie Ihr Programm vor dem Kunden, also der Lehrperson, aber auch den anderen Klassenmitgliedern.

Gestalten Sie dies wie eine Verkaufspräsentation. Es soll möglichst 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 persönliche Reflexion über den Ablauf des Projekts: Teamarbeit und Umgang miteinander, Arbeitsaufteilung, Höhepunkte und Tiefpunkte/Ärger, Zufriedenheit über das Erreichte, Verbesserungsvorschläge für die Zukunft...


BenotungDiese Arbeit wird mit einer Semsternote und einer Modulnote bewertet. Die Noten gelten für alle Gruppenteilnehmer1. Zur Benotung werden die Dokumente für die Vertiefungsarbeit (VA) und die Individuellen Produktivarbeit herangezogen

1 Analyse und Konzept• Datenbank-Schema • Wire-Frame, oder gleichwertige Visualisierung • Prototyp (lauffähig)

50% der Zeugnis note

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)

50% der Zeugnis note

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)

50% der Modul prüfungsnote

4 Live-Präsentation des Programms, Powerpoint und Projektverlauf • Präsentation des eigenen Projekts, live vor der Klasse• die Reflexion• Arbeitsjournal

50% der Modul prüfungsnote

Abzugebende Dokumente und DatenDie Daten, sowie weitere Hilfsdokumente finden sich unter http://tinyurl.com/m3182013 . Die Abgaben lassen sich aber in folgende Schritte mit zugehörigen Dokumenten gruppieren:

1. Analyse und Konzept (1/2 Note für das Zeugnis)

◦ Datenbank-Schema ◦ Wire-Frame, oder gleichwertige Visualisierung der Programmoberfläche◦ Prototyp (lauffähig und der Lehrperson demonstrierbar) als Datenbank-Dump mit PHP-

Code

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)

1 Wenn jemand nicht mitarbeitet so ist dies im Vorfeld der Lehrperson zu melden. Es kann jedoch auch am Ende eine Notenreduktion für einzelne Mitglieder vergeben werden, wenn ein begründeter Verdacht besteht, dass dieses Mitglied sich nicht angemessen beteiligt hat (Aussagen der anderen Gruppenteilnehmer und das Arbeitsjournal sind hier wichtige Hinweise)


http://tinyurl.com/m318-2013

3. Realisation◦ Programmdokumentation◦ Testdokumentation◦ Handbuch

4. Präsentation◦ Powerpoint/Openoffice Präsentation◦ Dokumentation Ihrer Arbeit im Arbeitsjournal (bis zum Schluss)◦ Programm mit Source-Code

▪ als virtuelle Maschine, lauffähig 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-AnforderungenSie sollen ein Online-Arbeitsjournal realisieren. Die folgenden Anforderungen (und die Benotung) gliedern sich in drei Prioritäten:

1. Notwendige Anforderungen: ohne diese ist das Programm nicht funktionsfähig und einsatzfähig für den gesetzten Zweck als Arbeitsjournal

2. Praktisch sinnvolle Anforderungen: wenn diese Anforderungen nicht erfüllt werden, so kann das Programm nur eingeschränkt verwendet werden - bleibt aber im Grundsatz nutzbar

3. Zusätzliche Anforderungen: diese runden die Benutzung des Programms ab (häufige Arbeitsabläufe sind für Benutzer einfach gestaltet, das Programm ist sicher..)

AnforderungslisteDies ist eine Vorlage der Anforderungen des Programms, Sie sollen eine eigene Liste erstellen, wo Sie die Einträge in möglichst kleine Einzelteile unterteilen, für sich selbst priorisieren, zuteilen und auch Dinge wie Dokumentation, Tests ... als einzelne Einträge mit Nummer und geschätztem Zeitaufwand eintragen.

Dies soll von Ihnen als Google-Dokument (Tabelle) umgesetzt werden. Jeder Eintrag (ToDo) soll eine eindeutige Nummer bekommen, die auch nicht geändert wird, sodass aus dem Arbeitsjournal und anderen Dokumenten auf genau diesen Eintrag/Todo per Nummer referenziert werden kann.

Nr. Anforderung / Userstory Prio-rität

100 Der Zugang zum Programm ist Benutzername/Passwort basiert geschützt 1

... Mehrere Benutzer können das Programm gleichzeitig bedienen 1

.. Benutzer können inaktiv gesetzt werden, sodass diese sich nicht mehr einloggen können, aber intern noch als Benutzer existieren.

1

. Es wird zwischen Benutzergruppen/Rollen unterschieden• Administratoren (die z.B. neue Lehrer anlegen können)• Lehrer (die z.B. neue Benutzer und Projekte anlegen können usw.)• Schüler/Benutzer (die nur Einträge vornehmen können)

1


Administratoren können beliebige neue Lehrer erfassen, beliebige Lehrer / Benutzer / Projekte / Teams / Einträge verändern oder löschen

1

Lehrer können neue Projekte erfassen, Teams aus Schülern bilden und Schüler mit Passworten hinzufügen. Sehen aber nur die eigenen Teams und Projekte, nicht die der anderen Lehrer

1

Schüler können Arbeitsjournaleinträge machen für sich in ihrem Team und sehen die eigenen und die anderen Einträge ihres Teams und können aber nur die eigenen Einträge verändern

1

Benutzer/Schüler können in Gruppen organisiert werden• Eine Klasse / Projekt hat beliebig viele Teams• Teams mit beliebig vielen Personen, die zum selben Team gehören (es sind

damit auch einzel-Arbeiten möglich, wo 1 Team = 1 Benutzer

1

Es lassen sich pro Schüler und Arbeitsjournaleintrag eingeben:• Datum• Uhrzeit (von/bis) der geleisteten Arbeit (daraus wird die geleistete

Stundenanzahl berechnet)• Kurzzusammenfassung der geleisteten Arbeit für Übersichtsdialoge• Langversion der dann ausgeführten Arbeiten und Probleme ohne

Grösseneinschränkungen• Zielerreichung in Prozent seit letztem Eintrag• Ziel für nächsten Eintrag (für die Zielerreichung)

1

Teamübersicht: in der Teamübersicht, 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

1

Klassenübersicht, die nur der Lehrperson offen steht ist sichtbar:• Jedes Team nebeneinander, geordnet nach Datum/Wochen• dabei pro Datum:

2

Die Einträge bilden Summen über die Arbeitszeit (Gesamtarbeitszeit bisher und diese Woche, letzte x-Wochen..)

1

Es ist pro Team eine Übersicht vorhanden• mit Hilfe derer zu den jeweiligen detaillierten Einträgen der Mitglieder

gesprungen werden kann• die eine Kurzform der Inhalte präsentiert und so einen groben Überblick

über die Arbeit des Teams gestattet, sowie den Beitrag der einzelnen Mitglieder

1

Lehrpersonen (und eventuell andere Gruppenteilnehmer) können Kommentare / Bewertungen zu Einträgen hinzufügen, die nur von der Lehrperson verändert werden kann

2


Übersichtstabellen für konkrete Anwendungszenarien existieren, z.B. • tabellarische Ansicht aller Teams, mit geleisteten Stunden und nächsten

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

2

Es können pro Projekt Einstellungen vorgenommen werden:• Arbeitsjournal-Einträge werden gesperrt nach einer frei einstellbaren Zeit

und können auch von den Besitzern nicht mehr verändert werden• Teams sehen die Einträge 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 für die ganze Klasse sichtbar

2

Weitere Filtermöglichkeiten von Übersichtsdialogen:• nach Datum / Wochen• nach beliebigen Teams, die miteinander verglichen werden sollen

2

Benutzer können 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 für ein neues Projekt minimiert wird.

2

Benachrichtigungen für Teams oder Personen können von Lehrern oder Teammitgliedern erfasst werden. Diese wird sichtbar, wenn sich die Person / Team das nächste Mal einlogged

3

Die Übersichtstabellen lassen sich filtern• nach frei auswählbaren Teams• nach Datumsbereichen

3

Die Übersichtseinträge lassen sich sortieren nach Spalten 3

Es existiert eine Excel/Openoffice Vorlage, mit deren Hilfe eine CSV Datei für ein Projekt erzeugt werden kann - zum Einlesen als Textdatei

3

Die Einträge bilden weitere Summen über die Arbeitzeit (Durchschnitt und Vergleich zum Teamdurchschnitt über alle Teams hinweg)

3

Zu einzelnen Arbeitsjournal-Einträgen können Dokumente angehängt werden, die die Arbeit und deren Fortschritt dokumentieren

3

Ein https Zugang verschlüsselt die Verbindung der Benutzer mit dem System 3

Übersichtstabellen lassen sich nach mehr als einem Kriterium sortieren (z.B. Team und Datum oder innerhalb eines Teams nach geleisteter Arbeit und dann Datum..)

3

Detail-Einträge in Arbeitsjournalen können formatiert werden (in HTML) 3

Grafische Darstellung (Balken- Kuchendiagramm)• geleisteter Arbeit pro Person• pro Gruppe (also aller Gruppenteilnehmer im Team)• Teams im Vergleich

3


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

3


Tipps• Mit diesem Projekt werden Sie erfahren, dass Sie auch Aufgaben mit vielen Unbekannten

lösen können, 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, unabhängig wie gut das Endprodukt ist.

• Überlegen Sie sich immer, ob ihre Wunschlösung auch in der zur Verfügung stehenden Zeit machbar ist. Ideal sind Lösungskonzepte, die bei Bedarf erweitert oder abgespeckt werden können.

• In jedem Projekt kommt der Endtermin schneller als man denkt, auch wenn man sich in der Planung Mühe 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 unabhängig voneinander, zeitlich parallel machen können.

◦ Bringen Sie ihre Unterlagen zum Ende der Schulstunden wieder auf den aktuellen Stand und besprechen Sie das weitere Vorgehen bis zum Beginn der nächsten Schulwoche miteinander.

◦ Projektplanung und Arbeitsjournal sind die Arbeitsmittel dazu.


Anhang, Beschreibung der Dokumente, Beispiele

ArbeitsjournalDa 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 Lese-Rechte dazu einräumen.

In jeder Schulstunde sollte als erstes das Arbeitsjournal auf den neuesten Stand gebracht werden. Die Lehrperson kann zu beliebigen Zeiten das Arbeitsjournal einfordern, Sie müssen es dann vorweisen können und die Lehrperson bewertet es nach Vollständigkeit, Ausführlichkeit, 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 ausgeführten Arbeit

• Platz für ausführliche Beschreibung der ausgeführten Arbeit

• Nummer der ausgeführten Arbeit in der eigenen Anforderungsliste

• Ziel oder Milestone zu dem die ausgeführte Arbeit gehört

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

BeispielDatum 2.3.2013

Arbeitszeit 1.5h

Person Peter Muster

Zusammenfassung Arbeit an Benutzerverwaltung, Milestone 1

Tasks 102, 108, 109

Detailbeschreibung Bei der Benutzerverwaltung kann man nun einen Benutzer anlegen und wieder löschen. Die Tasks 102, 108 wurden erledigt und können getestet werden.Das Editieren klappt noch nicht ganz (Taks 109): die Editier-Buttons führen noch nicht zu einem Update des Eintrags in der Datenbank

nächstes Ziel Task 109 fertigstellen und damit den Milestone 1 dem Test übergeben

Eigene AnforderungslisteSchauen Sie sich dazu die Anforderungsliste auf Seite 9 an. Erstellen Sie daraus ein eigenes Dokument (Google-Tabellen-Doc).


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.

BeispielZum Beispiel, aus dem Punkt "Benutzername/Passwort basiert einloggen" machen Sie so etwas wie:

Nr Task Prio

101 Eine globale Funktion bauen: is_logged_in(), die überprüft, ob der Benutzer eingeloggt ist. Die Funktion gibt true/false zurück

1

102 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

2

103 Eine globale Funktion bauen: get_user_right(), die überprüft, welche Rechte-Stufe ein Benutzer hat. Die Funktion gibt 1-3 zurück (1: Schüler, 2: Lehrer, 3: Admin)

3

104 Auf der Benutzer-Editieren Seite (user_edit.php) wird die Berechtigung des Benutzers geprüft: wenn der Benutzer keine Admin-Rechte hat, so wird er zu main.php umgeleitet

4

Konkret heisst das also

• Nehmen Sie die vorgegebene Anforderungsliste/Userstory und Sie formulieren die Anforderungen genauer aus Programmierer- und Testersicht, sodass der Lösungsweg klar wird

• Setzen Sie sich mit dem Problem auseinander, und wie sie es lösen könnten (welche Seiten müssen angepasst werden, welche Funktionen hinzugefügt, welche Variablen..)

• Priorisieren Sie das Todo (1-n)

• Vergessen Sie auch die anderen Todos nicht, wie Test, Dokumentation...

Vergeben Sie für jeden Eintrag (ToDo) eine eindeutige Nummer, die auch nicht mehr geändert wird.

MilestonesEin Milestone (Meilenstein) ist ein konkreter Teil des Programms, das messbar, sichtbar fertiggestellt wurde. Zum Beispiel: "Benutzerverwaltung funktioniert".

Alle zwei/drei Wochen ist ein Milestone fällig.

Teilen Sie die Eigene Anforderungsliste in zusammengehörende, unabhängie Bereiche/Milestones auf, Milestones sollten

• dem Benutzer demonstrierbar neue Funktionalität zeigen (Sie können 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. Schätzen Sie den erwarteten Zeitaufwand für jeden Milestone und planen Sie konkrete Daten, an denen die Milestones erledigt sein


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 unabhängig erledigen kann. Niemand ist also je untätig.

Haken Sie die Anforderungen (ToDos) nach und nach als erledigt ab, wenn sie ausprogrammiert/erledigt sind.

BeispielZum Beispiel könnten Milestones so aussehen:

Datum Milestone ToDos

4.2.2013 Benutzerverwaltung funktioniert grundsätzlich. Jeder Benutzer bekommt eine passende Login-Seite. Benutzer können angelegt werden, geändert und gelöscht. Das HTML-Layout und CSS für die Seite stehen grundsätzlich fest.

101, 102, 104, 105, 131, 141

18.2.2013 Benutzer können einen einfachen Arbeitsjournaleintrag anlegen, den die anderen Teammitglieder auch sehen

133, 134, 141

4.3.2013 Der Übersichtsdialog des Teams ist fertig. Alle Arbeitsjournal-einträge der Mitglieder werden nebeneinander dargestellt, mit Summen der geleisteten Stunden und Kurzzusammenfassung (nicht Detaileinträgen)

201, 203, 222, 109, 151, 172

... ... ...

20.4. alle Einträge der Priorität 1 aus der Anforderungsliste wurden erledigt und sind als Gesamtes benutzbar

...

ProgrammdokumentationDie 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 für 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 Lösungen.

Am Schluss überarbeiten Sie das Dokument und geben Empfehlungen ab, als wie gut Sie das


Programm und einzelne Teile einstufen, was verbessert werden kann und wann Sie das gemacht haben oder warum nicht.

Fügen Sie hier auch am Ende ein aktuelles Datenbankmodell mit kurzer Beschreibung hinzu.

Beispiel: Code-SmellsFolgendes 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 vollständig und kann es auch nicht sein. Finden Sie Dinge, die Sie an Ihrem Code stören, erklären Sie, warum dies störend ist, und was Sie dagegen tun könnten.

• 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 möglichst unabhängige Teile auf, mit klaren Parametern und Rückgabewerten

• Lange Parameterlisten an Funktionen. Versuchen Sie nur das Nötigste zu übergeben.

• Globale Variablen. Diese sind möglichst ganz zu vermeiden.

• Aussagekräftige Funktionsnamen

• Kommentare fehlen im Programm. Das Programm sollte intuitiv verständlich sein für jeden, der minimale PHP-Kenntnisse besitzt (auf der anderen Seite, wenn sie zu viel an einer Funktion dokumentieren müssen, so ist sie vielleicht zu kompliziert und könnte vereinfacht werden)

TestdokumentationDie Testdokumentation besteht aus mindestens zwei Dokumenten. Einer Übersicht über alle gemachten Tests und einer Checkliste (mit nummerierten Einträgen für jeden Test).

Dokumentieren Sie, wann Sie was geprüft haben, wie Ihr Programm reagiert hat und was für ToDos oder Konsequenzen daraus resultierten über den gesamten Projektverlauf in der Übersicht.

Bauen Sie hier ruhig auch Verbesserungsvorschläge ein. Zum Beispiel aus Benutzersicht (z.B. "Beim Erfassen eines Journaleintrags könnten Datum und Uhrzeit mit dem aktuellen Datum vor-ausgefüllt werden, so spart sich der Benutzer in den meisten Fällen Zeit") und besprechen Sie dies mit dem Programmierer. Danach fügen Sie einen Eintrag in die Eigene Anforderungsliste mit neuer Nummer ein.

Diese Testdokumentation (Testübersicht und Checkliste) wird am Schluss abgegeben und wird benotet.

Beispiel: Vorschläge für die ChecklisteDiese Liste ist nur ein Vorschlag, um daraus Ihre Checkliste zu erstellen. Finden Sie weitere Testfälle und -möglichkeiten.

• Geben Sie in Felder etwas ein, was viel zu lang ist

• Fügen Sie spezielle Characters ein wie: *?\/<>();"'#%... die eine Bedeutung beim Programmieren haben. Probieren Sie auch andere spezielle Characters wie ©½..


http://de.wikipedia.org/wiki/Smell_(Programmierung)

• Lassen Sie Felder leer, die ausgefüllt werden müssen

• 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)

◦ Fügen Sie Dinge zusammen, die nicht zusammen gehören (Teams mit 0 Mitgliedern, Teams mit allen Personen) - prüfen Sie wie sich die Übersichtdialoge verhalten

• Bösartiges Umgehen mit dem Programm

◦ Schliessen Sie mittendrin den Browser, währen sie zusammengehörende Daten eingeben

◦ Schalten Sie Apache/MySQL aus, während jemand Daten eingibt

◦ Löschen Sie Benutzer, die Einträge haben. Löschen Sie Teams, die am Arbeiten sind und Arbeitsjournaleinträge haben - wird hier nachgefragt vor dem Löschen, ob wirklich alles gelöscht werden soll?

◦ Loggen Sie sich zweimal ein (auch als unterschiedliche Nutzer) und löschen einen Benutzer, an dem sie im zweiten Fenster gerade etwas editieren

• Testen Sie verschiedene Filter und Sortierungen in Übersichtsdialogen

• Springen Sie wild zwischen nicht zusammengehörenden Teilen des Programms hin und her

HandbuchSchreiben Sie ein Handbuch zu Ihrem Programm. Orientieren Sie sich am gelieferten Beispiel und anderen Ihnen bekannten Handbüchern.

Das Handbuch sollte 10-20 Seiten umfassen und mit Screenshots und klaren Beispielen für Nichtinformatiker, also die Benutzer Ihres Programms verständlich sein.

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

GruppenteilDer Gruppenteil, in dem Sie gemeinsam Ihre Zusammenarbeit beurteilen (2-3 Seiten):

• Wer, warum welche Rolle und Aufgaben übernahm, warum diese Milestones und diese Daten gewählt 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 erklären Sie hier unbedingt warum.

• Sie formulieren Verbesserungsvorschläge (Effizienzsteigerung: Planung/Arbeit/Zeit, Leerläufe..) und was Sie daraus lernen und nächstes Mal besser machen werden.Denn Sie werden noch mehrere grössere Projekte in der Schule verwirklichen müssen


Individueller TeilIm individuellen Teil, den Sie auch nicht den anderen Gruppenmitgliedern zeigen sollen 2 , dokumentiert jede Person für sich die gelernten Erfahrungen (1 Seite).

• Den eigenen Umgang in der Gruppe, Arbeitshaltung und Effizienz, Ihre Stärken und Schwächen und wie Sie im Projekt mitgearbeitet haben (Selbstbeurteilung).

• Sie beurteilen dieselben Kriterien auch bei dem/den anderen Gruppenmitgliedern (Fremdbeurteilung).

• Sie beurteilen die Nützlichkeit des Moduls, den Arbeitsauftrag durch die Lehrperson, den Ablauf des Moduls und bringen Verbesserungsvorschläge an. Was hätte durch die Lehrperson besser/genauer formuliert werden können, wo wäre 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.

2 Die getrennte Abgabe soll nur dazu dienen eine ehrlichere eigene Sichtweise beschreiben zu können. Sie ist kein Dokument um den anderen anzuschwärzen oder schlecht zu machen.


Documents

Moduldokumentation M318 (Arbeitsjournal)