Blog

MS-Access ade! Aus alt mach neu.

1.      Gründe / Ausgangslage

Mit MS-Access konnten vor 15 Jahren auf komfortable Art und Weise Anwendungen entwickelt werden, welche eine Datenbank, Logik und eine Benutzeroberfläche beinhalteten. MS-Access als Basis-Technologie wird von Microsoft nicht mehr unterstützt. Mit Windows 10 funktioniert es bereits heute nicht mehr. Offizielle Abkündigung von MS-Access 2010 ist im Oktober 2020.

Alte Datenbank MS-Access

Solche Anwendungen gibt es einige, sie sind viele Jahre alt, meist gibt es keine Dokumentation. Mit MS-Access war es schwierig, unterschiedliche Kundenwünsche unter einen Hut zu bringen. Eine gängige Lösung war, pro Kunde eine eigene MS-Access Lösung zu entwickeln. Was zur Folge hatte, dass der Aufwand in Bezug auf Releaseplanung und Durchführung überproportional stieg.

2.      Vorgehen

Die bestehende Anwendung ist ziemlich sicher noch im Einsatz und kann somit aus funktionaler Sicht (Use Cases) analysiert werden. Dabei geht es um die Hauptfunktionalitäten. Es wird sich kaum lohnen, sämtliche Funktionen bis ins Detail anzuschauen. Denn vielfach bietet sich die Gelegenheit, nicht (mehr) benötigte Funktionalitäten wegzulassen.

Ein Quervergleich mit dem Programmcode ist sinnvoll. Letztendlich liegt die Wahrheit im Programmcode! Eine kurze Analyse gibt zugleich einen Einblick bezüglich Komplexität. Allzu viel Zeit sollte nicht aufgewendet werden.

Danach macht es Sinn, ein Pflichtenheft zu erstellen. Wichtige technische Punkte sind Architektur (Web- oder Desktop-Anwendung) und Technologien (Java / .NET / PHP etc).

Die Kosten müssen auch berücksichtigt werden. Ist der Kunde bereit, zusätzliche Kosten zu tragen? Wie sieht die Konkurrenz aus? Parallel zur Erstellung des Pflichtenheftes kann eine Aufwandschätzung mit 10% Genauigkeit gemacht werden. Spätestens bei Vollendung des Pflichtenheftes muss klar sein, ob sich die Neuentwicklung lohnt.

Cloud Datenbank

3.      Checkliste

Folgende Checkliste hilft, dass keine wesentlichen Informationen verloren gehen:

  • Gibt es Dokumente (Handbuch, Benutzeranleitung, Code-Beschreibung).
  • Bei welchen Kunden kann die Anwendung im realen Betrieb angeschaut werden.
  • Läuft die komplette Anwendung inkl. Datenbank auf einem Entwicklungsrechner und kann dort analysiert werden.
  • Ist bekannt, bei welchen Kunden welche Version installiert ist.
  • Ist der Sourcecode für die verschiedenen Kunden vorhanden.
  • Welche Hauptfunktionalitäten gibt es, welche werden von den Kunden genutzt.
  • Welche Hauptfunktionalitäten braucht es nicht mehr.
  • Ist es möglich, die bestehenden Daten zu übernehmen / migrieren.
  • Gibt es Kunden, welche als Erste die neue Anwendung nutzen wollen / müssen. Eventuell muss nicht die gesamte Funktionalität von Anfang an entwickelt werden.
  • Braucht es einen Mockup, um möglichst früh ein Feedback der bestehenden Kunden einzuholen.
  • Müssen Mitarbeiter geschult werden, damit die Neuentwicklung selbst gemacht werden kann.

4.      Fazit

  • Eine Neuentwicklung bietet die Gelegenheit, die Kundenzufriedenheit zu erhöhen.
  • Architektur und Technologien sind wichtige Punkte für den längerfristigen Erfolg, siehe https://hyperformers.com/architektur-die-erfolgsbasis/.
  • Ev. ist eine interne Weiterbildung der Mitarbeiter nötig, weil das Wissen in Bezug auf die neuen Technologien noch nicht vorhanden ist. Das ist gleichzeitig die Chance, die Mitarbeiter auf den neusten Stand zu bringen, siehe https://hyperformers.com/weiterbildung-im-digitalen-zeitalter/.
  • Nach Möglichkeit einen Pilotkunden auswählen, der nicht die gesamte Funktionalität von Anfang an braucht.

Rasanter Technologiewandel – .NET Core mit Angular

Die Technologien ändern schneller und die Vielfalt nimmt zu. Muss man immer auf dem neusten Stand sein? Am Beispiel der Microsoft .NET Core Technologie im Zusammenspiel mit Angular werden konkrete Antworten für eine Webanwendung aufgezeigt.

Webanwendung Heute

Eine mögliche Architektur auf dem neusten Stand der Technik sieht wie folgt aus:

  • Benutzeroberfläche mit Angular 4
  • Geschäftslogik, Datenhaltung mit .NET Core 2
  • Einsatz eines Frameworks für den Datenbank-Zugriff, z.B. Dapper
  • Test der Schnittstellen zwischen Angular und .NET Core mit Postman
  • Vollständige Entkopplung zwischen Benutzeroberfläche und Logik

.NET Core ist open source und Plattform unabhängig (läuft z.B. auf Windows, Linux und Mac). Angular ist die am weitesten verbreitete Technologie für Benutzeroberflächen von Webanwendungen.

VR-Technologie

Der Lauf der Zeit

Vor 4-5 Jahren sah die Vorgänger-Architektur so aus:

  • Benutzeroberfläche mit Razor Views (Einsatz eines JavaScript-Frameworks wie jQuery)
  • Geschäftslogik, Datenhaltung mit ASP.NET MVC (Model View Control) 5
  • Einsatz eines Frameworks für den Datenbank-Zugriff, z.B. Dapper
  • Vollständige Entkopplung zwischen Benutzeroberfläche und Logik

Im Jahr 2013/2014 gab es Angular 1 bereits, steckte noch in den Kinderschuhen. Ab 2015 war AngularJS verfügbar. D.h. vor 4-5 Jahren war Angular im Zusammenspiel mit ASP.NET MVC kein Thema.

Muss es immer das (Aller)Neuste sein?

Diese Frage hängt von der Konstellation ab:

1) Entwicklung einer neuen Anwendung

Hier lohnt sich der Einsatz der neusten Technologien. Damit wird die Zeit bis zum nächsten Wechsel maximal verzögert. Zu beachten sind folgende Punkte:

  • Technologie / eingesetzte Version muss stabil sein
  • Es müssen auf Fremdprodukte vorhanden sein. Konkretes Beispiel: NHibernate war Anfang 2018 nicht für .NET Core 2 verfügbar.
  • Neben der Entwicklung muss auch das Hosting angeschaut werden. .NET Core ist viel komplizierter als ASP.NET MVC

2) Weiterentwicklung einer bestehenden Anwendung

Meist werden noch andere Fremdprodukte / Bibliotheken eingesetzt. Solange der Support für diese Produkte und Technologien gewährleistet ist, muss nicht auf die neuste Technologie gewechselt werden. Dies ist meist für einige Jahre gewährleistet. Ausser es gibt neue Funktionen, die von der Anwendung gebraucht werden.

Technologie Wandel

Technologie Wechsel

In unserem Beispiel betrifft der Wechsel zwei Technologien:

1) Razor Views -> Angular

Es sind komplett verschiedene Technologien. Der bestehende Code kann nicht verwendete werden. Die Benutzeroberfläche muss neu entwickelt werden. Das bedeutet meistens viel Aufwand.

2) ASP.NET MVC -> .NET Core

Das Grundkonzept der Controller (Ablauflogik) kann übernommen werden. Der Startup-Code und die Konfiguration sind verschieden. Ein Teil des bestehenden Codes kann verwendet werden.

Im Normalfall ist der Controller-Teil eher klein. Darum ist es nicht so wichtig, wie viel davon wiederverwendet werden kann.

Wichtig ist, dass die Geschäftslogik nicht im Controller integriert ist.

Fazit

  • Wird eine Anwendung neu entwickelt, lohnt sich der Einsatz der neusten Technologien. Es sollen stabile Versionen eingesetzt werden. Weiter muss geprüft werden, ob es die nötigen Fremdprodukte zu dieser Technologie gibt.
  • Bei einer bestehenden Anwendung gibt es keinen zeitlichen Druck, die neusten Technologien einzusetzen.
  • Bei einem Technologiewechsel muss meist die Benutzeroberfläche neu entwickelt werden. Das ist mit viel Aufwand verbunden.
  • Die Geschäftslogik MUSS technologie-neutral sein. In unserem Fall: Programmierung in C# ohne Verweise / Referenzen auf Angular oder spezifische .NET Core Bibliotheken. Auf diese Weise kann die Geschäftslogik mit jeder Technologie eingesetzt werden, auch für ein App.

Links

Architektur – DIE Erfolgsbasis

Software Architektur ist von zentraler Bedeutung und kann einfach erklärt werden. Ein Vergleich mit der Überbauung einer Siedlung ermöglicht Parallelen zur Software Architektur. Auch als technischer Laie können Sie die richtigen Fragen stellen und verstehen die groben Zusammenhänge.

Ein Blick in die Überbauung einer Siedlung

Als konkretes Beispiel betrachten wir die Überbauung einer neuen Siedlung mit Einfamilienhäusern (EFH) auf der grünen Wiese. Der Käufer kann zwischen 3 Varianten wählen:

  • 5 Zimmer EFH mit Flachdach, ohne Garage
  • 5 Zimmer EFH mit Giebeldach und Garage
  • 5 Zimmer EFH mit Giebeldach, Garage und Solaranlage für die Stromerzeugung

Architektur-Gebauede

Als Architekt stellt sich die Frage, ob diese 3 Varianten fix geplant werden oder ob ein Modulbaukasten besser wäre:

  • Auswahl Anzahl Zimmer (5 oder 6.5)
  • Mit / ohne Garage
  • Flachdach oder Giebeldach
  • Mit / ohne Solaranlage

Vergleich der beiden Varianten:

3 fixe Varianten Modulbaukasten
Einfacher komplexer
Schneller realisiert (falls keine Zusatzwünsche) Mehr Aufwand zu Beginn (= teurer)
Nicht flexibel: Neue Anforderungen führen zu neuen Varianten Einfacher erweiterbar, z.B. Anzahl Nasszellen wählbar

Mehr Varianten

Gefahr von zu vielen Varianten im Laufe der Zeit Gefahr von zu vielen (kleinen) Modulen, die Übersicht geht verloren

 

Der Architekt muss entscheiden, welche Flexibilität nötig ist resp. welche Rahmenbedingungen gegeben sind:

  • Soll der Kunde kaufen, was vordefiniert ist (Auswahl aus genau 3 Varianten)
  • Wie viele EFH sollen insgesamt gebaut resp. verkauft werden
  • Wann muss das erste EFH verkauft sein, wie lange darf es max. dauern, bis alle EFH verkauft sind
  • Wie viel darf ein EFH kosten: Ein Konkurrenzvergleich liefert wichtige Informationen

Die Zukunft kann niemand voraussagen. Die Wahl der richtigen / besseren Variante ist immer verbunden mit einer subjektiven Einschätzung der Zukunft.

Von den Bauwerken zur Software Architektur

Als Vergleich wird die Entwicklung einer Buchhaltungs-Software herangezogen. Die Siedlung entspricht der Buchhaltungs-Software, das EFH einem Kunden (privat oder geschäftlich).

Es gibt wieder 3 Varianten:

  • Light: Einfache Buchhaltung, nicht mandantenfähig, ohne MWSt, keine Schnittstellen zu anderen Systemen
  • Simple: Doppelte Buchhaltung, mandantenfähig, mit MWSt, keine Schnittstellen zu anderen Systemen
  • Advanced: Doppelte Buchhaltung, mandantenfähig, mit MWSt, Schnittstellen zu anderen Systemen

Buchhaltung

Als Modulbaukasten gibt es folgende Konfigurationsmöglichkeiten:

  • Einfache oder doppelte Buchhaltung
  • Mit / ohne MWSt
  • Mandantenfähig
  • Schnittstellen (z.B. Export von Buchungen im csv-Format)

Marketing / Verkauf müssen folgende Fragen beantworten:

  • Wie lange darf es max. dauern, bis eine erste Variante verkauft werden kann und wie hoch dürfen die Entwicklungskosten dafür sein
  • Welche Variante ist es: Light oder Simple? Die komplizierteste Variante wird selten als Erste umgesetzt.
  • Wann müssen die anderen Varianten bereit sein und wie hoch dürfen die Entwicklungskosten dafür sein
  • Sind weitere Varianten denkbar: Doppelte Buchhaltung, nicht mandantenfähig, ohne MWSt

Danach muss die Technik entscheiden, ob die fixen Varianten oder der Modulbaukasten umgesetzt werden.

Wechsel der Architektur

Ein Wechsel der Architektur ist kostspielig. Die Architektur der Software widerspiegelt sich in der Grundstruktur der Anwendung:

  • Eingesetzte Tools und Technologien
  • Struktur der Kernfunktionalitäten (Module, Ablauf, Daten)
  • Definition der Schnittstellen

Bei einem Wechsel müssen nicht alle Punkte betroffen sein. Jeder einzelne Punkt für sich alleine betrachtet kann mit Aufwand verbunden sein.

Technisch ist ein Wechsel machbar. Je später der Wechsel erfolgt desto teurer wird es. Sind z.B. schon Lizenzen für das Buchhaltungsprogramm verkauft worden, muss der technische Support sichergestellt werden. Diese Kunden sind nicht bereit, für eine neue Version, die keine neuen Funktionen beinhaltet, Geld zu bezahlen. Eine Migration dieser Kunden auf die neue Architektur kostet auf jeden Fall Zeit (und somit auch Geld).

Ein paar Tipps

  • Im Zweifelsfall einfach als kompliziert: Eine einfache Architektur ist übersichtlicher und leichter verständlich.
  • Nicht zu sehr in die Zukunft schauen: Es ist besser, nicht alle Eventualitäten von Anfang an zu berücksichtigen. Meist kommt es anders als zu Beginn gedacht. Was nicht von Anfang an gebraucht wird aber schon realisiert ist, kostet mehr und macht die Architektur komplizierter.
  • Sind die Module beim Modulbaukasten zu klein, besteht die Gefahr, dass die Architektur zu kompliziert ist. Jedes Modul hat Schnittstellen und kommuniziert mit den anderen Modulen. Je mehr Module es gibt, desto komplexer wird es. Vor lauter Bäumen sehen Sie den Wald nicht mehr. In diesem Fall können mehrere Module zu einem einzigen zusammengefasst werden.

Fazit

  • Parallelen zum Bauwesen erlauben, die Grundzüge einer Software Architektur besser zu verstehen und die richtigen Fragen als Laie zu stellen.
  • Es ist besser, mit einer (zu) einfachen Architektur zu starten und diese zu verfeinern als mit einer (zu) komplizierten.
  • Ein Wechsel der Architektur ist immer mit (hohen) Kosten verbunden und sollte vermieden werden.

Effiziente Software Begutachtung im Detail

Die 3 Kernbereiche Architektur, Schnittstellen und Fremdprodukte werden detaillierter untersucht. Als Grundlage dient der Überblick.

Dieser Teil ist Technik lastig und setzt Programmierkenntnisse voraus.

Geschäftslogik

Die Geschäftslogik muss in sich gekapselt sein. Dies bedeutet, dass sie nicht weiss, wie die Daten gespeichert werden. Sie weiss nur, dass es eine interne Schnittstelle zur Speicherung gibt. Wie die konkrete Umsetzung aussieht (File, Datenbank), darf die Geschäftslogik nicht wissen. Somit kann auf einfache Weise eine Oracle-Datenbank durch eine mySQL-Datenbank ersetzt werden.

Die Geschäftslogik darf auch nicht wissen, ob sie von einer Webanwendung oder einer Mobile App verwendet wird. Oder ob es beides miteinander gibt. Ist diese Trennung garantiert, kann die Benutzeroberfläche ausgetauscht oder es können neue Benutzeroberflächen hinzugefügt werden.

Diese Abhängigkeiten können einfach geprüft werden: Gibt es einen technischen Verweis (Import) zur Datenhaltung oder Benutzeroberfläche? Falls ja, gibt es ein Problem.

Business Logik

Datenhaltung

Die Datenhaltung kümmert sich nur um das Speichern, Suchen und Lesen von Daten. Je nach Anwendung können folgende Punkte wichtig sein:

  • Schnelle Suche von Daten in grossen Tabellen oder in mehreren Tabellen (sog. Joins)
  • Schnelle Speicherung von mehreren tausend Datensätzen auf einmal (sog. Bulk Insert)

Es ist möglich, dass die Geschäftslogik (teilweise) in der Datenbank in Form von Stored Procedures vorhanden ist. Aus Sicht der Wiederverwendbarkeit und des einfacheren Verständnisses bevorzugt der Autor eine Lösung im Programmcode (Java, C#).

Benutzeroberfläche

Jede Art der Benutzeroberfläche hat ihre Eigenheiten. Gemeinsam ist, dass es für jede Art Fremdprodukte gibt, welche die Entwicklungszeit verkürzen und die Qualität steigern. Wenn es sich nicht um eine ganz einfache Benutzeroberfläche handelt, sollte ein Fremdprodukt eingesetzt werden. Sonst wird das Rad nochmals erfunden.

Je nach eingesetztem Fremdprodukt drängt sich eine gewisse technische Struktur auf. Es ist wichtig, diese Struktur festzulegen und einzuhalten. Bei einer Webanwendung mit Angular ist eine Unterteilung in Module, Komponenten, Modelle und Services zwingend. Sonst ist der Code schwer verständlich und kaum erweiterbar.

Schnittstelle Programm

Schnittstellen

Folgende Punkte sind zu beachten:

  • Versionierung: Im Lauf der Zeit gibt es Erweiterungen der Schnittstelle. Jede Erweiterung kann zu Inkompatibilitäten bei den Benutzern (meist andere Programme) führen. Ändert die Datenstruktur, weil es z.B. zusätzliche Daten gibt oder bestehende Daten wegfallen, hat das Auswirkungen bei den Benutzern. Deshalb ist eine Versionierung der Schnittstelle wichtig: Mehrere Versionen werden gleichzeitig unterstützt. So entscheiden die Benutzer selber, wann sie die neue Version verwenden. Ohne Versionierung müssen alle Benutzer gleichzeitig wechseln.
  • Robustheit / Fehlertoleranz: Beim Bezug von Daten muss damit gerechnet werden, dass der Inhalt stark variieren kann. Manchmal gibt es Fehler und es werden nicht alle Daten geliefert. Wichtig ist, dass versucht wird, möglichst alle Daten heraus zu bekommen. Fehler sollen möglichst genau dem Benutzer gemeldet und in ein Logfile geschrieben werden.
  • Kapselung: Bei Problemen mit der Schnittstelle darf nicht die gesamte Anwendung betroffen sein (und nicht mehr funktionieren). Die Datenstruktur der Schnittstelle darf z.B. in der Geschäftslogik nicht bekannt sein. Sonst führen Anpassungen in der Datenstruktur auch zu Anpassungen in der Geschäftslogik. Daten und Methoden der Schnittstelle müssen gekapselt sein.

Komplexe Fremdprodukte

Die einfachen Fremdprodukte werden nicht analysiert, weil diese zu wenig wichtig sind.

Wird ein Fremdprodukt an vielen Stellen in der Anwendung eingesetzt, macht eine Kapselung Sinn. Das kann z.B. ein eigenes Modul fürs Lesen und Erstellen von Excel-Files sein. Innerhalb dieses Moduls wird das Fremdprodukt eingesetzt. Anpassungen (z.B. neue Version) beschränken sich nur auf das eine Modul. Das Fremdprodukt kann auf diese Weise einfacher ausgewechselt werden.

Zusammenfassung

Je nach Komplexität der Anwendung dauert die detaillierte Analyse 1-3 Wochen. Das Resultat sind konkrete Aussagen, was gut ist und was verbessert werden soll. Die Verbesserungsvorschläge beinhalten eine grobe Aufwandschätzung. Das ist für die Planung und das weitere Vorgehen wichtig.

Effiziente Software Begutachtung im Überblick

Haben Sie Ärger mit ihrem Software-Lieferanten oder möchten eine Aussage bezüglich Qualität ihrer Software? Mit ein paar Tagen Aufwand und der Pareto-Regel resultiert eine aussagekräftige Begutachtung. So wird’s gemacht.

Code Review

Die 3 wichtigsten Bereiche sind:

Architektur

Die Architektur resp. Struktur der Software ist von zentraler Bedeutung. Die meisten Anwendungen haben eine Benutzeroberfläche, bilden Firmenprozesse ab und speichern Daten. Dies ist eine sog. 3-Schichten-Architektur:

  • Benutzeroberfläche: Führt den Benutzer zielgerichtet zum gewünschten Ergebnis (Webanwendung, Desktop-Anwendung und/oder mobile Anwendung)
  • Geschäftslogik: Bildet die Firmenprozesse ab. Das Firmen-Wissen steckt in dieser Schicht. Dies ist der wichtigste Teil und muss wieder verwendbar sein.
  • Datenhaltung: Die Daten werden persistent gespeichert (Filesystem, Datenbank).

Die Struktur gibt einen ersten Hinweis auf die Granularität: Ist die Anwendung unterteilt in (zu) viele Unterprojekte oder gibt es ein riesiges Projekt, das alles beinhaltet.

Schnittstellen

Braucht die Anwendung Informationen von fremden Systemen oder liefert sie Informationen an fremde Systeme? Schnittstellen sind heikel. Es ist wichtig, dass diese gekapselt sind, damit Änderungen nicht die gesamte Anwendung betreffen. Und die Software muss robust resp. fehlertolerant sein.

Time for Code Review

Fremdprodukte

Um das Rad nicht neu zu erfinden, werden Fremdprodukte eingesetzt. Die Anzahl eingesetzter Fremdprodukte gibt einen Anhaltspunkt bez. Komplexität der Anwendung. Dabei unterscheide ich 2 Arten:

  • Komplexe Produkte wie z.B. eine Bibliothek zur Erstellung der Benutzeroberfläche oder zur Erstellung von Excel-Files ohne die Installation von Office.
  • Einfache Produkte wie z.B. ein Mapper (kopiert Daten von einem Objekt ins andere, hat keine Logik).

Für beide Arten gilt: Im Lauf der Zeit wird es neuere Versionen geben. Irgendwann muss auf eine neuere Version gewechselt werden. Dabei kann es passieren, dass die neue Version nicht mehr kompatibel ist und es zu einem ungeplanten Mehraufwand kommt. Oder ein Fremdprodukt wird abgekündigt und ein Ersatz muss gesucht werden.

Zusammenfassung

Je nach Grösse und Komplexität der Anwendung ist die grobe Analyse obiger Punkte in 1-3 Tagen gemacht. Das Resultat ist eine Liste mit Punkten zur detaillierten Abklärung.

Die technischen Details sind hier.

Excel-Anwendungen im Unternehmen – Gefahr oder Segen?

Excel bietet mehr als Tabellenkalkulationen: Charts, komplexe Berechnungen oder umfangreiche Formulare sind nur einige Beispiele. Excel ist weit verbreitet und der Quasi-Standard. Es braucht wenig Zeit, um eine Excel-Anwendung zu erstellen.

Neben Excel gibt es die Möglichkeit, massgeschneiderte, firmenspezifische Anwendungen zu entwickeln. Eine solche Anwendung bietet bei gewissen Einsatzgebieten Vorteile. Die Vor- und Nachteile der Ansätze werden gegenübergestellt. Eine Checkliste hilft, die richtige Wahl zu treffen.

 

Excel Anwendung

Checkliste

Die Features beziehen sich auf typische Anwendungen in KMU’s. Die Checkliste ermöglicht eine erste Einschätzung, ob eine Excel-, Desktop oder Webanwendung Sinn macht.

Feature Excel Desktop Webanwendung
Benutzer-führung / Usability Möglich
kann sehr aufwendig sein
Ja
Wizzard: Benutzer füllt Daten in vordefinierter Reihenfolge aus
Navigation: Hilft für  Überblick
Ja
Wizzard: Benutzer füllt Daten in vordefinierter Reihenfolge aus
Navigation: Hilft für  Überblick
Validierung Eingabedaten Möglich

kann sehr aufwendig sein

Ja

Z.B. mit Tooltips, Fehler-meldungen

Ja

Z.B. mit Tooltips, Fehler-meldungen

Benutzer muss jederzeit Zugriff haben Kaum möglich

Zugriff von privat meist unmöglich

Zugriff von mobilen Geräten meist nicht möglich

Kaum möglich

Zugriff von privat meist unmöglich

Zugriff von mobilen Geräten gar nicht möglich

Ja

Zugriff von privat OK

Zugriff von mobilen Geräten OK

Mehrsprachig Kaum möglich

Keine Unterstützung

Ja

Wird von allen gängigen Programmier-sprachen unterstützt

Ja

Wird von allen gängigen Programmier-sprachen unterstützt

Daten von Schnittstellen (extern) holen Kaum möglich Ja

Muss programmiert werden

Ja

Muss programmiert werden

Nachvollzieh-barkeit: Wer hat wann welche Eingaben gemacht Kaum möglich Ja

Muss programmiert werden

Ja

Muss programmiert werden

Integration in Office-Anwendungen Optimal Möglich

Muss programmiert werden

Möglich

Muss programmiert werden

Schutz von Firmen-Wissen Gering

Wer das Excel hat, kennt die Logik

Hoch

Quellcode ist für Aussenstehende nicht verfügbar

Hoch

Quellcode ist für Aussenstehende nicht verfügbar

Modularität: Gleiche Funktionalität nur 1x vorhanden Schwierig

Meist sind die einzelnen Excel-Files isoliert

Möglich

Muss vom Entwickler umgesetzt werden

Möglich

Muss vom Entwickler umgesetzt werden

Immer die neuste Version der Anwendung verwenden Nicht garantiert

Es zirkulieren alte Excel-Sheets

Garantiert.

Benutzer muss Update machen.

Garantiert

Passiert automatisch

Kompatibilität Aufwand gering

Aufwand für verschiedene Excel-Versionen

Aufwand gering

Aufwand für verschiedene Betriebssysteme

Aufwand mittel

Aufwand für verschiedene Browser

Aufwand für erstmalige Entwicklung Gering

Schnelle Fortschritte

Je umfang-reicher desto schwieriger

Mittel

Es braucht Abklärungen bez. Architektur / Struktur

Eher hoch

Es braucht Abklärungen bez. Architektur / Struktur

Hosting

Aufwand für Weiterent-wicklung Mittel

Ab einer gewissen Grösse / Komplexität unübersichtlich

Gering

Voraussetzung: Struktur passt

Gering

Voraussetzung: Struktur passt

Begriffserklärung für diesen Blog

Firmenspezifische Anwendung

Eine Anwendung ist ein Computerprogramm. Eine firmenspezifische Anwendung liefert auf spezifische Anwendungsfälle der Firma eine massgeschneiderte Lösung.

Mit welcher Technologie (Excel, Desktop, Webanwendung) die firmenspezifische Anwendung umgesetzt wird, spielt aus Sicht der Anwender keine Rolle.

Excel-Anwendung

Eine Excel-Anwendung besteht aus einem Excel-File (.xlsx oder .xls). Häufig braucht es Makros, welche mit VBA (Visual Basic for Applications) programmiert werden. Damit die Excel-Anwendung verwendet werden kann, muss Excel auf dem Gerät installiert sein.

Desktop Anwendung

Eine Desktopanwendung wird auf einem bestimmten Gerät (PC, Laptop) installiert. Eine Windows-Anwendung wird typischerweise als Desktopanwendung (exe-File) geliefert und muss vom Benutzer installiert werden.

Webanwendung

Eine Webanwendung braucht keine Installation. Es braucht lediglich einen Browser. Auf Webanwendungen kann auch von mobilen Geräten zugegriffen werden.

Zusammenfassung

Die Checkliste gibt eine erste Einschätzung. Fällt diese klar zugunsten einer Anwendungsart aus, sind keine weiteren Abklärungen nötig. Bei Unsicherheit kann es Sinn machen, zuerst die Excel-Anwendung (als Prototyp) zu erstellen. Zu einem späteren Zeitpunkt kann diese durch eine Desktop- oder Webanwendung ersetzt werden.

Marketing-Pragmatismus vs. Entwickler-Perfektionismus

Fürs Marketing zählen Features wie einfache Benutzerführung, Facts & Figures. Das sind Verkaufsargumente. Der Software-Entwickler achtet auf ein perfektes Design der Anwendung und auf ein solides Gerüst (Architektur). Die Anwendung muss einige Jahre «leben». Fürs Marketing ist eine schnelle und kostengünstige Lieferung wichtig. Der Software-Entwickler braucht Zeit (=Geld), die optimale Lösung zu finden. Willkommen im Spannungsfeld Pragmatismus vs. Perfektionismus.

Done is better than perfect

Marketing Sicht

Folgendes passiert, wenn die Anwendung vollständig aus Marketing Sicht entwickelt wird:

  1. Rasche Umsetzung der ersten Features. Die Kosten sind im budgetierten Rahmen.
  2. Der erste Release ist ein Erfolg. Es gibt mehrere zufriedene Kunden.
  3. Neue Kundenwünsche brauchen mehr Zeit für die Umsetzung als erwartet. Die Kosten steigen, die Termine können nicht mehr eingehalten werden.
  4. Die Kunden sind verärgert.

Entwickler Sicht

Folgendes passiert, wenn die Anwendung vollständig aus technischer Sicht entwickelt wird:

  1. Bestes Design & optimales Gerüst.
  2. Alle Eventualitäten und späteren Erweiterungen sind berücksichtigt.
  3. Die Anwendung ist zu 100% getestet, bevor sie freigegeben wird.
  4. Die Entwicklung dauert viel zu lange / wird nicht fertig und ist dementsprechend zu teuer.
  5. Die Anwendung kann nicht verkauft werden.

Kombinierte Sicht

Die Wahrheit liegt dazwischen:

  1. Gerüst und Design müssen passen. Damit sind Wartbarkeit und künftige Erweiterungen effizient möglich.
  2. Die Grundfunktionalität muss vorhanden und getestet sein.
  3. Danach muss möglichst schnell verkauft werden.
  4. Zusatzfunktionen werden später realisiert.
  5. Marketing und Entwicklung müssen miteinander sprechen.

Perfect or Progress

Ein paar Details zu obigen Punkten:

Gerüst und Design:

  • Grundsatzentscheide fällen, z.B. Web Anwendung oder Desktop Anwendung.
  • Existierende Programmier- und Architektur-Standards verwenden, z.B.  Angular 2, .NET Core, WPF mit MVVM.
  • Libraries / vorhandene Komponenten nutzen, z.B. für die Erzeugung von pdf-Files.
  • Richtige Umsetzung durch kompetente Entwickler, das Rad nicht neu erfinden.

Grundfunktionalität:

  • Der minimale Funktionsumfang muss durch das Marketing definiert werden.
  • Die Geschäftslogik wird mit sogenannten Unit Tests (automatische Tests) geprüft.
  • Die Benutzeroberfläche wird mit manuellen Tests geprüft.

Verkauf:

  • Die Entwicklungskosten müssen möglichst schnell gedeckt werden.
  • Je schneller verkauft wird, desto rascher gibt es ein Kundenfeedback.
  • Elementare Probleme werden so früh wie möglich erkannt. Grössere Probleme können vermieden werden.
  • Der Entwickler muss über seinen eigenen Schatten springen, weil manchmal die Zeit nicht reicht, eine Funktionalität technisch perfekt zu realisieren. Solange das Gerüst und das Design immer noch stimmen, ist das kein Problem.
  • Der Verkäufer muss über seinen eigenen Schatten springen, weil er nicht alle Features von Anfang an verkaufen kann.

Zusatzfunktionen:

  • Mittels agiler Entwicklung werden neue Features / Kundenwünsche rasch umgesetzt (Zyklen von 2- 3 Wochen)
  • Das Risiko wird minimiert, unnötige Features zu realisieren (die von Anfang an geplant aber nie gebraucht werden). Dies spart Kosten und Zeit.

Miteinander sprechen:

  • Missverständnisse zwischen Marketing und Entwicklung müssen vermieden werden. Dies kann teuer werden. Von Anfang an das Richtige entwickeln.
  • Keine Spezifikation ist 100% genau, es gibt immer Interpretationsspielraum. Wichtig ist, möglichst schnell etwas zeigen zu können.

Zusammenfassung

Eine erfolgreiche Anwendung entsteht, wenn Marketing und Entwicklung eng zusammenarbeiten. Eine gesunde Mischung aus Perfektionismus und Pragmatismus ist nötig, um den minimalen Funktionsumfang so rasch wie möglich zu realisieren. Dies ist die Basis für den langfristigen Erfolg.

Ärger mit ihren Software-Lieferanten?

Ein neues Projekt kommt nicht vom Fleck. Kleine Anpassungen sind zu teuer. Zum wiederholten Mal wird zu spät geliefert. Zu viele Beteiligte mit unklaren Kompetenzen. Kommt Ihnen das bekannt vor? Ein paar Tipps zur Abhilfe bei Ärger mit Software-Lieferanten.

Neue Projekte

Kommt ein neues Projekt nicht vom Fleck, gibt es verschiedene Gründe:

  1. Die Anforderungen sind nicht klar, unvollständig oder erst teilweise bekannt.
  2. Offeriert wird ein Ferrari, auch wenn ein VW Golf reicht.
  3. Zu komplizierter Prozessablauf mit zu vielen Diskussionsschlaufen.
  4. Zu hohe Kosten.
  5. Zu starker Fokus auf künftige Erweiterungen.

Beim 1. Punkt ist der Software-Lieferant in der Pflicht: Er muss nachfragen, damit er eine Anforderungsspezifikation sowie einen Mockup / Prototyp als Diskussionsgrundlage.

Jeder Software-Lieferant versucht, so effizient wie möglich zu sein. Werden verschiedene Anwendungen entwickelt, die eine gemeinsame Funktionalität haben, ist es sinnvoll, eine sog. Plattform zu entwickeln. Eine neue Anwendung ‘bekommt’ automatisch die gesamte Funktionalität der Plattform. Auf diese Weise können neue Anwendungen schneller entwickelt werden.

Die Gefahr vom Ferrari entsteht, wenn der Lieferant auf einer solchen Plattform aufbaut oder aufbauen muss. Wenn der Kunde nur einen Bruchteil der gesamten Funktionalität benötigt, bezahlt er dennoch den vollen Preis. Beim Einsatz einer proprietären Plattform ist es für den Kunden praktisch unmöglich, den Quellcode zu übernehmen und die Anwendung bei einem anderen Lieferanten weiter zu entwickeln. Ein späterer Wechsel des Lieferanten heisst, die Anwendung von Grund auf neu zu entwickeln.

Lieferanten-Stopp

Die Projektverantwortlichen des Lieferanten koordinieren die Software-Entwicklung. Sie müssen Einiges von IT resp. Software-Entwicklung verstehen. Sonst entsteht ein grosser Informationsverlust. Es ist wie beim Telefonspiel: Der Input beim ersten Glied (Projektleiter Kunde unterscheidet sich stark zum Output des letzten Glieds (Entwickler Lieferant). Jedes Glied, das weggelassen werden kann, reduziert den Informationsverlust.

Zu hohe Kosten entstehen, wenn ein Ferrari anstelle eines VW Golf geliefert wird. Oder die Entwickler etwas Falsches entwickeln, weil der Output beim letzten Glied falsch war. Hier hilft ein Hinterfragen der eingesetzten Produkte / Frameworks beim Lieferanten.

Sinnvoll ist es, künftige Erweiterungen von Anfang an in der Architektur zu berücksichtigen. Zu viel Gewicht sollte dennoch nicht beigemessen werden. Bei einem neuen Projekt ist es oft schwierig, mögliche Erweiterungen zu kennen.

Bestehende Projekte

Bei Ärger in einem bestehenden Projekt respektive einer existierenden Anwendung ist das primäre Ziel, mit dem Lieferanten einen Weg zu finden, um die Probleme zu lösen. Das ist am Einfachsten und Effizientesten. Ein Wechsel ist immer mit zusätzlichen Kosten und Zeitverlust verbunden und erst der letzte Ausweg.

Häufigste Probleme sind:

  1. Offerierte Kosten für die Weiterentwicklung sind zu hoch.
  2. Lieferverzug oder zu lange Lieferzeit.

Versteht der Kunde wenig von IT, lohnt sich der Einbezug eines Spezialisten in den Bereichen Architektur und Entwicklung. So können beim Lieferanten die richtigen Fragen gestellt werden. Es ist ein Gespräch auf Augenhöhe. Der Lieferant merkt, dass seine Aussagen und Offerten kritisch hinterfragt werden. Es ist vergleichbar mit dem Einholen einer ärztlichen Zweitmeinung.

Der Quellcode gehört dem Kunde. Ein Code-Review seitens Kunde hat folgende Vorteile:

  • Der Lieferant weiss, dass er keine überhöhten Aufwände offerieren kann.
  • Der Kunde hat einen Überblick über die Architektur und die Qualität der Software. Bei grösseren Mängeln ist ein Refactoring (Überarbeitung der Software bei gleicher Funktionalität) sinnvoll, besonders bei einem langfristigen Projekt.
  • Schwachstellen können behoben werden und künftige Lieferungen sind schneller und günstiger.

Um die Kosten für den Review so gering wie möglich zu halten, reicht meist eine grobe Übersicht.

Zusammenfassung

Sie haben folgende Möglichkeiten, Termine und Kosten ihres Software-Lieferanten in den Griff zu bekommen:

  • Klare Definition der Anforderungen, damit der Lieferant weiss, was er machen muss.
  • So wenig Ansprechpersonen wie möglich, damit die ursprüngliche Information möglichst unverändert bleibt.
  • Hinterfragen der eingesetzten Produkte / Frameworks, falls ein Lieferantenwechsel geplant ist.
  • Beizug eines Software-Spezialisten, um die richtigen Fragen zu stellen.
  • Durchführung eines Code-Reviews, um den Druck auf den Lieferanten zu erhöhen und sich einen Überblick über die Software-Qualität zu beschaffen.

Nachhaltige Verbesserung der Software

Hier erfahren Sie viel über ihre Möglichkeiten zur nachhaltigen Verbesserung der Qualität. Mit einfachen Massnahmen und der Pareto-Regel erzielen Sie einen maximalen Ertrag.

1.       Funktionalität

Die Funktionalität wird am besten aus einem Mix von Pflichtenheft, Visualisierung und Use Cases beschrieben, weil damit verschiedene Aspekte berücksichtigt werden.

Folgende Massnahmen bieten sich an:

  • Vollständigkeit, dazu gehören auch die nicht-funktionalen Anforderungen
  • Einfache Sprache, keine Fremdwörter, Erklärung der Begriffe
  • Review intern und mit Kunde: Beginn der Entwicklung erst nach Abnahme der Funktionalität!
  • Ablage der Informationen, sodass alle Projektmitarbeiter darauf Zugriff haben. Sind externe Mitarbeiter involviert, machen Cloud-Lösungen Sinn, z.B. Confluence.

2.      Performanz

Die kritischen Funktionen müssen möglichst früh umgesetzt werden, sodass diese gemäss den definierten Randbedingungen getestet werden können. Dies betrifft nicht nur die Performanz sondern das grundsätzliche Vorgehen bei einer Entwicklung.

Ist die Performanz ein kritischer Faktor und wird erst am Schluss gemessen, kann es böse Überraschungen geben. Im schlechtesten Fall muss die Architektur angepasst werden, was mit hohen Kosten und Terminverzug verbunden ist.

Software Qualität Verbesserung

3.      Benutzerfreundlichkeit

Jede Anwendung muss ein Logfile haben. Darin protokolliert die Anwendung beispielsweise, auf welche Buttons der Benutzer klickt. Damit kann ein Profil erstellt werden, wo sich der Benutzer wie lange aufgehalten hat und wo nicht.

Die Zielgruppe muss möglichst früh beim Testen involviert werden. Achtung: Die Anwendung muss stabil funktionieren, sonst ärgern sich die die Benutzer.

4.      Zuverlässigkeit

Ein zentraler Punkt für die Zuverlässigkeit ist das Testen der Anwendung. Dazu braucht es:

  • Ein Testkonzept, welches die Grundzüge und Ideen beschreibt. Software können Sie nie zu 100% testen.
  • Testfälle, um mit möglichst wenig Aufwand eine möglichst grosse Abdeckung zu erzielen.

Das Testkonzept und die Testfälle müssen vor Beginn der Umsetzung definiert werden. Sonst kann es passieren, dass Testfälle definiert werden, die nicht getestet werden können. Das kann unter Umständen verheerend sein.

5.      Wartbarkeit

In seltenen Fällen ist eine Anwendung von Anfang an wiederverwendbar und modular. Meist besteht Zeitdruck und der Fokus liegt auf der Funktionalität. Das ist normal. Aus diesem Grund muss Zeit fürs Refactoring eingeplant werden: Der Code wird später so modularisiert, dass die bestehende Funktionalität nicht ändert.

6.      Zusammenfassung

Mit diesen einfachen und kostengünstigen Massnahmen wird die Qualität erheblich gesteigert:

  • Vollständigkeit und Review der Anforderungen
  • Kritische Funktionen möglichst früh umsetzen und testen
  • Benutzer der Zielgruppe müssen möglichst früh mit der Anwendung arbeiten / testen
  • Testkonzept und Testfälle vor Beginn der Umsetzung definieren
  • Regelmässig Zeit fürs Refactoring planen

 

Qualität ja – genau so viel, wie nötig!

Qualität in der Software Entwicklung ist wichtig und kann gemessen werden. Verschiedene Faktoren beeinflussen die Qualität. Je nach Anwendung ist nicht jeder Faktor gleich wichtig. Eine Online-Banking Anwendung hat andere Qualitätsfaktoren als eine Vereinsbuchhaltung. Bei allen Anwendungen gibt es bezüglich Qualität eine Gemeinsamkeit: Nur so viel Qualität wie nötig!

Qualitätssteigerung in der Software Entwicklung

In Anlehnung an ISO 25010 gibt es 8 Merkmale:

  • Funktionalität: Sind alle Funktionen vorhanden und korrekt umgesetzt.
  • Performanz: Sind die Antwortzeiten genügend schnell und ist der Ressourcenverbrauch OK.
  • Kompatibilität: Auf welchen Betriebssystemen, Browsern muss es funktionieren.
  • Benutzerfreundlichkeit: Kann der Benutzer die nötigen Aufgaben in nützlicher Frist lösen.
  • Zuverlässigkeit: Wie fehlertolerant ist die Anwendung, gibt es Abstürze.
  • Sicherheit
  • Wartbarkeit: Wie einfach können neue Funktionen umgesetzt werden.
  • Portierbarkeit

Der Fokus liegt in diesem Blog bei kleineren Anwendungen. Da sind Funktionalität, Performanz, Benutzerfreundlichkeit, Zuverlässigkeit und Wartbarkeit am Wichtigsten. Die Merkmale müssen als Ganzes beurteilt werden, da sie sich gegenseitig beeinflussen können.

In einem ersten Schritt wird beschrieben, wie die Qualität dieser fünf Merkmale gemessen werden kann. In einem zweiten Schritt geht es darum, die Qualität als Ganzes zu verbessern.

Qualitätsmessung

Die Qualität kann nicht immer absolut gemessen werden. Darum macht es Sinn, sog. Qualitätsfaktoren zu definieren und diese zu bewerten oder zu messen.

Time-Cost-Quality

1.      Funktionalität

Damit die Funktionalität gemessen werden kann, muss diese beschrieben sein. Dazu gibt es verschiedene Möglichkeiten:

  • Pflichtenheft mit funktionalen und nicht-funktionalen Anforderungen
  • Prototyp / Mockup (Visualisierung)
  • Anwendungsfälle (Use Cases)

Je detaillierter die Beschreibung, desto einfacher ist die Messung resp. Überprüfung. Eine Kombination dieser Möglichkeiten ist sinnvoll.

2.      Performanz

Typischerweise werden die Antwortzeiten verschiedener Funktionen definiert. Wichtig sind die Randbedingungen: Wie viele Benutzer führen die Funktion gleichzeitig aus, wie gross ist die Datenmenge etc.

Beispiel: Das Lesen aller Hotel-Reservationen eines einzelnen Tages muss < 0.5 sec dauern.

Randbedingungen: 5 Benutzer gleichzeitig, die Datenmenge besteht aus 2000 Hotel-Reservationen.

Die Datenmenge kann einen erheblichen Einfluss auf die Antwortzeit haben. Sind nur 10 Hotel-Reservationen vorhanden, ist die Antwortzeit kürzer als bei 2000.

3.      Benutzerfreundlichkeit

Es gibt viele Möglichkeiten, die Benutzerfreundlichkeit (Usability) zu messen. Diese sind teilweise aufwändig und teuer.

  • Der Benutzer wird beobachtet, entweder im Labor oder in der richtigen Arbeitsumgebung. Beim Eye-Tracking wird geschaut, welchen Bereichen der Benutzeroberfläche am meisten Beachtung geschenkt wird.
  • Inspektion durch Experten, Überprüfung auf Normkonformität und allgemein anerkannte Richtlinien und Standards.
  • Fragebogen an Benutzer abgeben.
  • Mündliche Befragung (Interview).
  • Der Benutzer denkt bei der Durchführung laut und äussert so seine Gedanken und Gefühle.
  • Auswertung der Logfiles, z.B. Verweildauer, Navigationswege.

Daraus lassen sich sogenannte Metriken ableiten:

  • Effektivität: Anteil erfüllter Aufgaben x Erfüllungsgrad der Aufgaben
  • Effizienz: Effektivität / Aufgewendete Zeit
  • Benutzerzufriedenheit: Subjektive Eindrücke der Benutzer, statistisch ausgewertet
  • Anzahl Hotlineanrufe, Tickets

4.      Zuverlässigkeit

Verfügbarkeit, Fehlertoleranz und Wiederherstellbarkeit bilden als Ganzes die Zuverlässigkeit.

Die Verfügbarkeit kann einfach gemessen werden: Gesamtzeit – Ausfallzeit / Gesamtzeit.

Bei einfacheren Anwendungen entspricht die Fehlertoleranz der Robustheit der Benutzeroberfläche und/oder der Schnittstellen:

  • Ungültige / fehlende Eingaben bei Benutzeroberflächen dürfen zu keinem Fehler / Absturz führen.
  • Ungültige / fehlende Daten, welche über eine Schnittstelle bezogen werden, dürfen zu keinem Fehler / Absturz im nachfolgenden Ablauf führen.

Eine einfache Möglichkeit zur Messung der Fehlertoleranz besteht darin, die möglichen Eingabefehler / Schnittstellenfehler zu spezifizieren und zu testen.

Wiederherstellbarkeit bezeichnet die Fähigkeit, die Bereitstellung zu dem Punkt wiederherzustellen, zu dem ein Ausfall erfolgt ist. Die Fähigkeit zum schnellen Wiederherstellen nach einem Systemausfall erfordert nicht nur die Verfügbarkeit aktueller Sicherungen der Daten. Vielmehr muss auch ein Plan vorhanden sein, um diese Daten auf neuer Hardware wiederherstellen zu können.

Gemessen wird die Zeit, die es braucht, um das System auf der laufenden oder neuen Hardware wiederherstellen zu können.

Software-Quality-Management

5.      Wartbarkeit

Wiederverwendbarkeit, Modularität, Testbarkeit und Änderbarkeit bilden als Ganzes die Wartbarkeit. Letztendlich geht es darum, wie einfach eine bestehende Anwendung durch neue Funktionen erweitert werden kann. Die einzelnen Teile beeinflussen sich gegenseitig: Eine modulare Anwendung ist mit grosser Wahrscheinlichkeit besser testbar.

Bei Wiederverwendbarkeit geht es hier um Module. Ein Modul bietet eine in sich geschlossene Funktionalität an. Ein Modul kann innerhalb der gleichen Anwendung oder in verschiedenen Anwendungen wiederverwendet werden. In welchen Anwendungen ein Modul eingesetzt wird, kann meist durch Referenzen auf dieses Modul festgestellt und somit gemessen werden.

Modularität ist wie ein Baukasten. Im Idealfall werden aus dem Baukasten die einzelnen Module ausgewählt und miteinander verbunden / verlinkt. Modularität allein zu messen macht wenig Sinn. Stattdessen ist die Modularität Bestandteil der Wiederverwendbarkeit.

Die Testbarkeit wird indirekt gemessen resp. hängt vom Testaufwand ab. Je geringer die Testbarkeit, desto grösser der Testaufwand.

Die Änderbarkeit ist ein Mass dafür, wie schnell, fehlerfrei und einfach eine Änderung gemacht werden kann. Letztendlich wird die Zeit gemessen, welche dafür nötig ist. Ein absoluter Vergleich ist schwierig. Ist der Kunde bereit, die benötigte Zeit zu bezahlen, ist die Änderbarkeit gut. Nach mehreren Änderungen ist ein Trend ersichtlich.

6.      Zusammenfassung

Qualität wird wie folgt gemessen:

  • Funktionalität: Vergleich mit Pflichtenheft, Prototyp, Use Cases
  • Performanz: Messung von Antwortzeiten bestimmter Funktionen
  • Benutzerfreundlichkeit: Effizienz, Benutzerzufriedenheit, Hotline Anrufe
  • Zuverlässigkeit: Ausfallzeit, Wiederherstellungszeit, Spezifikation möglicher Fehler und Test
  • Wartbarkeit: Testaufwand, Zeit für Änderungen, Anzahl Wiederverwendungen / Modul

Im nächsten Beitrag werden die Möglichkeiten zur Verbesserung der Software Qualität beschrieben.

Weiterführende Links:

Qualitätsmerkmale von Software

Innovative Ideen umsetzen

Sie haben innovative Ideen und sehen grosses Potenzial. Sie wissen nicht, wie Sie diese Ideen erfolgreich umsetzen können? Dieser Beitrag zeigt einen schematischen Ablauf und mögliche Stolpersteine.

Innovative Ideen im Kopf

Die Idee im Kopf muss niedergeschrieben werden. Dadurch findet eine erste Präzisierung statt. Die Idee wird hinterfragt. Mehr als eine Seite (auf Papier) ist nicht nötig. Am besten zeigen Sie die Idee jemandem, der kein Fachspezialist ist. So ist sichergestellt, dass die Beschreibung verständlich ist und die erste Rückmeldung erfolgt.

Zu diesem Zeitpunkt macht eine kritische Beurteilung noch keinen Sinn. Diese muss vor der Umsetzung erfolgen.

Innovation
Innovation

Konkretisierung mit Visualisierung

Die Idee allein genügt noch nicht. Es braucht eine Konkretisierung sowie Marktabklärungen. Es ist nebensächlich, ob diese beiden Schritte nacheinander oder miteinander gemacht werden.

Ein Bild sagt mehr als 1000 Worte. Das trifft auch hier zu. Eine Visualisierung der Idee ist verständlicher als Text. Die meisten Software Anwendungen haben eine Benutzeroberfläche. Eine rudimentäre Erstellung der verschiedenen Dialoge inkl. Navigation hilft ungemein, sich ein Bild der Idee machen zu können. Spätestens jetzt wird es zu wertvollen Diskussionen kommen: Wie ist das gemeint? Braucht es das?

Es gibt verschiedene Tools, um sog. Wireframes / Mockups zu erstellen. Wir setzen seit Jahren WireframeSketcher ein: Das Aussehen kann je nach Anwendungstyp (Mobile App, Webanwendung, Desktopanwendung) angepasst werden. Zudem kann die Visualisierung in die Cloud geladen und mit anderen Personen geteilt werden. Kommentare sind auch möglich, sodass eine interaktive Beurteilung möglich wird.

Marktabklärungen

Marktabklärungen sind unumgänglich. Die Umsetzung kostet Geld, es ist eine Investition. Einfache Marktabklärungen sind dank Google möglich:

  • Gibt es das Produkt bereits
  • Falls ja, zu welchem Preis und in welchen Ländern
  • Falls nein, gibt es ähnliche Produkte
  • Wie gross ist das Marktpotenzial, wieviel davon kann in etwa genutzt werden

Ein grosser Stolperstein ist das Zurechtbiegen der Abklärungen, damit sich die Umsetzung lohnt. Wenn Sie die Umsetzung schon gestartet und Zeit resp. Geld investiert haben, fällt ein späterer Abbruch umso schwerer.

Grundlage für den Entscheid sind vollständige Marktabklärungen. Was heisst vollständig? Die Marktabklärungen sollte nicht nur der Ideenlieferant, sondern mind. eine zusätzliche Person machen, z.B. der Begutachter der Idee. Der Ideenlieferant sucht in Google ganz anders als eine neutrale Person. Oft sind die Stichworte des Ideenlieferanten zu spezifisch, was unabsichtlich zu einer einseitigen Abklärung führt.

Market Research, Google
Market Research

Entscheid, Umsetzung

Fällt der Entscheid zugunsten der Umsetzung aus, geht es los. In einer kleineren Firma gibt es meist folgende Randbedingungen:

  • Wenig Budget
  • Wenig Zeit
  • Verkauf des Produkts so rasch wie möglich

Aus diesen Gründen ist eine agile Vorgehensweise sinnvoll. Sie müssen einen minimalen Funktionsumfang definieren. Danach können Sie das Produkt verkaufen. Vorteilhaft sind Testkunden, denen das Produkt schon vorher geliefert werden kann.

Der Vorteil liegt auf der Hand: Je kleiner der minimale Funktionsumfang ist, desto schneller kann verkauft werden und desto schneller wird ersichtlich, ob das Produkt überhaupt rentiert.

Eine neu entwickelte Anwendung wird zu Beginn ein paar Kinderkrankheiten haben: Erfahrungsgemäss dauert die Entwicklung länger als geplant und der Termindruck ist gross. Darum muss nach der Einführung genügend Zeit für die Fehlerbehebung eingeplant werden. Eine kurze Reaktionszeit ist bei einem neuen Produkt sehr wichtig.

Fazit

Damit innovative Ideen erfolgreich umgesetzt werden können, braucht es:

  • Eine Konkretisierung der Idee auf max. 1 Blatt Papier
  • Eine Visualisierung der Idee inkl. Marktabklärungen
  • Eine kritische Beurteilung
  • Eine agile Umsetzung: Mit möglichst geringem Aufwand so rasch als möglich verkaufen

Mögliche Stolpersteine:

  • Keine (kritische) Beurteilung durch eine aussenstehende Person
  • Unvollständige Marktabklärungen / Zurechtbiegen der Marktabklärungen
  • Keine Etappierung der Umsetzung: Alles auf einmal
  • Schlechte Qualität und zu lange Reaktionszeit bei Problemen

Weiterbildung im digitalen Zeitalter

Weiterbildung ist wichtig und nötig. Qualifizierte Mitarbeiter sind unentbehrlich. Die Halbwertszeit des Wissens wird immer kürzer. Obwohl diese Tatsachen bekannt sind, hapert es oft bei der Umsetzung. Stete Weiterbildung im digitalen Zeitalter ist gefragt.

Wir befinden uns im digitalen Zeitalter, Industrie 4.0 ist in aller Munde. Den digitalen Wandel können wir nicht aufhalten, aber wir können ihn mitgestalten. Um längerfristig konkurrenzfähig zu bleiben, ist agieren (mitgestalten) gefragt. Unsere hohen Lohnkosten können wir z.B. durch eine schnellere Lieferung, bessere Qualität oder durch Einmaligkeit (der Erste sein) wettmachen. Damit dies möglich ist, braucht es gut qualifizierte Mitarbeiter auf allen Ebenen.

Weiterbildung im digitalen Zeitalter
Weiterbildung im digitalen Zeitalter

Weiterbildung kann auf verschiedene Arten erfolgen.

Zeitschriften, Fachartikel

Das ist am günstigsten. Ein regelmässiges Lesen von Zeitschriften hilft, künftige Trends erkennen zu können. Die Erkenntnisse werden im Team diskutiert, um eine möglichst breite Abstützung zu haben. Die Gefahr besteht, das Gelesene zu vergessen ohne es anzuwenden.

Knowhow-Transfer in der Firma

Wenn das Wissen in der Firma besser verteilt ist, erhöht sich die Flexibilität. Eine Firma hat z.B. 3 Entwickler. Der erste ist ein Datenbank Spezialist, der zweite programmiert Benutzeroberflächen und der dritte programmiert Geschäftslogik. Wenn jeder Entwickler nebst seinem Kerngebiet noch ein zweites Gebiet beherrscht, können diese Entwickler effizienter eingesetzt werden.

Das Erarbeiten des nötigen Wissen braucht Zeit und Geld. Ein erprobter Weg ist die Betreuung durch den Spezialisten. Dabei ist es wichtig, von Anfang an konkrete Aufgaben zu lösen. Ein theoretisches Einarbeiten durch das Studium vieler Dokumente ist wenig abwechslungsreich und langweilig.

Zu Beginn wird viel mehr Zeit benötigt, um eine Arbeit zu erledigen. Der Spezialist investiert Zeit in die Betreuung und der Lernende muss sich einarbeiten und sich im neuen Thema zurechtfinden. Mit der Zeit reduziert sich der Betreuungsaufwand merklich. So kann beispielsweise eine Stellvertretung in den Ferien erfolgen. Eine ungleichmässige Auslastung der Mitarbeiter kann so geglättet werden.

Mitarbeiter Skills
Mitarbeiter Skills

Lehrgänge, Studium

Es gibt verschiedene Lehrgänge und Studien an Höheren Fachschulen (HF) und Fachhochschulen (FH). Darauf wird nicht näher eingegangen, da es den Rahmen dieses Beitrages sprengen würde.

On the Job

Training on the job ist heute selbstverständlich. Ein Mitarbeiter kommt früher oder später in eine Situation, wo das eigene Wissen nicht mehr ausreicht. Er muss sich neues Wissen bei einer konkreten Aufgabe aneignen. Google sei Dank.

Wichtig ist, dass eine Kontrolle stattfindet. Die gleiche Aufgabe kann auf verschiedene Arten gelöst werden und meist gibt es (zu) viele Möglichkeiten. Die Vor- und Nachteile müssen bekannt sein. Sonst besteht die Gefahr, dass die Lösung alles andere als optimal ist und die Probleme später auftreten, z.B. bei der Wartbarkeit.

Firmenkurse

Das ist die optimale Möglichkeit, einzelne Mitarbeiter gezielt weiter zu bilden. Diese sollten immer konkrete Projekte / Probleme der Firma behandeln. Dadurch ist der Lerneffekt am grössten, weil der Mitarbeiter etwas Neues lernt und es sogleich anwenden kann. Ob sich ein Firmenkurs (finanziell) lohnt, hängt von der Anzahl Teilnehmer und der Dauer ab. Die direkten Kosten sind meist höher als bei einem externen Kurs, dafür ist der Nutzen umso höher.

Externe Kurse

Externe Kurse gibt es praktisch zu jedem Thema. Die Schwierigkeit liegt darin, den richtigen Kurs mit dem richtigen Schwierigkeitsgrad zu finden. Über- und Unterforderung bringen wenig. Die Umsetzung des Gelernten in der Firma ist meist schwieriger als bei einem Firmenkurs. Dafür gibt es einen Austausch zwischen den Teilnehmern, der nicht zu unterschätzen ist.

Fazit

Wie so oft im Leben gibt es nicht die richtige oder die einzige Art der Weiterbildung. Eine Kombination ist meist sinnvoll. Welche Arten genutzt werden, hängen primär von der Qualifikation / Selbständigkeit der Mitarbeiter und den finanziellen Möglichkeiten der Firma ab. Wichtig ist, dass eine gezielte Weiterbildung erfolgt. Nichts tun und abwarten ist die falsche Strategie.

Weiterführende Links

Weiterbildung Höhere Fachschule Uster

Firmenkurse Hyperformers

Web Frameworks mit JavaScript und HTML5

Kennen Sie Web Frameworks mit JavaScript und HTML5? Sprechen Sie AngularJS, Ionic, jQuery, Kendo UI, MooTools oder Wakanda? Verstehen Sie Foundation, Gumby, Yaml, MontageJS, Bootstrap oder HTML Kickstart? Alles klar oder besteht Erklärungsbedarf? Es handelt sich um JavaScript und/oder HTML5-Frameworks.

Web Frameworks mit JavaScript und HTML5
Bootstrap

Bootstrap

Gut, jetzt sprechen wir Bootstrap. Der Einsatz dieses Frameworks verspricht einiges:

  • Geeignet für alle Personen (Anfänger – Experte)
  • Für alle Web-Anwendungen (von der einfachen statische Seite bis zur komplexen Verknüpfung mehrerer dynamischer Seiten)
  • Ideal für alle möglichen Geräte, insbesondere auch mobile Geräte wie Smartphone und Tablet
  • Diverse vorgefertigte Komponenten – ready to use

Als Anfänger freue ich mich, dass ich dieses Super-Framework einsetzen und so die Produktivität von Anfang an massiv steigern kann. Auf der Einstiegsseite kommen Begriffe wie CSS, Präprozessor, Less, Sass und Plugin vor. Wie war das mit dem Anfänger? Sich nur nicht entmutigen lassen und in die Welt vom Web-Engineering eintauchen!

Mit CSS (Cascading Stylesheet) wird die Darstellung von HTML-Elementen gemacht. Die Grundidee ist die Trennung von Inhalt (HTML) und Gestaltung (CSS). Auf diese Weise können Layout, Farben, Typographie und Animationen definiert werden. Gewisse Attribute können vererbt werden, müssen also nicht jedes Mal neu definiert werden. Ein zentraler Punkt für mobile-fähige Websites: Mit CSS können für verschiedene Ausgabemedien (PC, Smartphone, Tablet) unterschiedliche Darstellungen vorgegeben werden.

CSS3Less ist ein sog. CSS Präprozessor. Dieser bietet zusätzliche Funktionalität wie Variablen. Variablen kenne ich als Programmierer und freunde mich mit CSS immer mehr an. Mit Hilfe von Variablen können Farben, Font Eigenschaften etc. zentral gespeichert werden.

Sass (Software as a service) ist ein allgemeines Konzept bei der Software-Entwicklung. Für meine einfache Webseite brauche ich das zum Glück nicht.

Wie funktioniert es mit dem jQuery Plugin? Was hat jQuery mit Bootstrap zu tun? jQuery ist ein Framework, welches zusammen mit Bootstrap verwendet werden kann. jQuery plugins sind gekapselte Funktionalitäten, welche mit jQuery implementiert sind. Ich bin begeistert: es stehen unzählige Funktionalitäten zur Verfügung, welche ich nicht selber implementieren muss. Eines habe ich schon gelernt: ein neues Framework bedeutet viel Arbeit. Also beschliesse ich, im Moment auf jQuery plugins zu verzichten.

jQuery Carousel
jQuery Carousel

Erste Erfahrungen

Mittlerweile habe ich schon viel Zeit verbracht, um mir diese Informationen zu beschaffen. Geschafft, denke ich und starte voller Elan mit meinem ersten Projekt: Eine einfache statische Webseite, um erste Erfahrungen mit Bootstrap zu sammeln. Ich wollte absichtlich kein bestehendes Beispiel anschauen sondern von Beginn weg etwas selber machen. Schliesslich wollte ich etwas lernen. Gelernt habe ich mehr als ich wollte. Nicht unbedingt gewollt. Der Reihe nach:

  • Der Download der aktuellen Version hat geklappt (kompiliert mit minified CSS, JavaScript und Fonts).
  • Mit welchem Tool erstelle ich die Webseite? Notepad oder eine komfortable IDE? Da ich nicht viel Zeit verlieren wollte, entschied ich mich für Notepad. Was ich erst später bemerkte: eine Validierung der HTML-Tags sowie eine optisch (farbliche) Kennzeichnung ist nicht möglich. Das wäre sehr hilfreich gewesen, besonders als Anfänger.
  • Wie wird Bootstrap eingebunden, wo müssen die Files gespeichert sein? Wie funktioniert es mit relativen Pfaden? Auf Anhieb hat es nicht geklappt.

jQuery UI Bootstrap
jQuery UI Bootstrap

Schlussendlich habe ich es geschafft, eine statische Seite mit Bootstrap zu erstellen. Ohne Framework wäre es wesentlich schneller gegangen. Rückblickend kann ich sagen:

  • Damit ein Framework (ob JavaScript oder HTML) richtig eingesetzt werden kann, sind Grundlagenkenntnisse in JavaScript, HTML5 und CSS nötig.
  • Jedes Framework, das neu eingesetzt wird, erfordert am Anfang (viel) Zeit.
  • Längerfristig lohnt sich der Einsatz eines Frameworks.

Weiterführende Links:

Model View Control – für einmal anders

model view controlWem der Begriff Model bekannt ist, hat auch schon eines oder mehrere davon gesehen (View). Doch wie verhält es sich mit dem Controller? Hat das etwas mit Buchhaltung zu tun?

Begriffe

Weit gefehlt: MVC (oder Model View Controller) ist ein Begriff aus der Software-Entwicklung. Es gibt unzählige Erklärungen und Beschreibungen. Die Kernpunkte können wie folgt zusammengefasst werden:

  • In der Geschäftslogik (oder Businesslogik) einer Anwendung steckt das Know-How. Diese Logik muss wiederverwendbar sein. Sie ist unser Model.
  • Die nackten Resultate der Geschäftslogik müssen auf verschiedenen Endgeräten dargestellt werden. Das sind unsere Views.
  • Damit das Model weiss, was es machen muss und die View stets die aktuellen Daten bekommt, braucht es einen Controller. Der Controller ist somit das Bindeglied zwischen Model und View.
  • Dank dieser Kapselung haben z.B. Änderungen in der View keinen Einfluss aufs Model. Der Testaufwand reduziert sich entsprechend.

Diese Grundlagen reichen bereits, um ein konkretes Beispiel anzuschauen. Die Steuerersparnis beim Einzahlen in die 3. Säule und die Kapitalsteuern bei deren Bezug sind kantonal unterschiedlich.

Model View Control
Model View Control

Aufgaben View

  • Eingabe aller benötigten Daten: Steuerbares Einkommen und Vermögen, Einzahlung und Kapital 3. Säule, Auswahl Kanton
  • Buttons für die gewünschten Aktionen: Werte berechnen oder Eingabe löschen
  • Anzeige der berechneten Daten: Steuerersparnis und Kapitalsteuern

Aufgaben Controller

  • Erkennen der Aktionen, z.B. Werte berechnen
  • Auslesen und konvertieren der Eingabedaten
  • Übergabe der Daten ans Model und Start der richtigen Berechnung(en)
  • Übergabe der berechneten Werte an die View

Aufgaben Model

  • Berechnung Steuerersparnis für alle Kantone
  • Berechnung Kapitalsteuern für alle Kantone

Designaspekte

Wie zu Beginn erwähnt, steckt im Model unser Know-How. Es lohnt sich also, beim Design ein paar Punkte zu berücksichtigen:

  • Das Model rechnet immer mit typisierten Werten (z.B. Integer, Double). Liegen die Eingabedaten als String vor, müssen diese vorgängig vom Controller konvertiert werden.
  • Die Validierung der Eingabedaten (sind alle Mussfelder ausgefüllt, wurden gültige Zahlen eingegeben) geschieht in der View oder im Controller, nicht aber im Model selbst.
  • Die Validierung von Grenzwerten (Einzahlung 3. Säule >= 0) kann im Model oder Controller erfolgen. Wenn einzelne Werte von anderen abhängig sind, kann die Validierung nur im Model gemacht werden.
  • Die Schnittstelle zur Berechnung der Steuerersparnis und der Kapitalsteuern ist für alle Kantone gleich, die Implementierung für jeden Kanton unterschiedlich. Daher drängt sich die Definition eines Interfaces auf. Ein Beispiel mit Java:

Sauele3a Interface
Sauele3a Interface

Anhand der folgenden Beispiele wird klar, warum eine solche Trennung Sinn macht:

  • Maximalbetrag für Einzahlung ändert jedes Jahr: betroffen ist nur das Model resp. die konkreten Implementierungen der einzelnen Kantone. In der View und im Controller ändert nichts. Somit muss nur das Model getestet werden.
  • Die aktuelle View ist mit Swing (Java) realisiert. Die Anwendung soll im Internet zur Verfügung stehen. Dies wird mit JSF erreicht. Das Model bleibt unverändert, Controller und View gibt es in dieser Form nicht mehr.
  • Bei der Validierung der Mussfelder sollen die nicht ausgefüllten Felder rot markiert werden. Je nach eingesetzter Technologie ist nur die View betroffen, ev. noch der Controller. Das Model ist auf jeden Fall nicht betroffen.

Weiterführende Links:

MVC: http://de.wikipedia.org/wiki/Model_View_Controller

Zutaten beim Online-Marketing

Zutaten

Es gibt verschiedene Zutaten beim Online-Marketing:

  • Zielperson: wer genau wird angesprochen, welche Bedürfnisse hat sie, was sucht sie nicht.
  • Suchmaschinenmarketing: ist der wichtigste Bestandteil und wird detaillierter angeschaut.
  • Website: steht im Zentrum und muss dem Besucher einen Mehrwert liefern.
  • Content: zugeschnitten auf die Zielperson(en) mit ansprechenden Bildern, aktuellem Inhalt und interessanten Videos.
  • E-Mail Marketing: zugeschnitten auf die Zielperson(en) mit spezifischen Informationen.
  • Social Media Instrumente: der Einsatz von Facebook drängt sich auf, weil damit mit potenziellen Kunden interagiert werden kann.

Google Adwords

Das Suchmaschinenmarketing (bei Google) besteht hauptsächlich aus SEO (Search Engine Optimization) und AdWords (bezahlte Werbung). Eine Suche nach „HTML5 Grundlagen“ liefert folgendes Ergebnis:

Google Suche mit AdWords
Google Suche

An erster Stelle kommen AdWords-Resultate, gekennzeichnet durch das gelbe Ad-Symbol. Danach folgen die Ergebnisse gemäss Google-Ranking von SEO. Anhand dieser Resultate sieht man, dass video2brain sowohl bezahlte Werbung schaltet wie auch im Google-Ranking zuoberst erscheint. Braucht es beides oder kann man sich auf eines beschränken?

Search Engine Optimization

Die Mehrheit der Nutzer steht bezahlter Werbung eher skeptisch gegenüber. Daher braucht es SEO auf jeden Fall. Dazu gehören folgende Themen:

  • Onsite Optimierung (Aktivitäten auf der eigenen Website):
  • Sauberen HTML Code ohne Validierungsfehler erstellen
  • Title, Description und Keywords verwenden
  • HTML-Tags verwenden, welche das Ranking verbessern
  • Text auf Keywords optimieren (wichtige Keywords müssen mehrfach vorkommen)
  • Bilder mit Keywords benennen
  • Offsite Optimierung (Links von fremden Websites auf unsere)
  • Social Bookmark Dienste
  • Websites von Freunden und Partnern
  • Anfrage bei themenverwandten Websites
  • Google Tools: Google stellt eine Reihe von Tools und Leitfäden zur Verfügung. Wichtig ist auch, ihre Suchergebnisse zu analysieren.

SEO: Search Engine Optimization

AdWords

Auch wenn nur eine Minderheit der Nutzer die AdWords-Resultate zuerst anwählt, lohnt es sich:

  • AdWords können ganz genau auf die Zielperson(en) abgestimmt werden
  • AdWords können nach Region und Uhrzeit gesteuert werden
  • Kosten fallen nur an, wenn der Nutzer via AdWord auf die Website gelangt (Cost per Click)
  • Kurzfristig einsetzbar, liefern meist nach kurzer Zeit messbare Erfolge

Wie so oft gibt es kein eindeutiges Erfolgsrezept. In den meisten Fällen macht eine Kombination von SEO und AdWords Sinn. Mit AdWords kann das Ranking kurzfristig beeinflusst werden. Mit SEO braucht es deutlich länger.

Weiterführende Links: