Arbeitsteilung und Koordination (bei sequentieller Entwicklung)

Ausarbeitung , 1998 , 23 Seiten , Note: 2,0

Informatik - Programmierung

Die Sequentielle Entwicklung ist neben der Inkrementellen Entwicklung eine Vorgehensweise zur strukturierten Erstellung von Hardware-Software-Systemen. Das Wasserfallmodell, das in diesem Zusammenhang vorgestellt wird, ist eine Methode, die eine Anzahldefinierter Phasen nacheinander abarbeitet, wobei die darauffolgende Phase erst begonnen werden darf, wenn die vorgelagerte Phase zu einem definierten Zustand des Objektes geführt hat. Anschließend werden die Begriffe Arbeitsteilung und Koordinationsowie deren verschiedene Formen erläutert. Die Arbeitsteilung gliedert sich in drei Schritte: Analyse, Segmentierung und Zuteilung. Die Analyse und Segmentierung richtet sich in der Art nach der Verrichtung und Merkmalen der Objekte. Koordination ergibt sich notwendigerweise aus der Arbeitsteilung und wird in den Formen der persönlichen Weisung, Selbstabstimmung und Programmen beschrieben. Die zunächst erklärten Begriffe und Formen werden dann unter folgenden Annahmen bewertet: Die Anforderungen an das System stehen anfangs fest. Sie ändern sich weder während der Entwicklung noch kommen neue Anforderungen hinzu. Die Softwareentwicklung selbst soll sequentiell gestaltet sein. Ziele der Arbeitsteilung und Koordination sind Kosten, Einhalten des Zeitplanes, Motivation der Mitarbeiter sowie die Qualität des Produktes.

Inhaltsverzeichnis

1 Sequentielle Softwareentwicklung
1.1 Einleitung
1.2 Ziele der Softwareentwicklung
1.3 Das Vorgehensmodell
1.4 Rahmenbedingungen

2 Arbeitsteilung
2.1 Analyse
2.2 Segmentierung
2.3 Zuteilung

3 Koordination
3.1 Koordination durch persönliche Weisung
3.2 Koordination durch Selbstabstimmung .
3.3 Koordination durch Programme
3.4 Sonstige Koordinationsinstrumente

4 Zusammenfassung

Zusammenfassung

Die Sequentielle Entwicklung ist neben der Inkrementellen Entwicklung eine Vorgehensweise zur strukturierten Erstellung von Hardware-Software-Systemen. Das Wasserfallmodell, das in diesem Zusammenhang vorgestellt wird, ist eine Methode, die eine Anzahl de nierter Phasen nacheinander abarbeitet, wobei die darau olgende Phase erst begonnen werden darf, wenn die vorgelagerte Phase zu einem de nierten Zustand des Objektes geführt hat.

Anschlieÿend werden die Begri e Arbeitsteilung und Koordination sowie deren verschiedene Formen erläutert. Die Arbeitsteilung gliedert sich in drei Schritte: Analyse, Segmentierung und Zuteilung. Die Ana- lyse und Segmentierung richtet sich in der Art nach der Verrichtung und Merkmalen der Objekte. Koordination ergibt sich notwendiger- weise aus der Arbeitsteilung und wird in den Formen der persönlichen Weisung, Selbstabstimmung und Programmen beschrieben. Die zu- nächst erklärten Begri e und Formen werden dann unter folgenden Annahmen bewertet: Die Anforderungen an das System stehen an- fangs fest. Sie ändern sich weder während der Entwicklung noch kom- men neue Anforderungen hinzu. Die Softwareentwicklung selbst soll sequentiell gestaltet sein. Ziele der Arbeitsteilung und Koordination sind Kosten, Einhalten des Zeitplanes, Motivation der Mitarbeiter so- wie die Qualität des Produktes.

1 Sequentielle Softwareentwicklung

1.1 Einleitung

Das Ziel dieses Textes soll sein, den Prozeÿ der Softwareentwicklung in Hin- blick auf Arbeitsteilungsmaÿnahmen und Koordinationsmöglichkeiten zu un- tersuchen. In der Theorie und Praxis der Softwareeentwicklung nden sich verschiedene Modelle der Vorgehensweise. Wir werden uns auf die sequen- tielle Vorgehensweise, bei der (im Idealfall) die Projektphasen nacheinander abgearbeitet werden, beschränken. Sie soll im Abschnitt 1.3 kurz vorgestellt werden. Die Art der Arbeitsteilung und Koordination ist abhängig von der Unternehmensumwelt und wie man dieser begegnen will. Um den Rahmen dieser Arbeit nicht zu sprengen, sollen auch hier einschränkende Annahmen getro en werden, die in Abschnitt 1.4 erläutert werden.

Arbeitsteilung besteht aus drei Teilprozessen, nämlich aus der Analyse, Segmentierung und Zuteilung. In Kapitel 2 werden die drei aufeinander- folgenden Schritte genauer beschrieben. Kapitel 3 beschreibt schlieÿlich die durch die Arbeitsteilung notwendig werdende Koordination. Um die in den erwähnten Kapiteln vorgestellten Arten der Arbeitsteilung und Koordination bewerten zu können, werden im Abschnitt 1.2 Kriterien herausgearbeitet.

1.2 Ziele der Softwareentwicklung

Die Ziele von Unternehmungen können vielfältig sein. Deshalb muÿ auch hier eine Auswahl getro en werden. Es soll unterstellt werden, daÿ ein Ziel der Unternehmung ist, möglichst gute Qualität bei einem Minimum an Ko- sten zu erzeugen. Weiterhin soll der vorgegebene Zeitplan1 eingehalten wer- den. Während Kostenminimierung und Einhaltung des Zeitplanes¹ intuitiv verständliche Variablen sind, ist es fraglich, was der Einzelne unter guter Software (und damit unter Softwarequalität) versteht. Wir können uns auf folgende Qualitätsmerkmale² beschränken:

Funktionalität : Die Funktionen, die in der Spezi kationsphase de niert wurden, sollen vorhanden sein und ordnungsgemäÿ arbeiten.

Zuverlässigkeit : Das System soll dauerhaft die Anforderungen erfüllen.

Benutzbarkeit : Der Anwender soll sich mit dem System schnell vertraut machen und einfach bedienen können.

E zienz : Die Antwortzeiten sollen angemessen sein. Das System soll möglichst geringe Ansprüche an die Ressourcen stellen.

Änderbarkeit : Änderungen am Produkt sollen schnell und einfach zu voll-ziehen sein.

Übertragbarkeit : Die Software soll sich leicht auf andere Umgebungen übertragen und anpassen lassen.

Die genannten Merkmale müssen im Einzelfall genauer detailliert und in Hinblick auf den Erfüllungsgrad spezi ziert werden. Ein weiteres Ziel soll die Motivation der Mitarbeiter sein.

1.3 Das Vorgehensmodell

Im Bereich der sequentiellen Softwareentwicklung nden sich verschiedene Vorgehensmodelle.³ Das Wasserfallmodell soll als ein Vertreter der sequen- tiellen Entwicklung vorgestellt werden. Im Gegensatz zur inkrementellen Vorgehensweise steht dabei die Implementation am Ende einer Kette von Phasen, die auch Rücksprünge zu vorgelagerten Entwicklungsstufen erlaubt.

Die einzelnen Phasen werden nun kurz skizziert:⁴

1. Die Initialisation eines Projektes beginnt mit der Projektbegründung, in der das Projekt verbal formuliert und gegenüber Alternativvorschlägen gerechtfertigt wird.
2. Im zweiten Schritt ndet eine Spezi kation der Anforderungen statt. Das Ziel ist ein Soll-Konzept inklusive Anforderungsdokument und Zeitplan.
3. Ausgehend davon wird ein Systementwurf (zunächst grob und dann detailliert) erstellt. Dabei wird die Systemarchitektur (bestehend aus den Hard- und Softwarekomponenten) genau beschrieben.
4. Die Realisierungsphase enthält die Programmierung der Systemkom- ponenten sowie deren Tests.
5. In der Implementation ndet eine Einbettung des Systems in seine Arbeitsumgebung statt. Diese Phase reicht von der Anpassung der schon existierenden Daten bis zum Training der Mitarbeiter.
6. Während des Betriebs muÿ das System, z.B. zur Einführung von Up- dates (Änderungen), gewartet werden.

Parallel zu diesen sequentiellen Arbeitsschritten nden prozeÿbegleitende Maÿnahmen statt. Zum einen handelt es sich um eine ständige Kontrolle, ob die Phasen korrekt durchgeführt werden (Veri kation ) und ob das, was getan wird, überhaupt zur Zielerreichung angemessen ist (Validation ). Stetige Qualitätsprüfung von Anfang des Projektes an ist Voraussetzung für kostengünstige Softwareentwicklung.⁵ Zum anderen wird versucht, zu bestimmten Zeitpunkten des Geschehens (zu sogenannten Milestones) vorher de nierte Zustände des Systems zu xieren.

1.4 Rahmenbedingungen

Im folgenden sollen vereinfachende Annahmen über die Umwelt gemacht werden. Diese stellen eine idealisierte Situation dar, die aber eine gute Ausgangssituation für die von uns betrachtete sequentielle Entwicklung bieten, da externe Störungen weitgehend eliminiert werden.

- Alle Anforderungen⁶ an das Softwaresystem sind vor Beginn der Entwicklung in allen Einzelheiten de niert.
- Es kommen keine neuen Anforderungen während der Entwicklungs- phase hinzu und die bestehenden ändern sich nicht. Das heiÿt, daÿ we- der durch den Auftraggeber noch durch Dritte (Staat, Wettbewerber, u.s.w.) Ereignisse entstehen, die Ein uÿ auf die Systementwicklung haben.

Daraus folgt, daÿ schon zu Projektbeginn wichtige Informationen zur Verfügung stehen und nicht im Laufe der Entwicklung bescha t werden müssen. Es ist also davon auszugehen, daÿ im Grunde keine Rücksprache mit dem Auftraggeber gehalten werden muÿ, um ein Produkt herzustellen, das den Vorstellungen des Auftraggebers entspricht.

2 Arbeitsteilung

Die Arbeitsteilung verfolgt das Ziel, gegebene Aufgabenstellungen so zu struk- turieren, daÿ sie e zient von Ressourcen (Menschen, Maschinen, u.s.w.) ab- gearbeitet werden können. Dabei können E ekte entstehen, die möglicher- weise negativ auf die Motivation der Mitarbeiter wirken. Lösungen dieses Problems können unter anderem in der Aufgabengestaltung liegen.⁷

Der Prozeÿ der Arbeitsteilung selbst läÿt sich in drei grundlegende Schritte gliedern:⁸ Analyse, Segmentierung und Zuteilung der Aufgaben.

2.1 Analyse

Bevor die zu erledigenden Aufgaben in kleine Einheiten zerlegt werden können, bedürfen sie einer vollständigen Spezi kation, die als Analyse bezeichnet wird. Neben den Aufgaben werden auch die Ressourcen vollständig beschrieben, um deren Leistungspotentiale zu kennzeichnen. Den Aufgaben werden Lastpotentiale zugeordnet.

Man unterscheidet zwischen einer merkmalsorientierten und einer bezie- hungsorientierten Analyse.⁹ Aufgabenmerkmale sind z.B. gleichartige Bewe- gungsabläufe oder räumliche Nähe, während Ressourcenmerkmale die Quali- kation des Bearbeiters, technische Merkmale von Maschinen, u.s.w. betref- fen. Die beziehungsorientierte Analyse beschreibt die Aufgaben und Ressour- cen nach genereller Zusammengehörigkeit , womit eine enge Ver echtung mit anderen Objekten gemeint ist. Zum Beispiel existieren auf der Aufgabenseite starke Abhängigkeiten bei der Bearbeitung mit den anderen Aufgaben oder es können durch die gemeinsame Bearbeitung groÿe Zeitersparnisse auftreten. Das Ergebnis der Analyse besteht in einem Anforderungspro l der Aufgaben und Leistungspro len der Ressourcen, die in einem nachgelagerten Schritt miteinander verglichen werden.

Das Wasserfallmodell enthält in der Anforderungsspezi kation eine Ana- lyse der Gesamtaufgabe. Das Modell stellt implizit Anforderungen an die ausführenden Personen, da es die Rollen de niert, die in verschiedenen Pha- sen benötigt werden. Im Systementwurf und der Realisierungphase werden detaillierte Anforderungen erstellt: welche Methoden- und Programmier- kenntnisse notwendig sind, u.s.w. Hierbei wird also eine Analyse nach Merk- malen der Aufgabenträgern erstellt, die durch den Aufbau des Wasserfallm- odells vorgegeben ist. Innerhalb der Phasen ndet eine weitere Detaillierung statt, wobei sich die gängigen Methoden des Entwurfs an Merkmalen der Aufgabe orientieren und diese entweder top-down verfeinern oder buttom-up vergröbern.¹⁰

2.2 Segmentierung

In der Aufgaben- und Ressourcensegmentierung, die sich an die Analyse anschlieÿt, wird eine Aufteilung der Aufgaben erreicht, wobei komplexere Aufgaben zunächst in übersichtlicherere Teilaufgaben (Segmente) aufgeteilt werden. Der Kontext (Interdependenzen zu anderen Aufgaben) tritt hier- bei zunächst in den Hintergrund und wird später in der Aufgabenzuteilung wieder aufgegri en.

Mit der Orientierung am Ausgangsobjekt, der verrichtungsorientierten Zerlegung sowie der Orientierung am Zielobjekt lassen sich drei Arten der Analyse unterscheiden.¹¹ Bei der Orientierung am Ausgangsobjekt wird ver- sucht, die zu verrichtende Aufgabe nach Eigenschaften der Einsatzobjekte (z.B. Material, Personal) aufzugliedern. Analog bedeutet eine Orientierung am Zielobjekt, daÿ eine Aufgliederung nach Aspekten des angestrebten Ob- jektes erzielt werden soll. Ein Zielobjekt könnte z.B. ein zu entwickelndes (Software-)Produkt sein. Schlieÿlich wird bei der verrichtungsorientierten Zerlegung nach ähnlichen Abläufen (z.B. gleichartigen Arbeitsschritten) wäh- rend der Verrichtung zerteilt. Weiterhin existiert die Möglichkeit, eine Men- genteilung vorzunehmen, bei sich die Arbeitsträger eine Anzahl von gleichen Arbeitsobjekten aufteilen. Diese spielt in der Softwareentwicklung jedoch eine untergeordnete Rolle.

Es ist nicht möglich, den Prozeÿ der Softwareentwicklung nur einer Art der Segmentierung zuzuordnen. Das in Kapitel 1 vorgestellte Wasserfallm- odell nimmt eine erste Zerlegung nach Zielobjekten vor, denn es zerteilt die Gesamtaufgabe in Phasen, an deren Ende (vorerst) fertige Ergebnisse stehen. Diese können sich zwar im Laufe der Gesamtentwicklung noch einmal ändern, sind nach einer abschlieÿenden Prüfung aber zunächst verbindlich für die nachfolgenden Arbeitsschritte. Die Phasen selbst können wiederum in Tei- laufgaben zerlegt werden. Beispielsweise erscheint es in gröÿeren Projekten sinnvoll, die Spezi kation und den Systementwurf nach Objekten zu zertei- len. Angenommen, es handelt sich um ein Pizzataxi-Informationssystem, das sowohl die eingehenden Informationen (gewünschte Pizza, Zieladresse, Telefonnummer, . . . ) erfassen als auch eine möglichst gute Route für die Fahrer ermitteln soll. Hier bietet es sich an, die Teilbereiche Datenerfas- sung und Tourenplanung auf zwei unabhängige Teams aufzuteilen. Eine Segmentierung nach der Verrichtung ist vor allem dort sinnvoll, wo unab- hängig vom Objekt gleiche Arbeitsschritte vollzogen werden. Die den ganzen Entwicklungsprozeÿ begleitenden Maÿnahmen sind ein solches Beispiel. Hier sind auch Hilfswerkzeuge zu nden, die den spezialisierten Arbeitsprozeÿ un- terstützen, z.B. Tools zur Unterstützung des Kon gurationsmanagements. Auch eine Zusammenfassung von Teilaufgaben mit dem Verrichtungsprin- zip ist möglich. Zum Beispiel können Programmkomponenten in Modulen zusammengefaÿt werden, wenn sie groÿe Abhängigkeiten untereinander be- sitzen.

2.3 Zuteilung

Die Zuteilung ist die abschlieÿende Zuweisung von Aufgabensegmenten zu Ressourcen, wobei nun der Kontext der Aufgabenstellung und des Aufga- benträgers beachtet werden muÿ, um herrschenden Abhängigkeiten und Be- ziehungen zwischen der Aufgabe und dem Aufgabenträger gerecht zu werden.

Die Zuteilungsproblematik besteht aus zwei Dimensionen:¹² Erstens muÿ jedem Aufgabensegment ein anforderungsgerechter Aufgabenerfüller gegenübergestellt werden. Anforderungen, die ein Aufgabenpaket an den Bearbeiter stellt, müssen also mindestens erfüllt werden. Andererseits können auch Ressourceneigenschaften berücksichtigt werden.

Die andere Perspektive bezieht sich auf das raum-zeitliche Verhältnis zwi- schen den Aufgaben-Ressourcen-Komplexen. Jede Aufgabe nimmt eine (in der Analyse) festgelegte Zeit des potentiellen Aufgabenträgers in Anspruch und muÿ evtl. an einem bestimmten Ort bearbeitet werden. Neben diesen technischen Restriktionen sind noch weitere Nebenbedingungen rechtlicher (gesetzlich vorgeschriebene Pausenzeiten, Höchstdauerbeschränkungen) und sozialer Natur (Wünsche des Personals) zu berücksichtigen.

3 Koordination

In Anschluÿ an die Arbeitsteilung ergibt sich aus mehreren Gründen die Notwendigkeit der Koordination. Zum einen muÿ die Tätigkeit des einzel- nen Aufgabenträgers durch Maÿnahmen (Koordinationsinstrumente) in den Gesamtkontext eingebettet werden. Durch die Zerteilung einer Aufgabe in Teilaufgaben wird eine Reduktion der Komplexität erzielt. Damit verbunden ist allerdings auch, daÿ der einzelne Mitarbeiter den Überblick über den Ge- samtkontext, in dem er sich mit seiner Teilproblemlösung be ndet, verliert. In komplexen Problemsituationen herrschen Interdependenzen zwischen den Segmenten, die miteinander abgestimmt werden müssen. Insbesondere bei einer Segmentierung nach bestimmten Aufgabenerfüllungsfunktionen besteht ein hoher Bedarf an Koordination.¹³ Die Handlungen der einzelnen Ressour- cen müssen also auf das gemeinsame Unternehmensziel koordiniert werden.

Die Segmentierung der Aufgaben und Ressourcen als ein Prozeÿ der Ar- beitsteilung scha t eine hierarchische Struktur: Oberaufgaben werden in kleinere Unteraufgaben zerteilt und zunächst getrennt betrachtet, damit sie e ektiv bearbeitet werden können. Später müssen sie wieder zu der hierar- chisch höher gelegenen Oberaufgabe zusammengefügt werden.¹⁴ Anhand der Verläufe, die die Informationen nehmen, lassen sich zwei Arten der Koordi- nation di erenzieren:¹⁵

Die Feedbackkoordination ist reaktiv angelegt. Erst wenn Probleme auftreten, die nicht von dem Aufgabenträger gelöst werden können, wird die (hierarchisch) darüber liegende Ebene informiert, die ggf. wiederum Rat bei der nächsthöheren Instanz sucht. Der Ereignisstrom durchläuft die Organisationsstruktur also von unten nach oben: buttom-up. Der Weg bis zur Lösung eines Problems ist deswegen möglicherweise (je nach Organisationstiefe) lang und verhindert ein rasches Handeln.

Durch eine Vorauskoordination werden im Voraus Verfahrensmuster fest- gelegt, wie sich die einzelnen Organisationsmitglieder in bestimmten, zukünf- tig zu erwartenden Fällen verhalten sollen. Tritt eine Störung auf, die nicht in eine Problemklasse paÿt, kann nicht vorhergesehen werden, wie die Or- ganisation reagieren wird, da kein passendes Schema existiert. Dynamische Umwelten, in denen sich die Organisation in schnell wechselnden Umwelt- situationen wieder ndet, sind auf ein gewisses Maÿ an reaktivem Verhalten angewiesen. Bei diesem Koordinationstyp durchlaufen die Informationen die Hierarchie von oben nach unten: top-down. Eine starke Feedbackkoordinati- on scheint unter den gegeben Rahmenbedingungen unangebracht, da es keine externen Störgröÿen gibt, die sie notwendig machen könnten. Interne Störun- gen wurden aber nicht ausgeschlossen. Dazu zählen z.B. Krankheitsfälle, die einen durchgängigen Arbeitsprozeÿ verhindern, von Mitarbeitern falsch ver- standene Spezi kationen, u.s.w. Eine passende Koordination berücksichtigt dies oder versucht, solche Störungen erst gar nicht aufkommen zu lassen.

Die nachfolgend aufgeführten Instrumente dienen der Koordination. Die Gliederung orientiert sich an den steuernden Medien.¹⁶

3.1 Koordination durch persönliche Weisung

Persönliche Weisung ist das am einfachsten zu handhabende Instrument der Koordination. Entscheidungen werden auf der obersten Hierarchieebene ge- tro en und an die direkt darunter angegliederten Ebenen weitergegeben, die ihrerseits eine Detaillierung der Aufgabe vornehmen und diese ebenfalls wei- tergeben, bis die unterste Ebene erreicht wird. Wenn die Anweisungen eine komplexere Struktur aufweisen, wird von den Entscheidern eine hohe Quali- kation gefordert.

Die Flexibilität und Reaktionszeit kann durch den Einsatz der persönli- chen Weisung im Sinne einer Feedbackkoordination erheblich gesteigert wer- den. Eine zu starke Belastung dieses Instruments kann aber den gegenteiligen E ekt bewirken, wenn etwa Mitarbeiter wegen jeder Kleinigkeit ihre Hand- lungen beim Vorgesetzten absichern. Durch den Einsatz moderner, elektro- nischer Medien, etwa dem Internet, können persönliche Anweisungen auch über groÿe Distanzen statt nden. Die betro enen Personen müssen sich nicht mehr Auge in Auge gegenüber stehen, damit Anweisungen schnell verbreitet werden können.

Dadurch, daÿ das Instrument seine Grenzen bezüglich Belastung und An- forderungen an die Entscheidungsträger hat, ist es nur als ergänzende Maÿ- nahme denkbar, wohl aber nicht als zentraler Steuerungsmechanismus. Un- ter den genannten Rahmenbedingungen ist eine persönliche Weisung nahezu unnötig, da der komplette Handlungsablauf theoretisch im Voraus geplant werden und in Programmen¹⁷ beschrieben werden kann. Kleinere Korrek- turen (z.B. von falsch verstandenen Anweisungen) können hierdurch leicht erreicht werden.

3.2 Koordination durch Selbstabstimmung

Während in der Koordination durch persönliche Weisung Einzelpersonen Entscheidungen tre en, ist es auch möglich, einer Gruppe von Personen die Entscheidungskompetenz (Gruppenentscheidung) zu überlassen. Die Tren- nung der Instanzen in Planende und Ausführende kann somit aufgehoben werden, da die betro enen Personen selbst über die eigenen Handlungen ab- stimmen.

Wir sprechen von einer Instrumentalisierung der Selbstabstimmung, wenn die Gruppenentscheidung o ziellen Charakter hat, d.h. für die betre enden Mitarbeiter verbindlich ist und möglichst schriftlich dokumentiert wird. In- o zielle Absprachen unter Mitarbeitern sind damit nicht gemeint. Es lassen sich mehrere Regelungen denken, nach denen die Gruppensitzungen einberu- fen werden:¹⁸

Die Gruppenmitglieder entscheiden selbst, ob und wie sie sich untereinan- der abstimmen. Diese freie Regelung erhöht die Flexibilität des Instruments, fordert von den Mitgliedern aber auch eine gröÿere Disziplin, denn die Anläs- se sind nicht vorgegeben, sondern werden selbst bestimmt und möglicherweise nicht erkannt.

Zu bestimmten Themen werden Gruppensitzungen angesetzt, die dann verbindlich sind. Dadurch wird das Risiko durch subjektive Fehlentschei- dungen, ob eine Gruppenentscheidung zu tre en ist, minimiert. Die Frage, welche Themen wichtig genug sind, ist vorher zu beantworten und kann si- cherlich nicht vollständig beanwortet werden. Daher ist eine Sensibilisierung der Mitglieder notwendig, ob zu auftretenden Ereignissen, für die nicht ex- plizit eine Versammlung vorgesehen ist, trotzdem die Gruppe einbezogen werden sollte.

Regelmäÿig oder fallweise werden Gremien gebildet, die sich auch aus Personen verschiedener Funktionsbereiche zusammensetzen können und bereichsübergreifende Themen behandeln. Es besteht die Gefahr, daÿ die Stimmen einzelner Teilnehmer mehr Gewicht erhalten als die der anderen, was eine Gruppenentscheidung faktisch bedeutungslos machen würde und nicht mehr als Selbstabstimmung zu bezeichnen wäre.

Die angesprochenen Regelungen sind nicht überschneidungsfrei. Es ist sicherlich sinnvoll, regelmäÿige Themensitzungen mit der Option auf auÿerordentliche Tre en einzurichten.

Die Frage, ob eine Koordination durch Selbstabstimmung oder durch per- sönliche Weisung vorzuziehen ist, kann nicht pauschal beanwortet werden, sondern hängt von verschiedenen Faktoren ab: Als Nachteil sollte der hohe Zeitbedarf genannt werden, der eine Konsens ndung in der Gruppe in An- spruch nimmt. Einzelne Teilnehmer können sich aus egoistischen Gründen gegen die allgemeine Gruppenmeinung stellen und so eine e ektive Entschei- dung blockieren. Auf der anderen Seite ist es aber auch möglich, daÿ sich die Gruppe zu sehr aufeinander abgestimmt hat und eine geschlossene Mei- nung vertritt. Auÿerdem läuft die Gruppe Gefahr, riskante Entscheidungen zu schnell zu akzeptieren.¹⁹ Insgesamt muÿ die Gruppe die Ziele der Organi- sation verfolgen, die wiederum Anreize setzen kann, um die Gefahr von Op- portunismus zu verringern.²⁰ Damit die Gruppe bessere Entscheidungen als ein Einzelner tri t, müssen sich die Teilnehmer gegenseitig ergänzen. Wenn alle Mitglieder im Grunde das gleiche Wissen, die gleichen Quali kationen und die gleichen Sichtweisen haben, werden sie keine bessere Entscheidung tre en können als jeder für sich alleine.²¹

Allgemein kann die Deligation von Entscheidungen an Gruppen vor al- lem die Motivation der Mitarbeiter stärken. In einer stark hierarchischen Struktur werden die Entscheidungswege entlastet, die Mitarbeiter fühlen sich stärker involviert und mit der Aufgabe verbunden. Unter den genannten Voraussetzungen können eventuell bessere Ergebnisse entstehen als bei einer Individuums-Entscheidung. In einer dynamischen Umwelt ermöglicht ins- besondere die Selbstabstimmung ohne Regelungen eine höhere Flexibilität. Gruppensitzungen sind besonders vorteilhaft, wenn viele Interessenvertreter anzuhören sind. Die Rahmenbedingungen ermöglichen aber einen ieÿenden Prozeÿ, so daÿ Gruppenentscheidungen einzig die Motivation der Mitarbeiter fördern könnte. Da sie in der Regel längere Zeit in Anspruch nehmen und weitere genannte Gefahren bergen, scheint dies unter den gegebenen Vor- aussetzungen kein geeignetes Instrument zu sein. Hinzu kommt, daÿ eine Selbstabstimmung teuer ist, da viele Personen an die zeitintensive Entscheidung gebunden sind.

3.3 Koordination durch Programme

Anders als die bisher betrachteten Instrumente kann eine Koordination durch Programme nur zur Vorauskoordination eingesetzt werden. Unter Program- men werden dabei verbindliche Handlungsanweisungen verstanden, wie bei Eintreten von Ereignissen zu verfahren ist. Die Detaillierung der Programme kann variieren und wirkt stark auf die Flexibilität einer Arbeitsinstanz ein. Je genauer dem Arbeitsträger einzelne Schritte vorgeschrieben sind, desto weniger Spielraum hat er bei der Bewertung von Ereignissen und der Durch- führung des Programms. Neben Programmen kann die Koordination auch auf Plänen beruhen, die eine starke Ähnlichkeit zu Programmen aufweisen, aber eher das Was und nicht das Wie vorgeben. Sie können als Zielvor- gaben verstanden werden. Zunächst werden in Programmen Problemklassen de niert, die den wahrgenommen Realitätsausschnitt begrenzen und somit zu unterschiedlichen Sichtweisen führen. Nachdem der Bearbeiter die Pro- blemklasse identi ziert hat, kann er anhand des Problemklassenverfahrens eine Lösung erarbeiten. Dadurch, daÿ nur ein Teil der Umwelt betrachtet wird, wird auch die Komplexität reduziert. Das kann sowohl ein Nachteil als auch ein Vorteil sein, je nach Problemkontext. In einer stark dynamischen Umwelt wird man eher dazu neigen, dem Aufgabenträger groÿe Spielräume bei der Bewertung und Durchführung zu lassen und nur in statischen Um- weltsituationen kann die Koordination einzig auf Programmen beruhen, da nur dann eine vollständige Klassi zierung aller Ereignisse möglich ist.

Allgemein führt die Anwendung von Programmen zu einer Standardi- sierung der Verfahrensweisen, was sich positiv auf die zeitliche Planbarkeit auswirkt. In der Softwareentwicklung können standardisierte Methoden und Werkzeuge eingesetzt werden, die den Mitarbeiter in den einzelnen Phasen unterstützen. Programmiervorschriften erhöhen die Möglichkeit zur Wieder- verwendung und Änderbarkeit, was sich wiederum auf die Kosten auswirkt. Vorgaben von bestimmten Regeln können die Übertragbarkeit sichern, z.B. die Verwendung von Normen in der Programmierung wie POSIX. In ver- schiedenen Projekten lassen sich oft ähnliche Programme einsetzen, so daÿ deren Wiederverwendung Kosten reduziert.

3.4 Sonstige Koordinationsinstrumente

Die folgenden Instrumente fallen aus dem Rahmen der Gliederung, weil man ihnen kein steuerndes Medium zuzuordnen kann. Sie sollten aber trotzdem aufgrund ihrer Bedeutung genannt werden:

Mit Unternehmenskultur ist eine generelle Ausrichtung und Identität der Mitarbeiter eines Unternehmens gemeint. Ihnen liegen die gleichen oder ähn- liche Annahmen über die Umwelt, der Organisation an sich und der darin arbeitenden Menschen zugrunde, sie haben eine gemeinsame Wertegrundla- ge über Richtlinien und Standards. Die Unternehmenskultur kann sich in äuÿerlich sichtbaren zeigen, z.B. in einem gleichartigen Auftreten (Kleidung, Umgangsformen, u.s.w.) der Mitarbeiter oder in bestimmten ritualisierten Handlungen. Ein Ziel ist es, ein einheitliches Deutungsmuster von Informa- tionen zu erstellen, was den Koordinationsbedarf senkt und die Gefahr von Miÿklassi zierungen von Ereignissen reduziert. Wenn sie den Mitarbeitern glaubhaft vermittelt und gelebt wird, trägt sie zu einem positivem Betriebs- klima bei und führt zur Identi zierung der Mitarbeiter mit dem Unterneh- men.²²

Die Unternehmenskultur kann ein sehr mächtiges Instrument sein, weil sie unsichtbar die Werte des Unternehmens durchsetzt. Ein Unternehmen, das es irgendwie gescha t hat, Qualitätssicherung in den Köpfen der Mit- arbeitern zu etablieren, braucht eigentlich gar keine eigene Abteilung mehr dafür. Leider ist dieses Irgendwie kein leicht zu analysierender Prozeÿ.²³

Die Rolle, die ein Mitarbeiter in einem Unternehmen ausübt, ist Teil des Koordinationsmechanismus. Ein Qualitätssicherer weiÿ, daÿ sein generelles Aufgabengebiet in dem Au nden von Fehlern oder im Sichern von festgeleg- ten Standards liegt. Durch diese Spezialisierung von Personen auf bestimmte Aufgaben wird ein grundsätzlicher Teil der Koordination geleistet.

Eine weiteres Instrument zur Koordination sind interne Märkte. Abtei- lungen, denen man Gewinnverantwortlichkeit übergibt (sog. Pro t Center ), tauschen untereinander Leistung anhand von wirtschaftlichen Gesichtspunk- ten aus, wodurch ein internes Verrechnungs- und Koordinationssystem ent- steht. In Hinblick auf die Kosten mag es sinnvoll sein, den verschiedenen Bereichen der Softwareentwicklung Gewinn- und Kostenverantwortlichkeit zu übertragen. Dieses Thema erscheint aber sehr komplex und es sind weite- re Überlegungen notwendig, inwieweit dieses Konzept übertragbar ist, etwa inwieweit man die Leistungen der Qualitätssicherung verrechnet.

4 Zusammenfassung

Es wurde von den Voraussetzungen einer sehr statischen Umwelt ausgegan- gen, so daÿ eine Vorauskoordination durch Programme keine externen Ein- üsse gestört werden kann. Theoretisch ist es möglich, ein genaues Vorgehen- sprogramm zu erstellen, nachdem die Anforderungen in Phase 2 des Wasser- fallmodells geklärt wurden. Macht man weitere Einschränken, z.B. daÿ der Auftraggeber seine Vorstellungen eindeutig formulieren kann, kann ganz auf eine Gruppensitzung verzichtet werden. Quellen von Störungen können also nur im Unternehmen selbst liegen, zum Beispiel in einer ungenauen Spezi- kation. Rückfragen und Einsatz persönlicher Weisung können hier helfen. Eine angemessene Unternehmenskultur kann der Qualität des Produktes in allen Merkmalen nutzen. Als Ziel wurde auch die Motivation der Mitarbeiter de niert. Zu strikte programmatische Handlungsvorgaben wirken sich nega- tiv auf die Motivation aus. Hier müssen Spielräume erhalten bleiben, damit die Mitarbeiter das Produkt als ihr Werk betrachten können.

Neben den genannten Instrumenten kann versucht werden, den Koordi- nationsbedarf durch andere Maÿnahmen zu reduzieren.²⁴ Eine Entkopplung der einzelnen Entwicklungsphasen ist im streng sequentiellen Modell nicht möglich, wohl aber bei Anwendung des inkrementellen Modells. Dort wird ein Basissystem erstellt, das schrittweise erweitert wird. Eine weitere Mög- lichkeit besteht in einer breiteren Ausbildung der Mitarbeiter. Ein Software- entwickler, der sich auch mit den Fachaspekten anderer Bereiche auskennt, braucht weniger Anweisungen.

Der Bereich der Arbeitsteilung wurde nur recht knapp behandelt. Even- tuell ist es notwendig, eine di erenziertere Untersuchung der in der Software- entwicklung eingesetzten Methoden durchzuführen. Als Resultat dieser Ar- beit kann nur festgehalten werden, daÿ die Analyse der Aufgaben sich meist nach Merkmalen der Aufgaben und Aufgabenträger orientiert. Das erscheint auch sinnvoll, da es, anders als in der Industrie, wenig motorische Abläufe gibt, die zu einem gemeinsamen Verrichtungsmerkmal führen können.

Literatur

[Boehm/Software/] Barry W. Boehm: Software Engineering Economics. Englewood Cli s 1981

[DIN/Qualitätsmerkmale/] DIN (Hrsg.): DIN 66272: Informationstechnik - Bewerten von Softwareprodukten - Qualitätsmerkmale und Leit- faden zu ihrer Verwendung. Identisch mit ISO/IEC 9126: 1991. Oktober 1994. Berlin 1994

[Eisenführ/Betriebwirtschaftslehre/] Franz Eisenführ: Einführung in die Be- triebwirtschaftslehre. Stuttgart 1996

[Frese/Aufgabenanalyse/] Erich Frese: Aufgabenanalyse und -synthese. In: Erwin Grochla (Hrsg.): Handwörterbuch der Organisation. Stuttgart 1980, S.207-218

[Frese/Grundlagen Organisation/] Erich Frese: Grundlagen der Organisati- on. 6. Au age, Wiesbaden 1995

[Kieser, Kubicek/Organisation/] Alfred Kieser, Herbert Kubicek: Organisa- tion. 3. Au age, Berlin New York 1992

[Macharzina/Unternehmensführung/] Klaus Macharzina: Unternehmens- führung. 2. Au age, Wiesbaden 1995

[Reiÿ/Arbeitsteilung/] Michael Reiÿ: Arbeitsteilung. In: Erich Frese (Hrsg.): Handwörterbuch der Organisation. 3. Au age, Stuttgart 1992, S. 167-178

[Rühli/Koordination/] Edwin Rühli: Koordination. In: Erich Frese (Hrsg.): Handwörterbuch der Organisation. 3. Au age, Stuttgart 1992, S. 1164-1175

[Stahlknecht/Wirtschaftsinformatik/] Peter Stahlknecht: Einführung in die Wirtschaftsinformatik. 7. Au age, Berlin u.a. 1995

Thesenpapier

1. Gruppenentscheidungen sind nur in dynamischen Umwelten sinnvoll. In statischen Umweltbedingungen ist es immer besser, Entscheidungen von Einzelnen tre en zu lassen.

2. Persönliche Weisung ist ein ideales Instrument der Feedbackkoordina- tion.

3. In statischen Umwelten kann auf Feedbackkoordination verzichtet wer- den.

4. Arbeitsteilung führt automatisch zu einer Reduktion der Kosten.

5. Programme können nur in statischen Umweltsituationen als Koordina- tionsinstrument eingesetzt werden.

[...]

---

¹ s. Abschnitt 1.3

² Vgl. DIN/Qualitätsmerkmale/

³ Vgl. Stahlknecht/Wirtschaftsinformatik/ 242

⁴ Vgl. Boehm/Software/ 35 und Stahlknecht/Wirtschaftsinformatik/ 249

⁵ Vgl. Boehm/Software/ 39f

⁶ s. Spezi kationsphase in Abschnitt 1.3

⁷ Vgl. Frese/Grundlagen Organisation/ 133

⁸ Vgl. Reiÿ/Arbeitsteilung/ 168

⁹ Vgl. Reiÿ/Arbeitsteilung/ 170

¹⁰ Vgl. Stahlknecht/Wirtschaftsinformatik/ 282

¹¹ Vgl. Frese/Aufgabenanalyse/ 209

¹² Vgl. Frese/Aufgabenanalyse/ 214f

¹³ Vgl. Eisenführ/Betriebwirtschaftslehre/ 62

¹⁴ Vgl. Kiesen, Kubicek/Organisation/ 97f

¹⁵ Vgl. Kiesen, Kubicek/Organisation/ 100

¹⁶ Vgl. Kiesen, Kubicek/Organisation/ 104

¹⁷ s. Abschnitt 3.3

¹⁸ Vgl. Kiesen, Kubicek/Organisation/ 107

¹⁹ Vgl. Frese/Grundlagen Organisation/ 172

²⁰ Vgl. Frese/Grundlagen Organisation/ 129f und 133

²¹ Vgl. Frese/Gundlagen Organisation/ 175

²² Vgl. Macharzina/Unternehmensführung/ 213f

²³ Vgl. Frese/Grundlagen Organisation/ 152f

²⁴ Vgl. Kiesen/Kubicek/ 102f

• Hochschule: Universität zu Köln
• Veranstaltung: Fachbereich Wirtschaftsinformatik
• Note: 2,0
• Autor: Dirk Räbiger (Autor:in)
• Erscheinungsjahr: 1998
• Seiten: 23
• Katalognummer: V96301
• ISBN (eBook): 9783638089777
• ISBN (Buch): 9783640876952
• Sprache: Deutsch
• Schlagworte: Arbeitsteilung, Koordination, Entwicklung), Fachbereich, Wirtschaftsinformatik