A A A
| Sitemap | Kontakt | Impressum | Datenschutz
ETZ Logo VDE Verlag Logo

Open-Source-Werkzeuge in der Software-Entwicklung

Open-Source-Werkzeuge in der Software-Entwicklung

Linux ist als Betriebssystem für die Maschinensteuerung weit verbreitet. Denn es ist kostenlos und lässt sich individuell anpassen. Doch auch für die agile Software-Entwicklung im Maschinenbau und in der Automation bieten sich einige Open-Source-Lösungen an. Sie helfen Entwicklern, schnell ans Ziel zu kommen und die Qualität stetig zu verbessern.

Ein sitzender Pinguin erscheint bei vielen vor dem inneren Auge, wenn sie an das Thema Open Source denken. Denn der gezeichnete Seevogel mit Namen Tux ist das Maskottchen von Linux. Viele Entwickler schätzen an dem Betriebssystem neben der Stabilität, der Sicherheit, der Transparenz und der Skalierbarkeit auch den offenen Quellcode, der es erlaubt, Linux individuell anzupassen. Aus diesem Grund ist der Einsatz auch im Maschinenbau und in der Automation verbreitet. Aber nicht nur als Betriebssystem kommen Open-Source-Lösungen infrage. Aus dem vielfältigen Angebot lassen sich passende und leistungsstarke Werkzeuge für die gesamte Entwicklung einer Software zur Maschinensteuerung auswählen (Bild).
Open Source oder kommerzielle Lösung?
Open-Source-Werkzeuge sind in der Regel kostenlos. Damit liegt die Hürde für ihren Einsatz niedriger als bei kommerziellen Lösungen. Der Geschäftsführer oder der Mitarbeiter im Controlling muss im Vorfeld nicht erst lange vom Nutzen einer bestimmten Software überzeugt werden. Bewährt sich das Werkzeug in der Praxis, kann bei Bedarf die Investition in kostenpflichtige Zusatzmodule oder Upgrades schneller durchgesetzt werden. Der Kostenaspekt ist im Maschinenbau besonders interessant, weil abhängig von der jeweiligen Hardware und der Steuerung unterschiedliche Technologien – von der PC-Bedienoberfläche über SPS-Software bis hin zu ergänzenden Systemen zur Parametrierung der Anlage und so weiter – verwendet werden. Einzelne Werkzeuge, ob kommerziell oder offen, decken meist nicht die gesamte Bandbreite ab. Entwickler sind in diesem Fall daher oft auf eine Vielzahl von Lösungen angewiesen. Je stärker also auf Open-Source-Angebote gesetzt wird, desto mehr lässt sich einsparen.
Mindestens ebenso wichtig wie die geringen bzw. entfallenden Kosten ist der offene Quellcode, der in den meisten Fällen problemlos weiterentwickelt werden kann. Denn zum einen haben Unternehmen so die Gelegenheit, ein Werkzeug individuell anzupassen, zum anderen bilden sich rund um populäre Lösungen häufig breite Communities, die die Software kontinuierlich erweitern und verbessern. Das führt zu ausgereiften Werkzeugen, die von den Entwicklern in vielen Fällen den überladenen kommerziellen Angeboten vorgezogen werden. Es entstehen aber auch immer wieder spezifische Applikationen, die individuellen Anforderungen entsprechen. Außerdem lässt sich bei technischen Problemen in der Community schnell und zuverlässig Hilfe finden.
Mit Open-Source-Werkzeugen sind allerdings auch einige Schwierigkeiten verbunden. So kann es bei geringer Qualität des Open-Source-Produkts zu erheblichen, im Vorfeld nicht abzusehenden Folgekosten kommen. Darüber hinaus fehlt oft der professionelle Support, den man im kommerziellen Umfeld gewohnt ist. Bei Fehlern sind die Nutzer häufig darauf angewiesen, diese selbst – gegebenenfalls mit Unterstützung aus der Community – zu beheben. Bei einigen Open-Source-Angeboten bestehen zudem Lizenzeinschränkungen. So müssen nach GPL (General Public License) lizenzierter Software selbst entwickelte Erweiterungen im Quellcode freigegeben und damit der gesamten Community zugänglich gemacht werden.
Umfassendes Angebot von Open-Source-Werkzeugen
Unternehmen, die vor der Entscheidung stehen, kommerzielle Lösungen oder Open Source Software einzuführen, sollten die Vor- und Nachteile im Vorfeld abwägen. Einige Fragen helfen dabei:
• Erfüllt die Lösung die gestellten Anforderungen?
• Welche, eventuell zusätzlichen, Kosten fallen an?
• Wie hoch ist der Verbreitungsgrad? (Wie viele Anwender nutzen die Lösung?)
• Wie sieht der Support aus? (Gibt es eine aktive Community oder einen kommerziellen Support?)
• Wie steht es um die Produktreife? (V 0.0.x alpha oder V 0.9?)
• Wird die Lösung kontinuierlich gepflegt? (Wie alt ist die letzte Version?)
• Wie gut ist die Dokumentation? (Ist diese überhaupt vorhanden? Wenn ja, wie hoch ist die Qualität?)
• Welche Lizenzeinschränkungen – zum Beispiel GPL (General Public License), LGPL (Lesser General Public License) oder BSD-Lizenz (Berkeley Software Distribution) – bestehen?
Ist die Entscheidung grundsätzlich zugunsten der offenen Werkzeuge gefallen, bleibt zu prüfen, in welchen Phasen deren Einsatz sinnvoll ist und was aus dem umfassenden Angebot ausgewählt werden soll. Im Folgenden werden verschiedene Open-Source-Werkzeuge vorgestellt, die sich in die agile Softwareentwicklung integrieren lassen.
Feature-, Task- und Bug-Tracking
Anders als herkömmliche Vorgehensmodelle, die häufig als schwerfällig empfunden werden, ist die agile Softwareentwicklung schlank und flexibel (siehe Vorgehensmodell Scrum). Sie orientiert sich vor allem an den Zielen und gibt weniger Regeln vor. Entsprechend genießen die an einem Projekt beteiligten Entwickler mehr Freiheiten und organisieren sich selbst. Anstehende Aufgaben werden nach den speziellen Fähigkeiten sowie der aktuellen Verfügbarkeit verteilt und Fortschritte täglich besprochen. Kurzfristige Reaktionen auf sich verändernde Anforderungen sind so möglich.
Um dabei den Überblick zu behalten, ist zunächst eine klare und stets aktuelle Darstellung des gesamten Entwicklungsprojekts erforderlich. Dazu dient ein Feature-, Task- und Bug-Tracking-System, bei dem die einzelnen Funktionen der zu programmierenden Software (Features) in einzelne Aufgaben (Tasks) untergliedert sind. Die Fortschritte werden über die Tracking-Lösung erfasst. Was bereits erledigt wurde und wo noch etwas getan werden muss, ist so jederzeit leicht nachvollziehbar. Gleiches gilt für aufgetretene Fehler (Bugs) samt Bearbeitungsstatus.
Als Open-Source-Werkzeuge bieten sich für das Feature-, Task- und Bug-Tracking neben anderen Lösungen Mantis oder Bugzilla an. Beide Anwendungen laufen stabil, sind weit verbreitet und werden kontinuierlich gepflegt.
Transparente Versionsverwaltung
Neben dem aktuellen Projektstand sollten auch die Programmierfortschritte der verschiedenen Softwarekomponenten stets transparent sein. Eine zuverlässige Versionsverwaltung ist dafür wichtig. Als Open-Source-Lösung bietet sich etwa Subversion an. Mit dem Werkzeug lassen sich die verschiedenen Dateien in einem zentralen Projektarchiv (Repository) verwalten. Änderungen an einzelnen Softwarekomponenten können von den Entwicklern einfach in das Archiv „eingecheckt“ werden – am besten mindestens einmal am Tag. Die verschiedenen Versionen einer Komponente sind über eine Revisionsnummer für jedes Projektmitglied eindeutig zu erkennen. Ausgewiesen wird auch, welcher Entwickler an welcher Code-Zeile wann gearbeitet hat. Außerdem erstellt Subversion eine Historie sämtlicher Änderungen. Interessant ist auch die recht neue Lösung Mercurial , die sich vor allem für die standort- und länderübergreifende Zusammenarbeit von Entwicklern eignet.
Als Windows-Client kommen verschiedene Lösungen infrage. Überzeugend ist „TortoiseSVN“. Die Lösung unterstützt bei einer Reihe von täglichen Aufgaben wie dem Abrufen des Quellcodes aus dem Archiv oder dem Einchecken in das Archiv. Sie zeigt Unterschiede zwischen Versionen an und hilft dabei, Konflikte im Quellcode zu beseitigen. Außerdem lässt sich die Lösung nahtlos in eine Windows-Umgebung integrieren, an eine Bug-Tracking-Software anbinden und läuft schnell und zuverlässig. Weitere Windows-Clients sind „RapidSVN“ , „Subcommander“ oder „AnkhSVN“ , das sich direkt in die Entwicklungsumgebung Visual Studio von Microsoft integrieren lässt.
Kontinuierliche Integration
Auch wenn die Entwickler ihre Änderungen an den Dateien täglich über die Versionsverwaltung „einchecken“, sollte sichergestellt werden, dass die aus den einzelnen Softwarekomponenten bestehende Anwendung reibungslos funktioniert. Dazu ist eine kontinuierliche Integration (Continuous Integration) nahezu unumgänglich, bei der die Anwendung nach jeder Änderung neu erstellt und automatisch getestet wird. Treten Fehler auf, wird der verantwortliche Programmierer direkt informiert – etwa per E-Mail – und kann so kurzfristig das Problem beheben. Voraussetzung für die kontinuierliche Integration ist neben einer sauberen Versionsverwaltung, dass eine Build Server Software installiert ist, die die Anwendung automatisch erstellt und testet.
Ein kommerzielles, zumindest für kleinere Projekte jedoch kostenloses Werkzeug ist „TeamCity“ – Distributed Build Management and Continuous Integration Server. Ergänzt wird der Server von Build Agents, die separat installiert werden und das eigentliche Erstellen und Testen ausführen. Die ersten drei Agents sind in der kostenlosen Version von „TeamCity“ enthalten. Weitere Agents müssen für jeweils 246 € hinzugekauft werden. Völlig kostenlos (Open-Source) sind die Build-Server-Lösungen Cruise Control und Hudson .
Unit-Tests und Dokumentation
Für die entweder automatisch vom Build Server oder direkt vom Entwickler angestoßenen Tests stehen verschiedene Lösungen zur Verfügung. Mit Unit-Tests wird die Funktionsfähigkeit der einzelnen Komponenten überprüft. Dabei kommen Frameworks zum Einsatz, die in der Regel aus einer Bibliothek und einigen Werkzeugen bestehen. Als Open-Source-Lösung für Java-Software setzen Entwickler häufig auf „JUnit“ -Anwendungen, die in C++ programmiert sind und mit „CppUnit“ oder „UnitTest++“ überprüft werden können. Für die Programmiersprache C# bietet sich “„NUnit“:http://www.nunit.org/index.php an.
Die Entwicklung des Quellcodes und dessen Dokumentation zeitlich vonei-nander zu trennen, ist problematisch. Dadurch können leicht Fehler oder Ungenauigkeiten auftreten, die eine spätere Modifikation oder Ergänzung der Software erschweren. Daher empfiehlt es sich, Werkzeuge zu nutzen, die aus dem Quellcode automatisch die Dokumentation generieren. Eine leistungsstarke Open-Source-Lösung für diesen Zweck ist Doxygen . Damit lässt sich etwa ein Überblick zum Aufbau und den Elementen der dokumentierten Software erzeugen.
Kombination zu einer durchgängigen Kette
Jedes Open-Source-Werkzeug für sich erleichtert bereits die Softwareentwicklung. Zusätzliche Vorteile lassen sich dann erzielen, wenn die einzelnen Lösungen für einen konkreten Fall optimiert und mithilfe von Skripten intelligent zu einer durchgängigen Kette kombiniert werden. So wird die Anwendung etwa nach dem Einchecken einer Änderung in die Versionsverwaltung automatisch vom Build Server erstellt und ein Unit Test angestoßen. Eventuelle entdeckte Fehler werden via E-Mail an den Entwickler gemeldet und im Bugtracking-System gemeinsam mit den Funktionsanforderungen und Aufgaben verwaltet und geplant. Eine eindeutige Nummerierung der einzelnen Einträge über den gesamten Entwicklungsprozess hinweg sorgt für eine hohe Transparenz.
Sicher muss vor der Einführung neuer Werkzeuge genau abgewogen werden, ob kommerzielle oder Open-Source-Lösungen genutzt werden sollen. Orientiert man sich dabei an den oben gestellten Fragen, lässt sich eine einfache und genau zum eigenen Bedarf passende Werkzeug-Kette aufsetzen. Die Entwicklungskosten werden so gesenkt und die Softwarequalität wird zu geringen Investitionskosten sowie mit einem überschaubaren Aufwand nachhaltig gesteigert.
Vorgehensmodell Scrum: Am Ball bleiben
„Scrum“ bezeichnet einen komplizierten Rugby-Spielzug und bedeutet „Gedränge“. Der Zug kann nur gelingen, wenn das Team diszipliniert zusammenarbeitet.
Die Rollen
Der Product Owner formuliert und priorisiert die Anforderungen. Der Scrum Master ist für die Einhaltung der Rollen und die Überwachung der Rechte zuständig. Er sorgt für Transparenz und hilft dabei, Verbesserungspotenziale (im Prozess) zu erkennen und zu nutzen. Das Team besteht aus fünf bis neun Vollzeitarbeitskräften, die die Anforderung umsetzen.
Das Rennen
Scrum-Projekte bestehen aus kurzen Arbeitszyklen, die „Sprints“ genannt werden. Zuvor priorisiert der Product Owner die Aufgabenstellung, die es in einem Sprint zu lösen gilt. Das Team wählt umsetzbare Funktionalitäten aus und verpflichtet sich, diese innerhalb des Sprints fertigzustellen. Ein Sprint dauert zwischen zwei und vier Wochen. In täglich stattfindenden viertelstündigen Besprechungen beantworten die Teammitglieder folgende Fragen:
• Was habe ich seit dem letzten Treffen getan?
• Was werde ich bis zum nächsten Treffen tun?
• Gibt es ein Problem, das meine Arbeit behindert?

Der Beitrag als pdf

Dipl.-Ing (FH) Wolfram Schäfer ist Geschäftsführer der IT Engineering GmbH aus Pliezhausen bei Stuttgart.