Brainscape's Knowledge GenomeTM

Browse over 1 million classes created by top students, professors, publishers, and experts.


See full index

Software Engineering > Software Engineering > Flashcards

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

Merkmale guter Software

A
  • Wartbarkeit
  • Effizienz
  • Benutzerfreundlichkeit
  • Zuverlässigkeit
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Definition Ian Sommerville

A

Technische Disziplin, die sich mit allen Aspekten der Softwareherstellung beschäftigt (von Systemspezifikation bis zur Wartung nach Inbetriebnahme)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Aktuelle Herausforderungen

A

Heterogene Umgebungen(z.B. Webentwicklung; kurze Projektzielzeiten, Verlässlichkeit –> Therac-25)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

Kritische Systeme Definition

A

Menschen oder Wirtschaft:

  • sicherheitskritisch: Atomkraftwerk, einige Fahrassistenzsysteme
  • aufgabenkritisch: Navigationssysteme
  • Geschäftskritisch: ERP-System
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

Entwicklung kritischer Systeme

A
  • ausgereifte Technologien
  • hohe Testkosten (exponentieller Verlauf)
  • Gesamtsystem im Blick (Therac-25)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Software Engineering Code of Ethics and Professional Practice

A

ACM and the IEEE-CS

Sinnvoll, teilweise idealistisch

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

Zweck von Vorgehensmodellen

A
  • Erfahrungsbündelung
  • Grundstruktur für Projektplanung
  • Assessment
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

V-Modell des Bundes

A
  • Vorgehensmodell für öffentliche IT-Systeme
  • Umfangreiche Weiterentwicklung (agil, iterativ)
  • sehr umfangreich
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

Spiralmodell nach Barry Boehm

A
  • 4 Quadranten:
    1. Zieldefinition
    2. Risikoabschätzung
    3. Implementierung und Test
    4. Planung des nächsten Zyklus
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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
Q

Architekturdesign: dezentrale Datenhaltung

A

Vorteile: Zugriffszeiten, Offline-Funktionalität

Nachteile: komplexe Kommunikation zwischen Subsystemen, Datensicherung, Datenschutz, Datenkonsistenz, Zugriffskontrolle

26
Q

Client-Server-Architektur

A
  • 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
Q

Softwareanforderungen

A
  • 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
Q

GUI

A
  • 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
Q

Typen von Softwaresysteme

A
  • 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
Q

Besonderheiten von Web-Applikationen

A
  • 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
Q

Softwarewiederverwendung

A
  • 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
Q

Komponentenbasiertes SE

A
  • mittelgroße Komponenten als Blackbox(Klassen)
  • Inkompatibilitäten
  • v.a. unternehmensintern, z.B. Login, Suche, Sicherheitsfunktionen
33
Q

Testprinzipien

A
  • 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
Q

Verifikation und Validierung

A
  • Verifikation der Anforderungserfüllung
  • Validierung hinsichtlich der Zufriedenheit
  • besonders wichtig bei kritischen Systemen
35
Q

Software Reengineering

A
  • 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
Q

Defensive Programming

A
  • 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
Q

Nicht-funktionale Tests

A
  • Lasttest/Stresstest
  • Usability-Test
  • Recovery-Test (-> Datenintegrität)
  • Sicherheitstest (-> Penetration Testing)
38
Q

Teststufen

A
  • 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
Q

Testwerkzeuge

A
  • 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
Q

Standardsoftware

A
  • Definition: Universell, Festpreis, minimierter Anpassungsaufwand
  • Voraussetzung: standardnahe Anforderungen
  • Anpassung “Customizing” durch Parameter, integrierte Entwicklungsumgebungen (ABAP), Plattformen und Schnittstellen
41
Q

Vorteile Standardsoftware

A
  • 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
Q

Nachteile Standardsoftware

A
  • Performance/Hardwarebedarf: Individuallösung schlanker
  • Akzeptanz
  • Inkompatibilitäten mit bestehenden Systemen
  • Auswahlverfahren
  • nicht verfügbar für spezielle Anforderungen

–> Best of Breed

43
Q

Framework

A
  • 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
Q

Service-orientierte Architektur

A
  • 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
Q

XML-Standards für SOA

A
  • 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
Q

Entwurfsmuster (Design Pattern)

A
  • 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
Q

Aspektorientierte Entwicklung (AOSD)

A
  • 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
Q

Aspekt

A
  • 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
Q

Einweben von Aspekten

A

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

Software Engineering (2 decks)

Brainscape helps you reach your goals faster, through stronger study habits.
© 2024 Bold Learning Solutions. Terms and Conditions