Der Baukasten Objektorientierte Software-Entwicklung mit UML : Berufliche Weiterbildung in der Software-Industrie

Der in den vergangenen Jahren erwartete Boom des E-Learning ist nicht so eingetreten wie ursprünglich erhofft. Verschiedene Gründe sind hier, gerade im Bereich der KMUs, für eine Nicht-Annahme des Konzepts E-Learning verantwortlich. Doch ist speziell die Weiterbildung von Fachpersonal und der Auf- und Ausbau von Kompetenz für KMUs ein essenzieller Bestandteil der Sicherung des langfristigen Überlebens. Aus einer Analyse der Gründe für den Fehlschlag des E-Learnings, des pädagogischen Konzepts des hybriden Lernens und typischer Geschäftsmodelle im Aus- und Weiterbildungsbereich wurde am Fraunhofer IESE der modulare Baukasten Objektorientierte Software-Entwicklung mit UML" geschaffen. Ziel des Baukasten ist es, aus einer Bedarfsanalyse heraus maßgeschneiderte, kostengünstige und Nutzen bringende, im Lernerfolg und Wissenstransfer nachhaltige Weiterbildungsangebote für KMUs im Bereich der objektorientierten Software-Entwicklung mittels web-basiertem Training, Präsenzschulung, Tutoring und Coaching zu ermöglichen

Methoden- und Werkzeugunterstützung für evolutionäre, objektorientierte Software-Projekte

Die Software-Entwicklung verläuft in der Regel evolutionär, d.h. als eine Folge von Erweiterungs- und Anpassungszyklen, beruhend auf Erfahrung, Nutzung und Revision. Viele der bekannten Vorgehensmodelle, wie z.B. "Rational Unified Process" (RUP), berücksichtigen diesen evolutionären Aspekt der Software-Entwicklung ungenügend. Mit dem EOS-Modell, ein Vorgehensmodell für die evolutionäre, objektorientierte Software-Entwicklung (EOS), wird versucht, dieses Defizit zu überbrücken. In der ursprünglichen Fassung ist das EOS-Modell methodenunabhängig. Ein Ziel der Dissertation war es, konkrete Methoden für die EOS-Subprozesse Projektmanagement, Software-Entwicklung, Qualitätssicherung, Konfigurationsmanagement und Nutzung und Bewertung vorzuschlagen. Ausgehend von der Methoden-Definition wurde prototypisch ein Werkzeug implementiert, das eine systematische Unterstützung der definierten Methoden ermöglicht

SiMAP-FIS Passenger Information System

Ziel des Siemens-Fahrgastinformationssystems SiMAP®-FIS ist die Bereitstellung von Technologie zur Information der Fahrgäste von Verkehrsunternehmen über Zugläufe, Ankunftszeiten und besondere Betriebssituationen. Die Informationsdarstellung kann z.B. stationär über Anzeigen an den Bahnsteigen, im Internet oder mobil auf WAP-fähigen Endgeräten wie Mobile Phones oder PDA erfolgen. Die Anzeigen informieren über die in nächster Zeit einfahrenden Züge inkl. Zugziel, Ankunftszeit und ggf. Einfahr-Gleis. Zusätzlich sind aktuelle Sondermeldungen oder Werbetexte darstellbar. Der Praxissemesterbericht gibt einen Überblick über die Systemkomponenten, insbesondere Bereichsrechner, Bedienplätze und Stationsrechner. Schwerpunkt ist die Beschreibung der grundlegenden Software-Konzepte, darunter die plattformübergreifende Kommunikation mit Datentelegrammen auf XML-Basis via TCP/IP-Client/Server-Komponenten. Die namensgebende Siemens Modular Applikation Platform SiMAP® als gemeinsame modulare Software-Basis aller Microsoft-Windows-basierten Systemkomponenten wird mit ihrem objektorientierten Design vorgestellt. Programmiersprache ist C++

Interdependenzen zwischen betriebswirtschaftlichen Organisationsmodellen und Informationsmodellen

Der folgende Beitrag analysiert Zusammenhcnge zwischen betriebswirtschaftlichen Organisationsmodellen und Informationsmodellen in Form von Daten-, Funktijons- und Objektmodellen. Er soll diese Sichtweise erweitern und verschiedene Organisationsmodelle beziehungsweise Koordinationsformen beruecksichtigen. Aufbauend auf den betriebswirtschaftlichen Organisationsmodellen gilt es dann, geeignete Informationsmodelle und Modellierungsstrategien zu waehlen

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