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-25 11:12] stefan |
||
|---|---|---|---|
| Zeile 13: | Zeile 13: | ||
| * 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 | ||
| + | |||
| + | ==== Tipps ==== | ||
| + | * Jedes Wort im Text genau auf Auswirkungen auf Methoden/Attribute prüfen. Beispiel "Taste.LeuchteAn()". | ||
| + | * Jedes Element muss seinen Auftraggeber über eine "fertig"-Meldung benachrichtigen (wichtig für Sequenzdiagramme und Zustandsdiagramme) | ||
| + | * Benutzerinteraktionen werden ins Sequenzdiagramm aufgenommen. Beispiel: Benutzer drückt Taste. | ||
| ===== Einführung ===== | ===== Einführung ===== | ||
| Zeile 32: | Zeile 42: | ||
| ===== Objektorientierte Systementwicklung ===== | ===== Objektorientierte Systementwicklung ===== | ||
| + | |||
| ==== Anforderungen / Aufwandsermittlung ==== | ==== Anforderungen / Aufwandsermittlung ==== | ||
| Zeile 69: | Zeile 80: | ||
| * 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 363: | ||
| ==== 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 455: | ||
| ===== 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 504: | ||
| * 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 | + | * Wiki-Eintrag drucken/speichern |
| * UML-Diagrammtypen detaillierter anschauen | * UML-Diagrammtypen detaillierter anschauen | ||
| * Use-Case-Diagramm | * Use-Case-Diagramm | ||
| Zeile 469: | Zeile 532: | ||
| * Kompaktdarstellung ("Bonbon") | * Kompaktdarstellung ("Bonbon") | ||
| * Zustandsautomaten | * Zustandsautomaten | ||
| - | * Eigene Aufzeichnungen zur Vorlesung durchgehen | + | * Wie wird ein "defer" dargestellt |
| - | * Infos zu COCOMO II | + | |
| - | * http://www-ivs.cs.uni-magdeburg.de/~dumke/ST2/ST2Prozess.html | + | * Nähere Informationen einholen |
| - | * Script farbig ausdrucken | + | * Extreme Programming |
| - | * 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 573: | ||
| * 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 628: | ||
| ==== 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
