Software Engineering Flashcards
1
Q
Herkunft des Software Engineering
A
Softwarekrise Ende der 1960er-Jahre; Softwarekosten übersteigen Hardwarekosten; Scheitern von Projekten an Software: NATO-Konferenz 1968 in Garmisch
2
Q
Merkmale guter Software
A
- Wartbarkeit
- Effizienz
- Benutzerfreundlichkeit
- Zuverlässigkeit
3
Q
Definition Ian Sommerville
A
Technische Disziplin, die sich mit allen Aspekten der Softwareherstellung beschäftigt (von Systemspezifikation bis zur Wartung nach Inbetriebnahme)
4
Q
Aktuelle Herausforderungen
A
Heterogene Umgebungen(z.B. Webentwicklung; kurze Projektzielzeiten, Verlässlichkeit –> Therac-25)
5
Q
Kritische Systeme Definition
A
Menschen oder Wirtschaft:
- sicherheitskritisch: Atomkraftwerk, einige Fahrassistenzsysteme
- aufgabenkritisch: Navigationssysteme
- Geschäftskritisch: ERP-System
6
Q
Entwicklung kritischer Systeme
A
- ausgereifte Technologien
- hohe Testkosten (exponentieller Verlauf)
- Gesamtsystem im Blick (Therac-25)
7
Q
Software Engineering Code of Ethics and Professional Practice
A
ACM and the IEEE-CS
Sinnvoll, teilweise idealistisch
8
Q
Vorgehensmodelle
Software Process Models
A
- Standards für IT-Projekte, d.h. Projektphasen, -organisation, Dokumente, Kommunikationsbeziehungen und Methoden
- teilweise Tailoring möglich
- auch spezialisierte Vorgehensmodelle wie Raymonds Bazaar für Open Source Projekte
9
Q
Zweck von Vorgehensmodellen
A
- Erfahrungsbündelung
- Grundstruktur für Projektplanung
- Assessment
10
Q
Wasserfallmodell
A
- Ablauf: Anforderungen –> Design –> Implementierung –> Test –> Inbetriebnahme
- Vorteile: leicht verständlich, Qualitäts- und Zeitkontrolle durch Meilensteine
- Nachteil: keine Rückkopplung -> keine Änderung möglich, kein Prototyp -> kein frühzeitiger Test, kein Kundenfeedback -> kéine Erkennung von Missverständnissen
11
Q
V-Modell des Bundes
A
- Vorgehensmodell für öffentliche IT-Systeme
- Umfangreiche Weiterentwicklung (agil, iterativ)
- sehr umfangreich
12
Q
Inkrementell-iterative Methoden
A
- Initial nur Kernfunktionalität
- Ergänzung in mehreren Iterationen
- Zwischenprodukte als Prototypen
- Vorteil: frühe Fehlererkennung
- Nachteil: Wegwerfaufwand z.B. Web-Frontend
13
Q
Spiralmodell nach Barry Boehm
A
- 4 Quadranten:
1. Zieldefinition
2. Risikoabschätzung
3. Implementierung und Test
4. Planung des nächsten Zyklus
14
Q
Rational Unified Process (RUP)
A
- Vorgehensmodell für objektorientierte Softwareentwicklung mittels UML
- frei verfügbares Vorgehensmodell mit kostenpflichtigen Werkzeugen von Rational
- Vorteile: frühe Fehlererkennung durch Iteration, aktuelle Methoden, für objektorientierte Software mit Komponentenarchitektur, Parallelisierung möglich, Verfügbarkeit unterstützender(kostenpflichtiger Tools)
- Nachteile: Komplex, nur für OOP, nur Tools von Rational
15
Q
Agile Vorgehensmodelle
A
- seit Jahrtausendwende, Agiles Manifest mit 4 Values und 12 principles
- inkrementell-iterativ mit dynamischer Festlegung mithilfe von Kundenfeedback und Projektfortschritt
- Grundsätze: Softwareentwicklung vor Bürokratie (Strukturierung, Formalisierung, Dokumentation), Vertrauen vor detaillierter vertraglicher Absicherung (Einbindung der Anwender), Mensch vor Prozessen und Werkzeugen, Kundenzufriedenheit vor überholten Zielen (Flexibilität)
- Ausprägungen:
Crystal Clear/Crystal Family: Verschiedene Varianten je nach nach Risiko, Häufige Releases und Integration, Ähnlichkeit zu XP
Software Kanban: DevOps, Transparenz, Kapazitäten in Echtzeit, Jira, Visualisierung, weniger Struktur als Scrum
Feature-driven development: (FDD), eher klassisch, leichter einzuführen
Test-driven development: (TDD), gegen mangelhafte Testabdeckung, Tests vorher
Rapid-application development: (RAD) Spiralmodell Barry Boehm, schnell, Interaktion
Lean software development: Toyota, Eliminate waste, decide/deliver as late/fast as possible, amplify learning, empower the team, build integrity in, optimize the whole
16
Q
Extreme Programming (XP)
A
- bekannteste agile Methode
- Entwickler und Anwender in einem Raum –> Zyklusgeschwindigkeit
- 40-Stunden-Woche für maximale Produktivität
- Refactoring des Codes
- Entwicklungsstandards
- 2er Teams
- einfachste Lösung vor raffiniertester
Fazit: v.a. für kleinere Projekte in internen IT-Abteilungen
17
Q
Scrum
A
- Idee: Projektmanagement statt konkreter Praktiken
- Verantwortung beim Team, das sich selbst Richtlinien gibt
- Pre-Game: Teamzusammenstellung, Standards und Werkzeuge, Product Backlog durch Product Owner
- Game: Produkterstellung in Sprints, jeweils Sprint Planning Meeting für Sprint Backlog (-> Product Backlog), Daily Scrum(erreicht, will erreichen, blockiert), Sprint Review mit Product Owner und Stakeholder
- Post-Game: Dokumentation, Systemtest, User Acceptance Test
18
Q
SCRUM-Versionen
A
Problem: Skalierbarkeit über 1 Team hinaus(Chaos), Product Manager, lange Planungshorizonte, Prinzipien für Management
- Large Scale scrum (LeSS): skalierbar für große Produktgruppen
- Nexus Scrum: 3-9 Scrum Teams für 1 Produkt, Abhängigkeitsvermeidung untereinander
- Scrum at Scale: beliebig viele Teams, Daily Scrum auch untereinander, zusätzliche Rollen, Ergebnistypen und Termine
- Disciplined Agile Delivery (DaD): Initiierungs- und Transitionsphase umgeben Game; Elemente aus XP, RUP, Kanban, Lean Software
- Scaled Agile Framework (SAFe): Essential, Large, Portfolio
19
Q
Scrum - Rollen:
A
- Scrum-Master: Einhaltung der Scrum-Regeln, weder Teammitglied noch -leiter, Ansprechpartner für Teammitglieder
- Product Owner: Kundenkommunikation, Product Backlog, Projektziele durch User Stories
- Projektteam: Aufwandschätzung Backlog
20
Q
Continuous Integration
A
- mehrfach täglich neue Versionen
- automatisierte Builds
- automatisierte Tests
Vorteil: sofortige Fehlererkennung
Nachteil: letze stabile Version schwierig zu finden
21
Q
DevOps
A
Gemeinsame Ziele, Abläufe und Werkzeuge für Entwicklungsprojekte und Systembetrieb
Toolchain: Create, Verify, Package, Release, Configure, Monitor, Plan
22
Q
Lasten- und Pflichtenheft
A
- Lastenheft: Funktionale/Nicht-funktionale Anforderungen aus Sicht der Auftraggebers, Grundlage für Angebote
- Pflichtenheft: detaillierteres Realisierungsvorhaben aus Sicht des Auftragnehmers, Kriterien für Abnahme
23
Q
Softwaredesign
A
Gestaltung der Benutzeroberfläche, aber auch Architektur- und Strukturentscheidungen
24
Q
Verteilte Systeme
A
- mehrere Rechner mit gleichzeitigen Prozessen
- Vorteile: Skalierbarkeit, Fehlertoleranz
- Nachteile: Komplexität, Zugriffschutz auf Datenverkehr
25
Architekturdesign: dezentrale Datenhaltung
Vorteile: Zugriffszeiten, Offline-Funktionalität
Nachteile: komplexe Kommunikation zwischen Subsystemen, Datensicherung, Datenschutz, Datenkonsistenz, Zugriffskontrolle
26
Client-Server-Architektur
- zentraler Server (Rechenzentrum) und separate Benutzer-Clients
- 2-Tier-Modell: Thin-(einfaches Systemmanagement) und Fat-Client(effiziente Lastverteilung) je nach Anwendungsverarbeitung --> auch Webapplikationen
- 3 -Tier-Modell: Datenbankserver(Persistenz), min. 1 Applikationsserver, Clients (Benutzereingaben und Bildschirmdarstellung
27
Softwareanforderungen
- schriftlich gegen Mißverständnisse
- funktional: Eingaben, Situationen
- nichtfunktional: Zeiten, Standards, Kompatibilität --> smart!
- als Sprache(Nachteile!), Formulare, graphischen Modelle
Stakeholder: Kunden, Legacy-Entwickler, Benutzer, Entwickler ähnlicher Systeme, Experten
28
GUI
- Graphical User Interface: Benutzeroberfläche
- große Rolle für Zuverlässigkeit
- Abwanderung im Web
- Screen Prototypes
- User Acceptance Test für Usability
```
- Grundregeln:
Benutzervertrautheit
Konsistenz
Minimale Überraschung
Wiederherstellbarkeit
Benutzerführung
Benutzervielfalt
```
29
Typen von Softwaresysteme
- ereignisverarbeitend: ständige und sofortige Reaktion auf Nutzereingaben, hauptspeicherintensiv z.B. Echtzeitsystem, Grafik-und Officeprogramme
- batchverarbeitend: stückhafte Verarbeitung von Daten ohne Nutzereingabe, EVA-Architektur, z.B. täglicher Rechnungsdruck im ERP
- transaktionsverarbeitend: Schreib- und Lesezugriffe auf großen Datenbestand, 3-Tier-Modell, z.B. Auftragserfassung im ERP
- sprachverarbeitend: Anweisungsabarbeitung in formaler Sprache,
Komponenten für Prüfen, Auswerten und Ausführen, z.B. Compiler und Skriptinterpreter
30
Besonderheiten von Web-Applikationen
- Personalisierung
- harte Deadlines (z.B. Messen, Veranstaltungen)
- fachbereichübergreifende Teams
- Technologievielfalt (JS, HTML, CSS, JAVA, DB)
- externe Dienstleister
- direkte Konkurrenz (Abwanderung)
- Schnittstelle zu ERP-Systemen
- schwer zu prognostizierende Auslastung
31
Softwarewiederverwendung
- Kriterien: Entwicklungszeit, Nutzungsdauer(-> Wartung), Kompetenz des Entwicklungsteams, Kompromissbereitschaft der Kunden
- z.B. Wrapper um Legacysysteme, Entwurfsmuster, Aspektorientierte Softwareentwicklung, Komponentenbasierte Entwicklung, Programmbibliotheken, Programmgeneratoren, Verbindung/Integration von Standardsoftware
-
32
Komponentenbasiertes SE
- mittelgroße Komponenten als Blackbox(Klassen)
- Inkompatibilitäten
- v.a. unternehmensintern, z.B. Login, Suche, Sicherheitsfunktionen
33
Testprinzipien
- Black-Box/White-Box: Spezfikation/Aufbauwissen
- Anforderungsbasiert: Use Cases -> Test Cases
- Klassenbasiert: Einteilung in Äquivalenzklassen je nach Ein- und Ausgabewert
- Strukturell: Grenzfälle (mittlerer Wert bei binärer Suche)
- Pfadüberdeckung: alle möglichen Ausführungspfade
- Testen auf Zufallswerte: eher ergänzend
- CRUD: Datenbasiertes Testen nach Objektlebenszyklus
34
Verifikation und Validierung
- Verifikation der Anforderungserfüllung
- Validierung hinsichtlich der Zufriedenheit
- besonders wichtig bei kritischen Systemen
35
Software Reengineering
- Neuentwicklung eines Legacy-Systems ohne Funktionalitätsänderung
- Vorteil: geringere Kosten und Risiko als bei vollständiger Neuentwicklung
- Nachteil: keine neuen Funktionen --> meistens Vorrang
36
Defensive Programming
- Voraussetzungsüberprüfung vor Erfüllung des Selbstzwecks
- Voraussehen möglichst vieler Umstände und Misstrauen
- robust gegenüber Verstößen, durchlaufen oder geordent abbrechen
- Art des Exception Handlings
z. B. Benutzereingabe auf Fehler hinweisen
37
Nicht-funktionale Tests
- Lasttest/Stresstest
- Usability-Test
- Recovery-Test (-> Datenintegrität)
- Sicherheitstest (-> Penetration Testing)
38
Teststufen
- Unittest (Schnittstellentest)
- Integrationstest/Systemtest: mit Quellcodezugriff, Performance
- Auslieferungstest: ohne Quellcodezugriff, Funktionalität und Usability
- Alphatest: interner Auslieferungstest
- Betatest: eingeschränkter Testbenutzerkreis
- Regressionstest: Testen einer neuen Version, auch der unveränderten Teile
39
Testwerkzeuge
- Statische Codeanalyse mit Bug Tracking Tools: Automatisierte Untersuchung des Quellcodes auf typische, wiederkehrende Fehler z.B. Datentypen
- Dynamische Analyse z.B. Speicherverbrauch
- Testautomatisierung: aufwändig, deshalb v.a. Regressionstests und Lasttests
40
Standardsoftware
- Definition: Universell, Festpreis, minimierter Anpassungsaufwand
- Voraussetzung: standardnahe Anforderungen
- Anpassung "Customizing" durch Parameter, integrierte Entwicklungsumgebungen (ABAP), Plattformen und Schnittstellen
41
Vorteile Standardsoftware
- Zukauf von Expertise
- Kosten abschätzbar
- Wartungsaufwand abschätzbar
- kein Personalaufwand
- schnellere Implementierung
- ausgereifte Software
- Service, Doku, Schulung, Entwicklung aus einer Hand -> Synergie
- Integration, Schnittstellen -> alles aus einer Hand
- Experten auf dem Arbeitsmarkt verfügbar
42
Nachteile Standardsoftware
- Performance/Hardwarebedarf: Individuallösung schlanker
- Akzeptanz
- Inkompatibilitäten mit bestehenden Systemen
- Auswahlverfahren
- nicht verfügbar für spezielle Anforderungen
--> Best of Breed
43
Framework
- Def.: Programmiergerüst oder Ordnungsrahmen, extensible Skeleton
- inversion of Control: Hauptprogramm bei der Koordination und Sequenzierung der Anwendungsaktivität, Dependency Injection
- modular, wiederverwendbar, skalierbar
- spezielle Applikationsdomäne(Zweck)
- z.B. Hibernate für Persistenz in Web-Applikationen
44
Service-orientierte Architektur
- Art der Wiederverwendung mit Komponenten mittlerer Größe
- Komponenten als eigenständige Dienste im Netzwerk
- Standardprotokolle zur Kommunikation untereinander und nach außen
- -> plattform- und sprachenunabhängig
- aktuell: v.a. in geschlossenen Netzwerken statt öffentlich verfügbar
45
XML-Standards für SOA
- SOAP: Simple Object Access Protocol, Format der ein- und ausgehenden Nachrichten
- UDDI: Universal Description, Discovery and Integration, Format zur Suche nach Services und Informationsorganisation
- WSDL: Web Services Description Language, Servicebeschreibung
--> REST: Representational State Transfer, leichtgewichtige, aktuelle Alternative zu SOAP/UDDI/WSDL
46
Entwurfsmuster (Design Pattern)
- Wiederverwendung von abstrakten Konzepten
- 4 Elemente: Name, Domäne, Lösungsbeschreibung(oft UML), Konsequenzen(Beschränkung, Ineffizienzen)
- z.B. Model-View-Controller, Dependency Injection über Frameworks
47
Aspektorientierte Entwicklung (AOSD)
- Aufteilung in Komponenten nach Anforderungen --> Separation of Concerns!
- m:n-Beziehungen dennoch unvermeidbar --> crossing concerns(Authentifizierung, Logging, Sicherung)
- Konzept der Aspekte: Kapselung von mehrfach vorkommender Funktionalität --> Unabhängigkeit, Wiederverwendbarkeit
- Verifikation und Validierung: bei White-Box-Tests unabhängige Testung der Aspekte --> einzelne Testbarkeit der Advices, systematisches Ausprobieren aller Kombinationen von Aspekten und der Join Points
48
Aspekt
- 2 Bestandteile:
Advice: Quellcode
Pointcut: Definition, an welchen Join Points der Aspekt eingefügt werden soll
- Join Points:
- vor oder nach dem Aufruf von Methoden oder Konstruktoren
- Zugriffe auf bestimmte Attribute oder Objekte
- Initialisierung von Objekten
- Exceptions
49
Einweben von Aspekten
allgemein: durch Aspect Weaver
- bei Quellcodeverarbeitung: Einbau in den Code vor Kompilierung
- beim Linken: Einbau "in den Compiler"
- zur Laufzeit: Hintergrundüberwachung der Join Points und ggf. Ausführung des Advice
