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 | ||
|
se:softwaretechnologie [2008-02-18 10:52] stefan |
se:softwaretechnologie [2014-04-05 11:42] (aktuell) |
||
|---|---|---|---|
| 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 329: | Zeile 348: | ||
| * Fehlerbeseitigung | * Fehlerbeseitigung | ||
| - | ===== Prozessmodelle ===== | + | ===== Entwicklungsprozess ===== |
| + | Ein Prozess(modell) besteht aus | ||
| + | * Vorgehensmodell | ||
| + | * wann und unter | ||
| + | * welchen Voraussetzungen | ||
| + | * welches Produkt durch | ||
| + | * welche Aktivität mit | ||
| + | * Methodenzuordnung | ||
| + | * welcher Methode unter Verwendung von | ||
| + | * welchem Werkzeug entsteht, und | ||
| + | * Rollenzuordnung | ||
| + | * wer wie daran beteiligt ist. | ||
| + | |||
| + | ==== Wasserfallmodelle ==== | ||
| + | * Klassisch | ||
| + | * Analyse | ||
| + | * Definition | ||
| + | * Entwurf | ||
| + | * Implementierung | ||
| + | * Wartung | ||
| + | * 60 - 80% aller Fehler entstehen in der Analysephase! Analysefehler erzeugen 60 - 70 % der Gesamtkosten! | ||
| + | * erweitert: mit Validierungsphasen | ||
| + | * V-Modell von Boehm | ||
| + | |||
| + | ==== Prototyping und iterative Modelle ==== | ||
| + | * Evolutionäres Prototyping | ||
| + | * Spiralmodell | ||
| + | * Rapid Prototyping | ||
| + | * Exploratives Prototyping | ||
| + | * Baseballmodell | ||
| + | * Vorteile | ||
| + | * Risiken werden früh erkannt | ||
| + | * dem Kunden kann etwas vorgefüht werden | ||
| + | * offene Fragen können am Beispiel ausprobiert/geklärt werden | ||
| + | |||
| + | ==== Inkrementelle Entwicklung ==== | ||
| + | * Erstellen (und Ausliefern) des Produktes in mehreren zunehmend vollständigen Versionen | ||
| + | |||
| + | ==== V-Modell 97 ==== | ||
| + | * Internationaler Standard des Bundesinnenministeriums | ||
| + | * Stellt die **Anforderungen an das System** (Hard- und Software) in den Vordergrund | ||
| + | * Submodelle | ||
| + | * Systemerstellung | ||
| + | * Qualitätssicherung | ||
| + | * Konfigurationsmanagement | ||
| + | * (technisches) Projektmanagement | ||
| + | * **Dokumente** werden von **Aktivitäten** erzeugt | ||
| + | * Rollen und Rollenzuordnung (S. 21) | ||
| + | * Jeder Aktivität werden Methoden (Elementarmethoden S. 24) und Werkzeuge zugeordnet | ||
| + | * Szenarien | ||
| + | * Inkrementelle Entwicklung (Regelfall) | ||
| + | * Grand Design (Traditionelles Vorgehen) | ||
| + | * Einsatz von Fertigprodukten | ||
| + | * Objektorientierte Entwicklung | ||
| + | * Entwicklung wissensbasierter Systeme | ||
| + | * Software-Pflege und -Änderung | ||
| + | * Durch Tailoring wird aus dem V-Modell das Projekthandbuch erstellt (S. 30) | ||
| + | * Nachteile: schwerfällig, ausufernde Dokumentation, Tailoring/Erstellen des Projekthandbuchs ist Handarbeit (Fehlerquelle) | ||
| + | |||
| + | ==== V-Modell XT ==== | ||
| + | * Seit 2004 verbindlich für Aufträge des Bundes | ||
| + | * **Vorgehensbausteine** kapseln Rollen, Produkte und Aktivitäten (entsprechen etwa den Submodellen des V-Modells 97) -> Weltkarte (S. 34) | ||
| + | * Durchführungsstrategien (entsprechen Szenarien des V-Modells 97) (ggf. getrennte Strategien für AG und AN) | ||
| + | * Agile Entwicklung | ||
| + | * Komponentenbasierte Entwicklung | ||
| + | * Auftraggeberprojekte | ||
| + | * <del>Grand Design</del> | ||
| + | * <del>Objektorientierte Entwicklung</del> | ||
| + | * <del>Entwicklung wissensbasierter Systeme</del> | ||
| + | * Entscheidungspunkte | ||
| + | * Methoden und Werkzeuge | ||
| + | * Rollen | ||
| + | * Nachteile | ||
| + | * Wust von unstrukturierten Texten | ||
| + | * Wichtige Workflows/Rollen fehlen oder sind schwer auffindbar | ||
| + | * Anforderungen werden als gegeben vorausgesetzt | ||
| + | |||
| + | ==== Rational Unified Process ==== | ||
| + | * Ausschließlich für objektorientierte Softwareentwicklung mit der UML geeignet | ||
| + | * iterativ (alle Aktivitäten werden mehrfach durchlaufen) **und** inkrementell (jede Iteration bring einen Mehrwert) | ||
| + | * Use-Case-getrieben | ||
| + | * Architekturzentriert | ||
| + | * Phasen | ||
| + | * Inception | ||
| + | * Elaboration | ||
| + | * Construction | ||
| + | * Transition | ||
| + | * Workflows (entsprechen insgesamt dem Submodell SE des V-Modells 97) | ||
| + | * Business Modeling | ||
| + | * Requirements | ||
| + | * Analysis and Design | ||
| + | * Implementation | ||
| + | * Test | ||
| + | * Deployment | ||
| + | * 80% rule | ||
| + | * Timeboxing | ||
| + | * Nachteile | ||
| + | * Kommerzielles Produkt mit Verweisen auf kommerzielle Tools von Rational | ||
| + | * Spezialisierung des RUP für kommerzielle Client-/Server-Anwendungen: Object Engineering Process von Bernd Oesterreich | ||
| + | * Timepacing | ||
| + | |||
| + | ==== Agile Prozesse ==== | ||
| + | * Agile Manifesto (S. 52) | ||
| + | * Extreme Programming | ||
| + | * Crystal Methodenfamilie | ||
| + | |||
| + | ===== 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 ===== | ===== 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 340: | Zeile 504: | ||
| * Aufwandsschätzung | * Aufwandsschätzung | ||
| * http://de.wikipedia.org/wiki/Cocomo | * http://de.wikipedia.org/wiki/Cocomo | ||
| + | |||
| ===== ToDo ===== | ===== ToDo ===== | ||
| - | * Praktikumsunterlagen anschauen | ||
| - | * Infos zu Extreme Programming | ||
| - | * Infos zu Zustandsautomaten | ||
| - | * UML-Diagrammtypen detaillierter anschauen | ||
| - | * Use-Case-Diagramm | ||
| - | * Aktivitätsdiagramm | ||
| - | * Pins | ||
| - | * Control / Object Flow | ||
| - | * Beispiel von Robra (implizites Join oder so) | ||
| - | * Komponentendiagramm | ||
| - | * Ports (behavior port) | ||
| - | * subsystem | ||
| - | * Kompositions-Strukturdiagramm | ||
| - | * Verteilungsdiagramm | ||
| - | * Artefakte | ||
| - | * Kommunikationsdiagramm | ||
| - | * Sequenzdiagramm | ||
| - | * Combined Fragments | ||
| - | * Interaktions-Übersichtsdiagramm | ||
| - | * Timing-Diagramm | ||
| - | * Kompaktdarstellung ("Bonbon") | ||
| - | * Zustandsautomaten | ||
| * Eigene Aufzeichnungen zur Vorlesung durchgehen | * Eigene Aufzeichnungen zur Vorlesung durchgehen | ||
| - | * Infos zu COCOMO II | + | * Lernziele des Skripts anschauen |
| - | * http://www-ivs.cs.uni-magdeburg.de/~dumke/ST2/ST2Prozess.html | + | * Praktikumsunterlagen anschauen |
| - | * Script farbig ausdrucken | + | |
| - | * Informationen zu MVC. Welche Aufgabe hat der Controller? | + | |
| - | * Informationen zu SDL | + | |
| - | * Informationen zu OCL | + | |
| * Aufgaben zum Übungsprojekt Handhabungsautomat lösen | * Aufgaben zum Übungsprojekt Handhabungsautomat lösen | ||
| + | * Wiki-Eintrag drucken/speichern | ||
| + | |||
| + | * Nähere Informationen einholen | ||
| + | * Extreme Programming | ||
| + | * MVC. Welche Aufgabe hat der Controller? | ||
| + | * SDL | ||
| + | * OCL | ||
| + | * 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 400: | Zeile 552: | ||
| * 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 | + | * UML-Diagrammtypen detaillierter anschauen |
| - | * Was ist ein "aktives Objekt" genau? | + | * Use-Case-Diagramm |
| + | * Aktivitätsdiagramm | ||
| + | * Pins | ||
| + | * Control / Object Flow | ||
| + | * Beispiel von Robra (implizites Join oder so) | ||
| + | * Komponentendiagramm | ||
| + | * Ports (behavior port) | ||
| + | * subsystem | ||
| + | * Kompositions-Strukturdiagramm | ||
| + | * Verteilungsdiagramm | ||
| + | * Artefakte | ||
| + | * Kommunikationsdiagramm | ||
| + | * Sequenzdiagramm | ||
| + | * Combined Fragments | ||
| + | * Interaktions-Übersichtsdiagramm | ||
| + | * Timing-Diagramm | ||
| + | * Kompaktdarstellung ("Bonbon") | ||
| + | * Zustandsautomaten | ||
| + | * Wie wird ein "defer" dargestellt | ||
| ===== Übungen ===== | ===== Übungen ===== | ||
| Zeile 421: | Zeile 591: | ||
| ==== Seite 55 ==== | ==== Seite 55 ==== | ||
| + | * Was regelt ein Prozess? | ||
| + | * Ein Prozess regelt die Rahmenbedingungen, unter denen eine Software entwickelt wird (z.B. die Teilnehmer, die Entwicklungsmethoden und die verwendeten Werkzeuge). | ||
| + | * Was ist eine Rolle? | ||
| + | * Eine Rolle fasst Aufgaben zusammen, die von Mitarbeitern in einem Prozess wahrgenommen werden müssen (z.B. System Engineer). Eine Rolle kann von mehreren Mitarbeitern wahrgenommen werden und ebenso kann ein Mitarbeiter mehrere Rollen innehaben. | ||
| + | * Was macht ein Vorgehen nach dem Wasserfallmodell riskant und teuer? | ||
| + | * Fehler werden spät entdeckt und ihre Behebung kostet dann entsprechend mehr. | ||
| + | * Wodurch unterscheidet sich das ursprüngliche V-Modell nach Boehm von einem Wasserfallmodell? | ||
| + | * Das V-Modell sieht für jede Phase des ursprünglichen Wasserfallmodells eine entsprechende Testphase vor und erlaubt ausdrücklich Sprünge in frühere Phasen, wenn Fehler auftreten. | ||
| + | * Was bedeutet das "V" im V-Modell 97? | ||
| + | * **Vorgehens**modell | ||
| + | * Versuchen Sie, in den V-Modellen 97 und XT etwas zu finden, was dem Requirements Workflow des RUP entspricht. | ||
| + | * V-Modell 97: Unterpunkte von SE 1: z.B. Anforderungen an die Qualität definieren, Randbedingungen definieren etc. Das Ergebnis von SE 1 sind die Anwenderanforderungen. | ||
| + | * V-Modell XT: Die Anforderungen müssen komplett vom AG geliefert werden. | ||
| + | * Ist es nach der aktuellen Weltkarte der Vorgehensbausteine des V-Modell XT möglich, einen Prozess für ein sicherheitsrelevantes System zu definieren, das weder | ||
| + | HW noch SW enthält und keine Anforderungsfestlegung benötigt? | ||
| + | * Nein. Systemsicherheit erfordert alle drei genannten Komponenten. | ||
| + | * Wann soll im RUP die erste Version der Architektur vorliegen? | ||
| + | * Am Ende der Elaboration-Phase. | ||
| + | * Was unterscheidet den OEP vom RUP? | ||
| + | * Ausrichtung auf kommerzielle Systeme | ||
| + | * Timeboxing wird durch Timepacing (feste Abfolge von Terminen innerhalb einer Iteration) ersetzt | ||
| + | * Wo findet sich das Deployment Diagram der UML in den V-Modellen 97 und XT wieder? | ||
| + | * Führen Sie für Ihre Projektarbeit des Studiengangs ein "Standardisiertes Vortailoring" des V-Modells 97 durch. | ||
| + | * Was ist ein "System Metaphor", zu welchem Vorgehensmodell gehört es, und zu welchem Ziel soll es beitragen? | ||
| + | * Ein grober Überblick über das zu erstellende Gesamtsystem, das zu einem einheitlichen Verständnis bei den Beteiligten führen soll (Extreme Programming). | ||
| + | * Um den Termin halten zu können, verordnet der Projektleiter seinen Programmierern für die nächsten vier Wochen 20% Überstunden. Welchen Erfolg kann er erwarten? | ||
| + | * Überstunden wirken sich allerhöchstens kurzfristig aus. Auf längere Sicht führt die Mehrarbeit zu nachlassender Leistung bei den Mitarbeitern. | ||
| + | * Sie erhalten als Auftragnehmer vom Auftraggeber eine vollständige Anforderungsspezifikation. Womit müssen Sie nach zwei Jahren Entwicklungsdauer rechnen? | ||
| + | * Ca. 2% der Die Anforderungen ändern sich pro Monat, d.h. nach 2 Jahren sind nur noch knapp die Hälfte der Anforderungen gültig. | ||
| + | * Was hat TestDrivenDevelopment mit Wiederverwendung zu tun? | ||
| + | * Da die Testumgebung einen zusätzlichen Klienten für die zu testenden Komponenten darstellen, wird gleich sichergestellt, dass die Komponente mit mehreren (unterschiedlichen) Klienten kooperieren kann, was ein Nachweis für die Wiederverwendbarkeit ist. | ||
| + | * Was ist erforderlich, damit wiederverwendbare Komponenten auch wiederverwendet werden? | ||
| + | * Wiederverwendung muss durch einen Software-Reuse-Prozess unterstützt werden. | ||
| + | * Arbeiten Sie sich anhand der gegebenen Links in Scrum ein und definieren Sie eine Variante, die zu den besonderen Randbedingungen Ihrer Projektarbeit passt. | ||
| + | |||
| ==== 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.1203328370.txt.gz · 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
