Mittwoch, Oktober 25, 2006

Vorprojekt-Phase: Das Kunden-Orakel und die Hellseherei

"Guten Tag, mein Name ist Kluge, Martina Kluge, ich bin Geschäftsführerin der Firma BrainTeaser, man hat sie mir empfohlen."

Da steht sie, die liebe Frau Kluge. Ihre Präsenz erfüllt das ganze Büro, obwohl sie noch gar nicht eingetreten ist. Große, intelligente Augen blicken Sie neugierig an. Ihr Freund Heinrich, von ihm ist die Empfehlung, hat den Besuch schon vorgewarnt. Sie sei ein Wirbelwind, sagte er Ihnen am Telefon -- und er klang dabei amüsiert. Nun denn ...

"Bleiben Sie sitzen", sagt Frau Kluge freundlich, lächelt hinreißend und löst sich aus der Tür. Ihre Augen haben offenbar einen neuen Fixpunkt gefunden, auf den Sie regelrecht zustürzt. Sie strebt auf das voll beschriebene Whiteboard mit den Projektplanungen der nächsten sechs Monate zu. Das Ergebnis zweier Nächte Planungsarbeit mit Ihrem Kollegen Gerd. Das Zeug ist wichtig.

"Darf ich?"

Eigentlich nicht, eigentlich wollten Sie gerade "Nein" sagen -- aber es ist zu spät. Es kommt Ihnen vor, als habe Frau Kluge die ganze Planung mit nur einem einzigen Wischer vernichtet. Hoffentlich hat Gerd ein gutes Gedächtnis, seufzen Sie in sich hinein und haben den Gedanken längst aufgegeben sich vorzustellen. Wozu auch? Links neben Ihrer Bürotür ist das Schildchen mit Ihrem Namen nicht zu übersehen. Frau Kluge wird zweifellos wissen, wer Sie sind.

"Ich brauche sowas hier."

Ein paar flotte Striche. Ein Kästchen hier, eines da, ein Strich dazwischen.

"Wir wollen für unsere Kunden einen neuen Dienst anbieten. Über's Internet. Sie verstehen?! Ein neues Portal, ein neues Medium. Hier, da", Kluges Finger zeigt auf den einen Kasten, "ist unsere Datenbank mit allen Kundendaten. Name, Adresse, Sie wissen schon. Da drüben", ihr Finger wandert rüber, "da sollen die Applikationen andere Dienste aus unserem Unternehmen mit den Kundendaten auf eine ganz neue Art verknüpfen." Kluges Augen leuchten.

Für die nächste halbe Stunde ist Frau Kluge nicht zu bremsen. Obwohl Sie den Verlust Ihrer Planung noch nicht ganz verwunden haben, haben Sie geistesgegenwärtig nach Bleistift und Papier gegriffen und machen sich Notizen. Sie hätten doch einen Stenographie-Kurs machen sollen. Mehr als verständnisvolles Zunicken gesteht Ihnen Frau Kluge nicht zu. Sie redet und redet.

Am Ende fragt Sie Frau Kluge mit ihrem hinreißenden Lächeln:

"Können Sie uns die Software dazu entwickeln?"

Pause. Ruhe. Stille im Büro. Sie dürfen zum ersten Mal etwas sagen! Wie wollen Sie dieser Frau einen Wunsch abschlagen? Dieses Lächeln! Viel besser noch: Das ganze Vorhaben klingt gigantisch. Eine echte Herausforderung. So hört es sich jedenfalls an. Sie haben Fragen, 1000 Fragen. Eigentlich haben Sie fast gar nichts verstanden. Es klingt aber irgendwie toll.

"Ja? Bauen Sie uns das?"

Da Sie ein guter Mensch sind, ein guter Software Engineer dazu, sind Sie nett und aufrichtig zu Frau Kluge. Sie drücken Ihre Begeisterung aus, fassen in wenigen Worten zusammen, was Sie glauben verstanden zu haben. Ja, das klingt interessant, sehr interessant sogar. "Wir sollten das unbedingt in Angriff nehmen", hören Sie sich sagen, "die Idee klingt sehr überzeugend." Und dann gestehen Sie ihr, dass noch viel Arbeit vor Ihnen beiden liegt. Sie müssen erst verstehen lernen, was sie will, in welcher Welt sie lebt, welchen Zweck genau das Produkt verfolgt etc. Und dann, wenn das verstanden ist, dann können Sie ihr verraten, wie Sie weiter machen wollen. Wie ein Projekt dazu aussehen könnte. Ob eine Vorstudie erforderlich ist. Oder Prototyping. Oder oder.

Frau Kluge freut sich. Sie scheint kein "Ja" als Antwort erwartet zu haben. Sie freue sich über die weitere Zusammenarbeit. Sie scheint sich der Komplexität des Vorhabens vollkommen bewußt zu sein, wenn Sie sie so reden hören. Und natürlich müsse man jetzt in kleinen Schritten vorgehen. Sie wisse, ehrlich gesagt, ja auch noch nicht im Detail, wie das alles funktionieren solle. Aber die Idee, davon sei sie überzeugt.

Kurz darauf sitzen Sie wieder allein in Ihrem Büro. Sie rufen als erstes Gerd an. Er soll versuchen, die Planungen zu rekonstruieren. Dann trommeln Sie zwei ihrer besten Leute zusammen für ein Treffen nach dem Mittagessen. Sie wollen von dem Treffen mit Frau Kluge berichten und das weitere Vorgehen besprechen.

14:08 Uhr. Sie haben Niklas und Kristina von Kluges Monolog berichtet -- und dazu selber eine Dreiviertelstunde gebraucht. Beide sind beeindruckt. Ein interessantes Projekt, das sich da anbahnen könnte.

"Wie sollen wir vorgehen Kristina? Was glaubst Du?", fragen Sie.

"Wir haben alle Fragen über Fragen. Aber ich glaube, es ist nicht sehr geschickt, Frau Kluge mit unseren Fragen zu bombardieren."

"Das denke ich auch.", sagt Niklas, "Unsere Fragen resultieren ja aus einer gewissen Unkenntnis heraus. Es ist nur allzu menschlich, sich selbst aus vagen, unscharfen Angaben heraus ein erstes Bild zu machen. Diese Vorstellung, die wir uns jetzt machen, kann vollkommen falsch sein und an Frau Kluges Problemwelt vorbeizielen."

Kristina: "Wir müssen Wissen fließen lassen, von Frau Kluge zu uns. Das wird am leichtesten gelingen, wenn wir es schaffen, einen Dialog aufzubauen."

Niklas: "Ja, ein Beispiel wäre, unser erstes Verständnis in Szenarien zu beschreiben und die Szenarien aus verschiedenen Rollen zu beleuchten. Mit dem System sollen die Kunden arbeiten, Administratoren, aber auch Autoren und Redakteure in Frau Kluges Firma werden benötigt, um das System zu pflegen und mit Informationen zu füttern. So sieht das jedenfalls im Moment für mich aus."

Sie: "Wir würden immerhin merken, ob wir richtige Annahmen machen -- und worüber sich Frau Kluge bereits Gedanken gemacht hat."

Kristina: "Ich glaube auch, dass das eine gute Idee ist. Wir könnten das ergänzen um Papier-Prototypen, die das System konzeptionell abbilden und helfen, ein Szenario anzustoßen."

Sie: "Mir gefällt solch ein Ansatz. Gibt es noch weitere Ideen und Möglichkeiten, einen Dialog über das zu entwickelnde System in Gang zu setzen?"

Kristina: "Ich hatte neulich erst ein Buch in den Händen, das systematisch eine Fülle von 'Dialog-Techniken' zusammengetragen hat. Alles Techniken um in solchen frühen Phasen zu erfassen, was irgendwann mal in ein Anforderungsdokument münden wird. Ich kann das gerne mal nachlesen, vielleicht eine Vorauswahl machen und Euch vorstellen."

Sie: "Das klingt gut. Lass uns das so machen."

Niklas: "Sag mal, Du hast doch Frau Kluge bestimmt eine Telefonnummer abgeluchst, eine Kontaktperson, die auch viel über Kluges Visionen weiß und vielleicht mehr auf der technischen Seite steht. Die könnte ich ja mal kontaktieren."

Sie schmunzeln in sich hinein: "Ja, ich habe in der Tat eine Nummer, ein IT-Mensch aus Frau Kluges Firma. Das wäre sehr schön, wenn Du Dich telefonisch mit ihm in Verbindung setzen könntest."

Kristina: "Wann sollen wir uns wieder treffen? Ich könnte meinen Teil bis morgen gegen 16 Uhr erledigt haben. Ich habe zwar noch ein paar andere Dinge zu tun, aber das ließe sich einbauen."

Sie: "Schön. Wie sieht es denn überhaupt mit eurer Arbeitsbelastung aus? Ihr seid beide in laufenden Projekten involviert. Der Auftrag von Frau Kluge scheint Potential zu haben und könnte uns viel Geld bringen. Aber wir dürfen die aktuellen Projekte nicht gefährden. Könnt ihr euch darum auch kümmern, damit wir euch vernünftig einplanen? Können wir das morgen um 17 Uhr miteinander besprechen? Um 18 Uhr sind wir spätestens fertig."

Niklas: "Ok, machen wir. Ich werde bis dahin sicher auch mit dem IT-Menschen gesprochen haben."

---

Ein Tipp noch: Kristina wird ein Kapitel lesen aus dem Buch "Requirements-Engineering und Management" von Chris Rupp aus dem Hanser-Verlag, 2007, 4. Auflage. Und zwar genau das Kapitel, das auf der Webseite zum Buch als Leseprobe angeboten wird ;-)

Freitag, Oktober 20, 2006

Bucheinblicke

Manche Ideen taugen als Produktidee und lassen sich mit viel Glück erfolgreich auf den Markt bringen. Das "Web 2.0" ist voll mit solchen Versuchen. Andere Ideen schrammen an einer Grenze, die rechtlich vermutlich nicht ganz unbedenklich ist -- was aber auch konstruktiv als Kunstform umgemünzt werden kann.

Ein Beispiel: Amazon bietet eine "Search Inside"-Funktion bei ausgewählten Büchern in ihrem Verkaufsportal an. Sie geben einen Suchbegriff ein, und Ihnen wird eine Liste geliefert mit allen Seiten, die diesen Begriff enthalten. Klicken Sie nun eine Seite an, wird Ihnen die Buchseite als Bild vollständig angezeigt.

Es bedarf keiner großen Mühe, um sich mittels geschickter Suchabfragen den Einblick in ein ganzes Buch zu verschaffen. Hatten Sie die Idee auch schon? Die Idee liegt derart provokant nahe, auch der nächste Schritt, diesen Vorgang mit einem Programm zu automatisieren, dass sich eine Frage aufdrängt: Wie verträgt sich eine solche, eigentlich sehr kundenorientierte Funktion mit Urheberrechten?

Ich will darauf keine Antwort geben. Originell finde ich jedoch den Ansatz, es als Kunstprojekt zu inszenieren.

P.S.: Amazon hat die "Search Inside"-Funktion mittlerweile eingeschränkt.

Mittwoch, Oktober 11, 2006

Prozessor mit 10 Fingern

Computer rechnen mit Einsen und Nullen, nicht wahr?! Meistens, aber nicht immer. Ich kann mich dunkel erinnern, mal von einem Rechner gelesen zu haben, einem Rechner aus grauer Vorzeit, der mit einem höherwertigen Zahlensystem rechnete. Im 6er-, 10er- oder 12er-System, ich weiß es nicht mehr. Doch jetzt kann ich das Kramen in den grauen Zellen sein lassen. Es wird ihn wieder geben, den Computer mit "10 Fingern". (Für den Hinweis vielen Dank an AnA.) IBM hat erste Details verraten über den kommenden Power6-Prozessor. 5GHz und eine dezimale Fließkommaeinheit (Floating Point Unit, FPU) sollen den Prozessor auszeichnen, so vermeldet bei golem.

Die Verwendung des 10er-Systems lasse den Prozessor schneller rechnen, so heißt es in der Meldung. Aber warum? Details sind in der Meldung nicht zu finden, auch nicht auf den verlinkten Seiten. Meine Vermutung ist, dass die FPU auf Schaltungsebene mit mehrwertigen Logiken arbeitet, auf der die Zahlen durch verschiedene Spannungslevel abgebildet werden. In absehbarer Zeit wird das Geheimnis gelüftet werden.

Montag, Oktober 09, 2006

RFID

Eigentlich sind die kleinen Funk-Chips kalter Kaffee -- eine fast schon uralte Idee, die jedem Nachrichten-Techniker wie selbstverständlich vorkommen mag. Im Gespräch sind diese Chips schon seit vielen, vielen Jahren. Doch allmählich scheint ein Markt für ihren Einsatz zu entstehen. Es sieht so aus, als würde RFID (Radio Frequency Identification) Wirklichkeit werden. Die Marktprognosen sehen bestens aus (heise-Meldung).

Vor kurzem bin ich durch eine andere heise-Meldung auf eine Informationsbroschüre zu RFID gestoßen. Herausgegeben hat sie das Forum InformatikerInnen für Frieden und gesellschaftliche Verantwortung e.V. (FIfF). Die Broschüre ist angenehm zu lesen. Sie beschäftigt sich unter anderem mit der Technik, Anwendungen von RFID, Risiken & Ängsten und kryptographischen Methoden. Eine ausführliche Liste mit Links bietet interessierten Lesern Einstiegspunkte. (Übrigens finden Sie auf der Webseite von FIfF auch eine ähnlich aufgebaute Broschüre zur elektronischen Gesundheitskarte.)

Ich frage mich, ob man mit diesen Funk-Chips etwas machen kann, worauf bislang noch keiner gekommen ist. Hm ...

Mittwoch, Oktober 04, 2006

Idee zum WebCaching

Immer wieder treibt mich das Thema "HTTP-Caching" um -- ich nenne es auch gerne WebCaching, auch wenn der Begriff es nicht ganz trifft. Caching ist ein wichtiges Thema in vielen Bereichen, in denen es um Performanz geht. Prozessorarchitekturen, Datenbanken und webbasierte Systeme etc. nutzen Caching sozusagen als Turbolader. Vermeintlich langsame Systeme können durch geschickte Caching-Strategien rasend schnell werden, indem sie die von ihnen erwarteten Reaktionen vorhalten.

Kurz etwas Hintergrund zu HTTP und HTTP-basiertem Caching, bevor ich zu meiner Caching-Idee komme.

HTTP ist ein Anfrage/Antwort-Protokoll. Der Client, z.B. Sie über Ihren Webbrowser, schickt eine HTTP-Anfrage (request) an einen Webserver, und der Server beantwortet die Anfrage mit einer HTTP-Rückmeldung, einem HTTP-Reply. Es ist immer dasselbe. Ausschließlich der Client schickt Requests an den Server; und der Server reagiert nur auf diese Anfragen mit einem Reply. Das Prinzip ist sehr einfach.

Wenn Sie eine normale Webseite aufrufen, wird in aller Regel eine Vielzahl von HTTP-Requests an den Webserver geschickt. All das regelt der Browser automatisch für Sie und hängt ab von den Inhalten einer Webseite (Bilder, CSS etc.), die noch nachzuladen sind. Wenn Sie dieses Spielchen einmal verfolgen wollen, es gibt mit LiveHTTPHeaders eine nette Erweiterung für den Firefox, die Sie installieren können.

Caching funktioniert nur, wenn sich zwischen Client und Server eine oder mehrere Cache-Einheiten befinden, die den ganzen HTTP-Traffic mit abbekommen und gegebenenfalls HTTP-Requests "abfangen" und statt des Servers ein Reply an den Client zurückgeben. Der Server ist damit entlastet.

Bevor der Cache einen HTTP-Request abfängt, muss er wissen, für welche Requests er die Reply übernehmen darf. Dazu markiert der Server beim Versand einer Reply den HTTP-Header mit einem Hinweis, dass ein Cache die Nachricht für eine gewisse Zeit vorhalten darf. Der mitlesende Cache merkt sich das und antwortet zukünftig auf gleiche Anfragen in Stellvertretung für den Server.

Um es ein wenig konkreter zu machen: Sie dürfen sich einen Request wie eine Anfrage vorstellen die lautet "Gib mir den Inhalt der Webseite www.xyz.de/test.html", woraufhin der Webserver www.xyz.de bzw. ein zwischengeschalteter Cache den Inhalt test.html zurück liefert.

Bei diesem Ansatz gibt es ein Problem: Ändert sich test.html beim Webserver und ist die Caching-Zeit beim Cache noch nicht abgelaufen, liefert der Cache die "veraltete" Seite zurück -- und der Server kann den "neuen" Inhalt nicht ausliefern, da der Cache den HTTP-Request nicht durchläßt.

Irgendwie muss also der Cache vom Server über die Ungültigkeit von test.html im Cache informiert werden. Dazu gibt es jedoch kein standardisiertes Protokoll. Wenn Inhalte vor Ihrer Zeit im Cache ungültig werden, Pech gehabt. Wenn man auf Lösungen Marke Eigenbau verzichten möchte, dann muss man sich etwas einfallen lassen, was vollkommen verträglich ist mit der Standard-Webtechnologie.

Meine Idee dazu:

Der Client fragt test.html beim Server an. Der Server liefert zwar test.html mit einem Reply aus, jedoch enthält test.html nicht den eigentlichen Seiteninhalt, sondern ein JavaScript-Programm. Dieses Programm weist den Client an (sofern JavaScript ausgeführt werden darf), eine Seite test-001.html per Request vom Server anzufragen und den Inhalt von test-001.html zum Inhalt von test.html zu machen (Stichwort DOM, Document Object Model). Dieser Inhaltstausch ist wichtig, damit die Seite auch unter test.html per Bookmark gemerkt werden kann. Der Server gibt also test.html nicht zum Cachen frei, jedoch test-001.html (z.B. für eine Stunde).

Jede neue Anfrage nach test.html belastet zwar den Server damit, eine kurze Antwort auszuliefern, die das JavaScript-Programm enthält, aber die Folgeanfrage nach test-001.html wird vom Cache beantwortet. Dem Server wird damit der wesentliche Traffic vom Leib gehalten.

Ändert sich test.html beim Server, wird eine neue Version test-002.html generiert. Erreicht nun den Server ein neuer HTTP-Request für test.html, liefert er test.html mit einem leicht geänderten JavaScript-Programm aus, das nun nicht mehr zum Nachladen von test-001.html auffordert, sondern nach test-002.html verlangt. Damit wird der Cache "umgangen", der Server kann die aktuelle test-002.html-Seite ausliefern und fürs Caching (z.B. wieder für eine Stunde) freigeben.

Haben Sie die Idee im Kern verstanden?

Ich kann mir gut vorstellen nicht der Erste zu sein, der diese Idee hat. Wenn Sie eine entsprechende Seite finden, ich würde mich freuen davon zu erfahren. Vielleicht haben Sie noch andere interessante Ideen? Sicher gibt es noch andere Varianten zum Caching.