Qualität

Was ist Qualität? Alle versprechen es, aber vielleicht meinen nicht alle dasselbe? Deswegen wollen wir festlegen was wir unter guter Qualität der IT-Kundenleistungen verstehen. Nach unserem Verständnis, sind es mehrere Faktoren die dazu beitragen:

1. Die Sourcecode-Qualität

Zuerst der Code. Es ist doch das, was am Ende ausgeliefert wird. Eine gute Code-Qualität bedeutet für uns nichts anderes als eine gute Lesbarkeit! Der Code sollte verständlich sein: gut kommentiert, ordentlich formatiert, klar gegliedert, so dass der dahinterliegende Gedankengang klar wird. Hier ein Code-Auszug als Illustration unserer Standards:

/*-----------------------------------------------------------------------*/ 
/**
* @brief configDelta
* @descr
* This function compares two configurations and returns the differences.
*
* @param[in] other - the other configuration
* @param[in] scope - what delta requested: all the new entries, all the 
* deleted entries, or all changes altogether?
* @param[out] delta - the calculated diffrence
*
* @note Assumption: both configurations must be sorted!!!
*///----------------------------------------------------------------------->
void SimpleCfgFile::configDelta(const SimpleCfgFile& other, CfgDelta scope,
                                vector<string*>& delta) const
{
    TRACE_FUNC("SimpleCfgFile::configDelta");
    delta.clear();

    switch(scope)
    {
    case addedDelta:
        TRACE_DEBUG("addedDelta");
        // all in this but not in other:
        set_difference(begin(), end(),
                       other.begin(), other.end(),
                       inserter(delta, delta.begin()),
                       less_then_deref<string*>());
        break;

    case removedDelta:
        TRACE_DEBUG("removedDelta");
        // all in other but not in this:
        set_difference(other.begin(), other.end(),
                       begin(), end(),
                       inserter(delta, delta.begin()),
                       less_then_deref<string*>());
        break;

    case completeDelta:
        TRACE_DEBUG("completeDelta");
        // all in this but not in other + in other and not this:
        set_symmetric_difference(begin(), end(),
                       other.begin(), other.end(),
                       inserter(delta, delta.begin()),
                       less_then_deref<string*>());
        break;

    default:
        TRACE_ERR("Unknown scope requested for configuration delta!!!");
    }

    TRACE_VALUE(delta.size());
}

2. Die Kundenfeedback-Qualität

Viele IT Consultants sind so sehr in die Aufgabe vertieft, für den Kunden die bestmögliche Arbeit zu leisten, dass sie die Tatsache übersehen, dass Kunden nicht bloß die technische Expertise oder gar das Endergebnis kaufen. Sie möchten sich auch sicher fühlen können: sicher dass die richtige Person an dem Problem arbeitet, und dass sie auch im deren bestem Interesse handelt!

Gute Ergebinisse zu liefern ist sicherlich ein Teil davon, aber es reicht nicht. Damit der Kunde zufrieden ist, muss er vor allem genau wissen wie das Projekt voranschreitet. Dazu benutzen wir folgende "Hilfsmittel":

• der Wochenbericht

Jede Woche wird den Kunde kurz  über die Tasks, die in der letzen Woche bearbeitet wurden, und die entsprechenden Aufwände informiert. Die allgemeine Projektlage wird dann kurz beschrieben und die nächsten Aufgaben, die bearbeitet werden, genannt. Dies kann entweder mündlich (die bevorzugte Variante) oder per Email geschehen.

• die TODO-Liste

Jedes Projekt wird durch eine simple Todo-Liste definiert. Diese Liste enthält alle noch anstehenden Arbeiten, zusammen mit den zugehörigen Aufwandschätzungen und Prioritäten.

Die Regeln eines "Listen gesteuerten" Projektes sind einfach; es wird nichts gemacht was nicht auf der Liste steht, und es wird keine Prio 2, 3, usw. Aufgabe angefangen solange noch Prio 1 Aufgaben anstehen!

Für den Kunden bedeutet die Liste, dass er immer weiß welchen Umfang das Projekt momentan hat und wie lange es schätzungsweise noch dauern wird.

• das Burndown-Diagramm

Zu der Todo-Liste gehört eine graphische Darstellung des Projektverlaufes, das sogennante Burndown-Diagramm. Es zeigt wieviel Zeit noch zum Projektende bleibt, und gleichzeitig illustriert den Projektverlauf. Hier kann man sehen, wie sich der geschätzte Projektumfang mit der Zeit geändert hat, wieviele neue Aufwände mit der Zeit entdeckt wurden, wie schnell effektive gearbeitet wurde, und wie lange das Projekt nocht dauern wird

Dieses Diagramm heißt genauso wie ein bekanntes Diagramm aus der Agile/XP-Ecke, wird aber nicht mit Use Cases oder Story Points sondern eher traditionell mit den absoluten Zeitaufwänden (MT) skaliert.

3. Die Programm-Qualität

Darunter verstehen wir etwas anderes als unter der Code-Qualität. Letztendlich muss der Programm doch das machen wofür er geschrieben ist¹. Die Code-Qualität alleine kann das nicht garantieren. Wie wollen wir das machen?

Unsere Antwort heißt: 

• iterative, testgesteuerte Entwicklung mit einem frühen "Durchstich"!

Man beginnt mit einem funktionerenden Gerüst der Anwendung (dem ersten "Durchstich" oder Slice) und erweitert sie iterativ um einzelne Features. Dabei werden für jedes Feature Testfälle erstellt, die man laufen lassen kann, nachdem ein neues Feature hinzugekommen ist. Einfach? Ja, es ist eine pragmatische Auswahl der Verfahren aus RUP, Agile und XP Methodologien.²

Der Vorteil von diesem Verfahren ist, dass es immer irgendwas gibt, dass funktioniert, und die einelnen Features immer wieder neu getestet werden. Dazu wird in der Regel ein Testframework erstellt (Python oder C++, mit oder ohne GUI), dass eine Auswahl der zu durchführenden Testfälle oder Testsuiten ermöglicht, und die Testergebnisse interpretiert.

Bei der Fehlersuche und Tuning kommen dann

• verschiedene Tools 

zum Einsatz. Und zwar: Debugger, Memory-Leak Tools (C++ und Java, weil Java auch Memory Leaks hat!), Profiler und (wenn gewünscht) Code-Coverage Checker. Zuletzt wird zur Erstellung der Dokumentaion ein UML Tool verwedet (z.B. Enterprise Achitect). Das sieht ziemlich umfangreich aus, ist aber nötig um professionelle Programmqualität zu gewährleisten!

Wenn das Programm fertig ist, ist es

• noch nicht vorbei!

Trotz des ganzen Testing und Tooling wird es Fehler geben! Dann ist es wichtig, dass man die Fehler im Produktionscode schnell aufspüren kann. Deswegen legen wir großes Gewicht auf die Trace- und Log- Funktionalität!

--

1. Natürlich könnte man mit formalen Mitteln beweisen, dass der Programm korrekt ist, oder es automatisch von einem Model Checker überprüfen lassen (z.B. SPIN) - es bedeutet aber immer einen größeren Aufwand. Das mindeste wäre, es in einer Sprache zu schreiben, die sich als Input zu solchen Checkern eignet (OCaml, Haskell) - das können wir auch machen!
   
2. Zu einfach? Ja, richtig, wir benutzen hier kein TDD! Einige pragmatische Gründe dafür finden sie in: www.rbcs-us.com/documents/Why-Most-Unit-Testing-is-Waste.pdf