Benutzer-Werkzeuge
se:softwaretechnologie
Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
| Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung Nächste Überarbeitung Beide Seiten der Revision | ||
|
se:softwaretechnologie [2008-02-18 12:14] stefan |
se:softwaretechnologie [2008-02-23 16:48] stefan |
||
|---|---|---|---|
| Zeile 1: | Zeile 1: | ||
| ====== Software-Technologie ====== | ====== Software-Technologie ====== | ||
| + | |||
| ===== Schwerpunkte der Klausur ===== | ===== Schwerpunkte der Klausur ===== | ||
| Zeile 13: | Zeile 14: | ||
| * zwei Entwurfsmuster und eine sonstige Entwurfsmaßnahme einsetzen | * zwei Entwurfsmuster und eine sonstige Entwurfsmaßnahme einsetzen | ||
| * Zuletzt folgen acht Wissensfragen, die nichts mit dem Projekt zu tun haben. | * Zuletzt folgen acht Wissensfragen, die nichts mit dem Projekt zu tun haben. | ||
| + | * Eigene Notizen | ||
| + | * Architekturen | ||
| + | * UML-Spezialitäten | ||
| + | * Einsatz von Entwurfsmustern | ||
| + | * State machines | ||
| ===== Einführung ===== | ===== Einführung ===== | ||
| Zeile 32: | Zeile 38: | ||
| ===== Objektorientierte Systementwicklung ===== | ===== Objektorientierte Systementwicklung ===== | ||
| + | |||
| ==== Anforderungen / Aufwandsermittlung ==== | ==== Anforderungen / Aufwandsermittlung ==== | ||
| Zeile 69: | Zeile 76: | ||
| * Mögliche Verfälschungen (S. 85) | * Mögliche Verfälschungen (S. 85) | ||
| * Tilgung | * Tilgung | ||
| - | * unterspezifizierte Prozessworte | + | * Implizite Annahmen |
| - | * Verallgemeinerung | + | * Unvollständig spezifizierte Prozesswörter |
| + | * Unvollständige Komparative und Superlative | ||
| + | * Modaloperatoren der Möglichkeit | ||
| + | * Modaloperatoren der Notwendigkeit | ||
| + | * Verallgemeinerung (Generalisierung) | ||
| + | * Universalquantoren | ||
| + | * Unvollständig spezifizierte Bedingungen | ||
| + | * Substantive ohne Bezugsindex | ||
| * Verzerrung | * Verzerrung | ||
| + | * Nominalisierung | ||
| * Template | * Template | ||
| * [when][under what conditions] the system (shall | should | will) [be capable of | provide <whom> the ability to] <process> what how | * [when][under what conditions] the system (shall | should | will) [be capable of | provide <whom> the ability to] <process> what how | ||
| Zeile 344: | Zeile 359: | ||
| ==== Wasserfallmodelle ==== | ==== Wasserfallmodelle ==== | ||
| * Klassisch | * Klassisch | ||
| - | # Analyse | + | * Analyse |
| - | # Definition | + | * Definition |
| - | # Entwurf | + | * Entwurf |
| - | # Implementierung | + | * Implementierung |
| - | # Wartung | + | * Wartung |
| * 60 - 80% aller Fehler entstehen in der Analysephase! Analysefehler erzeugen 60 - 70 % der Gesamtkosten! | * 60 - 80% aller Fehler entstehen in der Analysephase! Analysefehler erzeugen 60 - 70 % der Gesamtkosten! | ||
| * erweitert: mit Validierungsphasen | * erweitert: mit Validierungsphasen | ||
| Zeile 436: | Zeile 451: | ||
| ===== Qualität des Entwicklungsprozesses ===== | ===== Qualität des Entwicklungsprozesses ===== | ||
| + | * Process Maturity Levels | ||
| + | * initial | ||
| + | * repeatable | ||
| + | * managed (defined) | ||
| + | * measured (managed) | ||
| + | * optimized (optimizing) | ||
| + | * Capability Maturity Model | ||
| + | * Key Process Areas -> erreichen Ziele | ||
| + | * Common Features -> richten sich an Implementierung und Institutionalisierung | ||
| + | * Key Practises -> beschreiben Infrastruktur und Aktivitäten | ||
| + | * Capability Maturity Model Integration | ||
| + | * modulares Konzept -> Integration neuer Entwicklungsdisziplinen | ||
| + | * staged representation -> CMM | ||
| + | * continuous representation -> Bewertung einzelner Prozessbereiche | ||
| + | * Prozessbereiche (mit Zielen ab S. 60) | ||
| + | * Process Management | ||
| + | * Project Management | ||
| + | * Engineering | ||
| + | * Support | ||
| + | * Standard CMMI Appraisal Method for Process Improvement | ||
| + | * Software Process Improvement and Capability dEtermination | ||
| + | * internationaler Standard (ISO 15504) | ||
| + | * inhaltlich zu 90% mit CMMI deckungsgleich | ||
| + | * Bootstrap | ||
| + | * DIN EN ISO 9000 ff | ||
| + | * "Schreib immer auf, wie du etwas machst, und tu alles so, wie es aufgeschrieben ist." | ||
| + | * Six Sigma | ||
| + | ===== Qualitätssicherung ===== | ||
| + | * Review | ||
| + | * Schreibtischtest | ||
| + | * Vier-Augen-Test | ||
| + | * Structured Walkthrough (Yourdon) | ||
| + | * Inspection (IBM) | ||
| + | * Fagan-Inspection (IBM) | ||
| + | * Vorgegeben Vorgehensmuster für verschiedene Dokumentklassen | ||
| + | * Autor nicht (!) Vorleser des Dokuments | ||
| + | * Statische Analyse | ||
| + | * Konstruktive Maßnahmen | ||
| + | * z.B. CodingStandards, CodingConventions, "sichere" Programmiersprachen | ||
| + | |||
| + | > Total Quality Management (TQM) bezeichnet die durchgängige, fortwährende und alle Bereiche einer Organisation (Unternehmen, Institution, etc.) erfassende aufzeichnende, sichtende, organisierende und kontrollierende Tätigkeit, die dazu dient, Qualität als Systemziel einzuführen und dauerhaft zu garantieren. (S. 68) | ||
| ===== Links ===== | ===== Links ===== | ||
| Zeile 444: | Zeile 500: | ||
| * Aufwandsschätzung | * Aufwandsschätzung | ||
| * http://de.wikipedia.org/wiki/Cocomo | * http://de.wikipedia.org/wiki/Cocomo | ||
| + | |||
| ===== ToDo ===== | ===== ToDo ===== | ||
| + | * Eigene Aufzeichnungen zur Vorlesung durchgehen | ||
| * Lernziele des Skripts anschauen | * Lernziele des Skripts anschauen | ||
| * Praktikumsunterlagen anschauen | * Praktikumsunterlagen anschauen | ||
| - | * Infos zu Extreme Programming | + | * Aufgaben zum Übungsprojekt Handhabungsautomat lösen |
| - | * Infos zu Zustandsautomaten | + | |
| * UML-Diagrammtypen detaillierter anschauen | * UML-Diagrammtypen detaillierter anschauen | ||
| * Use-Case-Diagramm | * Use-Case-Diagramm | ||
| Zeile 469: | Zeile 527: | ||
| * Kompaktdarstellung ("Bonbon") | * Kompaktdarstellung ("Bonbon") | ||
| * Zustandsautomaten | * Zustandsautomaten | ||
| - | * Eigene Aufzeichnungen zur Vorlesung durchgehen | + | |
| - | * Infos zu COCOMO II | + | * Nähere Informationen einholen |
| - | * http://www-ivs.cs.uni-magdeburg.de/~dumke/ST2/ST2Prozess.html | + | * Extreme Programming |
| - | * Script farbig ausdrucken | + | * Zustandsautomaten |
| - | * Informationen zu MVC. Welche Aufgabe hat der Controller? | + | * MVC. Welche Aufgabe hat der Controller? |
| - | * Informationen zu SDL | + | * SDL |
| - | * Informationen zu OCL | + | * OCL |
| - | * Aufgaben zum Übungsprojekt Handhabungsautomat lösen | + | * Petri-Netze (?) |
| + | * CORBA, CCM, COM, EJB, CAN(open) (?) | ||
| + | * MDA | ||
| + | * Was ist ein "aktives Objekt" genau? | ||
| + | |||
| + | ==== Erledigt ==== | ||
| * Entwurfsmuster genauer anschauen | * Entwurfsmuster genauer anschauen | ||
| * Übersichtsblatt mit Klassendiagrammen aller Pattern erstellen | * Übersichtsblatt mit Klassendiagrammen aller Pattern erstellen | ||
| Zeile 505: | Zeile 568: | ||
| * http://www.se.uni-hannover.de/documents/kurz-und-gut/ws2004-seminar-entwurf/software-metriken_mthomas.pdf | * http://www.se.uni-hannover.de/documents/kurz-und-gut/ws2004-seminar-entwurf/software-metriken_mthomas.pdf | ||
| * http://informatik.unibas.ch/lehre/ws05/cs203/softeng13.pdf | * http://informatik.unibas.ch/lehre/ws05/cs203/softeng13.pdf | ||
| - | * Petri-Netze (?) | + | * Infos zu COCOMO II |
| - | * CORBA, CCM, COM, EJB, CAN(open) (?) | + | * http://www-ivs.cs.uni-magdeburg.de/~dumke/ST2/ST2Prozess.html |
| - | * MDA | + | |
| - | * Was ist ein "aktives Objekt" genau? | + | |
| ===== Übungen ===== | ===== Übungen ===== | ||
| Zeile 562: | Zeile 623: | ||
| ==== Seite 63 ==== | ==== Seite 63 ==== | ||
| + | * Ein Bekannter erzählt Ihnen, seine Firma sei soeben nach CMM Level 1 zertifiziert worden. Was meinen Sie dazu? | ||
| + | * CMM Level 1 bedeutet keinerlei Struktur im Entwicklungsprozess. | ||
| + | * Ihre Firma beginnt plötzlich, Trainingsprogramme für ihre Mitarbeiter einzurichten. Was könnte der Grund sein? | ||
| + | * Erreichen eines höheren CMM-/CMMI-Levels. Die Weiter- bzw. Ausbildung von Mitarbeitern zählt zu den zu erledigenden Auflagen z.B. bei CMMI Level 2. | ||
| + | * Wieso ist CMMI für eine kontinuierliche Prozessverbesserung besser geeignet als CMM? | ||
| + | * CMM bewertet lediglich die Gesamtperformance des Unternehmens, während CMMI auch Teilbereiche berücksichtigt. Dadurch sind Verbesserungen besser nachvollziehbar und Schwachstellen eindeutig identifizierbar. | ||
| + | * Warum wurde Bootstrap entwickelt, und warum wurde die Entwicklung eingestellt? | ||
| + | Bootstrap wurde für eruropäische Firmen quasi als Konkurrenzprodukt zu CMM entwickelt, ist aber inzwischen von SPICE abgelöst. | ||
| + | * Worin besteht die Verwandtschaft zwischen CMMI, SPICE und Bootstrap und der Unterschied zu CMM? | ||
| + | * Die drei genannten Verfahren beinhalten auch die kontinuierliche Bewertung von Teilbereichen des Unternehmens, während CMM nur 5 allgemeine Stufen das Gesamtunternehmen betreffend anbietet. | ||
| + | * Die Kosten eines Projekts wurden auf 5 Mio. € geschätzt; im Angebot stehen aber 6,2 Mio. €. Welche Berechnung könnte dahinter stehen? | ||
| + | * Ein Softwarehaus, das auch Unteraufträge vergibt, möchte sich nach CMM zertifizieren lassen. Worauf muss es besonders achten? | ||
| + | * Auf die Zertifizierung seiner Unterauftragnehmer. | ||
| + | * Welche Reifegrade kennt ISO 9003? | ||
| + | * Keine. Lediglich "bestanden" oder "nicht bestanden". | ||
| + | * Woran denken Sie, wenn Sie SCAMPI hören? | ||
| + | * An ein Bewertungsverfahren zu CMMI. | ||
| + | * Wo ist von Stakeholdern die Rede? | ||
| + | * Bei CMMI Level 2. | ||
| + | |||
| ==== Seite 68 ==== | ==== Seite 68 ==== | ||
| + | * Hat es einen Sinn, auch für nicht-objektorientierte Programmierung C++ anstatt C einzusetzen? | ||
| + | * Ja, denn C++ ist "sicherer" als C und trägt damit zur konstruktiven Qualitätssicherung bei. | ||
| + | * Kann man ein Peer Review auch als konstruktive Maßnahme bezeichnen, und warum (nicht)? | ||
| + | * Nein, da Reviews im Nachhinein Fehler finden sollen und diese nicht vorab verhindern. | ||
| + | * Wie viele Teilnehmer erfordert ein Structured Walkthrough mindestens? | ||
| + | * 6: Autor, Moderator, Schriftführer, 3 Reviewer (Wartungsprophet, Normenreiter, Benutzervertreter) | ||
| + | * Ihr Abteilungsleiter will an Reviewsitzungen teilnehmen. Darf er das? | ||
| + | * Nein, denn ein Review soll ungezwungen ablaufen und die (negativen) Ergebnisse dürfen nicht zur Bewertung von Mitarbeitern herangezogen werden. | ||
| + | |||
| ==== Seite 86 ==== | ==== Seite 86 ==== | ||
| * Welche Techniken zur Spezifikation von Use Cases kennen Sie? | * Welche Techniken zur Spezifikation von Use Cases kennen Sie? | ||
se/softwaretechnologie.txt · Zuletzt geändert: 2014-04-05 11:42 (Externe Bearbeitung)
Seiten-Werkzeuge
Falls nicht anders bezeichnet, ist der Inhalt dieses Wikis unter der folgenden Lizenz veröffentlicht: CC Attribution-Noncommercial-Share Alike 4.0 International
