Software durch Menschenhand schaffen – ein Wunsch am Jahresende.

These: Menschen die sich wohl fühlen, Menschen die geachtet werden schaffen beachtliche Software.

Könnte man kleine Teams bilden, bestehend aus 3 bis 4 Entwicklern und Entwicklerinnen? Könnten sich diese kleinen Teams zu größeren Teams zusammensetzen? Zuerst zu Doppelteams, dann zu immer größeren Einheiten? Könnte sich eine Organisation von unten nach oben etablieren, je nach den Erfordernissen der Wirklichkeit?

Der Kunde ist für die systematische Erarbeitung der Kundenanforderungen zuständig

Gute Software benötigt gute fachliche Anforderungen.

Bevor ich meinen Artikel starte, möchte ich Ihnen ein frohes und besinnliches Weihnachtsfest im Kreis Ihrer Liebsten wünschen. Vielleicht kann man einige Wünsche an das menschliche Miteinander, die man in das Weihnachtsfest projiziert, lieber auf das ganze Jahr verteilen, um so diese wenigen Tage nicht zu überlasten. Unsere Branche wurde dadurch nicht ärmer werden. Doch jetzt zu meinem Weihnachtswunsch.

Ein hierarchisches System von Kontextobjekten

Gute Software benötigt gute fachliche Anforderungen.

Artikelübersicht
1. Teil	Ein Objekt-Aufgaben-Modell für das Requirements Engineering.
2. Teil	Der Ideenraum.
3. Teil	Themenobjekte ordnen Ideen in eine Roadmap.
4. Teil	Themen müssen einer Systemkontextanalyse unterzogen werden.
5. Teil	Ein hierarchisches System von Kontextobjekten.
6. Teil	Die Geschichten der Benutzer - User Stories erstellen.
7. Teil	Die Analyse des Problemraums führt zum Zielmodell.
8. Teil	Wie User Stories Use Cases gebären.
9. Teil	Szenarien setzen sich zu Use Cases zusammen.
10. Teil	Drei Perspektiven öffnen uns den Weg zu den Anforderungen.
11. Teil	Noch mehr Zusammenhänge durch die CRUD-Matrix.
12. Teil	Die Vielfalt der Szenarien.
13. Teil	Qualitätsanforderungen bilden einen Übergang zur Softwarearchitektur.
14. Teil	Ohne Abnahmekriterien läuft nichts.
15. Teil	Startschuss zur testgetriebenen Entwicklung.

Im letzten Artikel habe ich beschrieben, warum für Themenobjekte eine Systemkontextuntersuchung durchgeführt werden muss. Eigentlich wollte ich in diesem Post das Erstellen von User Stories beschreiben. Damit müssen wir jedoch noch einen Post warten, weil ich beim Reflektieren des Verhältnisses zwischen Kontextobjekt und inhärenten Unterobjekten Abhängigkeiten gefunden habe, die noch nicht beschrieben sind. Im Artikel Ordnung für Dokumente habe ich den Unterschied zwischen Quelldokumenten und Dokumenten, die gewonnene Informationen enthalten, beschrieben. Diese Formen der Dokumente stehen in einem engen Zusammenhang. Die gewonnene Information wird aus dem Quelldokument ermittelt.

Softwareentwurf ist ein organisierter Kreislauf

Prozessübersicht Softwareentwicklung

Artikelübersicht
1. Teil	Missing Links im Modell.
2. Teil	Gibt es einen eklatanten Wissensbruch in der Softwareentwicklung?
3. Teil	Entwurf und Bauen von Software – eine falsche Vorstellung.
4. Teil	Softwareentwurf ist ein organisierter Kreislauf.
5. Teil	In Softwareprojekten gibt es viel zu entdecken!
6. Teil	Die Interaktion mit dem Kontext ist ein wesentlicher Grund für den Erfolg eines Softwareprojektes.
7. Teil	Das unentdeckte Land oder wo noch nie ein Mensch gewesen.
8. Teil	Mit schlanken Methoden zu gewollter Software.
9. Teil	Die Flexibilität des Vorgehens schenkt laufende Verbesserungen.
10. Teil	Vom Problem seiner Rolle gerecht zu werden.
11. Teil	Wir gründen eine virtuelle Firma.
12. Teil	Warum ist unsere virtuelle Firma nur ein Torso?
13. Teil	Eine Arbeitsvorlage, ein strategisches Team und ein tolles Geschäft.
14. Teil	Ein fortgesetztes tolles Geschäft.

In einem Kommentar zum letzte Post wurde ich darauf hingewiesen, dass es nicht nur den Rücksprung zum Requirements Engineering geben darf. Wir können natürlich in jede Phase zurückspringen, in das Requirements Engineering genauso wie in die Softwarearchitektur oder die Implementierung. Nur ein sich ewiges Wiederholen des Bauens würde sich mir nicht erschließen. Auch können die Phasen verschieden lange dauern. Des weiteren kann es durchaus sein, dass verschiedene Teile des Teams oder Einzelleistungen in den Phasen gefragt sind. Eines muss jedoch klar sein: In welcher Phase befinde ich mich gerade? Die Vermischung der Phasen führt zu einer Vermischung des WAS mit dem WIE oder auch dem WIE im Großen (die Softwarearchitektur) mit dem WIE im Kleinen (das Softwaredesign, die Implementierung). Da kann es schon mal vorkommen, dass aus einem User Interface (einer Lösung, also ein WIE) Anforderungen abgeleitet werden (also das WAS). Das kann in ein und demselben Augenblick passieren.

Data Transfer Objects – ein Antipattern?

Praktisches Beipiel 2.2.3

Artikelübersicht
1. Teil	Das Data Transfer Object – Be or not to be.
2. Teil	Java Beans und Use Cases.
3. Teil	Data Transfer Objects – ein Antipattern?

In einer Anwendung treffen wir oft eine Trennung zwischen der Geschäftslogik und der Präsentation an. Die Präsentation greift auf die Geschäftslogik über definierte Schnittstellen zu. Diese definierte Schnittstelle können wir als Fassade implementieren. In der Fassade stellt die Businessschicht Zugriffsmethoden auf die Geschäftslogik bereit.

Wer kennt die Wahrheit der Entwickelung optimaler Software?

Allgemeines

Ich habe es mir zur Tradition gemacht den ersten Post des Monats für das Nachdenken über mein Tun zu nutzen und über Dinge, die mir bei meinem Tun begegnet sind. Kommentatoren zum Artikel Gibt es einen eklatanten Wissensbruch in der Softwareentwicklung hatten mir empfohlen, mich mit dem Buch "Software entwickeln mit Verstand" [DIER11] zu beschäftigen. Nachdem ich es gelesen habe, kann ich es zum Lesen und Reflektieren nur empfehlen. Es wird auf alle Fälle Einfluss haben auf nachfolgend erscheinende Artikel. Einer schwebt mir ganz fest im Kopf vor. Die Autoren stellen die Erstellung von Software als Wissensarbeit dar, bei der es eine dialektische Barriere zu überwinden gilt. "Eine dialektische Barriere liegt dann vor, wenn sowohl der Ausgangszustand, der Zielzustand als auch die Lösungsschritte ganz oder zumindest teilweise unbekannt sind." [S.30 DIER11] Was heißt es für den Einzelnen, für das Team und für die Interaktion mit der Umgebung, diese Barriere zu überwinden? Dazu finden sich eine Fülle von Ansätzen in diesem Buch.