Organisationsphasen

Inhaltsverzeichnis





ORGANISATIONSPHASEN

Ausgangssituation: Eine Gruppe von KFZ Handelsbetrieben hat die Idee, eine gemeinschaftliche Gebrauchtwagenb√∂rse unter dem Namen GWB mittels eines gemeinsamen Computersystems zu betreiben. Da dies eine Aufgabe darstellt, welche nicht im normalen Tagesbetrieb zu l√∂sen ist, beschlie√üen Sie, dies in Form eines gemeinsamen Projekts durchzuf√ľhren.

I. Grundlagen


A. Was ist ein Projekt


* Ein Projekt unterscheidet sich vom täglichen Arbeitsablauf durch eine neuartige, einmalige und komplexe Aufgabenstellung.

* Der Zeitbedarf f√ľr ein Projekt erstreckt sich meist auf einen gr√∂√üeren Zeitraum.

* Bei einem Projekt arbeiten mehrere Personen zusammen.

Das Projektmanagement wird in allen Bereichen der Wirtschaft und Verwaltung eingesetzt. Bei Kleinbetrieben kann dies beispielsweise die Einf√ľhrung eines Computersystems sein, bei Konzernen wird z.B. eine Fusionierung zweier Unternehmungen in Form eines Projektes durchgef√ľhrt.

Zu den Projekten z√§hlen auch die Einf√ľhrung eines neuen Produktes oder die Ausarbeitung und Einf√ľhrung einer Verwaltungsreform im Bereich der √∂ffentlichen Verwaltung.

Projekte können auch aus unterschiedlichen Blickwinkeln gesehen werden.

    Projekt als Aufgabe Projekt als Prozess Projekt als soziales System

Das folgende Skriptum sieht das Projekt vorwiegend als Prozess, wenngleich die beiden anderen Perspektiven nicht aus den Augen verloren werden sollen. Der letzte Punkt "Projekt als soziales System" ist Gegenstand der Organisationsentwicklung. Es ist von großer Bedeutung, die Erkenntnisse dieser Disziplin bei der Entwicklung von Produkten mit einzubeziehen.








B. Wie entsteht ein Projekt?


F√ľr das Zustandekommen eines Projekts kann es vielf√§ltige Ursachen geben. Typische Beispiele sind:


* Technische Entwicklung: Besonders das Gebiet der Elektronik ist durch einen rasanten Fortschritt gekennzeichnet. Hier entsteht das Phänomen, dass bei sinkenden Preisen die Leistung der Produkte steigt. Daher sind immer mehr Betriebe - wegen der Wettbewerbsfähigkeit - gezwungen, diese neuen Möglichkeiten einsetzen.

Beispiele:

- Einf√ľhrung des EDI (Electronik Data Interchange), also einer M√∂glichkeit, Daten wie Bestellungen, Lieferpapiere und Rechnung zwischen Betrieben elektronisch (per DF√ú) auszutauschen und automatisch zu verarbeiten.

- Umstellung des Produktionsablaufes auf CIM (Computer Integrated Manufacturing). Dieses Konzept geht von der Idee aus, dass die Planung und Steuerung von der Konstruktion eines Produktes √ľber die Produktion bis zur kaufm√§nnischen Abwicklung ganzheitlich von Computersystemen unterst√ľtzt wird.

* Volkswirtschaftliche Entwicklung: Durch einerseits größer werdende Märkte (z.B. EU) und andererseits steigenden Wettbewerb werden Betriebe gezwungen, ihre Strukturen und Organisationsformen zu ändern.

Beispiele: - Betriebszusammenlegungen und Kooperationen
- Spezialisierung
- Produkt√§nderungen oder Neueinf√ľhrungen.....

* Verbesserungsvorschläge: In vielen Betrieben werden durch Ideen der Mitarbeiter (z.B. das betriebliche Vorschlagswesen) oder durch Anregungen von Außen (z.B. Unternehmensberatung) neue Ansatzpunkte zur Rationalisierung der Unternehmensorganisation gefunden.


* betriebliche Probleme: Werden Missst√§nde oder Fehlentwicklungen in Unternehmungen erkannt, so k√∂nnen diese oftmals durch die Gr√ľndung eines Projektteams untersucht und beseitigt werden.

Beispiele:

- Anlässlich einer Inventur werden hohe Differenzen zwischen Soll und Ist Beständen festgestellt.

- Die Kostenrechnung zeigt eine Kostenexplosion im Bereich des Transports.

C. Organisationsformen eines Projekts


Eines der wesentlichsten Merkmale von Projekten besteht darin, dass es losgel√∂st von der √ľblichen betrieblichen Struktur (z.B. Linienorganisation) durchgef√ľhrt wird.

Beispiel: Im Zuge eines Projekts zur Einf√ľhrung eines automatisierten Bestellsystems wird ein Mitarbeiter der Einkaufsabteilung ins Projektteam berufen. Dabei wird vereinbart, dass der Mitarbeiter 40% seiner Arbeitszeit f√ľr das Projekt aufwendet und dass die Mehrbelastung in Form einer Projektpr√§mie abgegolten wird. Der Mitarbeiter bleibt fachlich weiterhin dem Einkaufsleiter unterstellt. Die Anweisungen bez√ľglich der Projektarbeit erh√§lt er allerdings vom Projektleiter.




















Abbildung Projektorganisation

Die Projektorganisation ist eine Form der Matrixorganisation. Dabei kann es zu Doppelunterstellungen kommen. In diesem Fall sollte das Ausmaß der Projektmitarbeit des einzelnen Mitarbeiters möglichst genau im Vorhinein definiert werden. Wird dies verabsäumt, so bildet dies im Laufe des Projektes ein hohes Konfliktpotential.
Auch sollte geklärt sein, wie die Mehrbelastung der Teammitglieder abgegolten wird. Dies könnten in Erfolgsprämien, Überstunden, Sonderurlaub nach dem Projekt oder auch beliebte Auslandsreisen bestehen.

Ein wesentlicher Punkt f√ľr das Gelingen eines Projekts ist die richtige Zusammensetzung des Projektteams.





Mitglieder eines Projektteams sollten sein:

* Mitarbeiter aus den betroffenen Abteilungen: Dabei sollten jene Mitarbeiter ausgew√§hlt werden, die einerseits √ľber detaillierte Kenntnisse √ľber die Arbeitsabl√§ufe in ihrer Abteilung verf√ľgen, andererseits sollten sie in ihrer Abteilung m√∂glichst hohes Ansehen genie√üen. Aus psychologischen und taktischen Gr√ľnden ist es besser, potentielle Gegner des Projektes ins Team einzubeziehen, anstatt sie auszugrenzen.

* Bei Projekten, bei denen der EDV Einsatz im Vordergrund steht, bietet sich die Beiziehung eines Informatikers an.

* Externe Mitarbeiter (z.B. Unternehmensberater, Projektmanager) bringen Erfahrungen von anderen Projekten und Betrieben ein. Sie eignen sich aus diesem Grund auch f√ľr die √úbernahme der Projektleitung. Oftmals werden sie als Au√üenstehende auch leichter von allen Abteilungen akzeptiert.


II. Vorstudie


A. Problemdefinition und Zielsetzung


Voraussetzung f√ľr den erfolgreichen Abschluss eines jeden Projekts ist die eindeutige Definition des Problems bzw. der Aufgabe sowie die klare Formulierung der Ziele des Projekts.

Dabei sind alle (z.T. kontroversiellen) Zielvorstellungen offen zu diskutieren und das Ergebnis dieses Prozesses möglichst genau festzuhalten. Geschieht dies nicht, so kann das Projekt u.U. wegen unterschiedlichen Erwartungshaltungen nicht erfolgreich abgeschlossen werden.
Es ist zu pr√ľfen, ob die Ziele des Projekts widerspruchsfrei sind, und mit den Unternehmenszielen konform sind.

"You may forget some critical factors,
but they won’t forget you!"(Tom Gilb)


ABBILDUNG "SCHAUKEL"

Zunächst werden Grobziele formuliert, diese werden dann in weitere Teilziele zerlegt.

Beispiel: In einem Gro√ühandelshaus wird beschlossen, ein Projekt zur Einf√ľhrung einer computergest√ľtzten Tourenplanung zu gr√ľnden. Als erste Phase werden die Ziele erarbeitet und dokumentiert.

Grobziel: - Senkung der Transportkosten um 7%


Teilziele:
    Erh√∂hung der Kapazit√§tsauslastung Optimierung der Wegstrecken durch Einsatz mathematischer Verfahren Einf√ľhrung einer leistungsorientierten Fahrerentlohnung

Auch diese Teilziele sind noch im Detail zu beschreiben. Sollte sich die Unternehmensleitung das Ziel "Einsparen von 20% der Fahrer" vorstellen, so sollte dieses Ziel klar ausgesprochen werden, da es ansonsten in der Projekteinf√ľhrungsphase zu derartigen Konflikten kommen kann, die den Erfolg des Projektes in Frage stellen.

Bei der Fallstudie "Gebrauchtwagenbörse" sind folgende Grobziele denkbar:

    Steigerung des Umsatzes aller Mitglieder durch aktuelles Informationssystem Verringerung der durchschnittlichen Verweildauer der einzelnen Gebrauchtwagen Vereinfachung der organisatorischen Arbeitsabl√§ufe durch EDV Unterst√ľtzung Gerechte und transparente Provisionsabrechnung Automatisierte Abrechnung der Vermittlungsprovisionen

B. Erarbeitung von Lösungsalternativen


Diese Phase stellt die höchsten Anforderungen an die Kreativität. Von den Zielvorstellungen ausgehend sollen mögliche Lösungswege erarbeitet werden.

Die Art der Problemlösungstechnik und das Ausmaß der notwendigen Kreativität ist von der Problemstellung abhängig.
Bei wohlstrukturierten Problemstellungen (wie z.B. Umstellung des Bestellwesens auf EDV) steht das Verhaltensmuster der rationalen Problemlösung im Vordergrund.





































ABBILDUNG RATIONALER PROBLEML√ĖSUNGSPROZE√ü

Bei offenen Problemstellungen (wie z.B. Einf√ľhrung eines neuen Produktes oder Entwicklung einer Marketingstrategie) bildet die kreative Probleml√∂sung den Schwerpunkt.




Von den zahlreichen Kreativit√§tstechniken ist das Brainstorming die bekannteste Vorgangsweise. Daher sollen einige wesentliche Kriterien angef√ľhrt werden:

    Organisatorische Voraussetzungen: Die Gruppe sollte aus 5 bis 10 Personen von verschiedenen fachlichen Bereichen und hierarchischen Ebenen bestehen. Ein Gruppenmitglied √ľbernimmt die Funktion des Moderators, dieser hat die Aufgabe, eine Atmosph√§re der Entspanntheit und Offenheit herzustellen. Dies gelingt eher an einem Ort, der von der t√§glichen Arbeitsst√§tte entfernt ist (Clausur). Der Moderator leitet den gruppendynamischen Prozess, er animiert die Mitglieder zum ungehemmten Aussprechen von Ideen, fasst diese zusammen und ist auch f√ľr die Dokumentation der Ergebnisse verantwortlich.

    Durchf√ľhrung: Zun√§chst werden die Regeln und der Zeitrahmen besprochen. Danach sollte das Thema bzw. die Zielsetzung deutlich sichtbar gemacht werden. Die Teilnehmer werden nun dazu angeregt, ihre Vorstellungen und Ideen m√∂glichst frei zu √§u√üern. Dies kann auch mittels K√§rtchen anonym geschehen. Die Ideen werden auf Flipcharts oder K√§rtchen an der Wand visualisiert. Wichtig ist dabei, dass kein Beitrag kritisiert oder beurteilt wird, damit auch v√∂llig au√üergew√∂hnliche und spontane Gedanken einflie√üen k√∂nnen. Die Produktivit√§t dieser Phase h√§ngt stark vom Geschick des Moderators ab, alle Teilnehmer zu aktivieren und dominante Pers√∂nlichkeiten eher auszugleichen (besonders wenn die Teilnehmer aus unterschiedlichen hierarchischen Ebenen stammen).

    Auswertung: Die gesammelten Ideen werden vom Moderator systematisiert und geordnet. Die Gruppe diskutiert dann ausf√ľhrlich √ľber alle Ideen und pr√ľft deren Beitrag zur L√∂sung der Problemstellung sowie deren Realisierbarkeit. Danach wird entschieden, welche der √ľbriggebliebenen Ideen von wem genauer ausgearbeitet werden.

Dieser Zyklus kann solange wiederholt werden, bis alle Teilnehmer der Meinung sind, die besten Lösungsvarianten gefunden zu haben.

Bei dem Fallbeispiel "Gebrauchtwagenb√∂rse" k√∂nnten die Mitglieder entweder selbst teilnehmen, oder jeweils einen oder zwei Mitarbeiter aus verschiedenen Bereichen in diese Gruppe entsenden. Die Funktion des Moderators k√∂nnte einem au√üenstehenden, erfahrenen Berater √ľbertragen werden. Diese Gruppe begibt sich ein Wochenende in ein sch√∂nes, jedoch entlegenes Hotel "in Clausur".

In einem mehrstufigen Prozess werden folgende Lösungsvorschläge erarbeitet:

    - F√ľr den organisatorischen Rahmen wird eine Vertriebsgenossenschaft gegr√ľndet. An dieser Genossenschaft sind alle Mitglieder je nach Betriebsgr√∂√üe beteiligt. - Ein Mitgliedsbetrieb √ľbernimmt die Rolle der zentralen Clearingstelle. Die bestehende EDV Anlage wird ausgebaut, ein zus√§tzlicher Mitarbeiter ist dort f√ľr die Betreuung des gesamten Systems zust√§ndig.



    - Es wird ein neues Computersystem mit mehreren DF√ú (Datenfern√ľbertragung) - Anschl√ľssen installiert. Dieses System wird allen Mitgliedern aber auch Konsumenten zug√§nglich gemacht. Jeder Gebrauchtwagenh√§ndler kann von seinem Computer alle Gesch√§fte (Angebote eingeben, Abfragen durchf√ľhren, Reservierungen vornehmen) im direkten Verbund mit der zentralen Stelle erledigen.

    - Eine weitere Variante besteht darin, die Gebrauchtwagenb√∂rse im Internet der √Ėffentlichkeit zug√§nglich zu machen. Dabei kann jeder Konsument die zentrale Datenbank der Genossenschaft nach unterschiedlichsten Kriterien (beispielsweise Typ, Marke, Baujahr, Preis.....) abfragen. Von einigen Mitgliedern wurde der Vorschlag gemacht, auch Bilder der Fahrzeuge zu integrieren. Auch hier soll eine direkte Reservierungsm√∂glichkeit vorgesehen werden.

C. Entscheidungsvorbereitung


Aufgabe dieser Phase ist es, die Entscheidung vorzubereiten, ob das Projekt durchgef√ľhrt werden kann bzw. soll. F√ľr den Fall, dass diese Entscheidung positiv gef√§llt wird, ist aus den erarbeiteten L√∂sungsvarianten jene zu ermitteln, die zur Erreichung der Ziele die optimalste darstellt.

Zur Beantwortung der ersten Frage wird speziell bei gr√∂√üeren Projekten eine Feasibilitystudy erstellt. Dabei wird die "Machbarkeit" des Projektes gepr√ľft. Diese "Machbarkeit" wird sowohl hinsichtlich technische wie auch hinsichtlich wirtschaftlichen bzw. politische Gegebenheiten gepr√ľft.

Um die Entscheidung m√∂glichst rational f√§llen zu k√∂nnen, werden f√ľr jede Variante die Kosten dem Nutzen gegen√ľbergestellt.




















1. Ermittlung der Kosten


In diesem Skriptum werden eher kleinere bis mittlere organisatorische Innovationen betrachtet.
Die Ermittlung der Kosten fällt hier im Vergleich zur Ermittlung des Nutzens noch relativ leicht.

Aus Gr√ľnden der Vergleichbarkeit sollte zwischen einmaligen und laufenden Kosten unterschieden werden. Mittels einer Investitionsrechnung k√∂nnen dann die einmaligen und laufenden Kosten in eine Zahlenreihe gebracht werden.

Beim Beispiel "Gebrauchtwagenbörse" könnte dies folgendes Aussehen haben:

* einmalige Kosten:

    Anschaffungskosten der Hardware und Software Kosten der Eigenentwicklung Installationskosten (Kabel, Modemanschl√ľsse....) Schulungskosten Umstellungskosten (Erstdatenerfassung....)


* laufende Kosten

- Personalkosten
- Raumkosten
- Wartung und Reparatur
- Telefonkosten
- Materialkosten

2. Ermittlung des Nutzens


Der Nutzen von EDV Projekten l√§sst sich meist nicht in Geldbetr√§gen ausdr√ľcken. In vielen F√§llen besteht er beispielsweise in dem raschen zur Verf√ľgung stellen von Informationen. Der Nutzen von Informationen ist davon abh√§ngig, wie es gelingt, dadurch die Entscheidungsqualit√§t zu verbessern.

Um den Nutzen der einzelnen Lösungsvarianten dennoch vergleichbar zu machen bedient man sich der Nutzwertanalyse.. Bei diesem Verfahren werden die einzelnen Anforderungen in kleinere Gruppen zerlegt und je nach Bedeutung gewichtet.

Den einzelnen Varianten werden Punkte der Zielerreichung (wie Noten z.B. von 1 - 5) zugeordnet und mit der Gewichtung der jeweiligen Gruppe multipliziert.

Die Summe dieser Produkte ergibt dann den gewichteten Zielerreichungsgrad jeder Variante. Die Variante mit der niedrigsten Punktezahl sollte ausgewählt werden.

BEISPIEL NUTZWERTANALYSE GEBRAUCHTWAGENB√ĖRSE

Variante 1: Verwendung der bestehenden EDV eines Mitgliedes mit zentraler Datenerfassung und Abfrage und Abrechnung.

Variante 2: Neuaufbau eines Computersystems mit direkter Verbindung der Computer aller Mitglieder. Dezentrale Erfassung und Abfrage.

Variante 3: Verwendung des Internet mit √Ėffnung f√ľr alle Interessenten.


Kriterien +
Gewichtung
Variante 1
Variante 2
Variante 3





rascher Abruf
40
(120) 3
(40) 1
(80) 2





einfacher
25
(75) 3
(25) 1
(50) 2
Ablauf









Stabilität +
20
(20) 1
(40) 2
(60) 3
Sicherheit









Zugang f√ľr die
15
(45) 3
(45) 3
(15) 1
√Ėffentlichkeit









Summen:

(260)
(130)
(205)


Der Nutzwert f√ľr die Variante 2 ist am h√∂chsten. Die Kosten der Varianten wurden folgenderweise gesch√§tzt:


Kostenart Variante 1 Variante 2 Variante 3

einmalige Kosten: 800.000. - 1.500.000. - 1.300.000. -

laufende Jahreskosten: 500.000. - 400.000. - 700.000. -


Aufgrund der Gegen√ľberstellung von Kosten und Nutzen f√§llt die Entscheidung zugunsten der Variante 2.


Die Vorstudie endet entweder mit einem konkreten Auftrag, mit der Feinstudie zu beginnen, oder manchmal auch mit dem Entschluss, das Projekt wegen zu hoher Kosten oder zu geringem Nutzen nicht weiterzuf√ľhren.


III. FEINSTUDIE



Der Schwerpunkt dieses Abschnitts liegt bei der Erfassung des Istzustandes, bei der Analyse desselben und bei der Ableitung der Stärken und Schwächen durch Vergleich mit dem Sollzustand.
Ein wichtiger Schritt zur Probleml√∂sung ist die Analyse des Istzustandes. Der Zweck der Istzustandsanalyse ist die Feststellung der St√§rken und Schw√§chen (Schwachstellen) des Istzustandes. Aufgrund der Schwachstellenanalyse erstellt der Systemplaner das Sollkonzept. Um die Erfassung und Darstellung des Istzustandes einer realen Situation durchf√ľhren zu k√∂nnen, werden bestimmte Methoden zur Erhebung und Darstellung des Istzustandes eingesetzt.

A. Die Bestandsaufnahme als Fundament des Softwareprojektes

Oder warum so viele Softwareprojekte scheitern.

Fehler, die in dieser Phase unterlaufen, wirken sich oftmals verheerend auf den Projekterfolg aus. In der Praxis kann immer wieder das Ph√§nomen beobachtet werden, dass bei der Anforderungsanalyse wesentliche Punkte √ľbersehen werden. Die Gr√ľnde daf√ľr sind vielf√§ltig.

    Die Anwender und die Informatiker leben in 2 unterschiedlichen Erfahrungswelten. Anwender denken oftmals nur an den Regelfall, Ausnahmen bzw. Sonderf√§lle werden vergessen. F√ľr Anwender sind manche Punkte derart selbstverst√§ndlich, dass sie nicht ausgesprochen werden. Informatiker haben einen v√∂llig anderen Zugang zum Problem und kennen derartige "Selbstverst√§ndlichkeiten" nicht. Informatiker hingegen l√∂sen vermeintliche Probleme des Anwenders, die f√ľr diesen keine sind.

Softwareentwicklung ist kein technisches, sondern ein kommunikatives Problem!

Untersuchungen in den USA (Caper Jones) haben ergeben, dass mehr als die Hälfte der Zeit eines Softwareprojektes mit Kommunikation verbracht wird. Lediglich 5% nimmt die eigentliche Programmierung in Anspruch!
Die Herausforderung besteht darin, die Realität möglichst genau in der Software abzubilden. Eine 100% Abbildung ist derart schwer zu erreichen, wie ein zu 100% fehlerfreies Programm.
Bevor mit der Erhebung des Istzustandes begonnen wird, sollte genau festgestellt werden, welche Bereiche wie detailliert erfasst werden sollen, damit nicht die Gefahr entsteht, dass die Erfassung des Istzustandes zum Selbstzweck wird und unnötige Datenfriedhöfe produziert werden.





Die Erfassung des Istzustandes hat sich immer an dem Grundkonzept zu orientieren.

In den meisten Fällen werden folgende Teilbereiche des bestehenden Systems untersucht:

* welche Aufgaben sind in welcher Reihenfolge zu lösen,
* welche Daten, Betriebsmittel werden dazu benötigt,
* welche Methoden werden verwendet,
* wann und wie häufig fallen diese Aufgaben an,
* welche Mengen sind zu bewältigen, wie hoch ist der Zeitbedarf,
* welche Daten werden produziert und welche Aufgaben sind davon
abhängig,
* welche Voraussetzungen sind f√ľr eine Aufgabe notwendig,
* wie werden die Daten transportiert und gesichert


B. Methoden der Istzustandserfassung


Die Methoden der Istzustandserfassung können in 2 Bereiche unterteilt werden.












1. 2.1 Dokumentenauswertung


Um einen ersten Einblick in den Untersuchungsbereich zu gewinnen, ist die Auswertung vorhandener Unterlagen empfehlenswert. Als Vorinformation √ľber den Istzustand bietet die Dokumentenauswertung eine vergleichsweise einfache M√∂glichkeit den Sachverhalt kennenzulernen. In der betrieblichen Realit√§t muss allerdings nicht immer der dokumentierte Zustand mit der Wirklichkeit zum Zeitpunkt der Erfassung √ľbereinstimmen.

Beispiel:

Ein laut Dokumentation eingesetztes Formular (z.B. Materialanforderungsschein) wird in der t√§glichen Arbeit nie verwendet, weil die Materialbestellungen von den Kostenstellen immer m√ľndlich oder telefonisch dem Lagerverwalter mitgeteilt werden.



Unterlagen f√ľr die Dokumentenanalyse:

Organigramme, Stellenbeschreibungen, Funktionspläne, Raumpläne, Verzeichnisse, Formulare, Vordrucke und sonstige Unterlagen.

Einsatzgebiet:

Zum Sammeln von Vorinformation √ľber den Istzustand bietet die Dokumentenauswertung eine rasche und einfache M√∂glichkeit den Sachverhalt
kennenzulernen.

Vorteile
Nachteil


+ geringer Erfassungsaufwand
- Problem der Übereinstimmung der Dokumentation mit der Realität
+ schneller Einstieg in das Problem möglich

+ keine Störung der Aufgabenträger



2. 2.2. Selbstaufschreibung


Der Mitarbeiter des Unternehmens (Aufgabentr√§ger) beobachtet sich selbst und schreibt seine T√§tigkeiten in Erfassungsformulare. Dabei k√∂nnen aber nur regelm√§√üig wiederkehrende und genau beschriebene Arbeiten untersucht werden. Au√üerdem ist der Aufgabentr√§ger f√ľr die Erfassung der Informationen entsprechend zu schulen. Die Auswertung der erfassten Informationen erfolgt durch den Systemplaner.


Einsatzgebiet:

Die Selbstaufschreibung ist f√ľr die Ermittlung von Zeitbedarf und Belastung bestimmter T√§tigkeiten eine gut geeignete Erfassungstechnik.

Vorteile
Nachteile


+ Totalaufnahmen der Tätigkeiten möglich
- personelle Widerstände möglich
+ Entlastung des Systemplaners
- subjektive Beurteilung der Tätigkeiten kann vorkommen

- Verfälschung denkbar





3. 2.3 Beobachtung


Bei der Beobachtung werden Informationen vom Systemplaner durch eigene Wahrnehmungen an einzelnen Arbeitsplätzen gesammelt. Bewährt hat sich die offene, passive Beobachtung in bestimmten Zeitabschnitten. Dauernde, verdeckte (dem Aufgabenträger nicht bekannte) Beobachtung mit aktiven Eingriffen des Systemplaners in die Tätigkeiten am Arbeitsplatz ist nicht empfehlenswert.

Einsatzgebiet:

Grundlagen f√ľr die Ursachen von Engpassproblemen, die Arbeitsplatzgestaltung, die Arbeitsbelastung und die Arbeitsplatzauslastung k√∂nnen mit der Beobachtungstechnik gut ermittelt werden.

Vorteil
Nachteile


+ unmittelbarer Einblick in den Untersuchungsbereich
- zeitaufwendig

- psychisch Belastung des Beobachteten

- unnat√ľrliche Verhaltensweisen


4. 2.4 Fragebogen


In Frageb√∂gen beantwortet der Aufgabentr√§ger schriftlich eine geordnete Menge von standardisiert - geschlossenen (durch Ankreuzen, Unterstreichen, Durchstreichen) und offenen Fragen (durch verbale Beschreibung). Fragebogenaktionen m√ľssen vom Systemplaner gut vorbereitet und organisiert sein. Bei der Frageformulierung sollten Suggestivfragen und provokante Fragen vermieden werden.




Beispiel f√ľr eine Suggestivfrage:

"Wie beurteilen Sie den mäßigen Erfolg unserer neuen Vertreterorganisation im Rahmen der Vertriebswege unseres Unternehmens? (Bitte ankreuzen)"


1
2
3
4
5
6
7
1 = ausgezeichnet







7 = vollkommen negativ

Im Einf√ľhrungsteil des Fragebogens soll der Befragte eine positive Einstellung zur Fragebeantwortung gewinnen. Im Befragungsteil werden die konkreten Antworten auf die zu erfassenden Informationen ermittelt. Im Schlussteil versucht der Systemplaner die Einstellung des Befragten zum Problem und zum geplanten Projekt f√ľr die Probleml√∂sung zu erfragen.

Einsatzgebiet:

Frageb√∂gen eignen sich f√ľr die Erfassung von einfachen, gleichf√∂rmigen Informationen von einer Vielzahl von Aufgabentr√§gern, die schwer zentral befragt werden k√∂nnen.

Vorteile
Nachteile


+ Befragte haben genug Zeit f√ľr Antworten
- geringe R√ľcklaufquoten
+ anonym möglich
- keine Dialogmöglichkeit
+ Angaben des Befragten dokumentiert
- Fragen können missverstanden werden
+ relativ kosteng√ľnstig

+ statistische Auswertungen möglich

+ gut mit Interview kombinierbar



5. 2.5 Interview


Beim Interview wird der Aufgabentr√§ger vom Systemplaner pers√∂nlich, m√ľndlich befragt. Der Interviewer muss √ľber die Aufgabenbereiche des Befragten einigerma√üen Bescheid wissen, um den gew√ľnschten Informationsbedarf decken zu k√∂nnen. F√ľr die Art der Fragestellung gelten die Regeln des Fragebogens. Neben Einzelinterviews sind auch Gruppenbefragungen mit dem Interviewer als Moderator m√∂glich.

Interviews f√ľhren leicht zu einer psychologischen Belastung des Befragten, die durch ein positives Gespr√§chsklima abgebaut werden k√∂nnen. Insbesondere sollen unberechtigte Bef√ľrchtungen des Befragten entkr√§ftet werden und Spekulationen durch Offenheit aus dem Weg ger√§umt werden. Der Interviewer soll nicht belehren sondern Fakten vermitteln um konkrete R√ľckmeldungen zu erhalten.. Jedes Interview sollte einem Leitfaden folgen, der einem Fragebogen √§hnlich sein kann.

Einsatzgebiet:

Der Istzustand komplexer betrieblicher Aufgaben und Arbeitsabläufe kann mit Interviews erhoben und analysiert werden.

Vorteile
Nachteile


+ Motivierungsmöglichkeit des Befragten
- Kosten - und zeitaufwendig
+ Vertiefung durch Nachfragen möglich
- Interviewer muss qualifiziert sein
+ "Verhör" als Methode einsetzbar
- Störung des Interviewten bei der Arbeit


6. 2.6 Zusammenfassung


Jede Planung eines neuzugestaltenden Organisationsbereiches erfolgt in Phasen. In der Literatur zur Systemplanung. werden verschiedene Phasenmodelle beschrieben. In den Phasen der Vorstudie (auch Grobstudie, Voruntersuchung, Machbarkeitsstudie genannt) und der Feinstudie (auch Istzustandsuntersuchung oder Detailstudie genannt) werden die - oben beschriebenen - Erfassungstechniken eingesetzt. Je nach Erhebungstechnik sind die einzelnen Methoden besser oder weniger gut f√ľr die Analyse geeignet. Die folgende Abbildung bietet eine Richtschnur f√ľr die Einsatzm√∂glichkeiten der einzelnen Techniken.


C. Darstellung des Ist Zustandes


Die Darstellung des Ist - Zustandes sollte jedenfalls schriftlich in einer strukturierten, √ľbersichtlichen Form erfolgen. Zum leichteren Verst√§ndnis sollte die schriftliche Dokumentation mit grafischen Methoden der Darstellung erg√§nzt werden.

Bei der grafischen Darstellung ist zwischen der Aufbauorganisation und der Ablauforganisation zu unterscheiden.

1. Darstellung der Aufbauorganisation (Folie 14)


Die Zuteilung von Aufgaben und Kompetenzen auf die einzelnen Bereiche, Abteilungen und Stellen eines Unternehmens geschieht mittels der Aufbauorganisation.
Die Stelle ist das Grundelement der Aufbauorganisation. Sie entsteht dadurch, dass mehrere Aufgaben zusammengefasst und einer Person zur Erf√ľllung √ľbertragen werden.

2. Stellenbeschreibung


Die Stellenbeschreibung ist die schriftliche Festlegung der Aufgaben, die von einer Person an einer Stelle durchzuf√ľhren sind, sowie die Kompetenz und die Verantwortung, die ihr dabei zukommen.
Am Beispiel der Stellenbeschreibung f√ľr den Netzwerkadministrator und PC - Benutzerberater wird der Grundinhalt Stellenbeschreibung erarbeitet:

Stellenbezeichnung: Netzwerkadministrator und PC - Benutzerberater

Qualifikation: Abschluss einer berufsbildenden höheren Schule oder vergleichbare Qualifikation

Stelleninhaber: Peter Baumgartner

Fachbereich: Informations - und Kommunikationssysteme

Kostenstelle: Informations - und Kommunikationssysteme 2467

Rangstufe: Berater

Stellenbezeichnung des unmittelbaren Vorgesetzten: Leiter des Fachbereichs nformations und Kommunikationssysteme

Name des unmittelbaren Vorgesetzten: Dr. Franz Buhl



Der Stelleninhaber nimmt in folgenden Angelegenheiten
    Bedarf an Anwendungssystemen Kosten - und Leistungsplanung Netzwerk Informationstransfer innerhalb und außerhalb des Unternehmens Softwareentwicklung und Systembetrieb Informations - und Kommunikationsinfrastruktur Ablauforganisation
fachliche Anregungen entgegen von: allen Abteilungen des Unternehmens
Stellenbezeichnung der unmittelbar unterstellten Mitarbeiter: Schreibkraft
Namen der unmittelbar unterstellten Mitarbeiter: Birgit Berger
Der Stelleninhaber wird vertreten von: Franz Breitfuß
Der Stelleninhaber vertritt: niemanden

Spezielle Befugnisse des Stelleninhabers:
- Vorschlag √ľber den Einsatz von PC und deren Software
- Vorschlag zur Ablauforganisation
- Vorschlag zur Aufbauorganisation
- Entwicklung von Software

Zielsetzung der Stelle:
Die Stelle hat den PC - Betrieb in der Unternehmung sicherzustellen. Im Besonderen hat die Stelle daf√ľr Sorge zu tragen, dass das Netzwerk einwandfrei und schnell funktioniert. Sie hat weiters die Softwareentwicklung auf den PC so zu planen, dass ausreichende Rationalisierungspotentiale ausgesch√∂pft werden k√∂nnen.

Weitere Aufgaben sind die Benutzerberatung und die Benutzerbetreuung in allen dezentralen EDV - Angelegenheiten der Informationsverarbeitung.

Der Stelleninhaber erf√ľllt im selbst√§ndigen Verantwortungsbereich entsprechend den allgemeinen F√ľhrungsrichtlinien laufend folgende Aufgaben:
    Fachliche Beratung der Anwender Planung der PC - Infrastruktur Planung der notwendigen dezentralen Anwendungssoftware Erarbeiten von Schulungskonzepten f√ľr die Mitarbeiter

Der Stelleninhaber hat folgende Kompetenzen:
- Vorschlagsrecht zur Anschaffung von dezentraler Hardware und Software
- Vorschlagsrecht zu Organisationsänderungen

Der Stelleninhaber kooperiert in folgenden Angelegenheiten
    Softwareentwicklung Softwarepflege Kommunikationsinfrastruktur
mit: allen Abteilungen


Der Stelleninhaber informiert in folgenden Angelegenheiten regelmäßig den Vorgesetzten:
- Monatliche, j√§hrliche und f√ľnfj√§hrige Planung
- Vergleiche zwischen Ist und Soll bei der Kosten - und Leistungsrechnung
- Außerordentliche Situationen



Der Stelleninhaber nimmt an folgenden Ausschusssitzungen regelmäßig teil:
- Sitzungen der EDV - Planungsgruppe
Vorteile der Stellenbeschreibung aus der Sicht des Mitarbeiters

    Er wei√ü, was von ihm erwartet wird, er kennt seine Aufgaben, seine Verantwortung und seine Kompetenzen. Er kennt seinen Handlungsspielraum und kann gegebenenfalls T√§tigkeiten ablehnen. Er wei√ü, von wem er Anweisungen entgegennehmen muss. Der Betriebsrat hat eine bessere √úbersicht √ľber die Stellenbewertung, Einstellungs - und Eignungspr√ľfungen sowie Bef√∂rderungs - und Lohnfragen. Die Einsch√§tzung der Angemessenheit des Gehalts der Mitarbeiter wird erleichtert. Es gibt Klarheit √ľber die Entwicklungs - und Aufstiegsm√∂glichkeiten.


Vorteile der Stellenbeschreibung aus der Sicht des Vorgesetzten

    Bessere √úbersicht √ľber die Aufgaben. Bessere Koordination der Aufgaben. Neue Mitarbeiter k√∂nnen rascher und leichter eingearbeitet werden. Die Leistungen der Mitarbeiter k√∂nnen eindeutig beurteilt werden. Unbesetzte Stellen k√∂nnen leichter ausgeschrieben werden. Die Mitarbeiter k√∂nnen gezielt ausgebildet werden. Improvisierte Einzelentscheidungen werden zur√ľckgedr√§ngt.

Nachteile der Stellenbeschreibung

    Die Erstellung, die laufende Weiterentwicklung und die Ver√§nderung der Stellenbeschreibung sind aufwendig. Allzu exakte Stellenbeschreibungen f√ľhren zu einer √úberorganisation. Stellenbeschreibungen bestehen oft nur auf dem Papier und werden von den Vorgesetzten und Mitarbeitern nicht beachtet. Stellenbeschreibungen k√∂nnen die Eigeninitiative hemmen,



Mehrere gleichartige Stellen werden in einer Abteilung zusammengefasst. In diesem Zusammenhang stellt sich die Frage, wie groß ist die Leitungsspanne (d.h. wie viele Mitarbeiter zu einer Abteilung zusammengefasst werden). Auf diese Frage gibt es keine eindeutige Antwort, sie hängt von mehreren Kriterien ab:
Von der Art der Tätigkeit: Je einfacher eine Aufgabenstellung ist, desto größer kann die Leitungsspanne sein.
Von der Qualifikation der Mitarbeiter: Je höher die Qualifikation der Mitarbeiter ist, desto größer kann die Leitungsspanne sein.
Vom F√ľhrungsstil: Wenn der Freiraum durch eine klare Zielsetzung gro√ü ist, und die Motivation der Mitarbeiter hoch ist, die vereinbarten Ziele zu erreichen, kann die Leitungsspanne gr√∂√üer sein.

In der Praxis liegt die Leitungsspanne im Durchschnitt zwischen 4 bis 10 Mitarbeitern. Moderne Managementphilosophien wie beispielsweise das "lean management" (schlanke Organisation) gehen davon aus, dass es durch entsprechende F√ľhrungstechniken, welche die Mitarbeiter zur selbst√§ndigen und eigenverantwortlichen Arbeit motivieren, gelingen sollte, die Leitungsspanne weiter zu erh√∂hen.
Wie einzelnen Stellen und Abteilungen gegliedert sind, kann in Form von Organigrammen grafisch √ľbersichtlich dargestellt werden:

3. Leitungssysteme


Das Leitungssystem definiert, wie die Weisungen und Informationen im Unternehmen fließen. Daraus lässt sich auch die Rangordnung einer Abteilung oder Stelle ableiten.

a) Linienorganisation


Die Linienorganisation ist die straffste Organisationsform, bei der die Weisungen und Informationen nur entlang der "Linie" gehen d√ľrfen.



















Wie in der obenstehenden Grafik dargestellt wurde, bietet die Linienorganisation klare Strukturen. Die Aufgaben, Kompetenzen, Verantwortungsbereiche und Anweisungsbefugnisse sind eindeutig festgelegt. Jede Stelle kann nur von einer ihr vorgesetzten Stelle (Instanz) Anweisungen erhalten und auch nur an ihre Instanz Informationen weitergeben.
Der gr√∂√üte Nachteil der Linienorganisation liegt in der mangelnden Flexibilit√§t, und der damit verbundenen B√ľrokratisierung. Dieser Nachteil f√ľhrt dazu, dass die Linienorganisation in der Praxis nur in den seltensten F√§llen derart streng vollzogen wird.

Beispiel: Wenn Herr Baumgartner, den Sie von der oben angef√ľhrten Stellenbeschreibung kennen, in seiner Funktion als Netzwerkadministrator an Frau Widman im Verkauf Anweisungen bez√ľglich der Datensicherung geben muss, so d√ľrfte er das gem√§√ü der Linienorganisation nicht direkt machen, sondern m√ľsste den Instanzenweg √ľber seinen Abteilungsleiter, die Gesch√§ftsf√ľhrung, den Verkaufsleiter beschreiten. Dass sich dies in der Praxis kaum bew√§hren wird, ist mehr als einsichtig.

b) Stablinienorganisation


Die Stablinienorganisation bildet eine Ergänzung der Linienorganisation. Einer Linienstelle kann dabei eine Stabsstelle zugeordnet werden. Die Stabsstelle berät die Linienstelle und hat keine direkte Weisungsbefugnis.



















Die klare Struktur als Vorteil der Linienorganisation bleibt auch bei der Stablinienorganisation erhalten. Der Nachteil der Schwerfälligkeit wird etwas gemildert. Zusätzlich können allerdings Kompetenzkonflikte zwischen der Linie und der Stabsstelle entstehen.
Beispiel: Wenn Peter Baumgartner in seiner Funktion als Netzwerkadministrator den Mitarbeitern Anweisungen √ľber den Umgang mit den Systemeinstellungen eines Arbeitsplatzes geben m√∂chte, kann er dies gem√§√ü der Stablinienorganisation nur √ľber die Gesch√§ftsf√ľhrung tun. In der Praxis wird das nicht funktionieren. Daher wird im Bereich Informatik nach anderen Modellen zu suchen sein.

c) Matrixorganisation


Bei der Matrixorganisation kommt es f√ľr manche Stellen zu Doppelunterstellungen. Ein klassisches Beispiel daf√ľr ist die Projektorganisation.

Beispiel: Im Zuge eines Projekts zur Einf√ľhrung eines automatisierten Bestellsystems wird ein Mitarbeiter der Einkaufsabteilung ins Projektteam berufen. Dabei wird vereinbart, dass der Mitarbeiter 40% seiner Arbeitszeit f√ľr das Projekt aufwendet und dass die Mehrbelastung in Form einer Projektpr√§mie abgegolten wird. Der Mitarbeiter bleibt fachlich weiterhin dem Einkaufsleiter unterstellt. Die Anweisungen bez√ľglich der Projektarbeit erh√§lt er allerdings vom Projektleiter.



















Abbildung Projektorganisation

Weitere Anwendungsgebiete f√ľr die Matrixorganisation ist die Aufteilung in Sparten und Funktionen. Eine Sparte kann ein eigener Produktbereich oder eine Niederlassung des Unternehmens sein.

4. Darstellung der Ablauforganisation (Folie 14)


Die Ablauforganisation regelt von welchen Stellen eine bestimmte Aufgabe, in welcher Reihenfolge, mit welchen Hilfsmitteln wie und in welcher Zeit zu erledigen ist.
Dabei ist anzustreben, dass jede Aufgabe, die im Unternehmen auftreten kann, derart beschrieben wird. Dadurch soll vermieden werden, dass einige Aufgaben nicht bzw. mehrfach (von unterschiedlichen Stellen) gelöst werden.

Beispiel: Ein Kunde sendet an die Tcom eine Reklamation, dass bei einem Laserdrucker die 2. Seite nicht automatisch vom richtigen Fach eingezogen wird. In der Posteingangsstelle wird diese Reklamation an die Abteilung Hardwareverkauf weitergeleitet. Ein Mitarbeiter dieser Abteilung reagiert nicht, da er der Meinung ist, dass dies ein Softwareproblem ist. Da der Kunde von der Tcom keine Reaktion erh√§lt, wendet er sich ver√§rgert an den Gesch√§ftsf√ľhrer, der verspricht sicherzustellen, dass dies in Zukunft nicht mehr passieren kann. Er veranlasst sofort eine √úberpr√ľfung der Reklamationsbehandlung.
Die Aufgaben werden zunächst in einzelne Arbeitsschritte zerlegt und den einzelnen Stellen zugeordnet. Jeder Arbeitsschritt sollte dabei möglichst genau beschrieben werden. Grafische Darstellungen des Ablaufes erleichtern den Überblick wesentlich.

Aufgabe: Behandlung einer Reklamation





Die Aktivitäten können entweder wie in dem obigen Beispiel mit Buchstaben oder grafischen Symbolen dargestellt werden. Jedenfalls sollte eine Legende angeschlossen werden.
Symbol
Bedeutung
V
verantwortliche Durchf√ľhrung
V / A
alternative verantwortliche Durchf√ľhrung
P
Pr√ľfung
P / A
alternative Pr√ľfung
E
Entscheidung

Bei den Hilfsmitteln wurden in diesem Fall die daf√ľr geeigneten Programme angef√ľhrt, es k√∂nnen aber auch Verzeichnisse, Kataloge, Dokumente und vor allem der Verweis auf die Dokumentation sein.

Die gewissenhafte Dokumentation der Arbeitsschritte bildet auch einen wichtigen Beitrag zum Qualit√§tsmanagement und ist eine Voraussetzung f√ľr die Zertifizierung nach einer Qualit√§tsnorm ISO900x.

In der letzten Zeit gewinnen Programmsysteme, mit denen der Arbeitsablauf in einem Unternehmen abgebildet werden kann, unter der Bezeichnung "Workflow" und "Groupware" zunehmend an Verbreitung.

Was ist Workflow - Management und Groupware?

Geschäftsprozesse

Ein Gesch√§ftsprozess besteht aus einer Menge von Aktivit√§ten, die ganz bzw. teilweise von ggf. verschiedenen Personen in einer definierten Reihenfolge ausgef√ľhrt werden m√ľssen. Dabei sind verschiedene Alternativen m√∂glich. Aktivit√§ten k√∂nnen beispielsweise sequentiell, parallel oder alternativ bearbeitet werden. Die Gesamtheit der Beschreibung der Aktivit√§ten, d.h. die Reihenfolge der Bearbeitung, die Beschreibung des Aufbaus und die Benennung von Verantwortlichen f√ľr Aktivit√§ten sowie die Beschreibung der informationstechnischen Hilfsmittel zur Durchf√ľhrung wird als Prozessmodell bezeichnet.

Ein systematisches Management von Gesch√§ftsprozessen dient der Minimierung von Reibungsverlusten bei der Bearbeitung von komplexen Vorg√§ngen, an denen mehrere Personen aus ggf. verschiedenen Abteilungen beteiligt sind. Solche Vorg√§nge erfordern ein hohes Ma√ü an Koordination und Kooperation der beteiligten Mitarbeiter. Systematisches Management von Gesch√§ftsprozessen bedingt daher die Modellierung, Analyse und Ausf√ľhrung von Gesch√§ftsprozessen.

    Modellierung: Ziel der Modellierung ist es, eine explizite Beschreibung der in einem Unternehmen ablaufenden Gesch√§ftsprozesse zur Verf√ľgung zu stellen und dadurch das Verst√§ndnis der einzelnen beteiligten Mitarbeiter f√ľr den Gesamtprozess zu erh√∂hen.

    Analyse: Nach der Erhebung eines Prozessmodells kann dieses durch vielf√§ltige Techniken analysiert werden. Durch Simulation k√∂nnen beispielsweise Verklemmungen oder kritische Pfade entdeckt werden. Au√üerdem lassen sich weitere Prozesseigenschaften, wie z.B. Auslastung der Mitarbeiter oder Ausf√ľhrungsdauer einzelner Prozessteile, untersuchen.

    Ausf√ľhrung: Werden Gesch√§ftsprozesse geeignet modelliert, kann sichergestellt werden, dass die Prozesse nur nach den im Modell festgelegten Regeln ablaufen k√∂nnen. Die rechnergest√ľtzte Ausf√ľhrung von Gesch√§ftsprozessen beinhaltet dazu ein automatisches Informieren der Mitarbeiter √ľber zu bearbeitende Aufgaben und das Bereitstellen der zugeh√∂rigen Information. Dar√ľber hinaus soll die M√∂glichkeit bestehen, Prozesse w√§hrend der Laufzeit an neue Gegebenheiten anzupassen, also dynamisch zu ver√§ndern.

Workflow - Management und Groupware

Werkzeuge, die zur Unterst√ľtzung der Koordination und Kooperation von Mitabeitern in interpersonellen Abl√§ufen dienen, werden unter dem Begriff Computer Supported Cooperative Work (CSCW) zusammengefasst. Im folgenden werden nur die Systeme betrachtet, die eine starke Aufgabenteilung unterst√ľtzen, n√§mlich Groupware - Systeme und Workflow - Management - Systeme.

Workflow - Management - Systeme

Workflow - Management - Systeme (WMS) eignen sich insbesondere zur Unterst√ľtzung von stark strukturierten Prozessen, d.h. Prozessen, die

    eine Reihe von Aktivitäten in einer bestimmten Reihenfolge bzw. parallel zueinander umfassen immer wieder in der gleichen oder ähnlichen Form auftreten mehrere Personen involvieren und einem starken Koordinierungsbedarf unterliegen.

Man spricht in diesem Zusammenhang oftmals auch von prozessorientierten Systemen. Workflow - Management - Produkte sind demnach Systeme, die u.a. zum Charakteristikum haben, Prozesse (Abl√§ufe) nach einem vorher definierten Modell zu steuern und eignen sich besonders f√ľr stark strukturierte und arbeitsteilige Organisationen.

Groupware - Systeme

Groupware - Systeme sind im Gegensatz zu Workflow - Management - Systemen eher f√ľr schwachstrukturierte Abl√§ufe geeignet. Sie haben dar√ľber hinaus die folgenden Eigenschaften:

•Groupware unterst√ľtzt die unternehmensweite Kommunikation.
•Groupware gestattet spontanes Agieren und Reagieren.
• Die Initiative geht h√§ufig vom Anwender und nicht vom System aus.



Bei dem Beispiel Gebrauchtwagenbörse fallen folgende Aufgaben an:

- Erfassen der Stammdaten von Händlern und Verkäufern
- Erfassen der Daten von Kunden und Interessenten
- Ausarbeiten von Kaufangeboten
- Erstellen der Kaufverträge und Eingabe der KFZ Daten
- Ausarbeiten und Kalkulation von Verkaufsangeboten
- Erstellen der Kaufvertr√§ge f√ľr den Verkauf
- Ermittlung und Abrechnung der Provisionen

F√ľr jede dieser Aufgaben sind alle oben angef√ľhrten Fragen zu beantworten.

Dabei werden die betroffenen Mitarbeiter interviewt und beobachtet. Die Unterlagen (z.B. bestehende Kaufvertr√§ge, Karteikarten....) werden gesammelt. Die Anzahl der Anfragen und Gesch√§ftsf√§lle wird f√ľr bestimmte Zeitr√§ume ermittelt (z.B. 60 Kaufvertr√§ge pro Monat).

Das Resultat der Erfassung des Istzustandes wird in schriftlicher, tabellarischer und grafischer Form dokumentiert.




ABBILDUNG ISTZUSTAND

Bei der darauf folgenden Istzustandsanalyse wird der erhobene Istzustand mit dem Sollzustand verglichen und analysiert.

Das Resultat dieses Prozesses wird auch als Stärken - Schwächenprofil bezeichnet.

Manche festgestellten Schwächen lassen sich auch sofort ohne größeren Aufwand beheben.

Beispiel: Bei der Analyse des Istzustandes wurde festgestellt, dass bei der Kalkulation eines Verkaufsangebotes f√ľr einen PKW die Stehzeit (und die damit verbundenen Zinskosten) nicht ber√ľcksichtigt wurde.
Da dies ein Bestandteil des Sollkonzeptes ist, wurde beschlossen, dies bereits im bestehenden manuellen Verfahren einzubeziehen.

Die Phasen der Erhebung des Ist - Zustandes und der Erarbeitung eines Sollkonzepts lassen sich nicht trennen. Die Feststellung des Ist - Zustandes ist ein kommunikativer Prozess, bei dem die Anwender zu den Problempunkten W√ľnsche und Anregungen √§u√üern und die externen Berater Erfahrungen aus anderen Projekten einbringen.

IV. Grobprojektierung



In dieser Phase geht es um die Realisierung des Projektes. Die Gliederung dieser Phase ist von der Aufgabenstellung des Projektes abhängig.

So haben beispielsweise Projekte aus dem Marketingbereich andere Schwerpunkte als Projekte aus dem Bereich der EDV Organisation.

Dieses Kapitel bezieht sich auf die Realisierung von DV Projekten.

Gliederung der Projektierung von DV Projekten:

* Entwurf der Organisation
* Entwurf der Datenstruktur
* Pflichtenheft und Ausschreibung
* Bewertung der Angebote und Abschließen von Verträgen


A. Entwurf der Organisation (Folie 16)


Das durch die Erfassung des Istzustandes angepasste Sollkonzept bildet die Ausgangsbasis f√ľr den Entwurf.

Bei dem Entwurf des Organisationsmodells werden alle Aufgaben (Aktionen) beschrieben und f√ľr jede Aufgabe folgende Details festgelegt:

* die Reihenfolge der Aufgaben (Ablauf)
* wie werden die Aktionen durchgef√ľhrt (Masken und Methoden)
* welche Daten und Sachmittel sind erforderlich
* welche Stellen sind zuständig (Aufbauorganisation)
* welche Verbindungen und Schnittstellen sind zu ber√ľcksichtigen
* welche Sicherheitsvorkehrungen sind notwendig.


F√ľr die Darstellung der Reihenfolge der Aufgaben eignet sich ein Funktionendiagramm am besten. In diesem Diagramm k√∂nnen auch die zust√§ndigen Stellen sowie die Hilfsmittel √ľbersichtlich visualisiert werden.


Mittels der Aufgabenanalyse kann jede Aufgabe auch in einzelne Teilaufgaben zerlegt werden. Dieses Verfahren gleicht jenem der Programmanalyse, es wird TOP DOWN (vom gesamten Problem bis zu den einzelnen Aufgabenelementen) genannt.


In der Praxis hat es sich als g√ľnstig erwiesen, bereits in der Organisationsphase die Benutzeroberfl√§che (z.B. Men√ľtechnik), die Bildschirmmasken und die Listbilder f√ľr die einzelnen Aufgaben zu entwerfen.

Dies hat den Vorteil, dass sich der zuk√ľnftige Anwender "seine" L√∂sung besser vorstellen kann und auch konkretere Verbesserungsvorschl√§ge einbringen kann.

Mit den modernen Softwareentwicklungswerkzeugen (Datenbanksprachen der 4. Generation) ist es relativ leicht m√∂glich, die Bildschirmentw√ľrfe mit "Leben" zu versehen. Der Anwender ist damit gleich in der Lage, mittels der Entw√ľrfe Daten einzugeben. Die Daten werden nicht weiterverarbeitet, sondern dienen lediglich zu √úbungszwecken.

Diese Technik wird als "Prototyping" bezeichnet. Unter einem Prototyp wird eine schnell verf√ľgbare Vorabversion eines Anwendungssystems verstanden. Prototyping war fr√ľher unter Verwendung von Programmiersprachen wie Basic oder Cobol viel zu aufwendig und wurde erst durch die Entwicklung der Datenbanksprachen der 4. Generation wirtschaftlich einsetzbar.

Arten des Prototyping

Nach der Art des Prototyping wird zwischen explorativem, experimentellem und evolutionärem Prototyping unterschieden.
Exploratives Prototyping: Ziel des explorativen Prototyping ist eine m√∂glichst vollst√§ndige Spezifikation der Funktionsanforderungen des zu planenden Anwendungssystems. Zweck dieser Art des Prototyping ist es, den Systemplanern einen Einblick in die Anwendungsaufgabe zu erm√∂glichen, mit den Benutzern verschiedene L√∂sungsalternativen zu diskutieren und die Realisierbarkeit des geplanten Anwendungssystems in einem gegebenen organisatorischen Umfeld abzukl√§ren. Die Vorgehensweise ist dadurch gekennzeichnet, dass man - ausgehend von ersten Vorstellungen √ľber das geplante Anwendungssystem - einen Prototyp entwickelt, der es erlaubt, diese Vorstellungen anhand konkreter Anwendungsbeispiele zu pr√ľfen und die gew√ľnschten Funktionen sukzessiv auszuloten. Im Mittelpunkt stehen nicht die Qualit√§t des Prototyps, sondern seine Funktionalit√§t und leichte Ver√§nderbarkeit und die K√ľrze der Entwicklungszeit. Exploratives Prototyping unterst√ľtzt daher prim√§r die Spezifikation der Funktionsanforderungen.

Experimentelles Prototyping: Ziel des experimentellen Prototyping ist eine vollst√§ndige Spezifikation der Anforderungen. Zweck dieser Art des Prototyping ist es, die Tauglichkeit von Objektspezifikationen, von Architekturmodellen und von L√∂sungsideen f√ľr einzelne Systemkomponenten nachzuweisen. Die Vorgehensweise ist. dadurch gekennzeichnet, dass man - ausgehend von ersten Vorstellungen √ľber die Zerlegung des Systems - einen Prototyp entwickelt, der folgendes erlaubt: die Wechselwirkungen zwischen den Systemkomponenten zu simulieren, anhand konkreter Anwendungsbeispiele die Zweckm√§√üigkeit der Schnittstellen der einzelnen Systemkomponenten zu √ľberpr√ľfen und die Flexibilit√§t der Systemzerlegung im Hinblick auf Erweiterungen im Experiment zu erproben. F√ľr die Qualit√§t des Prototyps gilt das beim explorativen Prototyping Gesagte. Experimentelles Prototyping unterst√ľtzt also prim√§r das System - und Komponentendesign der Anwendungssoftware.

Evolution√§res Prototyping: Ziel des evolution√§ren Prototyping ist eine inkrementelle Systemplanung, das hei√üt eine sukzessive Planungsstrategie nach folgender Vorgehensweise: Entwicklung eines Prototyps f√ľr die klar definierten Anforderungen. Das Ergebnis dient als Basissystem f√ľr den Anwender und f√ľr den n√§chsten Planungsschritt. Mit dem n√§chsten Planungsschritt werden weitere Anforderungen integriert und der Entwicklungsprozess beginnt von neuem. Damit wird die Systemplanung zu einem Prozess, der die Anwendung st√§ndig begleitet. Prototyp und produktives Anwendungssystem sind nicht mehr unterscheidbar.

Die Versuchung, den Prototyp zum Anwendungssystem "hochzuziehen" ist in vielen F√§llen sehr gro√ü. Die Erfahrung hat gezeigt, dass dies meist deswegen problematisch ist, da die Prototypen unsystematisch wachsen und somit nicht klar und systematisch aufgebaut sind. Sie entsprechen nicht den Qualit√§tsanforderungen f√ľr ein Softwareprodukt! Auch wenn es oft weh tut:

Prototypen sind ein Wegwerfprodukt!

Der konsequente Folgeschritt besteht darin, die Methoden und Entscheidungsregeln der Weiterverarbeitung zu den Bildschirmentw√ľrfen zuzuordnen.

Abbildung Bildschirmmaske f√ľr die Nachkalkulation

KFZ NACHKALKULATION

KFZ NR.: ____ MARKE _________________ TYPE: __________ FARBE: ________

EINKAUFSPREIS: ______ REPARATURKOSTEN: ______ KAPITALKOSTEN: ______

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

VORKALKULIERTER VERKAUFSPREIS: ______
TATS√ĄCHLICHER VERKAUFSPREIS: ______

RABATT: __._
DECKUNGSBEITRAG: __._

F1 = HILFE ESC = ENDE F3 = SUCHEN F10 = SPEICHERN
Zu jedem Eingabefeld werden die Regeln und Methoden - soweit notwendig - beschrieben. Kennzeichnen der Pflichtfelder: Eingabefelder die zwingend einzugeben sind, werden gesondert markiert.

Methoden:
* Kapitalkosten: 1. Tage berechnen
(Verkaufsdatum - Einkaufsdatum)
2. Zinsen berechnen
Einkaufspreis * Tage * Zinssatz/36000

* Deckungsbeitrag: 1. Direkte Kosten
Einkaufspreis + Reparaturen + Zinsen
2. Deckungsbeitrag in % vom Verkaufspreis
(Verkaufspreis - Kosten)*100/Verkaufspreis


Bei der Analyse der Aufgaben k√∂nnen bereits die daf√ľr notwendigen Informationen abgeleitet werden. Die Strukturierung dieser Daten ist Inhalt des n√§chsten Abschnittes.

Die Zuordnung der Aufgaben oder Teilaufgaben zu den bestehenden oder neu zu schaffenden Stellen kann in Form von Stellenbeschreibungen geschehen.

In den Stellenbeschreibungen sollten auch die Verbindungen zwischen den einzelnen Stellen festgehalten werden.

Beispiel: Die Verrechnungsstelle hat die Aufgabe, die abgeschlossenen Kaufvertr√§ge abzurechnen (z.B. Rechnungen zu erstellen oder auch die Nachkalkulation und die Provisionsabrechnung f√ľr den Verk√§ufer durchzuf√ľhren). Sie ben√∂tigt f√ľr die richtige Durchf√ľhrung alle Daten √ľber den Kaufvertrag vom Verk√§ufer und die Lagerungskosten vom Kundendienst. Die Verrechnungsstelle gibt t√§glich eine Kopie aller Fakturen an die Buchhaltung weiter.

Inhalt der Stellenbeschreibung können auch die zu verwendenden Methoden sein.

Zum Organisationsentwurf geh√∂ren auch die Entw√ľrfe f√ľr die Raumorganisation und die damit verbundenen Transportwege, sowie die Vorkehrungen f√ľr die Datensicherung und den Datenschutz.

Beispiele f√ľr die Datensicherungsma√ünahmen in unserem Fallbeispiel:

- √úberlegungen, was geschehen soll, wenn der zentrale
Computer ausfällt (ev. Ausweichsystem).

- Zugriffsbeschr√§nkungen √ľber Codew√∂rter (speziell f√ľr
den Zugriff mittels dem öffentlichen Fernsprechnetz).

- Festlegen, wer welche Datenfelder ansehen oder
verändern darf.

B. Entwurf der Datenstruktur (Folie 17)


Bei dem Entwurf der Datenstruktur werden die notwendigen Daten abgeleitet, zu Gruppen (Tabellen) zusammengefasst und deren Beziehungen zueinander definiert.

Dabei sollte jede Redundanz (mehrfache Speicherung derselben Information) vermieden werden

Der Vorgang, eine Tabelle derart zu aufzuteilen, dass keine redundanten Daten mehr gespeichert werden, heißt Normalisierung.
In Datenbanksystemen werden die Dateien Tabellen genannt. Die durch die Normalisierung entstandenen Tabellen m√ľssen wieder miteinander in Beziehung (Relation) gesetzt werden.

Dabei unterscheidet man 3 Arten von Beziehungen.

1. Die 1:N Beziehung


Jedem Datensatz der Haupttabelle k√∂nnen beliebig viele Datens√§tze in der verkn√ľpften Detailtabelle zugeordnet werden.
Angenommen, man wollte die Beziehung zwischen den KFZ und deren Besitzer speichern. Beispielsweise h√§tte die Firma "W√ľstenrot" 3 KFZ, dann w√ľrden dem Datensatz "W√ľstenrot" der Besitzer - Tabelle (Haupttabelle) 3 Datens√§tze der KFZ - Tabelle (Detailtabelle) zugeordnet werden.
Um in der Praxis leicht feststellen zu können, welche die Haupttabelle und welche die Detailtabelle ist, merke man sich einfach folgende Aussage:
Ein (1) Besitzer kann mehrere (N) Autos haben, aber ein Auto hat nur einen Besitzer. Daher ist die Besitzer - Tabelle die Haupttabelle.
Diese Art von Beziehung ist die am häufigsten verwendete Beziehung Typische Beispiele sind:

















Haupttabelle Detailtabelle

Kunde


Auftrag 1


Auftrag N


Firma



Mitarbeiter1


Mitarbeiter N


Um eine 1:N Relation zu bilden, muss in der Haupttabelle ein Feld als Prim√§rschl√ľssel definiert sein. Dieses Datenfeld dient als Verbindungsfeld, und muss auch in der Detailtabelle (dort jedoch keinesfalls als Prim√§rschl√ľssel) definiert werden.
Beispielsweise wird das Feld Kundennummer verwendet, um die Haupttabelle "Kunden" mit der Detailtabelle "Auftrag" zu verkn√ľpfen. Dieses Feld muss in beiden Tabellen vorhanden sein, und ist lediglich in der Tabelle "Kunden" als Prim√§rschl√ľssel definiert.

2. Die 1:1 Beziehung


In diesem Fall ist immer nur ein Datensatz der Haupttabelle mit einem Datensatz der Detailtabelle verkn√ľpft. Diese Art von Beziehung ist in der Praxis eher selten anzutreffen, da oftmals kein Grund f√ľr eine Normalisierung (Zerlegung in Einzeltabellen) besteht.
Sinnvoll ist diese Verkn√ľpfung z.B., wenn nicht jedem Datensatz der Haupttabelle ein Datensatz der Detailtabelle zugeordnet wird.
Beim obigen Beispiel m√ľsste man einen "Besitzer" als einen Besitzer eines F√ľhrerscheins definieren. Dann w√ľrde eine 1:1 Beziehung bedeuten, dass ein F√ľhrerscheinbesitzer nur ein Auto haben kann. Viele F√ľhrerscheinbesitzer haben jedoch kein Auto. In diesem Fall kann durch die Definition einer 1:1 Beziehung viel Speicherplatz gespart werden, da der Platz nur dann ben√∂tigt wird, wenn ein F√ľhrerscheinbesitzer auch ein Auto besitzt.
Auch hier dient ein Datenfeld f√ľr die Verkn√ľpfung der Datens√§tze. Dieses Datenfeld muss in der Haupttabelle als Prim√§rindex definiert sein.
1 : 1









Abb. Definition von Beziehungen unter MS - ACCESS

3. Die N:M Beziehung


Diese Art von Beziehung ist schwierig zu definieren, und wird daher in der Praxis nicht sehr häufig verwendet.
Ein Beispiel f√ľr eine N:M Relation ist die Verkn√ľpfung einer Lehrertabelle mit einer Sch√ľlertabelle. Hier unterrichtet zwar ein Lehrer eine bestimmte Anzahl von Sch√ľlern. Jedoch wird ein Sch√ľler wiederum von unterschiedlichen Lehrern unterrichtet.














Einige Datenbanksysteme bieten M√∂glichkeiten um diese Relation zu verwalten, bei vielen muss eine andere L√∂sung gefunden werden. So k√∂nnte z.B. das obige Beispiel durch die Einf√ľhrung einer weiteren Tabelle f√ľr die Unterrichtsf√§cher gel√∂st werden.


Dies soll am Beispiel "Gebrauchtwagenbörse" demonstriert werden:


1. Bilden von Tabellen:
















2. Erarbeiten der Satzstrukturen

Kurzname z 15 Marke z 15
Mitgliedsnr. z 5 Type z 10
Name z 35 Baujahr z 4
Straße z 20 Farbe z 10
Plz z 6 KM n 6
Ort z 20 Anzahl Vorbesitzer n 2
Telnr. z 12 Kurznamen
Telex z 12 Händler n 15
Faxnr: z 12 letzter Besitzer n 15
Mitglied seit d 8 Zustand z 1
Provisionssatz n 4,2 Einkaufspreis n 7
Verkaufspreis n 7
Statistik je Monat Datum Einkauf d 8
Anzahl n 4 Art z 8
Umsatz n 7 laufende NR n 4
Deckungsbeitrag n 7
Provision n 7
Lagerwert n 7



3. Definition der Schl√ľsselbegriffe und Verbindungen:

* Händlertabelle:

- Kurzname primär (=eindeutig)
- Mitgliedsnr. primär (=eindeutig)

* KFZ Tabelle:

- Marke + Type + Farbe sekundär (kann mehrfach vorkommen)
- Marke + Verkaufswert sekundär
- Art + Verkaufswert sekundär
- Art + Farbe sekundär
- laufende Nummer primär

Als Verbindung zwischen der KFZ und Händlertabelle dient der Kurzname des Händlers.

C. Lastenheft / Pflichtenheft und Ausschreibung (Folie 18)


F√ľr die Entwicklung der Software bestehen folgende M√∂glichkeiten:

- Einsatz von Standardsoftware (bereits bestehende, vielfach
eingesetzte Software)

- Individualsoftware (speziell f√ľr die Bed√ľrfnisse des Anwenders
neu entwickelte Software)

Hier ist zwischen 2 Varianten zu wählen:
* Eigenentwicklung oder
* Fremdbezug

Werden die Anforderungen nur vom Auftraggeber - ohne Mitwirkung des Auftragnehmers - zusammengestellt, so wird das Resultat "Lastenheft" genannt. Diese Variante ist beispielsweise dann gegeben, wenn die Anforderungen in einer Ausschreibung m√ľnden.

Von einem Pflichtenheft spricht man, wenn beide Seiten (Anwender und Entwickler) die Anforderungen erarbeiten und im Detail festlegen.

Die Erstellung eines Pflichtenheftes ist bei allen Varianten notwendig. Die Durchf√ľhrung einer Ausschreibung entf√§llt im Falle der Eigenentwicklung. Auf die Kriterien f√ľr die Auswahl der Variante wird beim n√§chsten Abschnitt eingegangen.




1. Ausarbeiten eines Pflichtenheftes


Das Pflichtenheft hat den Zweck, alle Anforderungen an das System zu dokumentieren, damit sich der Anbieter (bzw. der zuk√ľnftige Entwickler) mit dem System vertraut machen kann, um ein m√∂glichst genaues Angebot erstellen zu k√∂nnen. Das Lastenheft stellt auch einen festen Bestandteil der Vertr√§ge dar, es sollte daher m√∂glichst wenig Freiraum offen lassen.

Das Lastenheft beschreibt, was das Produkt leisten soll, aber nicht wie es realisiert wird!

Das Lastenheft bildet einerseits die Vorgabe f√ľr die Entwicklung sowie die Grundlage f√ľr die Abnahme und die weiteren Entwicklungsschritte.

Folgende Struktur des Lastenheftes hat sich bewährt:

* Darstellung der Ziele des Projekts
* Beschreibung der Systementw√ľrfe
* Definition der Schnittstellen
* Abnahmebedingungen
* Festlegung der gew√ľnschten Konfiguration

* Vorstellung der Organisation des Unternehmens

Der Anbieter sollte sich ein erstes Bild von dem Unternehmen machen können. Dazu sind folgende Daten erforderlich:

- Größe und Rechtsform des Unternehmens
- Branche, Märkte, Tätigkeit und Schwerpunkte
- Besonderheiten in der Organisation

* Darstellung der Ziele des Projekts

Der Entwickler muss die Ziele des Projekts genau kennen, da er ansonst nicht in der Lage ist, die Entw√ľrfe richtig einzuordnen. Es sollte auch die M√∂glichkeit, dass der Anbieter vielleicht in manchen Teilbereichen eine bessere L√∂sung vorschl√§gt, nicht ausgeschlossen werden.

* Beschreibung der Systementw√ľrfe

Den zentralen Bestandteil des Lastenheftes bildet sicherlich die systematische und √ľbersichtliche Beschreibung der Systementw√ľrfe.

Hier sollten die im vorangegangenen Abschnitt beschriebenen Entw√ľrfe genau und umfassend beschrieben werden, damit die Gefahr der Missverst√§ndnisse und Fehlinterpretationen weitestgehend gebannt wird.
Beim Lastenheft kann auf die Definition der Datenstrukturen und des Datenmodells verzichtet werden.
* Beschreibung der Schnittstellen

Schnittstellen zu bereits bestehenden oder geplanten Anwendungen sind ebenfalls festzulegen. Wenn Daten an au√üenstehende Firmen weitergegeben bzw. von diesen √ľbernommen werden sollen, sind auch diese externen Schnittstellen im Detail festzulegen. Weiters sollten bereits Umstellungsarbeiten wie z.B. die √úbernahme vorhandener Daten in das neue System angef√ľhrt werden.

* Festlegung der gew√ľnschten Konfiguration

Bis jetzt stand die Organisation und die Software im Vordergrund. Das ist so richtig, denn die notwendige Hardware ist daraus abzuleiten.

So bestimmt z.B. die Stellenbeschreibung, welche Stellen mit Computerarbeitspl√§tzen auszustatten sind. Aus der Beschreibung der Datenstrukturen in Verbindung mit dem Mengenger√ľst der Istzustandserfassung ergibt sich die Gr√∂√üenordnung der externen Speicher.

Bei unserem Fallbeispiel wurde bereits in der Vorstudie entschieden, dass alle H√§ndler online mir der zentralen Datenbank verbunden sind. Daher steht fest, dass Einrichtungen f√ľr die DF√ú (Datenfern√ľbertragung) notwendig sind.

Es hat sich als ein Vorteil erwiesen, dem Anbieter bei der Bestimmung der Konfiguration einen breiten Spielraum zu lassen, da die Hardware genau auf die angebotene Software abzustimmen ist.

Zu ber√ľcksichtigen sind lediglich folgende Punkte:

* Anzahl und Art der Computerarbeitsplätze
* Ergonomische Anforderungen (z.B.: Arten Farbbildschirme, Größe...)
* Anzahl und Art der Drucker (z.B.: Nadeldrucker f√ľr Formulare mit
Durchschl√§gen, Tinten oder Laserdrucker f√ľr Textverarbeitung)
* Die Zentraleinheit (CPU) ist abh√§ngig von der Wahl des Betriebssystems (z.B. entweder ein PC Netzwerk unter MSDOS, Windows NT oder OS/2, oder ein Mehrplatzsystem unter UNIX). Die Auswahl des Betriebssystems kann ebenfalls dem Anbieter √ľberlassen werden, au√üer betriebsinterne Gegebenheiten (z.B. Kompatibilit√§t zu bestehenden L√∂sungen) oder strategische √úberlegungen (zukunftssichere Softwareinvestition) legen das Betriebssystem fest.

    Die Gr√∂√üe der externen Speicher ist nur dann wesentlich, wenn noch andere Anwendungen auf diesem System laufen sollen. Die Zugriffsgeschwindigkeit auf externe Speicher kann in Form der Vorgabe der durchschnittlichen Antwortszeit (= die Zeitspanne von der Best√§tigung einer Eingabe bis zur vollst√§ndigen Ausgabe am Bildschirm) abgedeckt werden. Zusatzeinrichtungen f√ľr DF√ú und Datensicherung sind gegebenenfalls anzuf√ľhren.



MUSTER
LASTENHEFT F√úR EIN EDV - GESAMTSYSTEM


1. Zum Unternehmen

Die G.W.B reg. Ges.m.b.H. ist ein Gemeinschaftsunternehmen mehrerer KFZ Betriebe zwecks Betreibung einer Gebrauchtwagenbörse.

In einer neu zu schaffenden Zentrale werden alle Angebote der Mitgliedsbetriebe und deren Kunden gespeichert und stehen f√ľr sowohl f√ľr die Mitgliedsbetriebe wie auch f√ľr Privatpersonen online zur Verf√ľgung.

Derzeit setzt sich die Genossenschaft aus 7 Mitgliedsbetrieben im Raum Salzburg und Oberösterreich zusammen. Die Zentrale ist in Linz geplant.

F√ľr die erste Phase sind in der Zentrale 4 Mitarbeiter geplant.

2. Ziele des Projekts:

* Steigerung des Umsatzes aller Mitglieder durch ein
aktuelles Online - Informationssystem.

* Verringerung der durchschnittlichen Verweildauer der
einzelnen Gebrauchtwagen.

* Vereinfachung und Beschleunigung der organisatorischen
Arbeitsabläufe bei den Mitgliedsbetrieben durch die
EDV Unterst√ľtzung.

* Gerechte und transparente Provisionsabrechnung.

* Automatisierte Abrechnung der Vermittlungsprovisionen.

* Bereitstellung statistischer Auswertungen.

3. Beschreibung des Systems
(aus Platzgr√ľnden kann hier nur die Gliederung angef√ľhrt werden)

3.1. Aufgabenbereiche

3.1.1. Stammdatenerfassung:

* Mitgliedsbetriebe
* Kunden
* Interessenten
* Angebote
* Anfragen
* Gebrauchtwagen
* Reservierungen
* Verträge


3.1.2. Abfragen

3.1.3. Kalkulation von Angeboten (Verkauf)

3.1.4. Durchf√ľhrung von Reservierungen

3.1.5. Pr√ľfung von Angeboten (Einkauf)

3.1.6. Abschließen von Verträgen (Einkauf und Verkauf)

3.1.7. Rechnungslegung und √úbergabe in die Buchhaltung

3.1.8. Provisionsabrechnung

3.1.9. Abruf von Statistiken

F√ľr jede Aufgabe w√ľrde nun die Aufteilung in Teilaufgaben mit einer genaueren Beschreibung folgen.


3.2. Entw√ľrfe von Bildschirmmasken und Listen.

Beilage mit der Zuordnung der Masken zu den einzelnen Aufgaben.

3.3. Datenbankdesign: Datenstruktur und Zugriffswege

3.4. Konfiguration

3.4.1. Hardware

3.4.1.1. Zentrale:

    * 3 Arbeitspl√§tze erweiterbar bis zu 20 Pl√§tze * 1 Nadeldrucker mit ca. 800 Zeichen / Sek. * 1 Laserdrucker mit 8 Seiten / Min. 2 DF√ú Anschl√ľsse mit Modem 1 ISDN Anschluss * Plattenspeicher ca. 1300 MB * 1 Streamer Tape mit 1 GB

3.4.1.2. Außenstelle:

* 1 PC mit DF√ú Anschluss
* 1 Nadeldrucker mit ca. 300 Zeichen / Sek.

Alternative Erweiterung bestehende Anlage







3.4.2. Software:

* Betriebssystem Zentrale: Windows NT oder UNIX

* Außenstelle: Windows 95

* Bestehende Software: WORD 6.0 f√ľr Textverarbeitung

3.5. Mengenger√ľst:

- Kunden: 2000
- Interessenten 10000
- Angebote 400
- Verträge 5000
- Gebrauchtwagen 1000
- Reservierungen 300

2. Durchf√ľhren der Ausschreibung


Zu den weiteren Punkten (Ausschreibung, Bewertung und Vertr√§ge) kommt es nur im Falle einer Fremdvergabe. Selbst in Betrieben, die √ľber eine eigene EDV - Abteilung verf√ľgen, werden Ausschreibungen f√ľr EDV Projekte durchgef√ľhrt, da Fremdleistungen aus verschiedenen Gr√ľnden vorteilhafter sein k√∂nnen.

Diese Gr√ľnde k√∂nnen sein:

- Die eigene EDV Abteilung ist √ľberbelastet.
- Softwareb√ľros verf√ľgen in bestimmten Bereichen oft √ľber
spezielles Know How.
- Es existieren bereits fertige Branchenlösungen.
- Externe Softwarepartner arbeiten wirtschaftlicher.

Eine Ausschreibung bildet f√ľr die Anbieter (Softwareb√ľros, Hardwarelieferanten) die Grundlage f√ľr die Angebotslegung, und soll dem Ausschreiber den Vergleich der Angebote erleichtern.

Das Lastenheft wird zu diesem Zweck mit folgenden Teilen ergänzt:

* Allgemeiner Teil:
- Vorstellung der Organisation des Unternehmens
- Regelungen zur Zusammenarbeit zwischen den Partnern in
der Angebotsphase.
- Richtlinien f√ľr die Gliederung der Angebote, damit diese
leichter vergleichbar sind.
- Zust√§ndige Kontaktpersonen f√ľr R√ľckfragen.
- Anzahl, Termin und Ort f√ľr die Abgabe der Angebote.
- Zeitplan von der Angebotsbewertung bis zum
Vertragsabschluß.
- Regelungen √ľber die Vertraulichkeit der Ausschreibungs -
unterlagen.

* Fragenkatalog:

1. Fragen zum Anbieter:

    Firmenbezeichnung, Rechtsform, Firmensitz Entwicklung der Firma - Anzahl Mitarbeiter pro Geschäftsstelle Name der Kontaktperson Erfahrungen auf diesem Gebiet und Referenzen verwendetes Datenbanksystem

2. Fragen zur angebotenen Hardware Konfiguration:

- Kapazität und Ausbaufähigkeit der Komponenten
(CPU, externe Speicher, Drucker)
- M√∂gliche Anzahl weiterer Terminals ohne sp√ľrbare
Verlängerung der Antwortszeiten.
- Kompatibilität zu bestehender Hardware.
- √úbertragungsgeschwindigkeiten bei PC - Netzwerken und
DF√ú Einrichtungen.

3. Fragen zur angebotenen Software

- Art und Release (Version) des Betriebssystems.
- Welche weiteren Tools stehen zur Verf√ľgung?
- Kompatibilitäten zu anderen Betriebssystemen
(z.B. Unix zu MSDOS).
- Ergonomie der Benutzeroberfläche
- Welche Teile der Anwendungssoftware sind Standard,
welche Teile sind individuelle Ergänzungen?
- Wer hat die Standardsoftware erstellt, wer w√ľrde
die individuellen Anpassungen durchf√ľhren?
- Seit wann und wo ist die Software in ähnlicher Form
eingesetzt (Angabe der Referenzen)?
- Auf welchem Datenbanksystem beruht die Software,
welche Methoden und Sprachen wurden verwendet?
- Unter welchen Betriebssystemen wurde sie bereits eingesetzt?
- Muster aus der Bedienungs - und Programmdokumentation.

4. Kostenvarianten f√ľr:

- Kauf oder Miete, Leasing (beruhend auf 5 Jahre) Hardware
- Nutzung der Software (einmalig oder laufend)
- Wartung Hardware und Software
- Organisation und Beratung
- Installation
- Schulung
- Erweiterungen

5. Weitere Leistungen des Anbieters:

- Unterst√ľtzung bei der Umstellung (z.B. Daten√ľbernahme).
- Interventionszeit bei Hardware oder Softwareproblemen.
- Verf√ľgbarkeit f√ľr Erweiterungen der Anwendungssoftware.
- Anzahl und Namen der Mitarbeiter, die bei der Umstellung
und bei ev. sp√§teren Problemen zur Verf√ľgung stehen.

Die Fragen sollten so gestellt sein, dass sie einfach mit Zahlen oder wenigen Worten (ja - nein) beantwortet werden können. Dies erleichtert die Auswertung der Angebote wesentlich.

D. Angebotsbewertung und Vertragsabschluß


Die Analyse und Bewertung der Angebote hat das Ziel, das f√ľr den Ausschreiber optimale Angebot herauszufinden.

Als Verfahren zur Unterst√ľtzung dieses schwierigen Entscheidungsprozesses bietet sich wiederum die Nutzwertanalyse an.

In der Phase der Vorstudie wurde die Nutzwertanalyse eingesetzt, um die optimale Lösungsvariante zu finden. Hier geht es darum, aus den unterschiedlichen Angeboten das am besten geeignete Angebot zu ermitteln.

Grundlage hierf√ľr bilden die Anforderungen des Lastenheftes, aus denen die Bewertungskriterien f√ľr die Angebote abgeleitet werden.

Dieser Kriterienkatalog wird sehr umfangreich sein, so dass eine Unterteilung in mehrere Hauptgruppen empfehlenswert ist. Diese Hauptgruppen können wiederum in Untergruppen gegliedert sein (je nach Größe des Projekts). Um die Ausarbeitung zu erleichtern sollte die Gliederung der des Fragenkataloges der Ausschreibung entsprechen.

Einen schwierigen Punkt stellt sowohl die Gewichtung der Hauptgruppen und der einzelnen Kriterien, wie auch die Bewertung der Angebote dar, da diese meist nur subjektiv erfolgen kann.

Es sollte innerhalb der Projektgruppe ein Konsens √ľber die Gewichtung der Kriterien und die Bewertung der Angebote angestrebt werden.

Die Entscheidung orientiert sich an der Relation zwischen Kosten und Nutzwert der einzelnen Angebote.


Ist die Entscheidung f√ľr einen Anbieter gefallen, so gilt es nun, die notwendigen Vertr√§ge abzuschlie√üen.
Folgende Verträge können bei einem EDV - Projekt anfallen:

* Kaufvertrag, Mietvertrag oder Leasingvertrag f√ľr die Hardware;
* √úberlassungsvertrag, Mietvertrag oder Leasingvertrag f√ľr die
Nutzung von Systemsoftware und Anwendungssoftware;
* Wartungsvertr√§ge f√ľr Hardware, Systemsoftware und
Anwendungssoftware;
* Versicherungsverträge zur Abdeckung von Risiken durch den
Einsatz von Hardware und Software.
* Vertrag √ľber Beratungsdienstleistungen.

Diese Verträge regeln die Rechtsbeziehungen zwischen Auftraggeber (Kunde) und Auftragnehmer (Lieferant) und minimieren die verborgenen Risiken der Vertragspartner.

Die meisten Verträge haben folgende Gliederung:

- Vertragsart (Kaufvertrag, Mietvertrag....);
- Vertragspartner;
- Beschreibung des Vertragsgegenstandes (z.B. Bezug auf das
Lastenheft, Wartungsgegenstand);
- Definition der Schnittstellen (extern und intern)
- Angaben zur √úbergabe und √úbernahme
(z.B. Liefertermin, Installation, Testzeiten);
- Möglichkeiten der Schulung (z.B. Zeitpunkt, Ort, Umfang, ...);
- besondere Rechte des Käufers/Mieters, z.B. Nutzungsrechte
(einfache Nutzung, Nutzung im Konzern);
- Vertragsdauer und K√ľndigungsfristen;
- Angaben √ľber das vereinbarte Entgelt (z.B. Transportkosten,
Installationskosten, Schulungskosten, .....);
- Angaben √ľber m√∂gliche Preisver√§nderungen w√§hrend der Laufzeit
(z.B. Indexklauseln);
- Lieferbedingungen und Zahlungsbedingungen
(z.B. Eigentumsvorbehalt, Haftungsr√ľckhalt, Vertragsgeb√ľhren);
- Gewährleistung, Konsequenzen bei Leistungsstörungen, Garantie
f√ľr die Versorgung mit Ersatzteilen;
- Angaben √ľber Schadenersatz (z.B. P√∂nale f√ľr
Lieferzeit√ľberschreitung);
- Regelungen bei Leistungsverzug (z.B. Zahlungsverzug beim Mieter,
√úberschreitung der Interventionszeit bei Hardwareproblemen);
- Vereinbarungen f√ľr Erweiterungen sowohl bei Hardware wie auch
Software;
- Regelungen zur Geheimhaltung
- Vorgehensweise bei Konkurs oder Liquidation (z.B. Hinterlegung
der Sourcecodes)
- Gerichtsstand

Die Erstellung von EDV Verträgen wird in vielen Fällen durch die bestehenden Geschäftsbedingungen der Lieferanten bestimmt.
Unabh√§ngige Vereine und Institutionen (z.B. √ĖCG √Ėsterreichische Computer Gesellschaft) haben f√ľr alle Bereiche Modellvertr√§ge erarbeitet, die darauf abzielen, einen allgemein g√ľltigen Vertragsrahmen zu schaffen. Dieser Vertragsrahmen ist dann jeweils auf das konkrete Projekt abzustimmen.

V. FEINPROJEKTIERUNG


Zweck dieser letzten Phase eines EDV Projektes ist es, die Anforderungen des Lastenheftes in ein funktionierendes Gesamtsystem umzusetzen.

Diese Aufgabe kann folgenderweise gegliedert werden:

- Systemanalyse
- Softwareentwicklung
- Testverfahren
- Installierung


A. Systemanalyse


W√§hrend der Vertragsverhandlungen wird das Lastenheft mit dem Anbieter (Softwareentwickler) im Detail besprochen und in einigen Punkten modifiziert. Das Resultat wird "angepasstes Pflichtenheft" bezeichnet; dieses bildet die Grundlage f√ľr die Systemanalyse.

Die im angepassten Pflichtenheft beschriebenen Aufgaben werden bis in die einzelnen Arbeitsschritte (Befehle) analysiert und in Module gegliedert.

Folgende Prinzipien sind dabei hilfreich:

* Das Prinzip "Top Down" besagt, dass ausgehend von einer Gesamtaufgabe diese schrittweise in Teilaufgaben zergliedert wird (sozusagen von oben herab, oder vom allgemeinen zum Detail).
Die hierarchische Struktur der einzelnen Elemente kann graphisch √ľbersichtlich dargestellt werden. Diese Darstellungsform wird "HIPO" genannt.



























ABBILDUNG HIPO

* Prinzip der Abstraktion: Die Kunst des Abstrahierens liegt in dem Erkennen gleicher Merkmale und allgemeing√ľltiger Regeln, sowie in dem Hervorheben des Wesentlichen.
Die derart erarbeiteten Module m√ľssen gen√ľgend Freiraum lassen, um durch weitere Erg√§nzungen oder Modifikationen eine konkrete Funktion aus√ľben zu k√∂nnen.
Die Weiterentwicklung dieses Prinzips m√ľndet in der "Objektorientierten Programmierung". Folgender Vergleich soll dem leichteren Verst√§ndnis dienen:

Ein Handelsunternehmen hat folgende gleiche Merkmale:

- Es werden G√ľter von Lieferanten eingekauft,
- diese werden gelagert, geringf√ľgig bearbeitet und
- an Kunden verkauft.

Dabei sind folgende allgemeing√ľltige Regeln zu erkennen:

- Die Einkaufpreise sollen möglichst niedrig sein,
- der Lagerbestand soll möglichst klein sein, und
- die Verkaufspreise sollen möglichst hoch sein.

Diese Merkmale und Regeln treffen auf jeden Handelsbetrieb zu, sie sind f√ľr einen bestimmten Betrieb zu erg√§nzen oder zu modifizieren (wenn z.B. gar kein Lager gef√ľhrt wird).


Dieses Beispiel mag auf den ersten Blick sehr einfach erscheinen, es ist jedoch ein ausgepr√§gtes abstraktes Denkverm√∂gen notwendig, um dieses Prinzip √ľberall anwenden zu k√∂nnen.

Durch die richtige Anwendung dieses Prinzips, gelingt es, die Effizienz der Softwareentwicklung wesentlich zu steigern.

* Prinzip der Modularisierung: Zusammengehörige Aufgaben bzw. Einzelschritte sollten in Module zusammengefasst werden. Die einzelnen Module sind mittels Schnittstellen miteinander verbunden. Durch die Definition der Schnittstellen ist es möglich, dass die einzelnen Module unabhängig voneinander entwickelt und getestet werden. Bei der Gestaltung der Module sollte darauf geachtet werden, keine direkten Beziehungen zwischen den einzelnen Modulen zu gestatten.
Die Programme werden dadurch leichter durchschaubar und änderbar.

Zur Beschreibung der Funktionen wird sehr h√§ufig der Pseudocode verwendet. Es ist dies eine Mischung aus nat√ľrlicher Umgangssprache mit formalen Elementen und einer klaren Struktur.

Das Kalkulationsprogramm könnte folgenderweise im Pseudocode beschrieben sein;

Wenn der Verkaufspreis Null ist, berechne den Verkaufspreis mit folgender Formel:
Verkaufspreis = Einstandspreis / (1 - Deckungsbeitrag /100)
Wurde im Feld Deckungsbeitrag nichts eingegeben, dann nimm 30 % f√ľr den Deckungsbeitrag an
ansonsten berechne den Deckungsbeitrag nach der Formel:
Deckungsbeitrag = (Verkaufspreis - Einstandspreis) *100 / Verkaufspreis
Vergleiche den Deckungsbeitrag mit dem Mindest - Deckungsbeitrag.
Wenn der Deckungsbeitrag die unterste Grenze unterschreitet,
dann mache eine Fehlermeldung und springe wieder zur Eingabe des Verkaufspreises.

Der Pseudocode ist sogar f√ľr ge√ľbte Anwender verst√§ndlich und dient als Vorstufe zur Programmierung.

Manche Sachverhalte lassen sich auch durch Entscheidungstabellen √ľbersichtlich und verst√§ndlich darstellen.


Der Mindest - Deckungsbeitrag ergibt sich beispielsweise in Abhängigkeit vom Lagerbestand nach folgender Regel:

Lagermenge
Preisuntergrenze = Minimal Deckungsbeitrag in %
bis 10
20
11 - 50
19
51 - 100
17
√ľber 100
15






B. Programmierung


Das Ergebnis der Systemanalyse bildet die Grundlage f√ľr die Softwareentwicklung. Dieses Ergebnis kann in Form von Diagrammen, Pseudocodes oder Struktogrammen vorliegen.

Die Wahl der Programmiersprache ist u.a. von

- der gew√ľnschten Portabilit√§t (Kompatibilit√§t zu anderen Betriebssystemen),

- den bereits bestehenden Softwarelösungen oder den Zukunftsperspektiven,

- der Erfahrung im effizienten Einsatz mit dieser Sprache abhängig.

Die Produktivität der Softwareentwicklung steigt durch den Einsatz von sogenannten CASE Tools in Verbindung mit 4 GL Sprachen beträchtlich.
(vgl. Band II Programmiersprachen)

CASE ist die Abk√ľrzung f√ľr Computer Aided Software Engineering. Dahinter steht ein durchg√§ngiges Konzept, bei dem der Computer von Beginn des EDV Projekts bis zum Umsetzen in eine Programmiersprache Unterst√ľtzung anbietet.

Im Idealfall k√∂nnen CASE Tools aufbauend auf die Festlegung der Datenstruktur und die Methodenbeschreibung automatisch ein Programm in der gew√ľnschten Programmiersprache generieren.

Als 4 GL (fourth Generation Language, Programmiersprachen der 4. Generation) werden Programmiersprachen bezeichnet, deren Funktionsumfang wesentlich gr√∂√üer als der Programmiersprachen der 3. Generation ist. Mittelpunkt dieser Systeme bildet in den meisten F√§llen ein Datenbanksystem mit vielen Tools, die es erm√∂glichen in k√ľrzester Zeit neue Eingabeprogramme oder Auswertungen zu generieren.

Beispiele: ORACLE, DATAFLEX, PROGRESS, INGRES, MAGIC.......


IV.3. Testverfahren

Die Testverfahren sollen die korrekte und fehlerlose Funktion des Gesamtsystems sicherstellen.

Wenn es bei der Systemanalyse gelungen ist, das Gesamtsystem in viele unabh√§ngige Module zu gliedern, ist das Testen wesentlich einfacher. In diesem Fall wird mit einem Einzeltest zun√§chst gepr√ľft, ob jeder Modul das gew√ľnschte Ergebnis (Schnittstelle) bringt. Dies kann auch zeitlich unabh√§ngig voneinander geschehen, da die Eingabeschnittstellen selbst (z.B. mit einem Editor) erzeugt werden k√∂nnen.

Erst wenn alle Module derart gepr√ľft wurden, wird deren richtiges Zusammenspiel in einem Integrationstest getestet.
Bei gr√∂√üeren Projekten ist es in manchen F√§llen zweckm√§√üig, einen sogenannten Parallellauf durchzuf√ľhren. Dabei wird eine gewisse Zeit hindurch das neue System (Nachfolgesystem) neben dem alten System durchgef√ľhrt und die Ergebnisse miteinander verglichen.
Dieses Verfahren belastet den Betrieb erheblich, da es mehr als den doppelten Aufwand (Lernkurve und Abstimmarbeit) verursacht. Es ist auch nur in jenen F√§llen geeignet, bei denen das neue System dieselben Aufgaben wie das alte System erf√ľllt (was z.B. in unserem Fallbeispiel nicht der Fall ist).

C. Installierung



Je nach Art des Projektes kann die Installierung entweder die Umstellung des alten Systems (Istzustand) auf das neue System, oder die Einf√ľhrung eines neuen Systems (z.B. bei einer Erweiterung oder einer g√§nzlichen Neuerung) bedeuten.

Die Installierung kann schrittweise (Stufenkonzept) oder auf einmal erfolgen.

In beiden F√§llen wird zwischen der Installationsvorbereitung und der Durchf√ľhrung unterschieden.

Bei der Vorbereitung werden die Voraussetzungen f√ľr die erfolgreiche Installierung geschaffen. Zu den Voraussetzungen z√§hlen:

* personelle Vorbereitung: Die wichtigste Voraussetzung f√ľr das Gelingen des Projekts ist die richtige personelle Besetzung und vor allem der Ausbildungsstand sowie die Motivation der zuk√ľnftigen Benutzer. Dies kann durch rechtzeitige Schulungs - und Trainingsprogramme erreicht werden.

* Räumliche Vorbereitung: Neben der ergonomischen Gestaltung der Arbeitsplätze zählt auch die Verlegung der Kabel dazu.

* Gerätetechnische Vorbereitung: Die Hardware sollte rechtzeitig aufgestellt werden, damit alle Komponenten ausreichend getestet und aufeinander genau abgestimmt sind (z.B. Drucker, Modem....).

* Datentechnische Vorbereitung: Die f√ľr die Ersterfassung notwendigen Daten (z.B. Stammdaten) m√ľssen vorhanden sein. Wenn Daten aus dem alten System automatisch √ľbernommen werden, sind die √úberleitungsprogramme genauso zu testen.

Die eigentliche Installierung ist gerade bei gr√∂√üeren Projekten mit Stichtagsumstellung oftmals ein Vorgang, bei dem die Nerven aller Beteiligten auf das √§u√üerste strapaziert werden, da einerseits die Benutzer noch unge√ľbt sind und damit leichter Fehler machen, und andererseits die Programme auf manche Fehler noch nicht richtig reagieren.

Diesem Problem kann durch verstärktes Testen der Programme und längeres Training der Benutzer begegnet werden.

Auf jeden Fall sollten die Probleme in einer Datenbank systematisch aufgezeichnet mit Beschreibung, Ursache, Lösungsansatz, Aufwand, Datum, Verantwortliche und Termine werden. Die Anwender sollten davon in Kenntnis gesetzt werden, wenn - und wie - die Probleme gelöst wurden.

Eines der schwierigsten Probleme sind die √Ąnderungsw√ľnsche bzw. Erg√§nzungen der Anwender in der Phase der Einf√ľhrung. Derartige √Ąnderungsw√ľnsche sind ab der Phase der Grobprojektierung problematisch, da sie u.U. grundlegende Strukturen der Software betreffen k√∂nnen. Besonders schmerzhaft sind sie in der Phase der Einf√ľhrung. Leider treten sie aber gerade hier verst√§rkt auf, da sich die viele Anwender erst jetzt voll mit der Software auseinandersetzen.

Wie kann diesem Problem begegnet werden?

Erst sind die Ursachen f√ľr die √Ąnderungen zu analysieren:

Gesetzliche √Ąnderungen
m√ľssen realisiert werden
Fehler bei der Bestandsaufnahme
Abw√§gen des Aufwandes und der Auswirkungen, wenn Aufwand gering und Auswirkung gro√ü, durchf√ľhren, ansonst verschieben und verhandeln
Missverständnisse und Fehlinterpretationen
Abw√§gen des Aufwandes und der Auswirkungen, wenn Aufwand gering und Auswirkung gro√ü, durchf√ľhren, ansonst verschieben und verhandeln
√Ąnderung der Anwenderw√ľnsche
Verschieben und verhandeln
Fehler in dem Systementwurf
bei grundlegenden Fehlern Termine verschieben und neu konzeptionieren (Kostenfrage!)

Sie k√∂nnen sich vorstellen, dass diese Phase nicht einfach ist. Es kommt dabei sehr auf das "Fingerspitzengef√ľhl" und das gegenseitige Verst√§ndnis der Beteiligten an, f√ľr beide Seiten akzeptable L√∂sungen zu finden. Wenn bei der Projektrealisierung die Grunds√§tze der Organisationsentwicklung ber√ľcksichtigt wurden, kann man davon ausgehen, dass alle Beteiligten daran interessiert sind, das Projekt erfolgreich abzuschlie√üen und bereit sind, auch Mehrbelastungen auf sich zu nehmen.









VI. QUALIT√ĄT, KONTROLLE UND DOKUMENTATION


Qualit√§ts√ľberlegungen, Kontrolle und Dokumentation sind projektbegleitende Aufgaben und erstrecken sich √ľber alle Phasen.

A. Qualität in der Softwareentwicklung


Abschlie√üend m√∂chte ich darauf hinweisen, dass die Software - Herstellung den Charakter einer Ingenieurdisziplin hat und viele √Ąhnlichkeiten mit der Herstellung anderer technischer Produkte aufweist. Softwareprodukte werden von mehreren Personen f√ľr mehrere Benutzer hergestellt, und sie werden immer h√§ufiger Bestandteile komplizierter technischer und betriebswirtschaftlich orientierter Systeme. Das hei√üt, ihre Funktionsf√§higkeit und Zuverl√§ssigkeit ist Voraussetzung f√ľr die Funktionsf√§higkeit des Gesamtsystems, dessen Bestandteile sie sind. Daher ist es fast selbstverst√§ndlich, dass sich die Frage stellt: Wie k√∂nnen die in der Industrie heute √ľblichen Qualit√§tsanforderungen auch an Softwareprodukte gestellt und wie kann ihre Einhaltung gepr√ľft werden?
Softwarequalit√§t ist aber keineswegs schon ein exakt definierter Begriff. Es herrscht jedoch Einigkeit dar√ľber, dass unter dem Begriff der Qualit√§t eines Softwareproduktes weit mehr zu verstehen ist als nur seine Korrektheit. Was sind nun die Qualit√§tsmerkmale, die sich aufgrund der Qualit√§tsanforderungen ergeben und die G√ľte eines Softwaresystems bestimmen? Wie kann man diese Merkmale messen? Welche Konsequenzen ergeben sich f√ľr die Softwaretechnik aus den Qualit√§tsanforderungen?
Qualitätsmerkmale von Software so wie die von Maschinen zu messen, ist bis heute kaum möglich - es fehlen die entsprechenden Methoden und Maße
In diesem Kapitel soll dargelegt werden, welche Merkmale die Qualit√§t von Softwareprodukten charakterisieren und welche Ma√ünahmen zur Qualit√§tssicherung notwendig sind. Da nach m.E. die Forschungsergebnisse zur Entwicklung von Kennzahlen f√ľr das Ma√ü der Erf√ľllung eines Qualit√§tsmerkmals noch zu unausgegoren sind, bleibt dieses Teilgebiet unbehandelt.

1. Softwarequalitätsmerkmale

Die Qualit√§tsanforderungen an Softwareprodukte fanden ihren Niederschlag in der Definition von Qualit√§tsmerkmalen. Dabei st√∂√üt man aber in der Praxis vielfach auf ungel√∂ste Probleme, die vor allem auf zwei Bereiche zur√ľckzuf√ľhren sind: Es fehlt eine allgemein verbreitete und anerkannte Definition der Begriffe Qualit√§t und Qualit√§tsmerkmal, und es ist eine eindeutige, objektive Bewertung der Qualit√§t eines Softwareprodukts nicht m√∂glich. Qualit√§t muss aber notwendigerweise ein Ziel der Software - Entwicklung sein und wirkt sich sowohl auf die Planung als auch auf die Durchf√ľhrung und die Kontrolle der Softwareherstellung aus. Folgende Abbildung zeigt die wichtigsten und auch in der Praxis anerkannten Qualit√§tsmerkmale von Softwareprodukten



a) Korrektheit


Unter der Korrektheit eines Programmsystems verstehen wir die Eigenschaft, dass das Programmsystem die der Programmentwicklung zugrunde gelegte Spezifikation erf√ľllt. Die Korrektheit eines Programmsystems bezieht sich also auf die √úbereinstimmung zwischen Spezifikation und Programmtext und ist daher unabh√§ngig von der tats√§chlichen Verwendung des Programmsystems.

Besonders kritisch ist das Problem der Korrektheit eines Programms, das in ein komplexes Programmsystem eingebettet werden soll. Ist n√§mlich p die Wahrscheinlichkeit daf√ľr, dass ein einzelnes Programm korrekt ist, so gilt f√ľr die Wahrscheinlichkeit P der Korrektheit eines Programmsystems, das aus n Programmen besteht: P=pn. Wenn n sehr gro√ü ist, muss daher p fast 1 sein, damit P √ľberhaupt wesentlich von Null verschieden ist.





Korrektheitswahrscheinlichkeit eines Gesamtsystems in Abhängigkeit
von der Anzahl und Korrektheitswahrscheinlichkeit seiner Teile

b) Zuverlässigkeit


Die Zuverl√§ssigkeit eines Programms wird durch die Korrektheit und durch die Verf√ľgbarkeit bestimmt. Die Korrektheit eines Programmsystems haben wir oben ohne jede Aussage √ľber das Zeitintervall, in dem das Programmsystem eine vorgegebene Spezifikation erf√ľllt, definiert. Das zeitliche Verhalten der Erf√ľllung einer vorgegebenen Spezifikation h√§ngt von der Zuverl√§ssigkeit des Programmsystems ab.

Wir definieren daher die Zuverl√§ssigkeit eines Programmsystems als die Wahrscheinlichkeit, dass dieses System w√§hrend eines vorgegebenen Zeitintervalls eine (durch die Spezifikation festgelegte) Funktion f√ľr eine vorgegebene Anzahl von Eingabef√§llen unter festliegenden Eingabebedingungen erf√ľllt (vorausgesetzt, Hardware und Eingabe sind fehlerfrei). Ein Programmsystem kann als zuverl√§ssig angesehen werden, wenn es eine geringe Fehlerrate aufweist. Die Fehlerrate (d. h. die Wahrscheinlichkeit, dass in einem bestimmten Zeitintervall ein Fehler auftritt) h√§ngt von der H√§ufigkeit der Eingaben ab und von der Wahrscheinlichkeit, dass eine einzelne Eingabe zu einem Fehler f√ľhrt.




c) Benutzerfreundlichkeit


Benutzerfreundlichkeit verstehen wir als √ľbergeordneten Begriff f√ľr die Ad√§quatheit, die Erlernbarkeit und Robustheit eines Programmsystems.
Die Forderung nach Adäquatheit bezieht sich auf
(1) die vom Benutzer verlangte Eingabe,
(2) die vom Programmsystem angebotene Leistung und
(3) die vom Programmsystem produzierten Ergebnisse.

    zu (1) Die erforderlichen Eingaben sollen sich auf das Notwendigste beschr√§nken. Informationen sollen nur dann vom Programmsystem erwartet werden, wenn sie f√ľr die vom Benutzer gew√ľnschten Funktionen erforderlich sind. Das Programmsystem soll dem Benutzer eine flexible Dateneingabe gestatten und Plausibilit√§tskontrollen der Eingabedaten durchfuhren. In dialogorientierten Programmsystemen kommt der Einheitlichkeit, Klarheit und Einfachheit der Benutzerf√ľhrung besondere Bedeutung zu.

    zu (2) Die Leistungsf√§higkeit eines Programmsystems soll unter Ber√ľcksichtigung der Erweiterbarkeit den W√ľnschen des Benutzers angepasst sein, d. h. die Funktionen sollen sich auf die in der Spezifikation vorgegebenen Funktionen beschr√§nken.

    zu (3) Die von einem Programmsystem gelieferten Ergebnisse sollen √ľbersichtlich und gut strukturiert ausgegeben werden und einfach zu interpretieren sein. Das Programmsystem soll dem Benutzer Flexibilit√§t bez√ľglich des Umfangs, des Detailliertheitsgrades und der Art der Pr√§sentation der Ergebnisse bieten. Eventuelle Fehlermeldungen m√ľssen in einer f√ľr den Benutzer verst√§ndlichen Form bereitgestellt werden.

Die Erlernbarkeit eines Programmsystems h√§ngt unmittelbar von der Ausgestaltung der Benutzerschnittstellen und der Klarheit und Einfachheit der Benutzeranleitung (oder des Benutzerhandbuchs) ab. Die Benutzerschnittstelle soll so geartet sein, dass sie die Information m√∂glichst realit√§tskonform pr√§sentiert und eine effiziente Nutzung der angebotenen Funktionen unterst√ľtzt.

Das Benutzerhandbuch (siehe nächsten Abschnitt) soll klar und einfach aufgebaut und von unnötigem Ballast frei sein. Es soll dem Benutzer erklären, was das Programmsystem insgesamt zu leisten imstande ist, wie die einzelnen Funktionen aktiviert werden, welcher Zusammenhang zwischen den Funktionen besteht, welche Ausnahmezustände auftreten und wie sie behoben werden können. Außerdem soll es ein Nachschlagewerk sein, das es gestattet, zu Fragen schnell und bequem die richtige Antwort zu finden.

Unter der Robustheit eines Programmsystems verstehen wir die Eigenschaft, die Auswirkungen von Bedienungsfehlern, falschen Eingabedaten und Hardwarefehlern abzuschwächen.
Ein Programmsystem ist robust, wenn die Folgen eines Fehlers in der Bedienung, der Eingabe oder der Hardware in bezug auf eine gegebene Applikation umgekehrt proportional zu der Wahrscheinlichkeit des Auftretens dieser Fehler in der gegebenen Applikation sind.

Das hei√üt, h√§ufig zu erwartende Fehler (z. B. fehlerhafte Kommandos, Tippfehler, ...) m√ľssen mit besonderer Umsicht behandelt werden, seltener erwartete Fehler (z. B. Stromausfall) k√∂nnen gro√üz√ľgiger behandelt werden, d√ľrfen aber trotzdem keine irreparablen Folgen nach sich ziehen.

d) Wartungsfreundlichkeit


Unter der Wartungsfreundlichkeit eines Programmsystems verstehen wir seine Eignung f√ľr die Lokalisierung von Fehlerursachen, f√ľr die Durchf√ľhrung von Fehlerkorrekturen und die Eignung zur Ver√§nderung oder Erweiterung der Programmfunktionen. Diese Definition deutet an, dass die Wartungsfreundlichkeit von der Lesbarkeit, der Erweiterbarkeit und der Testbarkeit eines Programmsystems abh√§ngt.

Die Lesbarkeit eines Programmsystems hängt von der Darstellungsform, vom Programmierstil und seiner Konsistenz, von der Lesbarkeit der Implementierungssprache, der Strukturiertheit des Systems, der Qualität der Dokumentation, aber auch von den Werkzeugen zur Inspektion eines Programmsystems ab.

Unter Erweiterbarkeit verstehen wir die M√∂glichkeit, gew√ľnschte √Ąnderungen an den passenden Stellen ohne unerw√ľnschte Nebenwirkungen einzuf√ľgen. Dies ist ganz besonders abh√§ngig von der Strukturiertheit (Modularit√§t) des Programmsystems und von den M√∂glichkeiten, die die Implementierungssprache daf√ľr zur Verf√ľgung stellt, aber nat√ľrlich auch von der Lesbarkeit (zum Auffinden der passenden Stellen), der Verf√ľgbarkeit einer verst√§ndlichen Programmdokumentation und von den zur Verf√ľgung stehenden Werkzeugen.

Unter Testbarkeit eines Programmsystems verstehen wir seine Eignung f√ľr die Verfolgung des Programmablaufs (Laufzeitverhalten unter vorgegebenen Bedingungen) und f√ľr die Lokalisierung von Fehlern. Die Testbarkeit h√§ngt im wesentlichen von der Modularit√§t und der Strukturiertheit des Programmsystems ab. Modulare, gut strukturierte Programme eignen sich besser zum systematischen, stufenweisen Testen als monolithische, unstrukturierte Programme. Testwerkzeuge und die M√∂glichkeit der Formulierung von Konsistenzbedingungen (Assertionen) im Quellcode reduzieren den Testaufwand und bilden wichtige Voraussetzungen f√ľr einen umfangreichen, systematischen Test aller Systemkomponenten.








e) Effizienz


Unter der Effizienz eines Programmsystems verstehen wir die Eigenschaft des Programmsystems, seinen Zweck unter bestm√∂glicher Ausnutzung aller ben√∂tigten Ressourcen zu erf√ľllen. Der Begriff "Ressourcen" muss dabei sehr weit gefasst werden und bezieht sich auf Zeit, Speicherplatz, √úbertragungskan√§le und periphere Einheiten.

f) Portabilität


Unter der Portabilit√§t eines Programmsystems verstehen wir die Leichtigkeit, mit der es auf andere Rechner √ľbertragen werden kann. Die Portabilit√§t eines Programmsystems h√§ngt also vom Grad seiner Rechnerunabh√§ngigkeit ab. Die Rechnerunabh√§ngigkeit ist z. B. bestimmt durch die Wahl der Implementierungssprache und durch den Grad der Ausnutzung spezieller Systemfunktionen und Hardwareeigenschaften. Die Portabilit√§t h√§ngt damit in hohem Ma√üe davon ab, ob das Programmsystem so organisiert ist, dass die systemabh√§ngigen Teile zu leicht austauschbaren Programmkomponenten zusammengefasst sind. Ein Programmsystem kann als portabel bezeichnet werden, wenn der √Ąnderungsaufwand f√ľr die √úbertragung wesentlich kleiner ist als der Aufwand f√ľr eine neue Implementierung.

2. Die Bedeutung der Qualit√§tsmerkmale f√ľr die Softwareherstellung


Die Qualit√§tsanforderungen an ein Softwareprodukt beziehen sich nicht nur auf das fertige (benutzerreife) Produkt. Die Qualit√§t des Endproduktes h√§ngt vielmehr von der Qualit√§t der Zwischenprodukte ab, d. h. die Qualit√§tsanforderungen beziehen sich auf alle Ebenen der Softwareherstellung. Schlechte Qualit√§t von Zwischenprodukten (z. B. Architekturdesign) hat immer schlechte Qualit√§t des Endprodukts zur Folge. Hinsichtlich der Qualit√§tsmerkmale und ihrer Bedeutung f√ľr den Herstellungsprozess unterscheiden wir zwischen: Qualit√§tsmerkmalen, die das Endprodukt betreffen und Qualit√§tsmerkmalen, die die Zwischenprodukte betreffen.

Qualitätsmerkmale von Endprodukten gliedern wir in:

    * Qualit√§tsmerkmale, die die Anwendung betreffen, Sie wirken auf die Eignung des Produkts f√ľr die geplante Anwendung. (Korrektheit, Zuverl√§ssigkeit und Benutzerfreundlichkeit), *Qualit√§tsmerkmale, die die Wartung betreffen, Sie wirken auf die Eignung des Produkts f√ľr Funktionsver√§nderungen und - erweiterungen (Lesbarkeit, Erweiterbarkeit und Testbarkeit), *Qualit√§tsmerkmale, die die √úbertragung betreffen. Sie wirken auf die Eignung des Produkts f√ľr die √úbertragung in eine andere Einsatzumgebung (Portabilit√§t und Testbarkeit).

Qualitätsmerkmale von Zwischenprodukten gliedern wir in:

    Qualit√§tsmerkmale, die die Transformation betreffen, Sie wirken auf die Eignung eines Zwischenprodukts f√ľr seine unmittelbare Transformation in ein nachfolgendes (h√∂herwertiges) Produkt (Korrektheit, Lesbarkeit und Testbarkeit), ¬∑Qualit√§tsmerkmale, die sich auf die Qualit√§t des Endprodukts auswirken. Sie wirken unmittelbar auf die Qualit√§t des Endprodukts (Korrektheit, Zuverl√§ssigkeit, Ad√§quatheit, Lesbarkeit, Erweiterbarkeit, Testbarkeit, Effizienz und Portabilit√§t).

3. Maßnahmen zur Qualitätssicherung


Softwarequalität entsteht nicht von selbst. Es bedarf einer Reihe von Maßnahmen, um sicherzustellen, dass das Endprodukt eine akzeptable Qualität aufweist. Die wichtigsten Maßnahmen dazu sind:

(1) Konstruktive Maßnahmen:
* Konsequente Methodenanwendung in allen Phasen des Entwicklungsprozesses,
* Einsatz adäquater Entwicklungswerkzeuge,
* Software - Entwicklung auf der Basis hochwertiger Halbfabrikate,
* konsequente Fortschreibung der Entwicklungsdokumentation.

(2) Analytische Maßnahmen:
* Statische Programmanalyse,
* dynamische Programmanalyse,
* systematische Auswahl geeigneter Testfälle,
* konsequente Protokollierung der Analyseergebnisse.

(3) Organisatorische Maßnahmen:
* Einsatz von Vorgehensmodellen,
* kontinuierliche Weiterbildung der Produktentwickler,
* Institutionalisierung der Qualitätssicherung


B. Dokumentation


Die Dokumentation begleitet das Projekt von der ersten Stunde bis zum endg√ľltigen Abschluss.
So ist z.B. bereits bei der Vorstudie zu kontrollieren, ob die gewählte Lösungsvariante tatsächlich mit den Projektzielen vereinbar ist. Anhand eines Beispieles aus der Praxis soll demonstriert werden, warum die laufende Dokumentation schon bei der Vorstudie so wichtig ist.

Bei der Vorstudie wird sehr viel Zeit mit dem Abw√§gen der einzelnen L√∂sungsvarianten oder von Teilbereichen daraus verbracht. Dabei treten zahlreiche Argumente f√ľr oder gegen einen Vorschlag auf.

Werden die Argumente, warum man sich f√ľr eine bestimmte Variante und nicht f√ľr andere Vorschl√§ge entschieden hat, nicht ausreichend begr√ľndet und dokumentiert, so l√§uft man Gefahr, dass nach einiger Zeit (u.U. von anderen Personen) wieder √ľber dasselbe Problem nachgedacht wird, und dass dabei einige wesentliche Argumente von damals in Vergessenheit geraten sind.

Jede Besprechung sollte systematisch protokolliert und geordnet - am besten in einer Datenbank - gespeichert werden. Mittels Stichwörtern, Teilnehmern oder Datum sollte auf das jeweilige Protokoll zugegriffen werden können.

Ein wesentlicher Punkt ist die Dokumentation der Programme selbst. Zunächst sind die Funktionen aller verwendeten Module zu beschreiben. Die Verwendung bzw. der gegenseitige Aufruf sollte u.U. grafisch dargestellt werden.
Der Programmcode selbst sollte mit ausreichenden Kommentaren versehen werden. Was als ausreichend zu bezeichnen ist, hängt von der gewählten Programmiersprache und dem jeweiligen Problem ab. In einer Richtlinie der IBM kann bis zu einem Verhältnis von 1 : 25 (ein Befehl mit 25 Wörtern Kommentar) gehen.

Eine gute Dokumentation erleichtert die Wartung der Software wesentlich und macht einen Personalwechsel nicht zur mittleren Katastrophe!

Jeder Softwareentwickler - besonders Entwicklungsgruppen - m√ľssen eigen Richtlinien dar√ľber aufstellen, wie Programme aufgebaut, Variablen und Felder benannt und wie die Benutzeroberfl√§che zu gestalten ist. Diese Richtlinien sind zu dokumentieren!
Wenn man allerdings das Rad nicht neu erfinden möchte, kann man sich an bestehenden Richtlinien orientieren. Beispielsweise hat Microsoft einen "style guide for applications" herausgegeben.

Viele Anwender sind beruhigt, wenn Sie zu der Software umfangreiche Handb√ľcher erhalten. M. E. k√∂nnen diese allerdings durch ein gut aufgebautes Hilfesystem ersetzt werden. Wichtig ist jedoch f√ľr die Anwender, die spezifische Benutzung der Software zu dokumentieren. Dies geschieht meist in der Form eines Organisationshandbuches, in dem beispielsweise die Verwendung aller Schl√ľsselbegriffe, Merkmale und anderer Kennzeichen festgelegt ist.

C. Kontrolle


Jede Phase wird durch ein Ergebnis abgeschlossen.

Problemdefinition und Zielsetzung
Dokumentation der Projektziele
Vorstudie
Projektstudie, Lösungsansätze, Kosten - und Terminplan
Feinstudie
Dokumentation des Ist - Zustandes und Anforderungsprofil
Grobprojektierung
, Lastenheft, Pflichtenheft, Ausschreibung und Verträge
Feinprojektierung
Detailanalyse, Datenmodell, Funktionsbeschreibung, Modulverzeichnis, kommentierter Programmcode, Testplan und Ergebnisse, Schulungsunterlagen, Organisationshandbuch und Problemdatenbank

Die Qualit√§t dieser Ergebnisse sollten immer wieder in sogenannten "Reviews" √ľberpr√ľft werden. Gut ist diesem Zusammenhang, wenn diese z.T. auch von au√üenstehenden Personen durchgef√ľhrt werden, damit das Ph√§nomen der "Projektblindheit" vermieden werden kann.

12505 Worte in "deutsch"  als "hilfreich"  bewertet