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.

Ä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

 

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

Von der Geschäftsidee zur IT-Umsetzung (1)

Ausgangslage

Am Anfang steht die Geschäftsidee auf einem einzigen Blatt Papier – am Ende resultiert eine IT-Lösung, welche weltweit eingesetzt werden kann. Dieses schwierige Unterfangen wird im Folgenden am Beispiel von Spotsonscreen beschrieben. Eine erfolgreiche Zusammenarbeit zwischen zwei KMUs: Spotsonscreen hat eine neue Geschäftsidee, Hyperformers ist verantwortlich für die IT-Umsetzung.

Geschäftsidee

Die Geschäftsidee ist einfach: Werbebotschaften können selber zusammenstellt und auf beliebigen Geräten (TV, Beamer, Tablet) abgespielt werden. Die Werbebotschaften können nach Warengruppen (Rayon) und Filialen klassiert und mit ein paar wenigen Klicks auf die Geräte verteilt werden. Eine permanente Internetverbidnung braucht es nicht.
Spotsonscreen hat umfangreiche Marktabklärungen in der Schweiz und im angrenzenden Ausland gemacht. Es bestehen bereits Kontakte zu möglichen Kunden. Höchste Zeit, mit der IT-Umsetzung zu starten. Als Erstes erarbeitet Hyperformers ein Konzept mit verschiedenen Varianten, wie dieses System aussehen kann. Es braucht ein benutzerfreundliches Verwaltungstool, um die Werbebotschaften hochzuladen und anschliessend auf die Geräte zu verteilen. Es braucht Geräte, welche mit dem Verwaltungstool kommunizieren und die richtigen Videos herunterladen können. Dies bedingt, dass es klar definierte Schnittstellen zwischen der Videoverwaltung und den Geräten braucht.

Storyboard

Der Auftraggeber kann mit technischen Begriffen nicht viel anfangen. Deshalb ist es wichtig, möglichst schnell mit dem Entwurf der Benutzeroberfläche zu beginnen. Eine einfache Möglichkeit besteht darin, ein sog. Storyboard zu erstellen: Verschiedenen Screens werden miteinander verlinkt und der Auftraggeber kann durch die einzelnen Screens navigieren. Damit werden zwei Fliegen auf einen Schlag erwischt:

  • Hyperformers muss die Geschäftsidee verstehen und sich Gedanken zur Umsetzung machen
  • Der Kunde kann verifizieren, ob seine Idee richtig verstanden wurde und vollständig ist
Endgerät Screen
Visualisierung

Beispiel Storyboard: Screen zur Generierung von Reports

Dies ist ein iterativer Prozess. Entscheidend ist, dass die Geschäftsidee von verschiedenen Perspektiven (Auftraggeber, IT, mögliche Kunden) betrachtet wird. So werden alle Aspekte abgedeckt. Eine kritische Haltung aller Beteiligten ist unerlässlich. Dies setzt gegenseitiges Vertrauen voraus. Es geht darum, die Geschäftsidee weiter zu entwickeln, damit sie effizient umgesetzt werden kann.

Am Beispiel Spotsonscreen ist dies gelungen. Nach diversen Besprechungen und zwei Reviews ist sichergestellt, dass:

  • Hyperformers die Anforderungen verstanden hat
  • Das Storyboard korrekt ist
  • Das technische Konzept umgesetzt werden kann
  • Die Umsetzung etappiert wird, damit möglichst schnell verkauft werden kann

Weiterführende Links:

Im nächsten Blog wird die technische Umsetzung beschrieben.