Sonntag, 29. Dezember 2013

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?

Dienstag, 24. Dezember 2013

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.

Donnerstag, 19. Dezember 2013

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.

Samstag, 14. Dezember 2013

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.

Montag, 9. Dezember 2013

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.

Mittwoch, 4. Dezember 2013

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.