Entwicklungsmethodiken zur kollaborativen Softwareerstellung – Stand der Technik

Die weltweit wachsende Nachfrage nach Unternehmenssoftware erfordert immer neue Methoden und Formen der Zusammenarbeit (Kollaboration) bei der Softwareerstellung. Zu diesem Zweck untersucht und vergleicht dieses Arbeitspapier existierende Vorgehensmodelle und deren Evolution. Zusätzlich werde erste Ansätze zur kollaborativen Softwareerstellung vorgestellt und ihre Eignung für ein kommerzielles Umfeld analysiert. Die Arbeit verwendet hierzu einen eigenen Vergleichsrahmen, der u.a. auch so genannte "Kollaborationspunkte“ in Betracht zieht, d.h. Aktivitäten im Prozess an denen das Einbinden mehrerer Entwickler und/oder Anwender vorteilhaft ist. Die Erkenntnisse aus der vergleichenden Analyse des Stands der Technik werden schließlich dazu verwendet, Defizite existierender Ansätze aufzuzeigen und Anforderungen für unterstützende Werkzeuge abzuleiten

Ansätze der Forschung zur Unterstützung der Entwicklung von Softwarekomponenten

Das vorliegende Arbeitspapier entstand aus einem Vortrag, welcher im Rahmen einer Veranstaltung der Wirtschaftsinitiative "Baden-Württemberg: Connected" (bwcon) aus der Reihe "Forum Unternehmenssoftware" gehalten wurde. Das übergeordnete Ziel dieser Veranstaltung war, die zukünftigen Perspektiven – Chancen und Herausforderungen – komponentenbasierter Software für Softwarefirmen und -anwender aufzuzeigen und zu diskutieren. Der Beitrag der Universität Mannheim bestand darin, die aktuellen Ansätze der Forschung zur Unterstützung der komponentenbasierten Softwareentwicklung im Überblick darzustellen, insbesondere eigene Ansätze und Projekte zu diesem Thema vorzustellen und einen Ausblick auf zukünftige Entwicklungen zu geben. Die wichtigsten Punkte des Vortrags sowie die Ergebnisse der anschließenden Diskussionsrunde mit Anwendern von Unternehmenssoftware, Softwareherstellern sowie weiteren Wissenschaftlern auf diesem Gebiet werden in diesem Papier zusammengefasst

Die beiden Seiten der Nachnutzbarkeit - Ein Paradigmenwechsel im IT-Projektgeschäft

IT-Anwendungen sind der Lebensnerv nahezu jedes Unternehmens. Marktanforderungen haben zur Folge, dass die eingesetzten IT-Systeme ausgetauscht und durch immer bessere Anwendungen ersetzt werden müssen. Während die Unternehmen früher Beratertage zur Implementierung neuer IT-Lösungen eingekauft haben, streben sie jetzt an, sich schlüsselfertige Lösungen implementieren zu lassen. Diese Veränderung im Nachfrageverhalten der Anwenderunternehmen verlockt viele Beratungsunternehmen, Kundenbindung über eigene, proprietäre Lösungen zu erreichen. Im vorliegenden Papier werden dieses Vorgehen diskutiert. Als Ergebnis wird der Begriff der Nachnutzbarkeit von Projektlösungen eingeführt und ein Vorschlag zur Realisierung offener, nachnutzbarer Projektlösungen entwickelt, die ohne künstliche Abhängigkeiten auskommen und das freie Spiel von Angebot und Nachfrage am IT-Beratungsmarkt ermöglichen. Zunächst wird der Begriff der Nachnutzbarkeit definiert.Anschließend werden wesentliche Randbedingungen für Nachnutzbarkeit betrachtet und Konsequenzen abgeleitet. Im Kapitel 4 wird ein Weg skizziert, wie eine Projektmanagement-Plattform für nachnutzbare Systemintegrationsprojekte entwickelt werden kann. Dieser wird gemeinsam von der TFH Wildau und der PROMOS consult beschritten. Die Verantwortung liegt dabei in den Händen der Autoren.IT-Applications are the lifeblood of each company. Caused by the requirements of the market the companies have to change their IT-systems regularly and substitute them by new applications. In former times companies bought »manpower« for the implementation of the new solutions but today they want their consultants to install turn-key applications. This change leads to the situation that many consultant companies try to ameliorate their customer relationship in offering own, proprietary solutions. In the following paper we will discuss this phenomenon. The term of »post-availability« will be introduced and a proposal for the realisation of open, post-available project solutions will be developed. These solutions are characterized by the fact that they don’t need any dependencies and that they lead to a »free play« of offer and request in the IT-consultant market. First we define the term »post-availability«, advantages and disadvantages will be discussed which leads to the contemplation of the main framework requirements (factors of success) of »post-availability« and their consequences. Chapter 4 provide a way how to develop a project-management-platform for »post-available« system integration projects. The realisation of the ideas will be carried out by the University of Applied Sciences Wildau and the PROMOS consult. The responsibility lies in the hands of both authors

Analyse der Barrieren und Treiber zwischenbetrieblicher Softwareerstellung und Konstruktion einer Kollaborationsplattform für kleine und mittlere Unternehmen

Die Erstellung von Unternehmenssoftware gliedert sich zunehmend in die Herstellung von Komponenten durch einzelne Zulieferer, die von Systemintegratoren zusammengeführt und implementiert werden. Dadurch gewinnt die zwischenbetriebliche Zusammenarbeit in der Softwarebranche zunehmend an Bedeutung. Um den Wertschöpfungsprozess innerhalb dieser entstehenden, so genannten Softwarelieferketten zu stärken, werden mit dem vom Wirtschaftsministerium Baden-Württemberg geförderten Projekt TASK die unternehmensübergreifende Entwicklung, Integration und Implementierung von Softwarekomponenten unterstützt. Dieser Artikel stellt zum einen die Struktur und den bisherigen Verlauf des Projekts vor, zum anderen werden wissenschaftliche Erkenntnisse aus der empirischen Analyse der Barrieren und Treiber zwischenbetrieblicher Softwareerstellung sowie der Gestaltung einer Kollaborationsplattform für die zwischenbetriebliche Softwareerstellung präsentiert. Den Abschluss bildet eine Diskussion aktueller und zukünftiger Probleme bei der Etablierung zwischenbetrieblicher Zusammenarbeit in der Softwareindustrie am Beispiel mittelständischer Unternehmen in Baden-Württemberg

Pattern-Oriented Transformations between Analysis and Design Models (POTAD)

One answer to many current challenges in the electronic domain of automotive development, is a continuous model-based engineering process that integrates models of system and software development. A system model describes by the use of the logical system architecture the func-tions of a vehicle and through the technical system architecture the realising electronics, such as control units, sensors/actuators and data busses. During software development, a software design model for selected functions of the logical system architecture must be constructed with consideration of the technical architecture and further requirements. Current model-based development approaches claim to automate the transition between different development phases by the concept of model transformations. This concept lends itself to generate a skele-ton of the software design model from the system architecture model, thereby automating a part of the software engineering activities. The analysis of this work shows that the collected domain specific requirements, which must be made on a model transformation mechanism for such a scenario, are not fulfilled by current approaches. The approach taken in this work, the Pattern-Oriented Transformations between Analysis and Designmodels (POTAD) uses the system architecture as an analysis model within software development and systemizes the connection with the design model on the basis of analysis and design patterns. By means of this systematisation, a POTAD transformation rule instantiates for an analysis pattern different design patterns under consideration of non-functional requirements and the technical system architecture. At the same time, links between an analysis and design pattern are created, which are used to trace design decision later. The feasibility of the solution is shown by a prototype, which follows the POTAD development process and executes the transformation rules formulated in the POTAD transformation lan-guage.POTAD was verified by several student works based on a case study, which covers typical characteristics of the examined domain. The results of these works showed the suitability and improved the methodology as well as the transformation language and pointed out the limits of the approach taken.Eine Antwort auf viele aktuelle Anforderungen im Elektrik/Elektronik-Bereich der Fahrzeugent-wicklung ist ein durchgängig modellbasierter Entwicklungsprozess, der Modelle der System- und Softwareentwicklung integriert. Ein Systemmodell beschreibt mit der logischen System-architektur die Funktionen eines Fahrzeugs und mit der technischen Systemarchitektur die realisierende Elektrik/Elektronik, wie z. B. Steuergeräte, Sensoren/Aktoren und Bussysteme. Im Rahmen der Softwareentwicklung muss für einzelne Funktionen aus der logischen System-architektur unter Berücksichtigung der technischen Systemarchitektur und weiterer An-forderungen ein Softwaredesignmodell erstellt werden. Aktuelle modellbasierte Entwicklungs-ansätze versprechen mit Hilfe des Konzepts der Modelltransformation den Übergang zwischen Modellen unterschiedlicher Entwicklungsphasen automatisieren zu können. Dieses Konzept bietet sich dazu an, aus einem Systemarchitekturmodell ein Grundgerüst eines Softwaredesign-modells zu erzeugen und damit einen Teil der Softwareentwicklungsaktivitäten zu auto-matisieren.Die Analyse dieser Arbeit zeigt, dass die erarbeiteten domänenspezifischen Anforderungen, die für solch ein Szenario an einen Modelltransformationsmechanismus gestellt werden müssen, durch aktuelle Ansätze nicht vollständig erfüllt werden. Der eigene Ansatz Pattern-Oriented Transformations between Analysis and Designmodels (POTAD) verwendet die logische Systemarchitektur im Rahmen der Softwareentwicklung als Analysemodell und systematisiert dessen Zusammenhang mit dem Designmodell auf der Basis von Analyse- und Designmustern. Für ein im Analysemodell gefundenes Analysemuster instanziiert eine POTAD-Transformationsregel mit Hilfe dieser Systematik in Abhängigkeit nichtfunktionaler An-forderungen und der technischen Systemarchitektur unterschiedliche Designmuster im Design-modell. Gleichzeitig werden Verknüpfungen zwischen den Analyse- und Designmustern angelegt, die zur späteren Verfolgung von Designentscheidungen genutzt werden. Anhand eines dem POTAD-Entwicklungsprozess folgenden Prototyps, der die in der POTAD-Transformationssprache formulierten Regeln ausführen kann und die Verfolgbarkeit werkzeug-seitig unterstützt, wird die Realisierbarkeit des Lösungsansatzes gezeigt. POTAD wurde durch studentische Arbeiten anhand einer Fallstudie überprüft, die typische Eigenschaften der betrachteten Domäne abdeckt. Die Ergebnisse dieser Arbeiten haben die Tauglichkeit von POTAD gezeigt, die Methodik und die Transformationssprache verbessert und Grenzen aufgezeigt

Aufwandschätzung und Produktivität in der Softwareentwicklung : Probleme und Problemlösungsansätze

Softwareentwicklungsprojekte sind vielfach durch gravierende Termin- und Budgetüberschreitungen gekennzeichnet. Sofern Methoden und Verfahren zur Aufwandschätzung hierfür ausschlaggebend sind, kommen bestehende Meßprobleme des Software Engineering bzw. der Softwaremetrie zum Tragen, die durch verbesserte Interpretation eingeschränkt werden können. Ein solcher Lösungsansatz wird nachfolgend in seinen Grundzügen vorgestellt

Ermittlung des Industrialisierungsgrades der Anwendungsentwicklung in der Fertigungsindustrie

Die Industrialisierung ist mittlerweile auch in der Softwarebranche angekommen. In dieser Arbeit wird ein Modell vorgestellt, das eine Einstufung der verschiedenen Ausprägungen der Industrialisierung in der Anwendungsentwicklung ermöglicht. Ferner wird auf Basis dieses Modells ein Bewertungsverfahren vorgestellt, welches einem Unternehmen erlaubt, den Grad an Industrialisierung in der Entwicklung von Anwendungen zu ermitteln. Das Ergebnis dieser Ermittlung dient dem Unternehmen als Basis für eine Entscheidung zur Optimierung der Softwareentwicklung. Mit der Festlegung eines Sollgrades können zudem die Ziele für die Verbesserung der Anwendungsentwicklung definiert werden. Eine regelmäßige Ermittlung des Industrialisierungsgrades ermöglicht dabei die Dokumentation des aktuellen Fortschrittes. Eine praktische Bewertung eines Unternehmensbereiches wird im Rahmen einer Fallstudie exemplarisch durchgeführt

Wege zu einer Software-Komponenten-Industrie -Erfolgsfaktoren für die Bildung von virtuellen Gemeinschaften in der Software-Entwicklung

Software hat sich in den letzten Jahren zu einem der zentralen Faktoren innerhalb der industriellen Wertschöpfungskette entwickelt. Die Wertschöpfung der Primärbranche, d.h. der softwareentwickelnden Unternehmen in Deutschland, übersteigt mit ca. 25 Mrd. Euro (im Jahr 2000) die Wertschöpfung im Sektor Landwirtschaft, Forstwirtschaft und Fischerei um ca. 20 % [GfK+2000]. Außerdem hängt die Produktivität fast aller produzierenden Branchen sowie des Dienstleistungssektors weitestgehend von der Unterstützung durch geeignete Software ab. Aus dieser großen Bedeutung ergibt sich ein enormes Einsparpotenzial, das durch die effiziente Erstellung und durch den effizienten Einsatz von Software realisiert werden kann

Software Factory - ein Statusbericht

Die Fabrik scheint nicht mehr das Vorbild der Softwareproduktion zu sein. Dennoch zeigt sich bei genauerer Betrachtung, daß sowohl das Ziel, Softwareprozesse wie Fabrikprozesse zu beherrschen, als auch die Fabrikanalogie, Softwareprozesse wie Fabrikprozesse zu betrachten, im wesentlichen weiterhin bestehen. Weil Erwartung und Erfolg so weit auseinanderklafften, hat die zunehmend auf technische Aspekte eingeengte und auf Automatisierung zielende Interpretation die Software Factory in Mißkredit gebracht. Daß die Praxis aus den technischen Lösungsansätzen in der Forschung und Softwarewerkzeugentwicklung nicht den Nutzen ziehen konnte, den man erwartet hat, muß nicht gegen die Lösungsansätze oder die Werkzeuge sprechen. Es ist aber deutlich geworden und dies wird auch durch eine Studie unseres Lehrstuhls bestätigt, daß die Umsetzungsprobleme in der Praxis außer auf technische Probleme wesentlich auf einem Mangel an Verständnis und Beherrschung der organisatorischen und methodischen Aspekte zurückzuführen sind. Es ist also die Bedeutung der im ursprünglichen Konzept der Software Factory wesentlichen organisatorischen und methodischen Aspekte wiederentdeckt worden. Allerdings wird die Verbesserung der organisatorischen und methodischen Rahmenbedingungen der Softwareentwicklung nicht mehr unter dem inzwischen als kontaminiert geltenden Begriff Software Factory belrieben, sondern unter den Begriffen: Prozeßorientierung, Total Quality Management etc. Aber es gibt inzwischen neben der Kritik einer zu eingeschränkten Problemsicht auch substantielle Kritik an der Fabrikanalogie selbst. Das verbesserte Verständnis der Softwareprozesse hat die Grenzen der Analogie zu den Fabrikprozessen deutlich gemacht