Software Engineering
HTWG - SE - Mündliche Prüfung
HTWG - SE - Mündliche Prüfung
Fichier Détails
| Cartes-fiches | 21 |
|---|---|
| Langue | Deutsch |
| Catégorie | Informatique |
| Niveau | Université |
| Crée / Actualisé | 13.01.2014 / 14.02.2016 |
| Lien de web |
https://card2brain.ch/box/software_engineering2
|
| Intégrer |
<iframe src="https://card2brain.ch/box/software_engineering2/embed" width="780" height="150" scrolling="no" frameborder="0"></iframe>
|
Wer ist der Erschaffer und Erfinder von Extreme Programming?
Wer sind die Hauptentwickler vom Testing-Framework "JUnit"?
Von wem wurden Design Pattern zuerst beschrieben?
Was beschreiben Design Pattern im Bereich der Software Entwicklung?
Welches Design Pattern kann als Ersatz von langen Switch-Case-Statements eingesetzt werden.
Welches Pattern eignet sich, um mehrere Objekte bei einer Änderung des Zustandes zu benachrichtigen?
Für welches Szenario eignet sich das Decorater Pattern?
Was wird mit dem Command Pattern erreicht?
Welches Design Pattern definiert eine vereinfachte Schnittstelle zur Benutzung eines Systems oder einer Menge von Objekten?
Welche Methode zur Kostenschätzung geht auf Barry (W.) Boehm zurück?
Dinge die du über die Delphi-Methode wissen solltest
- Erfahrene Entwickler/SArchitekten kommen zusammen
- Jeder schätzt die Kosten für das Projekt
- Geschätzte Kosten werden diskutiert (Komplexität, Ideen zur Implementierung etc)
Das CoCoMo-Model
- COnstructive COst MOdel
- Diese Methode ist am weitesten verbreitetet
- entwickelt von Barry Boehm 1981
- bekannt als COCOMO 81
COCOMO: Drei Modi
COCOMO hat 3 verschiedene Modi, die die Komplexität des Projekts bestimmen sollen:
- Organic Mode (simple)
- Semidetached Mode
- Embedded Mode
COCOMO: Organic Mode
- kleine bis mittelgroße Softwareprojekte
- beteiligte Mitarbeiter haben bereits Erfahrung mit ähnlichen Projekten
- Spezifikationen und Schnittstellen werden nicht so streng gehandhabt
- stabile Entwicklungsumgebungen, wenige, für die Entwickler, neue Technologien werden verwendet
COCOMO: Semidetached Mode
- für Projekte zwischen Organic und Embedded Mode
- mittelgroße Projekte (zwischen 50 und 300 KDSI)
- Beteiligte haben bereits ein mittleres Maß an Erfahrung in der Entwicklung solcher Projekte
- Team besteht aus erfahrenen und unerfahrenen Entwicklern
COCOMO: Embedded Mode
- zeichnet sich durch straffe, unflexible Strukturen und Richtlinien aus (Hauptunterschied zu organic u. semidetached)
- oft für sicherheitsrelevante Projekte (z. B. Flugassistenzsysteme, Systeme für Banken)
- zeichnen sich oft durch lange Design- und Analysephasen aus
- neue Technologien und Entwicklungsumgebungen sind notwendig
COCOMO: Annahmen / Voraussetzungen
- Primärer Kostenfaktor (Cost-Driver) ist die Anzahl delivered code instructions (DSI)
- Das Projekt setzt sauberes und gutes Management voraus. Auch Self-Management von Entwicklern UND Kunden.
- Festgelegte Spezifikationen ändern sich während des Entwicklungsprozesses NICHT (grundlegend).
- KRITIK: COCOCMO berücksichtigt leider nur eine Variable (DSI) und die 3 Modi zur Ermittlung der Kosten!
COCOMO: Berechnung / Gleichungen / Faktoren
Beispiel: Semidetached, 32000 DSI
- Effort: 3.0*32^1.12 = 146 Mann-Monate
- Schedule: 2.5 * 146^0.35 = 14 Monate
- Produktivität: 32KDSI / 146MM = 219 DIS/MM
- Personalbedarf:
COCOMO: Was ist seit der Definition passiert?
- Objektorientierung wurde erfunden / zum Standard
- Modeldriven development
- Software wurde "wiederverwendbar"
- Errungenschaften wie neue Sprachen, Compiler, IDEs, Libraries
kick-ass disadvantages vom WATERFALL-MODEL
- Hauptproblem: Zu lange Feedback-Zyklen
- Schritte im Zyklus zurück sind nicht möglich: (zb Design Phase done, aber später bemerkt man ein Fehler darin)
- es ist alt :D (Es gab zu dieser Zeit noch keine OO usw)
- Nicht geeignet für kontinuierliche Projekte
Spiral Modell
Entwickelt von Barry Böhme (ja, der vom COCOMO-Model) 1985
- das erste Modell mit Interationen (um möglichst schnell Risiken -> Kosten zu entdecken)
