• Gründungsphilosophie

PERA Software Solutions GmbH wurde im Januar 2001 von Peter Most und Ralf Holly gegründet.

Die Gründung der Firma ging aus der Enttäuschung der beiden Geschäftsführer hervor, die sich in ihrem bisherigen Berufsleben ergab. In vielen Projekten, in denen sie mitwirkten, kam es immer wieder zur Wiederholung klassischer Fehler und Vernachlässigung der internen Softwarequalität. Aufgrund dieser zwei Faktoren kam es in fast allen Fällen zu erheblichen zeitlichen Verzögerungen, manchmal sogar zum völligen Scheitern der Projekte.

Ziel des Unternehmens ist es -- unter Berücksichtigung dieser Punkte -- Software termingerecht mit hoher äusserer und innerer Qualität zu entwickeln, und somit den langfristigen Produkterfolg zu gewährleisten.

• Vermeidung klassischer Fehler

Die einschlägige Software-Engineering Literatur hat über die letzten Jahrzehnte ein enormes Wissen aufgebaut. Renommierte Autoren wie Frederick P. Brooks, Gerald M. Weinberg, Tom DeMarco, Ed Yourdon und Steve McConnell haben in Dutzenden von Publikationen dargestellt, wie Software erstellt werden muss, um mit hoher Wahrscheinlichkeit im vorgegeben Zeitrahmen fertig zu werden. Dabei stehen nicht besondere Methodiken und Prozesse, wie z. B. CMM oder ISO-9000, im Vordergrund. Es wird vielmehr gesunder Menschenverstand angewendet und eine Reihe von Fehlern aufgezeigt, die immer wieder gemacht werden und letztendlich zum Scheitern vieler Projekte führen (sog. "Classic Mistakes" oder "Software Project Antipatterns"). Es gibt aber auch eine Vielzahl von "Do's", Vorgehensweisen, die ein Projekt zum Erfolg führen (sog. "Best Practices").

Obwohl diese Fakten seit Jahren und Jahrzehnten bekannt sind, haben wir die Erfahrung gemacht, dass in vielen Firmen -- auch in Großfirmen -- dieses Wissen nicht vorhanden ist. Das liegt zum einen daran, dass es üblicherweise nicht an Universitäten gelehrt wird. Darüber hinaus sind Softwareentwickler und Projektmanager nur selten bereit, in ihrer spärlichen Freizeit auch noch eine Vielzahl von Büchern zu lesen. Die dadurch vergebenen Chancen führen unnötig oft zum Scheitern von Projekten und hoher Fluktuation.

• Interne Softwarequalität

Ein weiterer, auf den ersten Blick als eher "low-level" und nicht ganz so wichtig erscheinender Aspekt ist die Vernachlässigung der internen Softwarequalität. Damit sind Faktoren gemeint, die -- im Gegensatz zur äußeren Qualität -- nicht vom Endbenutzer unmittelbar erkannt werden können, wie z. B. Lesbarkeit des Quelltextes, Robustheit, Modularität, und Wiederverwendbarkeit. Während die meisten Firmen durchaus Maßnahmen zur Sicherstellung einer relativ hohen äußeren Qualität ergreifen (z. B. durch umfangreiches Testen), wird die interne Qualität oft vernachlässigt.

In einer hektischen, schnellebigen Zeit, in der Schlagwörter wie "Time to Market" zählen, in der sich Produktspezifiaktionen oft ändern und nicht selten nur per Zuruf an die Entwickler weitergegeben werden, erscheint es geradezu paradox, sich Zeit für die interne Qualität zu nehmen. Häufig trifft man auf Haltungen wie: "Wichtig ist nur das, was der Endbenutzer zu sehen bekommt. Für interne Qualität haben wir -- wenn überhaupt -- nur später Zeit. Erst muss die erste Version dieses Produkts raus. Zuviel interne Qualität verzögert nur die Auslieferung".

Dieser weitere klassische Fehler ist einer der beliebtesten. In der Praxis verhält es sich nämlich genau andersherum. In den meisten Fällen dauert es nicht länger, Programme von hoher interner Qualität zu schreiben. Vielfach ist es z. B. schon in der gegenwärtigen Version möglich, Code wiederzuverwenden. Ebenso kann sich ein neuer Mitarbeiter, der dem Projekt erst später beitritt, wesentlich schneller in bestehenden Quelltext einarbeiten (und damit eher produktiv werden), wenn von seinen Kollegen Wert auf Lesbarkeit gelegt wurde. Auch eine hohe Erweiterbarkeit hat unmittelbare Vorteile, wenn sich die Anforderungen während der Programmierphase häufig ändern.

Der größte Nutzen hoher interner Qualität ergibt sich natürlich bei Folgeversionen. Laut David Parnas zieht ein Softwareprodukt immer Folgeversionen bzw. Varianten mit sich. Früher oder später sind neue Merkmale zu implementieren oder eine Portierung auf eine andere Plattform notwendig. Spätestens dann macht sich eine hohe interne Qualität bezahlt, da Folgeversionen wesentlich schneller auf den Markt gebracht werden können.

Natürlich ist es auch möglich, fehlende interne Qualität nachzurüsten. Wenn man davon ausgeht, dass ein Softwareprodukt viele Folgeversionen haben wird, ist dieser Schritt sogar empfehlenswert. Man muss sich jedoch im Klaren sein, dass dieses "Refactoring" wesentlich höhere Kosten verursacht, als wenn bereits von Anfang an Wert auf hohe interne Qualität gelegt worden wäre. Dennoch ist es immer noch billiger, als weiterhin "Pflaster" auf die Software zu kleben und zu riskieren, dass das bröckelige System unter den neuen Anforderungen zusammenbricht.

• Unsere Vorgehensweise

Aufgrund unserer großen Erfahrung im Bereich "modernes Software-Engineering" wissen wir, wie man vorgehen muss, um qualitativ hochwertige Software termingerecht fertig zu stellen. Wir legen unsere Schwerpunkte auf Vermeidung klassischer Fehler und Konzentration auf hohe interne Qualität. Speziell die Betonung der internen Qualität ist uns wichtig, da nur so gewährleistet werden kann, dass auch zukünftige Versionen mit hoher Kundenzufriedenheit termingerecht ausgeliefert werden können.

• Unsere Dienstleistungen

Wir sind bekennende "Software-Praktiker" und sind daher vornehmlich an Design und Programmierung von objektorientierter Software in C++ und Java interessiert. Dabei geht es uns nicht nur um die Durchführung von neuen Projekten. Natürlich übernehmen wir auch die Erweiterung und Verbesserung von bestehender Software ("Refactoring").

Zusätzlich bieten wir folgende Dienstleistungen an:

- Erarbeiten von Spezifikationen/Pflichtenheften
- Durchführung von Softwareprojekten vor Ort oder "off-site"
- Beratung und Schulung zum Thema "modernes Software-Engineering"
- Einführung qualitätsverbessernder Maßnahmen (Code Reviews, Coding Standards, Tools)
- Erstellung von Qualitätsgutachten (z. B. Bewertung der internen Qualität)
- Durchführung von Machbarkeitsstudien