2. Randbedingungen
(engl.: Architecture Constraints) Nach den Architekturtreiber im Kapitel 1 sollten Sie hier alle Fesseln festhalten, die Software-Architekten in ihren Freiheiten bezüglich des Entwurfs oder des Entwicklungsprozesses einschränken.
Architekten sollten klar wissen, wo Ihre Freiheitsgrade bezüglich Entwurfsentscheidungen liegen und wo sie Randbedingungen beachten müssen. Randbedingungen können vielleicht noch verhandelt werden, zunächst sind sie aber da.
Nutzen Sie informelle Listen, gegliedert nach den Unterpunkten dieses Kapitels.
Im Idealfall sind Randbedingungen durch die Anforderungen vorgegeben, spätestens die Architekten müssen sich dieser Randbedingungen bewusst sein.
2.1 Technische Randbedingungen
(engl.: Technical Constraints) Tragen Sie hier alle technischen Randbedingungen ein. Zu dieser Kategorie gehören Hard- und Software-Infrastruktur, eingesetzte Technologien (Betriebssysteme, Middleware, Datenbanken, Programmiersprachen, ...).
Beispiele:
2.2 Organisatorische Randbedingungen
(engl.: Organizational Constraints) Tragen Sie hier alle organisatorischen, strukturellen und ressourcenbezogenen Randbedingungen ein. Zu dieser Kategorie gehören auch Standards, die Sie einhalten müssen, sowie juristische und gesetzliche Randbedingungen.
Mögliche Kategorien:
2.3 Konventionen
Fassen Sie unter dieser Überschrift alle Konventionen zusammen, die für die Entwicklung der Software-Architektur relevant sind.
Entweder die Konventionen als Kapitel hier direkt einhängen oder aber auf entsprechende Dokumente verweisen.
(engl.: Architecture Constraints) Nach den Architekturtreiber im Kapitel 1 sollten Sie hier alle Fesseln festhalten, die Software-Architekten in ihren Freiheiten bezüglich des Entwurfs oder des Entwicklungsprozesses einschränken.
Architekten sollten klar wissen, wo Ihre Freiheitsgrade bezüglich Entwurfsentscheidungen liegen und wo sie Randbedingungen beachten müssen. Randbedingungen können vielleicht noch verhandelt werden, zunächst sind sie aber da.
Nutzen Sie informelle Listen, gegliedert nach den Unterpunkten dieses Kapitels.
Im Idealfall sind Randbedingungen durch die Anforderungen vorgegeben, spätestens die Architekten müssen sich dieser Randbedingungen bewusst sein.
2.1 Technische Randbedingungen
(engl.: Technical Constraints) Tragen Sie hier alle technischen Randbedingungen ein. Zu dieser Kategorie gehören Hard- und Software-Infrastruktur, eingesetzte Technologien (Betriebssysteme, Middleware, Datenbanken, Programmiersprachen, ...).
Beispiele:
- Hardware-Infrastruktur: Prozessoren, Speicher, Netzwerke, Firewalls und andere relevante Elemente der Hardware- Infrastruktur
- Software-Infrastruktur: Betriebssysteme, Datenbanksysteme, Middleware, Kommunikationssysteme, Transaktionsmonitor, Webserver, Verzeichnisdienste
- Systembetrieb: Batch- oder Onlinebetrieb des Systems oder notwendiger externer Systeme?
- Verfügbarkeit der Laufzeitumgebung: Rechenzentrum mit 7x24h Betriebszeit? Gibt es Wartungs- oder Backupzeiten mit eingeschränkter Verfügbarkeit des Systems oder wichtiger Systemteile?
- Grafische Oberfläche: Existieren Vorgaben hinsichtlich grafischer Oberfläche (Style Guide)?
- Bibliotheken, Frameworks und Komponenten: Sollen bestimmte „Software-Fertigteile“ eingesetzt werden?
- Programmiersprachen: Objektorientierte, strukturierte, deklarative oder Regelsprachen, kompilierte oder interpretierte Sprachen?
- Referenzarchitekturen: Gibt es in der Organisation vergleichbare oder übertragbare Referenzprojekte?
- Analyse- und Entwurfsmethoden: Objektorientierte oder strukturierte Methoden?
- Datenstrukturen: Vorgaben für bestimmte Datenstrukturen, Schnittstellen zu bestehenden Datenbanken oder Dateien
- Programmierschnittstellen: Schnittstellen zu bestehenden Programmen
- Programmiervorgaben: Programmierkonventionen, fester Programmaufbau
- Technische Kommunikation: Synchron oder asynchron, Protokolle
- Betriebssystem und Middleware: Vorgegebene Betriebssysteme oder Middleware
2.2 Organisatorische Randbedingungen
(engl.: Organizational Constraints) Tragen Sie hier alle organisatorischen, strukturellen und ressourcenbezogenen Randbedingungen ein. Zu dieser Kategorie gehören auch Standards, die Sie einhalten müssen, sowie juristische und gesetzliche Randbedingungen.
Mögliche Kategorien:
- Organisation und Struktur
- Ressourcen (Budget, Zeit, Personal)
- Organisatorische Standards
- Juristische und gesetzliche Faktoren
- Organisationsstruktur beim Auftraggeber: Droht Änderung von Verantwortlichkeiten? Änderung von Ansprechpartnern?
- Organisationsstruktur des Projektteams: mit/ohne Unterauftragnehmer, Entscheidungsbefugnis der Projektleiterin
- Entscheidungsträger: Erfahrung mit ähnlichen Projekten, Risiko-/Innovationsfreude
- Bestehende Partnerschaften oder Kooperationen: Hat die Organisation bestehende Kooperationen mit bestimmten Softwareherstellern? Solche Partnerschaften geben oftmals Produktentscheidungen (unabhängig von Systemanforderungen) vor.
- Eigenentwicklung oder externe Vergabe: Selbst entwickeln oder an externe Dienstleister vergeben?
- Entwicklung als Produkt oder zur eigenen Nutzung? Dies bedingt andere Prozesse bei Anforderungsanalyse und Entscheidungen. Im Fall der Produktentwicklung: Neues Produkt für neuen Markt? Verbessertes Produkt für bestehenden Markt? Vermarktung eines bestehenden (eigenen) Systems? Entwicklung ausschließlich zur eigenen Nutzung?
- Festpreisprojekt oder Abrechnung nach Zeit und Aufwand?
- Zeitplan: Wie flexibel ist der Zeitplan? Gibt es einen festen Endtermin? Welche Stakeholder bestimmen den Endtermin?
- Zeitplan und Funktionsumfang: Was ist höher priorisiert, der Termin oder der Funktionsumfang?
- Release-Plan: Zu welchen Zeitpunkten soll welcher Funktionsumfang in Releases/Versionen zur Verfügung stehen?
- Projektbudget: Fest oder variabel? In welcher Höhe verfügbar?
- Budget für technische Ressourcen: Kauf oder Miete von Entwicklungswerkzeugen (Hardware und Software)?
- Team: Anzahl der Mitarbeiter und deren Qualifikation, kontinuierliche Verfügbarkeit.
- Vorgehensmodell: Vorgaben bezüglich Vorgehensmodell? Hierzu gehören auch interne Standards zu Modellierung, Dokumentation und Implementierung.
- Qualitätsstandards: Fällt die Organisation oder das System in den Geltungsbereich von Qualitätsnormen (wie ISO-9000)?
- Entwicklungswerkzeuge: Vorgaben bezüglich der Entwicklungswerkzeuge (etwa: CASE-Tool, Datenbank, Integrierte Entwicklungsumgebung, Kommunikationssoftware, Middleware, Transaktionsmonitor).
- Konfigurations- und Versionsverwaltung: Vorgaben bezüglich Prozessen und Werkzeugen
- Testwerkzeuge und -prozesse: Vorgaben bezüglich Prozessen und Werkzeugen
- Abnahme- und Freigabeprozesse (für Datenmodellierung und Datenbankdesign, Benutzeroberflächen, Geschäftsprozesse/Workflows, Nutzung externer Systeme, etwa: schreibender Zugriff bei externen Datenbanken)
- Service Level Agreements: Gibt es Vorgaben oder Standards hinsichtlich Verfügbarkeiten oder einzuhaltender Service-Levels?
- Haftungsfragen (Hat die Nutzung oder der Betrieb des Systems mögliche rechtliche Konsequenzen? Kann das System Auswirkung auf Menschenleben oder Gesundheit besitzen? Kann das System Auswirkungen auf Funktionsfähigkeit externer Systeme oder Unternehmen besitzen?)
- Datenschutz: Speichert oder bearbeitet das System „schutzwürdige“ Daten?
- Nachweispflichten: Bestehen für bestimmte Systemaspekte juristische Nachweispflichten? Hinsichtlich der SOX-Diskussion der letzten Jahre gewinnt dieser Punkt stetig an Bedeutung!
- Internationale Rechtsfragen: Wird das System international eingesetzt? Gelten in anderen Ländern eventuell andere juristische Rahmenbedingungen für den Einsatz (Beispiel: Nutzung von Verschlüsselungsverfahren)?
2.3 Konventionen
Fassen Sie unter dieser Überschrift alle Konventionen zusammen, die für die Entwicklung der Software-Architektur relevant sind.
Entweder die Konventionen als Kapitel hier direkt einhängen oder aber auf entsprechende Dokumente verweisen.
- Programmierrichtlinien
- Dokumentationsrichtlinien
- Richtlinien für Versions- und Konfigurationsmanagement
- Namenskonventionen