Individualsoftware

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen

Individualsoftware (auch Individuallösung) ist ein Begriff der Informationstechnik, welcher eine individuell, d. h. für einen bestimmten Anwender angefertigte Anwendungssoftware bezeichnet.[1][2] Sie zeichnet sich dadurch aus, dass sie maßgeschneidert gemäß den Anforderungen eines einzelnen Auftraggebers erstellt wird – im Gegensatz zu Standardsoftware, die für eine größere Menge (potenzieller, zum Teil noch unbekannter) Anwender entwickelt wird.

Individualsoftware wird entweder von den Softwareentwicklern eines Unternehmens oder einer Institution, ggf. auch von Privatanwendern, erstellt oder bei einem externen Dienstleister für Softwareentwicklung in Auftrag gegeben. Eine Mischform aus beiden ist, wenn für spezielle Aufgabenstellungen („Spezialisten“) oder zum Ausgleich fehlender Entwicklungskapazitäten externe Dienstleister für das Projekt beauftragt werden. Typische Anwender von Individualsoftware sind Einrichtungen, die spezifische Anforderungen an ihre Software haben, für die keine exakt passenden marktgängigen Softwareprodukte verfügbar sind.

Erstellung und Pflege von Individuallösungen, ggf. auch der Betrieb und andere IT-Dienstleistungen werden oft, durch entsprechende Verträge in ihren Details festgelegt, an externe IT-Unternehmen ausgelagert. Die Auftraggeber sind dann Kunden dieser Dienstleister, bleiben aber Eigentümer der Software. Je nach Umfang der extern vergebenen Aktivitäten kann die Auslagerung rechtlich über einen Werkvertrag (bei weitgehend autonomer externer Erstellung) oder über einen Dienstvertrag abgewickelt werden.

Gründe für die Entscheidung für eine Individuallösung

[Bearbeiten | Quelltext bearbeiten]

Wenn sich ein Unternehmen für die Erstellung einer Individualsoftware entscheidet, kann dies unterschiedliche, einander nicht ausschließende Gründe haben:

  • Es gibt keine bekannte, geeignete Standardsoftware.
  • Die Kosten einer Individualsoftware werden niedriger geschätzt als die einer Standardsoftware.
  • Man möchte sich nicht an einen Softwareanbieter binden (Lock-in-Effekt), sondern die Kontrolle über die künftige Entwicklung der Software sicherstellen.
  • Die eigene Software soll dem Unternehmen Wettbewerbsvorteile gegenüber Mitbewerbern verschaffen (Funktionalität, Flexibilität, Stabilität).
  • Man möchte, obwohl es Standardprodukte für den angestrebten Zweck gibt, eine besser passende Lösung entwickeln (z. B. organisatorische und technische Eigenheiten/Anforderungen des Unternehmens individuell berücksichtigen).

Weitere Argumente/Gründe siehe auch [1] und [2].

Vorgehensweise und eingesetzte Technologien

[Bearbeiten | Quelltext bearbeiten]

Das einzige begriffsbildende Kriterium für den Begriff „Individualsoftware“ (ISW) ist, dass sie individuell – zum Einsatz bei einem bestimmten Anwender (i. S. von Auftraggeber/Eigentümer) – entwickelt wurde. Im Hinblick auf die Vorgehensweise bei der Softwareentwicklung (Vorgehensmodelle, eingesetzte Entwicklungsmethoden, Werkzeuge und Architekturen) muss sich diese deshalb nicht grundsätzlich und zwangsläufig vom Vorgehen bei Standardsoftware (SSW) unterscheiden. Die in mehr oder weniger vielen Details unterschiedlichen Eigenschaften von SSW und ISW (siehe z. B. in [2]) machen jedoch auch andere Vorgehensweisen erforderlich oder möglich. Beispiele:

Projektauslöser

Initiiert wird ein Projekt für ISW zumeist dann, wenn Anforderungen auftreten, die von existierender SSW nicht erfüllt werden, und wenn die Erweiterung der bisherigen Lösung (gleichgültig ob ISW oder SSW) nicht praktikabel ist.

Lasten- und Pflichtenheft

Die Anforderungen an die Software werden aus der Sicht eines einzigen Auftraggebers formuliert. Sie beziehen sich deshalb auf (nur) dort vorhandene Gegebenheiten, eine umfassende Anpassungsfähigkeit an Gegebenheiten bei unterschiedlichen Anwendern ist nicht erforderlich.[2] Gewünschte spätere Anpassungsmaßnahmen müssen bei SSW über einen ggf. langwierigen Genehmigungsprozess laufen, bei ISW ist ihre Umsetzung dagegen einfacher möglich, muss aber vom Anwender selbst geleistet oder beauftragt werden.

Technische Umgebungsbedingungen

In der Regel wird ISW für eine definierte technische Systemumgebung (wie JEE oder .Net-Framework etc.) erzeugt. Flexibilität bezüglich möglicher funktionaler Anpassungen muss nicht, kann aber, beispielsweise durch Parametrisierung, vorgesehen sein.

Qualität der Lösung

ISW kann exakt auf die Anforderungen und Gewohnheiten beim Anwender ausgerichtet werden. Ihre Benutzerschnittstellen finden oft eine höhere Akzeptanz bei den Benutzern[2] als eine ungewohnte und evtl. funktional überdimensionierte SSW. Häufig verfügen die Entwickler eines SSW-Herstellers über mehr Erfahrung. Fehler, die z. B. bei einem Anwender entdeckt wurden, können behoben und die SSW in Form eines Updates allen anderen zur Verfügung gestellt werden.[2]

Dokumentation

Da eine SSW so dokumentiert sein muss, dass ihr Inhalt von vielen Benutzern/Anwendern verstanden wird, ist sie in den meisten Fällen umfassender und systematischer gegliedert (lt. Seite 9 in [2]: „Volumen und Qualität des Handbuchs“) als eine Dokumentation, die nach den Regeln und Gewohnheiten eines einzelnen Unternehmens erzeugt wird.

Technische Einführung

Die bei SSW üblichen Installationsprogramme sind bei ISW häufig nicht oder nur in einfacher Form vorhanden, weil keine oder nur wenige Customizingfunktionen erforderlich sind, und weil die Software mit den gegebenen Verfahren der Zielumgebung installiert werden kann.

Vergleicht man Individualsoftware mit dem Erwerb einer Standardsoftware, so sind bei ISW die Kosten für Entwicklung, Pflege und Wartung die in der Regel von nur einem einzigen Auftraggeber aufzubringen. Diesem Aufwand stehen die periodisch zu zahlenden Lizenzkosten für SSW gegenüber, wobei der ggf. deutlich höhere Entwicklungsaufwand auf viele Nutzer/Anwender umgelegt werden kann.

Als Mischform kann mit Techniken wie Aspektorientierte Programmierung oder Feature Oriented Programming individuelle Software aus fertigen Standard-Komponenten sowie individuellen Spezial-Komponenten zusammengesetzt werden.

Kostensenkende Faktoren

[Bearbeiten | Quelltext bearbeiten]

Es gibt Kostenfaktoren, die bei der Entwicklung und dem Betrieb von Individualsoftware nicht oder nur in geringerem Maße anfallen. Diese können sein:

  • Die Software muss ggf. nur für eine begrenzte Anzahl an Benutzern/Arbeitsplätzen eingesetzt werden; Standardlösungen wären deshalb evtl. überdimensioniert und beanspruchen höhere Betriebsressourcen.
  • Daher können auch die Kosten für Hilfs- und Unterstützungsleistungen („Support“) gegenüber der Vielzahl von Benutzern bei Standardsoftware bei der Individualsoftware geringer ausfallen. Oft besteht für die Benutzer ein schnellerer und einfacherer Zugang zu Unterstützung leistenden Personen/Stellen.
  • Die Kosten für Benutzerdokumentationen können geringer sein – wenn man davon ausgehen kann, dass die Benutzer im Entwicklungsprozess eingebunden waren/sind, deshalb die Funktionalität kennen und oft auch auf die Gestaltung der Oberfläche Einfluss genommen haben.
  • Standardisierungsgrad und Flexibilität der Software müssen weniger ausgeprägt sein. Das heißt, die Software muss nur die individuell erforderliche Funktionalität bieten. Auch muss sie bezüglich der Systemlast oft nur einer geringeren Anzahl von Anwendungsfällen gerecht werden und muss nicht auf unterschiedlichen Systemumgebungen lauffähig sein.
  • Bei Individualsoftware sind die Prozesse zur Fehlerbearbeitung und der anschließenden Softwareverteilung oft sehr viel einfacher: Fehlermeldung, Fehlerbehebung und Bereitstellung einer neuen Version können schneller vonstattengehen.
  • Auf eine Installationssoftware kann oft verzichtet werden. Bei Standardsoftware ist dagegen ein Mechanismus, in der Regel ein Installationsprogramm, Bestandteil des Vertriebsapparates, das die fehlerfreie und automatische Installation auf den Zielsystemen durch in der Regel Laien ermöglicht. Dieser Mechanismus muss mit einer Vielzahl von unbekannten Zuständen auf den Zielsystemen zurechtkommen, und es muss außerdem ein sauberer Deinstallations-Mechanismus zur Verfügung gestellt werden, um die Software wieder zu entfernen. Dies kann erhebliche Kosten verursachen und ist auch in Test, Fehlersuche und Support sehr umfangreich.
  • Die Kosten für Werbung und Verteilung entfallen in der Regel.
  • Falls eine Software auf mehreren Rechnern eingesetzt werden soll, entstehen bei Standardsoftware höhere Lizenzkosten, da entsprechend viele Lizenzen gekauft werden müssen. Eine Individualprogrammierung kann hier durchaus günstiger sein, da die Entwicklung nur einmal bezahlt werden muss.
  • Durch die Abrechnung nach Aufwand können in Individualprojekten ebenfalls Kosten gespart werden, wenn Auftraggeber und Auftragnehmer partnerschaftlich, professionell und offen miteinander arbeiten.[3]

Kostenerhöhende Faktoren

[Bearbeiten | Quelltext bearbeiten]

Andererseits wird in der Praxis der Kostenaufwand häufig enorm unterschätzt. Dies mag darin begründet sein, dass die Anwender oder Auftraggeber aus den geringen Kosten für den Erwerb einer Standardsoftware irrtümlich auf die Kosten einer Individualsoftware schließen.

Weitere Faktoren für hohe Kosten bei Individualsoftware (die meisten dieser Punkte können bei der Standardsoftware auch auftreten, jedoch zeigt die Erfahrung, dass sie sich hier mit der Zeit selbst aus dem Projekt eliminieren):

  • Die (im Vergleich zu Standardsoftware) häufig kurze Entwicklungszeit und damit verbundener „zeitlicher Erfolgsdruck“ führen zu allerlei Fehlentscheidungen oder voreiligen Entscheidungen oder Entwicklungsabläufen. Oft wird nicht genug Zeit genommen, um die am Markt verfügbaren Entwicklungsumgebungen, Bausteine oder Teillösungen in Betracht zu ziehen.
  • Der Auftraggeber möchte, da er beispielsweise auch Teilzahlungen geleistet hat, vorzeitig Teilergebnisse sehen. Häufig sind jedoch in der Softwareentwicklung über lange Zeiträume keine sichtbaren Erfolge vorweisbar, jedenfalls nicht gegenüber dem Auftraggeber, wenn dieser ein softwaretechnischer Laie ist. Daher werden oft vorzeitig gewisse wichtige Entwicklungsschritte vernachlässigt, um schnell zu vorzeigbaren Ergebnissen zu kommen. Dies rächt sich später durch hohen Zeitaufwand, der nötig ist, um dadurch entstandene Fehler wieder auszubügeln. Ein Großteil des Entwicklungsaufwandes besteht in Planungen, in vorbereitender Entwicklung, der Entwicklung von Modulen oder Teilprogrammen, der Vorbereitung von Umgebungen, dem Test und der Anpassung von Teilsystemen, der Dokumentation der Quelltexte und der Systementwicklung und dergleichen.
  • Die Wahl von falschen oder unangemessenen Entwicklungswerkzeugen oder Umgebungen.
  • Der Auftraggeber greift durch nicht sachgerechte Weisungen in den Entwicklungsprozess ein, die zu Kostenerhöhungen führen, oder er hat gewisse sachfremde Vorgaben (z. B. Aufsetzen auf nicht mehr zeitgemäße vorhandene Software oder Hardware, Zusammenarbeit mit von ihm vorgeschlagenen Mitarbeitern oder Firmen oder Systemen).
  • Beauftragung oder Einbeziehung von nicht qualifizierten Firmen oder Personen durch die Entwickler.
  • Der Auftraggeber entscheidet sich während des Entwicklungsprozesses um, was Umfang und Art der Aufgabenstellung betrifft
  • Die Entwickler entscheiden sich während des Entwicklungsprozesses um, was die Art der eingesetzten Entwicklungssysteme und Werkzeuge betrifft.
  • Fehlender Konkurrenzdruck. Auf dem Markt für Standardsoftware besteht dadurch ein gewisser Konkurrenzdruck, dass sich das Endprodukt mit ähnlichen am Markt befindlichen Produkten messen muss.

Einzelnachweise

[Bearbeiten | Quelltext bearbeiten]
  1. a b Der Marki Standard-Software versus Individual-Software[1]
  2. a b c d e f g Uni Hannover Archivlink (Memento des Originals vom 4. März 2016 im Internet Archive)  Info: Der Archivlink wurde automatisch eingesetzt und noch nicht geprüft. Bitte prüfe Original- und Archivlink gemäß Anleitung und entferne dann diesen Hinweis.@1@2Vorlage:Webachiv/IABot/archiv.iwi.uni-hannover.de Potenziale und Risiken von Standard- und Individualsoftware
  3. Siehe auch Vorteile der Abrechnung nach Aufwand (Memento vom 24. Juli 2010 im Internet Archive).