Handlungssituationen

Handlungsziele und typische Handlungssituationen

1. Erfasst Problemstellungen, entwickelt strukturiert Lösungsansätze und übersetzt sie für die Stakeholder.

Paul Muster erhält von seinem Software-Team den Auftrag, eine Applikation zu programmieren. Stakeholder ist das Business-Team, welches das Problem beschrieben hat. Er kann mittels Rückfragen ans Business-Team das Problem eingrenzen und beschreiben. Er achtet darauf, dass er die Anforderungen genau und verständlich beschreibt, damit sie von den Business-Analysten verstanden werden. Er achtet auch darauf, dass er keine technischen Lösungen in den Anforderungen erwähnt. (HZ 1.1, 1.2)

2. Erstellt eine geeignete visuelle Darstellung für die Programmierung von Anforderungen.

Aus den Anforderungen kann Paul Muster die ungefähre Logik des Programms ableiten. Er kann den Ablauf visuell darstellen mit einem Activity Diagramm, damit er seinen Vorschlag auch den Business-Analysten zeigen kann. (HZ 3.1, 3.2)

3. Leitet aufgrund der Vorgaben die erforderlichen Daten (Eingabe, Verarbeitung, Ausgabe und ihre Datentypen) ab.

Paul Muster kann aus den beschriebenen Anforderungen die nötigen Eingaben vom Benutzer ableiten, sowie was die Ausgabe des Programms sein soll. Er kann daraus auch die notwendigen Variablen und ihre Datentypen bestimmen.(HZ 2.2) Mithilfe der Logikbeschreibung (Activity Diagramm) kann er weitere nötige Daten für die Verarbeitung und Ausgabe bestimmen.(HZ 2.3)

4. Implementiert die Applikation mit Hilfe von Kontrollstrukturen und selbst erstellten Funktionen.

Paul Muster kann in seinem Code die notwendingen Kontrollstrukturen (if-statemtents, loops) für die Logik einsetzen. (HZ 4.2, 4.4) Er achtet darauf, dass redundante Code-Abschnitte in Funktionen ausgegliedert werden. (HZ 4.6) Er gliedert seinen Code in wiederverwendbare Abschnitte (Funktionen). Er findet sich in der IDE zurecht und kann Fehler und Warnmeldungen korrekt interpretieren - z.Bsp.wenn er Kontrollstrukturen an einer falschen Stelle im Code einsetzt oder schreibt. (HZ 4.5)

5. Hält vorgegebene Konventionen ein, kommentiert den Code und achtet dabei auf die Wartbarkeit.

Das Software-Team erklärt Paul Muster die Code-Conventions im Team. So muss z.Bsp. stets der Autor und eine kurze Beschreibung in jedem Programm stehen. Funktionen werden vorgängig kommentiert. (HZ 5.1) Paul Muster schreibt klare Kommentare, damit sein Code auch später verstanden wird. (HZ 5.2)

6. Interpretiert Mängel (Fehler) in der Software und korrigiert diese.

Paul Muster kann Fehler beim Ausführen des Programms ausfindig machen, indem er einen Debugger einsetzt. (HZ 6.1) Paul Muster fragt in seinem Team nach einem Code-Review, damit er eine Meinung zu seinem Code erhält. Im Code-Review Gespräch wird klar, dass ein Code-Abschnitt sehr umständlich geschrieben ist. Paul kann nun den Code effizienter und klarer gestalten.(HZ 6.3)