1
Q
Was ist Software?
A
ICS = Information and Communication Software
- Computerprogramme und ihre dazugehörige Dokumentation
- Software wird nur für bestimmte Kunden (individuelle Software) oder für einen allgemeinen Markt (Standardsoftware) entwickelt
- Gute Software soll dem Benutzer die erforderlichen Funktionalitäten und Performance liefern und wartbar, zuverlässig und nutzbar sein
2
Q
Wer braucht Software?
A
• Die meiste Software, die in Organisationen benutzt wird, ist für Leute mit speziellen Bedürfnissen entwickelt worden
- Stakeholder ist jeder, der ein Interesse an der Software hat
- Ein Benutzer ist jemand, der die Software benutzt, um Aufgaben auszuführen
- Manchmal sind Stakeholder Benutzer, aber die meisten Stakeholder nutzen die Software nicht selbst (z.B. ist ein CEO oft an der Entwicklung von Software beteiligt, auch wenn er diese nie benutzt)
3
Q
Wer erstellt Software?
A
• Wird typischerweise von einem Team von Softwareentwicklern entwickelt, bestehend aus:
- Business-Analysten oder Anforderungsanalysten, die Anforderungen an die Software verfassen, indem sie Benutzer oder Stakeholder interviewen
- Designer und Architekten, die die technische Architektur und das System der Software planen, entwerfen und modellieren
- Programmierer, die den Code für die Software schreiben
- Tester, die verifizieren, dass die Software den Anforderungen entspricht und sich wie erwartet verhält
4
Q
Warum schlagen Softwareentwicklungsprojekte oft fehl?
A
- Leute fangen an zu programmieren, bevor sie das Problem verstehen
- Das Team hat eine unrealistische Vorstellung davon, mit wieviel Arbeit die Entwicklung verbunden ist
- Fehler werden früh eingebaut, aber spät entdeckt
- Manager versuchen Qualität in die Software zu „testen“
- Kommunikationsschwierigkeiten zwischen den einzelnen Teammitgliedern
5
Q
Was versichert den Erfolg eines Softwareprojekts?
A
• Anwendung von „Good Engineering Practices“:
- Manager und Teams möchten oft wichtige Engineering Praktiken überspringen (Aufwandsschätzung, Anforderungsakquisation,…)
- Wenn es schneller wäre, die Software ohne diese Praktiken zu erstellen, würde dies niemals verwendet werden
- Grund für die Anwendung dieser Verfahren ist, Zeit zu sparen und die Softwarequalität durch genaue Planung und frühzeitige Erkennung von Fehlern zu verbessern
6
Q
Software Engineering (SE) / Softwareentwicklung
A
- Diziplin, die sich mit allen Aspekten der Softwareproduktion beschäftigt
- Engineering als Disziplin bedeutet die Anwendung geeigneter Theorien und Methoden zur Lösung von Problemen, unter Berücksichtigung organisatorischer und finanzieller Grenzen
- Software Engineering deckt alle Aspekte der Software Produktion ab:
- Technischer Entwicklungsprozess (Hauptaufgabe)
- Projektmanagement, Entwicklung von Tools, Methoden, etc. um die Softwareproduktion zu unterstützen
• Software Engineering ist ein Teil des ICT-Projekt Managements
7
Q
Wichtige Ziele der Softwareentwicklung
A
- Entwicklung von Software nach festgelegten Qualitätsstandards
- Vermeidung von schlimmen Verzögerungen und Überschreitungen des Budgets
- Anpassung an sich verändernde Anforderungen bei Einhaltung von Budget und Terminen
8
Q
Software-Projektplanung: Vision and Scope Document
A
- Eines der wichtigsten Werkzeuge eines Projektmanagers
- Ermöglicht den Stakeholdern und Entwicklern ein gemeinsames Verständnis von den Bedürfnisse, die die Software erfüllen muss
- Typische Dokumentengliederung:
- Problemstellung
a) Projekthintergrund
b) Interessengruppen (Stakeholder, User etc)
c) … - Vision der Lösung
a) Vision Statement
b) Liste der Features
c) …
9
Q
Projektplan
A
• Wird von vielen Leuten in einer Organisation verwendet
- Projektmanager: Kommunikation des Projektstatus an die Stakeholder, Planung der Teamaktivitäten
- Teammitglieder: Kontext ihrer Arbeit verstehen
- Stakeholder: Sicherstellen, dass Projekt auf Kurs ist
• Projektplan besteht aus
- Leistungsbeschreibung (Statement of Work / SOW): Liste der zu entwickelnden Funktionen und deren geschätzte Entwicklungszeit
- Ressourcenliste: Liste aller Ressourcen, die für das Projekt benötigt werden
- Work Breakdown Structure: Liste der Aufgaben, die für die Entwicklung wichtig sind
- Projektzeitplan: Zuordnung der Ressourcen und Zeit zu einer benötigten Aufgabe
- Risikoplan: Risiken, die das Projekt bedrohen und potenzielle Lösungen
10
Q
Scheduling (Entwicklung eines Projektplans)
A
- Zuordnung der Ressourcen zu den Aufgaben
- Identifizieren von Abhängigkeiten zwischen den Aufgaben
- Entwicklung eines Plans
- Scheduling: Benötigter Aufwand und Ressourcenallokation der Aufgaben sowie Abhängigkeiten zw. Aufgaben müssen bekannt sein
- Forward Calculation:
- Earliest Start Schedule (ES) wird bestimmt
- Earliest Finish Schedule (EF) kann auf Basis von ES (und Länge und Abhäng. der Aufgaben) berechnet werden
• Backward Calculation:
- Finish Schedule wird bestimmt
- Die späteste (latest) Start Schedule kann auf Basis der EF (und Länge und Abhäng. der Aufgaben) berechnet werden
11
Q
Slack und kritischer Pfad
A
Slack = Pufferzeit
• Slack einer Aktivität:
- Total Slack: zulässige Verzögerung einer Aktivität ohne eine Verletzung des Projekttermins
- Free Slack: zulässige Verzögerung einer Aktivität, die keinen Einfluss auf den frühsten Start einer Nachfolgeaktivität hat
- Kritische Aktivität: Aktivität ohne Slack
- Kritischer Pfad: Pfad innerhalb eines Netzwerkplans, der nur kritische Aktivitäten enthält
12
Q
Risikoplan
A
- Liste von allen Risiken, die das Projekt bedrohen, zusammen mit einem Plan, der die Risiken abwenden kann
- Einen Risikoplan entwerfen:
- Brainstorming von potenziellen Risiken
- Ermitteln der Bedeutsamkeit jedes Risikos
- Erstelle einen Abschwächungsplan
13
Q
Software Engineering Prozess - Ansätze
A
- Es gibt viele verschiedene Arten von Software und es gibt kein universelles Set von SE Methoden, die auf alle Arten anwendbar sind
- Welche Arten von Software-Engineering-Methoden anzuwenden sind, hängt ab von:
- Art der zu entwickelten Anwendung
- Anforderung des Kunden
- Hintergrund des Entwicklerteams
- Software Engineering Process: Strukturiertes Set von Akitivtäten, um eine Software zu entwickeln
- Alle Software Engineering Prozesse weisen folgende Aspekte auf:
- Anforderungs-Spezifikationen
- Design und Implementierung
- Validierung (Evaluation der Features im Bezug auf die Anforderungen)
- Evolution (Modifizieren der Software im Bezug auf Kundenbedürfnisse)
14
Q
Software Anforderungen
A
- Softwareanforderungen spezifizieren das gewünschte Verhalten einer Software
- Anforderungsanalysten erstellen Softwareanforderungen durch Anforderungserhebungen (z.B. Interviews mit den Nutzern & Stakeholdern, Beobachtung der Nutzer bei der Arbeit)
- Softwareanforderungen sollten in einer Software-Anforderungsspezifikation dokumentiert werden, die dem entsprechenden IEEE Standard entspricht
15
Q
Use Cases
A
- Eine Beschreibung einer bestimmten Interaktion, die ein Benutzer mit einer Software haben kann
- Sind einfache Mittel, um die Funktionalität einer Software zu beschreiben
- Beschreiben weder interne Abläufe der Software, noch erklären sie, wie die Software implementiert wird
Funktionale versus nicht funktionale Anforderungen:
- Funktionale Anforderungen definieren das explizit wahrnehmbare Verhalten einer Software (Einloggen, Berechnung, etc)
- Nicht-funktionale Anforderungen definieren Merkmale einer Software, die ihr Verhalten nicht beeinflussen (Qualitätsattribute, z.B. Benutzerfreundlichkeit, Leistung, Fehlerbehandlung)
16
Q
Design und Implementierung
A
- Vision and Scope dokumentiert die Bedürfnisse einer Organisation
- Anforderungen geben das erforderliche Verhalten von Software an, um diese Bedürfnisse zu erfüllen
- Design legt fest, wie Softwareanforderungen technisch umgesetzt werden sollen
17
Q
Validierung durch Test Cases
A
- Ein Test Case spezifiziert einen Benutzertest, um ein bestimmtes Softwareverhalten zu bewerten/evaluieren
- Test Case sind Use Cases sehr ähnlich
- Ein Testplan ist eine Liste aller erforderlichen Test Cases, die durchlaufen werden müssen, um die Funktionalität einer Software anhand ihrer spezifischen Anforderungen zu bewerten
- Ein typischer Test Case ist in einer Tabelle dargestellt und beinhaltet:
- Einen eindeutigen Namen und eine eindeutige Nummer, eine kurze Beschreibung
- Eine Beschreibung des Status der Software vor dem Test
- Schritte, die die Interaktion während des Tests ausmachen
- Erwartete Ergebnisse, die den erwarteten Status bzw. das erwartete Verhalten der Software definieren
18
Q
Evolution durch Change Control
A
- Change Control ist eine Methode, um nur diejenigen Änderungen zu implementieren, die es wert sind, weiterverfolgt zu werden, während unnötige oder teure Änderungen daran gehindert werden, das Projekt entgleisen zu lassen
- Einrichten eines Change Control Boards: Projektmanager - Wichtige Stakeholder, Designer, Programmierer, Tester etc
- Change Control Board entscheidet, welche der beantragten Änderungen umgesetzt werden
19
Q
Plangesteuertes vs. Agiles Software Development
A
- Plangesteuertes SD besteht aus Prozessen, in denen alle Aktivitäten im Voraus geplant wurden und der Fortschritt an diesem Plan gemessen wird
- In agilen Prozessen ist die Planung inkrementell und es ist einfacher, den Prozess zu ändern und den Kundenanforderungen anzupassen
• In der Praxis enthalten die meisten praktischen Prozesse Elemente beider Ansätze
20
Q
Software Development Process Modelle
A
- Beschreiben den Entwicklungsprozess, durch Definierung der einzelnen Schritte und Ergebnisse der Entwicklung
- Festlegen von Prinzipien, Methoden und Tools für den Entwicklungsprozess
- Festlegen einer chronologischen Sequenz für Planung, Entwicklung und Implementierung
Arten:
- Sequenzielle Modelle: Aufeinanderfolgende Phasen mit zunehmender Granularität (Detailgenauigkeit) und Meilensteine als Ergebnis von Phasen
- Modifizierte sequentielle Modelle: Phasen werden mit zunehmender Granularität und Meilensteinen als Phasenfolge verschachtelt (nicht mehr linear)
- Evolutionäre Modelle: Keine Phasen mit definierten Ergebnissen, stattdessen iterative (wiederholende) Zyklen von Design, Implementierung und Validierung
- Agile Modelle: Nur ein allgemeiner Rahmen für einen Ansatz; weniger Regeln, sehr flexible, dynamische Phasen
21
Q
Sequentielle Modelle: Das Wasserfallmodell
A
- Es gibt sehr viele Versionen
- Nach jeder Phase werden ein oder mehrere Dokumente erstellt, auf denen man sich „abmelden“ muss
- „Wasser fließt nicht hoch“ -> Es ist schwer, Aktionen einer abgeschlossenen Phase nachträglich zu ändern
- Ansatz sollte nur verwendet werden, wenn die Anforderungen klar und gut verstanden sind
- Spiegelt traditionelle Ingenieurspraxis wider
- Einfacher Managementansatz
22
Q
Modifizierte Sequentielle Modelle: Das V-Modell
A
- Ähnelt dem Wasserfallmodell, macht aber die Abhängigkeit zwischen Entwicklung und Verifikation explizit
- Linke Hälfte des V repräsentiert die Entwicklung und die rechte Hälfte die Systemvalidierung
- Anforderungsspezifikationen umfassen die Anforderungserhebung und die Analyse
23
Q
Evolutionäre Modelle
Das Spiralmodell
A
• Grundkonzept:
- Entwickelung einer Implementierung
- Implementierung wird dem Benutzer demonstriert
- Verfeinerung auf Grundlage des Feedback des Benutzers, bis ein adäquates System entsteht
- Zwei Arten von Entwicklungsmodellen: Explorativ und Wegwerfprototyping
- Vorteile: Schätzungen von Budget, Zeitplan, usw. wird mit fortschreitender Arbeit realistischer
- Nachteile: Erfordert Fachwissen in Risikobewertung - Nur für große Systeme geeignet
24
Q
Agile Modelle
A
Eigenschaften:
- Nur ein allgemeiner Entwicklungsrahmen
- Starke Integration des Kunden und Interaktion mit dem Kunden während des Entwicklungsprozesses
- Kurze Entwicklungszyklen
- Kontinuierliche Änderung der Anforderungen
- Direkte und informelle Kommunikation zwischen den Projektteilnehmern
- Wenig Dokumentation
- Erfordert hohe Disziplin der Teilnehmer
- Gut anwendbar für innovative Projekte und wenn Spezifikationen unsicher sind bzw. ständigen Veränderungen unterliegen
25
SCRUM
26
Wie heißt die Mutter von Nicki Lauda?
Mama Lauda
PWIN WS 2018/19
flashcards
Decks in class (10)
# Cards
