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.
* 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.
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.
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.
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
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.
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.
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:
n Anschaffungskosten der Hardware und Software
n Kosten der Eigenentwicklung
n Installationskosten (Kabel, Modemanschlüsse.)
n Schulungskosten
n Umstellungskosten (Erstdatenerfassung.)
* laufende Kosten
- Personalkosten
- Raumkosten
- Wartung und Reparatur
- Telefonkosten
- Materialkosten
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 |
|
|
|
|
|
|
|
|
|
|
|
einfacher |
|
3 |
|
|
|
Ablauf |
|
|
|
|
|
|
|
|
|
|
|
Stabilität + |
|
1 |
|
|
|
Sicherheit |
|
|
|
|
|
|
|
|
|
|
|
Zugang für die |
|
3 |
|
|
|
Öffentlichkeit |
|
|
|
|
|
|
|
|
|
|
|
Summen: |
|
|
|
|
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.
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.
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
Die Methoden der Istzustandserfassung können in 2 Bereiche unterteilt werden.
Beschreibung des
Istzustandes einer gegebenen Situation
Erhebungstechniken Darstellungstechniken
Erhebungstechniken
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 |
|
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 |
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 |
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 = 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 |
|
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 |
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.
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.
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.
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:
n Fachliche Beratung der Anwender
n Planung der PC-Infrastruktur
n Planung der notwendigen dezentralen Anwendungssoftware
n 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
n Softwareentwicklung
n Softwarepflege
n 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:
Das Leitungssystem definiert, wie die Weisungen und Informationen im Unternehmen fließen. Daraus lässt sich auch die Rangordnung einer Abteilung oder Stelle ableiten.
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.
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.
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.
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.
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
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: ______
TATSACHLICHER 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.
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.
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.
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
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.
Lehrer3 Schüler 3 Schüler 4 Schüler 5 Lehrer2 Schüler 2 Schüler 1 Lehrer1
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:
NACHFRAGER
KFZ
N:M
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.
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.
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
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:
n Firmenbezeichnung, Rechtsform, Firmensitz
n Entwicklung der Firma- Anzahl Mitarbeiter pro Geschäftsstelle
n Name der Kontaktperson
n Erfahrungen auf diesem Gebiet und Referenzen
n 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.
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.
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
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 |
|
|
|
|
|
|
|
|
über 100 |
|
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).
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 Anderungswünsche bzw. Ergänzungen der Anwender in der Phase der Einführung. Derartige Anderungswü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 Anderungen zu analysieren:
|
Gesetzliche Anderungen |
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 |
|
Anderung 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.
Qualitätsüberlegungen, Kontrolle und Dokumentation sind projektbegleitende Aufgaben und erstrecken sich über alle Phasen.
Abschließend möchte ich darauf hinweisen, dass die Software-Herstellung den Charakter einer Ingenieurdisziplin hat und viele Ahnlichkeiten 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.
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
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
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.
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.
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 Anderungen 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.
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.
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 Anderungsaufwand für die Übertragung wesentlich kleiner ist als der Aufwand für eine neue Implementierung.
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).
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
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.
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.
Haupt | Fügen Sie Referat | Kontakt | Impressum | Nutzungsbedingungen
