Development

You need more than just a run of the mill system? You're looking for further evaluation options for your database which your current system doesn't provide? You'd like to map process steps which your existing system doesn't take into account? Why not have us develop a system for you which is customized and in complete alignment with your needs? Just tell us what you need - we'll take of everything else!

Our Basic Philosophy

We develop software for business information systems and technical applications - individual, customized solutions which are effected in close cooperation with our clients. These systems are a matter of existential significance for both our customers and ourselves; for our customers because without them many of their business operations would come to a standstill, and for us because the development of these systems is our sole and primary business activity.

We have to develop good systems because our existence as a software house would otherwise be rendered moot. That's why producing software of high quality is not just a matter of paying lip service for us but is our daily reality put into practice by the contributions of each and everyone of our employees. 

Methods

For more than a decade the question of "phase models versus evolutionary models" has been the subject of passionate debate in professional circles. There is much to say in favour of the former, as well as the latter model.

That's why we try to make use of the advantages of both models, though the evolutionary approach plays a more dominant role in our work. If you would like to know the reasons for this, have a look here at a brief comparison between the two methods:

Die ewige Diskussion

Die Frage „Phasenmodell oder evolutionär?“ wird seit über einem Jahrzehnt in Fachkreisen leidenschaftlich diskutiert, neuerdings belebt durch die Gestaltung von Internetanwendungen und durch die Diskussion über Extreme Programming (XP). Dabei wird das Phasenvorgehen als Wasserfall- und das evolutionäre als Spiralmodell bezeichnet, abgeleitet von entsprechenden grafischen Darstellungen, die nur jeweils eine von mehreren Veranschaulichungen sind.

Betrachten wir zunächst das phasenweise Vorgehen. Die Abfolge Fachliche Spezifikation – Technisches Design – Modulimplementierung – Test ist natürlich keine strenge Sequenz, sondern wird vielfach aufgelöst durch Überlappung von Phasen, Überarbeitung von Ergebnissen früherer Phasen aufgrund von Erkenntnissen in späteren Phasen (Fehler, Verbesserungen, neue Anforderungen), Bildung von Stufen, d.h. von aufeinander aufbauenden Teilsystemen, die eigenständig betrieben werden können.

Die Verfechter des Spiralmodells behaupten gerne, das Wasserfallmodell sei altmodisch, weil Großrechner-orientiert und eine Bastion der zentralen DV-Abteilungen, die die Anwender nicht beteiligen wollen. Vor allem aber kritisieren sie, es laufe ohne Rückkopplungen von späteren in frühere Phasen ab, also ohne die Erkenntnisse zu nutzen, die man zwangsläufig im Projektverlauf gewinnt.

Unter evolutionärem Vorgehen verstehen wir die Entwicklung einer Folge von Prototypen, deren letzter im Regelfall das laufende System ist. Die Kernidee dabei ist, den Anwender früh und intensiv mit laufender Software zu konfrontieren (statt mit papierenen Spezifikationen), um damit Erfahrungen und Anforderungen für den jeweils nächsten Schritt zu gewinnen. Erfahrungen und Erkenntnisse während des Projekts fließen damit sofort in die Entwicklung ein.

Die Verfechter des Wasserfallmodells behaupten gerne, eine Entwicklung auf Basis des Spiralmodells sei unplanbar, könne daher nicht auf Festpreisbasis abgewickelt werden und hätte einen wesentlich höheren Integrationsaufwand, da sich die Software während des Projektes ständig ändert und neue Prototypen installiert werden müssen. Weiterhin würde wenig Wert gelegt auf Spezifikations- und Designdokumente, da die Programmierung ausgehend von Entwürfen der Benutzeroberfläche dominiere.

Und was lernen wir daraus?

Bei genauerem Hinsehen auf die praktische Vorgehensweise vieler Entwicklungsunternehmen stellten wir fest, dass jede der Methoden kaum so eingesetzt wird, wie sie in der Literatur beschrieben wird. Beim Wasserfallmodell werden über die Phasen einzelne Versionen von Systemen oder Teilsystemen entwickelt (eben wie Prototypen), damit Rückkopplungen möglich werden. Das Spiralmodell wird häufig von einer Dokumentation begleitet.

Wir entwickeln individuelle Software auf die Anforderungen unserer Kunden hin. Es liegt in der Natur praktisch veranlagter Menschen, lieber etwas anzufassen und damit zu arbeiten anstatt sich theoretisch alle möglichen Fälle auszudenken - das klappt auch bei hervorragend geplanten Projekten nicht, sobald etwas mehr Komplexität ins Spiel kommt.

Deshalb "mischen" auch wir die Methoden, wobei jedoch das evolutionäre Vorgehen eindeutig überwiegt.

Die wesentlichen Schritte sind:

  • Erstellung einer funktionalen Spezifikation (Lastenheft oder Grobspezifikation) am Beginn eines Projektes.
  • Angebot und Vereinbarung eines Festpreises (bei allen bisherigen Projekten wurde der Preis gehalten).
  • Entwicklung von Prototypen entsprechend der vereinbarten Prozess-Schritte und der kritischen Systemteile.
  • Erstellung der Design-Spezifikation parallel zur Entwicklung.
  • Test der Komponenten parallel zur Entwicklung.
  • Validierung der Systeme inkl. Gegenüberstellung Anforderung - Design - Testergebnis.
  • Integration und produktiver Einsatz von Teilsystemen und -funktionen.

Wir kommen bei dieser Methode zu hervorragenden Ergebnissen, da wir auf viele "fertige" und getestete Bausteine zurückgreifen können, die sich in vielen Projekten bewährt haben. Alle kritischen Elemente werden im Regelfall an den Anfang der Entwicklung gestellt und erreichen durch die gewählte Methode zwangsläufig am Ende des Projektes eine hohe Reife.

Wir halten die vereinbarten Festpreise, da auch bei dieser Vorgehensweise Vereinbarungen über den Funktionsumfang getroffen werden und ein Projektmanagement durchgeführt wird.

Wir wickeln damit auch große Projekte ab, weil sich die einzelnen Funktionsblöcke in überschaubare Phasen aufteilen lassen, welche dann für sich gesehen als Teilprojekte realisiert werden können.

Wie erreichen damit eine sehr hohe Identifikation der Anwender, da sich diese in die Entwicklung einbringen können und falsche Annahmen sofort erkannt und korrigiert werden können.

Share page: