imported>Sokrates 399: Typografie.

2026-03-31T11:49:15Z

Typografie.

Neue Seite

'''Organisationsmuster''' dienen der Lösung von [[Problem]]stellungen durch das Hinzufügen einer [[Struktur]] zu einem System aus Menschen, wie etwa [[Firma|Firmen]], [[Politische Partei|politischen Parteien]], dem [[Militär]] und anderen [[Organisation]]en.<ref name="orgpatterns" />

== Geschichte ==
Während Organisationsmuster bereits sehr lange existieren, geht der Begriff des [[Muster]]s auf den Architekten [[Christopher Alexander]] zurück.<ref name="Alexander1977" /><ref name="Alexander1979" /> Die Ideen Alexanders wurden Anfang der 1990er Jahre in der [[Softwareentwicklung]] übernommen und später auf Organisationen ausgeweitet.<ref name="orgpatterns" />

== Organisationsformen ==
{{Hauptartikel|Aufbauorganisation|Primärorganisation|Sekundärorganisation}}

== Organisationsdesignmuster ==

=== Projektmanagementmuster ===
==== Gemeinschaft des Vertrauens ====
Die persönlichen Beziehungen zwischen Mitarbeiten haben einen wesentlichen Einfluss auf die Effektivität eines Teams. Deshalb ist es wichtig eine ''Gemeinschaft des Vertrauens''<ref name="orgpatterns" /> (englisch: ''community of trust'') aufzubauen. Ohne Vertrauen zwischen den Mitarbeitern ist die Kommunikation eingeschränkt und Arbeitsabläufe müssen unabhängig bewältigt werden, was zu einem mehrfachen Aufwand führt.

Um die Gemeinschaft zu stärken, ist es wichtig, selbst Vertrauen in die anderen zu zeigen. Zugriffsbeschränkungen auf Informationen oder bürokratische Hürden bei Arbeitsabläufen können das Vertrauen beeinträchtigen, weshalb es wichtig ist Mitarbeitern über ihre eigenen Arbeitsabläufe die Kontrolle zu übergeben. Zudem benötigen die Mitarbeiter das Gefühl bei Entscheidungen einen Einfluss zu haben, da sie dadurch den Entscheidungen eines Entscheidungsträgers eher Vertrauen schenken. Auch fühlen sich die Mitarbeiter dadurch eher dazu verpflichtet Verantwortung für die übertragenen Aufgaben zu übernehmen. Dies ist deshalb wichtig, da einer anderen Person eine [[Verantwortung]] nicht gegeben werden kann (sie kann lediglich für ihre Taten [[Rechenschaftspflicht]]ig sein), sondern die entsprechende Person die Verantwortung selbst übernehmen muss.

==== Ermächtigung ====
Bei der ''Ermächtigung''<ref name="orgpatterns" /> (englisch: ''empowerment'') wird bewusst auf die Kontrolle über untergebene Mitarbeiter verzichtet. Im Gegensatz zur [[#Gemeinschaft des Vertrauens|Gemeinschaft des Vertrauens]] die auf einem (impliziten) bilateralen Abkommen beruht, geht die Ermächtigung unidirektional von einer übergeordneten Stelle aus. Das Ziel der Ermächtigung ist einerseits die Gemeinschaft des Vertrauens auszubauen und andererseits die übergeordneten Stellen durch einen Abbau von [[Bürokratie]] zu entlasten.

==== Einschätzung des Zeitplans ====
Eine ''Einschätzung des Zeitplans''<ref name="orgpatterns" /> (englisch: ''size the schedule'') wird durchgeführt, wenn das zu erstellende Produkt verstanden ist und die Projektgröße abgeschätzt werden kann.

Sowohl zu eng gefasste als auch zu groß angelegte Zeitpläne sind negativ zu bewerten. Zu eng gefasste Zeitpläne führen zu einer Überbeanspruchung der Mitarbeiter und zu einem Nichteinhalten von vereinbarten Terminen oder der Auslieferung eines minderwertigen Produktes. Dadurch werden auch nachfolgende Organisationseinheiten bzw. der Kunde beeinträchtigt. Zu groß angelegte Zeitpläne erhöhen die Kosten für den Kunden durch das Verschwenden von Zeit auf Nebensächlichkeiten. Beides führt zu verpassten Marktchancen.

Einer Beschleunigung von Arbeitsabläufen durch eine Erhöhung der Mitarbeiterzahl steht oft das [[Antimuster#Brooks’sches Gesetz|Brooks’sche Gesetz]] und das [[Amdahlsches Gesetz|Amdahlsche Gesetz]] gegenüber.

Die Mitarbeiter, die am Projekt arbeiten, sollten an der Einschätzung der Projektzeit – vor allem für den eigenen Arbeitsaufwand – mitarbeiten. Gute Einschätzungen können hierbei mit finanziellen Anreizen oder zusätzlicher Freizeit belohnt werden. Zudem sollten zwei Zeiteinschätzungen erstellt werden. Ein interner Zeitplan der in Absprache mit den Mitarbeitern erstellt wird, sowie ein externer, welcher mit dem Kunden vereinbart wird. Der externe Zeitplan sollte hierbei für ein mittelgroßes Projekt ein bis zwei Wochen bzw. zwei bis drei Monate über dem internen Zeitplan liegen, um eventuelle Überschreitungen abfangen zu können.

==== Comparable Work ====
'''Comparable Work'''<ref name="orgpatterns" /> ist ein Muster, welches von [[Ward Cunningham]] wie folgt definiert wurde:

{{Zitat
|Text=Every project must commit to delivery on a few hard times and fast dates. This is actually fortunate because it is about the only way to get out of work that is going poorly.
|Sprache=en
|Autor=Ward Cunningham
|Quelle=
|Übersetzung=Jedes Projekt muss sich auf die Auslieferung zu mehreren festen und schnell aufeinanderfolgenden Terminen festlegen. Dies ist vorteilhaft, denn es ist der einzige Weg, um Arbeit, die schlecht vorangeht, loszuwerden.
|ref=<ref name="Comram1996" />}}

''Siehe auch:'' [[Scrum]].

==== Get on with it ====
Bei ''get on with it''<ref name="orgpatterns" /> oder auch ''partial evaluation'' wird das Projekt bereits gestartet, obwohl noch nicht alle [[Anforderung (Informatik)|Anforderungen]] klar sind. Auch sind Abhängigkeiten im Detail oft nicht vorhersehbar und ergeben sich oft erst gegen Ende eines Projektverlaufs. Sobald die Richtung der Projektentwicklung abschätzbar ist, sollte daher mit den Dingen begonnen werden, für die eine hohe [[Zuversicht]] besteht. In dieser Phase kann bereits nach einem [[informell]]en Arbeitsplan gearbeitet werden und [[Prototyp (Technik)|Prototypen]] können ausgearbeitet werden. Die Prototypen geben zugleich eine Einsicht wie die Struktur des fertigen Produkts aussehen kann und ermöglicht das Benennen von [[#Named stable bases|stable bases]]. Oft werden früh gestartete Projekte in Form von [[Skunk works]] ausgeführt. Diese werden am besten parallel zu anderen Geschäftsprozessen ausgeführt und nutzen dabei nicht ausgelastete Ressourcen.

Dieses Muster führt zu einer Beschleunigung der Fertigstellung des Produktes. Da jedoch Arbeit aufgrund von sich ändernden Anforderungen teilweise verworfen werden muss, sollte dieses Muster nicht eingesetzt werden, wenn es sich bei der für die Aufgabe benötigten Ressourcen um einen Engpass handelt, von dem auch andere Prozesse abhängig sind. Auch bedarf es einer guten Kommunikation mit nachfolgenden Einheiten mittels responsibilities engage und hallway chatter.

''Siehe auch:'' [[#Build prototypes|Build prototypes]].

==== Named stable bases ====
''Named stable bases''<ref name="orgpatterns" /> sind definierte Schnittstellen zwischen Projektteilen. Diese werden benannt, wenn der Projektplan erstellt wurde und die Entwicklung des Produktes gestartet ist. Durch die definierten Schnittstellen erlangen die einzelnen Teams ein gemeinsames Verständnis für das zu entwickelnde Produkt und können auf ein definiertes Grundverhalten aufbauen. Die Menge der festgelegten und benannten Schnittstellen sollte dabei regelmäßig (z. B. wöchentlich) erweitert werden.

Die Entwicklung von [[Prototyp (Technik)|Prototypen]] stellt einen Weg dar, eine Grundmenge an Schnittstellen zu definieren.

''Siehe auch:'' [[#Build prototypes|Build prototypes]], [[#Programming Episodes|Programming Episodes]].

==== Inkrementelle Integration ====
Bei der ''inkrementellen Integration''<ref name="orgpatterns" /><ref name="BerczukAppleton2002" /> (''englisch: incremental integration'') werden die Teile eines zu entwickelnden Produktes regelmäßig zusammengefügt. Hierdurch werden größere Integrationsprobleme im späten Entwicklungsstadium des Produktes vermieden. Der Entwicklungsstand wird aufgezeichnet und zu einer neuen [[#Named stable bases|''stable base'']], auf der die weitere Entwicklung des Produktes aufgebaut wird.

==== Private world ====
Als ''private world''<ref name="orgpatterns" /><ref name="BerczukAppleton2002" /> (''private Welt'') wird eine Arbeitsumgebung bezeichnet, über die ein einzelner Mitarbeiter alleine verfügt und alle nötigen Werkzeuge bereitstellt, die für die Tätigkeiten des entsprechenden Mitarbeiters nötig sind.

Private worlds sind häufig in der Softwareentwicklung anzutreffen, bei dem ein Programmierer neben der [[Integrierte Entwicklungsumgebung]] und dem [[Compiler]] auch über einen lokalen [[Schnappschuss (Informationstechnik)|Snapshot]] der zu entwickelnden Software (d. h. einer [[#Named stable bases|named stable base]]) und den benötigten [[Programmbibliothek]]en verfügt, um die Software jederzeit erstellen und testen zu können.

==== Build prototypes ====
''Build Prototypes''<ref name="orgpatterns" /><ref name="Graham1991" /> (''baue Prototypen'') ist ein Grundsatz, der den Bau eines [[Prototyp (Technik)|Prototyps]] des zu erstellenden Produkts empfiehlt. Am Prototyp wird das Konzept des Produktes ersichtlich und es können mögliche Probleme des Produktes bereits frühzeitig erkannt und in der weiteren Produktentwicklung in Form von zu testenden Anforderungen berücksichtigt werden.

Durch den Prototyp kommen Änderungsanforderungen an das Produkt bereits frühzeitig, wodurch teure Fehlentwicklungen vermieden werden. Es ist hierbei ratsam den Kunden in die Entwicklung mit einzubeziehen und [[Feedback (Kommunikation)|Feedback]] zum Prototyp einzuholen.

==== Take no small slips ====
''Take no small slips''<ref name="orgpatterns" /> (etwa: ''mache keine kleinen Ausrutscher'') ist anzuwenden, wenn ein Projekt hinter dem Zeitplan liegt. Wenn der geplante Fertigstellungstermin immer wieder um einige wenige Tage verschoben wird, sinkt das Vertrauen in den Projektplan. Daher sollte der Fertigstellungstermin gleich um einen größeren Bereich, ggf. mit eingeplanter Sicherheit, verschoben werden.<ref name="Brooks1995" />

Der Projektstatus sollte etwa einmal wöchentlich überprüft und dabei der voraussichtliche Fertigstellungstermin aufgrund statistischer Daten erneut eingeschätzt werden.

==== Arbeitsteilung ====
''Arbeitsteilung''<ref name="orgpatterns" /><ref name="Cunningham1996" /> (englisch: ''work split'') ist eine Methode um sich auf die wichtigen Tätigkeiten zu konzentrieren, indem das Team aufgeteilt wird und weniger wichtige Tätigkeiten in Untergruppen verlagert wird. Die wichtigen Tätigkeiten sollten hierbei nicht mehr als die Hälfte des Teams beschäftigen, während unwichtige Tätigkeiten entfallen können.

Eine Arbeitsteilung sollte angewandt werden, wenn wichtige Ziele hinter dem Zeitplan liegen, weil das Team mit der Erreichung weniger wichtiger Ziele beschäftigt ist.

==== Completion headroom ====
Wenn für jede Arbeitsgruppe in einem Projekt der voraussichtliche Fertigstellungstermin berechnet wird, so wird die Differenz zwischen dem voraussichtlichen Fertigstellungstermin und dem geplanten Fertigstellungstermin als '''completion headroom'''<ref name="orgpatterns" /><ref name="Cunningham1996" /> (wörtlich: ''Fertigstellungs-Kopffreiheit'') bezeichnet.

Diese Differenz sollte mindestens einmal pro Woche neu berechnet werden, um mit geeigneten Maßnahmen durch das Management gegensteuern zu können, falls die Differenz zu stark ansteigen sollte. Hierbei eignet sich unter anderem eine Neupriorisierung und anschließende Aufteilung der Tätigkeiten sowie ggf. das Verschieben des geplanten Fertigstellungstermins.

==== Implizite Anforderungen ====
''Implizite Anforderungen''<ref name="orgpatterns" /> (''implied requirements'') sind Anforderungen, die der Kunde hat, ohne dass diese explizit aufgelistet werden. Implizite Anforderungen entstehen, indem die einzelnen Funktionen des zu entwickelnden Produktes aufgeteilt und benannt werden.

Speziell in der Softwareentwicklung können implizite Anforderungen Sicherheit, Performance, Logging, Backup-Strategien, Fehlerbehandlungen, Wartbarkeit, Anpassbarkeit an veränderte Geschäftsprozesse usw. beinhalten.

==== Warteschlange ====
Eine ''Warteschlange''<ref name="orgpatterns" /> (englisch: ''work queue'') ist eine priorisierte Liste [[#Implizite Anforderungen|implizierter Anforderungen]], also noch zu tätigenden Arbeiten. Die Reihenfolge der Tätigkeiten ändert sich, wenn sich die Anforderungen ändern.

Eine Warteschlange entspricht dem [[Backlog]] in [[Scrum]].<ref name="Cunningham1996" /><ref name="Beedle1999" /><ref name="Rising2000" />

Eine Warteschlange ist deutlich einfacher zu handhaben und übersichtlicher als ein traditioneller [[Netzplantechnik|Netzplan]] aus [[Gantt-Diagramm]]en, der schwerer zu erstellen ist, die beteiligten Personen mit Details überfordert und zudem großteils verworfen werden muss, falls sich die Anforderungen ändern.

==== Recommitment Meeting ====
Ein ''Recommitment Meeting''<ref name="orgpatterns" /><ref name="Cunningham1996" /> ist ein Treffen des Projektmanagements und führender Entwickler eines Projekts, wenn [[#Implizite Anforderungen|implizite Anforderungen]] nicht innerhalb des vorgesehenen Zeitplans eingehalten werden können. Hierbei gilt es zu klären, wie eine benötigte Funktionalität mit dem kleinstmöglichen Aufwand zu realisieren ist. Anschließend wird der Zeitplan mit Hilfe eines [[#Warteschlange|Work-Queue]]-Berichts aktualisiert.

==== Informal Labor Plan ====
Ein '''Informal Labor Plan'''<ref name="orgpatterns" /> ist ein öffentlicher Richtzeitplan. Individuen oder Kleingruppen erstellen eigene kurzzeitige Zeitpläne, um die Arbeit so einzuteilen, dass der vom Management aufgestellte Zeitplan bestmöglich eingehalten werden kann. Der Projektmanager überwacht den Zeitplan lediglich mit einer groben Auflösung, während sich die Mitarbeiter selbstständig um die Details kümmern und sich untereinander zur Einhaltung ihres Zeitplans verpflichten.

==== Development-Episode ====
Bei einer ''Development-Episode''<ref name="orgpatterns" /> kümmern sich alle Mitarbeiter eines Teams um dasselbe Problem. Hierdurch werden die unterschiedlichen Stärken der einzelnen Personen kombiniert, um eine bestmögliche Lösung zu erzielen. Als Nebeneffekt wird Wissen von Spezialisten auf die anderen Mitarbeiter übertragen, wobei auch das Ansehen der Spezialisten innerhalb der Gruppe steigt.

==== Developer Controls Process ====
''Developer Controls Process''<ref name="orgpatterns" /> ist eine Informationsstruktur innerhalb eines Unternehmens, bei dem die Entwickler eines Produkts bidirektional mit allen beteiligten Stakeholdern kommunizieren können. Der Informationsfluss umfasst hierbei etwa Ideen, Anforderungserhebung, Testen, Auslieferung und Vermarktung der jeweiligen Produkte.

Hierbei gilt es jedoch darauf zu achten, Entwickler nicht mit Aufgaben zu überlasten. Dies kann durch Filterung des Informationsflusses, Aufgabenverteilung innerhalb des Entwickler-Teams, sowie Delegierung erfolgen.

==== Work Flows Inward ====
''Work flows inward''<ref name="orgpatterns" /> ist eine Informationsstruktur, bei der Arbeit von außerhalb des Unternehmens direkt zur passenden Rolle fließt. Um dies zu ermöglichen, bedarf es klar definierter Rollen und gefestigter Prozessabläufe.

Kennzeichnend ist hierbei, dass das Management nur gering am Informationsfluss beteiligt ist und keine zusätzliche Arbeit generiert. Zudem ist darauf zu achten, dass der Informationsfluss von einem Kunden zum jeweiligen Mitarbeiter einen informellen und keinen weisenden Character besitzt.

==== Programming Episodes ====
Eine ''programming episode''<ref name="orgpatterns" /> ist es, wenn von einer Software jene Programmabschnitte in Code festgeschrieben werden, zu denen es eine klare Entscheidung zum gewünschten Verhalten gibt. Programmabschnitte zu denen keine klare Entscheidung möglich ist, werden nach einem Review der existierenden Codebasis zu einem späteren Zeitpunkt getroffen und in einer nachgelagerten programming episode implementiert.

==== Someone Always Makes Progress ====
''Someone always makes progress''<ref name="orgpatterns" /> ist ein Managementprinzip, bei dem sich ein Teil des Teams um die Kernaufgabe der Erreichung eines bestimmten Ziels kümmert, während sich ein anderer Teil des Teams um Aufgaben kümmert, welche von der Kernaufgabe ablenken.

==== Weitere Projektmanagementmuster ====
Weitere Projektmanagementmuster sind team per task, sacrifice one person, mercenary analyst, interrupts unjam blocking, don’t interrupt an interrupt, day care und [[#Surrogate customer|surrogate customer]].<ref name="orgpatterns" />

=== Muster für schrittweises Wachstum ===

==== Size the organisation ====
Bei ''size the organisation''<ref name="orgpatterns" /> geht es darum, die benötigte Größe eines Teams für ein Projekt, bzw. die benötigte Größe des Unternehmens als Summe aller Teams, einschätzen zu können. Bei großen Projekten (bei Software > 25 [[Vorsätze für Maßeinheiten|k]][[Lines of Code|SLOC]]) ist es selten, dass das Projekt innerhalb der geplanten Zeit und Kosten fertiggestellt wird. Die Gründe hierbei sind vielfältig:

Wenn das Projektteam zu groß ist, werden meist die Kosten so hoch, dass sich das Investment nicht lohnt. Bei einem zu großen Projektteam geht der gemeinsame Überblick über das Produkt verloren. Zu große Teams sind bei kleinen Änderungen weniger anpassungsfähig und brachen länger um zu reagieren. Bei einem zu kleinen Team kann die Zeit nicht eingehalten werden. Ist das Projektteam zu klein, fehlt die kritische Masse und damit das Moment um das Projekt zu verwirklichen. Wird das Projektteam während des späten Projektverlaufs vergrößert, tritt das [[Brookssches Gesetz|Brookssche Gesetz]] ein.

Bei Softwareprojekten mit einem gut ausgewählten und unterstütztem Projektteam von 10 Personen lassen sich Projekte der folgenden Größenordnung bewältigen:<ref name="orgpatterns" /> 60 kSLOC in 8 Monaten, 200 kSLOC in 15 Monaten und 1500 kSLOC in 31 Monaten. Hierbei kann jede Rolle im Team mit 3 bis 7 anderen Rollen kommunizieren, wodurch auch eine Kommunikation innerhalb verschiedener Abteilungen in großen Unternehmen gewährleistet ist.

Die beste Teamgröße variiert mit dem Projekt, sollte jedoch nicht weniger als 3 Personen und nicht mehr als 12 Personen ausmachen. Größere Teams sollten aufgeteilt werden, wobei aber auch die Aufteilung durch eine Veränderung der Arbeitsabläufe zu einer Verringerung der Produktivität führen kann.

==== Surrogate customer ====
Ein ''surrogate customer''<ref name="orgpatterns" /> (''Ersatzkunde'') wird eingesetzt, wenn der Kunde für Feedback zum Produkt benötigt wird, der Kunde jedoch nicht zur Verfügung steht.

Die Problematik, dass der Kunde nicht zur Verfügung steht, kann aus verschiedenen Gründen entstehen. Etwa wenn das Produkt die Kunden erst erzeugen soll, der Kunde zu beschäftigt ist, der Kontakt mit dem Kunden zu einem gegebenen Zeitpunkt unangebracht ist oder eine fehlerhafte Unternehmenspolitik die Entwickler des Produktes vom Kunden trennt. Um den Kunden zu ersetzen, sollte eine Person gewählt werden, die nicht an der Entwicklung des Produktes beteiligt (d. h. nicht voreingenommen) ist. Jedoch gilt zu beachten, dass ein Ersatzkunde den eigentlichen Kunden nicht völlig ersetzen kann und nur eine zeitlich begrenzte Lösung darstellt.

== Standards ==
* [[BS 15000]]
* [[ITIL]]
* [[ISO/IEC 20000]]
* [[Microsoft Operations Framework]] (MOF)
* [[COBIT]]
* [[eTOM]]

== Personen ==
* [[Alistair Cockburn]]

== Literatur ==
* {{Literatur
|Autor=James O. Coplien, Heil B. Harrison
|Titel=Organizational Patterns of Agile Software Development
|Verlag=[[Mediengruppe Pearson|Pearson]], [[Prentice Hall]]
|Ort=Upper Saddle River
|Datum=2004
|ISBN=0-13-146740-9
|Seiten=432}}
* {{Literatur
|Autor=Linda Rising
|Titel=The Patterns Almanac 2000
|Verlag=[[Addison-Wesley]]
|Ort=Amsterdam
|Datum=2000
|ISBN=0-201-61567-3
|Seiten=448}}
* {{Literatur
|Autor=Steve Berczuk, Brad Appleton
|Titel=Software Configuration Management Patterns: Effective Teamwork and Practical Integration
|Verlag=Addison-Wesley
|Datum=2002
|ISBN=0-201-74117-2
|Seiten=208}}

== Weblinks ==
* {{Internetquelle
|autor=[[Ward Cunningham]]
|url=http://c2.com/cgi/wiki?WelcomeVisitors
|titel=Portland Pattern Repository’s Wiki
|hrsg=Cunningham & Cunningham, Inc.
|sprache=en
|abruf=2013-03-10}}
* {{Internetquelle
|autor=[[Brian Foote]]
|url=http://www.laputan.org/
|titel=Pattern Labyrinth
|sprache=en
|abruf=2013-03-10}}

== Einzelnachweise ==
<references>
<ref name="orgpatterns">
{{Literatur
|Autor=James O. Coplien, Heil B. Harrison
|Titel=Organizational Patterns of Agile Software Development
|Verlag=[[Mediengruppe Pearson|Pearson]], Prentice Hall
|Ort=Upper Saddle River
|Datum=2004
|ISBN=0-13-146740-9
|Seiten=432}}
</ref>

<ref name="Alexander1977">
{{Literatur
|Autor=Christopher Alexander
|Titel=A Pattern Language: Towns, Buildings, Construction
|Verlag=Oxford University Press
|Ort=New York
|Datum=1977
|ISBN=0-19-501919-9
|Seiten=1171}}
</ref>
<ref name="Alexander1979">
{{Literatur
|Autor=Christopher Alexander
|Titel=The Timeless Way of Building
|Verlag=Oxford University Press
|Datum=1979
|ISBN=0-19-502402-8
|Seiten=568}}
</ref>

<ref name="Beedle1999">
{{Internetquelle
|autor=Mike Beedle, Martine Devos, Yonat Sharon, Ken Schwaber, Jeff Sutherlan
|url=http://www.ootips.org/yonat/Scrum.pdf
|titel=Scrum: A Pattern Language for Hyperproductive Software Development
|format=PDF; 118 kB
|sprache=en
|abruf=2013-03-28}}
</ref>


<ref name="BerczukAppleton2002">
{{Literatur
|Autor=Stephen Berczuk, Brad Appleton
|Titel=Software Configuration Management Patterns: Effective Teamwork, Practical Integration
|Verlag=Addison-Wesley
|Ort=Amsterdam
|Datum=2002
|ISBN=0-201-74117-2}}
</ref>
<ref name="Brooks1995">
{{Literatur
|Autor=[[Frederick Brooks]]
|Titel=The Mythical Man-Month: Essays on Software Engineering
|Verlag=Addison-Wesley
|Datum=1995
|ISBN=0-201-83595-9
|Seiten=272}}
</ref>

<ref name="Comram1996">
{{Literatur
|Autor=[[John Vlissides]], [[Norman Kerth]], [[James Coplien]]
|Titel=Pattern Languages of Program Design
|Reihe=Pattern Languages of Program Design
|BandReihe=2
|Auflage=1.
|Verlag=Addison-Wesley
|Datum=1996
|ISBN=0-201-89527-7
|Kapitel=Demo Prep: A Pattern Language for the Preparation of Software Demonstrations
|Seiten=624
|Sprache=en
|Online=[http://c2.com/cgi/wiki?PatternLanguagesOfProgramDesign c2.com]
|Abruf=2013-03-07}}
</ref>
<ref name="Cunningham1996">
{{Literatur
|Autor=[[Ward Cunningham]], [[John Vlissides]], [[Norman Kerth]], [[James Coplien]]
|Titel=Pattern Languages of Program Design
|Reihe=Pattern Languages of Program Design
|BandReihe=2
|Verlag=Addison-Wesley
|Ort=Amsterdam
|Datum=1996
|ISBN=0-201-89527-7
|Kapitel=Episodes: A Pattern Language of Competive Development}}
</ref>
<ref name="Graham1991">
{{Literatur
|Autor=Ian Graham
|Titel=Specification in Expert Systems and Conventional IT Projects
|Sammelwerk=Computing and Control Engineering Journal 2
|Band=2
|Datum=1991
|Seiten=82–89}}
</ref>

<ref name="Rising2000">
{{Literatur
|Autor=Linda Rising
|Titel=The Patterns Almanac 2000
|Verlag=Addison-Wesley
|Ort=Amsterdam
|Datum=2000
|ISBN=0-201-61567-3
|Seiten=448}}
</ref>
</references>

[[Kategorie:Organisationstheorie]]
[[Kategorie:Softwaretechnik]]
[[Kategorie:IT-Management]]
[[Kategorie:Management]]

Organisationsmuster - Versionsgeschichte

imported>Sokrates 399: Typografie.