Re: Lastenheft war -> Re: Bitte um Feedback für Moderationskonzept des Schulserver-Entwicklertreffens in Karlsruhe
Hallo Volker,
ich möchte mich recht herzlich für die Antworten bedanken, insbesondere
die Erklärungen der Abkürzungen. Ist insgesamt auch schlüssig.
Allerdings gelingt es mir trotz allem nicht, deine Überlegungen auf des
Orginal-"Pflichtenheft" nachzuvollziehen.
Volker Eckert schrieb:
ich immer wieder Lastenheft bla, Pflichtenheft blub lese, sehe ich
mich genötigt mich zum Thema Qualifizierung zu äusssern!
Ich konnt`s einfach nicht mehr ertragen @ Helmut & Michael :)
Das es Probleme gibt, war offensichtlich. habe ich schon an anderer
Stelle geschrieben.
Ich werde jetzt nicht so ins Detail gehen, und möchte nur grob
aufzeigen wie es in etwa sein sollte:
Als Erstes kommt das Grundgerüst in Form einer DQ; am besten ein
Lastenheft. Die Werkzeuge einer Qualifizierung können durchaus
unterschiedlich sein, es kommt immer auf das Produkt an. Der
Auftraggeber (Lehrer) legt im Lastenheft grob fest, was er braucht und
setzt Prioritäten. Beispiel: Das BS sollte einen Printserver haben,
der die Funktion x und Funktion y ermöglicht. Der Auftragnehmer
(Programmierer) legt dann fest, wie er die Aufgaben erledigt, indem er
beschreibt, wie er das Ganze durchführen möchte. Beispiel: Als
Printserver wird Cups Version XY mit den Funktionen xyz gewählt.
Diese detaillierte Beschreibung nennt man Pflichtenheft.
Wie oben schon gesagt, danke für die Begriffsbestimmung. Aber mir geht
es nicht um Begriffe. Wenn ich ein Buch lese, dann versuche ich zu
erkennen, was der Autor zum Ausdruck bringen will. Genauso hier:
m.E. wollen beide Dokumente die Anforderungen aus Sicht der Lehrer
beschreiben. Für mich erheben sich die 2 Fragen,
- welches Dokument beschreibt die Anforderungen besser und
- welches Dokement ist für die Entwicklung brauchbarer.
Welches Dokument die Anforderungen besser beschreibt, siehe mein
Beispiel mit dem Drucker. Bleibt die Frage zu klären, welches ist
brauchbarer?
Der Auftraggeber bekommt das Pflichtenheft und prüft, ob es mit seinem
Lastenheft konform geht, und stimmt das weitere Vorgehen mit dem
Auftragnehmer ab.
Im Fall von Skolelinux ist leider erst ein Pflichtenheft erstellt
worden, welches meiner Meinung nach eine eiermilchlegende Wollmilchsau
beschreibt, deren Verwirklichung unrealistisch erscheint.
da meine Meinung etwas anders ist, möchte ich diese hier darstellen:
die Anforderungen der Schule sind oft deutlich härter und komplexer als
in der Industrie.
- wo "reiten" so viele Nutzer über die PCs wie im Bildungsbereich
- wo werden soviel verschiedene Programme auf jedem PC installiert
- wo muß man auch mit soviel Vandalismus rechnen wie in der Schule
- wo betreuen noch unbezahlte, nicht geschulte Admins die PCs
- wegen Ausschreibungzwang gibt es häufig untaugliche (billige) Hardware
installiert von häufig inkompetenten Firmen ("schnelle Mark")
Damit ist doch zu erwarten, das eine eierlegende Wollmilchsau gebraucht
wird, die außerdem noch "idiotensicher" bedienbar ist und auch noch
solchen Anforderungen wie Datenschutz und Datensicherheit (allerdings
mit anderen Prioritäten) gewährleisten muß.
Genau das ist die Aufgabe und dem stellen sich Arktur, GEE, BW-ML und
wie sie alle heißen. Wer mit der "eierlegenden Wollmilchsau" ein Problem
hat, der sollte sich nicht an die Entwicklung eines Schulservers wagen.
nun zur meiner Situation. muß dazu sagen, das ich vor einem Jahr meine
Schule (Gymnasium) gewechselt habe. Früher ein winNT-Server, an der
Schule hat ein Kollege das Netz auf einer SuSE selbst eingerichtet. Ich
unterstütze ihn bei der Betreuung. Seit ca. 3 Monaten beschäfitge ich
mit Arktur 3.5 und seit 2 Wochen lese ich diese Liste mit.
Nehmen wir den Arktur, dann "bearbeitet/erfüllt" dieser Server von dem
Pflichtenheft die Punkte 1 und 2, allerdings ohne die "Synchronisation
mit dem Schulverwaltungsprogramm" und ohne "Klausurumgebung" (die
scheint es noch nirgendwo zu geben). Auch zum CD-ROM-Server leistet
Arktur nichts, aber dazu gibt es mehrere ergänzende Lösungen im Netz.
In diesem sogenannten Pflichtenheft steht ab dem Punkt 2.2: _mögliche_
Zusatzangebote. Mögliche Zusatzangebote bedeutet für mich, _wenn_
diese bereitgestellt werden, dann wäre es doch gut, wenn sie das leisten
können, was dort angegeben ist. Aber wenn man diese Punkte streicht oder
auf später verschiebt steht das allemal nicht im Widerspruch zu diesem
Text.
also selbst wenn es nicht machbar _wäre_ , gibt es mit den Punkten 2.2
und folgende eigentlich kein Problem. Aber so wie ich seine Seite unter
http://www.arktur.th.schule.de/installation/index.htm verstehe, scheint
er seinen Arktur so modifiziert zu haben, das er etliche Forderungen
dieses Pflichtenheftes in seiner Schule realisiert. Weiter ist zu
erkennen, dass zu weiteren Lösungen die Dokumentation (von anderen)
angegeben ist. Zumindest sieht es für mich so aus, als ob für dieses
Orginalpflichtenheft die Modifikationen für Arktur existieren. Was aber
mit Arktur geht sollte auch mit Debian, SuSE usw. gehen.
interessant ist weiter, dass für die im Pflichtenheft geforderte
Backup-Lösung eine für Arktur angepaßte Lösung von einem Dieter Kroemer
existiert.
Was für mich noch viel überraschender war, dass auf meine Nachfrage hier
in der Liste zu dem Printserver ich eine sehr detaillierte
Installationsanleitung entsprechend der Forderungen dieses
Orginalpflichtenheftes gemailt bekam. Dafür auch nochmal hier in der
Liste meinen Dank.
Die Programmierer in dieser Form zu Knebeln ist völliger Unsinn und
führt zu garnix, ausser ein toll aussehendes Papier zu erzeugen,
welches zwar noch in Fragmenten als Anhaltspunkt dienen kann, aber
sonst nur tot auf irgendwelchen Servern liegt.
seltsam. ich habe bezogen auf dieses originale Pflichtenheft nun schon
etliche Realisierungen (meist für Arktur) gesehen. Ich habe den
Eindruck, dass keiner der Entwickler von HD. Kirmse oder gar von einem
Text geknebelt wurden.
Aber noch etwas zu den Programmierern. Den Server den wir in der Schule
einsetzen, da wurde überhaupt nichts programmiert, trotzdem hätte uns
diese "Vorlage" beim Einrichten sehr geholfen und uns auch mehr
Sicherheit gegeben, an "alles" gedacht zu haben. natürlich ist das
Anlegen von hunderten Schülern mit einem Programm wie bei Arktur viel
komfortabler. wir haben dagesessen und haben tagelang eingetippt. Und
andere Schulen machen es genauso. Das bedeutet aber, damit ein
funktionierender Schulserver entsteht, muß in erster Linie konfiguriert
werden. Das Bereitstellen einer lehrersicheren Oberfläche durch die hier
laufend zitierten Programmierer kann nach und nach erfolgen. Was eben
noch nicht da ist, läßt sich auch mit einer guten Anleitung (Doku)
simulieren.
Aus diesem Grund war es richtig und wichtig ein Dokument zu erzeugen,
welches den Erstellern von Skolelinux eine Richtschnur gibt und für
weitere Qualifizierungsarbeiten als Grundlage dient. Der nächste
Schritt sollten eine IQ und eine OQ sein. In Diesen werden
Akzeptanzkriterien festgelegt die, aus dem Lastenheft hervorgehen und
entsprechend geprüft werden - das Kirmsepapier eignet sich hierfür
nicht :P
Wenn es sich nicht für Skole eignet, für einen zukünftigen Arktur eignet
es sich sicher.
Mit freundlichen Grüßen
Michael
Reply to: