fit 2002: Produktionsverhältnisse: Software Factories
  [ eXtreme Programming | Programmieren als Kunst | Chief Programmer Team | Software Factories | Community Programming ]
 

überblick

  Software Factories
Das Wort Fabrik soll auf länger andauernde Anstrengungen von mehreren Personen hindeuten, die gemeinsam auf ein Ziel hinarbeiten, dessen Rahmen über Einzelprojekte weit hinausgeht. Man kann jedoch die Softwareproduktion nicht mit Massenproduktionen in herkömmlichen Fabriken vergleichen. [1-1] Heute wird meist nicht mehr der Begriff Fabrik für die Verbesserung der organisatorischen und methodischen Aspekte der Softwareentwicklung verwendet, sondern Begriffe wie Prozessorientierung oder Total Quality Management. [1-2]

Wodurch sind Software Factories entstanden?

Mitte der 70er Jahre herrschte eine Softwarekrise [1-5], da immer mehr Anbieter auf den Markt kamen, die Programmierer ihre Arbeit aber als künstlerische Tätigkeit sahen, und kaum Dokumentation von Programmen und deren Variablen vorhanden war. Bereits Ende der 60er gab es erste Denkmodelle, der große Boom bei der Gründung von Software Factories setzte jedoch erst ab 1976 ein. [1-1]

Die Software Organisationen mussten professioneller werden. Die Kunden und Hersteller sahen sich folgende Anforderungen gegenüber: mehr Transparenz in der Entwicklung, schneller Feedback, höhere Produktivität und bessere Qualität der Produkte.

Erste Ansätze die in Richtung von Software Factories gingen, tauchten bereits in den späten 60ern auf. R. W. Bemer führte bei General Electric erstmal 1968 ein System ein, das standardisiere Tools für die Programmierung verwendet, und eine Datenbank mit Daten aus früheren Entwicklungen und Management- und Finanzdaten anlegt. Beinahe gleichzeitig stelle M. D. McIlroy bei AT&T ein anderes Konzept für ein Software Factory vor. 1969 tauchte der Gedanke auf, für die Erstellung von Programmen bereits vorhandenen Code wieder zu verwenden. Die erste wirkliche Software Factory der Welt würde 1969 von Hitachi in Japan gegründet, wenig später folgte die USA mit dem bereits etablierten Software Hersteller, System Development Corporation. In den Jahren 1975-1977 setzt ein Boom in Richtung Software Fabriken ein, große japanische Unternehmen wie NEC, Toshiba und Fujitsu änderten ihre Produktionsart. [1-1]

Die Hauptströmungen der Software Factories

Bei der Entwicklung der Software Factories lassen sich vier verschiedene Ansätze, Entwicklungsströmungen unterscheiden.

  • Japanischer Ansatz: Industrialized Software Organisation
  • Europäischer Ansatz: Generic Software Factory
  • Nordamerikanischer Ansatz: Experience-based Component Factory
  • Nordamerikanischer Ansatz: Mature Software Organisation
Für jede dieser Entwicklungen sollen im Folgenden die Voraussetzungen und Rahmenbedingungen für die Entstehung besprochen werden. Welche Ziele würden bei der Gründung verfolgt und wie sollen diese Ziele erreicht werden? Außerdem soll bei jedem Ansatz kurz die organisatorische Umsetzung besprochen werden. [1-1]

Japan: Industrialized Software Organisation

Die Entwicklung soll anhand des Toshiba Software Factory Konzepts beschrieben werden.Toshiba entwickelt Software für Kontrollsysteme von Kernkraftwerken, Turbinen, etc.. Die Motivation für die Unternehmensumgestaltung in Richtung Software Factory lag darin, dass der Wunsch nach höherer Qualität durch Reduktion der Fehler in der Software bestand. Die Produktivität sollte darunter natürlich nicht leiden. Dieses Ziel soll dadurch erreicht werden, dass eine Umgebung geschaffen wird, in der Design, Programmierung, Test, Installation und Wartung in einheitlicher Art durchgeführt werden. Die Strategie für die Umsetzung gliedert sich in drei Bereiche. Das Erste ist die Schaffung geeigneter Gebäudes, in denen die Entwicklungsprozesse unterstütz werden können, zweitens wird eine »Software Work Bench« installiert, die den Entwicklungsprozess in allen Bereichen unterstützt. Drittens wurde eine Kontroll- und Beobachtungsinstanz geschaffen, die den Entwicklungsverlauf beobachtet. Später kamen noch weitere Initiativen dazu, die folgenden Bereichen einheitlich gestalteten: Arbeitsplatz, Software tools, user interfaces, standardisiert Richtlinien für Projektdesign und Projektmanagement, standardisierte technische Ausführung und Beschreibung, Fortbildungsprogramme, Qualitätssicherung, Bibliotheken mit bereits vorhandenem Code und technischen Datenbanken, Karrieresysteme, ... . Die Software Work Bench unterstützt alle Mitarbeiter auf den verschiedenen Entwicklungsebenen eines Projekts. Die Entwicklungsprojekte sind durch ein Wasserfall-Modell organisiert, wobei die einzelnen Arbeitsschritte in Arbeitseinheiten zerlegt werden. Jede Arbeitseinheit sollte in einer festgelegten Zeiteinheit erfüllt werden. Täglich oder wöchentlich wird kontrolliert, ob das Plansoll erfüllt ist und bei Schwierigkeiten oder Verzögerungen kann sofort reagiert werden. Die Wiederverwendung von Code trägt dazu bei, die Produktivität zu steigern und die Qualität zu steigern. Als erster Schritt muss der Code verfügbar gemacht werden und eine gute Dokumentation vorliegen. Jedem Programm müssen aussagenkräftige Keywords zugeordnet werden, die Funktionalität des Codes gut beschreiben und nach denen gesucht werden kann. Weiters werden »Quality Circles« eingerichtet. Gruppen von Freiwilligen diskutieren Möglichkeiten, die zu einer Verbesserung der Produktionsverhältnisse führen. Die besten Vorschläge eines Standortes werden prämiert und die Gewinner nehmen an der jährlichen Firmenkonferenz teil, bei der es wieder Preise und Auszeichnungen für die besten Ideen gibt. [1-1]

Bis heute ist Hitachi, die erste japanische Software Factory, die weltweit größte.

Europa: Generic Software Factory

Dieser Ansatz ist auch unter dem Namen Eureka Programm oder Eureka Software Factory bekannt. An der Entwicklung dieses Programms waren europäische Konzerne, Computerhersteller, Software Hersteller, Forschungseinrichtungen und Universitäten beteiligt. 10 Jahre lang (1987-1996) wurde in verschieden Subprojekten entwickelt und die Kosten auf Industrie und nationale europäische Regierungsstellen aufgeteilt. Ziel des Projekts ist es für die Errichtung von Software Factories die nötigen Voraussetzungen zu schaffen. Dazu gehören technische und organisatorische Unterstützung, die Festlegung von Standards und die Schaffung der benötigten Infrastruktur. Außerdem soll eine Organisation geschaffen werden, die Unterstützung für die einzelnen Unternehmen gewährleistet, die CASE-Architektur. Das Eureka Programm soll also einen Rahmen für die Gründung von Software Fabriken liefern. Es werde auch Standards und Richtlinien für die Entwicklung von Softwarekomponenten in den ISDEs (Integrated Software Development Environments) festgelegt. Diese einheitlichen ISDE Standards ermöglichen die Kommunikation und den Austausch von verschiedenen Komponenten über einen gemeinsamen Datenbus. Komponenten, die für ein bestimmtes Projekt benötigt werden, können aus den am Datenbus vorhandenen ausgewählt und kombiniert werden. Forschungsergebnisse werden allen Teilnehmern zur Verfügung gestellt. Die Anzahl der Firmen, die sich den Eureka Software Factory Standards anschlossen ist stetig gestiegen. Die Firmen erhalten Unterstützung (support environment) und beachten dafür einheitliche Standards, die auch die Entwicklung von gemeinsamen Werkzeugen ermöglichen [1-1]

USA: Experience-based Component Factory

Die Experience-based Component Factory wird vom Software Engieneering Laboratory entwickelt, das seit 1976 besteht und von der NASA, der Universität von Maryland und der Computer Science Corporation gemeinsam betrieben wird. Ziele dieses Projekts sind das Verstehen des Sofrwareherstellungsprozesses in der Entwicklungsumgebung, die Bestimmen des Einflusses von verfügbaren Technologien und das Einfließen lassen von gefundenen Methoden in den Entwicklungsprozess. Neue Entwicklungen und Technologien sollen in einer Produktionsumgebung getestet werden und gleichzeitig soll deren Einfluss auf Kosten, Qualität und Funktionalität untersucht werden. Um aus dem Forschungszentrum, dem Software Engieneering Laboratory ein gewinnbringendes Unternehmen zu machen müssen Qualität und Produktivität erhöht werden. Drei Schritte haben sich dabei als effizient herausgestellt: Effektivität der Entwicklung erhöhen, Reduktion der Menge an Rework, wieder verwenden von Life-Circle Produkten. [1-1]

Diese Ziele sollen durch folgende Schlüsselstrategien erreicht werden:

  • Entwicklungsparadigmen: Projekte werden genau geplant, die Ziele festgelegt und es wird überprüft ob Ergebnisse aus früheren Experimenten benötigt werden. Die Resultate werden auf übereinstimmung mit den Zielvorgaben analysiert und sämtliche Ergebnisse werden so zusammengeführt, gepackt und dokumentiert, dass sie für zukünftige Projekte leicht wieder verwendet werden können.
  • Kontinuitätsanspruch: jedes Projekt hat seine eigene Charakteristik, einen bestimmten Zweck und eigene Ziele. Durch die Schaffung eines gemeinsamen Abstraktionslevels soll eine gemeinsame Basis für Projektbeschreibungen geschaffen werden. [1-1]

Organisatorisch ist die Experience-based Component Factory in zwei Teile geteilt:
Die Projekt Organisation, die für Planung und Entwicklung zuständig ist und die »Experience Factory« die sich hauptsächlich mit Fortbildung und Technologie-Transfer beschäftigt.

Darstellung der Organisation der Experience-based Component Factory [1-1]

USA: The Mature Software Organization

Das letzte Software Factory-Konzept ist definiert durch das Capability Maturity Model, kurz CMM. Ursprünglich wurde CMM vom Amerikanischen Verteidigungsministerium verwendet, um Software Lieferanten zu werten. Nach vielen schlechten Erfahrungen mit Softwareerzeugern sollte dieser Fragenkatalog helfen, solche Fehler zu vermeiden und funktionierende Software zu erhalten. Das Hauptziel der Software Factory sollte es sein, einen vorhersehbaren, selbstverbessernden und wirtschaftlichen Software Entwicklungsprozess zu finden, der eine hohe Qualität von Software bringt. Vorhersehbar meint Kosten- und Terminüberschaubar. Selbstverbessernd meint eine stetige Weiterentwicklung des Produktes und, dass Techniken entwickelt werden, die diesen Prozess der Weiterentwicklung begünstigen. Wirtschaftlich meint, dass der Entwicklungsprozess überschaubar und wieder verwendbar ist. Wichtig war auch, dass all dies durch verbesserte Prozessüberwachung erreicht werden sollte und nicht durch Methoden oder Tools. Der eigentliche Gedanke der hinter CMM steht, ist die schrittweise Verbesserung der Software Entwicklung. So definiert CMM genau, welche Prozesse den Schlüssel zu einer guten Softwareentwicklung bilden und wie diese Prozesse verbessert werden können. Die Software Firma die das Ideal der CMM umsetzt, muss folgende Charakteristiken erfüllen: strenge Disziplin in der Planung und Zielsetzung und Einfluss von Wissen aus bereits abgeschlossenen Projekten. Weiters soll die Software Entwicklung und die Software an sich vorhersehbar sein, denn sie sollen sich immer in messbaren Grenzen bewegen. Das Hauptziel von CMM ist eine stetige Verbesserung, die stetig verbessert wird. [1-1]

Vergleich der 4 Konzepte

  • Wenn wir die nur die Namen der 4 Konzepte vergleichen, fällt auf, dass im vierten Konzept, dem Mature Software Organisation, der Term Software Factory nicht vorkommt.
  • Während die zwei amerikanischen und das europäische Konzepte »nur« Konzepte sind, meint das Japanische Modell ein ganz bestimmte Umsetzung nämlich die Toshiba Software Factory.

Vergleich erster Teil [1-1]

  • Alle vier Konzepte wollen Prozesse, Tools und Architekturen zusammenführen. Während die Ziele der Industrialized Software Factory und die Generic Software Factory in der Erstellung und Verbesserung von Tools und Entwicklungsumgebungen liegen, verfolgen Experience-based Component Factory und Mature Software Organization hauptsächlich die Entwicklung und Verbesserung von Prozesse.
  • Verfügen Industrialized Software Factory und Mature Software Organization über Messsysteme die den Fortschritt aufzeigen, haben Generic Software Factory und Experience-based Component Factory kein Messsystem.

Vergleich zweiter Teil [1-1]

  • Sowohl Generic Software Factory als auch Experience-based Component Factory und Mature Software Organization verwenden Projektmodelle, während bei Industrialized Software Factory ohnehin alles standardisiert ist.

Stärken und Schwächen [1-1]

  • Bei etwas genauerer Betrachtung sieht man, dass sich die vier Konzepte in zwei Gruppen aufsplittern lassen. Ein Gruppe (Generic Software Factory und Industrialized Software Factory) versucht die Herstellung einer Infrastruktur, die die Entwicklung von Software Prozessen erleichtert, während die andere Gruppe (Experience-based Component Factory und Mature Software Organization) versucht optimale Software Prozesse, die sich auf die Erfahrung stützt, zu entwickeln. [1-1]

Hauptunterschiede der vier Strömungen [1-1]

Entwicklung der Software Factory in der Literatur

Bereits Ende der 60er Jahre wurden in der Literatur die ersten Vorschläge unterbreitet, wie die Softwareentwicklung nach dem Vorbild der industriellen Produktion erfolgen sollte: In der »Software Factory« werden mit Hilfe standardisierter, computergestützter Werkzeuge auf der Basis eines formalisierten, mittels technischer und ökonomischer Kennzahlen kontrollierten Prozesses Softwareprodukte - gegebenenfalls in »Massenproduktion« - erstellt. Betrachtet man die quantitative Entwicklung wissenschaftlicher Veröffentlichungen zum Thema Software Factory, so stellt man fest, daß der Zenit Ende der 80er bzw. Anfang der 90er Jahre überschritten wurde. Unterstellt man einen positiven Zusammenhang zwischen der Anzahl wissenschaftlicher Veröffentlichungen zu einem Thema und dessen Aktualität in Forschung und Praxis, so kommt man zu dem Ergebnis, daß das Schlagwort Software Factory in den letzten Jahren an Popularität verloren hat [1-8]

Entwicklung in der Literatur [1-8]

Auch wenn der Begriff Software-Factory seine Popularität verloren hat, ist die Idee weiterhin aktuell. Die meisten wissenschaftlichen Arbeiten zur Weiterentwicklung von Sorfware Engineering und die Bemühungen zur Verbesserung der Softwareproduktion haben ähnliche oder gleichen Ziele: die Verwendung standardisierter, computergestützter Werkzeuge und formalisierte Prozesse, die technisch und ökonomisch kontrollierbar sind. Es gibt auch weiterhin Beträge, die auf eine Automatisierung in der Software Herstellung zielen und sich an der Fabrikanalogie orientieren, im Vordergrund stehen aber Bestrebungen, das Management und die Qualität der Prozesse zu erhöhen.

Quellenangaben

  Wir haben haupsächlich Materialien verwendet, die im Internet in Form von Artikeln, Buchauszügen und Berichten zuverfügung standen.

Verweise auf Arbeiten anderer Gruppen

Data Mining and Data Warehouse
Data Mining und Data Warehouse spielen bei der Sammlung und Wiederverwendung von Code für Software Factories eine wichtige Rolle.
Knowledgemanagement
Knowledgemanagement stellt auch ein Konzept dar, wie Wissen und Informationen weitergegeben und für andere Verfügbar gemacht werden kann.
Wasserfallmodell
Das Wasserfallmodell wird oft bei Software Factories verwendet.
Prototyping
Beide Konzepte haben das Ziel die Kommunikation zwischen Auftraggebern, Nutzern und Entwicklern zu verbessern.
Wissensakquisition
Ist auch eine Methode zur Wissenverteilung und Wissensbewahrung.
Büroautomatisierung
Grundgedanken der Büroautomatisierung finden sich in der Entwicklung der japanischen Worck Bench wieder.
Programmiersprachen
Die Suche nach Verbesserungen und einheitlichen Standards forderte gemeinsame, effiziente und fehlerlose Programmiersprache.
 

(c) FIT 2002 Gruppe 2