Verschwendung bereits zu Beginn eines Projektes…

Ein überfülltes Materiallager ist Verschwendung pur. Lebensmittel vergammeln, Werkstoffe korrodieren und Anforderungen verlieren ihre Gültigkeit.

Unter dem Begriff “The 7 Mudas“ (Verschwendung, japanisch) finden sich deren 7 Arten:

1. Überproduktion
2. hohe Lagerbestände
3. Wartezeit
4. unnötige Bewegung
5. unnötige Transporte
6. Überbearbeitung
7. Fehler

Ich widme mich hier dem Thema “hohe Lagerbestände“. Ich will Antworten liefern, wie explizites Wissen (niedergeschriebene Anforderungen) in Anlehnung an die 7 Mudas, tief gehalten werden können.

“Meine Mittel will ich so verwalten, dass wenig weit soll reichen“ [William Shakespeare]

Was William Shakespeare bereits vor ein paar hundert Jahren erkannt hat, gilt auch heute noch. Schauen wir uns ein paar Fakten an, um der Frage über das “Wenige“ etwas näher zu kommen:

• Unsere Ressourcen sind beschränkt:
  Faktoren Zeit und Geld: Es ist eine Verschwendung, Unnötiges zu dokumentieren.

• Man kann nicht alles spezifizieren:
  Es ist ein Mythos zu glauben, wir könnten eine SW vollumfänglich spezifizieren. Aufgeblasene Dokumente sind unsinnig. Sie werden überflogen statt gelesen.

• Spezifikationen müssen verwaltet und gepflegt werden:
  Changes können einen Rattenschwanz von Änderungen erzeugen. Je weniger Text, desto weniger Tipp-Ex!

Spätestens jetzt drängt sich die Frage auf, was soll ich nun spezifizieren, damit das “Wenige weit soll reichen“? Die Antwort ist so einfach wie banal:

1. Nur spezifizieren, was relevant ist und entsprechend einen Mehrwert erzeugt.
2. Vorsicht beim spezifizieren von allgemeinem Wissen (implizites Wissen). Dies ist eine Verschwendung von Ressourcen und Zeit. Die Herausforderung ist hier eine gute Balance zu finden.

Noch Fragen? Vermutlich ganz viele. Hier 3 Beispiele:

• Wenn für eine schweizer Heizungsfirma eine Buchhaltung-Software entwickelt wird, dann muss nirgend die Sprache definiert werden. Logisch läuft das Programm in Deutsch. Definieren müsste man erst eine Mehrsprachigkeit. Einen echten Mehrwert hingegen erzeugt ein Mockup, welches die UI visualisiert und die Buttons festlegt.

• In einem Feld soll ein Monat (Integer 1-12) eingebeben werden können. Logisch, dass bei einer inkorrekten Eingabe eine Fehlermeldung nicht spezifiziert werden muss. Das ist implizites Wissen, gemeinsames Verständnis dafür ist vorhanden. Wir erwarten, dass die Gültigkeit der Eingabewerte überprüft wird.

• Eine Maschinensteuerung hat folgende Verhaltensregeln:

A1:       Detection Error   =>  repeat 3x

E1:       Hardware Error  =>  re initialize

E11:     E1 in Kombination A1   =>   re initialize AND repeate 2x

Es ist meine Erfahrung, dass Detailspezifikationen oft unnötig die allgemeinen Anforderungen konkurrieren. Man kann es technisch sicher begründen, warum in diesem Beispiel, die Kombination von A1 und E1 die goldene Exzeption E11 aufrufen soll. Jedoch – die Frage hängt in der Luft: Ist diese wirklich nötig? Oder wurde sie nur der vollständigkeitshalber definiert? Denn, einen Mehrwert in Bezug auf die Funktionalität wird mit E11 nicht erreicht, sondern nur eine Zeiteinsparung.

– Jede zusätzliche Anforderung erzeugt einen Mehraufwand für das Requirements-Engineering, die Entwicklung und das Testing.

– Auch sollte man nicht vergessen, jede zusätzliche Anforderung macht die SW anfälliger für Bugs.

Vorsicht

Grosse Projekte brauchen nach wie vor viele Anforderungen in unterschiedlichen Abstraktionen, verwaltet in Tools oder ganzen Tool Suiten. Tabellen, Diagramme und sonstige Visualisierungen sind wichtig.

Lean Requirements-Engineering soll kein Freipass sein, Anforderungen willkürlich zu kürzen. Gerade mit dem impliziten Wissen muss mit grosser Vorsicht umgegangen werden. Da spielt das Domain Wissen im Team eine entscheidende Rolle.

Quick-Wins:

• Steigerung der Effizienz indem “das Wenige“ bewusst gemacht wird.
• Das Ausmerzen der Verschwendung erfolgt elegant ohne viel Staub aufzuwirbeln. Prozesse und Strukturen müssen nicht umgekrempelt werden.

Introduction

Multi-threaded programs are becoming more important because today’s software doesn’t benefit from multi-processor machines unless it utilizes multiple threads. Unfortunately, multi-threaded applications are prone to programming mistakes that are difficult to detect and localize due to the unpredictable and therefore nondeterministic execution order.
Faults that are unique to concurrent programs are data races, where unsynchronized access to shared memory locations results in inconsistent data, and dead locks, where two or more threads block each other. Hence, the need for tools that help in finding these kind of faults is hugely important.

Helgrind: a thread error detector

Maybe you’ve heard of the freely available tool Valgrind before. Its default tool Memcheck is able to detect memory-related bugs (memory leaks, doubly freed memory, use of deleted memory, use of uninitialized memory, etc.). It turns out that Valgrind also comes with a tool called Helgrind for detecting synchronization errors in C and C++ programs.

So let’s have a try and access a shared memory location from two threads without using synchronization:

The problem with this example is that ‘var’ is not protected for being updated simultaneously by both threads! A correct program would protect ‘var’ e.g. with a lock of type ‘pthread_mutex_t’, which is acquired before each access and released afterwards. Such missing locking can cause obscure timing dependent bugs!

Debugging process

Now, let’s run g++ compiler over this source code to create the executable:

We compile our program with -g to include debugging information so that Helgrind’s error messages include exact line numbers.

Using Helgrind (provided that we’re on a Unix platform) is as simple as:

As clear from the command above, the main binary is ‘valgrind’ and the tool which we want to use is specified by the option ‘–tool’. The ‘./simple_race’ above signifies the executable over which we want to run Helgrind. And the ‘./helgrind.log’ specifies that Valgrind sends all of its messages to this file.

Helgrind’s output for this program is:

A lot of details for an apparently very simple bug! But the lines above show that the checker was able to correctly detect the data race. The main error message says that there is a race as a result of a read of size 4 (bytes) at 0x601038, which is the address of ‘var’, happening in function ‘main’ at line 23 in the program.

In order to suppress false reportings in subsequent runs of Helgrind, it is possible to write a so-called suppressionfile that contains report-type and call-stack-patterns of locations that are false positives or part of code that is not modifiable like third-party libraries.

Conclusion

Helgrind can be very helpful in finding and resolving threading-related problems. Like all sophisticated tools, it is most effective when you understand how use it. The tool may generate a huge amount of warnings containing many false positives, but you can find real bugs, too! So play around with Helgrind!

And happy debugging!