<
>
Download

Zusammenfassung
Informatik

Hamburger Fern-Hochschule - HFH

2013

Dieter C. ©
8.00

1.05 Mb
sternsternsternsternstern
ID# 50673







Grundlagen der Wirtschaftsinformatik

- Entwicklung von Anwendungssystemen-


1. Zusammenhang von Entwicklung und Anwendung

1.1. Anwendungen als Teil betrieblicher Informationssysteme

In betrieblichen Informationssystemen werden zur Bewältigung der Daten- und Informationsmengen Computersysteme herangezogen (Rechentechnik). Hauptkomponenten sind Hardware, Software und Orgware. Zunächst ist zu untersuchen, ob im bestehenden betrieblichen Informationssystem Prozesse existieren, deren Funktionen mit Hilfe von Software realisiert werden können. Ist das möglich, werden diese als Anwendungen bezeichnet.

Eine Anwendung im Sinne der Wirtschaftsinformatik dient demnach der Lösung im Wesentlichen vorgegebener Anwendungsproblemen, die nach geeigneter Modellierung durch Programme realisiert wird.


Mit Anwendungen verbundene Unternehmensziele/Organisationsziele

► Integration von Arbeitsabläufen ► Schaffung organisatorischer Flexibilität

► Unabhängigkeit von Standorten ► Unabhängigkeit von Herstellern

► schnelle Nutzung neuer Technologien und technischer Flexibilität ► Sicherung der Kooperationmöglichkeiten

► Investitionsschutz für alte und neue Anwendungen ► Integrationsfähigkeit

► Skalierbarkeit ► Vermeidung von Komplexität

â–º Wirtschaftlichkeit

Anwendung als Dienstleistung von Informationssystemen

Grundlegende Vorüberlegungen sind:

► Die Unterstützung der Arbeit in einem Unternehmen durch Informationssysteme ist eine Dienstleistung, das heißt

Mittel zum Zweck, und ist deshalb so effizient wie möglich zu gestalten.

► Wachsende Nutzung von Anwendungen bedeutet steigende Komplexität von verwendeten Funktionen, wodurch die

Beherrschbarkeit der Systeme immer schwieriger wird.

Eine einfache Möglichkeit diese Probleme zu beherrschen, sind offene betriebliche Informationssysteme. Deren grundlegende Eigenschaften sind:

► Portierbarkeit (Übertragbarkeit) ► Interoperabilität (Zusammenarbeit)

► einheitliche Benutzeroberfläche

1.2. Standard und Individualanwendungen

Da Software ein Produkt ist, gilt natürlich auch in Analogie zur Fertigung anderer Produkte für die Software, dass eine „Massen- oder Serienfertigung“ in der Regel zu niedrigeren Preisen führt als die „Einzelproduktion“. Bei der massenhaften Verbreitung von Softwareprodukten können die meist hohen Entwicklungskosten auf viele Produkte umgelegt werden. Allerdings ist Software ein immaterielles Gut.

Dadurch ist die Kostenfrage bei Softwareprodukten im Wesentlichen auf die Entwicklung von Prototypen, Zwischen- und Endprodukten in Verbindung mit den notwendigen Aktivitäten des Marketings, Vertriebs und der Unterstützung der Anwendung fokussiert. Das „Serien- oder Massenprodukt“ der Software ist die Standardsoftware, das „Einzel- oder Kleinserienprodukt“ ist die Individualsoftware.

Individualsoftware

Individualsoftware ist auf spezielle Belange im Unternehmen zugeschnittene Software, die auf Grund der Individualität der Lösung nur sehr begrenzt eingesetzt werden kann.

Standardsoftware

Standardsoftware ist Software, die parametriert, aber ohne Veränderungen bei den Nutzern eingesetzt werden kann, meist in Form fertiger Produkten am Markt angeboten wird und einen klar definierten Anwendungsbereich unterstützt. Falls eine Standardsoftware stark modifiziert werden muss, um ausschließlich den speziellen Bedingungen eines weiteren Nutzers gerecht werden zu können, kann das nicht mehr als Standardsoftware bezeichnet werden.

Sie ist dann wieder Individualsoftware.

Standardsoftware für verwandte, aber variierende Anwendungen wird durch Parametrisierung erreicht. Parameter in der Software dienen dazu, die Software an die speziellen Belange des Nutzers anzupassen, ohne Änderungen des Programmcodes vornehmen zu müssen. Der Begriff „Customizing“ bezeichnet die Anpassung der Standardsoftware an die Kundenwünsche. Es sollte aufwärtskompatibel, schnell, kostengünstig und transparent zu realisieren sein. Kostenlos werden von Softwareentwicklern Standardprodukte in Form von Public Domain Software der Allgemeinheit zur Verfügung gestellt.

Preisgünstig können Standardprodukte als Shareware bezogen werden. Nach einer Periode kostenloser Anwendung der Software kann der Nutzer sich registrieren lassen und bezahlt dann eine vergleichsweise geringe Gebühr. Menge und Differenziertheit der Anwendungen nehmen nach wie vor rasant zu. Der Bedarf an Software wächst weiterhin sprunghaft.

Entscheidung zwischen Individual- und Standardsoftware

Durch breiten Einsatz von Standardanwendungen und die Nutzung von entsprechenden Entwicklungsmethoden und

–werkzeugen kann dem Problem entgegengewirkt werden. Deshalb sieht die aktuelle Verfahrensweise vor:

(1) Zunächst wird bei Bedarf der Nutzung einer Anwendung nach einem geeigneten Standardprodukt gesucht.

Gegebenfalls wird eine Anpassungsentwicklung vorgenommen. Der Aufwand für die Anpassung hängt von der
Anpassungsfähigkeit (Adaptabilität) der Standardsoftware an individuelle Gegebenheiten ab.

(2) Ist keine geeignete Standardanwendung verfügbar, dann muss eine individuelle Lösung gefunden werden. Es

entsteht, wenn wirtschaftlich vertretbar eine Individualanwendung, die sich auf einen oder einige wenige
Anwendungsfälle beschränkt.

Die Entscheidung zwischen Individual- oder Standardprodukte wird oft auch als Entschluss für Make-or-Buy bezeichnet. Die individuelle Software wird „gemacht“, die Standardlösung wird gekauft.


Weitere Gesichtspunkte:

► Die verstärkte Hinwendung zu Standardanwendung befreit den Nutzer nicht davon, sich mit Entwicklungsfragen

seiner Anwendung zu befassen.

â–º Entwicklungsarbeiten im Bereich der Anwendungen sind in jedem betrieblichen Informationssystem notwendig, da es

das Universalsystem für ein solches Informationssystem nicht gibt.

► Der prozentuale Anteil der Entwicklung von Individualsoftware im Vergleich zu Standardanwendungen ist rückläufig.

► Neuere Entwicklungen am Markt reflektieren auf das Application Service Providing (ASP). Ziel von ASP ist es, dem Nutzer Standardanwendung über Netze durch elektronische Dienstleister zur Verfügung zu stellen.

1.3. Entwicklung und Architektur von Anwendungen

Fälle die Individualsoftware:

â–º Individual- oder Standardsoftware

Die Frage ist, ob ein Produkt entsteht, das der Lösung eines speziellen Problems dient, oder ob bereits mit Beginn

der Entwicklung ein breites Anwendungsfeld avisiert wird. Allerdings ist es möglich, das sich Individualsoftware zu

Standardsoftware entwickeln.

â–ºNeu-, Anpassungs- oder Weiterentwicklung

Neuentwicklung = ein völlig neues Produkt entsteht

Anpassungsentwicklung = Anpassung von Standardprodukten an spezielle betriebliche Informationssysteme

oder als Veränderung bereits eingeführter Produkte.

Weiterentwicklung = Werden nicht nur kleine Korrekturen an Produkten ausgeführt, spricht man auch

von Weiterentwicklung.

Anpassungs- und Weiterentwicklung gewinnen, immer mehr an Bedeutung, da der Markt für Standardprodukte

expandiert und die Produkte immer besser anpassungsfähig werden (Reengineering)

Die Entwicklung selbst ist eine interdisziplinäre, umfangreiche und komplexe Aufgabe. Wird diese Tatsache ignoriert, führt das in der Regel zu Fehlern, Kosten- und Terminüberschreitungen bei der Projektabwicklung. Ein großer Anteil fertig gestellter Produkte kommt überhaupt nicht oder nur mit erheblichen Änderungen zum Einsatz. Das Problem wurde erkannt. Das sporadische Vorgehen durch „learning by doing“ wurde durch eine wirtschaftliche Systemplanung und –entwicklung ersetzt.

â–º Systemdenken insbesondere zeitliche (Phasen) und inhaltliche (Stufen) Strukturierung des Systems , Integration von

Subsystemen und Aufbau von Regelkreisen.

â–º Beachtung der Ziele der Systemgestaltung

â–º Vorgehen als Folge sequentieller, zeitlicher Phasen nach straffem Plan

► Einbau von Regelkreisen für Selbstorganisation und Qualitätskontrolle

► interdisziplinäre Teamarbeit mit entsprechender Projektorganisation

â–º Anwendung geeigneter Techniken, Methoden und Werkzeuge

Software Engineering

Unter Software Engineering ist die systematische und fundierte Anwendung von Methoden, Verfahren, Standards und Werkzeugen zur Planung, Entwicklung, Realisierung und Wartung der Anwendungen zu verstehen. Software Engineering bedeutet ingenieurmäßige, transparente und nachvollziehbare Anwendungsentwicklung. Erfolgt sie rechnergestützt so spricht man von CASE (Computer Aided Software Engineering).

Strukturierung des Produktes und des Produktentwicklungsprozesses bedeutet zunächst Modellierung der zukünftigen Anwendung. Moderne Architekturkonzepte gehen prinzipiell von einer Mehrebenen-Architektur

Strukturierung des Produktes und des Produktionsentwicklungsprozessen bedeutet zunächst Modellierung der zukünftigen Anwendung. Moderne Architekturkonzepte gehen prinzipiell von einer Mehrebenen-Architektur als Systemarchitektur aus.

Schichtenmodell nach DREWS

► Präsentationsebene geräteabhängige Darstellung der Benutzeroberfläche auf unterschiedlichen Ausgabegeräten

► Dialogebene geräteunabhängige Steuerung und Koordinierung der Benutzeroberfläche und des –dialogs

â–º Anwendungsebene anwendungsspezifische Steuerungs- und Verwaltungsfunktionen

► Daten- & Dienstebene Erledigung der vom Nutzer der Anwendung gestellten Anforderungen und Aufträgen

► Datenzugriffsebene Zugriff auf die anwendungsunabhänigen Datenbanksysteme.

Die Ebenen werden durch systemneutrale Programmschnittstellen getrennt. Dabei wird unterschieden zwischen:

► internen Schnittstellen Regelung der Nutzung von Kommunikationsprotokollen, Diensten des Betriebssystems, die für die Anwendungsentwickler offen gelegt sind.

► Anwendungsschnittstellen zur Kommunikation von Teilen der Anwendung mit anderen Teilen der Anwendung und zur Anforderung von Systemdiensten, die für Entwickler und Nutzer transparent sind.

Sichten nach dem ARIS-Konzept

Anwendungssoftware grenzt sich durch die Eigenschaft, konkrete betriebliche Anwendungen zu unterstützen, von der Systemsoftware ab. Sie ist integraler Bestandteil komplexer betrieblicher Anwendungen, die gemäß des

► Funktionssicht unterstützende Funktionen

â–º Datensicht verwendete und generierte Daten

â–º Organisationssicht beteiligte Organisationseinheiten

► Prozesssicht zu Grunde liegende Geschäftsprozesse und Workflows

â–º Ressourcensicht bestehende Systemplattform

â–º Produktsicht materielles oder immaterielles Produkt

Die Anwendungsentwicklung wird durch die Funktionssicht geprägt. Daher kann sie sinnvoll nach dem Verwendungszweck –branchenneutrale und branchenspezifische Administrations- und Dispositionssysteme, Führungs- und Querschnittssysteme- klassifiziert werden.

Anwendungsarchitektur

Da die Anwendungssysteme Teil des gesamten betrieblichen Informations- und Kommunikationssystem sind, ist die Anwendungsarchitektur auch Teil der Gesamtsystemarchitekur.

Die Anwendungsarchitektur wird also vom betrieblichen Gesamtmodell der Informations- und Kommunikationssysteme ausgehend über die allgemeine Architektur des Anwendungssystems bis hin zur konkreten, speziellen betrieblichen Ausprägung entwickelt.

1.4. Auswahl von Anwendungen

Vor- und Nachteile von Standardsoftware zur Individualsoftware

Beurteilungskriterien von Standardsoftware

Zunächst ist die Frage der Funktionalität der Software zu beantworten. Aus der Beschreibung der Geschäftsprozesse werden die Funktionen abgeleitet, die durch Software sinnvoll zu unterstützen sind. Weiter Fragen können Client/Server-Architektur, Programmumgebung, Schulungsofferten, Einführungs- und Anwendungsberatung, Weiterentwicklung, Preis und Kosten, Zertifikate etc. betreffen.

„Make-or-Buy“ wird somit zur für jeden Fall individuell zu untersuchenden Entscheidung, meist auch noch mit strategischer Bedeutung. Die Entscheidung für eine spezielle Welt von Anwendungssystemen ist strategischer Natur und langfristig wirksam. Daher sind solche Entscheidungen Aufgabe der Unternehmensführung im Rahmen des Informationsmanagement.

2. Projektmanagement der Anwendungsentwicklung

2.1. Projektmanagement

Merkmale von Projekten

► zeitlich begrenzt ► zielgerichtet ► zu planende Aktivitäten

► messbarer Erfolg ► mehrere beteiligte Personen ► Leitung, Führung und Kontrolle

â–º gewisse Einmaligkeit â–º abgestimmt auf Umfeld â–º Gliederung und Struktur

Die Besonderheit von Projekten der Anwendungsentwicklung ergibt sich aus dem spezifischen Gegenstand und dessen hoher Bedeutung für die Funktionsfähigkeit des Unternehmens überhaupt. Besondere Kennzeichen von diesen Projekten sind:

â–º erheblicher (meist teurer) Ressourcenverbrauch vor allem an Fachpersonal

► Zeitraum von der Initialisierung bis zur Inbetriebnahme über Monates und Jahre

â–º hohes Fehlerrisiko bei isolierter Behandlung anstelle integralem Ansatz

► hohes Ergebnisrisiko bezüglich der Projektziele

â–º bedeutende Unsicherheit hinsichtlich geplanter Termine und Kosten

2.2. Projektvorbereitung und –leitung

â–º Projektvorbereitung

ï‚Ÿ Ableitung der Projektziele aus den Unternehmenszielen

ï‚Ÿ Bestimmung der Projektorganisation und der Projektleitung

ï‚Ÿ Formulierung des Projektauftrages und der Detailziele

ï‚Ÿ Definition der Projektphasen und des Ressourcenverbrauchs

 Festlegung der Projektpriorität zur Projektsteuerung

â–º Formen der Projektorganisation

ï‚Ÿ Projektorganisation durch Stabstellen

 Aufstellen einer „Task Force“ bzw. eines Teams

ï‚Ÿ Matrix- Projektorganisation

Neben klaren Vorstellungen zur Projektorganisation, zum Projektablauf, zur Wirtschaftlichkeit, dem

Ressourceneinsatz, den zu erreichenden Projektzielen, etc. beeinflusst die personelle Zusammensetzung des

Teams die Erfolgschancen maßgeblich.

â–º Anforderungen an die Projektleitung

ï‚Ÿ Fachkenntnisse

ï‚Ÿ Sozialkompetenz

 konzeptionelle und organisatorische Fähigkeiten

Bei zunehmend international geführten Projekten kommen noch Sprachkompetenzen und Kenntnisse der

internationalen Gepflogenheiten, Gesetzte und Organisationsformen etc. hinzu.

Für Anwendungsentwicklung als intelligenzintensiver, kreativer Prozess gilt, dass die Humanressourcen der Schlüssel zum Erfolg des Projektes sind.

2.3. Projektplanung und –durchführung

Fällt die Entscheidung zur Aufnahme des Projektes schließt sich die systematische Projektplanung an. Zunächst wird die Projektgruppe installiert, die sich ungefähr paritätisch aus Informatikern und Nutzern zusammensetzten sollte. Es werden zwei Projektleiter eingesetzt, eine inhaltlich-fachliche Leitung und eine administrative Leitung. Die Projektgruppe beginnt mit der Projektplanung vom Groben zum Feinen. Ergebnisse hierbei sind:

► ein Personalplan, der Qualifizierung, Zeiträume und Aufgabenverteilung für das Personal regelt

â–º ein Finanzierungs- und Kostenplan mit einer Wirtschaftlichkeitsprognosse

► ein Plan zur Bereitstellung der sonstigen Ressourcen für das Projekt (Räumlichkeiten, Betriebs-, Hilfsmittel, etc.)

Aus den Arbeitspaketen abgeleitete Aufträge sollten im Sinne einer besseren Nachvollziehbarkeit des Projektfortschrittes schriftlich erteilt, ihre Ergebnisse protokolliert und dokumentiert werden.

2.4. Projektkontrolle und –abschluss

Basis für die Projektkontrolle ist ein gut organisiertes System der Projektinformationen. Dazu zählen:

â–º Dokumentationswesen zur schriftlichen Fixierung der Arbeitsergebnisse

► Berichtswesen für die informelle Transparenz im Projekt bezüglich Informationen über den Stand und Fortschritt der Arbeiten.

â–º Benutzerinformationen zur zeitgerechten und zielgerichteten Information, Orientierung und Einbeziehung

der potentiellen Anwender in die Projektergebnisse.

Zielgerichtete Information innerhalb der Projektgruppe an die Entscheider und an die Nutzer sowie die Art der Präsentation bilden die Voraussetzung für den Erfolg des Projektes. In einer Zeit, wo Wissen sehr schnell allgemein verfügbar ist und Sachkompetenz als gegeben betrachtet wird, müssen alle verfügbaren Möglichkeiten ausgenutzt werden, um schneller und effizienter zum Ergebnis zu kommen als potentielle Konkurrenten.

Die Projektdokumentation als statische Dokumente, dient als:

► Entscheidungsbasis für die Projektverantwortlichen

► Verständigungsgrundlage für das Projektteam

► Informationsmittel für zukünftige Nutzer

► Grundlage für die Wartung, Anpassung und Weiterentwicklung

Je besser die Dokumentation, desto unabhängiger wird man von einzelnen Fachleuten und Personen.

Projektkontrolle

Projektdokumentation und –berichtswesen bildet die Basis für eine fundierte Projektkontrolle. Sie bieten die Möglichkeit, im laufenden Projekt möglichst frühzeitig Probleme zu erkennen und geeignete Maßnahmen zu ihrer Behebung einzuleiten. Elemente der Projektkontrolle sind:

â–º Einhaltung der Terminplanung inklusive der Erreichung der Sachziele

► Aufwandserfassung mit einem permanenten Vergleich der realen Aufwände mit den geplanten Aufwänden.

► Zweckmäßigkeit der Aufgabenabgrenzung und –strukturierung einschließlich der sachlogischen Zusammenhänge im

Projektablauf

► Zweckmäßigkeit der geplanten organisatorischen Maßnahmen und der eingesetzten Mittel.

Zusammenfassend sollen folgende Erfolgsfaktoren für Projekte der Anwendungsentwicklung hervorgehoben werden

â–º Formulierung klarer Zielsetzungen

► Festlegung einer zweckmäßigen und angemessenen Projektorganisation

► Engagement der potenziellen Nutzer bereits in der Phase der Ideenfindung bis zur Projekteinführung

â–º Bereitstellung qualifizierten Personals sowie ausreichender Finanz- und Sachmittel durch Entwickler und Nutzer

► Transparenz durch gezielte Information und Präsentation für alle Beteiligten

► Nachvollziehbarkeit durch übersichtliche Dokumente und Entscheidungsunterlagen

â–º Gliederung des Gesamtkonzeptes in Phasen inklusive klarer Zuordnung von Terminen, Verantwortlichkeiten und

Prioritäten für die Phasen oder Teile der Phasen.

Nach der Projektdurchführung erfolgt die Projekteinführung sowie Projektbetreuung. Der Anwender bzw. Auftraggeber wird eingewiesen und ggf. geschult und übernimmt eine fertige Lösung. Das Projektteam steht für Wartungsarbeiten und weitere Kommunikation hinsichtlich Fehlerbewältigung zur Verfügung.

3.1. Vorgehensmodell

Jedes Projekt zur Entwicklung einer einsatzbereiten, marktreifen und möglichst fehlerfreien Software benötigt einen organisatorischen Rahmen. Dieser wird mit Hilfe von so genannten Vorgehensmodellen definiert. Sie beschreiben die Art und Weise, wie an eine Projektabwicklung heranzugehen ist. Sie Definieren die Aktivitäten, ihre Reihenfolge und die Personen die sie ausführen.

Jede Aktivität endet mit einem Ergebnis (Artefakt). Inhalt und Layout eines Artefakts sind in einem Artefaktmuster festzuhalten. Für das Ausführen von Aktivitäten zeichnen Mitarbeiter verantwortlich, die vom Vorgehensmodell definierte Rollen übernehmen. Sie erstellen, ausgehend von bestehenden Artefakten ein neues Artefakt oder ändern ein bestehendes unter Beachtung des Vorgehensmodells ab.

In der Praxis nutzen die Mitarbeiter eines Projektes häufig Software-Entwicklungstools. Die genutzten Programme müssen mit den Methoden des gewählten Vorgehensmodells korrespondieren. Deshalb ist die Auswahl geeigneter Tools zur Durchführung von Aktivitäten in einem Projekt eine wichtige Aufgabe des Projektmanagement. Alle derzeit bekannten Vorgehensmodellen beruhen auf der Verwendung von Phasen.

Das Projekt wird ausgelöst durch die fachliche Problemstellung, die durch eine Analyse des gegenwärtigen (Ist-)Zustandes untersetzt wird, worauf die Entwicklung einer Lösungsidee und eines Fachkonzeptes folgen. Danach werden Entwicklung des Konzeptes der Anwendung, Systementwurf, Realisierung inklusive Programmierung und Einführung angeschlossen. Da es leider keine standardisierte Form des Vorgehensmodells gibt, ist eine Unmenge von Modellen entwickelt worden.

Allgemeine Phaseneinteilung nach BALZERT

Phasenmodelle beziehen sich auf die Anwendungsentwicklung von der Produktidee bis zur Einführung der fertigen Anwendung. Wird auf eine Neu-, Anpassungs- oder Weiterentwicklung mittels eines Projektes reflektiert, dann kann auf keine der Phasen verzichtet werden, ohne Gefahr zu laufen, Regeln die jedem Planungs- und Entwicklungsvorgang zu Grunde liegen, zu verletzen und gravierende Fehler zu begehen.

Jede Phase enthält eine Reihe von Aktivitäten, deren Durchführung essentiell für die Fertigstellung des Softwareproduktes ist.

► Ziel der Phase ► durchzuführende Aktivitäten

► Rollenzuordnung zu den Aktivitäten ► zu erstellende Artefakte

â–º zu verwendende Artefaktmuster â–º Methoden, Konventionen, Richtlinien und Checklisten

â–º einzusetzende Entwicklungswerkzeuge und Sprachen

Trotzdem darf nicht jegliche Kreativität im Keim erstickt werden. Deshalb muss der richtige Mittelweg zwischen Standardisierung und Freiheitsgraden gefunden werden. Das Ziel sollte lauten:

► nur so viele Phasen, Aktivitäten und Rollen wie unbedingt nötig zu definieren

â–º beim Aufbau der Artefakte auf Standardisierung achten

► optimale Werkzeugunterstützung gewährleisten

► jedes Artefakt einer Qualitätsprüfung unterziehen

P

Fehler, die frühzeitig erkannt werden, erfordern wesentlich weniger Aufwand für die Behebung als die zu einem späteren Zeitpunkt des Projektfortschrittes entdeckten Fehler.


lanungsgrundsatz


Deshalb sollte der Umfang der Arbeiten vor allem in frühen Phasen der Projektabwicklung ausreichend dimensioniert sein. Für die Wartung des Produktes nach seiner Einführung muss etwa noch einmal der dreifache Aufwand wie für die Entwicklung veranschlagt werden. Der Testaufwand kann erheblich höher liegen, besonders bei Anwendungen, die hohe Anforderungen an die Fehlerminimierung stellen (Atomkraftwerke, Ordnersysteme an Börsen).


| | | | |
Tausche dein Hausarbeiten

G 2 - Cached Page: Thursday 28th of March 2024 02:29:57 PM