Evaluierung von Softwarearchitekturen

Kostengründen oder aus anderen Gründen. Die wohl einfachste Weise, künftige Erweiterungen zu erkennen, ist die Einschränkungen auf ihre Plausibilität zu überprüfen. Auch ein Vergleich mit bereits existierender Software ist ein guter Ansatz, den üblichen Leistungsumfang des geforderten Softwaretyps zu ermitteln. So ist die Begrenzung der Zielgruppe auf Profispieler möglicherweise dann ein Problem, wenn diese Zielgruppe zu klein ist oder nur wenige Profispieler bereit sind sich zu registrieren, um die Plattform wirtschaftlich zu betreiben. Werden jedoch auch Freizeitspieler zugelassen, so wird eine Plausibilitätsüberprüfung der Züge notwendig. Der Algorithmus, der für die Überprüfung zuständig ist, kann jedoch auf einfache Weise vom System entkoppelt werden, wenn das Entwurfsmuster ‚Strategy’ angewendet wird. Da diese Funktion jedoch gar nicht vorgesehen ist, kann vorerst mit einem ‚leeren’ Algorithmus gearbeitet werden, der durch einen anderen ersetzt wird, sollte der Erweiterungswunsch auftauchen. Die Kosten für diese Lösung sind geringer, als das nachträgliche Schaffen passender Schnittstellen. Die fehlende Schnittstelle zu Fremdsystemen könnte schon eher ein Problem werden. Gerade Spieler im Profibereich werden wohl mehrere Programme nutzen. Hier muß also geprüft werden, ob ein Standard zum Datenaustausch zwischen Schachprogrammen überhaupt existiert und wenn ja, wie dieser definiert ist.8 Das geplante Software-System sollte also zumindest die für dieses Format erforderlichen Daten erfassen und bereithalten. Eine einfache Import- und Exportfunktion läßt sich so nachträglich relativ leicht erstellen. In der Projektbeschreibung ist der Aspekt der Administration des Systems überhaupt nicht berücksichtigt. Eine Community muß aber administriert werden, mindestens jedoch muß die Möglichkeit bestehen, Nutzer zu sperren, die ihren Beitrag nicht bezahlt oder die gekündigt haben. Der direkte Zugriff auf die dafür vorgesehenen Datenbankrelationen ist zwar möglich, erfordert aber doch einige Sachkenntnis und birgt die Gefahr der Fehlbedienung. Eine sicher notwendige Erweiterung wäre also eine Administrationsoberfläche. Der letzte Punkt, die nicht benötigte Schach-Engine, wird wohl nicht als Erweiterungswunsch auftauchen, da dadurch der Charakter des Programms (eine Community) stark verändert würde. Die Erweiterung wird deshalb nicht weiter eingeplant. Falls doch gewünscht, läßt sich eine Schach-Engine einfach als weiterer Benutzer in das System integrieren. Vorsichtshalber legt man daher einen Benutzer [...]

Spieler können live gegeneinander spielen. Livespiele können zeitlich begrenzt werden, d.h. spielen gegen die Stoppuhr. Bei Livespielen kann zugeschaut werden. Die Spieler können bei einem Livespiel Audio benutzen, um sich zu unterhalten. Die Spiele werden gespeichert. Gespeicherte Spiele können geladen und analysiert werden. Spiele sollen jedoch auch zeitversetzt möglich sein, das System sendet bei Änderungen des Spielstands eine e-Mail an den gegnerischen Spieler. Spiele können Wettkampf- oder Übungsspiele sein. Nach abgeschlossenen Wettkampfspielen wird der ELO7 der Spieler automatisch neu berechnet. Ein Spieler kann die Eröffnung des Gegners mit den in der Datenbank gespeicherten Spielen bis zu einer bestimmten Tiefe abgleichen, um so festzustellen, ob der Gegner möglicherweise einen Schachcomputer oder sonstige Hilfen verwendet. [...]

Ein häufig auftretendes Problem ist, daß aus Kosten- oder anderen Gründen von vornherein Einschränkungen im Leistungsumfang gemacht werden. Im späteren Betrieb der Software erweisen sich diese Einschränkungen dann als massive Störungen, die beseitigt werden müssen. Ein guter Ansatz ist daher, die Anwendungsfälle so umfassend wie möglich auszuarbeiten, so daß künftige Erweiterungswünsche erkannt werden können und entsprechende Schnittstellen und Datenstrukturen vorbereitet, bzw. Räume dafür geschaffen werden können. Je gründlicher diese Ausarbeitung ist, desto weniger Überraschungen ergeben sich während der Entwicklungsphase. Die Mehrkosten für eine gründlichere Analyse der Anforderungen und Planung der Anwendungsfälle amortisieren sich erfahrungsgemäß mit der ersten Erweiterung des Systems. Der Kunde erkennt neue Möglichkeiten, trotz seiner umfassenden Fachkenntnis, oft erst im Zuge der Entwicklung. Auch dies ist ein guter Grund, Anwendungsfälle umfassend zu planen. Ausufernde Kosten und ungeplant wuchernde Systeme lassen sich so vermeiden. 3.2 Projektbeschreibung [...]