Barcamp Bodensee in Friedrichshafen am kommenden Wochenende

In der Anfahrtsbeschreibung zum Barcamp steht:

"Difficult because lake in the way Chose to drive around and then use either western or eastern approach."

Das stimmt natürlich nur bedingt, denn es gibt die Fähre Romanshorn-Friedrichshafen, siehe Bild und nicht ganz direkt, aber für diejenigen, die aus Richtung Konstanz starten, existiert die Fähre Konstanz-Meersburg, auch "schwimmende Brücke" genannt.

• Fähre
• Bodensee von Friedrichshafen aus
• Zeppelin über Konstanz

Einen Artikel zum Barcamp mit Bild des Veranstaltungsortes gibts bei doubleslash. Wir berichteten ja bereits im April davon, dass wir hingehen im Artikel übers Barcamp. Weitere Berichte liefert die Google-Blogsuche. Das Barcamp Bodensee findet am Wochenende des 31. Mai und 1. Juni in Friedrichshafen statt. Wer noch nie am Bodensee war, kann sich anhand der Bilder einen ersten Eindruck verschaffen. Die Bilder sind aus verschiedenen Jahreszeiten, See und Himmel können jedoch auch innerhalb eines Tages so unterschiedlich aussehen. Inzwischen sind fast 200 Teilnehmer angemeldet und viel mehr wären auch nicht zugelassen, maximal wohl 220. Dabei ist mit einkalkuliert, dass es noch kurzfristige Absagen gibt. Wer Interesse hat mal zu sehen, was bisher an Themen angeboten wird, bzw. gewünscht wird erfährt das und mehr auf den Seiten des Barcamps Bodensee.

Bücherliste zu Webdesign, Projektmanagement, Informatik usw.

Hier im Blog gibts ja bereits die Quellenliste zu Requirements Engineering. Inzwischen ist auch unsere Bücherliste, mit den bei miradlo genutzten, Büchern online. Ganz vollständig ist sie noch nicht, aber wir arbeiten dran. Da es einfacher ist, diese Liste als eigenständige Seite, laufend zu aktualisieren, habe ich mich entschlossen, sie außerhalb des Blogs im allgemeinen Bereich unterzubringen. Die Bücherliste enthält die Titel, die in unseren Bücherregalen zu finden sind. Angefangen haben wir bereits mit Kurzkommentaren zu den Büchern, so dass ihr nachschauen könnt, welche Bücher wir für besonders empfehlenswert halten. Die Kommentare werden wir im Lauf der Zeit noch ergänzen, die Liste als solche natürlich ebenfalls. Wir haben Bücher aus folgenden Bereichen aufgeführt:

• CSS
• Webdesign
• Linux
• Projektmanagement
• Informatik
• Programmieren (PHP, Java...)
• Usability, Barrierefreiheit usw.
• Design

Darüber hinaus haben wir eine kleine Serie der diversen Versionen des Dudens. Das Kochbuch für Geeks ist ebenfalls dabei, eine gute Freundin hat mir das geschenkt. Sicherlich nicht in der Hoffnung, dass ich deshalb koche, sondern eher als Anregung, was ich mir von den kochenenden Menschen in meiner Umgebung wünschen könnte und einfach so zum Amüsieren. Ja, es stimmt, was ihr daraus schließt: ich koche nicht, auch nicht ein bisschen, auch nicht ab und zu. Zumindest dann nicht, wenn es nicht zählt, Tiefkühlgemüse in der Mikrowelle zu erhitzen und wenn die Definition ist, dass Salat nicht gekocht wird.

Webentwicklung mit Linux und seinen Programmen

Teil III der Artikelserie zu Linux in der Webentwicklung von Peter Kröner, befasste sich mit den Programmen. Beim Vorschlag Gimp brandete in den Kommentaren die übliche Diskussion auf, dass Gimp nicht wie Photoshop sei. Nun, ich kann zu Photoshop nichts sagen, ich habe es ein- zweimal bei jemand gesehen aber nie benutzt. Allerdings kann ich zu Gimp manches sagen. Ob das Argument stimmt, dass Gimp mit Photoshop-Dateien nicht klar käme, kann ich nicht beurteilen, da wir bisher selten Daten austauschen mussten. Für Logos, bekamen wir bisher noch jedes Mal ein Format, z.B. PDF, welches sich nutzen ließ. Denn es gibt ja nicht nur Gimp, auch Scribus und Inkscape sind durchaus hilfreich, je nach Anforderung. Was meines Erachtens absolut nicht stimmt, ist die Unübersichtlichkeit von Gimp, die alle Windows-Nutzer anführen. Gimp funktioniert hervorragend und sehr übersichtlich, wenn man es mit den Mitteln von Linux entsprechend nutzt.

Mehr lesen

Episode 8: Vorstudie strukturieren ::: Softwareprojekte

Ein Projekt ist einmalig. Es ist mit gewissen Risiken verbunden und ist, da es einmalig ist, nicht mit einem anderen Projekt direkt vergleichbar. Das ist eine in allen Lehrbüchern beschriebene Tatsache. Wenn Projekte einmalig sind, wieso geht man dann immer mehr oder weniger gleich an Projekte heran? Ganz einfach: Projekte können anhand bestimmter Eigenschaften klassifiziert werden. Und so ist die Herangehensweise natürlich pro Projekttyp sehr ähnlich. Wenn ich hier jetzt beschreibe, wie die Vorstudie zu strukturieren ist, kann das keine allgemeingültige Beschreibung sein. Es ist eine mögliche Art die Vorstudie zu strukturieren. Wenn man nichts hat, kann man sich hier ein paar Ideen herausfischen. Andere Themengebiete sind nicht relevant oder durch diese Vorstudie nicht abgedeckt. Also: Selber kreativ sein und Hirn einschalten! Nicht alles was Roland sagt stimmt. Normalerweise laber ich sogar ziemlich viel Mist. Das kommt daher, dass es keine einzige Wahrheit gibt. Die Projektmanagementwelt ist bunt und nicht schwarz- weiß. Thomas befragte in der ersten Woche die Entwickler, Giuseppe, den Familienvater der anderen Firma und einige schwere Jungs. Thomas ist (so wie ich) ein bisschen schwer von Begriff. Aber nach der Woche war ihm klar, dass er sich mit einer kriminellen Vereinigung eingelassen hatte und so schnell da nicht mehr herauskommen wird. Welchen Zweck die Betonschuhe und der Familienteich haben wurde ihm auch klar. „Was solls, wenn man schon Mist baut, dann wenigstens Spaß dabei!“, sagte er sich. Da an kündigen nicht zu denken war, entschied Thomas sich das Projekt durchzuführen. Er erstellte eine Vorlage für eine Vorstudie mit folgenden Kapiteln (zu den Begriffen siehe Glossar Informatik):

Einleitung / Management Summary

Hier wird auf maximal einer Seite beschrieben was mit dem zu erstellenden System erreicht werden soll. Es soll den Auftraggebern eine Zusammenfassung geben, was sie erhalten und die wichtigsten Eckpunkte auflisten.

Systemübersicht

Falls möglich, sollte gleich eine sehr grobe Systemübersicht dargestellt werden.

Anforderungen

Auflistung der Eigenschaften die dieses System haben soll. Die Anforderungen werden in funktionale und nicht-funktionale Anforderungen aufgegliedert. Hier kann schon mit Usecases gearbeitet werden. Wie die Anforderungen zusammen gesammelt werden ist im Prinzip nicht wichtig. Hauptsache sie sind eindeutig identifizierbar und so vollständig wie möglich. Beispielsweise kann man jeder Anforderung eine Nummer geben. Diese Nummer kann man später wieder verwenden.

Funktionale Anforderungen

Hier wird beschrieben was man mit dem System später machen kann. Zum Beispiel „Anf#82: Verwalten der schweren Jungs“ oder „Anf#98 Auflistung wie viel Schmuggelware abgegeben wurde“ Weiterhin sind funktionale Anforderungen die Beschreibung der Schnittstellen und anzubindenden Systeme.

nicht-funktionale Anforderungen

Wie der Name schon sagt- handelt es sich hier um Anforderungen, die nichts direkt mit der Funktion zu tun haben. Im Prinzip ist es egal ob eine Berechnung 100 Tage benötigt. Wenn nach 100 Tagen das Ergebnis der Berechnung vorliegt, hat die Funktion funktionert. Eventuell sind 100 Tage aber ein bisschen lange um 20+30 zu rechnen

Sicherheitsanforderungen

Welche Personen dürfen auf welche Daten zugreifen? Wie schützen wir uns vor anderen Familien oder der Steuerbehörde?

Geschwindigkeit

Wie lange darf eine Bearbeitung dauern?

Mengengerüste

Wie viele Mitarbeiter, Daten und Zugriffe sind zu erwarten?

Betreibbarkeit

Welche Service Levels müssen vereinbart werden? Vor allem bei einem System, indem Personen direkt betroffen sind, muss man sich hier besonders viel Gedanken machen. Wie viel Wartungsfenster sind zu erwarten? Welche weiteren Kriterien sind hier zu beachten? (Rechenzentrumeigenschaften usw.)

Rechtliche Fragen

Was erlaubt das Gesetz? Im Fall der Familie: was ist erlaubt und was wird geahndet?

Desaster Recovery

Wie schnell müssen welche Funktionen nach einer Katastrophe wieder verfügbar sein? Welche Vorgaben sind in der Firma vorhanden?

Business Continuity

Wie wird gewährleistet das im Katastrophenfall die Geschäfte weiter getätigt werden können? Von welchen IT-Systemen ist die Firma abhängig?

Wartbarkeit

Gibt es spezielle Anforderungen an die Wartbarkeit der Systeme? Beispielsweise sind die Legacy Systeme weiterhin zu warten. Wie soll das gewährleistet werden?

Erweiterbarkeit

Jedes System muss erweiterbar sein. Wo sind die Grenzen? Woran kann erkannt werden, dass diese Grenzen erreicht werden?

Dokumentation

Welche Dokumentation (Betriebsdokumente, Sourcecode Beschreibung usw.) muss erstellt werden?

Stakeholder

Welche Personengruppen sind im späteren Projekt zu beachten? Je politischer ein Projekt ist, desto wichtiger ist es zu wissen, wen man alles informieren muss. Dieser Punkt kommt zwar später wieder in der Projektbeschreibung, doch schadet es nichts, sich schon sehr bald darüber klar zu werden, wer alles betroffen ist.

Abgrenzungen

Was ist nicht Aufgabe dieses Systems? Diese Frage ist sehr wichtig. Ansonsten wird man mit ungeplanten Anforderungen zugeschüttet. Beispielsweise ist das bestehende System deshalb so komplex, da während des Erstellens immer neue Anforderungen hinzugefügt wurden. Hier kann erkannt werden, dass die Vorstudie unter Umständen schon ein eigenes Projekt ist. Bei großen Systemen wird daher die Vorstudie schon als Evaluationsprojekt durchgeführt. Egal wie groß ein Projekt ist, ich kann nur empfehlen eine gewissenhafte Vorstudie durchzuführen. Jede Überlegung in diesem Bereich spart euch hinterher das Vielfache an Ärger, Fehlern und Aufwänden!