• Fenster Eigenschaften Ebenen Scribus | klicken vergrößert

• Text unmarkiert Standardschriftart Scribus | klicken vergrößert

Scribus ist ein Desktop-Publishing-Programm, oder auch Layoutprogramm. Gedacht ist Scribus um beispielsweise Visitenkarten oder Flyer für die Druckvorstufe, also die Dokumentversion die professionelle Druckereien als Vorlage benötigen. Andere Programme, die damit vergleichbar sind, sind die proprietären Programme Adobe PageMaker, QuarkXpress oder Adobe InDesign. Zu den genauen Funktionen dieser Programme kann ich nichts sagen, da ich keins davon ernsthaft genutzt habe.

Viele glauben anfangs dass OpenOffice.org Writer oder Word für alles geeignet sind, was man so am Rechner machen möchte. Je nachdem welchen Zweck es erfüllen soll, stimmt das jedoch nicht. Für Magazine, Newsletter, Anzeigen, Broschüren, Kalender und anderes, was anprechend gesetzten Text der später gedruckt werden soll, sind spezielle Programme besser. Ich nutze Scribus auch zum Erstellen von Logos, die als svg vorliegen sollten, so dass sie jeweils in passender Größe in verschiedenen Fällen eingesetzt werden können.

Normalerweise bietet sich dafür eher inkscape an. Dort fehlte jedoch einige Zeit der PDF-Export, eine ganz schlechte Idee, um Dateien an Druckereien weiter zu geben. Schwierigkeiten hatte ich außerdem mit dem Austausch von Dateien aus Inkscape nach Scribus. Da ich häufiger Scribus brauche, nutze ich es häufig auch für Aufgaben, die eigentlich eher zu Inkscape gehören.

Für Scribus gibt es ein deutschsprachiges Wiki, in dem vieles gut erklärt wird. Schwierig für Anfänger ist hierbei, dass man zunächst gar nicht weiß, welche Funktion man eigentlich sucht. Deshalb beginne ich hier eine kleine Serie zu Scribus, die die ersten Grundlagen und Stolperfallen behandelt. Weiterführendes gibt es in den Dokumentationen im Netz, beginnend beim Einstieg in Scribus.

Scribus Eigenschaften und Ebenen

Innerhalb von Scribus arbeitet man üblicherweise mit Ebenen. Aufgerufen wird das zugehörige Fenster unter /Fenster/Ebenen. Die einzelnen Elemente, z.B. eine Textbox bearbeitet man über den Dialog Eigenschaften, aufrufbar z.B. über /Fenster/Eigenschaften. Viele Befehle können auf mehreren Wegen erreicht werden. Weil ich es ständig brauche öffnet sich Scribus bei mir von vorne herein mit Ebenen und Eigenschaften.

Anfänger nutzen Scribus häufig erstmals bei einem fremden Dokument, um etwas anzupassen. Je nachdem wie ein solches Dokument angelegt ist, können bereits beim ersten Versuch etwas zu markieren, Schwierigkeiten entstehen. Im zweiten Bild ist die Textbox markiert, dabei ist im Ebenendialog erkennbar, zu welcher Ebene die Box gehört. Der Text selbst ist nicht markiert, in der Anzeige der Eigenschaften wird daher die installierte Standardschrift gezeigt, jedoch nicht die für diesen Text tatsächlich genutzte Schrift.

Markieren klappt nicht?

Häufig ist die erste Hürde, dass sich nicht markieren lässt, was man möchte. Was nicht markiert ist, kann auch nicht geändert werden. Dafür gibt es einige Gründe, die häufigsten:

• Objekt liegt nicht in der Ebene, in der man steht
• Ebene ist gegen Veränderung gesperrt
• Objekt ist Teil einer Gruppe
• Objekt liegt hinter einem anderen Element
• Textbox ist markiert, aber der Text selbst nicht, deshalb ändert sich nichts

Ganz ab und zu liegt es tatsächlich an Scribus, welches sich beispielsweise beim Text mit der Maus markieren zuweilen verschluckt. Innerhalb der Textbox nutze ich da lieber STRG +a das klappt zuverlässig.

Was ist daran falsch?

Aus Sicht des Programmierers war alles super. Wir hatten es einfach und der Datenfluss war 100% unter Kontrolle. Die Kommunikationsmuster können wir uns noch sehr gut vorstellen. Der Anwender ist mit dem Programmfluss geschaltet und er muss seine Arbeitsweise an das Programm anpassen.

Wie bitte? Der Anwender muss sich anpassen?

Hm… Da ist glaube ich das Problem. Der Businessprozess sieht unter Umständen überhaupt nicht vor, dass der Anwender auf die Antwort vom Server warten soll. Vielleicht will der Anwender gleich mit dem Bearbeiten von Kundeninformationen, wie Lieblingsfarbe und Lieblingsauto weiter machen. Und er möchte gar nicht auf den Server warten.
Viel schlimmer noch. Der Anwender wird genötigt zu warten und wird aus seinen Gedankengängen herausgeworfen. Und das ist nun wirklich schlecht.

Rettung naht mit AJAX usw.

Jaja, wir kennen das. Dann bauen wir halt was Modernes ein und kommunizieren asynchron. Wir lassen den Anwender weiter machen und alles ist prima.
Aber jetzt kommt unser Problem der neuen Welt.

Wie informieren wir unseren Anwender?

Wir überlassen also die Korrektur und Testerei der eingegebenen Daten unserem asynchronen Prozess. Der macht das prima und unser Anwender tippt fröhlich weiter.
Mitten in der Eingabe der Lieblingsfarbe poppt aber eine Fehlermeldung auf die da sagt: “Bitte geben Sie einen Namen ein“.
Und der Anwender wird aus seinem Businessprozess und seinen Gedanken herausgeschleudert.
Na schön, da er sowieso direkt zum Namen zurückgeführt wird (der Fokus ist wieder auf dem Namensfeld) gibt er den Namen halt ein.
Blöd ist nur, dass er mittlerweile aber auch noch eine falsche Farbe eingegeben hat, da die Applikation ihn ja aus seiner Farbeingabe herausgerissen hat.
Also kaum ist er mit dem Namen fertig, oder er tippt noch am Namen rum, poppt schon wieder eine Fehlermeldung auf: “Bitte geben Sie eine korrekte Farbe ein“.
Oha!
Wir haben hier wohl was falsch programmiert gelle?
Klar, solche Probleme muss man schon irgendwie anders lösen. Aber bevor man an eine hoch interaktive Webseite herangeht, sollte man sich darüber im Klaren sein.

War’s das schon?

Nein, es gibt noch tollere Probleme.
Stellt euch vor wir sitzen in einer größeren Firma, oder wir arbeiten sogar an verschiedenen Standorten (was im Web ja gewünscht ist) und zwei Editoren arbeiten zur Zeit am gleichen Datensatz.
Der Eine will die Lieblingsfarbe der Person ändern, da eine E-Mail vorliegt ,in der der Kunde sagt, dass seine Lieblingsfarbe rot sei, und gleichzeitig ruft der Kunde einen zweiten Mitarbeiter an und sagt, seine Lieblingsfarbe sei doch blau.
Beide Mitarbeiter tippen also an der Farbe herum.
Und was geschieht nun?
Der Mitarbeiter mit der roten Farbe editiert einen veralteten Datensatz. Da er ein wenig länger braucht, wird zuerst die blaue Farbe der Telefonanfrage abgespeichert und dann die rote Farbe.
Beide Editoren sehen unter Umständen nicht, dass der andere Editor auch auf dem Datensatz sitzt.
Also wird die Eingabe noch komplexer.

Wie kann dass gehen?

Tja, während ein Editor die Farbe der E-Mail bearbeitet, muss der Datensatz für Veränderung gesperrt werden. Auch in einer wunderbaren AJAX-Superdupper-Anwendung.
Der zweite Editor, muss z.B. die Möglichkeit haben den ersten Editor zu informieren, dass neue Informationen vorliegen.
Oder es muss eine Prioritätendefinition vorhanden sein. Telefonbesprechungen müssen vor E-Mail Besprechungen gesetzt werden.
Oder es muss beschrieben werden, wer wann was wieso gemacht hat.
Weiterhin wäre es doch toll, wenn der Editor, der die E-Mail bearbeitet hat, über die Änderung informiert würde.
Das könnte so ablaufen, dass gerade geänderte Werte ihm noch einmal vorgelegt werden. Beispielsweise, falls innerhalb der nächsten zehn Minuten ein Wert von einer anderen Person geändert wurde, wird dieser Wert nochmals zur Überprüfung angezeigt.

Fazit

Sobald wir eine tolle, blinkende, asynchrone Eingabemöglichkeit für unsere Benutzer erstellen, begeben wir uns auf gefährliches Gebiet. Die Nebenläufigkeiten von asynchronen Eingaben sind extrem komplex und müssen im Einzelfall genau analysiert werden.
Interaktive und an den Geschäftsprozess angepasste Webapplikationen sind klasse. Aber die Schwierigkeiten und Gefahren sind ungleich höher als bei einer Einwegkommunikation. Natürlich können dort auch solche Gefahren lauern, der Prozess ist jedoch einfacher zu verwalten.

Und dann mache ich manchmal den Fehler und glaube meinen Einsteigern, dass sie alles verstanden haben. Hier ein paar Beispiele:

EVA ist doch soooo klar

Ich fang immer bei EVA (nicht bei Adam) an. Und ich meine damit, dass man in einem Computerprogramm zuerst etwas eingibt, dann verarbeitet und dann ausgibt.

Cool gell?

So, ich zeig also meinen Einsteigern wie man etwas eingibt. Dann erkläre ich ihnen, dass wir jeden Wert den man eingegeben hat, erst einmal auf seine Richtigkeit überprüfen muss. Und erst dann darf man ihn verarbeiten. Wenn das auch noch geklappt hat, gibt es eine Ausgabe. Die kann entweder direkt in einem Text, oder als Rückgabewert in einer Funktion oder in einem Datenbankeintrag oder in einem Schaltprozess für einen Motor erfolgen.

Meine Einsteiger nicken eifrig, schauen sich meinen Code an und legen los. Solange ich dabei bin, sieht es noch recht gut aus. Eine Woche später vergessen schon einige, dass die Eingaben überprüft werden sollen. Und einen Monat später fällt ihnen nicht einmal mehr ein wie man etwas verarbeitet.

Was ist passiert?

Sie haben zwar EVA verstanden, aber die Grundlagen wie man eine Überprüfung erstellt sind nicht verstanden worden. Blöderweise sind viele der Einsteiger auch noch von männlichen Geschlecht. Und viele Männlein dürfen nicht zeigen, dass sie etwas nicht können. Vorher quälen sie sich lieber und bauen viel Bockmist.

Testen ist easy

Auch ein Klassiker. Da bauen wir die ersten Testfälle und lassen unsere Systeme durchrattern. Einen Monat später haben meine Buben und Mädels dann vollkommen vergessen, dass es verschiedene Testmethoden gibt. Das Resultat ist, dass Programme ausgeliefert werden, die beim ersten Knopfdruck schon anfangen komisch zu vibrieren. Das ist ziemlich ätzend.

Und wieder steht das Problem im Vordergrund, dass nicht einmal klar ist was eine For-Schleife ist. Traurig aber wahr.

Hab ich eine Idee?

Da viele der Einsteiger, oder auch Fortgeschrittenen, sich nicht trauen zu sagen, dass sie etwas nicht verstanden haben, habe ich eine Artikelserie Grundlagen angefangen. Dort schreibe ich zu den Grundlagen der Programmierung immer wieder ein paar Artikel. Jeder kann in dem Schulungsblog ungestört lesen. Falls mal eine Frage auftauchen sollte, kann die mit Kommentaren an mich gestellt werden. Vielleicht hilft diese Serie ein paar Einsteigern und Fortgeschrittenen mit den Programmiergrundlagen einfacher fertig zu werden.

Und da es so viele Programmierbeispiele gibt, möchte ich noch eines hinzufügen

Ute hat mich mal gefragt, ob wir eine Newsfunktion erstellen können, mit der man auch ein paar Bilder einfügen kann. Soll heißen, dass aktuelle Informationen auf einer Webseite so lange dargestellt werden, bis sie nicht mehr aktuell sind. Also Weihnachtsgrüße sollen nur automatisch zu Weihnachten erscheinen und kurz vor Ostern können wir die abstellen Aussehen soll es ihrer Vorstellung nach, in etwa wie folgt:

• Newssystem erstellen

Newsüberschrift Ostergrüße

Neben dem Bild einer News soll die jeweilige Überschrift einer Meldung oder Neuigkeit stehen und anschließend der dazugehörige Text. Weiterer Text oder die nächste Meldung folgt dann erst danach.
[Zumindest in standardkonformen Browsern klappt das... ]

Dieses Newssystem soll Bilder einpflegen können. Und da wir ja gerne komplizierte Sachen machen, sollen die Editoren, die die Texte schreiben, mit einem vernünftigen Rechtesystem ausgestattet sein.

Kurz gesagt: Wir wollen eine komplette Webapplikation bauen.

Und wir sind Wiederholungstäter. In den letzten Jahren haben wir diverse Webapplikationen erstellt. Diesmal gehen wir jedoch einen etwas anderen Weg. Ich habe unter Newssystem erstellen beschrieben, wie das Newssystem aussehen soll und wir diskutieren dort im Internet über die Erstellung. Falls ihr mitmachen wollt, seid ihr herzlich eingeladen.

Es geht darum, ein wirklich rundes und großes System zu erstellen mit dem wir später auch noch was anfangen können. Die Entwicklung wird wohl etwas langsamer vorwärts gehen, als wenn ich das Teil alleine schreiben würde. Aber vielleicht erfinden wir hier ein paar schönere und bessere Komponenten bei denen wir alle was lernen?

Beispielsweise wäre es nicht sehr ratsam ein Dach so zu konstruieren, dass das Wasser nicht abläuft sondern zur Mitte des Dachs hinfließt. Ein weiteres nicht ratsames Beispiel wäre es eine Decke so zu konstruieren, dass sie sich nicht selbst tragen könnte. Wenn man dann noch auf die Idee kommt, auf diese Decke einen Stuhl zu stellen, findet man sich höchstwahrscheinlich ein Stockwerk tiefer wieder.

Unsere Vorfahren haben also Architekturmuster erfunden. Daneben haben wir vor ein paar tausend Jahren auch noch das Rad erfunden. Wir empfanden das als ziemlich praktisch. Man kann mit so einem Rad die Reibungsverluste beim Schieben verringern. Und heute sagen wir immer wieder mal, dass wir das Rad nicht neu erfinden sollen.

Wie sieht das in der IT aus?

Die IT ist ein relativ neues Themengebiet. Vor ein paar Jahren erfand jeder Entwickler seine Räder jeden Tag nochmals. Irgendwie haben viele von uns, dann viele Stunden verbracht auf Problemen rumzunagen, die es eigentlich schon längst nicht mehr geben sollte.

Und genau hier setzen Architekturmuster und Design Patterns an.

Wir generieren heute eine Webapplikation, indem wir die Architektur auf den Browser, den Webserver, den Datenbankserver und das Netzwerk verteilen.

Wir verwenden Factory Patterns um bestimtme Objekte zu erzeugen.

Wir mixen die diversen Observer, Strategy und Composite Patterns und erstellen Model View Controller Patterns.

Das einzige Problem mit all den schönen Patterns ist, dass die Dinger ziemlich unverständlich sein können. Wenn ein neuer Entwickler anfängt, ist er mit Schleifen, if-Abfragen und anderen Schweinereien schon ziemlich ausgelastet. Wenn dann noch ein Roland vorbei kommt und ihm sagt “heute bauen wir mal ein Singleton”, dann fühlt sich der Anfänger irgendwie nicht wohl. Deshalb habe ich bei guggat emol Blog eine Designpattern Einführung erstellt. Ich werde nicht noch einmal alle Design Patterns, die zur Genüge beschrieben wurden, beschreiben. Ich werde hier die Design Patterns, die ich in den Programmierbeispielen verwende, erläutern. Später werden diese Patterns dann für reelle Aufgaben verwendet.

Wer weiß, vielleicht bauen wir in ein paar Jahren weniger IT-Decken die sich nicht selbst tragen können?

In den ersten Teilen ging es um die Studie als solche, sowie um Zufriedenheit mit der Open-Source-Software und der Rolle, die sie in Unternehmen spielt. Bei den folgenden Punkten geht es um die Frage, was erhoffen sich die Anwender im Unternehmen von OSS, wo gibt es Schwierigkeiten. Die Ergebnisse der Nutzung des externen Supports werden ebenfalls beleuchtet.

• Was versprechen sich Unternehmensanwender von Open Source? Wo erleben sie Probleme?

  • Kosten sparen ist der meistgenannte Grund für den Einsatz, gefolgt von offenen Standards und Herstellerunabhängigkeit
  • Gründe für den Einsatz sind außerdem Plattformunabhängigkeit und die Tatsache, dass OSS in manchen Bereichen Standard ist (da schlägt sicherlich z.B. der Apache als Webserver zu Buche)
  • Motive für den Einsatz sind vor allem:
    • Freiheit (insbesondere Zugang zu offenen Standards und Herstellerunabhängigkeit)
    • offene Quellen (insbesondere Zugriff auf Quelltexte, Anpassbarkeit)
    • Qualität (insbesondere die Leistungsfähigkeit, sowie die hohe Zuverlässigkeit und Sicherheit)
    • Pragmatismus (insbesondere die einfache Möglichkeit etwas erst einmal testen zu können, die Bekanntheit großer Open-Source-Lösungen und das interne Know-how zu bestimmten Lösungen)
  • Je länger und intensiver OSS eingesetzt wird, desto wichtiger werden Gründe, wie die technische Qualität. Trotzdem nennen rund 90% er erfahrenen Anwender das Sparen von Lizenzkosten, jedoch nur 76% der Einsteiger als Beweggrund  für den Einsatz von Open-Source-Software.
  • Hindernisse für den Einsatz sind vor allem die Integration bestehender Software. Dies trifft noch stärker auf große Unternehmen zu, da hier die Komplexität der eingesetzten Software steigt.
  • Ein weiteres Hindernis ist für einige der Mangel an qualifiziertem Personal, auch hier wieder vor allem in den größeren Unternehmen.
  • Manche nennen noch fehlende oder fehlerhafte Funktionen, als ein zumindest zuweilen auftretendes Problem.
  • Wobei schlussendlich 10% der Teilnehmer keine Hindernisse wählten.

Zehn Prozent sehen keine Hindernisse, keine Schwierigkeiten mit Open-Source-Software, andere überlegen vorm Einsatz was für und was gegen OSS spricht. Die Motive für den Einsatz haben sicher auch mit den Erfahrungen mit lizensierter Software zu tun. Wenn Software teuer ist, sind Probleme und Schwierigkeiten deutlich störend als wenn sie nichts oder weniger kostet. Erstaunt hat mich, dass die Zahl derer die Lizenzkosten als einen Grund für den Einsatz einsetzen steigt mit längerer Nutzung. Ich hatte eher erwartet, dass Neueinsteiger überwiegend die Kosten sehen, gegenüber anderen Gründen, wie der Herstellerunabhängigkeit, der Anpassbarkeit und ähnlichem.

Für mich kommen alle Gründe zusammen, ich kann nicht direkt einen deutlich hervorheben. Wichtiger als die Lizenzkosten sind mir jedoch alle weiteren Gründe. Wenn eine Software gut ist, stört es mich nicht so sehr dafür auch zu bezahlen. Im Vergleich der Software, die ich einsetze stehen jedoch der Preis einer Lizenzsoftware und ihre möglichen Vorzüge in keinem akzeptablen Verhältnis.

Beim Gespräch in unserem Unternehmen war die Sichtweise ähnlich, interessant ist frei wählen und ausprobieren zu können. Wenn ein Programm nicht bietet, was man sich erhofft probiert man ein anderes. Auch Linux selbst ist ja genau so offen, es gibt eine Vielfalt an Distributionen und ein Wechsel ist recht leicht möglich. Ebenso gilt das für die grafische Oberfläche, ob man KDE, Gnome oder eine der anderen GUIs bevorzugt ist Geschmackssache und kann auch recht einfach geändert werden. Bei lizensierter Software sind solche, schnellen und einfachen Wechsel kaum möglich, hat man doch jedesmal dafür bezahlt.

Sehr angenehm ist die Geschwindigkeit bei Open-Source-Software, neue Möglichkeiten und Ideen werden viel schneller umgesetzt und sind verfügbar.

Die Anpassbarkeit einzelner Anwendungen ist heute nicht mehr ganz so wichtig, wie noch vor einigen Jahren, da es fast immer Alternativen gibt, die genau das bieten, was der einen Anwendung vielleicht fehlt. Trotzdem erschrecke ich mich immer wieder bei lizensierter Software, wie wenig da meist angepasst werden kann.

• Inwieweit wird externer Support in Anspruch genommen?

  • Zusammengefasst wird sehr wenig externer Support genutzt, nur 35% gaben an, sich externe Unterstützung zu holen.
  • Diejenigen, die externen Support nutzen sind zu 90% zufrieden oder sehr zufrieden mit diesem.
  • Je größer das Unternehmen, desto häufiger wird auf externen Support zurückgegriffen.

Für uns ist der externe Support ebenfalls kein Thema, wir passen unsere Software selbst an, aktualisieren diese selbst und mal abgesehen von Recherchen im Netz oder direkten Anfragen bei einem Pluginautor, nutzen wir zur Zeit keinen externen Support. Ich denke das liegt aber auch an der Unternehmensgröße, denn je mehr Software genutzt wird und je komplexer die Infrastruktur der eingesetzten Software ist, desto spezialisierter muss das Wissen der Betreuenden sein. Da lohnt es dann doch oft auf einen Fachmann zurückzugreifen, welcher schneller eine Lösung für den jeweiligen Wunsch oder das bestehende Problem findet.

Im vorläufig letzten Teil dieser Serie geht es um die genutzte Software, welche Open-Source-Software  in welchem Maß eingesetzt wird.

Es gibt ja immer mal wieder die Diskusssionen, dass man mit Open-Source-Programmen nicht professionell arbeiten könne. Gerade im Bereich der Bildbearbeitung wird das ja recht massiv behauptet. Via Karl-Tux-Stadt gibts dafür mal wieder einen Gegenbeweis.

In den Niederlanden gab es einen Wettbewerb für den Entwurf einer 5 Euro-Gedenkmünze. Vorgabe dabei war, dass auf der einen Seite die Königin abgebildet ist, andererseits war das Thema Architektur. Den Wettbewerb hat Stani Michiels gewonnen, der für seinen Entwurf GIMP, Inkscape, und sein eigenes Programm Phatch nutzte, also ausschließlich Open-Source-Software. Phatch, schaue ich mir sicher nochmal genauer an, es sah auf den ersten Blick sehr spannend aus.

Der Belgier beschreibt Schritt für Schritt in seinem Blog pythonide wie die Münze entstand und was er sich dabei überlegt hat. Einen deutschsprachigen Artikel mit Bildern gibts bei Anneke. Stani erklärt, wie er das Bild der Königin aus den Namen wichtiger niederländischer Architekten erstellte. Er beschreibt, wie er die Auswahl traf, welche Architekten in welcher Reihenfolge erwähnt werden. Nicht chronologisch, nicht alphabetisch, nicht nach Büchern, sondern durch Suchmaschinenergebnisse, sortiert wurden die Architekten nach der Anzahl Treffer in Suchmaschinen.

Die Rückseite der Münze besteht aus Büchern von oder über die wichtigen Architekten. Stani verfolgte außerdem das Ziel die Niederlande und die Hauptstädte der jeweiligen Provinzen mit in seinem Entwurf zu verarbeiten. Die Auswahl der Bücher lässt in der Mitte Platz, um die Niederlande zu formen, an den Stellen der Hauptstädte sind Vögel.

Mich haben sein Entwurf und insbesondere seine Erklärungen beeindruckt. Ein Designer, der Hintergrund, Optisches und neue Medien insbesondere auch noch Open-Source so perfekt miteinander verbindet, das kannte ich noch nicht. Schaut euch seinen Bericht selbst an, auch dann wenn ihr sonst nicht gern englische Artikel lest, allein schon die Bilder des Entwurfs sind sehenswert.

• Arbeitsfläche konsole
• Desktop bildle
• virtueller Desktop kontact

Aktuell fragt Frank Helmschrott grad danach, ob man virtuelle Arbeitsflächen nutzt. Bislang waren zumindest die Kommentierenden überwiegend keine Fans von solchen Umgebungen. Für mich sind mehrere Desktops essenziell. Was ich beim Start morgens direkt nutze, habe ich bereits beim Thema Webeentwicklung mit Linux beschrieben.

Ich nutze immer vier Arbeitsflächen:

• konsole
• kontact
• bildle
• divers

konsole

Die wichtigste Arbeitsfläche, da sind immer zwei Konqueror (Dateimanager) offen in den gerade meistgenutzten Verzeichnissen. Außerdem natürlich eine Konsole. In dieser gibts einige benannte Fenster, die immer im passenden Pfad stehen, sei es für SVN (Subversion Versionskontrolle) für Sicherungskopien, Arbeiten auf anderen Rechnern…

kontact

Hier ist meist Kontact offen, also mit Mailprogramm, Kalender, Terminen, RSS-Akregator, Usenet, Adressbuch und so.

Außerdem ist hier immer ein Firefox mit mindestens acht, meist eher so um die dreißig Tabs offen. Ständig offen sind, die Adminbereiche der eigenen Blogs, ein Tab mit Suchmaschine, die Blogansichten der eigenen Blogs.

Hinzu kommen die Tabs mit allem was ich noch tun will und tun muss. Artikel lesen und kommentieren, Webseiten betreuen, recherchieren…

bildle

Auf dieser Arbeitsfläche gibts kein Hintergrundbild, wie sonst in halbtransparent z.B. in der Konsole immer sichtbar. Wenn ich mit Bildern arbeite, sei es in Digikam der Bildverwaltung, mit Scribus oder mit GIMP, dann brauche ich einen nicht ablenkenden Hintergrund.

divers

Hier liegt das, woran ich gerade aktuell arbeite. Mal OpenOffice.org-Dateien, mal Quanta (Webseiteneditor), mal Eclipse (PHP-Entwicklungsumgebung und SVN-Client), mal diverse andere Browser, wenn es um Layoutentwürfe oder Tests von Webseiten geht.

Nutzen mehrerer Arbeitsflächen/Desktops

Ich habe so immer die entsprechenden Programme an ein und derselben Stelle. Ich liebe den Vollbildmodus, habe jedoch meist recht viel gleichzeitig offen und könnte ohne meine Desktops keinen Überblick behalten.

In der Kontrollleiste, die von jeder Fläche aus sichtbar ist, lassen sich

• häufig genutzte Programme öffnen
• zwischen Arbeitsflächen wechseln
• Umschalter um den jeweiligen Desktop ohne ein Programm anzuzeigen (da liegen ein paar Symbole für weitere häufiger, aber nicht täglich genutzte Programme
• zwischen offenen Programmen wechseln
• wird ein Farbwähler angezeigt, der von jeder Stelle des Bildschirm die Farbwerte aufnehmen kann
• gibts eine Tastaturumschaltung deutsch, englisch, spanisch, nützlich wenn ich an fremdsprachigen Präsentationen arbeite
• gibts noch Kontrollsymbole
  • für die Akkulaufzeit
  • die Bildschirmauflösung
  • das Touchpad
  • die verschiedenen Kopierspeicher unter Linux
  • Kopete für Chats per ICQ und Jabber
  • die Brieftasche KWallet, die Passwörter verwaltet
• sowie das Amaroksymbol, falls ich nebenbei Musik höre
• das Wetter von Friedrichshafen, dass fast so ist wie hier in Konstanz (aktuell 2°C und Schneeregen)
• das Datum und eine textbasierte Uhr, die jetzt grad “fünf vor halb eins” anzeigt

Manche mögen mehrere Monitore, damit lässt sich ähnlich arbeiten. Für mich passt das nicht, da ich meist mehrmals täglich den Platz wechsle, mal stehend, mal am Schreibtisch, mal in diesem Raum, mal auf dem Balkon…

Ich könnte nicht effektiv arbeiten mit einem Rechner, bei dem sich das nicht so ähnlich einrichten lässt. Wenn ich zum Testen von Webauftritten mal auf einer Standard-Windowsinstallation arbeite, bin ich völlig genervt. Weder mehrere Arbeitsflächen, noch sinnvoll einfaches Kopieren auch mit mittlerer Maustaste, viele Programme öffnen unzählige Fenster, nie werde ich mich an Doppelklicks gewöhnen…

Meines Erachtens ist vieles auch Gewohnheit, je nachdem womit man häufiger umgeht, kommt man damit am besten klar. Jedoch sollte man sich ein System schaffen, welches zur eigenen Arbeitsweise passt, egal wie sehr sich die vom Standard des jeweils genutzten Betriebssystems unterscheiden mag.

Als Fan des Usenets und von Mailinglisten ist die Antwort für mich völlig klar:

ich mag keine HTML-E-Mails

Am liebsten ist mir bei allem die reine Textform, ich lese Blogs und Foren wenn irgend möglich im Akregator als RSS-Feed und in reiner Textform. Auf die entsprechenden Webseiten gehe ich nur, wenn es dafür einen Grund gibt, z.B. eine Umfrage oder weil kommentieren möchte.

HTML ist ein tolles Format für Webseiten, in E-Mails hat es meines Erachtens nichts zu suchen. Ich lasse in meinem KMail nicht zu, dass irgendwelche Inhalte nachgeladen werden, damit sind einige Newsletter sehr übersichtlich   Wenn ich einige Male so einen wenig informativen Newsletter bekommen habe, dann weiß ich, dass ich mit dem meine Zeit nicht vergeuden muss. Gute Newsletter lassen mich normalerweise wählen. Das klappt auch nicht immer, aber dann ist es ein weiterer Grund zur Abmeldung.

Textmails, die mit vernünftigen und korrekt eingestellten Mailprogrammen verschickt werden, sind

• wesentlich einfacher zu lesen,  denn sie haben meine Lieblingsschrift und die von mir bevorzugte Schriftgröße
• besser geeignet für mehrfaches Antworten, da Zitieren einwandfrei funktioniert
• schneiden die überflüssige Signatur beim Antworten ab
• brauchen weniger Platz, sei es beim Senden oder beim Aufbewahren
• sind unabhängig vom genutzten Programm immer lesbar

Tobias wird die Ergebnisse am Ende der Umfrage veröffentlichen. Angekündigt ist ein PDF, ich hoffe noch auf eine andere Form, denn

ich mag PDFs nicht als Webseitenersatz

Für mich sind PDFs ein klasse Format um

• Dokumente auszutauschen
• um auszudrucken

…aber für Informationen, die ich einfach erreichen möchte, sind PDFs meines Erachtens ungeeignet. Mich nervt, dass es im Web schon fast üblich ist, alles was man irgendwo mal in ein Text- oder Tabellendokument gepresst hat, als PDF zu veröffentlichen. Aus meiner Sicht ist HTML das Format, um einfach an Informationen zu kommen. Wenn es das noch als RSS-Feed für regelmäßige gelesene Seiten gibt – perfekt!

Vielleicht liegt es daran, dass

• ich kein Windows nutze
• ich ungeduldig bin
• ich gern möglichst viele Informationen in kurzer Zeit erreichen möchte
• ich eher Informatikerin als Designerin bin

Ich weiß es nicht, mich nerven PDFs, wenn ich Informationen suche, dann meist mit der Option -pdf. Noch schlimmer finde ich Links, die ungefragt und unangekündigt zu einem PDF-Download führen. Im Vergleich zu den meisten Webseiten sind PDF-Programme langsam, sei es der Acrobat Reader oder selbst mein KPDF, das ist zwar schneller als der Klotz von Adobe, aber immernoch langsam im Vergleich. Auch empfinde ich die Navigationsmöglichkeiten als umständlicher, das Format ist eben ein Druckformat, also meist umgekehrt propotional zu meinem Bildschirm, und und und…
Da ich jedoch immer häufiger über PDFs stolpere, da viele E-Mails leider als HTML-Mails verschickt werden, erhoffe ich mir durch die Umfrage, dass manche sich zumindest mal überlegen, warum und wo sie welches Format nutzen.

Also auf geht’s nehmt doch auch an der Umfrage teil, es sind wirklich nur wenige knappe Fragen…

Ich eignete mir BPM, Design Patterns, UML, J2EE, PHP, EAI, SOA, Webservices, Web2.0 und vieles mehr an. Vor lauter dazulernen habe ich völlig vergessen, dass es auch Anfänger gibt, denen das Programmieren nicht in die Wiege gelegt wurde. Unser Azubi bei miradlo hat mir da die Augen geöffnet. Unsere Welt dreht sich extrem schnell und wir dürfen nicht stehen bleiben. Dummerweise müssen die “Neuen” auch irgendwie hinterher kommen.

Da stellt sich nun die Frage, was sie alles lernen müssen und was wirklich nicht mehr benötigt wird.

Dinge die garantiert noch benötigt werden

Ich glaube beim Einstieg in die Programmierung sind die folgenden Themengebiete immer noch unumgänglich:

Boolesche Algebra

Das ist DIE Grundlage. Zum Einstieg sollten wirklich die grundlegenden Elemente erlernt werden. Im Internet findet sich genügend Dokumentation darüber; (siehe wikipedia oder IT-Wissen). In den Schulen sollte das auch unterrichtet werden. Leider sollte das nur unterrichtet werden. Bei manchen Schulen wird im ersten Lehrjahr alles mögliche unterrichtet, die benötigten mathematischen Grundlagen sind jedoch eher nicht gern gesehen…

Datentypen

Hier geht es weiter. Wenn man sich in die Programmierung einlernen will, sollte man sich mit den Standarddatentypen auskennen. (Siehe wikipedia) Es ist wichtig zu wissen, was folgende Datentypen bedeuten:

• bool
• int
• long
• double
• float
• String

Egal in welcher Programmiersprache. Irgendwie findet man diese elementaren Datentypen immer wieder.

Syntax der Programmierung

Wie in at-mix.de schön beschrieben, handelt es sich bei der Syntax um die Festlegung welche Zeichen miteinander kombiniert werden dürfen. Im letzten Jahr habe ich mehrmals Anfänger erlebt, die ihre Programme nach Form, anstatt nach Syntax erstellten. Wenn man das zuvor noch nicht gesehen hat, ist es schwer zu erklären. Vielleicht gelingt mir das mit einem Beispiel:

Die Aufgabe war eine Überprüfung von Eingabewerten durchzuführen:

// Some other codeif(a > 10){

// do something which looks like a very long string

}else{

// do something else which didn't fit in this line. So you have to look what to do...

}

Der zu lange Text sah nicht gut aus und so wurde er umgebrochen:

// Some other codeif(a > 10){

// do something which looks like a very long string

}else{

// do something else which didn't fit in this line.

So you have to look what to do...

}

Wenn ihr euch ein bisschen mit programmieren auskennt, wisst ihr warum das keine gute Idee ist

Der Code sieht zwar schöner aus, kann aber nicht mehr ausgeführt werden. Ein weiteres Beispiel, bei dem die Syntax nicht verstanden wurde, zeigt diese Zeile hier:

if(count($argv > 2)){}

Anstatt:

if(count($argv)  > 2){}

Na erkennt jeder den Unterschied?

Fazit

Im ersten Moment ist es irritierend, wenn man selbst diese Fehler lange nicht mehr macht. Doch es hat mir gezeigt, dass man vor lauter bunten Oberflächen, schnelleren Modellen und einem blinden Glauben an die Technik immernoch auf die Menschen achten muss, die diese Maschinen bedienen. Egal wie perfekt unsere Computer und Methoden werden, schlussendlich müssen wir sie bedienen und verstehen können, um wirklich nutzbringende Systeme erstellen zu können.

Schaut euch mal ein bisschen um und überprüft ob alle in eurem Umfeld noch mitkommen…

Optisch am Schönsten und der einzige, der bei mir in Standardeinstellung mit SVG klar kommt ist der Konqueror, spätestens auf Seiten mit Formularen mit mehreren Buttons sehen diese sehr viel besser aus, als mit anderen Browsern.

Für manches was Firefox nicht so gut kann, z.B. mehrere Nutzerprofile mit gespeicherten Passwörtern für eine Webseite verwalten, nehme ich den Seamonkey. Der ist nicht sehr hübsch, aber in solchen Fällen praktisch.

Tatsächlich nur noch zum Testen nehme ich die ies4linux. Leider funktioniert der IE7 seit einiger Zeit nicht mehr. Da ich den jedoch nur selten brauche, bietet sich dann sowieso ein weiterer Rechner an, der entweder auch ein Windows oder zumindest eine VMWare mit Windows hat. Inzwischen ebenfalls nur noch zum Testen nutze ich den Firefox in Version 2.0.0.14.

Firefox 3 als Standardbrowser

• Firefox auf 1920 bietet Platz für sichtbar rund 20 offene Tabs

Überwiegend arbeite ich mit Firefox 3, der im Gegensatz zu einigen 2-er Versionen, auch wieder stabil mit vielen Tabs (fast immer deutlich mehr als zwanzig, manchmal auch bis zu sechzig) zurecht kommt. Manches was verändert wurde, gefällt mir gut, z.B:

• die bereits erwähnte Stabilität
• Firefox 3 kann hier wieder im Hintergrund geöffnet werden, beim Feeds lesen, nutze ich das gern, um alles im Hintergrund schon mal zu öffnen, was ich noch anschauen möchte, ohne jedoch das Lesen der Feeds wegen jedes Links zu unterbrechen

ein paar Punkte mag ich dagegen eher nicht:

• Beispielsweise ließ sich bisher beim Lesezeichen speichern das Fenster mit den diversen Lesezeichen in der Größe verändern, das geht zumindest in der Standardeinstellung erst einmal nicht.
• Auch beim Theme musste ich ein bisschen suchen, bis ich eins fand, was mir optisch gefällt, zu meinem KDE-Theme, Keramik, passt und außerdem praktisch ist. Das ein oder andere Theme sieht zwar klasse aus, ist aber schwer lesbar, das mag ich nicht.
• Meiner Arbeitsweise mit sehr vielen Tabs, kam die vorherige Version Tabs solange nebeneinander anzuzeigen, bis die Faviconbreite erreicht ist, mehr entgegen, als die aktuelle Einstellung, die von einer größeren Mindestbreite pro Tab ausgeht.
• Sicherlich ließe sich noch manches anpassen, aber das kostet alles in allem doch immer ein, zwei Stunden Zeit und so wichtig ist es mir grad nicht.
• Standard ist inzwischen auch der Seiten- statt des Textzooms, das lässt sich ändern über:
  • about:config
  • In die Adressleiste about:config eingeben, anschließend die Eigenschaft browser.zoom.full auf false setzen.

Das hilft mir jedoch nicht, denn dann bräuchte ich ein weiteres Profil, um den Standardzoom zu testen, das will ich nicht, da mehrere Profile immer auch Pflegeaufwand bedeuten.

Aktualisierung zum Textzoom vom 23.7.

Über einen Kommentar bei Robert  zu STRG ++ kam der Hinweis auf eine gaaaaanz einfache Möglichkeit (Artikel gibts auch dazu): Im Menü Ansicht kann schlicht bei Text-Zoom ein Häkchen gemacht werden… Tja, wenn ich da mal reingeschaut hätte…

Im Zusammenhang mit den Vor- und Nachteilen von fixen und flexiblen Layouts, kam vor kurzem in einer Liste die Frage auf, warum jemand wohl seinen Browser tatsächlich auf 1920*1200 noch in voller Größe verwendet. Bei mir liegt das an meinen persönlichen Gewohnheiten. Ich bevorzuge Browserfenster, die den gesamten Bildschirm ausnutzen aus mehreren Gründen:

• um einen möglichst großen Teil meiner Tabs im Überblick zu behalten, sind 1920 Breite prima; wie im Bild zu sehen, klappt das dann mit etwa zwanzig davon, die nebenstehende Liste zeigt, dass es meist trotzdem noch mehr offene Tabs gibt
• meist mag ich auch Platz und Freiraum in einem Layout, nur falls die Breite des Texts bei einem Layout nicht beschränkt wird, z.B. bei Wikipedia, kommt es vor, dass ich zum Lesen längerer Texte, das Fenster auch mal verkleinere
• die Lesezeichen unterhalb der Adressleite, die ich sehr häufig brauche haben, sind so fast alle sichtbar
• meine Standardschriftgröße im Firefox ist etwas größer eingestellt, damit kann ich auch die, zur Zeit modernen, kleinen Schriften noch lesen. Die schon unter Windows kleinen Schriften, sind auf Linux noch kleiner und je nach installierten Schriftarten, werden sonst sehr viele Websites unlesbar. Ab und zu mal STRG und + nutzen stört mich nicht, aber ich möchte das nicht bei jedem Seitenaufruf tun müssen.
• da ich vier virtuelle Arbeitsflächen nutze
  • belegen Browser und Kontact nur eine Arbeitsfläche
  • eine weitere ist für die Konsole mit mehreren Fenstern und für meist zwei Konqueror im Dateimanagermodus
  • die dritte Arbeitsfläche nutze ich für die Bildbearbeitung, dort gibts auch kein Hintergrundbild auf dem Desktop
  • die vierte Arbeitsfläche wird von Quanta, Eclipse und OpenOffice.org belegt, je nachdem was ich gerade brauche

Mehr zu den Programmen, die ich ständig nutze gibts im Artikel Webentwicklung mit Linux und seinen Programmen. Für mich sind das meine optimalen Arbeitsbedingungen, wann immer mal einer meiner Jungs mal kurz an meinen Rechner geht, fällt mir auf, dass das nur für mich gilt. Bisher kenne ich noch niemand, der genau meine Einstellungen bevorzugt.  Die großen Unterschiede bei den Lieblingseinstellungen sind für mich auch der Grund, eher flexible Layouts zu bevorzugen, die jedem Einzelnen viel Spielraum lassen, doch dazu demnächst mehr…

Ärgern lohnt sich nicht und meckern ohne etwas zu tun, finde ich unnötig. Sinnvoller ist es, die jeweiligen Anwender zu informieren. Mit diesem Beitrag beginne ich, in loser Folge, eine kleine Serie zum Thema: Usenet, Mailinglisten, Foren und Blogkommentare.

Viele Diskussionen und Ärgernisse kommen dadurch zustande, dass langjährige Teilnehmer genervt sind, weil Anfänger sich nicht vorher über die Regeln informiert haben, bzw. die Regeln nicht einhalten.

Andere hochkochende Diskussionen entstehen weil Teilnehmer, die schon lange dabei sind zuviel von Anfängern erwarten.

Mein Ziel ist, beiden Seiten die Unterschiede und Regeln dieser Informationsmittel möglichst einfach zu erklären, um hoffentlich das ein oder andere Missverständnis zu beseitigen.

Mailinglisten

Wie man E-Mails verfassen sollte, insbesondere in Mailinglisten habe ich bereits unter Umgang mit E-Mails beschrieben. Bei Mailinglisten bekommt man die Mails der jeweiligen Liste direkt in den eigenen Account, genauso wie die anderen Nachrichten, die privat oder geschäftlich eingehen.

Abonniert man eine Mailingliste, so können, je nach Liste, schon mal mehrere hundert Mails an einem Tag eingehen. Daher bietet es sich an, für Mailinglisten nicht diesselbe Adresse zu nutzen, wie für private und geschäftliche Mails. Abmelden kann man sich bei solchen Listen meist durch ein E-Mail an den Listenserver. Die Adresse steht fast immer am Ende jeder Mail.

Usenet

Das Usenet ist ein weltweites Netz von Newsgruppen zu den unterschiedlichsten Themen und in verschiedenen Sprachen. Im Usenet werden Mails, die Postings oder Artikel genannt werden, auf Newsservern gespeichert und von Newsserver zu Newsserver verbreitet.

Die Nachrichten, die in die jeweiligen Gruppen gepostet werden, die man abonniert hat, bleiben weiterhin auf dem Newsserver. Normalerweise liest und schreibt man mittels eines Newsreaders, ein Programm, das die besonderen Anforderungen des Usenets berücksichtigt. Bei miradlo nutzen wir den KNode, ein KDE-Programm (KDE grafische Oberfläche für Linux).

Wer lieber offline lesen möchte, sollte sich einen Newsserver einrichten, genaueres dazu bezogen auf den “Hamster” für Windows, findet man auf Volker Gringmuths Seiten zum Hamster. Diese Software hat noch andere Vorteile und Einstellungsmöglichkeiten, die für Mails und News interessant sein könnten.

Im Gegensatz zu Mailinglisten füllt sich nicht der jeweilige Mail-Account. Stattdessen sorgt die jeweilige Software (KNode, Hamster…) dafür, dass nur die Artikel lokal vorhanden sind, die man haben möchte. Möchte man die Nachrichten lesen, so werden zunächst die Betreffzeilen angezeigt, erst wenn man entscheidet das einzelne Posting zu lesen, wird der gewünschte Artikel abgeholt (bzw. bei Newsservern wie dem Hamster angezeigt). Die jeweilige Software ist so einstellbar, dass die gelesenen Artikel anschließend gelöscht werden.

Weitere Informationen zum Usenet, gibt es bei einklich.net, den Seiten von Volker Gringmuth, er hat einen umfassenden Bereich speziell zum Usenet.

Foren

Die einzelnen thematischen Gruppen des Usenet werden auch Foren genannt. Der Begriff meint sonst jedoch eher die Webforen. Ein Webforum ist meist ebenso thematisch geordnet, wie das Usenet, es gibt Foren zu den verschiedensten Themen. Ein Forum liegt auf einem Webserver und ist unter einer Webadresse erreichbar, z.B. das deutsche Wordpressforum. Die Einstiegsseite eines Forums zeigt einen Überblick der einzelnen Kategorien. In diesen werden die zugehörigen Themen meist nach Datum sortiert angezeigt.

Wer eine Frage hat oder eine Information geben möchte, eröffnet ein Thema und die anderen Besucher antworten zu diesem Thema. Alle Einträge werden auf einer oder mehreren Seiten zu dem jeweiligen Thema in chronologischer Reihenfolge angezeigt. Meist muss man sich zunächst registrieren, um schreiben zu dürfen, damit werden Spameinträge vermieden.

Die Struktur und die möglichen, technischen Einstellungen von Foren sind so angelegt, dass die Besucher nicht selbst dafür sorgen müssen, dass die Beiträge zu einem Thema an der richtigen Stelle erscheinen. Die technischen Einstellungen sorgen dafür, dass die einzelnen Beiträge optisch gleich aufgebaut sind. Daher sind Foren auch für ungeübte Anwender schnell nutzbar, sie benötigen kaum Vorwissen, wie bei Mailinglisten oder im Usenet.

Blogs

Was Blogs sind, wissen die meisten Leser wahrscheinlich bereits, denn ihr lest ja grad ein Blog. Wer es nicht so genau weiß, findet Begriffserklärungen im Glossar Blogs. Ein Blog wird einerseits von einem oder mehreren Autoren geschrieben, andererseits haben Besucher die Möglichkeit dort zu kommentieren (jedenfalls meistens). Manche Blogs leben eher von den Beiträgen der Autoren und haben nur einige Kommentare. Andere Blogs leben vor allem durch die Kommentare, es gibt Blogs, in denen zu einem Kurzbeitrag mit wenigen Zeilen regelmäßig Gespräche mit über dreißig Kommentaren entstehen.

Ähnlich wie in Foren braucht ihr für ein Blog keine besondere Software, lesen klappt mit jedem Browser. Um jedoch beispielsweise RSS-Feeds zu abonnieren bietet sich Software an. Sei es es eine Webapplikation, wie die diversen Web-Feedreader, sei eine Browsererweiterung, um gezielt Feeds zu lesen, oder ein Programm wie Akregator, mein Liebling um zu lesen. Der Akregator lässt sich so einstellen, dass alle Beiträge unterschiedlichster Blogs identisch aussehen, in meiner Lieblingsschrift und -größe, ich lese so am Liebsten.

Im nächsten Teil geht es um den Umgangston und die Netiquette in den verschiedenen Informationsquellen Usenet, Mailinglisten, Foren und Blogs.

Thomas hatte sich die beiden Familien angeschaut…

…und sich den Betrieb genauer betrachtet.

Im Fall von Hans, Karl und Orlando kann man nicht von einem klassischen Betrieb sprechen. Die drei sind Entwickler und Betreiber in Personalunion. Bei der zweiten Familie ist die Entwicklung und der Betrieb voneinander getrennt. Die Entwicklung erstellt ein Programm und übergibt es an den Betrieb. Eine vernünftige Dokumentation, wie das jeweilige Programm zu bedienen und warten ist, gibt es nicht. Wenn ein Fehler auftritt, handelt der Betrieb intuitiv. Wenn das nicht klappt, wird der Incident an die Entwickler übergeben.
Thomas will bei der Neugestaltung der gemeinsamen IT die beiden Betriebe zusammenlegen und einen möglichst stabilen Betrieb aufbauen.
Seine Überlegungen:
„Wenn ich den Betrieb permanent mit in das Projekt einbinde wird die Stakeholderliste unnötig groß. Jeder will mitreden und an eine Weiterentwicklung der Software ist kaum zu denken.“
„Wenn ich den Betrieb erst kurz vor der Abnahme einbinde, ist die Gefahr extrem hoch, dass die erstellte Software nicht betreibbar ist.“
Was für ein Dilemma!
Nach einigem hin- und her entschied sich Thomas für folgendes Vorgehen:
„Ich lass den Betrieb bei der Anforderungsanalyse all seine Anforderungen, die zu diesem Zeitpunkt bekannt sind, formulieren.“
Bekannte Anforderungen können sein:

• Bekannte Betriebssysteme, die von den Mitarbeitern verwaltet werden können
• Monitor-Elemente, die gesetzt sind und die eingebunden werden müssen
• Angaben, wie Projekte dokumentiert und Betriebshandbücher aufgebaut sein müssen
• Angaben, wie Artefakte an den Betrieb übergeben werden müssen
• …

„Zusammen mit den Anforderungen der Kunden erstelle ich die Architektur und das Detailkonzept. Das Detailkonzept wird vom Betrieb überprüft und anhand der detaillierten Informationen kann der Betrieb genauer angeben, was er wirklich braucht.“
„Danach lasse ich den Betrieb erst einmal wieder in Ruhe.“

Zu diesem Zeitpunkt werden im…

Projekt vor allem die neuen Komponenten

erstellt.

„Wenn ein testbares System vorhanden ist, muss der Betrieb wieder ran und kontrollieren ob alles für ihn in Ordnung ist.“
Zu testen sind hier

• Stabilität
• Auswirkungen auf andere Komponenten
• Installierbarkeit
• Konfigurierbarkeit
• Performance
• …

„Weiterhin werde ich die Betriebsmitarbeiter während dieser Tests schulen.“
Hier ist die Gefahr hoch, dass die Zeit für die Schulung nicht ausreicht, um die Mitarbeiter wirklich für den Betrieb fit zu machen.
Und da haben wir auch wieder das Dilemma. Entweder hat man über eine lange Zeit viele Mitarbeiter blockiert und dafür aber später gut ausgebildete Kollegen oder man kommt im Projekt schneller vorwärts und fährt das Risiko, dass sich die Betriebsübergabe verschiebt.
Ich selbst glaube, dass es hier keine ideale Lösung gibt.

Man muss sich für einen Mittelweg entscheiden. Wichtig ist jedoch, dass der Betrieb von Anfang an ausreichend informiert wird.