projekte - Einträge für April 2008

  • April, 2008
  • Fish & Chips Incident-Process

    Ein anderer Titel für diesen Blog ist: „How to get a cup of coffee for free, learn about Incident management and understand the need for a security concept.“ Doch dieser Titel ist etwas lange... Ich war mal wieder „dienstlich“ in England unterwegs. Eigentlich sollte ich für meine Firma herausfinden, was man dort alles besser machen kann. Nun zumindest für das Leben habe ich etwas gelernt. Trotz, oder wegen, meines Übergewichts kann ich nicht darauf verzichten Fish & Chips zu kaufen. Natürlich mit Salt and Vinegar. Also, ich gehe in den nächsten Futterladen und finde vier Frauen und einen Mann vor. Die Personen möchte ich mit Fischfrau 1, Fischfrau 2, Fischfrau 3, Cheffischfrau und John den Fischgriller bezeichnen. Mich selbst nenne ich Kunde 1. Fischfrau 1: "Hello" Kunde 1: "Hello, one fish and chips please." Fischfrau 1: "John, one fish and chips please!" John stürzt sich an die Fritiermaschine und der Fisch wird generiert. Fischfrau 1: "3,50 please." Kunde reicht eine zwanzig-Pfund-Note. Fischfrau 1 benutzt die Registrierkasse und liefert 6,50 Pfund zurück. Außerdem schließt sie die Kasse. Kunde 1 wundert sich und erwähnt, dass er gerne noch zehn Pfund change mehr hätte. Immerhin bedeuten zehn Pfund später ungefähr drei Biere, die Kunde 1 benötigt um diesen Blog formulieren zu können.

    Juchu! Wir haben einen Incident!

    Fischfrau 1 erkennt, dass sie einen Fehler gemacht hat. Sie ruft nach der Cheffischfrau. Das klappt aber nicht, da Fischfrau 2 besorgt heranstürmt und sich die Sachlage erklären lässt. Das Problem lässt sich schnell und einfach eingrenzen. Kunde hat zwanzig Pfund gegeben und nur für zehn Pfund Ware und Geld erhalten. Die beiden haben eine erste Lösung erarbeitet. Fischfrau 2 fragt den Kunden 1, ob er wirklich zwanzig Pfund gegeben hat. Dieser beantwortet die Frage mit „yes“. Beide Fischfrauen rufen nach der Cheffischfrau und erklären dem Kunden „I am sorry“. Ein weiterer Kunde kommt vorbei und fragt wie lange der Fischladen heute offen hat. Fischfrau 2 sagt ihm, dass bis um halb zehn offen ist. Es wird ein weiteres „I am sorry“ dem Kunden 1 entgegen geschmettert. Dieser denkt sich noch nichts dabei, da John den Fisch fertig gebraten hat und in den Fischzwischenspeicher überführt hat. Die gesamte Aufmerksamkeit des Jägers (Kunden 1) ist nun auf den Fisch gerichtet. Eventuell kann via Telepathie der Fisch herüberwachsen? Cheffischfrau erscheint und erkennt, dass die Kasse geöffnet werden muss. Cheffischfrau: „John, I need the key!“ John liefert den Schlüssel an Fischfrau 3, die sich an Fischfrau 1, Fischfrau 2 und Cheffischfrau vorbeizwängt um die Kasse zu öffnen. Cheffischfrau generiert eine Abrechnung der Kasse. Hierzu wird der Saldo über alle vorhandenen Tagestransaktionen ausgedruckt. Fischfrau 1 steht nebenan und ist vollkommen von Scham und Schande eingewickelt. Sie kann außer '„I am sorry“ sagen' nichts mehr tun. Cheffischfrau fängt an, vor allen Gästen die Münzen, die sich in der Kasse befinden, zu zählen. Die weiteren Kunden bezahlen ohne change zu benötigen. Dreimal klappt das auch und Fischfrau 2 und 3 können die Lage unter Kontrolle halten. Beim Kunden 4 geht das schief. Er benötigt Wechselgeld. Der Betrieb muss eingestellt werden. Eine Schlange williger Fischkäufer bildet sich. Fischfrau 1 kann kaum noch atmen, generiert jedoch in regelmäßigen Abständen ein „I am sorry“. Kunde 1 beteuert, dass so etwas ja mal passieren kann. Die weiteren Kunden sehen das vermutlich anders und beginnen den Kunden 1 als alleinigen Schuldigen zu deklarieren. Cheffischrau ist mit dem Zählen der Münzen durch und macht sich an die Scheine. Kunde 1 beginnt Strategien zu erarbeiten.
    • Geld zurück geben lassen?
    • 10 Pfund abgeben und auf drei Biere verzichten? (kaum vorstellbar)
    • Weiter lächeln oder doch den deutschen Proll auspacken?
    • Einfach gehen und zwanzig Pfund abschreiben? (sicher nicht, bin Schwabe)
    • Kontrolle, ob er tatsächlich 20 Pfund übergeben hat oder ob der Fehler doch bei ihm liegt. (klingt verlockend und wird als Zwischenlösung angesehen.)
    Cheffischfrau hat fertig gezählt. Alle vier Frauen und John ziehen sich nach hinten zurück und beraten die Lage. Kunde 1 hört ein paar sehr beunruhigende Worte: „I can't pay him 10 pound back!“ Nach weiterer Kontrolle kommt Cheffischfrau wieder nach vorne. „You gave us 20 pound?“ Kunde 1 bejaht. Sie zeigt die Kassenabrechnung und ihr Zählergebnis. Die Zählung ergab, dass sich 978,50 Pfund in der Kasse befinden. Die Abrechnung behauptet, dass nur 968,50 Pfund vorhanden sein sollen. Es könnte also durchaus sein, dass der Kunde 1, zehn Pfund zu wenig Wechselgeld erhalten hat. Die Entscheidung ist getroffen worden, der Kunde 1 erhält zehn weitere Pfund zurück. Fischfrau 3 fragt Kunden ob er ein "Coffee" aufs Haus haben will. Dieser bejaht. Fischfrau 2 verpackt den Fisch und fragt nach salt & vinegar. Fischfrau 1 japst ein letztes „I am sorry“. Kunde 1 wird mit seinem Fisch, Geld und Kaffee entlassen und verschwindet. Der Incident-Fall wird abgeschlossen.

    Ergebnis des Incidents:

    Mindestens vier Gäste sind verschwunden und entschieden sich für Diät oder einen anderen Fischladen. Der Incident verursachte 15 Minuten Stillstand im Laden. Weiterhin mussten Löhne für 5*15 Minuten bezahlt werden was somit 75 Minuten Arbeitszeit ausmacht. Ein Kaffee (Kosten ca. 50 Pence) musste mitgegeben werden. Für die 15 Minuten musste die Arbeit eingestellt werden und dennoch Raummiete, Strom usw. bezahlt werden.

    Folgende Behauptung wird aufgestellt:

    Wenn die 10 Pfund sofort zurückgegeben worden wären, wären die Kosten geringer gewesen. Faszinierend finde ich allerdings, dass sich Cheffischfrau nicht verzählt hat. :-) Jetzt kommt aber der Hammer! Stellt euch vor ich wäre ein Krimineller.
    • Ich weiß, wann der Fischladen zugemacht wird (halb zehn)
    • Ich weiß, dass mindestens 968,50.- Pfund in der Kasse vorhanden sind.
    • Ich komme um halb zehn mit meinem Freund Revolver vorbei und erhalte nicht nur einen Kaffee umsonst sondern auch noch 968,50 Pfund.
    Daraus folgt, dass der Verlust sich um mindestens 968,50 Pfund erhöht. Der Incident Prozess führt zu sehr hohen Verlusten. Es wird den Verbrechern direkt mitgeteilt was an einem Freitag ungefähr in der Kasse ist. => Die Gefahr dass die Räuber am Freitag öfters vorbei kommen wird erhöht. Gegenmaßnahmen:
    • Zählen von Geld immer ohne direkten Blickkontakt der Kunden
    • Security Konzept ist notwendig und führt zu einem sichereren Betrieb.
    • Keine 1000 Pfund in der Kasse deponieren. Ab- und zu mal Geld entfernen und an einem sicheren Ort lagern.
    • Fünf Personen sind für den Fischladen gleichzeitig zu viel. Man kann z.B. mit drei Personen den Laden laufen lassen und die Ladenöffnungszeiten mit gleichem Personal verlängern. Die treten sich dann nicht auf den Füßen herum und haben alle ein bisschen was zu tun.
    • Die Mehreinnahmen können zu mehr Lohn für die Mitarbeiter führen.
    • Mehr Spaß an der Arbeit, da sie nicht mehr so langweilig ist.
    Ich werde jetzt auf alle Fälle meinen Job kündigen und mich als Fischladen-Optimierer durchschlagen. ;-)
  • Episode 6: Grenzen des Refactorings ::: Softwareprojekte

    Zu Episode 1 wurde ein Kommentar geschrieben der mir zeigte das auch noch andere Mitstreiter das Problem des Refactorings aktiv angehen. Die Aussage „Andererseits weiß ich, dass wenn ich die Firma verlasse, dann werden die Projekte andere nach mir übernehmen und wieder alles reverseengeneeren müssen. ...wenn ich das Unternehmen verlasse, muss von vorne begonnen werden“ fand ich sehr passend. Mit Refactoring kann man nicht die Welt retten. Ein Softwaresystem ist für mich wie ein lebender Organismus. Unsere Haut wird beispielsweise alle sieben Jahre erneuert. Bei Software verhält sich das im Prinzip genauso.

    Orlando war mal wieder auf einer Schulung

    Ok, da war er schon in Episode 3 und das hat auch seinen Grund. Orlando ist Single und liebt es in Hotelzimmern herumzuhängen. Da das Familienunternehmen zur Zeit noch nicht in mehreren Ländern vertreten ist, ist es für ihn die einzige Möglichkeit das Jet-Set-Gefühl zu erleben. Bei der Schulung wurde der Model Driven Architecture-Ansatz besprochen. Wieder kam er freudestrahlend zurück und wollte das Erlernte sofort ausprobieren. Das ist auch eine typische Orlando Eigenschaft. Er nimmt gerne Neues an und versucht so viel wie möglich gleich zu implementieren. Da es sich bei dem, von Hans, Karl und Orlando, betreuten System um ein hochriskantes, produktives System handelt, ist diese Freude an Neuem für Hans und Karl nicht unbedingt nachvollziehbar. Zuweilen sind Orlandos Kollegen sonderbar altmodisch und wollen vor allem ein überlebensfähiges, stabiles System haben. Vielleicht liegt das an den Betonschuhen die am Ausgang von den schweren Jungs abgestellt wurden... Wie dem auch sei. Hin- und wieder werden Hans und Karl von Orlando überredet etwas Neues zu implementieren. Die Drei wollten erreichen, dass die Entwicklung auf Dauer gesehen immer stabiler und sicherer wird. Deshalb schauten sie sich ihr System genauer an und überlegten ob Model Driven Architecture eventuell eingeführt werden kann.

    Keine Architektur?

    Karl schaute sich die bisherigen Architekturkonzepte an. „Also im Moment sind wir mit einem Mischmasch zwischen prozeduraler Programmierung und objektorientierter Programmierung konfrontiert. Wenn wir das ändern wollen, müssen wir das ganze System am Besten wegwerfen und neu bauen.“ Die drei waren sich hier sehr einig. Ein Neubau würde jedoch einem langanhaltenden Tauchgang im Familienteich nahe kommen. „Vielleicht können wir uns wenigstens eine Architektur überlegen wie es aussehen sollte und das als unsere Strategie definieren. Dann könnten wir beim Review darauf achten in die Richtung der Strategie zu arbeiten“, bemerkte der geschulte Orlando. Hans nickte zustimmend. „Das klingt schon eher machbar. Wir werden also mit dem Refactoring keine endgültige Lösung finden. Wir werden die, zur Zeit erkannten Fehler und Missstände, aufdecken und korrigieren können. Das System wird also nie fertig werden.“ Orlando überlegte: „Ich glaube, dass ist eine normale Eigenschaft in komplexen Systemen. Jede neue Idee führt zu einer Änderung und diese Änderung erfordert neue Vorgehensweisen. Ich glaube das Geheimrezept liegt im Changemanagement und in der Umsetzung der Strategievorgaben. Lasst uns zuerst einmal eine Strategie für die nächsten drei- bis fünf Jahre definieren. Wir sollten dringend mit Giuseppe reden um zu erfahren was er alles vor hat. Dann können wir unsere IT-Bemühungen entsprechend auslegen.“ Vielleicht habt ihr euch schon hin- und wieder gefragt warum Firmen viel Geld für Enterprise Architektur ausgeben. Ich habe im Moment das Vergnügen mit den Architekten eng in einer Gruppe zusammen arbeiten zu können. Die Kollegen produzieren im Prinzip (außer Papier und endlosen Telefongesprächen ;-) ) nichts. Doch der Gewinn für die Firma ist, dass sie sich über die weiteren Jahre Gedanken machen. Es ist wichtig die IT-Landschaft, wie jede andere Prozesslandschaft, über die Jahre hin proaktiv zu bewirtschaften. Unsere drei Freunde haben aus Angst vor Betonschuhen bisher nur reagiert. Mit dem Handwerkzeug Reverse Engineering, haben sie erreicht sich über Wasser zu halten und nicht zusammen mit ihrem alten System zu sterben. Doch um wirklich eine gute Zukunft zu haben, kommen sie um eine Strategie und eine sinnvolle Planung nicht herum. Es wird Zeit das wir eine Koordination in die Geschichte bringen! Um ehrlich zu sein, ich bin gespannt wo dieses Blog noch hinführt...
  • Softwareprojekte Episode 5 ::: Coderefacturing und Lavacode Beseitigung

    Begonnen habe ich mit der Vorgeschichte und den Episode 1, Episode 1, 2, 3 und 2, 3 und 4 in diesem Teil geht es um Coderefacturing In Episode 3 (Refacturing kann helfen) habe ihref="http://miradlo.net/bloggt/index.php?79-s""> 3 und 4 in diesem Teil geht es um Coderefacturing In Episode 3 (Refacturing kann helfen) habe ich schon ein bisschen über Lavacode und Reviewzyklen gesprochen. Jetzt möchte ich ein paar Beispiele, wie Lavacode aussieht und wie man ihn wegputzen kann, aufzeigen. Die Review-Sessions von Hans, Karl und Orlando liefhref="http://miradlo.net/bloggt/index.php?80-s""> 4 in diesem Teil geht es um Coderefacturing In Episode 3 (Refacturing kann helfen) habe ich schon ein bisschen über Lavacode und Reviewzyklen gesprochen. Jetzt möchte ich ein paar Beispiele, wie Lavacode aussieht und wie man ihn wegputzen kann, aufzeigen. Die Review-Sessions von Hans, Karl und Orlando liefen schon einige Wochen. Im Schnitt schafften sie zehn Klassen pro Woche und mittlerweile konnten sie schon diverse Probleme und Schwachstellen ausloten und flicken. Orlando war gerade dabei einen Observer zu putzen. Im Dateisystem fanden sich folghref="http://miradlo.net/bloggt/index.php?79-s"">Episode 3 (Refacturing kann helfen) habe ich schon ein bisschen über Lavacode und Reviewzyklen gesprochen. Jetzt möchte ich ein paar Beispiele, wie Lavacode aussieht und wie man ihn wegputzen kann, aufzeigen. Die Review-Sessions von Hans, Karl und Orlando liefen schon einige Wochen. Im Schnitt schafften sie zehn Klassen pro Woche und mittlerweile konnten sie schon diverse Probleme und Schwachstellen ausloten und flicken. Orlando war gerade dabei einen Observer zu putzen. Im Dateisystem fanden sich folgende Dateien:
    • lavaklassen
    • TestDummyModel Eine Unit-Testklasse mit der das DummyModel auf Funktion überprüft wurde.
    • BaseUIElement Der Observer mit dem das Subjekt überwacht werden soll.
    • TestBaseUIElement Ratet mal ;-) Ist wohl eine Testklasse.
    • BaseModel Beinhaltet die Basis-Modell Information und schlussendlich die echte Subjekt-Methode.
    Um das BaseModel testen zu können, wurde ein TestBaseModel eingeführt. Das DummyModell wurde nur dazu benötigt um die protected-Methoden der BaseModelklasse testen zu können. Der Aufwand, um DummyModel und TestDummyModel entwickeln zu können, betrug in etwa einen Arbeitstag. Jetzt kommt aber der Hammer: Die Wartung von DummyModel und TestDummyModel kostete zwei Stunden. Im zweiten Jahr wuchsen die Wartungsaufwände auf zwei Tage an. Das bedeutet, dass die Wartung mehr kostete als die ursprüngliche Herstellung. Wie konnte das passieren? DummyModel wurde nicht nur für den Test von BaseModel verwendet, sondern wurde in vielen anderen Testszenarien als einfache Lösung angesehen, die protected-Methoden von BaseModel zu verwenden.
    • lavaexplosion
    Eine Änderung am DummyModel verursachte nun enorme Kosten bei den Testklassen.

    Was kann man da besser machen?

    Ok, zuerst kann man mal über ein sauberes Konzept und „wir programmieren nur gegen Schnittstellen“ und all die schönen Regeln beherzigen. Manchmal sieht man aber den Klassenwald vor lauter Methoden nicht mehr. Lavacode entsteht, niemand kann ihn 100% verhindern. Wenn aber so ein Problem erkannt wurde, muss man handeln. Orlando griff in die Tasten und entfernte das DummyModel. Das Testen der protected-Methoden löste er durch eine Wrapperklasse im TestBaseUIModel und die Testklassen wurden so umgebaut, dass sie sich wieder an Schnittstellen halten und keine Wartungsexplosion zu erwarten ist. Karl hatte an einem nebligen Freitag ein Problem beim Review. „Jungs schaut mal her: Diese Methode hier verursacht das Problem, dass wir an zwanzig Stellen im Programm Abhängigkeiten schaffen. Das ganze ist nicht modular sondern vernetzt. Wenn ich das jetzt aber ändern soll werde ich nicht fertig und außerdem müssen wir das extrem gut testen. Was sollen wir machen?“ Termine drücken im Familiengeschäft immer. Wenn die drei den nächsten Release vergeigen ist mindestens einer der Drei bei Fred. Dementsprechend sind Klaus, Orlando und Hans etwas vorsichtig beim kompletten Umstellen der Systemkomponenten. Hans schaute sich das Problem an: „Also gut, wir schaffen das jetzt nicht. Geh doch durch alle dir bisher bekannten Komponenten durch und schreibe ein TODO hinein. Wir analysieren das Thema über die nächsten Wochen und falls wir dann glauben, dass wir es schaffen können, putzen wir den Code.“ Diese Idee beruhigte die Nerven der drei gestressten Entwickler doch sehr. Vier Review-Zyklen später war das Problem vollständig analysiert und sie konnten ohne Familienteich die Abhängigkeiten auflösen. Wenn beim Codereview festgestellt wird, dass ein größerer Aufwand vorhanden ist, muß dies vermerkt werden. Der Projektleiter muss eine Issue-Liste führen und neue Anforderungen und Probleme dort hinterlegen. Es werden immer Problemstellungen vorhanden sein, die nicht sofort gelöst werden können. Die schlechteste Alternative ist diese einfach zu verdrängen. Wenn im Sourcecode dokumentiert ist, dass noch Nacharbeiten notwendig sind und Zeit und Aufwand für diese Nacharbeiten im Projekt budgetiert worden sind, stellen diese notwendigen Korrekturen kein Problem dar.
  • Softwareprojekte Episode 4 ::: Testen hilft

    Die bisherigen Teile Episode 1, Episode 2 und Episode 2 und Episode 3 über die Vorgehensweisen bei Softwareprojekten starteten mit der Episode 3 über die Vorgehensweisen bei Softwareprojekten starteten mit der Vorgeschichte, heute geht es ums Testen, insbesondere um Unit Tests. Ein paar Wochen später fand Hans im Netz diverse Testvorgehen und Tools. „Fred schau dir das mal an, die Unit Tehref="http://miradlo.net/bloggt/index.php?69-s"">Vorgeschichte, heute geht es ums Testen, insbesondere um Unit Tests. Ein paar Wochen später fand Hans im Netz diverse Testvorgehen und Tools. „Fred schau dir das mal an, die Unit Tests sind wirklich cool!“ Er war auf der Seite JUnit und beide studierten die Beschreibung. „Das ist aber verflixt aufwändig umzusetzen. Wir müssten mindestens ein Personenjahr aufwenden, um unser System damit auf Funktion zu überprüfen“, bemerkte Karl. Orlando kam um die Ecke und klärte die Beiden auf: „Wir müssen ja nicht alles auf einmal testen. Wir bauen die Testfälle für neue Funktionalität. Wenn wir unser wöchentliches Refactoring durchführen können wir die wichtigsten Testfälle für den bestehenden Code erstellen. Auf diese Weise werden die dunklen Stellen im System weniger und wir können ruhiger schlafen.“ Dies erschien den Kollegen eine gute und einfache Vorgehensweise zu sein.

    Beim Unit Test sollten (mindestens) die folgenden Dinge beachtet werden:

    • Unit Test bedeutet wirklich Unit. Teste vor allem einzelne Komponenten und keine komplexen Abläufe mit Unit Test. Für komplexe Abläufe und Interaktionen mit mehreren Klassen bietet sich z.B. ein ANT Script eher an.
    • Teste die Übergabeparameter.
    • Wenn möglich teste jeden Übergabeparameter ob die Methode auf Grenzwerte (negative Zahlen, zu große Werte usw.) korrekt reagiert. Teste weiterhin, ob die Eingabewerte nur korrekte Werte annehmen können, (z.B. kein 30. Februar bei einer Datumgsübergabe). Teste auf Nullwerte und bei nicht typsicheren Sprachen, wie PHP, ob falsche Typen übergeben werden können, Beispiel: String erwartet, Array übergeben)
    • Falls möglich teste sämtliche Pfade (Pfadabdeckung) innerhalb der Methode.

    Beispiel:

    if($i == 0){ // do something }else{ // do something else } Hier sind zwei Pfade zu überprüfen. Nur wenn beide Pfade vernünftig reagieren, kannst du dir sicher sein, dass alles gut ist.

    Für Projektleiter und gute Entwickler:

    Es ist eine sehr schnelle und effiziente Art zu entwickeln, wenn man nicht mit dem Programm sondern mit den Testfällen anfängt. Die Zeit, die für die Erstellung der Testfällen benötigt wird, wird durch krampfhafte Fehlersuche am Ende des Projekts locker eingespart. Ein einziges Mal war ich mit Unit Tests bei einer Änderung langsamer, da ich vom Observer auf Eventpattern umstellte und dabei viele Testfälle wirklich manuell überarbeiten musste. Dies war jedoch eine Ausnahme. Wenn eine Änderung am System durchgeführt wird, kann mit Unit Test sehr schnell ein Regressionstest durchgeführt und die Funktionalität überprüft werden. Also nochmal: Es ist ein Aberglaube, dass die Erstellung von Unit Tests irgendwie die Entwicklung bremst. Das Gegenteil ist in deutlich über 95% der Fall. Das Einzige was Zeit kostet, ist es als Projektleiter den Mut zu haben diese Vorgehensweise zu wählen und die Einlernzeit neuer Mitarbeiter in Unit Tests. (Die Einlernzeit ist übrigens nicht sehr hoch.) Für Tester ist das auch eine coole Sache. Sie können die Detailkonzepte direkt in automatische Tests überführen und Regressionstests werden regelrecht spaßig!

Seite 1 von 1, insgesamt 4 Einträge