Montag, 27. September 2010

Korrektive Wartung - wer bezahlt für Fehler?

Folgendes schreibt mir ein Bekannter, der IT Koordinator in einem größeren Betrieb ist, zum Thema korrektive Software Wartung, da er meine Vorlesungsfolien (TU Wien - Software Wartung und Evolution) im Internet gefunden hat:
In der Praxis läuft es aber immer wieder auf die selben Diskussionspunkte hinaus:
  • Fehler oder "works as designed"
  • Fehler oder Änderungswunsch -> Unterscheidung korrektive bzw. adaptive Wartung
  • Fehler: bezahlen oder nicht.
Gerade der letzte Punkt ist strittig, da die korrektive Wartung in unserer Wartungspauschale enthalten ist. Jedoch wird eine Entwicklung erst nach Abnahme produktiv gesetzt. Der Fehler wurde also beim Test nicht festgestellt. Und wer ist nun schuld, dass es den Fehler im Produktivsystem überhaupt gibt?

Und das ist meine Antwort:

Die Probleme sind mir – als Individualsoftwarehersteller und Ziviltechniker für Informatik – gut bekannt. Also kurz mein Statement dazu:
Die Korrektheit ist der Grad, zu dem ein implementiertes Feature einer Anforderungsspezifikation entspricht. Das Problem ist, dass Anforderungen in den meisten Fällen nicht eindeutig sind (weil sie meist in Prosa und nicht mathematisch abgefasst sind; ein paar UML Grafiken helfen da auch nur ein bisschen) und daher im Nachhinein immer Interpretationsspielraum bieten – das kann nun der Hersteller für seine Zwecke ausnutzen (das ist „works as designed“). Leider ist es ebenso schwierig, eine ganz eindeutige Anforderungsspezifikation im Vorhinein („up-front“) zu liefern, daher sind neuerdings lernende Ansätze wie Scrum so populär.
Es liegt im Interesse des Herstellers, einen Fehler („korrektive Wartung“) wenn möglich als Änderungswunsch zu titulieren, um den Aufwand für die Änderung (Behebung des Fehlers oder Erweiterung der Funktionalität) bezahlt zu bekommen.
Bei meinem Projekten/Kunden halten wir es mit Fehlern – auch in Übereinstimmung mit der mir bekannten relevanten Gesetzgebung - so: Es gibt 6 Monate Gewährleistung ab der Abnahme (6 Monate weil B2B und nicht B2C), in dieser Zeit sind Fehler der Klasse 1 (betriebsverhindernd) und Klasse 2 (betriebsstörend) auf Kosten des Herstellers zu beheben. Dabei ist es auch irrelevant, ob der Fehler im Test nicht aufgefallen ist („versteckter Mangel“), selbst wenn der Kunde mitgetestet hat. Es ist dem Kunden nicht zuzumuten, alle Fehler beim Akzeptanztest aufzudecken – selbst wenn eine Mitwirkungspflicht bei der Durchführung der Tests vertraglich vereinbart ist. Bei Fehlern der Klasse 3 (Kosmetik) weisen wir unserer Kunden darauf hin, dass hier eine strenge Auslegung der Anforderungen besteht – für den Hersteller ist es schwer, wirtschaftlich zu bleiben, wenn der Kunde ab der Abnahme alle 3 Tage meldet, dass er jene Farbe und jenen Dialog gern anders gestaltet hätte. Hier wird generell der Dialog gesucht und Mediation durch den Projektleiter betrieben. Größere Änderungen in der Klasse 3 sind vom Kunden zu bezahlen.
Ist die korrektive Wartung in der Wartungspauschale enthalten, liegt also die Behebung von Fehlern beim Hersteller – hier ist eine genaue Definition von Fehlerklassen - siehe oben - zu empfehlen. Neben dem Fehlergewicht kann man z.B. auch den Fehlertyp (falsch, fehlend, überflüssig, ungenau) zur Klassifizierung heranziehen.
Ein weiteres Problem hierbei ist die Arbeitsweise in der adaptiven oder erweiternden Wartung – wenn der Kunde schlechte Anforderungsqualität „auf Zuruf“ liefert und den Entwicklungsprozess chaotisch managed, kommen wir bei der Verantwortlichkeit für Fehler im System auch ins Diskutieren.
Wie auch immer – denke ich – dass dieses Thema immer Spielraum für Diskussion bietet. Daher muss man möglichst viel Munition vorrätig haben - und eine Mediation von außen - vor allem in heiklen Fällen - kann hier auch helfen, um dem Hersteller zu zeigen, dass er nicht nur den Kunden überzeugen muss (bzw. überrumpeln kann). 


Und was denkt ihr?

Euer
JWR@coopXarch.

Mittwoch, 22. September 2010

Und wo ist die Dokumentation?

Das Thema Softwaredokumentation ist kein leichtes - oft fragt man sich am Ende des Projektes, welche Dokumentation eigentlich beauftragt war und nun zu liefern ist. Damit das nicht passieren kann, habe ich vor einiger Zeit einen Projektauftrag für Softwaredokumentation erstellt. Dieser ist in der Projektstartphase gemeinsam mit dem Kunden auszufüllen und formal zu bestätigen (z.B. durch Unterschrift oder Commitment-Abgabe). Man beachte, dass z.B. ein Pflichtenheft nicht verpflichtend zu erstellen und zu liefern ist - in kleineren Projekten kann das Pflichtenheft aus einer Reihe von Einträgen (z.B. User Stories) in einem Issue Management Tool bestehen. Den QS-Plan samt Testdokumentation würde ich aus heutiger Sicht aber in den verpflichtenden Teil aufnehmen. Vielleicht findet Ihr die Idee ja nett und könnt das Template verwenden bzw. ergänzen - ich bin sicher, es gibt noch ganz viele andere Arten von Dokumentation...


Projektname

Projektcode

Mandatorisch

Projekthandbuch (IPMA konform, Ausfüllungsgrad je nach Projektgröße)

Technische Spezifikation

Source Code Kommentare

Entwickler Javadoc
Optional

Pflichtenheft

Requirementsspezifikation

Dokumentation der Machbarkeitsstudie

Architekturspezifikation

Designspezifikation

GUI Spezifikation

Package- oder Modulspezifikation

Qualitätssicherungsplan und Testdokumentation

Wartungshandbuch

API Javadoc

API Dokument

Benutzerhandbuch

Administrationshandbuch

Installationshandbuch

Betriebshandbuch

Schulungsunterlagen
Name

Datum, Ort

Unterschrift





































JWR@coopXarch.

Sonntag, 12. September 2010

Was macht die IT Abteilung?

Dies scheint eine generelle Frage zu sein: Schaffe ich es, meine verstreuten Architekturen auf einige wenige zu reduzieren und damit Kosten und Personal zu sparen? Manche Firmen müssen laut der Hackett-Group täglich damit kämpfen, "einfach nur alles am Laufen zu halten, statt IT-Investitionen zu tätigen, die ihre Gesamtkosten reduzieren oder ihre Effektivität steigern". Tappen wir in die Wartungsfalle, in der alle organisatorische Kapazität darauf verwendet werden muss, das rasch aufgebaute komplexe soziotechnische System am Leben zu erhalten, ohne Chance auf Optimierung und Innovation? Was kann man dagegen tun? Und in welcher Reihenfolge? Antworten bitte als Kommentare! Danke!

JWR@coopXarch.

Dienstag, 7. September 2010

Vortrag am 4. Oktober 2010 in der Wirtschaftskammer Österreich in Wien

Liebe Leser!

Ich spreche in meinem Vortrag im Rahmen der CON.ECT Eventmanagement Veranstaltung "Software Trends" über das Spannungsfeld Qualitätssteigerung versus Kostensenkung im Kontext von Individualsoftware.

Das Prinzip der Ökonomie: Höhere Qualität zu geringeren Kosten - ist das für Individualsoftware machbar?

Warum ist Software so teuer, nie fertig und funktioniert nicht optimal? In der Softwareindustrie ist man fast täglich mit diesen Fragen konfrontiert und der Druck, weitere Kosteneinsparungen zu erzielen, erscheint angesichts der ungelösten Qualitätsprobleme kontraproduktiv. Das Spannungsfeld Kosten versus Qualität führt zu folgender Frage: Werden Produktivitätssteigerungen durch Technologie- und Prozessinnovationen in absehbarer Zeit zu höherer Kosteneffizienz in der Fertigung von Individualsoftware führen oder wird dieser Kostenvorteil durch Investitionen in die Qualitätssicherung immer komplexerer Systeme kompensiert? Der Sprecher nimmt sich als Softwarearchitekt und  Projektmanager dieser spannenden Frage an und kommentiert in diesem Kontext aktuelle Trends zur Qualitätssteigerung bzw. Kostensenkung.

Montag, 04. Oktober 2010 von 13:20 bis 14:00 Uhr (Die Gesamt-Veranstaltung findet von 12:00 bis 18:00 statt: Veranstaltungsprogramm). Anmeldung erforderlich.

Wirtschaftskammer Österreich, HS 7, 1040 Wien, Wiedner Hauptstraße 63

Ich freue mich natürlich über Euren Besuch!

Euer
JWR@coopXarch.

Montag, 6. September 2010

Was ist Software Architektur? Gibt es eine klare Antwort? Eine Betrachtung.

Wenn wir über Architektur sprechen, denken wir intuitiv, wir alle sprächen über das gleiche Thema. Jedoch gibt es viele Definitionen von Software Architektur und noch mehr Darstellungen derselben. Es gibt Architecural Views, Styles und Patterns, Architekturbeschreibungssprachen und -notationen und Architekturbewertungsverfahren. Ist Architektur immer auch Design und umgekehrt? Was tut ein Software Architekt den lieben langen Tag?

James: "Wir suchen einen Software Architekten!"
Dean: "Was werde ich am ersten Tag machen?"
James: "Wir wollen die Architektur unserer Software dokumentieren!"
Dean: "Kein Problem! In welchem Format?"
James: "Ich hoffte, das würdest Du uns sagen!"
Dean: "Ich kann mich ja mal in den Code einlesen..."

Es gibt viele Wege, Architektur zu beschreiben - sicher gibt es besser und schlechter geeignete Repräsentation, was ist aber nun wichtig, wenn man über Architektur spricht?
  • Erstens sollten wir in einer Gruppe eine einheitliche Sprache entwickeln. Nach der Sapir-Whorf Hypothese schafft Sprache Wirklichkeit, und um uns nicht in einem semantischen Albtraum zu verlieren, ist es sinnvoll eine "Gesamtsprache" - so etwas wie die Ubiquitous Language (UL) aus dem Domain Driven Design Bereich - zu entwickeln. Erzeugen wir dieselben Bilder im Kopf, können wir zufrieden sein. Ein Bild sagt mehr als 1000 Worte - und darum ist eine grafische Architekturbeschreibung auch so sinnvoll.
  • Zweitens sollten wir uns nicht panisch an postulierte Vorgaben halten - legt man alle Bücher zu Software Architektur aufeinander, kann man bald getrost dem Eiffelturm Konkurrenz machen. Gut ist, was gefällt - was unserem Problem in unserer Umgebung am Effektivsten zu Leibe rückt. Mut zum Anderssein - wenn es Sinn macht. Mut zum Experiment, wenn man das Gefühl hat, da ginge noch etwas besser - und Mut, sinnlose Ansätze formlos wieder zu verwerfen.
  • Drittens sollten wir als Entwickler Architekten nicht vorsorglich verdammen und als Architekten Entwickler nicht bevormunden. Diversität der Meinungen und der konstruktive Dialog produzieren - ein Aufeinander hacken, sei es, um Justament Standpunkte zu verteidigen oder persönliche Überzeugungen aus Eigeninteresse zum Postulat hochzustilisieren, zerstört. Zerstörte Architektur ist auch Architektur - nur macht sie keinen Spaß. Erfahrene Architekten haben so ein ungutes Gefühl in der Magengegend, wenn ihnen ein zerrüttetes soziotechnisches System eine zerstörte Architektur als "einzig machbaren Weg" vorstellt - da weiß man, dass Arbeit auf einen zukommt.
    Architektur (und Architekturmanagement) ist die Courage, aus einer Menge von möglichen Wegen einen gangbaren (viablen, würden die Konstruktivisten sagen) einzuschlagen, ihn konsequent zu verfolgen und evolutionär anzupassen. Dann wird der Weg durch den steinigen Entwicklungsalltag breiter und sicherer, das Produkt übersichtlicher und seine Evolution einfacher - und es macht bedeutend mehr Spaß, mit von der Partie zu sein.

    Euer
    JWR@coopXarch.