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?
Meine Thesen gegen den Istzustand
Ich freue mich über jeden fachlich qualifizierten Kommentar und bedanke mich dafür im Voraus!
Sonntag, 29. Dezember 2013
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.
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.
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.
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
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.
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
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.
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.
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.
Abonnieren
Posts (Atom)