"Java ist raus aus den Kinderschuhen"

Eine Welt ohne Java? – Das ist für doubleSlash-Mitbegründer Oliver Belikan nicht vorstellbar. Ganz im Gegenteil: doubleSlash hat bei der Entwicklung der objektorientierten Programmiersprache selbst einen entscheidenden Anteil geleistet und sich von Anfang an in der Entwicklercommunity engagiert. Die objektorientierte Programmiersprache ist heute nicht nur bei Software und Webanwendungen, sondern auch bei uns ein fester Bestandteil bei der Softwareentwicklung in Kundenprojekten und bei der eigenen Produktentwicklung. So steckt die Java-Technologie beispielsweise im Postfinder oder dem BMW-Produktkonfigurator. Im Interview berichtet Oliver Belikan von Java-Erfahrungen aus der Praxis und wirft einen Blick in die Zukunft.

Mehr…

Zertifizierte Qualitätssicherung – Mit qualifizierten Tests zu erfolgreichenen Projekten

Qualitätssicherung – german testing boardGeschafft! Vier Tage Schulung und anschließend eine Prüfung. Jetzt bin ich zertifizierter Softwaretester und habe eine ganze Menge gelernt, was das professionelle Testen von Software angeht. Nicht nur bezüglich des eigentlichen Testens, sondern auch zur Planung, Vor- und Nachbereitung und Konzeption. Für viele ist das ein eher unangenehmes Thema – langweilig und unproduktiv, muss man eben machen. Aber Qualitätssicherung ist nicht nur ungemein wichtig, sondern auch spannend, wenn man sie professionell betreibt.

Warum hat professionelle Qualitätssicherung bei doubleSlash einen hohen Stellenwert und was bringt das dem Kunden und uns?

Softwareentwicklung hat oftmals den Ruf, unter hohem zeitlichen Druck zu stehen. Und wenn am Ende das Release-Datum naht, wird an den augenscheinlich unproduktiven Aufgaben wie der Qualitätssicherung gespart. Dass diese Tätigkeiten aber keineswegs unproduktiv sind, wird spätestens dann klar, wenn Korrekturen am bestehenden System nötig sind. Der Aufwand, Abweichungen nach der eigentlichen Entwicklungsphase zu korrigieren, ist um ein Vielfaches höher als wenn sie im Entwicklungsprozess entdeckt und behoben werden.

Manche Fehlerquellen können sogar schon im Vorfeld gefunden werden, wenn zum Beispiel die Anforderungen schon frühestmöglich in Reviews validiert und auf Testbarkeit geprüft werden. Ein weiterer Pluspunkt einer frühen Einbindung professioneller Tester: Die später durchzuführenden Softwaretests können intensiv geplant und vorbereitet werden. So entstehen im Testprozess messbare Qualitätswerte, die für spätere Entwicklungszyklen hilfreiche Aufschlüsse geben können.

Qualitaetssicherung_1760

Das ist eine von zahlreichen Erkenntnissen, die man von einer Schulung mitnimmt. Eine weitere ist, dass es keine einzig gültig, starre Vorgehensweise für die Qualitätssicherung gibt. Die Vorgehensweise und Zielsetzungen sind immer projektabhängig, beispielsweise von der Prozessmethode in der Entwicklung: In Wasserfall-Projekten wird die Testplanung und -durchführung natürlich anders aussehen als in iterativen agilen Methoden wie beispielsweise Scrum. Die Herausforderung, mit der sich ein Testmanager konfrontiert sieht, ist, eine zum Projekt passende Teststrategie zu konzipieren und zu planen – und das unter Berücksichtigung der bewährten internationalen Standards.

Um eine solche Qualitätssicherung anbieten und betreiben zu können, besuchen die Qualitätssicherer von doubleSlash Schulungen auf Grundlage der Ausbildungspläne des International Software Testing Qualifications Board (ISTQB) und lassen sich im Anschluss vom ISTQB zertifizieren. Mit dieser Zertifizierung stellen wir sicher, dass eben diese Standards in unseren Produkten und Projekten eingehalten werden und bieten unseren Kunden auch professionelle Qualitätssicherung als Service an.

So kann die Qualität konstant hoch gehalten oder sogar noch gesteigert werden. Das steigert die Freude an der Entwicklung, in der Nutzung von und somit auch die Zufriedenheit mit dem Geschaffenem.

Usability als zentraler Erfolgsfaktor für gute Unternehmenssoftware

Usability„Software für Unternehmen entspricht häufig nicht den Erwartungen“ – so lautet der Titel einer News-Meldung[1], die vergangene Woche im iX Fachmagazin für professionelle Informationstechnik erschienen ist. Laut der genannten Studie des Beratungsunternehmens FleishmanHillard[2] belegen Entwickler von Software für Unternehmen den letzten Platz in der Kategorie Innovation.
Mehr…

Security in Webanwendungen Teil 3: Sicherer Betrieb von Webapplikationen

In dieser Blogserie haben wir bereits die Themen Design– und Programmierung von sicheren Webanwendungen behandelt. Im letzten Teil wird beschrieben, wie der sichere Betrieb von Webapplikationen gewährleistet werden kann.

Reduzieren von Serverinformationen

Selbstverständlich möchte man einem Hacker so wenig Informationen über ein System geben wie nur möglich. Allein die Anzeige der Versionsnummer der verwendeten Server kann genutzt werden, um gezielt nach Informationen über Sicherheitslücken der spezifischen Versionen zu suchen. Dadurch wird der Aufwand, in das System einzudringen, für einen Angreifer geringer.

Das übliche sicherheitssensible System nutzt einen Proxyserver um die SSL-Verschlüsselung der Verbindung zu terminieren, damit der eigentliche Applikationsserver vor dem direkten Zugriff durch die Nutzer geschützt wird. Die Datenübertragung zwischen dem Proxy- und Applikationsserver erfolgt dann oft unverschlüsselt. Somit gibt es bereits für eine Webapplikation zwei Server, bei denen man die Versionsnummer verbergen muss. Das Verbergen der Server- und Versionsinformationen hat Auswirkungen auf zwei Ebenen. Die eine Ebene ist das HTTP-Protokoll, die zweite Ebene die Anzeige von Exceptions in der Webapplikation. In beiden Ebenen werden keine oder nur reduzierte Informationen angezeigt. Generell sollten dem Nutzer jedoch sowieso keine Exceptions oder Stacktraces angezeigt werden.

Im Folgenden wird an einer Beispielarchitektur gezeigt, wie sich die Versionsnummern abschalten lassen. Genutzt wird ein Apache Webserver in der Version 2.2 als TLS-Proxy, welcher die SSL-Verbindung terminiert und einen Apache Tomcat in der Version 7, der als Applikationsserver dient.

Im Apache Webserver lassen sich die Serverinformationen über den folgenden Eintrag in der Datei „httpd.conf“ anpassen:

ServerTokens Prod

Mit dieser Angabe wird lediglich der Name des Servers angezeigt, im Ursprungszustand würde der Apache Webserver die folgenden Informationen ausgeben:

  • Name des Servers
  • Versionsnummer
  • Name des verwendeten Betriebssystems
  • Name und Versionsnummer der verwendeten Module

Diese Informationen wären für einen Hacker sehr nützlich, denn er kann auf dem Schwarzmarkt gezielt Tools einkaufen, die ihm helfen den Server zu kompromittieren.

Die Reduzierung der Serverinformationen beim Apache Tomcat 7 gestaltet sich etwas schwieriger. Um hier die Serverinformationen zu reduzieren, muss man die Datei „ServerInfo.properties“ aus dem JAVA-Paket „catalina.jar“ entpacken. Zum Entpacken öffnet man die Konsole des Betriebssystems und wechselt in das Verzeichnis „lib“ innerhalb des Apache Tomcat. Anschließend führt man folgenden Befehl aus:

jar xf catalina.jar org/apache/catalina/util/ServerInfo.properties

Nun befindet sich innerhalb des Bibliotheksverzeichnisses der Verzeichnispfad „org/apache/catalina/util“, in dem wiederum die Datei „ServerInfo.properties“ existiert. Im folgenden Beispiel ist der Inhalt der Datei bereits angepasst und im Eintrag „server.info“ die Versionsnummer entfernt:

server.info=Apache Tomcat
server.number=7.0.50.0
server.built=Dec 19 2013 10:18:12

Nun zeigt auch der Apache Tomcat im HTTP-Protokoll und bei Exceptions keine Versionsnummern mehr an.

Die Sicherheit in Webapplikationen kann also an mehreren Stellen optimiert werden. Schon beim Desgin wird durch die Beachtung von Sicherheitsmechanismen ein höherer Standard gewährleistet. Maßnahmen bei der Programmierung, wie beispielsweise das Escaping von Metazeichen oder die Nutzung eines Sicherheitstokens, sorgen ebenfalls für mehr Sicherheit in Webanwendungen. Durch die Reduzierung der Serverinformationen kann auch beim Betreiben von Webapplikationen das Risiko eines Hackerangriffs gesenkt werden.

Was hat XAVER mit Softwareprojekten zu tun?

Wassertropfen_kleinAnfang Dezember wütete der Orkan XAVER über Deutschland und ich hörte im Nachgang  zufällig im Radio einen Bericht darüber. War er vielleicht doch nicht so heftig? Ist ja nicht viel passiert. Weit gefehlt. Der Bericht hat deutlich gemacht, mit welchen Maßnahmen verhindert wurde, dass die Jahrhundertflut an den Küsten große Schäden anrichtet.

Land unter. Menschenleben in Gefahr. Flugzeugabsturz.

Das waren die drei wesentlichen Katastrophen, die in dem Bericht betrachtet wurden. Schon nach den Fluten in den letzten Jahrzehnten wurden die Deiche ausreichend verstärkt. Die Vorhersage des Orkans und seiner möglichen katastrophalen Folgen kam ausreichend früh. Die Menschen auf den Halligen konnten ihre Häuser schützen. Die Patrouillen am Deich kontrollierten auf Schäden, bevor das Wasser durchbrach. Der Flughafen Hamburg wurde geschlossen, bevor wieder eine vollbesetzte Maschine in Gefahr einer Bruchlandung geriet.

Was hat das nun mit Softwareprojekten zu tun? Der Katastrophenschutz in Zusammenhang mit dem Orkantief XAVER ist ein Paradebeispiel für gelungenes Risikomanagement.

Das falsche Produkt. Zu spät. Zu teuer.

Auch in Software-Projekten müssen drei große Katastrophen mit Risikomanagement verhindert oder gemindert werden: Das falsche Produkt. Zu spät. Zu teuer. Hier haben wir viele Erfahrungen mit Risiken, die sich im Vorfeld schon erahnen lassen. Auch Software-Projekte müssen in puncto Risiken bewertet, mit Maßnahmen belegt und permanent beobachtet werden. Es braucht Frühwarnsysteme, um das Eintreffen der Risiken rechtzeitig zu erkennen und Schutzmaßnahmen zu definieren.

Vielleicht motivieren die positiven Ergebnisse des Risikomanagements beim Orkantief XAVER dahingehend, das eine oder andere Handwerkszeug für das eigene Projekt noch einmal zu überprüfen. Dann kann sich der Projektleiter eines komplexen Projektes auf die Frage: „Das war doch gar nicht so schwierig, oder? Ist ja gar nichts passiert…“ gemütlich zurücklehnen und mit einem Grinsen antworten: „Da habe ich wohl alles richtig gemacht.“

In diesem Sinne wünsche ich Ihnen allen einen guten und gesunden Rutsch ins neue Jahr, keine Katastrophen und immer „Happy Projects“ – auch in 2014.

10 Erfolgsfaktoren für das Anforderungsmanagement in agilen Software-Großprojekten

Prozess_ScrumEine der Hauptaufgaben des Product Owners in agilen Softwareprojekten ist es, die Produktanforderungen mit dem Kunden abzustimmen und in sogenannten User Stories zu beschreiben. Diese werden dann von den Entwicklern Stück für Stück in Form von darin heruntergebrochenen Tasks umgesetzt. Nach jeder Entwicklungsiteration – dem Sprint – entsteht ein auslieferfähiges Ergebnis. Die Abstimmung der User Stories und Akzeptanzkriterien ist ein zentraler Prozess der agilen Entwicklungsmethodik, der in der Praxis meist mehrere Abstimmungschleifen durchläuft.

Was aber, wenn der Product Owner und sein Team nicht alleine an einem Softwareprodukt arbeiten, sondern 17 weitere Teams mit vielen Abhängigkeiten untereinander beteiligt sind? Wenn es auch viele Kunden mit konkurrierenden Zielen gibt, die teilweise international verteilt sind und zum Teil selbst große Softwareprojekte mit eigenen Zeitplänen repräsentieren? Dann wird das Anforderungsmanagement im Projekt zu einer besonderen Herausforderung auf dem Weg vom Wunsch zur Wirklichkeit.

Mit unseren Erfahrungen aus der agilen Entwicklung webbasierter Softwareanwendungen haben wir die 10 wichtigsten Erfolgsfaktoren zusammengefasst, damit das Anforderungsmanagement auch in agilen Großprojekten gut und effizient funktioniert:

1. Die Scrum-Rollen „Kunde“ und „Product Owner“ werden beide ausgefüllt.

In Filmsprache übernimmt der Kunde die Rolle des Produzenten und der Product Owner die Rolle des Drehbuchautors. Der eine fordert das Produkt an, der andere gestaltet es. In vielen Projekten werden diese beiden Rollen vermischt bzw. eine davon wird gar nicht gelebt. Das führt zu einem Vakuum bei der Entwicklung der Produkt-Vision und der fachlichen Prioritäten.

2. Der Kunde trägt die Produkt-und Release-Vision mit.

Die Produkt-Vision ist sowohl fachliche Klammer als auch Motivationsfaktor für die Teams. Deswegen ist es eine wichtige Aufgabe des Product Owners, diese Vision permanent dem Team zu vermitteln. Aber nur wenn der Kunde diese Vision voll mitträgt, wird das Produkt letztendlich seine Anforderungen treffen.

3. Die Teams kennen die übergreifende Produkt- und Release-Vision.

Die Teams sollen nicht nur die Vision für das eigene Team, sondern für das ganze Produkt kennen. Nur so verstehen sie sich als Teil des Ganzen und unterstützen im Bedarfsfall auch gerne andere Teams.

4. Der Kunde steht für das Review zur Verfügung.

Agile Projekte leben von einem ständigen Lernzyklus. Wird das Review vom Kunden nicht wahrgenommen, fehlt eine wichtige fachliche Feedbackschleife zum Produkt und damit zum Entwicklerteam.

5. Scrum of Scrum wird für Product Owner, Scrum Master und technische Architektur gelebt.

Wenn viele Scrum Teams an einem Produkt arbeiten, werden Product Owner und Scrum Master jeweils in eigenen Gruppen – im sogenannten Scrum of Scrum – organisiert. In diesen Gruppen werden teamübergreifende Fragen geklärt. Nur wenn das Konzept des Scrum of Scrum auch die technische Architektur umfasst, können softwarearchitektonische Inkonsistenzen verhindert werden.

6. Es gibt nicht zu viele Teams.1

Nach unserer Erfahrung sind mehr als 7 Teams in einem Projekt nicht effizient mit klassischen Scrum-Methoden steuerbar. Die Gruppe der Product Owner und Scrum Master überschreitet dann die optimale Teamgröße. In einem Software-Großprojekt ist allerdings oft eine größere Skalierung notwendig. In diesem Fall sind die Teams in einzelnen Zellen z.B. nach Features oder Produktkomponenten zu organisieren, um die Komplexität beherrschbar zu machen und die Teamgrößen immer übersichtlich zu halten.

7. Die Abhängigkeiten zwischen den Teams sind gering.

Starke Abhängigkeiten zwischen den Teams führen zu ungeplanten Anforderungen, die außerhalb des Backlogs vorbeigesteuert werden. Das ist Gift für eine effiziente Abarbeitung der User Stories und demotiviert die Teams.

8. Anforderungen von abhängigen Teams werden über die Product Owner eingesteuert.

Wenn sich größere Abhängigkeiten zwischen den Teams nicht vermeiden lassen, sind diese im Scrum of Scrum über die Product Owner einzusteuern. Das bremst zwar scheinbar die schnelle Hilfe für das Nachbarteam aus, sichert aber auf Dauer eine bessere Planbarkeit des Gesamtprojekts.

9. Es gibt ein übergreifendes Anforderungsmanagement für Großprojekte mit vielen Anforderern

Wenn es nicht mehr den einen Kunden gibt sondern viele Anforderer aus unterschiedlichen Initiativen und Projekten, dann ist für große strategische Anforderungen ein vorgeschaltetes Anforderungsmanagement sinnvoll. Nur so bekommen die Product Owner die Anforderungen mit ausreichender Stabilität und fachlicher Tiefe.

Die Aufgaben eines solchen Anforderungsmanagements sind:

a.    Sicherstellung der Ende-zu-Ende-Betrachtung der Anforderungen über alle Projekte hinweg.
b.    Prüfung der unternehmerischen Relevanz angeforderter Themen.
c.    Herbeiführung der Entscheidungen im Change Control Board.
d.    fachliche Aufbereitung von Themen für die Product Owner.
e.    Verdichtung der Sprintergebnisse und Schaffung von Transparenz über den Stand der Anforderungen für die anfordernden Projekte.

10. Das übergreifende Anforderungsmanagement ist Teil des Multiprojektmanagements bei sehr großen anfordernden Initiativen.

Das Multiprojektmanagement sorgt für die richtige Auswahl und den richtigen Schnitt der Projekte. Dazu leistet das übergreifende Anforderungsmanagement einen zentralen Beitrag, da es die verschiedenen Fachbereichsanforderungen aus Unternehmenssicht strategisch zusammenführt.

Checkliste: Software besser mieten oder kaufen?

Sie stehen vor der Entscheidung, ob Sie eine Marketingsoftware kaufen oder besser mieten sollen? Dann nutzen Sie unsere Checkliste, um eine sichere Entscheidung treffen zu können.

Wann Sie Software besser kaufen sollten:

  1. Bei schneller Umsetzungsmöglichkeit durch Ihre eigene IT-Abteilung.
  2. Bei gutem und funktionierendem „in House“ Support und ausreichend Ressourcen der IT-Abteilung.
  3. Wenn die neue Marketingsoftware viele technische Schnittstellen und Anbindungen an existierende Systeme erfordert.
  4. Bei strikter Sicherheitspolicy oder strenge Vorgaben durch Revision, Compliance oder IT-Strategie.
  5. Wenn generell die abzuspeichernden und zu pflegenden Daten als „sehr sensibel“ einzustufen sind.
  6. Wenn die Anwendung als „unternehmenskritisch“ zu bewerten ist.
  7. Bei kontinuierlichen und permanenten Weiterentwicklungen mit eigenen Ressourcen.
  8. Wenn gültige Softwarelizenzen z.B. für Oracle Enterprise schon im Hause sind.
  9. Wenn evtl. vorhandene eigene und geeignete Hardware genutzt werden kann.
  10. Wenn IT-Standard für Ausfallsicherung, Cluster, Backup etc. existiert.
  11. Wenn Sie damit Kosten sparen (Infrastruktur, Hardware, Betreuung, …).
  12. Wenn Test/Integrationssystem „nahe“ beim Produktionssystem stehen muss (z.B. aufgrund Vielzahl von technischen Schnittstellen).

Wann Sie Software besser mieten sollten:

  1. Wenn das System möglichst sofort genutzt werden soll.
  2. Solange noch wenige Schnittstellen zu anderen eigenen Systemen existiert.
  3. Wenn noch offen ist, ob das System später selbst betrieben werden soll und zunächst eine Test-/Pilotphase angestrebt wird.
  4. Wenn eher einmalige Importvorgänge (z.B. Urladung) existieren. D.h. wenige technische „Online“-Schnittstellen existieren.
  5. Ein Hostingpartner hat sich im Kerngeschäft gut mit SLA´s, Tools und entsprechenden Supportgewährleistungen spezialisiert.
  6. Häufig ist die Performance bei weltweiten Zugriffen besser wie im eigenen internen Firmennetz.
  7. Wenn die Weiterentwicklung, Anwendungssupport, Betreuung eher von dem Dienstleister übernommen werden soll.
  8. Kein oder zu wenig Administrations-Know-How über Glassfish, Tomcat, Oracle im Haus existiert.

Weitere Links:

Themen und Trends der EclipseCon Europe 2013

Brian Fitzpatrick (Google)Die EclipseCon Europe zählt zu den größten Veranstaltungen der Eclipse Foundation in Europa und stellt eine Plattform für die europäische Entwickler- und Anwender-Community dar. Ganz deutlich zu erkennen war in diesem Jahr unter anderem der Trend zu Machine-to-Machine (M2M) und Internet of Things (IoT), der mittlerweile auch Einzug in die Eclipse Plattform hält.

Vom 29. bis 31. Oktober 2013 fand die achte europäische Konferenz rund um freie Entwicklunsplattform Eclipse in dem mittlerweile als Veranstaltungsort etablierten Forum im Schlosspark in Ludwigsburg statt. Das Programm bestand aus einer bunten Mischung von Erfahrungsberichten über den Einsatz von Eclipse als Entwicklungs- und Anwendungplatform sowie Vorträgen zu neuen aber auch etablierten Technologien auf Basis von Eclipse und Java.

Trend: Internet der Dinge

Besonders auffällig war in diesem Jahr die große Anzahl an Vorträgen mit Themen aus dem Bereich Machine-to-Machine (M2M) und Embedded Devices. Die Eclipse Platform reagiert auf den Trend zum Internet der Dinge gleich mit einer ganze Reihe von Open-Source-Projekten, die Services, Frameworks, Protokolle und Tools zur Vereinfachung der M2M-Entwicklung bereitstellen.
Eines dieser Projekte, das gleich in mehreren Vorträgen auf der Konferenz vertreten war, ist das Paho Projekt. Dieses stellt skalierbare Open-Source Implementierungen von Standard-Messaging-Protokollen (z.B. MQTT) für den Einsatz in Applikationen im M2M oder Embedded Umfeld bereit. Paho inkludiert derzeit Client-APIs für C und Java, es sind aber bereits weitere für C++, JavaScript, Lua und Phyton geplant.
Zwei weitere auf der ECE Europe vorgestellte Eclipse M2M Projekte sind Mihini und Koneki. Während Mihini eine auf Linux basierend Embedded Runtime bereitstellt, die eine High-Level Lua API für die Entwicklung von M2M Applikationen freilegt, stellt Koneki mit den Lua Development Tools eine komfortable IDE für die Entwicklung von Embedded Software mit Lua dar.

Die Eclipse Platform stellt sich aber auch der Herausforderung komplexe Anwendungen für multiple mobile Platformen unter Verwendung von einfachen Widgets zu entwickeln. Auf der Konferenz wurde hierfür das mobile Eclipse Framework Tabris vorgestellt. Tabris ermöglicht es Anwendungen mit grafischer Benutzeroberfläche unter Einsatz von Java und SWT zu erstellen, die auf den verschiedenen Endgeräten dann mit nativen UI-Widgets (Cocoa Touch Widgets in iOS, Java basierte Widgets in Android und HTML5 in einem Browser) dargestellt werden. Das ganze funktioniert mittels Standard JavaEE Technologien, über die eine Applikation auf einem Server erzeugt und deren Benutzeroberfläche über eine JSON-Repräsentation an die nativen Clients übermittelt wird.

Eclipse Modeling Framework

Eine nicht ganz neue Eclipse Technologie, die sich aber dennoch in gleich mehreren Vorträgen auf der Veranstaltung platzierte, ist das Eclipse Modeling Framework (EMF). Hierbei handelt es sich um ein Modellierungs-Framework zur automatisierten Generierung von Java Code auf Basis eines XMI Modells. EMF stellt zudem eine Reihe von Tools und Adapterklassen zur Erweiterung und Manipulation eines Modells u.a. auch zur Laufzeit einer Anwendung zur Verfügung. Diese Vorteile werden zum Beispiel von dem Application Model einer Rich Client Anwendung auf Basis von Eclipse 4 genutzt. Mit der EMF Client Platform können sogar ganze Benutzeroberflächen modelliert und automatisch generiert werden. Das Data-Binding zwischen Model und UI-Elementen wird dabei vom Framework automaitisch vorgenommen. Bei doubleSlash setzen wir EMF bereits seit 2011 in einem Projekt für unseren Kunden BMW ein.

Es gab noch eine ganze Menge weiterer Vorträge, die der Konferenz in Ludwigsburg ihren Abwechslungsreichtum verliehen. So wurden zum Beispiel die Neuerungen in Java 8, das automatisierte Testen von Benutzeroberflächen Eclipse-basierter Anwendungen mit Q7 und viele weitere spannende Themen vorgestellt. Abschließend lässt die EclipseCon Europe 2013 auf jeden Fall den folgenden Eindruck zurück: Die Eclipse Platform und ihre Community werden auch in Zukunft eine stabile und aktive Platform mit vielen innovativen und zukunftsorientieren Projekten und Technologien bereitstellen.

Warum sich nicht drängen?

Nein, nicht sich drängen lassen, sondern sich drängen. Gemeint ist damit SCRUM (englisch für Gedränge), was ein Vorgehensmodell der Softwaretechnik ist, das sich immer größerer Beliebtheit erfreut.
Der Ansatz von Scrum[ref]Beschreibung des Projektmanagement-Frameworks http://de.wikipedia.org/wiki/Scrum[/ref] ist empirischinkrementell und iterativ. Er beruht auf der Ansicht, dass die meisten modernen Entwicklungsprojekte zu komplex sind, um durchgängig planbar zu sein. Scrum versucht, die Komplexität durch drei Prinzipien zu reduzieren:

SCRUM bei doubleSlash

  1. Transparenz: Der Fortschritt und die Hindernisse eines Projektes werden täglich und für alle sichtbar festgehalten.
  2. Überprüfung: In regelmäßigen Abständen werden Produktfunktionalitäten geliefert und beurteilt.
  3. Anpassung: Die Anforderungen an das Produkt werden nicht ein und für alle Mal festgelegt, sondern nach jeder Lieferung neu bewertet und bei Bedarf angepasst.Mehr…

Mehr Flexibilität durch Eclipse 4

Eclipse ist den Meisten als Integrierte Entwicklungsumgebung (IDE) für Java bekannt. Mit einem Marktanteil von über 65% stellt sie heute die führende Entwicklungsumgebung für Java dar. Doch Eclipse ist weitaus mehr als das.

eclipse-juno-logoSeit dem Release der Version 3.0 im Jahr 2004 unterstützt Eclipse die Wiederverwendung seiner Platform für das Erzeugen von Stand-Alone-Applikationen, bekannt unter der Bezeichnung RCP (Rich Client Platform). Eclipse 4 ist die nächste Generation der Platform für das Entwickeln Eclipse basierter Anwendungen. Bei doubleSlash setzen wir Eclipse 4 bereits seit 2011 in einem Projekt für unseren Kunden BMW ein.

Das Entwickeln von Softwareapplikationen auf Basis von Eclipse hat sehr viele Vorteile. Eine der Kernkomponenten der Eclipse Platform ist die OSGI-Implementierung Equinox. Sie ermöglicht die Entwicklung und Ausführung modularer Eclipse Applikationen unter dem Einsatz von Plug-ins. Des Weiteren verwendet die Eclipse Platform native User-Interface-Komponenten, die stabil und zuverlässig sind. Große Unternehmen wie IBM und Google verwenden die Eclipse Platform für ihre Produkte und stellen dadurch sicher, dass die Platform flexibel und schnell bleibt und sich weiterentwickelt.

Das Application Model

Eclipse 4 entstammt dem Inkubatorprojekt Eclipse E4, einem Projekt zur Verbesserung der Eclipse Platform. Es rationalisiert die besten Teile der 3.x APIs und löst gleichzeitig viele bekannte Probleme der RCP Entwicklung mit Eclipse 3.x.
In Eclipse 4 wird die Struktur einer Applikation über ein abstraktes Modell beschrieben, dem Application Model. Dieses beinhaltet sowohl die visuellen Elemente (z.B. Windows und Parts) als auch die nicht visuellen Elemente (z.B. Commands und Handler) der Anwendung. Das Application Model kann sowohl deklarativ während der Entwicklung, als auch während der Laufzeit verändert werden. Außerdem ist es möglich, das Model über Fragmente zu erweitern, die über Plug-ins hinzugefügt werden.

Neue Technologien

Eclipse 4 führt zudem neue Technologien ein, welche die RCP Entwicklung deutlich flexibler machen. Dies sind unter Anderem die Unterstützung von Dependency Injection und die Realisierung von API Definitionen über Annotations. Bei Eclipse 3.x müssen Komponenten wie Handler bestimmte Interfaces implementieren oder von abstrakten Klassen ableiten um ein gewünschtes Verhalten des Frameworks zu indizieren. Das koppelt die entsprechenden Klassen eng an das Framework und erschwert unter Anderem das framework-unabhängige Testen dieser. In Eclipse E4 werden API Definitionen durch Annotationen umgesetzt. Dadurch können z.B. Handler-Klassen als POJOs (Plain Old Java Object) realisiert und damit unabhängig getestet werden.

Einfache UI-Erstellung

Eclipse 4 ermöglicht außerdem das Stylen von UI-Widgets unter Einsatz von CSS. Ähnlich wie bei Webseiten kann so das Aussehen einer Applikation durch Austauschen der CSS-Dateien individuell angepasst werden, ohne dass der Quellcode der Applikation von Anpassungen betroffen ist. Dies kann auch während der Laufzeit passieren.
Eine weitere revolutionäre Verbesserung in Eclipse 4 ist die Entkopplung des Application Models von seiner Präsentationsschicht. Während Eclipse 3.x fest an SWT gebunden ist, sind unter Eclipse 4 andere UI-Toolkits wie z.B. Swing oder JavaFX zum Rendern der Oberfläche möglich.

Da Eclipse 4 ein anderes Programmiermodell verwendet als Eclipse 3.x, sind Eclipse 4 Applikationen nicht abwärtskompatibel. Die Eclipse 4 Platform stellt jedoch das sogenannte Compatibility Layer zur Verfügung. Hierbei handelt es sich um eine Komponente, welche die Schnittstellen der 3.x API auf die 4.0 API mappt und dadurch eine Verwendung von 3.x basierten Komponenten unter Eclipse 4 ohne jegliche Anpassungen ermöglicht.

Die aktuelle Version 4.2 von Eclipse 4 wurde im Juni 2012 unter dem Namen „Juno“ released. Eclipse 4 löst mit diesem Release Eclipse 3.x als Mainstream Platform für das Eclipse Projekt ab. Gebunden an den Eclipse Release Train kann auch in den kommenden Jahren jeweils im Juni mit dem Release der neuesten Version der Platform gerechnet werden. Damit ist sichergestellt, dass  Eclipse 4 auch in Zukunft eine stabile und etablierte Platform zur Entwicklung modularer Anwendungen sein wird.