Software Engineering

  • Motivation und Einfuerung
  • Agile Softwareentwicklung I
  • Agile Softwareentwicklung II
  • Analyse und Spezifikation I

    • Motivation und Einfuerung

    Software sind alle Programme, Verfahren, die zugehoerige Dokumentation und Daten, die mit dem Betrieb eines Rechnersystems zu tun haben. Ihre besondere Eigenschaft ist, dass sie abstrakt und nicht direkt wahrnehmbar ist. Software ist unstet, also die kleinste Veraenderung kann zu massiven Aenderungen im Systemverhalten fuehren. Man kann schwierig den Funktionsnachweis machen und generell wird Software schnell komplex. Software Engineering ist die Anwendung eines systematischen, diziplinierten und quantifizierbaren Ansatzes auf die Entwicklung, den Betrieb und die Wartung von Software, d.h. die Anwendung der Prinzipien des Inginieurwesens auf Software. Es auch viel mehr als nur einfach Programmieren! Das magische Dreieck ist ein Diagramm, dass darstellt, wie es sich in einem IT-Projekt verhaelt, wenn man an den Stellschrauben Aufwand, Leistung und Zeit was veraendert. In den spaeten 60er-Jahren kam es zu der Software-Krise aus folgenden Gruenden: Software-Projekte wurden immer groesser, bei groesseren Projekten kamen vorherschende Methoden zu kurz und somit wuchsen sie nicht mit, SW-Projekte scheiterten haeufig und hatten Probleme und die Hardware wuchs zusammen mit den Problemen an. Im SE spricht man von 8 Aktivitaeten unzwar:

    1. Mangement grosser und komplexer Projekte und/oder Produkte
    2. Schaetzung von Terminen und Kosten
    3. Erfassung von Kunden- und Marktanforderungen
    4. Entwurf von Software- und Systemarchitekturen (Prinzipien wie Abstraktion, Strukturierung, Hierachisierung und Modularisierung)
    5. Guter Programmierstil und Entwicklungswerkzeuge
    6. Sicherstellung eines hohen Qualitaetsniveaus
    7. Aenderungsmangement
    8. Wartung und Weiterentwicklung von Altsystemen

    Zuletzt wird geklaert worauf erfolgreiche IT-Projekte beruhen. Man macht sorgfaeltige Analysen und Spezifikationen, man verwendet die modernsten Entwurfsmethoden, man bezieht alle Projektbeteiligten ein und man sollte alle Prozesse planen und kontrollieren.

    Agile Softwareentwicklung I

    Der Software Life Cycle geht fuenf Phasen durch. In der ersten Phase macht man eine Anaylse der Software (falls vorhanden) und spezifiziert was sie tun soll. In der zweiten macht man die Entwicklung, wo das System selber erstellt, integriert und getestet wird. Die dritte Phase ist die Abnahme wo man prueft ob die Kundenanforderungen erfuellt werden. Der Betrieb, also die Installation und Wartung beim Kunden findet in der vierten Phase statt. In der fuenften und letzten Phase kommt die Evolution, was nichts anderes bedeutet, als das man die Software weiterentwickelt, anhand der neuen Anforderungen und so beginnt man wieder bei Phase eins. Der Grossteil der Kosten faellt dabei auf die Wartung/Betrieb der Software.

    Beim SE-Prozess setzt man die Kunden- / Useranforderungen in ein Softwareprodukt um. Hierbei gibt es fuenf charakteristische Eigenschaften fuer einen solchen Prozess:

    1. Umsetzung der Kunden- / Useranforderungen in Software-Anforderungen
    2. Software-Anforderungen designen
    3. Die Designs implementieren
    4. Implementierten Code testen
    5. Code testen
    6. Installation und Ueberpruefung der Software vor Ort

    Das Wasserfallmodell ist ein Weg ,um einen Entwicklungsprozess umzusetzen. Dort werden Aktivitaeten festgelegt, die sich an den Software-Lebenszyklus orientieren. Es traegt das Wort "Wasserfall" in sich, da man von Aktivaet zu Aktivitaet weiter- bzw. runtergeht, ohne zurueck. Dennoch kann man mit lokalen Zyklen zurueckspringen. Um dieser linearen Vorgehensweise entgegenzuwirken, kommt agile SE in's Spiel.

    Aus den Herausforderungen linearer Prozessmodelle haben sich gleichzeitig zentrale Motive fuer agile Methoden herausgebildet:

    1. Ueber-Analyse
    2. Hohe Kosten fuer spaetere Aenderungen
    3. Buerokratisierung des Entwicklungsprozess
    4. hoher Dokumentations-Overhead
    5. Zeitverzug von Projekten

    Im agilen Manifest stehen die 12 Leitgedanken, welche die Werte der agilen Methoden vertreten.

    Scrum

    Scrum ist ein Framework um agile Software zu entwickeln und wird eingesetzt wenn Anforderungen nicht gleich bleiben und uneindeutig sind. Die empirische Prozesssteuerung ist die Grundidee von Scrum und folgt den Prinzipien Transparenz, Inspektion und Anpassung von Ergebnissen und Aktivitaeten und basiert darauf, dass von Iteration zu Iteration der Entscheidungsspielraum sinkt.

    In Scrum sind der Product Owner, Scrum Master und das Dev-Team involviert. Diese Arbeiten mit folgenden Artefakten:

    Dabei interagieren alle Teilnehmer ueber folgende Aktivtaeten mit- / untereinander:

    Agile Softwareentwicklung II

    In Scrum plant man was und bis man es ausliefern moechte, in einem Zeitraum von einen bis vier Monaten. Der PO und das Dev-Team (ggf. noch andere Stakeholder) erstellen gemeinsam einen groben Projektplan. Darin nennt der Auftraggeber seine Wuensche, welche als Product Backlog Items festgehalten werden. Der PO ordnet diese Items nach ihrer Wichtigkeit und das Team schaetz den Aufwand, wie auch die Risiken fuer die jeweiligen Items ein. Danach macht das gesamte Team einen Zeitplan fuer die wichtigsten Kundenwuensche fuer jede Iteration.

    Um zu schaetzen wie gross eine Funktionalitaet ist, verwendet man am besten Planing Poker. Der Abluaf ist wie folgt:

    1. Einigen auf Referenz-Item
    2. PBI auswaehlen, dass eingeschaetzt werden soll
    3. Verstaendnisfragen klaeren
    4. Spielkarte (Fibonaccizahl) auswaehlen
    5. Karten gleichzeitig aufdecken
    6. Ausreisser erlaeutern ihre Entscheidungen
    7. nochmal einschaetzen
    8. sinnvollsten Wert auswaehlen

    Mit Story Points schaetzt man die Schwierigkeit eines PBI ein mit einem Referenz PBI. Der Vorteil ist, dass man abstrakter vergleichen kann, ohne an Zeiteinheiten gebunden zu sein. Die Nachteile sind, dass es recht aufwaendig wird, wenn das Projekt gerade erst angefangen hat, wenn das Team fast keine Erfahrung in dieser Art von Arbeit hatte, wenn das Team mit neuen Entwicklungswerkzeugen arbeitet und ausserdem sind alle Einschaetzungen immernoch subjektiv, wodurch am Anfang die Einschaetzungen falsch sind. Mit der Zeit aber verbessern sich die Schaetzungen.

    Die Velocity (wie hoch das Arbeitsmass eines Teams ist) im Kern der empirische Planung in Scrum ist insofern bedeutsam, dass man aus ihr heraus zukuenftige Abschaetzungen besser machen kann.

    Indem man die Anzahl der nicht erledigten Aufgaben und den Aufwand festhaelt, kann man kontrollieren wie der Fortschritt des Projekts aussieht.

    Folgende Grafik stellt dar, wie Scrum mit agilen Methoden gegen den Problemen von zum Beispiel des Wasserfall-Modells entgegenwirkt.

    Analyse und Spezifikation I

    Anforderungsanalyse

    Bei der Anforderungsanalyse ist es wichtig sich immer zu vergewissern, dass der Kunde Leistungen aus der Software erwartet, aber nicht viel dafür in Form von Geld, Mühe, etc. zu zahlen. Man muss auch gut verstanden was die Markt- und Benutzerbedürfnisse sind und in welchen Kontext das Produkt verwendet wird. Misachtet man diese Aspekte, so wird das End-Produkt auch nicht die Anforderungen erfüllen!k Das wieder gerade zu biegen, also ab der Phase der Abnahme und Betrieb, kostet extrem viel im Gegensatz, wie wenn man das schon bei der Anforderungsanalyse beachtet hätte.

    Anforderungen

    Informelle Definition einer Anforderung: Eine Anforderung ist eine zu erfüllende Bedingung oder eine Eigenschaft, die ein System haben muss, um ein Problem zu lösen oder ein Ziel zu erreichen.

    Hier noch eine Grafik die zeigt, wie man sich die Hierachie der Anforderungen der verschiedenen Teilnehmern vorstellen kann:

    funtionale Anforderungen

    Mit funktionalen Anforderungen beschreibt man die primären Benutzeraufgaben die das Produkt unterstützen soll. Diese kann man in Aktionen übersetzen die vom System ausgeführt werden. Um diese Aktionen identifizieren zu können helfen folgende Leitfragen:

    nicht-funktionale Anforderungen

    Diese Art von Anforderungen sind sehr wichtig für den Produkterfolg. Sie beschreiben die Qualitätseigenschaften einer Software und können mit folgenden Leitfragen eingehalten werden:

    Wenn man diese Anforderungen formuliert, soll man sie am besten als Einschränkungen oder Zusicherungen formulieren. Es sollen so wenige Schlagwörter wie möglich und so präzise wie nötig geschrieben werden!

    Beispielsweise kann man bei der Corona-Warn-App als nf-A. Genauigkeit, Ausfallsicherheit, Geräteunabhängigkeit und Lesbarkeit festhalten.

    Herausforderungen der Analyse

    Das Ausarbeiten der Anforderungen ist nicht immer leicht. Aus der Kundensicht können die A. nicht genannt, weil er nur an die eigenen Wünsche und Ziele denkt; eine hidden agenda verfolgt werden; deren Fachsprache ist nicht so leicht verständlich. Auf der Ebene der Stakeholder können die A. widersprüchlich sein, oder neue Stakeholder kommen mit neuen A. Herausfordernd bleibt es auch, da sich A. während der Analyse und Entwicklung verändern können.

    Doch wie analysiert man? Dafür gibt es eine Reihe von Methodiken. Die ersten drei Methoden in der unten aufgeführten Liste werden häufig für die agile Produktentwicklung genommen!

    Personas, Features

    Die folgende Grafik erklärt wie man von Personas zu Features kommt.

    Szenarios, User Stories

    Szenarien beschreiben wie die Abfolge der Interaktion mit der Software ist, aber diese Interaktionen werden nicht genauer beschrieben, wohingegen User Stories strukturiert und ganz genau beschreiben wie eben diese Interaktion verlaufen soll.

    Die untere Tabelle zeigt welche Kriterien man einhalten muss, um eine gute User Story zu erstellen. (INVEST)