stop Die aktuelle Softwaretechnik-Webseite finden Sie stets unter VorlesungSoftwaretechnik. stop

Softwaretechnik WS2004/2005

09 Aug 2023 - 17:03 | Version 56 |

Dies ist die detaillierte Veranstaltungsseite zur Vorlesung und Übung "Softwaretechnik".

Beschreibung

Softwaretechnik (oder englisch Software Engineering) ist die Lehre von der Softwarekonstruktion, also das Grundlagenfach zur Methodik. Die Softwaretechnik ist bemüht, Antworten auf die folgenden Fragen zu geben:

Diese Vorlesung gibt einen Überblick über die Methoden 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

Zum Empfang aktueller Mitteilungen über die Vorlesung und Übung sollten sich alle Hörer/innen auf die Mailingliste se_v_swt@lists.spline.inf.fu-berlin.de eintragen. Dort bitte auch den vollen Namen angeben.

Prüfungsmodalitäten

Kriterien für den Erwerb des Übungsscheins (Diplom) bzw. der Leistungspunkte (Bachelor) sind

Die Details werden in den Übungsgruppen erläutert. Zu Details des Übungs-/Tutoriumsablaufs siehe UebungsRegeln.

Klausurtermine siehe bei VorlesungSoftwaretechnik2004.

Inhalt

Literatur

Die Vorlesung basiert auf dem Lehrbuch

Ian Sommerville: "Software Engineering", 7th edition, Pearson Education, 2004.

Das Buch ist momentan leider noch nicht auf Deutsch verfügbar. Der Preis beträgt ca. EUR 65,-.

Da das Buch in Englisch ist, die Übungsblätter aber in Deutsch, haben wir ein Übersetzungs-Glossar entwickelt.

Die Anschaffung des Buches ist sehr empfohlen (zumal Softwaretechnik ein Thema ist, das auch nach dem Studium sehr relevant bleibt), ist aber nicht zwingend notwendig.

Stoffplan

Die Foliensätze sind auf Englisch; Vortragssprache ist jedoch Deutsch. Sie sollten die Terminologie sowohl auf Englisch als auch auf Deutsch beherrschen. Um das zu erleichtern, werden wir im Verlauf des Semesters ein Glossar einrichten.

  1. An Introduction to Software Engineering
    Anmerkungen
    • Wichtigkeit von Softwaretechnik (Software Engineering); Problemstellungen der Softwaretechnik; Professionelles Verhalten von Software-Ingenieuren; Softwareprodukt = Programme + Dokumentation; Software-Produktattribute (Wartbarkeit, Verlässlichkeit, Effizienz, Benutzbarkeit u.a.); Software-Prozess (Spezifikation, Entwicklung, Validation, Evolution); Methoden (Prozesse, Notationen, Form- und Verhaltensregeln); CASE-Werkzeuge (Editoren, Datenablagen, Prüfwerkzeuge, Automatisierungswerkzeuge); Anmerkungen (Lernziele, Prinzipien, Lernstil)
  2. Socio-technical Systems
    • Sozio-technische Systeme versus HW-/SW-Systeme; Kontext; emergente Eigenschaften; system engineering (insbes. Integration); Systembeschaffung; Altsysteme
  3. Critical Systems
    • Kritisches System (sicherheitskritisch, geschäftskritisch); Verlässlichkeit (Verfügbarkeit, Zuverlässigkeit, Sicherheit, Schutz); Maßnahmen (Fehlervermeidung, Defektentfernung, Schadensbegrenzung); sozio-technischer Entwurfsansatz
  4. Software Processes
    • Generische Software-Prozessmodelle (Wasserfallmodell; evolutionäre Entwicklung; komponentenbasierte Entwicklung); Benutzungskriterien; Iteration; Rollen, Aktivitäten, Phasen; Modelle für Anforderungsbestimmung, Entwicklung, Test, Evolution; Rational Unified Process (RUP); Rolle von CASE
  5. Project Management and Risk Management
    • Aufgaben; Eigenarten; Projektplanung (Meilensteine; grafische Darstellungen); Risiken und Risikomanagement
  6. Software Requirements
    • Benutzeranforderungen, technische Anforderungen; Funktionale und nichtfunktionale Anforderungen; Anforderungsdokument; Schnittstellenbeschreibungen
  7. Requirements Engineering Processes
    • Aktivitäten: Machbarkeitsstudie, Anforderungserhebung, -beschreibung, -analyse, -validation, -verwaltung; Beteiligtengruppen; soziale und organisatorische Faktoren; Qualitätsmerkmale für Anforderungen (Gültigkeit, Widerspruchsfreiheit, Vollständigkeit, Realismus, Überprüfbarkeit); Veränderung von Anforderungen
  8. System Models
    • Modelle und Sichten; Kontext/Umgebung; Verhaltens-, Daten-, Objektmodelle; Methoden
  9. Critical Systems Specification
    • Verlässlichkeits- und Sicherheitsanforderungen; Spezifikation von Sicherheit, Schutz, Zuverlässigkeit; Risikogetriebene Spezifikation; Quantifizierung und Maße (POFOD, ROCOF, MTTF, Verfügbarkeit); Induzierte funktionale Anforderungen (Versagensvorbeugung und -behandlung)
  10. Formal Specification
    • Rolle bei der Anforderungsanalyse; Anwendungsbereich; algebraische Schnittstellenbeschreibung; modellbasierte Verhaltensbeschreibung (Zustand, Vor-/Nachbedingungen); formale und nichtformale Spezifikation; Einbettung in den SW-Prozess
  11. Architectural Design
    • Entscheidungen auf der Architekturebene; Aspekte von Architektur (Organisation, Zerlegung, Verteilung, Steuerung); Architekturstile; Referenzarchitekturen (Aspekte: Domänenwissen, Beschreibung/Übermittlung von A., Vergleich von A., Bewertung von A.); Organisationsarten (Ablagen, Client/Server, abstrakte Maschinen); Zerlegungsarten (Objekte, Pipelines); Steuerungsarten (zentralisiert, ereignisbasiert)
  12. Distributed Systems Architectures
    • Vorteile (gemeinsame Ressourcennutzung, Offenheit, Nebenläufigkeit, Skalierbarkeit, Fehlertoleranz); Nachteile (Komplexität, Dienstqualität); Client/Server; verteilte Objekte; Object Request Broker (CORBA); dienstorientierte Architekturen; Peer-to-Peer-Architekturen; firmenübergreifende Systeme
  13. Application Architectures
    • Stapelverarbeitung (Eingabe, Verarbeitung, Ausgabe) vs. Transaktionsverarbeitung (Fortschreibung einer Datenbank); Resourcenverwaltungssysteme; ereignisverarbeitende Systeme; sprachen-verarbeitende Systeme
  14. Object-oriented Design
    • Entwurf als Menge interagierender Objekte, die jeweils über Zustand und Operationen verfügen; Objekte als Dienstgeber; Entwurfsprozess; UML (diverse Arten von statischen und dynamischen Modellen; Diagramme und Modelle); Schnittstellen und Verkapselung
  15. Real-time Software Design
    • Echtzeitsysteme (Anforderungen; nebenläufige Prozesse; Sensoren und Aktuatoren); Entwurfsprozess; Echtzeit-Betriebssystem; generische Prozessarchitekturen (Überwachungs-, Steuerungs-, Datensammelsysteme)
  16. User Interface Design
    • Entwurfsprinzipien; Interaktionsstile (direkte Manipulation, Menüsysteme, Formularsysteme, Kommandosprachen, natürliche Sprache); grafische vs. textuelle Präsentation von Informationen; Farbe; Entwurfsprozess (Benutzeranalyse, Prototyping, Benutzbarkeitsprüfung)
  17. Rapid Software Development
    • Inkrementelle, iterative und agile Methoden; Extreme Programming (Kundeneinbindung; allmähliche Verbesserung; Test-zuerst-Entwicklung; etc.); Prototypansatz vs. interative Entwicklung (schlecht vs. gut verstandene Anforderungen zuerst); Werkzeuge zur Entwicklung von Prototypen
  18. Software Reuse
    • Vorteile (Kosten; Entwicklungszeit; Risikominderung); Hindernisse (Verfügbarkeit; Entdeckung; Verstehen; Brauchbarkeit; Vertrauen; Anpassung; Fortschreibung); Arten von Wiederverwendung (Muster; Generatoren; Frameworks; Komponenten; Anwendungen); COTS; Software-Produktlinien; ERP-Systeme
  19. Component-based Software Engineering
    • Komponenten (Export-Schnittstelle; Import-Schnittstelle); Komponentenmodelle (Standards+Infrastruktur); Entwicklungsprozess (Zerlegung in Komponenten; Komponenten bauen oder finden; Zerlegung anpassen; Adapter bauen; Komposition); Probleme (Verfügbarkeit; Eignung; Versionen; Evolution)
  20. Critical Systems Development
    • Verlässlichkeit durch Fehlervermeidung, Fehlererkennung und Fehlertoleranz; Fehlertoleranz (Fehlerentdeckung, Schadensanalyse, Wiederaufsetzen, Fehlerreparatur); Wege zu Fehlertoleranz (Diversität; Redundanz); Fehlervermeidung im SW-Prozess (definierter Prozess; Vermeidung bestimmter Konstrukte); spezifische Techniken (Ausnahmebehandlung; N-Versions-Programmierung; Wiederherstellungsblöcke)
  21. Software Evolution
    • Veränderung und Nutzen; Wartung und Kostenfaktoren; Prozesse für Evolution; Lehmans Gesetze; korrektive, adaptive und erweiternde Wartung; Re-Engineering (Restrukturierung, Nachdokumentation); Vorgehen je nach Zustand und Wert des Systems
  22. Verification and Validation
    • Verifikation (gegen Spezifikation) versus Validierung (gegen Bedürfnisse); statische Analyse (z.B. Inspektionen); dynamische Analyse (Test); Cleanroom-Prozess (inkrementelle Entwicklung mit Transformationen; statische Verifikation; statistisches Testen); Testpläne
  23. Software Testing
    • Validierungstesten (um Zuverlässigkeit zu zeigen) versus Defekttesten (um Probleme aufzudecken); Komponententest, Integrationstest, Systemtest; Testfallentwurf (Funktionstest (black box), Strukturtest (white box); Schnittstellentest, Äquivalenzklassen-Partitionierung); Testautomatisierung
  24. Critical Systems Validation
    • Messung von Zuverlässigkeit; Wachstumsmodelle für Zuverlässigkeit; Sicherheitsargumente; Sicherheits- und Verlässlichkeitsfälle; Benutzungsprofile; Gefahrenerkennung und -überwachung;
  25. Managing People (individuals and groups)
    • Überlegungen zu Personalauswahl (Ausbildung, Bereichserfahrung, Anpassungsfähigkeit, Persönlichkeit) und Personalbindung; Motivationsfaktoren (Interaktion, Anerkennung, Weiterentwicklung); P-CMM (People Capability Maturity Model); Kommunikation in Gruppen (Status, Gruppengröße, Organisationsform, Geschlechter, Persönlichkeitstypen); Arbeitsumgebung (Interaktionsräume, abgeschirmte Arbeitsräume);
  26. Software Cost Estimation
    • Faktoren: Entwicklungszeit, Größe, Personal, Ausstattung, Kosten; Schätzverfahren (); Preisangebote versus Produktionskosten; Personalausstattung versus Entwicklungszeit; Produktivitätsfaktoren (Begabung, Bereichserfahrung, Projektgröße, Werkzeugunterstützung, Arbeitsumfeld, etc.); COCOMO 2 ()
  27. Quality Management
    • Aufgabe; Dokumentation; Standards und bewährte Praktiken; Begutachtungen; Messungen und Maße
  28. Process Improvement
    • Prinzipien; Prozessqualität versus Produktqualität; CMM (Capability Maturity Model: ad-hoc, wiederholbar, definiert, quantitativ verwaltet, optimierend) und seine Anwendbarkeit; Prozessmodelle (Teilprozesse, Aufgaben, Aktivitäten, Bedingungen, Ausnahmen, Rollen, Kommunikationspfade, zu liefernde Ergebnisse); zielorientiertes Messen
  29. Configuration Management
    • Konfigurationsverwaltung (oder -management, KM); Aktivitäten (Planung, Versionsverwaltung, Änderungsverwaltung, Erbauen); Systemfreigaben (Programme, Daten, Konfigurationsparameter, Dokumentation); Werkzeuge (Revisionsverwaltung, Konfigurations- und Änderungsverwaltung, Erbauer); Versionsidentifikation und -auswahl
  30. Der Persönlichkeitstyp
    • Was ist das?; Wozu soll das gut sein?; Die Jung'schen Kategorien (extrovertiert/introvertiert, wahrnehmend/intuitiv, denkend/fühlend, hinnehmend/entscheidend); zugehörige Typsysteme und Messinstrumente (MBTI, KTS); andere Typsysteme (Enneagramm, Big Five); Wie bestimme ich meinen Typ?
  31. Tipps zur Anforderungsanalyse
    • noch mal einige Hinweise zum Thema Urteilskraft und Konzentration auf das Wesentliche. (Die Cartoons hierin sind nicht so ernstzunehmen; die Hinweise aber durchaus)
  32. Kleinkram, Nachbemerkungen
    • KISS, empfehlenswerte Gewohnheiten (Ingenieurnotizbuch, Fehlerbuch, Datumstempel, TODO-Marken); Englischkenntnisse; Hinweis zur beruflichen Zufriedenheit; praxisrelevante weiterführende Literatur

Übungsblätter

Historie des Stoffplans

WS 2004/2005:

WS 2003/2004:

WS 2002/2003 (Blockkurs im März):

Übersetzungs-Glossar

(Kommentare)

Wenn Sie Anmerkungen oder Vorschläge zu dieser Seite haben, können Sie sie hier (möglichst mit Datum und Name) hinterlassen:

Bei Lehmann's Online Büchershop gibt es das obige Buch auch derzeit für 57,50 EUR siehe http://www.lob.de

-- Heiko Ehrig - 15.10.2004

Ich fände es sinnvoll, wenn im Abschnitt über Patterns "Inversion of Control (Kontrollumkehr)" erwähnt werden würde, da diese eins der Hauptprobleme des Zusammenfügens von Komponenten behebt. Es ist eins der fehlenden Teile, ohne welche der eigene Code immer einen Rest Uneleganz behält.

-- ChristopherOezbek - 12 Jan 2005