CARDS+

Tag: Wissen (page 1 of 8)

Was beschreibt der Baustein Spec?

Agile Software-Entwicklung hat uns von einigen Zwängen der phasen-orientierten Prozesse befreit.

  • Wir müssen nicht mehr alles zu Beginn des Projektes wissen. Wir dürfen miteinander und voneinander lernen.
  • Wir haben keine getrennten Teams für Analyse, Entwicklung und Test. Wir lieben selbstorganisierte cross-funktionale Teams.
  • Niemand muss in einer Software-Fabrik arbeiten. Wir reden miteinander und entwickeln das unserer Meinung beste Produkt.

Trotzdem gibt es in agilen Prozessen den Bedarf für Anforderungsanalyse, Stakeholder-, Architektur- und Lizenzmanagent, auf jeden Fall in großen Unternehmen. Eine agile Projektorganisation bewegt sich immer in einem Spannungsfeld zwischen Selbstorganisation der Entwickler, verbunden mit der vollständigen Kontrolle über die Implementierung ihrer Komponenten, und der Einschränkung der Vielfalt der Lösung aufgrund übergreifender Ziele, internationaler Normen oder unternehmensweiter Vorgaben. Immer kontrovers!

Continue reading

Softwarearchitekturen dokumentieren und kommunizieren

Mein Fazit: Ziel des Buches ist es, den Leser viele wichtige Informationen und praktischen Beispiele in die Hand zu geben, um die Architektur jedes Software-Produktes angemessen zu beschreiben. arc42 zieht sich als roter Faden durch das Buch. Eine gute Wahl, wie ich finde. Ich musste aber schnell feststellen, dass der Autor wenig auf agile Methoden eingeht. Das ist eigentlich schade. Ich hatte die Hoffnung, dass der Autor den Kreis bei der Dokumentation größer zieht. Den gerade agile Methoden brauchen keine scharfe Trennung in fachliche Anforderungen und technische Dokumentation. Bei den Praxisbeispielen fehlen mir moderne Architekturen. Continue reading

Was beschreibt der Baustein Task?

Komplexe IT-Systeme bestehen aus Software, Middleware und Hardware. Der Betrieb eines IT-Systems stellt nicht erst seit der Idee der DevOps eine große Herausforderung an eine Betriebsorganisation. Moderne Systeme sind heterogen in vielerlei Hinsicht. Software wird von den Entwicklern in verschiedenen Programmiersprachen entwickelt. Eine Architektur mit Microservices oder die Verwendung der Cloud führt zu einer Vielzahl von Komponenten, die mit unterschiedlichen Technologien realisiert werden. Datenbanken haben relationale Modelle oder sind dokumenten- oder graphenbasiert. Verteilte Datenverarbeitung mit Events oder Microbatches spielt durch den Bedarf an Big-Data-Lösungen eine immer größere Rolle. Die Liste ließe sich noch fortsetzen.

Continue reading

Confluence macht es möglich!

Die Methode CARDS+ ist ein agiler Ansatz mit dem Ziel, Produktwissen strukturiert und mit hoher Qualität zu erfassen. Ohne Wiki wird die Umsetzung jedoch nicht gelingen. Confluence vom australischen Hersteller Atlassian ist so ein Wiki. Ein Confluence-Bereich ist sehr gut geeignet für den Aufbau einer Produktdokumentation. Confluence hat alle Funktionen, die notwendig sind für die Umsetzung der Methode CARDS+. Und mit dem Add-On-Konzept gibt es eine Vielzahl von Erweiterungsmöglichkeiten für das Wiki, z.B. Glossary, Scroll-Office, Scroll-Versions und die Integration von Gliffy, Draw.io oder Balsamiq.

Continue reading

CARDS+ in großen Unternehmen

Viele Unternehmen in Deutschland stehen vor der großen Herausforderung der digitalen Transformation. Sie wirkt sich auf alle Geschäftsfelder des Unternehmens aus. Die IT des Unternehmens muss in vielen Fällen überarbeitet werden. Themen wie systematische Analyse aller Daten des Unternehmens (big data, data mining, text mining) und darauf aufbauend Prognosen (predictive analytics, machine/deep learning) und Simulationen überfordern die jetzt im Einsatz befindlichen Systeme. Diese Bestandssysteme können nur mehr sehr aufwändig und langsam geändert werden, weil sie häufig komplexe Verbünde monolithischer Anwendungen sind. Schnelle Reaktionen auf sich ändernde Märkte oder Ziele des Unternehmens sind dann mit großen Risiken für die IT verbunden.

15 CARDS+ in großen Unternehmen

Continue reading

CARDS+ passt zu agiler Entwicklung

Das Ziel agiler Entwicklung ist es, den Entwicklungsprozess flexibler und schlanker zu machen, als das bei den klassischen Vorgehensmodellen der Fall ist. Man möchte sich mehr auf die zu erreichenden Ziele konzentrieren und auf technische und soziale Probleme bei der Entwicklung eingehen.

14 CARDS+ passt zu agiler Entwicklung

Continue reading

Sollen Begriffe für Code übersetzt werden?

Jede Software hat das Ziel, Probleme innerhalb eines Fachgebiets – der Domäne – für ihre Nutzer zu lösen. Beim Domain-Driven Design (kurz DDD) geht es nicht nur um die technische Umsetzung, sondern auch um unsere Denkweise beim Entwurf des Systems. DDD zusammen mit CARDS+ eröffnet weitere Optionen. Fachklassen (Entity und Aggregate) aus dem DDD sind eine ideale Ergänzung zum entsprechenden Begriff im Glossar. Das ist immens wichtig für die Bildung eines gemeinsamen Vokabulars im Projekt. Die gemeinsame Sprache ist ein wichtiges Ziel von CARDS+ und DDD.

Continue reading

Was beschreibt der Baustein Domain?

Software hat immer eine Struktur, unabhängig vom Architekturstil. Sind es bei monolithischen Systemen noch Schichten und Module, reden wir bei service- oder nachrichten-orientierten Systemen ganz allgemein von Diensten. Ein Dienst hat öffentliche Schnittstellen und eine Aufgabe. Schichten und Module werden zu Details der Implementierung eines Dienstes. Beim Domain-Driven Design (kurz DDD) nutzen wir den Begriff Module, um Ordnung und Übersichtlichkeit in ein Modell zu bringen. Ein weiterer Treiber für eine Struktur ist die Verwaltung von Code. Wir organisieren Code in Build-Projekten (z.B. mit gradle oder maven) und speichern Versionen davon in einem Code-Repository (z.B. git).

Kurz gesagt, es gibt eine ganze Reihe von Konzepten und Ansätzen, mit der wir eine Software strukturieren können. Ziel ist immer, die Komplexität der Software in den Griff zu bekommen, einen Überblick zu behalten.

Continue reading

Was beschreibt der Baustein Entity?

Unabhängig vom Architekturstil gibt es in jedem System Fachklassen bzw. ganz allgemein Informationsobjekte. Diese Objekte sind Datenspeicher (“etwas, das existiert”) oder repräsentieren einen aktuellen Zustand im System. Ein Informationsobjekt ist häufig mit einer Identität verbunden. Jede Software hat zum Ziel, Probleme innerhalb eines Fachgebiets – der Domäne – für ihre Nutzer zu lösen. Beim Domain-Driven Design (kurz DDD) geht es nicht nur um die technische Umsetzung, sondern auch um unsere Denkweise beim Entwurf des Systems. DDD zusammen mit CARDS+ eröffnet weitere Optionen. Informationsobjekte (Entity und Aggregate) aus dem DDD sind eine ideale Ergänzung zum entsprechenden Begriff im Glossar. Das ist immens wichtig für die Bildung eines gemeinsamen Vokabulars im Projekt. Die gemeinsame Sprache ist ein wichtiges Ziel von CARDS+ und DDD.

Spannend ist noch die Frage, ob wir bei der Implementierung des Domänenmodells die Begriffe ins Englische (der lingua franca der Entwickler) übersetzen sollen. Meine persönliche Empfehlung ist, keinen Begriff der Domäne zu übersetzen. Eine Übersetzung ins Englische widerspricht der Idee, dass Entwickler und Domänenexperten die selbe Sprache sprechen.

Continue reading

The minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.
Eric Ries

Continue reading

Olderposts

Copyright © 2018 Impressum Datenschutz

Zum Anfang ↑