Prüfliste: Softwarearchitekturdokument |
|
 |
Anhand dieser Prüfliste können Sie sicherstellen, dass das Softwarearchitekturdokument stabil, korrekt und vollständig ist. |
|
Beziehungen
Hauptbeschreibung
Prüflisteneinträge
Allgemein
Insgesamt hat das System eine solide Architektur, wenn folgende Bedingungen erfüllt
sind:
-
Die Architektur scheint stabil zu sein.
Die Notwendigkeit der Stabilität wird durch die Beschaffenheit der Konstruktionsphase vorgegeben. In dieser
Phase wird das Projekt normalerweise erweitert, es werden Entwickler hinzugefügt, die parallel arbeiten und
dabei nach Bedarf mit anderen am Produkt arbeitenden Entwicklern kommunizieren. Das Maß an Unabhängigkeit und
Parallelität, das bei der Konstruktion erforderlich ist, kann nicht erreicht werden, wenn die Architektur
instabil ist.
Die Wichtigkeit einer stabilen Architektur kann nicht deutlich genug betont werden. Geben Sie sich niemals mit
einem Kompromiss zufrieden - es ist immer besser, die Architektur richtig aufzubauen und die Konstruktionsphase
gegebenenfalls zu verschieben, als sie zu früh zu beginnen. Die Koordinationsprobleme, die beim Versuch, die
Architektur zu reparieren, auftreten können, während Entwickler versuchen, basierend auf eben dieser
Architektur ihre Arbeit zu tun, wiegen sehr viel schwerer als der Vorteil, der sich aus der Zeitersparnis
ergibt. Änderungen an der Architektur, die während der Konstruktion vorgenommen werden müssen, haben große
Auswirkungen, da sie in der Regel teuer, störend und demoralisierend sind.
Die echte Schwierigkeit bei der Bewertung der Stabilität der Architektur besteht in der Relativität des
Begriffs. Stabilität wird immer relativ zur erwarteten Änderung gemessen. Sie ist im Wesentlichen eine
subjektive Größe. Diese Subjektivität kann jedoch auf eine solidere Basis gestellt werden als nur Vermutungen.
Die Architektur selbst wird über Szenarios, die für die Architektur relevant sind, entwickelt. Dabei handelt es
sich um Untergruppen von Anwendungsfällen, die das technisch anspruchsvollste Verhalten repräsentieren, das vom
System unterstützt werden muss. Bei der Bewertung der Stabilität der Architektur wird darauf Wert gelegt,
sicherzustellen, dass die Architektur einen großen Bereich abdeckt, damit es bei ihrer weiteren Entwicklung
keine Überraschungen gibt.
Erfahrungen mit der Architektur können ebenfalls ein guter Indikator sein: Wenn die Änderungsrate in der
Architektur niedrig ist und niedrig bleibt, während neue Szenarios entwickelt werden, hat man Grund zu der
Annahme, dass die Architektur sich stabilisiert. Wenn dagegen jedes neue Szenario Änderungen in der Architektur
bewirkt, ist das ein Hinweis darauf, dass die Architektur noch in der Entwicklung begriffen ist und keine
Referenzierung gewährleistet werden kann.
-
Die Komplexität des Systems stimmt mit der bereitgestellten Funktionalität überein.
-
Die konzeptionelle Komplexität ist angemessen, Fachkenntnisse und Erfahrungen der folgenden Beteiligten
vorausgesetzt:
-
Benutzer
-
Bediener
-
Entwickler
-
Das System hat eine einzige konsistente, kohärente Architektur
-
Anzahl und Typen der Komponenten ist angemessen
-
Das System hat eine konsistente, systemweite Sicherheitseinrichtung. Alle Sicherheitskomponenten wirken zusammen,
um das System zu schützen.
-
Das System wird zum geplanten Termin verfügbar sein.
-
Die Architektur erlaubt die Wiederherstellung des Systems bei einem Fehler innerhalb des erforderlichen Zeitraums.
-
Entspricht die Lebensdauer der Produkte und Techniken, auf denen das System basiert, den Erwartungen?
-
Ein temporäres (taktisches) System mit einer kurzen Lebensdauer kann einfach mit alter Technologie erstellt
werden, da es bald nicht mehr gebraucht wird.
-
Ein System mit einer langen Lebenserwartung (das gilt für die meisten Systeme) sollte mit aktuellen
Technologien und Methoden erstellt werden, damit es zur Unterstützung zukünftiger Anforderungen verwaltet
und erweitert werden kann.
-
Die Architektur definiert klare Schnittstellen, um die Partitionierung für parallele teambasierte Entwicklung zu
ermöglichen.
-
Der Designer eines Modellelements kennt die Architektur gut genug, um das Modellelement entwerfen und entwickeln zu
können.
-
Der Paketansatz reduziert die Komplexität und verbessert das Verständnis.
-
Paketinhalte sind so definiert, dass sie in sich sehr stimmig sind, während die Pakete selbst nur lose miteinander
verbunden sind.
-
Ähnliche Lösungen in der einheitlichen Anwendungsdomäne wurden berücksichtigt.
-
Die vorgeschlagene Lösung ist leicht verständlich für jemanden, der allgemeine Kenntnisse der Aufgabendomäne
besitzt.
-
Alle Mitglieder des Teams teilen die Architektursicht mit dem Softwarearchitekten.
-
Das Softwarearchitekturdokument ist aktuell.
-
Die Richtlinien für Design wurden beachtet.
-
Alle technischen Risiken wurden entweder reduziert oder in einem Plan für unvorhersehbare Ereignisse
berücksichtigt. Neu ermittelte Risiken wurden dokumentiert und hinsichtlich ihrer potenziellen Auswirkungen
analysiert.
-
Die wichtigen Leistungskriterien (aufgestellte Budgets) wurden erfüllt.
-
Testfälle, Fehlersimulationen und Testkonfigurationen wurden definiert.
-
Die Architektur erscheint nicht überdimensioniert.
-
Die verwendeten Mechanismen erscheinen einfach genug für die Nutzung.
-
Die Anzahl der Mechanismen ist bescheiden und mit dem Systemumfang und den Anforderungen der Aufgabendomäne
konsistent.
-
Alle für die aktuelle Iteration definierten Anwendungsfallrealisierungen können von der Architektur ausgeführt
werden, wie in Diagrammen dargestellt. Diese Diagramme zeigen Folgendes:
-
-
Interaktionen zwischen Objekten
-
Interaktionen zwischen Aufgaben und Prozessen
-
Interaktion zwischen physischen Knoten.
|
Modelle
Gesamt
-
Partitionierung der Subsysteme und Pakete und deren Einteilung in Schichten ist logisch konsistent.
-
Alle Analysemechanismen wurden identifiziert und beschrieben.
Subsysteme
-
Die Services (Schnittstellen) von Subsystemen in höheren Schichten wurden definiert.
-
Die Abhängigkeiten zwischen Subsystemen und Paketen entsprechen Abhängigkeitsbeziehungen zwischen den
enthaltenen Klassen.
-
Die Klassen in einem Subsystem unterstützen die für das Subsystem identifizierten Services.
Klassen
-
Die wichtigen Entitätsklassen und deren Beziehungen wurden identifiziert.
-
Die Beziehungen zwischen den wichtigen Entitätsklassen wurden definiert.
-
Der Name und die Beschreibung der Klasse spiegelt eindeutig die Rolle der Klasse wider.
-
Die Beschreibung jeder Klasse erfasst genau die Zuständigkeiten der Klasse.
-
Die Entitätsklassen wurden dort, wo dies ratsam erschien, Entitätsklassen zugeordnet.
-
Die Rollennamen der Aggregationen und Zuordnungen beschreiben genau die Beziehung zwischen den
zusammengehörenden Klassen.
-
Die Vielfalt der Beziehungen ist korrekt.
-
Die wichtigen Entitätsklassen und deren Beziehungen sind konsistent mit Geschäftsmodell (falls vorhanden),
Domänenmodell (falls vorhanden), Anforderungen und Glossareinträgen.
Allgemeine Hinweise zum Modell
-
Der Detaillierungsgrad des Modells ist für die Zielsetzungen des Modells angemessen.
-
Für das Geschäftsmodell, das Anforderungsmodell oder das Designmodell werden Fragen der Implementierung während
der Ausarbeitungsphase nicht übermäßig betont.
-
Für das Designmodell besteht in der Konstruktionsphase ein guter Ausgleich zwischen den Funktionen in den
Modellelementen, wobei relativ einfache Elemente zur Erstellung eines komplexeren Designs zusammengestellt
werden.
-
Das Modell spiegelt die Vertrautheit und Kenntnis des gesamten Spektrums der Modellierungskonzepte für die
Aufgabendomäne wider. Für das aktuelle Problem werden Modellierungstechniken in angemessener Weise verwendet.
-
Konzepte werden so einfach wie möglich modelliert.
-
Das Modell wird einfach weiterentwickelt. Erwartete Änderungen können einfach berücksichtigt werden.
-
Gleichzeitig wurde darauf geachtet, das Modell nicht zu überdimensionieren. Denn der Versuch, jede noch so
unwahrscheinliche Änderung bei der Konzeption des Modells zu berücksichtigen, geht auf Kosten der Einfachheit
und Verständlichkeit.
-
Die wichtigen Annahmen, die hinter dem Modell stehen, sind dokumentiert und können von den Prüfern des Modells
erkannt werden. Wenn die Annahmen auf eine gegebene Iteration angewendet werden können, muss das Modell im
Rahmen dieser Annahmen weiterentwickelt werden können. Außerhalb des Kontextes dieser Annahmen ist dies nicht
notwendigerweise der Fall. Das Dokumentieren der Annahmen ist eine Möglichkeit, die Designer davor zu bewahren,
mögliche Anforderungen zu übersehen. In einem iterativen Prozess ist es unmöglich, alle möglichen Anforderungen
zu analysieren und ein Modell zu definieren, das alle zukünftigen Anforderungen handhaben kann.
|
Diagramme
-
Der Zweck des Diagramms ist klar definiert und einfach zu verstehen.
-
Das grafische Layout ist sauber und bringt alle benötigten Informationen klar zum Ausdruck.
-
Das Diagramm vermittelt gerade genug Informationen, als nötig sind, um das gesetzte Ziel zu erreichen, nicht
mehr.
-
Die Kapselung wird effektiv genutzt, um Details zu verdecken und die Klarheit zu verbessern.
-
Die Abstrahierung wird effektiv genutzt, um bestimmte Details zu verdecken und die Klarheit zu verbessern.
-
Die Platzierung von Modellelementen bringt Beziehungen effektiv zum Ausdruck, ähnliche oder eng miteinander
verbundene Elemente werden zusammengefasst.
-
Beziehungen zwischen Modellelementen sind einfach zu verstehen.
-
Die Kennzeichnung von Modellelementen trägt zum Verständnis bei.
|
Dokumentation
-
Jedes Modellelement hat einen deutlichen Zweck.
-
Es gibt keine überflüssigen Modellelemente, jedes spielt eine wesentliche Rolle im System.
|
Fehlerbehebung
-
Für jeden Fehler oder jede Ausnahmebedingung definiert eine Policy, wie das System wiederhergestellt und in
einen "normalen" Status versetzt werden soll.
-
Für alle möglichen Typen von Eingabefehlern seitens des Benutzers oder falsche Daten von externen Systemen
definiert eine Policy, wie das System wiederhergestellt und in einen "normalen" Status versetzt werden soll.
-
Es gibt eine konsistent angewendete Policy für die Behandlung von Ausnahmesituationen.
-
Es gibt eine Policy für die Behandlung fehlerhafter Daten in der Datenbank, die konsistent angewendet wird.
-
Es gibt eine Policy für die Behandlung der Nichtverfügbarkeit der Datenbank, die konsistent angewendet wird.
-
Für den Fall, dass Daten zwischen Systemen ausgetauscht werden, gibt es eine Policy, die festlegt, wie Systeme
ihre Datensichten synchronisieren.
-
Wenn das System redundante Prozessoren oder Knoten verwendet, um Fehlertoleranz oder hohe Verfügbarkeit
sicherzustellen, gibt es eine Strategie, die sicherstellt, dass nicht zwei Prozessoren oder Knoten gleichzeitig
sich als primäre Prozessoren oder Knoten verhalten bzw. gegenseitig blockieren können.
-
Die Fehlermodi für ein verteiltes System wurden identifiziert und Strategien für die Fehlerbehandlung
definiert.
|
Übergang und Installation
-
Der Prozess für das Upgrade eines vorhandenen Systems ohne Datenverlust oder Verlust der Betriebsbereitschaft
wurde definiert und getestet.
-
Der Prozess für die Datenkonvertierung, der von vorherigen Releases verwendet wurde, wurde definiert und
getestet.
-
Der Zeitraum und die Ressourcen, die für das Upgrade oder die Installation des Produkts erforderlich sind, sind
klar definiert und dokumentiert.
-
Die Funktionalität des Systems kann nur für jeweils einen Anwendungsfall aktiviert werden.
|
Verwaltung
-
Der Plattenspeicherplatz kann während des laufenden Betriebs reorganisiert oder wiederhergestellt werden.
-
Die Zuständigkeiten und Prozeduren für die Systemkonfiguration wurden identifiziert und dokumentiert.
-
Der Zugriff auf Betriebssystem- oder Verwaltungsfunktionen ist eingeschränkt.
-
Die Lizenzvoraussetzungen sind erfüllt.
-
Die Diagnoseroutinen können während des laufenden Systembetriebs ausgeführt werden.
-
Das System überwacht die Betriebsleistung selbst (z. B. den Schwellenwert für die Kapazität, den Schwellenwert
für die kritische Leistung, die Nichtverfügbarkeit von Ressourcen).
-
Die Maßnahmen, die beim Erreichen von Schwellenwerten ergriffen werden, werden definiert.
-
Die Policy zur Behandlung von Alarmnachrichten wird definiert.
-
Der Mechanismus zur Behandlung von Alarmnachrichten wird definiert, es wurden Prototypen entwickelt und
getestet.
-
Der Mechanismus zur Behandlung von Alarmnachrichten kann so optimiert werden, dass falsche oder
redundante Alarmnachrichten verhindert werden.
-
Die Policys und Prozeduren für die Netzüberwachung und -verwaltung werden definiert.
-
Fehler im Netz können isoliert werden.
-
Es gibt eine Ereignis-Trace-Funktion, die aktiviert werden kann, um die Fehlerbehebung zu erleichtern.
-
Der Systemaufwand der Funktion ist bekannt.
-
Das Verwaltungspersonal hat die Kenntnisse, die nötig sind, um die Funktion effektiv zu nutzen.
-
Für einen heimtückischen Benutzer ist Folgendes nicht möglich:
-
In das System einzudringen
-
Kritische Daten zu zerstören
-
Alle Ressourcen zu verbrauchen.
|
Leistung
-
Leistungsanforderungen sind angemessen und spiegeln echte Einschränkungen in der Aufgabendomäne wider. Ihre
Spezifikation ist nicht willkürlich.
-
Schätzungen der Systemleistung sind vorhanden (nach Bedarf mit einem Auslastungsanalysemodell modelliert), und
sie zeigen an, dass die Leistungsanforderungen keine wichtigen Risiken bedeuten.
-
Schätzungen der Systemleistung wurden mit Architekturprototypen überprüft, insbesondere hinsichtlich der
leistungskritischen Anforderungen.
|
Speicherauslastung
-
Es wurden Speicherbudgets für die Anwendung definiert.
-
Es wurden Maßnahmen ergriffen, um Speicherlecks zu ermitteln und zu verhindern.
-
Es gibt eine konsistent angewendete Policy, die definiert, wie das virtuelle Speichersystem verwendet,
überwacht und optimiert wird.
|
Kosten und Zeitplan
-
Die tatsächliche Anzahl der entwickelten Codezeilen stimmt mit den geschätzten Codezeilen am aktuellen
Meilenstein überein.
-
Die Annahmen für die Schätzung wurden überprüft und bleiben gültig.
-
Schätzungen bezüglich Kosten und Zeitplan wurden basierend auf den neuesten Projekterfahrungen und der
Produktivitätsleistung erneut berechnet.
|
Portierbarkeit
-
Die Anforderungen für die Portierbarkeit wurden erfüllt.
-
Die Richtlinien für die Programmierung bieten spezifische Anleitungen für die Erstellung von portierbarem Code.
-
Die Richtlinien für das Design bieten spezifische Anleitungen für das Design portierbarer Anwendungen.
-
Es wurde ein Port-Test durchgeführt, um die Anforderungen der Portierbarkeit zu überprüfen.
|
Zuverlässigkeit
-
Qualitätsmessungen (MTBF, Anzahl ausstehender Mängel etc.) wurden durchgeführt.
-
Die Architektur ermöglicht im Falle eines Schadens oder eines Systemausfalls die Wiederherstellung.
|
Sicherheit
-
Die Sicherheitsanforderungen wurden erfüllt.
|
Organisatorische Fragen
-
Sind die Teams gut strukturiert? Sind die Zuständigkeit gleichmäßig auf die Teams verteilt?
-
Gibt es geschäftspolitische, organisatorische oder administrative Fragen, die die Effektivität der Teams
einschränken?
-
Gibt es persönliche Konflikte innerhalb der Teams?
|
Anwendungsfallsicht
Der Abschnitt mit der Anwendungsfallsicht des Softwarearchitekturdokuments ist wie folgt beschaffen:
-
Jeder Anwendungsfall ist wichtig für die Architektur, wenn folgende Bedingungen zutreffen:
-
Der Fall ist von allergrößter Wichtigkeit für den Kunden.
-
Der Fall beeinflusst Schlüsselelemente in den anderen Sichten.
-
Der Fall ist ein Faktor für die Reduzierung eines oder mehrerer wichtiger Risiken einschließlich aller
anspruchsvollen nicht funktionalen Anforderungen.
-
Es gibt keine Anwendungsfälle, deren Aspekte die Architektur betreffend, schon in einem anderen Anwendungsfall
berücksichtigt wurden.
-
Die für die Architektur wichtigen Aspekte des Anwendungsfalls sind klar und verlieren sich nicht in Details.
-
Der Anwendungsfall ist klar und wird sich wahrscheinlich nicht hinsichtlich der Architektur ändern, oder dass
es gibt einen Plan, wie Klarheit und Stabilität zu erreichen sind.
-
Keine Anwendungsfälle, die für die Architektur wichtig sind, wurden ausgelassen (möglicherweise wurden einige
Analysen nicht für diese Sicht ausgewählt).
|
Logische Sicht
Der Abschnitt mit der logischen Sicht des Softwarearchitekturdokuments ist wie folgt beschaffen:
-
Er gibt eine genaue und vollständige Übersicht über die für die Architektur wichtigen Designelemente.
-
Er zeigt alle Architekturmechanismen, die im Design verwendet wurden, zusammen mit der entsprechenden
Begründung der einzelnen Optionen.
-
Präsentiert die Schichten des Designs zusammen mit der logischen Grundlage für die Partitionierung der
Schichten.
-
Präsentiert alle im Design verwendeten Gerüste oder Muster zusammen mit der logischen Grundlage, die für die
Auswahl der Muster oder Gerüste verwendet wurde.
-
Die Anzahl der für die Architektur wichtigen Modellelemente entspricht Größe und Umfang des Systems und ist so
angelegt, dass die wichtigsten aktiven Konzepte im System noch verständlich sind.
|
Prozesssicht
Ressourceneinsatz
-
Es wurden potenzielle Konkurrenzsituationen (Prozesswettbewerb um kritische Ressourcen) identifiziert und
Auflösungsstrategien definiert.
-
Es gibt eine definierte Strategie für die Handhabung einer vollen E/A-Warteschlange oder eine vollen Puffers.
-
Das System überwacht sich selbst (Schwellenwert für die Kapazität, Schwellenwert für kritische Leistung,
Nichtverfügbarkeit von Ressourcen) und ist in der Lage, bei Auftreten eines Fehlers eine Fehlerbehebung
durchzuführen.
Leistung
-
Für jede Nachricht wurden Anforderungen für Antwortzeiten identifiziert.
-
Es gibt einen Diagnosemodus für das System, der die Messung von Antwortzeiten ermöglicht.
-
Die nominalen und maximalen Leistungsanforderungen für wichtige Operationen wurden angegeben.
-
Es gibt verschiedenen Leistungstests, mit denen festgestellt werden kann, ob Leistungsanforderungen erfüllt
wurden.
-
Die Leistungstests prüfen das Verhalten des Systems bezüglich Start und Abschluss, alternativer und
außergewöhnlicher Ereignisabfolgen in den Anwendungsfällen sowie Systemausfallmodi.
-
Schwächen in der Architektur, die das Potenzial für Leistungsengpässe schaffen, wurden identifiziert. Folgende
Punkte wurden insbesondere betont:
-
-
Verwendung einiger begrenzter gemeinsam genutzter Ressourcen, wie z. B. Semaphore, Dateikennungen,
Sperren, Verriegelung, gemeinsam genutzter Speicher etc.
-
Prozessübergreifende Kommunikation. Kommunikation, die Prozessgrenzen überschreitet, ist immer
aufwändiger als Kommunikation in einem Prozess.
-
Prozessorübergreifende Kommunikation. Kommunikation, die Prozessgrenzen überschreitet, ist immer
aufwändiger als Kommunikation in einem Prozess.
-
Verwendung des physischen und virtuellen Speichers. Der Punkt, an dem das System nicht mehr ausreichend
physischen Speicher hat und virtuellen Speicher zu nutzen beginnt, markiert einen starken
Leistungsabfall.
Fehlertoleranz
-
Für den Fall, dass Primär- und Sicherungsprozesse verwendet werden, wurde das Risiko, dass mehrere Prozesse
sich als Primärprozesse verhalten, berücksichtigt, und es wurden bestimmte Aktionen im Design ausgeführt, um
diesen Konflikt zu lösen.
-
Es gibt externe Prozesse, mit denen das System in einen konsistenten Zustand zurückgeführt werden kann, wenn es
aufgrund eines Ereignisses wie eines Prozessfehlers in einen inkonsistenten Zustand versetzt wird.
-
Wenn das System eine Toleranz für Fehler und Ausnahmebedingungen hat, kann es in einen konsistenten Zustand
zurückgeführt werden.
-
Diagnosetests können während des laufenden Systembetriebs durchgeführt werden.
-
Für das System kann während des laufenden Betriebs ein Upgrade (Hardware, Software) durchgeführt werden, falls
erforderlich.
-
Es gibt eine Policy für die Handhabung von Alarmnachrichten im System, die konsistent angewendet wird. Die
Policy für Alarmnachrichten deckt folgende Bereiche ab:
-
-
Die Sensitivität des Mechanismus für die Erfassung von Alarmnachrichten.
-
Die Vermeidung falscher oder redundanter Alarmnachrichten.
-
Die Anforderungen der Mitarbeiter, die den Mechanismus zur Erfassung von Alarmnachrichten verwenden,
hinsichtlich Schulung und Benutzeroberfläche.
-
Die Leistung des Mechanismus zur Erfassung von Alarmnachrichten wurde bewertet und bewegt sich innerhalb
akzeptabler Leistungswerte, wie in den Leistungsanforderungen festgelegt.
-
Die Anforderungen hinsichtlich der Auslastung und Leistung wurden überprüft und erfüllt. In dem Fall, dass die
Leistungsanforderungen unrealistisch sind, findet eine Anpassung statt.
-
Speicherbudgets wurden, soweit sie vorhanden sind, identifiziert, und die Software wurde dahingehend überprüft,
dass sie diese Anforderungen erfüllt. Es wurden Maßnahmen ergriffen, um Speicherlecks zu ermitteln und zu
verhindern.
-
Es existiert eine Policy für die Verwendung des virtuellen Speichersystems einschließlich seiner Überwachung
und Optimierung.
Modularität
-
Die Prozesse sind so unabhängig voneinander, dass sie, falls erforderlich, prozessor- und knotenübergreifend
verteilt werden können.
-
Prozesse, die an einem Standort ausgeführt werden müssen (aufgrund der Leistungs- und Durchsatzanforderungen
oder des Mechanismus für Interprozesskommunikation, z. B. Semaphore oder gemeinsam genutzter Speicher) wurden
identifiziert. Außerdem wurde diskutiert, welche Auswirkungen es hätte, wenn diese Arbeitslast nicht verteilt
werden könnte.
-
Asynchrone Nachrichten, die verarbeitet werden können, wenn Ressourcen verfügbarer sind, wurden identifiziert.
|
Deployment-Sicht
-
Die Durchsatzanforderungen wurden durch die Verteilung der Verarbeitungslast auf die Knoten erfüllt, und
potenzielle Leistungsengpässe wurden berücksichtigt.
-
Wenn Informationen auf verschiedenen Knoten verteilt und potenziell repliziert wird, ist die Datenintegrität
sichergestellt.
-
Die Anforderungen für einen zuverlässigen Transport von Nachrichten wurden, soweit vorhanden, erfüllt.
-
Die Anforderungen für einen sicheren Transport von Nachrichten wurden, soweit vorhanden, erfüllt.
-
Die Verarbeitung wurde auf Knoten verteilt, um den Datenaustausch im Netz sowie die entsprechenden
Antwortzeiten zu minimieren. Das Ziel ist, Konsistenz zu gewährleisten und Ressourcenengpässe zu vermeiden.
-
Die Anforderungen für die Systemverfügbarkeit wurden, soweit vorhanden, erfüllt.
-
Die maximale Systemausfallzeit im Falle eines Server- oder Netzausfalls wurde festgelegt und bewegt
sich innerhalb akzeptabler Grenzen, wie durch die Anforderungen definiert.
-
Redundante und Standby-Server wurden definiert, damit nicht mehrere Server als Primärserver definiert
werden können.
-
Alle potenziellen Fehlermodi wurden dokumentiert.
-
Fehler im Netz können isoliert, diagnostiziert und aufgelöst werden.
-
Der Spielraum für die CPU-Nutzung wurde identifiziert und die Messmethode definiert.
-
Es gibt eine Policy, die die Aktionen festlegt, die bei Überschreiten der maximalen CPU-Belegung auszuführen
sind.
|
|
© Copyright IBM Corp. 1987, 2006. Alle Rechte vorbehalten.
|
|