Beschreibung
Softwaretechnik (oder englisch Software Engineering) ist die Lehre von
der Softwarekonstruktion im Großen, also das Grundlagenfach zur Methodik.
Die Softwaretechnik ist bemüht, Antworten auf die folgenden Fragen zu geben:
- Wie findet man heraus, was eine Software für Eigenschaften haben soll (Anforderungsermittlung)?
- Wie beschreibt man dann diese Eigenschaften (Spezifikation)?
- Wie strukturiert man die Software so, dass sie sich leicht bauen und flexibel verändern lässt (Entwurf)?
- Wie verändert man Software, die keine solche Struktur hat oder deren Struktur man nicht (mehr) versteht (Wartung, Reengineering)?
- Wie deckt man Mängel in Software auf (analytische Qualitätssicherung, Test)?
- Wie organisiert man die Arbeit einer Softwarefirma oder -abteilung, um regelmäßig kostengünstige und hochwertige Resultate zu erzielen (konstruktive Qualitätssicherung, Prozessmanagement, Projektmanagement)?
- Welche (großenteils gemeinsamen) Probleme liegen allen diesen Fragestellungen zu Grunde und welche (großenteils gemeinsamen) allgemeinen Lösungsansätze liegen den verwendeten Methoden und Techniken zu Grunde?
- …und viele ähnliche mehr.
Diese Vorlesung gibt einen Überblick über die Probleme und Lösungsansätze
(Methodenlehre) und stellt
essentielles Grundwissen für jede/n ingenieurmäßig arbeitende/n
Informatiker/in dar.
Organisatorisches
Veranstalter
Voraussetzungen/Zielgruppe, Einordnung, Leistungpunkte etc.
Siehe den
Eintrag im KVV.
Die Veranstaltung ist eine Pflichtveranstaltung für die Studiengänge
Informatik Diplom und Informatik Bachelor.
Termine und Nachrichten
- Die Einteilung zu den Übungsgruppen erfolgt ausschließlich über das Blackboard System der Freien Universität Berlin, NICHT über das KVV.
- Melden Sie sich zu der Veranstaltung »Übung zu Softwaretechnik« (MATHINF_Ue_19516a_11S Übung zu Softwaretechnik) an.
- Melden sie sich innerhalb der Veranstaltung »Übung zu Softwaretechnik« zu der Ihrem Tutorium entsprechenden Gruppe an
- Vorlesung:
- Mo, 12-14 Uhr, Großer Hörsaal der Informatik, Takustr. 9
- Do, 12-14 Uhr, Großer Hörsaal der Informatik, Takustr. 9
- Übungen:
- Mo 14-16 Uhr, T9/049, Ute Neise
- Mo 14-16 Uhr, T9/055, Dominik Weidemann
- Mo 16-18 Uhr, T9/055, Julia Schenk
- Do 10-12 Uhr, T9/055, Dominik Weidemann
- Do 10-12 Uhr, T9/051, Rico Jonschkowski
- Do 14-16 Uhr, T9/046, Rico Jonschkowski
- Fr 12-14 Uhr, T9/049, Ute Neise
- Klausuren: siehe nachfolgenden Abschnitt
Prüfungsmodalitäten
Kriterien für den Erwerb des Übungsscheins (Diplom) bzw. der Leistungspunkte
(Bachelor) sind
- Aktive Mitarbeit in den Übungen
- Details zum Kriterium der aktiven Mitarbeit finden Sie hier.
- Bestehen der Klausur
- Die Klausur dauert 90 Minuten und es gibt 90 Punkte.
- Zum Bestehen wird eine Punktzahl ausreichen, die voraussichtlich im Bereich zwischen 28 und 38 liegen wird (ohne Gewähr). Die genaue Schwelle wird erst bei der Korrektur festgelegt.
- Bei der Klausur dürfen folgende Hilfsmittel verwendet werden:
- Ein selbst angefertigter Spickzettel mit maximaler Größe DIN A3. Alternativ: Zwei fest verbundene DIN A4 Zettel (tackern oder kleben). Es gibt keine Einschränkungen zu Schriftgröße und Inhalt. Der Zettel darf beidseitig beschrieben/bedruckt werden. Jede/r darf nur ihre/seine eigene mitgebrachte Unterlage benutzen.
- Studierende deren Muttersprache nicht Deutsch ist, dürfen selbstverständlich ein Wörterbuch in die Klausur mitbringen.
- 1. Klausur: Do 21.07.2011, 11:59-14 Uhr, Hörsaal 1a und 1b, Habelschwerdter Allee 45
- Aufteilung auf die Räume nach Nachname:
- A* - K*: Hörsaal 1a
- L* - Z*: Hörsaal 1b
- Klausureinsicht: Di 04.10.2011, 09:59 Uhr bis mindestens 10:30, SR 051, Takustr. 9
- 2. Klausur: Do 06.10.2011, 11:59-14 Uhr, Hörsaal 2, Silberlaube, Habelschwerdter Allee 45.
- Klausureinsicht: Mi 19.10.2011, 15:59 Uhr bis mindestens 16:30, SR 051, Takustr. 9
Inhalt
Literatur
Stoffplan
- (11.4.2011) Einführung:
Einführung
- Software; Softwaretechnik (SWT); Aufgaben der SWT; Persönlicher Bezug; Beteiligte; Gütemaßstab: Kosten/Nutzen; Qualität; Produkt und Prozess; Prinzip, Methode, Verfahren, Werkzeug; technische vs. menschliche Aspekte; Arten von SWT-Situationen; Lernziele; Lernstil
- (14.4.2011) Fallbeispiel:
Elektronische Gesundheitskarte
- Einordnung, Anforderungen 'eRezept' (funktionale, Leistungs-, Verfügbarkeits-, Sicherheits-), techn. Ablauf, einige Details, Dokumentenlandkarte, Beteiligte, Nutznießer und Konfliktlinien, Zeitverlauf, Exkurs Digitale Signatur.
- "Merke"-Hinweise zu: Domänen, nichtfunktionalen Anforderungen, Kooperationsbedarf, Projektrisiko.
- (18.4.2011) Einführung:
Die Welt der Softwaretechnik
- Routine und Innovation: Normales und radikales Vorgehen; Taxonomie: Probleme und Lösungen
- (21.4.2011) Modellierung:
Modellierung und UML
- Modelle und Modellierung (Realität vs. Modell; Phänomene vs. Konzepte); UML; Klassendiagramme; Sequenzdiagramme; Zustandsdiagramme (statechart); Aktivitätsdiagramme; sonstige Diagrammarten (Komponentendiagramme, Kollaborationsdiagramme, Inbetriebnahmediagramme, Kommunikationsdiagramme, Interaktions-Übersichts-Diagramme); UML Metamodell; Profile; einige Notationsdetails (Klassen, Assoziationen, Schnittstellen, Zustände)
- (28.4.2011) Ermitteln WAS:
Anforderungsbestimmung
- Erhebung (Requirements Elicitation): Anforderungen und Anforderungsbestimmung (Requirements Engineering); Arten von Anforderungen; Anforderungen und Modellierung; Harte und weiche Systeme; Probleme und Chancen erkennen; Erhebungstechniken (herkömmliche, darstellungs-basierte, soziale, wissenserhebende)
- (2.5.2011) Ermitteln WAS:
Anwendungsfälle (Use Cases)
- Was ist ein Use Case?; Wichtige Parameter (Bereich, Detailgrad/Zielniveau); schrittweise Präzisierung; Use-Case-Hierarchien (Überblick, Benutzerziele, Details); Checkliste für Use Cases
- (5.5.2011) Verstehen WAS:
Analyse (statisches Objektmodell)
- Von Use-Cases zu Klassen, Abbott's Methode (Substantive sind Kandidaten für Klassen, Verben für Operationen, Adjektive für Attribute, Eigennamen für Objekte, "ist ein" für Vererbung etc.); Checklisten zur Identifikation von Klassen, Assoziationen, Attributen, Operationen, Vererbung; Entwicklerrollen und Modellarten (Analysemodell vs. Entwurfsmodell)
- (9.5.2011) Verstehen WAS:
Analyse (dynamisches Objektmodell)
- Klassen finden mit dynamischer Modellierung; Zustandsdiagramme (statechart diagrams); Sequenzdiagramme; Aufbau eines Anforderungsanalyse-Dokuments; Validierung (und Gegensatz zu Verifikation)
- (12.5.2011) Entscheiden WIE:
Software-Architektur
- Architektur=Gesamtstruktur; Erfüllen nichtfunktionaler und funktionaler Anforderungen; globale Eigenschaften; wiederverwendbare Architekturen (Standard-Architekturen); Architekturstile (zum Selbstentwickeln von Architekturen); Modularisierung (Modulbegriff, Aufteilungskriterien)
- (16.5.2011) Entscheiden WIE:
Modularisierung
- Modulbegriff; Kriterien für Aufteilung; Fallstudie: KWIC; KWIC 1: Datenflusskette; Einschätzen der Entwurfsqualität; KWIC 2: Zentrale Steuerung; KWIC 3: Datenabstraktion; Verhalten bei Änderungen; Verwandtschaft mit Architekturstilen
- (19.5.2011) Wiederverwenden WIE:
Entwurfsmuster, Teil 1
- Was macht ein Problem schwierig?; Einfachheit durch Wiedererkennen von Mustern; Idee von Entwurfsmustern; Kompositum-Muster (composite pattern); Adapter-Muster (adapter pattern); Brücken-Muster (bridge pattern); Fassaden-Muster (facade pattern)
- (23.5.2011) Wiederverwenden WIE:
Entwurfsmuster, Teil 2
- Arten von Entwurfsmustern; Stellvertreter-Muster (proxy pattern); Kommando-Muster (command pattern); Beobachter-Muster (observer pattern); Strategie-Muster (strategy pattern); Abstrakte-Fabrik-Muster (abstract factory pattern); Erbauer-Muster (builder pattern)
- (26.5.2011) Spezifizieren WIE:
Schnittstellenspezifikation
- Sichtbarkeiten (public, protected, private, package), Spezifikation von Voraussetzungen (preconditions) und Wirkungen (postconditions) mit OCL (context, pre, post, inv); Abbildung von Assoziationen in Code
- (30.5.2011) Prüfen OB:
Analytische Qualitätssicherung, Teil 1
- Defekttest; Auswahl der Eingaben (Funktionstest, Strukturtest); Auswahl der Testgegenstände (bottom-up, top-down, opportunistisch); Ermittlung des erwarteten Verhaltens (Referenzsystem, (Teil)Orakel); Wiederholung von Tests (Rückfalltesten, Testautomatisierung)
- (6.6.2011) Prüfen OB:
Analytische Qualitätssicherung, Teil 2
- Testautomatisierung (Werkzeuge, Strukturierung, JUnit); Stoppkriterien für das Testen; Defektortung; Benutzbarkeitstest; Lasttest; Akzeptanztest; manuelle statische Prüfung (Durchsicht; Inspektion; Perspektiven-basiertes Lesen); automatische statische Prüfung (Modellprüfung; Quelltextanalyse)
- (9.6.2011) Vorbeugen DAMIT:
Konstruktive Qualitätssicherung (Qualitätsmgmt., Prozessmgmt.)
- Projekt- vs. Prozessmgmt.; Arten von Prozessmgmt.-Leitlinien; CMM-SW/CMMI (5 Prozessreifestufen); TQM (Prinzip: Kundenzufriedenheit); ISO 9000
- (16.6.2011) Entscheiden WIE (Prozess):
Prozessmodelle
- Rollen, Artefakte, Aktivitäten; Wasserfallmodell; Reparatur 1: Iteration (Prototypmodell, Evolutionäre Modelle, Spiralmodell); Reparatur 2: Flexiblere Planung (Agile Methoden); Prozessmodell-Auswahlkriterien; Anpassbare Prozessmodelle: RUP, V-Modell XT; Erklärung "Agile Methode" (XP)
- (20.6.2011) Randbedingungen:
Persönlichkeitstyp
- Was und warum; Die MBTI-Dimensionen (E/I, S/N, T/F, J/P); Warnungen und Hinweise; Die Keirsey-Temperamente (SJ, SP, NT, NF); Andere Typsysteme; Typen und SW-Engineering; Stärken und Gefahren; Typische Tendenzen; Eigenen Typ herausfinden
- (23.6.2011) Umsetzen (Prozess):
Projektmanagement, Teil 1
- Was und wofür?; Aufgabenfelder; Schätzen (Schätzverfahren; Funktionspunktschätzung); Todesmarschprojekte
- (27.6.2011) Umsetzen (Prozess):
Projektmanagement, Teil 2
- Zeit- und Ressourcenplanung; Microsoft Project; Critical Path Method (CPM); Finden von Aufgabenzerlegungen; Risikomanagement; Risikolisten; DOs and DON'Ts
- (30.6.2011) Umsetzen (Prozess):
Projektmanagement, Teil 3
- Teams; Sportteam oder Chor?; Organisationsstrukturen; Rollen; Kommunikationsstrukturen; psychologische Faktoren; Schätzen von Wahrscheinlichkeiten; Motivation; Attribution; Haltungen; soziale Einflüsse
- (4.7.2011) Umsetzen (Prozess):
Projektmanagement, Teil 4
- Projektplan; Projektleitung; nichtlineare Dynamik (Brook's Gesetz; Selbstverstärkung von Qualitätsmängeln; Teufelskreis von Qualität und Zeitdruck); Kommunikation (geplant/ungeplant, synchron/asynchron); Medien; Besprechungen
- (7.7.2011) Normales Vorgehen maximieren:
Wiederverwendung, Teil 1
- Arten der WV (Produkt/Prozess; Gegenstand; Ziel); Risiken und Abwägung; Hindernisse; Produktivität; WV für normales Vorgehen; Muster; Arten von Mustern; Prinzipien (Abstraktion, Strukturierung, Hierarchisierung, Modularisierung, Lokalität, Konsistenz, Angemessenheit, Wiederverwendung, Notationen); Analysemuster
- (11.7.2011) Normales Vorgehen maximieren:
Wiederverwendung, Teil 2
- Benutzbarkeitsmuster; Prozessmuster; Mustersprachen; Anti-Muster; Werkzeuge
- (14.7.2011) Wissen weitergeben:
Dokumentation
- Arten von Dokumentation; Qualitätseigenschaften (übersichtlich, präzise, korrekt, hilfreich); positive und negative Beispiele; Prinzipien (Selbstdokumentation, Minimaldokumentation); Begründungsmanagement (Fragen + Vorschläge + Kriterien + Argumente ergeben Entscheidungen)
- (??.7.2011) Berühmte letzte Worte:
Zusammenfassung
- Wiederholung aus 1. Vorlesung; Schnelldurchgang durch Stoffplan; wichtige nicht besprochene Themen; einige Empfehlungen
Übungen
- Die Anmeldung zu den Tutoriumsgruppem im Blackboard ist ab Montag den 11.04.2011 14 Uhr bis Samstag, den 30.04.2011 freigeschaltet.
- Die Tutorien beginnen in der 2. VL Woche (KW 16)
- Das 1. Übungsblatt gibt es in der 1. VL Woche (KW 15)
Wir freuen uns über Ihre Ideen und Ihre Kreativität zur Gestaltung der Tutorien. Sollten Sie mit Ihren Ideen unsicher sein oder Fragen haben, kommen Sie auf uns zu. Wir helfen gerne dabei, wenn es darum geht einen Vortrag, ein Quiz oder eine andere Idee zu realisieren.
Übungsblätter
Aktive Mitarbeit - Bonuspunktesystem
- Bearbeitung der Übungsblätter in Zweiergruppen
- keine Abgabe der Übungsblätter
Zur Besprechung der Übungsblätter werden in jedem Tutorium Teilnehmer zufällig aus dem "Lostopf" aller in der jeweiligen Blackboardgruppe angemeldeten Tutoriumsteilnehmer gezogen.
Notwendige Voraussetzungen zum Erreichen der aktiven Mitarbeit:
- Anmeldung in genau einem Tutorium über das Blackboard. Dort kann der aktuelle Stand des Bonuspunktekontos eingesehen werden.
- Zum Ende der Veranstaltung muss der Stand des Bonuspunktekontos >=0 Punkte sein.
Besprechung der Übungsblätter und Bonuspunkte-Verfahren:
- Jeder Teilnehmer startet mit einem ausgeglichenen Bonuspunktekonto (0 Punkte) und zwei Jokern.
- Ist ein gezogener Teilnehmer nicht anwesend oder nicht vorbereitet wird ein Punkt von seinem Bonuspunktekonto abgezogen
- Ein Joker muss vor dem Tutorium beim Tutor per Mail angesagt werden, damit wird der Teilnehmer für das Tutorium aus dem Lostopf heraus genommen.
- Durch ausarbeiten und halten eines Vortrages oder Quizzes werden dem Bonuspunktekonto 2 Punkte gutgeschrieben.
- Mit jedem negativen Punkt des Bonuspunktekontos verdoppelt sich die Anzahl der Lose für den Teilnehmer im Lostopf.
Man kann alternativ zum Übungsbetrieb auch ein selbstdefiniertes softwaretechnisches Projekt durchführen
und sich dann weitgehend aus dem restlichen Übungsbetrieb ausklinken.
Allerdings Vorsicht: Das nötige Üben für die Klausur liegt dadurch stärker in der eigenen Verantwortung! Details dazu
hier.
Beitragsarten
Für alle Beiträge gelten gewisse Ansprüche, damit diese als erfüllt gelten. Der Tutor bzw. die Tutorin werden beurteilen, ob diese Ansprüche erfüllt sind.
Die Themen für Präsentationen und Quizzes werden nicht vorgegeben, sondern es wird den Teilnehmern Freiraum bzgl. der Thematik als auch der Durchführungsgestaltung gelassen. Es ist jedoch aus organisationstechnischen Gründen eine terminliche und inhaltliche Abstimmung mit den Tutoren notwendig.
Vortrag
Vorträge müssen sich thematisch im Kontext der Softwaretechnik wiederfinden. Es können Themen der Vorlesung vertiefend betrachtet oder andere softwaretechnisch interessante Themen bearbeitet werden.
Es muss erkennbar sein, dass sich die Studierenden mit dem Thema weitergehend beschäftigt haben.
Folgende Aspekte gelten als Anhaltspunkte zu betrachtender Aspekte:
- Thema und dessen Kontext/Relevanz in der Softwaretechnik (wie/wo/wozu ist es relevant) → “ Where we are ”
- Thematik bzgl. bestimmter Aspekte tiefergehend betrachten / Querbezüge zu anderen Bereichen der Softwaretechnik
- Probleme / weitergehende Fragestellungen aufwerfen (nicht unbedingt klären) → “ what's next ”
- Immer die verwendeten Quellen angeben
- Es muss klar erkennbar sein, was die Studierenden aus den Quellen selbst erarbeitet haben
Dauer eines Vortrags ca. 20 Min. mit anschliessender kurzer Diskussion. Gerne können auch während des Vortrags die Teilnehmer einbezogen werden.
Quiz
Ein Quiz kann in beliebiger Form gestaltet werden (Papier, online-Quiz, Tafel, etc.).
Dabei muss das Quiz Themen der Vorlesung behandeln und soll diese durch anpruchsvoll gestaltete Elemente abfragen und festigen. Außerdem müssen sich die Studierenden überlegen, auf welche Art und Weise das Quiz in der Übung durchgeführt werden soll.
Auch muss erkennbar sein, dass die Studierenden ausführlich mit dem Thema und der Gestaltung des Quizzes und der Fragen beschäftigt haben.
Die Durchführung eines Quizzes soll einen Umfang von ca. 20 - 30 Min. haben.
Projekte
Ein Projekt funktioniert wie folgt:
- 3 bis 5 Studierende finden sich zu einem Team zusammen.
- Das Team formuliert einen schriftlichen Projektvorschlag: Was wollen wir tun? Warum? Was ist das Ziel des Projekts? Wann gilt das Ziel als erreicht (Kriterien)? Welche Teilaufgaben fallen dafür an? Wer soll welche erledigen? Wie viel Aufwand wird jede verursachen?
- Der Tutor stimmt dem Vorschlag zu (oder verlangt Änderungen/Ergänzungen). Projektthemen können beliebige Bereiche der Softwaretechnik betreffen, dürfen aber den Schwerpunkt nicht auf Implementierung haben. Es müssen insbesondere nichttriviale Planungs- und Qualitätssicherungselemente enthalten sein.
- Das Team präsentiert den Vorschlag im Tutorium und bittet um Kommentare: Ergänzungs- und Verbesserungshinweise, Warnungen vor Risiken und Fallen, technische Tipps
- Das Team führt das Projekt selbständig durch. Der Tutor steht als Ansprechpartner für Tipps oder bei heiklen Entscheidungen zur Verfügung.
- Das Team präsentiert dem Tutor das Projektergebnis, wobei alle Teammitglieder eine aktive Rolle übernehmen und auf die meisten Fragen fähig sein müssen, sinnvoll zu antworten.
- Der Tutor akzeptiert (hoffentlich) das Ergebnis.
- Das Team präsentiert das Ergebnis im Tutorium. Der Tutor entscheidet, ob alle Projektmitglieder ausreichend und gut am Projekt mitgewirkt haben um die Projektarbeit anerkannt zu bekommen.
Quellen
Software
- UML-Diagramme
- Offiziell: BOUML. Es ist nicht das tollste Programm der Welt, aber schnell und hinreichend gut. Alternativ können Sie die folgende große Liste von UML-Werkzeugen durchstöbern oder aber ein ganz normales, vektor-orientiertes Zeichenprogramm wie z.B. Inkscape nutzen.
- In den Rechnerpools: Auf den Rechnern im Keller ist IBM Rational Rose installiert, mit dem man perfekt Diagramme zeichnen kann. Rose hat allerdings eine Menge zusätzlicher Funktionen und ist nicht gerade ein schlankes Softwarepaket.
- Von Studenten empfohlen: Dia - Teil des Gnome-Desktops (auch unter Windows erhältlich)
Klausurvorbereitung
Grundsätzlich wird der Stoff der Vorlesung plus Stoff der Übungen geprüft. Die Übungsblätter geben einen guten Hinweis auf mögliche Aufgaben. Sie waren meistens wie folgt aufgeteilt: In der ersten Aufgabe wurden Begriffe abgefragt. In der Klausur werden diese Begriffe ohne weitere Erläuterung benutzt, aber explizit abgefragt werden sie allenfalls in Richtig/Falsch-Fragen, die insgesamt nur einen kleinen Teil der Klausur ausmachen werden, wenn überhaupt. Die letzten Aufgaben der einzelnen Übungsblätter waren meist Diskussionsanregungen, die in dieser Form schwerlich für Klausuren geeignet sind. Das heißt: Die zwei oder drei Aufgaben dazwischen definieren also den typischen Klausurstoff! Einige der Übungsblattaufgaben sind aus alten Klausuraufgaben hervorgegangen.
Ein Extra-Übungsblatt zur Klausurvorbereitung ist unter den Übungsblättern zu finden, zu dem auch Lösungshinweise gibt. Selbstverständlich kann es in der Klausur auch andere Aufgabenthemen und -typen geben; einige der Aufgaben dort sind aber sogar alte Klausuraufgaben.
Zusätzliches 3-LP-Projekt (nur für Studierende auf Lehramt)
Für das in Ihrem Lehramts-Studienplan geforderte Projekt/Praktikum im Umfang von 3 LP
gibt es keine explizite separate lehrveranstaltung.
Da es nur wenige betroffene Studierende gibt, suchen wir statt dessen für jede/n von Ihnen
eine individuelle Lösung.
Das Format ist angelehnt unter das für den Beitragstyp
[[ProjektInDerUebung]["Projekt"] oben im Abschnitt Übung
beschriebene, außer dass hier allein oder zu zweit (anstatt mit 3-5 Personen) gearbeitet wird.
Bitte wenden Sie sich entweder mit einer eigenen Projektidee an Ihren Tutor
oder mit der Bitte um einen Projektvorschlag an den/die Übungsleiter/in.
Historie des Stoffplans
- SS 2008 Vorlesung wegen Verlagerung ins Sommersemester von 30 auf 26 Einheiten gekürzt:
- die drei Einheiten zur eGK durch eine ganz neue ersetzt
- die zwei Einheiten zur UML-Einführung/Übersicht auf eine gekürzt
- die Einheit 35_Schnittstellenspezifikation etwas und 36_Objektimplementierung stark gekürzt und beide zusammengeführt
- WS 2005/2006
- Vorlesung komplett umgestellt auf ein eigenes Konzept, teilweise basierend auf Buch "Objektorientierte Softwaretechnik" von Brügge und Detoit.
- WS 2004/2005
- Vorlesung komplett umgestellt auf Buch SE7 von Ian Sommerville (zuvor: Buch von Helmut Balzert)
- WS 2003/2004
- Weggelassen:
- Einheit zu Komponenten (JavaBeans, COM);
- Einheit zu serverseitigen Komponenten (EJB, Corba, COM+)
- Einheit zu Web-UI (Servlet, JSP, CGI)
- Einheit zu Wiederverwendung
- Zugefügt:
- Einheit zu Dokumentation
- Einheit zu Testautomatisierung
- Einheit zu Risikomanagement
- WS 2002/2003 (Blockkurs im März)
- erste Durchführung, basierend auf Buch "Lehrbuch der Softwaretechnik" (Teil 1 und 2) von Helmut Balzert.
(Kommentare)
Wenn Sie Anmerkungen oder Vorschläge zu dieser Seite haben, können Sie sie
hier (möglichst mit Datum und Name) hinterlassen:
SWTIDSR