Programmierung ist nicht alles!

Diese Seite beschäftigt sich mit den Vor- und Nachwehen jeder Programmierung. Von der Analyse bis zu den Tests ist eine Menge rund um den Kernjob der Programmierung zu erledigen.

Analyse und Planung

Vor jeder Software-Entwicklung muss geklärt sein, worin die Aufgabe besteht: Was soll die Software enthalten, welche Ergebnisse soll sie bringen, welche Interaktionen müssen möglich sein, welche Zugriffe und Sicherheitsstufen sind notwendig usw. Wichtig sind dabei die Präzision, die Vollständigkeit und die Unmissverständlichkeit. Deshalb wird in großen betrieblichen Projekten sogar eine eigene Darstellungssprache benutzt, die UML (Unified Modeling Language = Vereinheitlichte Modellierungssprache). Folgende Dokumente sind für Softwareprojekte üblich, wenn es um die Festlegung der Aufgaben und Arbeitsschritte geht:

Das Lastenheft
Es beschreibt das Projekt aus der Sicht der Anwender, deren Anforderungen in deren Sprache: Was soll die Software leisten, welche Probleme soll sie lösen. Die Art der Realisierung spielt im Lastenheft keine Rolle.

Das Pflichtenheft
Es beschreibt technische Festlegungen, die aufgrund der im Lastenheft genannten Ziele und Vorgaben benötigt werden (Betriebssystem(e), Programmiersprache(n), Auslegung der Server, Organisation der Software bis zum detaillierten Aufbau von Bildschirmdialogen, Datenbanktabellen und benötigten Schnittstellen.

Die Analysediagramme
Sie beschreiben Begriffe und ihre Zusammenhänge aus Entwicklersicht. Das Lastenheft wird praktisch in der analytischen Sprache der Entwickler in Modellen und Diagrammen abgebildet. Das Dokument enthält idealerweise nur dann Freitext, wenn schwer formalisierbare Anforderungen zu formulieren sind. Wenn die Analysedokumente stimmig sind, wissen Entwickler, dass die Vorgaben aus dem Lastenheft im Sinne des Kunden umsetzbar sind.

Diese Dokumente beschreiben präzise die Anforderungen an die Software. Gerade in größeren Projekten kommt es häufig vor, dass Anforderungen vergessen oder erst nachträglich formuliert werden. Für Nicht-Programmierer ist es vollkommen unverständlich, wieso eine kleine Änderung in der Anforderung einen Rattenschwanz an Arbeit und damit Kosten nach sich ziehen kann. Deshalb ist es sinnvoll, eine Abnahmeerklärung unterzeichnen zu lassen, wenn die Arbeit an den Anforderungsdokumenten beendet ist. In der Abnahmeerklärung sollten alle Dokumente in ihrer letzten Version aufgeführt sein. Ist sie unterschrieben, gibt es für den Auftraggeber bei nachträglichen Änderungen keinen Grund, zusätzliche Kosten grundsätzlich in Frage zu stellen.

Die Anforderungsdokumente werden in der Regel ergänzt um

  • eine Aufwandsschätzung
  • ein Vorgehensmodell
  • ein Mock-up

Das Mock-up ist praktisch ein Fake der Software, das dem Auftraggeber in Grundzügen das Design der Nutzeroberfläche zeigt.

Erst aufgrund von Planung und Analyse kann ein Softwareprojekt seriös kalkuliert werden.

Auch bei kleineren Projekten und Arbeiten im Freundeskreis ist es allein schon aus Gründen der Arbeitsökonomie ratsam, vor Beginn der Programmierung alle Ziele und Wünsche zu klären. Erst mal anfangen und dann schauen, wie sich das Projekt entwickelt – das ist reine Zeitverschwendung.

Spezifikation und Entwurf

Die Spezifikation ist der erste Schritt in die Umsetzung des Anforderungsdokuments. In ihr legen die Programmierer dar, mit Hilfe welcher Programmiersprachen und Tools sie die Anforderungen erfüllen wollen. Neben den Funktionen der Software geht es dabei darum, wie Sicherheitsstandards erfüllt werden, wie Backups und Updates ausgeführt werden, für welche Browserversionen programmiert wird, wie Zugriffsrechte eingefügt werden etc. Und natürlich um Hardwarefragen. Wo und wie wird gespeichert, wie werden Anpassungen und Schnittstellen für das Backup-Office realisiert. Anhand einer guten Spezifikation lässt sich ein detaillierter Vergleich zwischen Soll- und Ist-Zustand vornehmen.

Im Entwurf geht es um die Softwarearchitektur. Dabei wird meist eines der drei folgenden Entwurfsprinzipien angewendet:

  • schrittweise Verfeinerung
  • Modularisierung
  • Strukturierung

Das erste Entwurfsprinzip ist für kleinere Projekte das brauchbarste, die beiden anderen zielen auf große bis sehr große Softwareprojekte ab. Im Verfahren der schrittweisen Verfeinerung entwirft man zunächst einen groben und relativ abstrakten Algorithmus. Dann wird Schritt für Schritt verfeinert, die Funktionen werden in zu programmierende Einheiten zerlegt. Dieses Verfahren nennt man auch Top-down-Entwurf – vom Allgemeinen zum Spezifischen.

In der Modularisierung wird in Einzelbausteinen entworfen, die dann zur Gesamtstruktur zusammengefügt werden. Und das Prinzip der Strukturierung schließlich geht von einer hierarchischen Anordnung der Systemkomponenten aus und beschreibt ihre Beziehungen untereinander.

Programmierung

Im engeren Sinn bedeutet Programmierung, den abstrakten Entwurf in Quellcode umzusetzen. Als Hilfsmittel dienen dazu die Werkzeuge, die Programmierer zur Verfügung haben:

  • Integrierte Entwicklungsumgebungen (DIE)
  • Editoren
  • Quellverwaltungssysteme
  • Übersetzer oder Compiler
  • Prüfsoftware
  • Testwerkzeuge

Validierung und Verifikation

Der letzte und entscheidende Schritt. Auf deutsch gesagt heißt das einfach: testen, testen, testen! Validierung oder Plausibilisierung, auf Englisch sehr schön Sanity Check genannt, verlangt die Kontrolle eines konkreten Wertes darauf, ob er zu einem bestimmten Datentyp gehört oder in einem vorgegebenen Wertebereich oder einer vorgegebenen Wertemenge liegt. Die meisten Programmfehler und Sicherheitsprobleme sind letztlich auf fehlende Plausibilisierung von Eingabewerten zurückzuführen.

Für die Validierung gilt die goldene Regel: never trust the user (traue niemals dem Benutzer) – wobei der „Benutzer“ in diesem Fall der Programmierer ist, der die fraglichen Funktionen und Module verwendet. Mit der Validierung von Werten sollte ein Programmierer schon im Entwicklungsprozess beginnen: Einzelne Funktionen und Module sollten regelmäßig Unit-Tests unterzogen werden, die den Quellcode flächendeckend (Code Coverage Analysis) auf korrektes Verhalten überprüfen. Auch bei der Übersetzung des Programmes können einige Arten der Validierung vom Compiler vorgenommen werden. Manche Programmiersprachen haben darüber hinaus ein Laufzeitsystem, das bestimmte Arten von Fehlern selbstständig erkennt, z.B. nicht vorhandene Objekte.

Unter Validierung fällt auch die Prüfung der Eignung beziehungsweise des Werts einer Software bezogen auf ihren Einsatzzweck. Grundlage ist das vorher aufgestellte Anforderungsdokument. Die Eignungsprüfung wird sowohl technisch als auch durch Benutzer ausgeführt. Es wird dadurch die Frage beantwortet: "Ist das richtige Produkt entwickelt worden?". Der klassische Abnahmetest kann in allen Entwicklungsstufen verschiedene Methoden umfassen:

  • Reviews mit dem Kunden, um Unklarheiten und irrtümliche Annahmen aufzudecken.
  • Prototyping von Benutzeroberflächen als Kommunikationsgrundlage mit dem Anwender
  • Teilergebnisse der Entwicklung vorstellen. Dadurch sollen schnelles Kundenfeedback und zuwachsende Entwicklung erreicht werden.
  • Nutzerakzeptanztests

In der Verifikation wird dagegen überprüft, ob ein System seiner formalen Spezifikation genügt. Die Frage lautet: "Bauen wir das Produkt richtig?". Es ist durchaus denkbar, dass eine Software ihre Spezifikation erfüllt, jedoch für den Kunden nur geringen Nutzen hat.

Methoden zur Verifikation sind:

  • Codereviews
  • formale Verifikation besonders sensibler Bereiche
  • Verfahren des Softwaretests
Algorithmus

Ein schwieriger, richtig mathematisch klingender Begriff, der etwas Einfaches meint und seinen Namen einer scherzhaften Umformung verdankt. Algorithmus ist eine genau definierte Handlungsvorschrift zur Lösung eines Problems oder einer bestimmten Art von Problemen in endlich vielen Schritten. Jedes Kochrezept ist also ein Algorithmus. Und jede Bauanleitung für ein zerlegt geliefertes Möbelstück (wenn sie denn funktioniert!).

Das Wort Algorithmus ist eine Verballhornung des Namens von Muhammed al-Chwarizmi, dessen arabisches Lehrbuch von 825 „Über das Rechnen mit indischen Ziffern“ in der lateinischen Übersetzung so begann: „Dixit Algorismi“ (Algorismi hat gesagt). Im Mittelalter wurde daraus lateinisch „algorismus“ oder „alchorismus“ oder „algoarismus“ für die Kunst des Rechnens mit arabischen Ziffern. Da man später die Wurzeln im Griechischen vermutete, wurde in der lateinischen Wissenschaftssprache aus dem „rismus“ ein „rithmus“.

Der Algorithmus spielt in der Informatik eine zentrale Rolle. Doch welche, darüber streiten die Gelehrten. Mal wird er definiert als das abstrakte Gegenstück zum konkret auf die Maschine zugeschnittenen Programm, mal als Maschinenprogramm für die ideale mathematische Maschine. Als gebrauchsfertige, notwendige und hinreichende Definition für Programmierer bleibt: Algorithmus ist eine genau definierte Handlungsvorschrift zur Lösung eines Problems oder einer bestimmten Art von Problemen in endlich vielen Schritten.

Suchen



gratis-infos-box