Tomorrow Comes Today

Wer macht eigentlich die Website fertig? Also nicht nur die Entwicklung des Softwarecodes oder die Konfiguration von RealURl oder das grundsätzliche Layout - sondern eben richtig fertig. Typischerweise gibt bei frontendlastigen Projekten eine Menge an Kleinigkeiten zu beachten, welche bei der Umsetzung einzelner Anforderungen nicht direkt auffallen oder nicht im Fokus stehen. Aspekte wie “Zurück-Links” bei Suchmasken, Detailanzeigen oder komplexeren Use Cases, Locallang-Einträge der Benutzerregistrierung , Community-Funktionen, RealURL-Konfiguration für parametrisierte Plugins, Caching-Optimierung usw. usf. gibt es zu Tausenden und einige von diesen sind nach Abschluss der Entwicklung von allen Funktionalitäten noch offen.

Hierfür wird ein Finalizer gebraucht. Man könnte auch zunächst das Gesamtsystem unter allen Aspekten testen, die Testergebnisse dokumentieren, von einem Entwickler beheben lassen und anschließend erneut einen Test durchführen. Nur ist gerade bei den genannten letzten Dingen der Aufwand der Behebung zumeist nicht größer als der der Dokumentation.

Nach Abschluß der Entwicklungsarbeit sollte dann der “Finalizer” ans Werk gehen. Dieser muss einen Blick für die Anforderungen, das Design, die Usability und die Funktionalität haben und alle Issues beheben. Bei umfangreichen oder sehr komplexen Projekten könnte auch eine Art Pair-Programming von Finalizer und Entwickler sinnvoll sein. Das Vorgehen sieht dabei ähnlich wie bei einem Test aus - nur das die Issues sofort behoben werden. Ist der “Finailzer” fertig, dann ist wirklich die Zeit für abschließende strukturierte Tests gekommen. Interesse an dieser Tätigkeit, dann einfach eine E-Mail an jobs (at) form4.de schicken.

Als Unternehmen, welches individuelle Softwarelösungen entwickelt die mindestens mittelfristig oder langfristig eingesetzt werden sollen, gelangt man früher oder später an den Punkt, dass die einst sehr gute und aktuell noch produktiv eingesetzte Lösung nicht mehr mit einer vielversprechenden Perspektive weiterentwickelt werden kann. Aber warum eigentlich?

Der Bedarf des Kunden für diese Lösung ist meist unverändert vorhanden oder hat sich höchstens um verschiedene Aspekte erweitert, sei es dass zusätzliche Funktionen oder die Integration in andere Systeme benötigt wird. Hier kann also nicht das Problem liegen. Dies merkt man auch daran, dass der Kunde selbst eine Lösung gar nicht für veraltet ansieht. Sie löst ja alle Aufgaben nach wie vor und konnte in der Vergangenheit auch immer um weitere Aspekte erweitert werden. Also warum jetzt plötzlich nicht mehr?

(more…)

As we are planning and prototyping a new technology for web based business applications at form4, I am constantly looking for future proof components for not only the use case but the business case view.

So I started with a little research abount workflow engines like jBPM and ended up with BPEL and some articles about this language. Well, one interesting aspect is the business process perspective and a second is the independence of the implementation technology.

For some reasons we focus on MDA by using UML for modelling and Java J2EE for the runtime and so I was looking for engines which are able to supply those languages: UML -> BPEL -> J2EE. So I found some insteresting articles: MagicDraw is going to support BPEL, jBPM announced an alpha release of a BPEL support and something about BPEL vs. Java writte by BEA and IBM.

But still open: the prototype. But I had some tries with jBPM - for my desperation not that successful as expected, but I will give it another try.