Besser spät als früh: Architekturentscheidungen

In den meisten Softwareprojekten wird angestrebt, die Architektur möglichst vollständig vorab zu spezifizieren. Doch eine einmal gefällte fundamentale Architekturentscheidung kann ein Korsett sein, aus dem man sich später nur noch mit großer Anstrengung oder gar nicht mehr befreien kann. Alternative Ansätze versuchen daher, architektonische Entscheidungen ganz bewusst zu verzögern und möglichst spät im Verlauf der Entwicklung zu fällen. Die Prämisse hierfür lautet: je später ich eine Entscheidung treffe, desto mehr Informationen stehen mir zur Verfügung, um sie auf eine solide Basis zu stellen. Obwohl solche Ideen bereits wiederholt proklamiert wurden und auch schon in der Praxis ihre Vorteile bewiesen haben, stoßen sie trotzdem noch häufig auf breiten Widerstand. In diesem Artikel wird gezeigt, was wirklich hinter dieser Idee steckt und für welche Teile eines Softwareprojektes späte Entscheidungen besonders geeignet sind. Des Weiteren wird erläutert, für welche Architekturentscheidungen größerer Aufwand betrieben werden sollte und für welche ein hoher Aufwand keinen signifikanten Wertbeitrag leistet.

Werkzeuge für Product Owner bei Bosch Rexroth

Wer als Produktmanager arbeitet oder die Rolle des Product Owner innehat, verwendet wahrscheinlich Microsoft Office Word, um Anforderungen aufzunehmen und zu dokumentieren, Excel, um Abschätzungen zu Kosten und Aufwand festzuhalten und Prioritäten zu vergeben, sowie ein Ticket-System oder Bug-Tracking-Tool, um mit Entwicklung und Qualitätssicherung zu kommunizieren. Leider haben diese Systeme keine gemeinsame Datenbasis: neben der Tatsache, dass die Daten mehrfach angelegt und gepflegt werden müssen, bedeutet jeder Übergang einen Informationsverlust. Einige Informationen stehen nur in Word, einige sind nur in Excel, andere sind nur im Ticket-System zu finden. Von den UML-Modellen, die mit Visio, Enterprise Architect oder ähnlichen Werkzeugen erstellt wurden, ganz zu schweigen. Der Product Owner zerreißt sich also zwischen diesen verschiedenen Tools der unterschiedlichen Ansprechpartner. Dieser Artikel zeigt, wie eine integrierte Werkzeugkette mit gemeinsamer, zentraler Datenbasis für die bekannten Tools aussehen kann.

Links und rechts des Weges: Qualitätssicherung ist mehr als Testfallverwaltung

Testen ist Teil eines komplexen Prozesses auf dem Weg von einer Idee oder einem Problem zu einer fertigen Software. Testen hat die Aufgabe, die Qualität der und das Vertrauen in die auszuliefernde Software sicherzustellen. Dabei kommen verschiedene Testtechniken und -methoden zum Einsatz: funktionale Tests, Beta- und Alpha-Tests, Akzeptanztests sowie entwicklernahe Testtechniken, wie Unit- und Integrationstests sind nur einige Beispiele.

“Traceagility” oder die Herausforderung ständig wandelnde Softwareprojekte nachzuverfolgen

In modernen Projekten wird vermehrt auf agile Methoden gesetzt und das mit steigendem Erfolg. Doch einige Bereiche wie die Traceability befinden sich nach wie vor in der Kritik. Wie behalten Sie in einem sich ständig wandelnden Anforderungskatalog den Überblick? Was bedeutet Traceability im Kontext eines agilen Softwareprojekts? Wie kann die Traceability in agilen und klassischen Projekten verbessert werden? Antworten auf diese Fragen erhalten Sie im nachfolgenden Artikel.

Hosting und Cloud – gleicher Inhalt, andere Verpackung?

Was ist der Unterschied zwischen einer Do-It-Yourself Homepage bei einem Webhoster und der Windows Azure Platform? Wann wählen Sie ein Hosting-Angebot und wann entscheiden Sie sich für eine Cloud-Plattform wie die Amazon Web Services oder Windows Azure? Cloud-Plattformen lassen sich von Hosting-Angeboten klar abgrenzen. Der Artikel stellt die Abgrenzungsfaktoren heraus und erleichtert die Evaluierung beider IT-Outsourcing-Möglichkeiten für Ihr Unternehmen. Dabei wird auf unterschiedliche Zielgruppen ebenso eingegangen wie auf die einzelnen Abstraktionsebenen der verschiedenen Angebote und deren Möglichkeiten.