Warum machen wir es nicht wie Toyota?

Gunter Dueck schrieb folgendes in seiner Artikelreihe im Informatikspektrum:

Weil wir managen, aber nicht unternehmen. Weil wir nicht glauben, dass wir alles gleichzeitig schaffen. Weil wir deshalb immer versuchen Toyota zu immitieren, aber diese Aufgabe schreiend unlogisch Schritt für Schritt angehen. [...] Niemand versteht, dass der Toyota-Weg aus logischen Gründen so begonnen werden muss: Jeden Tag ein bisschen weniger Verschwendung, jeden Tag ein bisschen mehr Ordnung, ein bisschen weniger Störungen[...]

In Verbindung mit agiler Softwareentwicklung will ich daraus die These ableiten, dass der Einsatz einer oder zwei Techniken der agilen SWE noch lange nicht zu Ziel führen. Ich habe Unittest, aber kein Continuous Integration, kein Codereview usw. 

Der Satz "eins nach dem anderen" habe ich schon oft gehört. Kann man sagen, wenn man 

etwas wirklich erreichen will, dann sollte man damit anfangen, wichtige Dinge parallel zu initiieren, da sie ihre Wirkung (Verbesserung, ...) erst im Zusammenspiel entwickeln? 

weitere Features des super Assistenten

Viele Vorgänge verlangen ein bestimmtes Vorgehen, also eine menge von Aktionen. Nehmen wir an, man plant eine Geburstagsfeier, da gibt es eine Menge Arbeitsschritte, die bei jeder Partyplanung vorkommen. Der intelligente PA könnte mich doch da unterstützen. Er kennt mein Adressbuch und damit auch meine möglichen Gäste, nämlich meine Freunde, Familie. D.h., die Aktion "Gäste einladen" würde eine Nachricht an alle Gäste schicken. Der PA schlägt mögliche Kanditaten schon vor. Natürlich weiß er, dass noch andere Punkte notwendig sind, z.B. einen Ort suchen, wie sieht es mit der Bewirtung aus, ...

Der PA muss also Checklisten abarbeiten können und mir die nächsten notwendigen Schritte vorschlagen.

Idee: der persönliche Assistent

Ja, es gibt ihn schon, den PDA. Dort kann ich im Kalender schauen, was ich noch machen muss, wann ich einen Termin habe usw.
Mein Problem ist, ich vergesse zu viel und wenn ich mir es aufschreibe, vergesse ich den Zettel zu lesen. Alles irgendwie verzwickt...
Hier mal paar Idee zu einem wirklich coolen PDA.

Gegeben sei ein PDA ähnliches Gerät mit Internetzugang und GPS. Ich befinde mich in einem Einkaufszenter. Dieser Ort ist für mich als bekannter Ort markiert und es ist bekannt, welche für mich wichtige Läden sich hier befinden. Ich schalte das Gerät an und wähle "things to do". Per GPS wird festgestellt, ich befinde mich in der Sachsenallee. Als nächstes werden meine Aufgaben durchsucht und alle für den jetztigen Zeitpunkt relevanten Aufgaben angezeigt. Das kann zum Beispiel sein, "im Kaufland nach Keksen mit Schoko Banane Geschmack suchen", "Haargel" aus dem DM-Markt. Es werden mir also alle die Aufgaben/Notizen angezeigt, die für mich gerade wichtig sein. Gerade wichtig leitet sich in diesem Szenario aus meinem Aufenthaltsort ab.

Ein zweites Szenario. Bevor ich früh aus dem Haus gehe, drücke ich auf den Knopf "Things to remeber". Es wird in meinen Terminkalender geschaut, was heute alles so ansteht und mit den Notizen/Aufgabe abgeglichen, die damit zusammenhängen. Ich habe einem Freund etwas aus dem Urlaub mitgebracht. Heute treffe ich mich mit ihm, natürlich habe ich im Reallife das Geschenk vergessen mitzunehmen. Mein PDA hätte eine Verbindung herstellen müssen und zwar zwischen "Aufgabe: Geschenk an Rüdi überreichen" und "Termin: Rüdi treffen".

Alle beiden Szenarien verlangen natürlich, dass man seine Termine und Aufgaben/Notizen immer erfasst.

Getting things done verfolgt eine ähnliche Strategie, Kontext abhängig werden die Aufgaben abgelegt.

Der Kontext leitet sich aus dem ab, wo ich bin, was ich mache, was ich vorhabe.

Mal sehen, was man mit "rememberthemilk.com" da machen kann. Termin kann man ja im Google-Calendar machen....

Modell für Dokumentation

Bis jetzt wurden 3 Elemente des Modells betrachtet. Aber was ist mit "Was wird dokumentiert"?

Damit sind wir bei 4 Fragen:
Wer liest und wer schreibt die Dokumentation?

Wo ist die Dokumentation hinterlegt?

Wie wird dokumentiert? 

Was wird dokumentiert?

Als nächstes sollten die einzelnen Frage erörtert werden. Es lohnt sich, sie in eine Reihenfolge zu bringen:

Was?

Wer?

Wie?

Wo?

6. Treffen AK Nichtfunktionale Anforderungen (NFR)

Gestern war das 6. Treffen des AK NFR in München bei Siemens. Es ging um Meßbarkeit und Abhängigkeiten zwischn NFR.  Ich glaube, ich auch zum ersten Mal einen echten Softwarearchitekt getroffen. Er hat einen kleinen Vortrag über seine Arbeit bzw. die Probleme gehalten, welche im Zusammenhang mit NFR und Archtitektur auftreten. Es ist nämlich so, dass viele NFR erst durch bestimmte Architekturmuster (Lösungen) zum Vorschein kommen. Ein weiterer wichtiger Fakt ist, dass es NFRs gibt, welche aus der Funktionalität des System entstehen und welche, die aus der Entwicklung des Systems entstehen (z.B. Wartbarkeit, Testbarkeit). Diese NFR einfach zu benennen reicht auch nicht aus. Es ist besser Szenarien zu beschreiben. Die Aussage "unser System soll wartbar sein", ist sehr schwammig formuliert. Hier sollte besser ein Wartbarkeitsszenario beschrieben werden, welches Auskunft über die konkret erwarteten Aktionen gibt. Es durchaus oft unterschätzter Fakt, ist die Traceabillity von Anforderungen und ihren resultierenden Archtitekturentscheidungen.

Zusammenfassung:

- Man sollte Anforderungen (auch NFRs) mit Szenarien beschreiben!

- Die Verfolgbarkeit von Anforderungen in die Architektur und auch Code sollte gegeben sein!

- Ein Architekt kann bei der Findung von NFRs sehr hilfreich sein, da Architekturlösungen zu bestimmten NFRs führen!

- Verschiede Perspektiven beachten, nicht nur den Anwender sondern auch den Entwickler.

Informatiker brauchen Modelle

Ich denke, jeder ist sich darüber bewusst. Demanch sollten wir jede Analyse eines Problemes mit der Erstellung eines Modells beginnen, oder?
Im Rahmen der Vorlesung Hardware/Software-Codesign wurden Modelle für den HS-Codesign Prozess vorgestellt. Auf den ersten Blick fragte ich mich, was mach ich damit. Genauer betrachtet, zeigte sich, dass die Modelle die wesentlichen Eigenschaften/Objekte und deren Beziehungen abbilden, bzw. veranschaulichen.

So hier nun mein Problem: Wie dokumentiere ich Software am besten? Wie bereits erwähnt, wie benötigen ein Modell.

Welche Elemente gibt es in dieser Welt?
1. Sichten: wer liest und wer schreibt die Dokumentation
2. Orte: wo ist die Dokumentation hinterlegt
3. Arten: in welcher Form liegt die Dokumentation vor

zu 1. Objekte der Klasse "Sichten"
Hier kann man verschiedene Rollen betrachten:
- Entwickler, der das System schreibt
- Entwickler, der das System weiterentwickeln und warten soll (also ein neues Teammitglied)
- Entwickler, der das System nutzt (API)
- Tester Entwicklung (Teilmenge von "Entwickler, der das System nutzt") (auf API Ebene)
- Tester Blackbox (auf Anwendungsebene)

zu 2. Objekte der Klasse "Ort"
- Quellcode
- Anforderungsspezifikation
- Testfallspezifikation

zu 3. Objekte der Klasse "Art"
- Prosa
- Javadoc
- Namenskonventionen
- Testfall

Nun gilt es, diese Elemente in Beziehung zu setzten.

Idee: Anforderungsspezifikation 1

Anforderungen liegen meist als Text und in Prosaform vor. Unter Annahme dieser 2 Gegebenheiten reicht ein einfacher Texteditor dazu aus, die Anforderungen aufzunehmen bzw. zu formulieren.
Wir wissen, dass im Laufe des Softwareentwicklungsprozesses Artefakte entstehen, welche eine Beziehung zu den spezifizierten Anforderungen besitzen. Diese Artefakte besitzen natürlich auch untereinander Beziehungen. In welcher Form (Text, Binär) diese Artefakte existieren sei erstmal nicht von Bedeutung.

In der Vorlesung "Entwurf verteilter System" fiel der Begriff Hypertext und der Hinweis, dass es sich dabei um ein Konzept für die Organisation von Wissen bzw. Informationen handelt. Wenn wir annehmen Wissen und Information ist Artefakte, dann bietet sich die Idee von Hypertext (Hypermedia) doch an, auch im Softwareentwicklungsprozess einzusetzen. D.h., es werden die Artefakte logisch verknüpft und man kann schnell die Beziehungen zwischen ihnen herausfinden. Stichwort Tracebillity!