| 

.NET C# Java Javascript Exception

5
Hi zusammen,
wir planen gerade im Unternehmen eine Neuauflage unserer Softwareprodukte (die wir an Endkunden verkaufen, also nicht inhouse nutzen). Die Wurzeln der aktuellen Version unserer Software liegen mindestens schon 20 Jahre zurück, dementsprechend könnt Ihr euch vorstellen wie der Code durch nachträglich hinzugekommene Anforderungen jetzt aussieht.

Wir planen die Software nun unter folgender Annahme: wir kennen die Anforderungen der Kunden und entwickeln Module die genau die Aufgaben bewältigen für die sie geschrieben wurden.

In unserer "alten" Software war es möglich, für bestimmte aufgaben vorgesehene Datenfelder mit völlig anderen (Kunden-Individuellen) Daten zu befüllen. Dem Kunden wurde das als "customizable" verkauft. Die dadurch entstehende Inkonsistenz möchten wir nun durch feste Vorgaben vermeiden.

Nun das Problem: Der Chef!

Als wir dem Boss unsere Planungsansätze vorgelegt haben hat er die Frage gestellt: "Und kann man dann auch wie bei Access oder Navision in einer Art Administratorkonsole neue Felder anlegen und auf die Formulare Ziehen?" (Das ganze dann natürlich mit (Datenbankstechnischen) Beziehungen zu unseren Daten)

Unser Ansatz ist natürlich, dass es gar nicht erst notwendig sein sollte eigene Datenfelder anzulegen, da wir ja vorher alle Details der Prozesse kannten und implementiert haben.

Ich frage mich nun ob es möglich ist diese Art von customizing von Daten, in Ralationen zu nicht-customizable - Daten in einer sauberen Art und Weise abzubilden.
News:
11.04.2014
Sweatdiver 126 1 6
1 Antwort
2
Wir planen die Software nun unter folgender Annahme: wir kennen die Anforderungen der Kunden und entwickeln Module die genau die Aufgaben bewältigen für die sie geschrieben wurden.

Erliegt nicht der Illusion, Ihr würdet die Anforderungen der Kunden kennen. Keiner kann das, nicht mal der Kunde ;-)
Unser Ansatz ist natürlich, dass es gar nicht erst notwendig sein sollte eigene Datenfelder anzulegen, da wir ja vorher alle Details der Prozesse kannten und implementiert haben.

Habt Ihr Euch gefragt, ob sich das der verantwortliche Entwickler vor 20 Jahren auch schon so gedacht hat?

Ich kenne weder Eure Domäne noch Euer Produkt, aber bei einer Neuentwicklung das gegenwärtige Wissen in Stein zu meisseln und zu hoffen, dass der Kunde keine neue Ideen hat, ist imho zum Scheitern verurteilt.

Ihr solltet eher analysieren, welche Teile der Applikation in den letzten 20 Jahren die größten Änderungen erfahren haben. Wenn Ihr das verstanden habt, wisst Ihr wesentlich genauer welche Variablen das Business Eures Kunden aufweist. Zumindest diese Teile der Applikation sollten nicht in Stein gemeisselt und auf wohlgewollte Entwicklervermutungen hin entwickelt werden, sondern mit einer Flexibilität versehen werden, die Euch erlaubt, auf die großen Probleme der letzten 20 Jahre mit einem müden Lächeln zu antworten.

Auch die Äußerungen Eures Chefs solltet ihr nicht per se als Problem auffassen, sondern besser versuchen, die Motivation hinter diesen Aussagen zu verstehen und zusätzliche Anforderungen abzuleiten, die Euer Oberhaupt an das Produkt hat.

Die saubere Art und Weise, die Du suchst, liegt also imho nicht primär in einer technischen Lösung (Relationen, Customizing, Daten). Das ist zu implementierungszentriert, also tief im Lösungsraum, statt im Problemraum gedacht.
11.04.2014
ffordermaier 8,4k 3 9
Vielleicht hab ich mich etwas missverständlich ausgedrückt.

Dass sich Anforderungen ändern, ist klar. Mir ging es eher darum, dass man eine Software für eine Konkrete Problemlösung entwickelt, die sich bei 100 Kunden gleichermaßen gut um das Problem kümmert.

Jeder dieser 100 Kunden hat aber seine eigenen, individuellen Merkmale und Kennzeichen die er gerne an bestimmte Entitäten hängen möchte, im Programm danach Filtern und letztlich statistisch auswerten will.

Btw. die Frage ob der verantwortliche Entwickler vor 20 Jahren auch so gedacht hat, kann ich eindeutig mit NEIN beantworten ;-)
Sweatdiver 12.04.2014

Stelle deine Software-architektur-Frage jetzt!