Probleme

• grosse Projekte werden nicht als solche gestartet
• die grosse technologische Vielfalt erschwert optimale Auswahl
• schwierige Koordination der teamorientierten Softwareentwicklung
• manueller, fehleranfälliger Buildprozess
• kein reproduzierbarer Buildprozess vorhanden
• die Notwendigkeit von reproduzierbaren, automatisierten Tests nicht erkannt
• ein ungenügender Einsatz von Werkzeugen zur Qualitätssicherung
• nicht aktuelle und fehlerhafte Dokumentation der Entwicklung
• grosse Abhängigkeit von proprietären Produkten
• zu geringe Unterstützung bei Portierungsarbeiten

Entstehung

Durch den gleichzeitigen, aber voneinander unabhängigen Einstieg in komplexe J2EE-Projekte bildete sich die TKR-Community, welche dem Erfahrungs- und Knowhow-Austausch zwischen den drei Gründungsmitgliedern der heutigen OSCG diente. Im Verlaufe der Jahre entwickelte sich so ein gemeinsames Wissen, das wir in regelmässigen Meetings und auf elektronischem Wege über Websites, CVS Server oder Wiki untereinander austauschen.

Weg

Durch diesen Erfahrungsaustausch erkannten wir schon früh als fundamentales Bedürnis die Definition einer möglichst universellen aber dennoch einheitlichen Projektverzeichnisstruktur. Die gemeinsame und allgemeingültige Struktur ermöglicht nicht nur ein schnelles sich zurechtfinden in anderen Projekten - vielmehr liegt der Hauptgewinn darin, dass auch alle Tools die darauf arbeiten müssen zentral und einheitlich konfiguriert werden können.
Mittels klar definierten Vorausetzungen, die sogar automatisch geprüft werden können (OSCAR - unser Verifikator), können verschiedene ausgewählte Tools (OSCG-Toolset - unsere Preselection) integriert werden und man ist innert kürzester Zeit produktiv. Die Tools werden sorgfältig ausgewählt und laufend auf ihren Nutzen hin geprüft.
Es zeigte sich sofort, dass im Zentrum integrierende Tools wie Maven, ANT und Eclipse stehen. Weitere so genannte Standalone-Tools wurden nur wenn sie eine wichtige Lücke schliessen (z.B. CVS oder CygWin), oder sonst speziell Spass gemacht haben, beigefügt. Der Entwickler ist dann am produktivsten, wenn er eine Umgebung hat, die kann was er braucht und dazu auch noch ein paar Highlights bietet.
In Zukunft stellen wir uns vor, weitere "Best Practices" aus unseren Erfahrungen zu publizieren.

Wie geht es weiter?

Wir sind daran weitere Werkzeuge, Kompilationen von bewährten Tools (OSCG-Toolset) und "Best Practices" zu sammeln und werden diese fortlaufend auf dieser Seite veröffentlichen.