Kurze Releasezyklen oder Releases-on-Demand? Der Usus in der technischen Entwicklung (Systems Engineering) geht eher in Richtung ein oder maximal zwei Releases pro Jahr. Ein häufiger Grund dafür, den wir in unseren Kundenprojekten beobachten, ist, dass die Dokumentation nicht auf dem aktuellen Stand ist und damit – zumindest in Bereichen, in denen die Dokumentation regulatorisch für ein Release erforderlich ist – kein Release stattfinden kann. Den ersten wichtigen Schritt, um dem entgegenzuwirken haben wir bereits im letzten Blogbeitrag unserer Serie zum agilen Systems Engineering beschrieben. Nämlich die systemische, gesamtheitliche Betrachtung dessen, was dazu erforderlich ist, um das Produkt auf den Markt zu bringen, z.B. eben die Dokumentation. Ein konkreter Ansatz, dem das Verständnis der Dokumentation als Teil des Produktes zu Grunde liegt, ist Continuous Documentation. Das Ziel: Die Dokumentation zu jedem Zeitpunkt der Entwicklung in einem potenziell releasebaren Stand zu halten, um dadurch den Gedanken des auslieferbaren Inkrements der agilen Softwareentwicklung auch im technischen Umfeld zu erfüllen.
WeiterlesenSchlagwort-Archive: Dokumentation
SOPHIST Workshop zum Thema „Sichten im Systems Engineering“ auf dem TdSE (Tag des Systems Engineering) – 16.11.2022, Paderborn
Die Gesellschaft für Systems Engineering e. V., kurz GfSE, hat diese Jahr wieder Ihren TdSE veranstaltet und SOPHIST war mit einem Workshop dabei. Zusammen mit der SAF-Arbeitsgruppe der GfSE – SAF steht für System Architecture Framework, haben wir gemeinsam den Workshop „Viewpoints, Sichten und Aspekte als Denkmodelle und Projekt Planungsmittel“ durchgeführt.
WeiterlesenAutomatisierte Testfallgenerierung: Wie Sie die Grundlage dafür schaffen können.
In unserer heutigen Welt läuft immer mehr automatisiert ab. Sei es die regelmäßige Fütterung der Haustiere, das Saugen mit einem Saugroboter zu bestimmten Zeiten oder das autonome Fahren, immer mehr wird in die Hände der Technik gegeben. Damit das aber auch so funktioniert wie man sich das wünscht, muss man eine klare, sinnvolle Basis schaffen, damit die Haustiere weder zu dick werden noch verhungern, der Saugroboter nicht mitten in der Nacht die Treppe runterknallt oder der Ausflug an den See nicht mit dem Auto im See endet.
WeiterlesenErkenntnisse aus Innovationsprojekt „Architektur im SE“
Im letzten Blogbeitrag haben wir Ihnen den Physical Viewpoint vorgestellt. In diesem und letzten Blogbeitrag der Blogreihe möchten wir unser Innovationsprojekt mit Ihnen Revue passieren lassen. Welche Erwartungen hatten wir? Was waren die Ziele und wurden diese erreicht? Vor welchen Herausforderungen standen wir und welche Lösungen haben wir gefunden? Welche Unterschiede gibt es zwischen dem bisherigen SOPHISTischen Ansatz und dem RFLP-Ansatz?
WeiterlesenRFLP: Physical Viewpoint
Das „P“ im RLFP-Ansatz von SPES2020
Im letzten Blogbeitrag haben wir Ihnen den Logical Viewpoint vorgestellt. Der Logical Viewpoint beschreibt, welche Informationen ein Architekturelement grundsätzlich empfangen, berechnen und bereitstellen muss. Dies ist nötig, um bei hoher technischer Varianz der Architekturelemente flexibel reagieren zu können. Jedoch lässt der Logical Viewpoint offen, um welche konkreten Architekturelemente es sich handelt. Der Logical Viewpoint gibt keine Aussagen über Hardwaredesignentscheidungen und konkrete Technologien. Diese und weitere Informationen hingegen liefert der Physical Viewpoint, den wir Ihnen heute vorstellen.
Ziel und Zweck
Weiterlesen