Intranetsoftware für jedermann – Teil 2

Im ersten Teil der Reihe Intranetsoftware für jedermann, habe ich Anforderungen definiert und eine erste Idee geliefert, wie sich ein solches System umsetzen lässt.
Doch die zentrale Frage, die sich viele stellen, ist damit meist nicht vom Tisch: Wie gehe ich das Ganze an?

Bevor ich diese Frage kläre möchte ich vorab sagen, dass es nicht DIE richtige Methode gibt.
Es gibt im Allgemeinen verschiedene Ansätze, wie man an ein solches Projekt ran geht.
Zu Beginn – und um Erfahrung zu sammeln – ist es sicherlich auch von Nutzen, wenn man direkt los legt. Denn bekanntlich lernt man nur aus Fehlern und diese werden hier sicherlich auftreten.
Man vergisst Implementierungen oder Teilbereiche, die sehr entscheidend sind.

Auch ich habe immer direkt angefangen, auf der Tastatur zu „klimpern“. Doch schnell habe ich bemerkt, dass es wichtig ist, seine Anforderungen genau zu definieren.
Nur wenn man im Voraus festlegt, was man erreichen will, wird man am Ende – oder bei einem Zwischenfazit – zufrieden sein.
Im professionellen Umfeld wird kein Entwickler auf die Idee kommen, einfach mal anzufangen ohne zu wissen, was genau dabei herauskommen soll.

Daher gilt: Mach dir einen Plan! Schreibe auf, was du erreichen willst und halte dich an deinen Plan. Während der Entwicklung – und der Testphase – wird dieser Plan schrumpfen oder auch wieder wachsen. Man hat ständig neue Ideen, die man versucht umzusetzen. Aber stecke dir Ziele, die du erreichen kannst. Fang klein an und versuche nicht alles auf einmal umzusetzen, das endet im Chaos.

Methoden

Viele private Projekte werden ohne genauen Plan oder ohne eine genauer Vorgehensweise umgesetzt.
Dabei ist eine Vorgehensweise zur Entwicklung nicht wegzudenken. Sie gibt eine Struktur vor und hilft Fehler zu vermeiden.

Hierbei können verschiedene Methoden genutzt werden. Klassische Methoden wären beispielsweise das Wasserfallmodell oder das Spiralmodell.

Wasserfallmodell

In der einfachen Variante besteht das Wasserfallmodell aus fünf Phasen. Die einzelnen Phasen sind hierbei voneinander abhängig, mit Ausnahme der ersten. Diese legt den Grundstein für das spätere Produkt und hat nur Nachfolger, aber keine Vorgänger.

Ganz einfach lässt sich das Wasserfallmodell in folgender Grafik darstellen:

Phase 1 – Anforderungen festlegen: Die Anforderungen an das spätere Produkt müssen definiert werden. Meist erfolgt das – in Rücksprache mit dem Auftraggeber – in einem Pflichten- bzw. Lastenheft. Das Pflichtenheft verpflichtet den Entwickler an die Erstellung der darin aufgezählten Punkte. Das Lastenheft spezifiziert die Anforderungen des Auftraggebers an die Software.

Phase 2 – Entwurf ausarbeiten: In der zweiten Phase wird ein Entwurf ausgearbeitet, welcher das System schematisch darstellt. Dazu nutzt man Diagramme, welche die einzelnen Komponenten in Verbindung zu anderen setzen. Hinzu kommt noch eine Definition von Aufgaben, welche die Komponenten erfüllen und welche Schnittstellen sie bieten.

Phase 3 – Entwurf implementieren: Die dritte Phase dient der Implementierung, also der Umsetzung des Entwurfs aus Phase 2 unter Berücksichtigung der Anforderungen aus Phase 1. Beachten sollte man hierbei, dass es immer noch Fehler im Produkt geben wird. Man wird trotz guter Planung nicht sofort fehlerfrei starten können. Die Fehler werden jedoch minimiert.

Phase 4 – Überprüfen: Nachdem in der dritten Phase der Entwurf implementiert wurde, Überprüft man nun in der vierten Phase das Ergebnis. Fehler werden – und sollten – aufgedeckt (werden).

Phase 5 – Inbetriebnahme: In der letzten Phase des Wasserfallmodells nimmt man das Produkt in Betrieb. Es ist die letzte Phase, da die grundlegende Entwicklung nun abgeschlossen ist. Wartung und Erweiterung fallen jedoch immer noch an und werden in eigenen Projekten bzw. Prozessen durchgeführt.

Wie jedes Vorgehensmodell hat auch das Wasserfallmodell seine Stärken und Schwächen. Besonders hervorzuheben ist meiner Meinung nach die genaue Abgrenzung, die in der Praxis sehr schwierig ist. Nicht jeder Schritt kann klar vom nächsten getrennt werden. Denn auch bei der Implementierung sollte eine Überprüfung stattfinden, weshalb sich die beiden Phasen durchaus vermischen können.
Jedoch gibt es während des Entwicklungsprozesses eine gute Struktur, welche für ein gutes Ergebnis sorgen sollte. Je nach Anwendung lässt sich dieses Modell auch abwandeln und so in noch mehr Phasen gliedern.

Spiralmodell

Das Spiralmodell ist – wie der Name bereits verrät – wie eine Spirale aufgebaut.
Grundlegende Phasen sind jedoch ähnlich bzw. gleich wie beim Wasserfallmodell. Dazu zählen die Festlegung der Ziele sowie die Entwicklung und der Test. Hinzu kommt jedoch die Risikoanalyse.

Wie man nun bereits an der Risikoanalyse erkennen kann, ist dieses Modell eher für risikoreiche und große Projekte geeignet. Daher möchte ich an dieser Stelle auch nicht weiter darauf eingehen, da ich mich mit der Intranetlösung eher auf ein kleines Projekt fokussiere. Weitere Informationen zum Spiralmodell findet man jedoch in den Links, welche ich am Ende des Artikels angehängt habe.

Extreme Programming

Im Gegensatz zu den ersten beiden Methoden ist das Extreme Programming eine agile Methode, die sich zum Ziel gesetzt hat, der Bürokratie (Dokumentation, Planung, etc.) weniger Beachtung zu schenken.

Hierbei wird die Software bereits entwickelt, während dem Auftraggeber noch nicht zu 100 % klar ist, was genau die Anforderungen sind.
Wichtig ist bei dieser Vorgehensweise die Kommunikation im Team und mit dem Auftraggeber.

Der Sinn hierbei ist, dass der Kunde an der Erstellung der Software teilnimmt, indem er ständig einbezogen wird. Dadurch soll sichergestellt werden, dass das Produkt später für Zufriedenheit sorgt.

Bewertung

Für mich persönlich spielt in der Erstellung einer Intranetsoftware für Familien eher das Wasserfallmodell eine Rolle, da es für den Nutzen nicht überdimensioniert ist. Eine Risikoanalyse ist meiner Meinung nach bei einem privaten Projekt, das aus Interesse an der Programmierung umgesetzt wird, nicht nötig. Das Extreme Programming fällt für mich wieder unter die Kategorie „direkt auf der Tastatur klimpern“, weshalb ich – gerade zu Beginn – davon abrate.

Selbstverständlich ist das eine subjektive Meinung, welcher nicht jeder zustimmen wird. Das ist auch gut so, denn jeder muss seinen eigenen Stil finden, wie er seine privaten Projekte am besten umsetzt. In einem Unternehmen ist dies nicht ohne weiteres möglich, denn man ist nur Teil eines Teams. Dieses Team – oder der Chef – bestimmt den Ablauf der Programmierung.

Übertragen auf die Intranetsoftware

Nun sollte man – nachdem man sich kurz gesammelt hat nach diesem vielen Input – Gedanken machen, wie es weiter geht.

Die Anforderungen haben wir bereits im ersten Teil spezifiziert. Sofern diese auf die eigenen Vorstellungen nicht zutreffen, sollte man sie natürlich dementsprechend anpassen.
Und schon ist es an der Zeit, einen ersten Entwurf zu erstellen.

Als leitende Fragen stelle ich mir hierbei:

• Wie hängen die einzelnen Teile zusammen?
• Was tun sie?
• Welche Aufgaben müssen sie später übernehmen?

Daraus kann man dann auch schnell erkennen, welcher Teil ein sehr wichtiger Baustein des ganzen Systems ist. In vielen Fällen wird das die Datenbankschicht bzw. das Datenbankmodul sein. Dieses – sofern man es als einzelnes Modul auskoppelt – stellt alle Daten für das komplette System zur Verfügung.

Tipp

Damit es zu Beginn nicht so schwer ist ein System schematisch darzustellen, kann man sich an einem Deployment-Diagramm orientieren.
Ich würde die einzelnen Teile des Systems anstelle von den Devices skizzieren und diese in eine sinnvolle Verbindung bringen.
Angelehnt an ein UML-Klassendiagramm kommen dann die einzelnen Funktionen (Methoden) hinzu, welche später die Aufgaben übernehmen.
Diese Klassen – und ihre Methoden – stellen die Applikationslogik dar.
In den Verweisen findet man ein gutes Beispiel für ein UML-Klassendiagramm und ein Deployment-Diagramm.

Auch hier ist zu erwähnen, dass im professionellen Umfeld keine Vermischung der beiden Diagrammen stattfindet, ich es jedoch der Einfachheit so mache. Das macht den Einstieg leichter und man freundet sich langsam mit solchen Diagrammen an.
Weiterhin wäre ein richtige Deployment-Diagramm für die Intranetsoftware zu überdimensioniert.

Schlusswort

Das war es nun auch schon wieder in diesem Teil.

Wir haben nun einen wichtigen Aspekt lange „durchgekaut“: Die Planung.
Sie erleichtert uns die Umsetzung des Projekts und gibt dem ganzen Prozess eine Struktur. So verfängt man sich nicht in Planungslosigkeit.
Weiterhin gibt sie uns Zeit zum Nachdenken, so dass wir gedanklich das künftige System komplett auseinander nehmen.
Damit diese Planung nicht unnütz ist, notieren wir sie in Form von Diagrammen. Wer möchte, kann diese natürlich auch noch in einem Text ausformulieren und sich selbst ein Pflichtenheft aufsetzen.

Was zusätzlich gemacht werden kann, ist das Einbeziehen von Freunden oder der Familie. Manchmal sieht man nur seine eigenen Anforderungen und kann sich schlecht in die Sicht anderer Personen versetzen. Man selbst legt viel Wert auf einen funktionierenden Kalender, während ein anderer Nutzer jedoch ein gutes Nachrichtensystem erwartet.
Außerdem ist es möglich, durch verschiedene Meinungen Schwächen im eigenen Konzept aufzudecken. Das erspart am Ende eine Menge Frust und Nachbesserungen.

Klar sollte aber sein, dass man nicht von Beginn an alles perfekt machen kann. Man wird im Laufe der Entwicklung auf Probleme stoßen, die man dann beheben muss. Auch im Produktivbetrieb kann es noch zu Fehlern kommen, die man nicht vorhergesehen hat. Aber: be cool. Das ist absolut normal und kein Grund zur Panik.

Verweise

Wikipedia.org: Spiralmodell

Wikipedia.org: Wasserfallmodell

Codesco.com: Klassische vs. agile Methoden der Softwareentwicklung

Agilemodeling.com: Deployment-Diagram

Wikipedia.org: Klassendiagramm