Sie sind auf Seite 1von 36

Softwaretechnik

(Software-Engineering)
Wintersemester 2010/2011
2.01.017

Andreas Winter
mailto:winter@se.uni-oldenburg.de
Jan Jelschen
mailto:jelschen@se.uni-oldenburg.de

© Andreas Winter 27.10.2010 Softwaretechnik 1


Zielgruppe
Bachelor of Science (3. Semester)
AM 5 – Softwaretechnik
o Informatik
• Basismodul, Pflicht
o Zwei-Fächer-Bachelor (90/30) (60/60)
• Professionalisierungsbereich
o Wirtschaftsinformatik
• Wahlpflicht, Professionalisierungsbereich
Master of Education
PB83 – Software-Engineering
o Informatik

© Andreas Winter 27.10.2010 Softwaretechnik 2


Organisatorisches
Vorlesung
Dozent: Andreas Winter
Termine: Donnertags, 8:30-10:00,
Raum: A11 1-101 (HS B)
Freitags, 10:15-11:45
Raum: A07 0-030
Beginn: 28. Oktober 2010
Übungen
Gruppen: 6
Beginn: 02./03./04. November 2010

© Andreas Winter 27.10.2010 Softwaretechnik 3


Organisatorisches
Veranstaltungsform:
o Vorlesung: 3 SWS
o Übung: 1 SWS

Terminplanung - Vorlesung
o bis zum Jahreswechsel: 4-stündig
(bis 17.12.2010) Donnerstags und Freitags
o nach dem Jahreswechsel: 2-stündig
(ab 06.01.2011) Donnerstags
Terminplanung –Übung
o durchgehend ein-stündig
(KW 43 - 6) DiMiDo

© Andreas Winter 27.10.2010 Softwaretechnik 4


Anmeldung zu den
Übungsgruppen bis
Organisatorisches 01.11.2010, 12:00

Übung 1 Übung 4
Tutor: Eike Langbehn (20) Tutor: Andreas Rehfeld (20)
eike.langbehn@uni-oldenburg.de andreas.rehfeldt@uni-oldenburg.de
Termin: Dienstags, 18:15-19:00 Termin: Mittwochs, 15:15-16:00
Raum: A06 4-418 Raum: A06 4-418
Übung 2 Übung 5
Tutor: Eike Langbehn (14) Tutor: Marion Gottschalk (16)
eike.langbehn@uni-oldenburg.de marion.gottschalk@uni-oldenburg.de

Termin: Dienstags, 19:50-20:00 Termin: Donnerstags, 14:15-15:00


Raum: A06 4-418 Raum: S 2-203
Übung 3 Übung 6
Tutor: Andreas Rehfeld (24) Tutor: Jan Jelschen (20)
andreas.rehfeldt@uni-oldenburg.de jelschen@se.uni-oldenburg.de

Termin: Mittwochs, 14:15-15:00 Termin: Donnerstags, 14:15-15:00


Raum: A06 4-418 Raum: A06 4-418

© Andreas Winter 27.10.2010 Softwaretechnik 5


Übungsbetrieb
Aufgabenblätter
o Bearbeitung in Kleingruppen (4 Personen)
o Bearbeitungszeit: eine Woche, Fr. bis Fr. 10:00
o erstes Aufgabenblatt: 29.10.2010
Hinweise
o Aufgabenblätter bauen nicht aufeinander auf
o fast alle Aufgaben waren einmal Klausuraufgaben
o Softwaretechnik ist Teamwork und erfordert Diskussionen
o Teamwork heißt nicht
• wenige arbeiten, der Rest sieht zu !!!
o Es gibt eher keine Musterlösungen
• Softwaretechnik muss man machen, das lernt
man nicht durch Lesen von Musterlösungen

© Andreas Winter 27.10.2010 Softwaretechnik 6


Übungsbetrieb - Termine
Verteilung auf Übungsgruppen
o Anmeldung zu den Übungsgruppen bis zum
01. November 2010, 12:00
in StudIP zur Vorlesung
Bildung der Kleingruppen (4 Personen)
o in den Übungen

© Andreas Winter 27.10.2010 Softwaretechnik 7


Übungsbetrieb
Freitags (Vorlesung)
o Ausgabe Themenblatt i
• in studIP zur Vorlesung: Dateien -> assignments
• auf der Website zur Vorlesung:
www.se.uni-oldenburg/teaching/st2010/
• im SVN: https://sehome.informatik.uni-
oldenburg.de/serep/teaching/ws1011/st2010/supplement/
o Rückgabe Themenblatt i-1 (bis 10:00)
• über das jeweilige Arbeitsgruppen-SVN
svn://orkan.Informatik.Uni-Oldenburg.DE:400XX/rXX/
– Lösungen ins Unterverzeichnis assignments einstellen
– für Graphiken und Texte: eine PDF-Datei: se_gXX_aYY.pdf einstellen
– für Programme: Java-Dateien (.java) in UTF-8 Codierung einstellen
– auf alle Seiten Namen der Bearbeiter und Übungsgruppe schreiben
– ausschließlich die Lösung in assignemnts einchecken

Dienstags/Mittwochs/Donnerstags (Übung)
o Vorbesprechung zu Themenblatt i
o Präsentation und Besprechung der Lösungen zu Themenblatt i-1

© Andreas Winter 27.10.2010 Softwaretechnik 8


Informationen zur Veranstaltung
Folien zur Vorlesung
o (fast) alle gezeigten Folien i.d.R. nach der Vorlesung
• in studIP zur Vorlesung: Dateien -> lecture
• im Web: www.se.uni-oldenburg/teaching/st2010/
• im SVN: https://sehome.informatik.uni-
oldenburg.de/serep/teaching/ws1011/st2010/supplement/
weitere Informationen zur Vorlesung
o News
• im StudIP zur Vorlesung
o Wiki
• im StudIP zur Vorlesung
• Hilfen und Informationen
• schöne Beispiellösungen
o Forum
• in StudIP zur Vorlesung
• bitte zur allgemeinen Diskussion nutzen
• Lösungsideen dürfen gepostet werden
© Andreas Winter 27.10.2010 Softwaretechnik 9
Klausur
Termin:
o Klausur: Donnerstag, 24.02.2011, 14-16 Uhr, A 14 1-101/2 (HS 1+2)
o Wiederholungsklausur:
Donnerstag, 31.03.2011, 8:30-10:30 Uhr, A07 0-030 (HS G)
Teilnahmebedingungen
o rechtzeitige Anmeldung zur Klausur
(Abwesenheit bei der Klausur trotz Anmeldung gilt als Fehlversuch)
o Leistungsnachweis (6 ECTS-Punkte)
o Erreichen von 50% der Gesamtpunkte der Klausur
Anreize zur aktiven Übungsteilnahme
• ab 70% der erreichbaren Punkte der Übungszettel: 1 Klausur-Bonuspunkt
• ab 80% der erreichbaren Punkte der Übungszettel: 2 Klausur-Bonuspunkte
• ab 90% der erreichbaren Punkte der Übungszettel: 3 Klausur-Bonuspunkte
• Klausur-Bonuspunkte werden nur zur Verbesserung der Note einer
bestandenen Klausur verwendet

© Andreas Winter 27.10.2010 Softwaretechnik 10


Organisatorisches
Termine:
28.10.2010 erste Vorlesung
29.10.2010 erstes Übungsblatt
01.10.2010, 12:00 Anmeldeschluss Übungsgruppen
02./03./04.10.2010 erste Übung
16.12.2010 Probeklausur
20.01.2011 letztes Übungsblatt
10.02.2011 Fragestunde
24.02.2011 Klausur
01.03-04.03.2011 European Conference on Software
Maintenance and Reengineering
31.03.2011 Nachklausur
© Andreas Winter 27.10.2010 Softwaretechnik 11
Wegweiser
Organisatorisches
1 Grundlagen und Motivation
1.1 Zielsetzung der Vorlesung
1.2 Literatur
1.3 Software-Fehler
1.4 Probleme bei der
Software-Entwicklung
1.5 Ingenieurdisziplin
Software-Engineering
1.6 Softwaretechnik-Prinzipien

© Andreas Winter 27.10.2010 Softwaretechnik 12


1.1 Zielsetzung der Vorlesung

© Andreas Winter 27.10.2010 Softwaretechnik 13


Algorithmen und Datenstrukturen
Java-Programmierung

Vorwissen
Grundbegriffe der Objekt-orientierten Software-Entwicklung
o Klasse, Objekt
o Variable, Methode
o Zuweisung,
Kontrollstrukturen (Sequenz, Verzweigung, Iteration)
o Vererbung
Grundlegende Datenstrukturen
o Liste, Menge, Multimenge, Stapel ...
Grundlegende Algorithmen
o Suchverfahren
o Sortierverfahren

© Andreas Winter 27.10.2010 Softwaretechnik 14


Zielsetzung der Vorlesung
Problembewusstsein schaffen
o Ursachen für Probleme der Informationstechnik erkennen
o Notwendigkeit für Softwaretechnik erkennen
Überblick vermitteln
o Terminologie der Softwaretechnik verstehen und anwenden
o zentrale Tätigkeiten zur Erstellung großer Softwaresysteme
erkennen und einordnen
o zentrale Rollen der bei der Erstellung großer Softwaresysteme
Beteiligten erkennen und einordnen
Handwerkzeug vermitteln
o Vorgehensweisen der Softwaretechnik bewerten und anwenden
o Prinzipien, Methoden und Techniken der Softwaretechnik bewerten
und anwenden

© Andreas Winter 27.10.2010 Softwaretechnik 15


• hier:
mehrere Mitarbeiter
Szenario über einen langen Zeitraum
• hier nicht:
ein "Freizeit"-Programmierer

Erstellung eines großen Softwaresystems


für einen Auftraggeber
• hier:
im Rahmen eines Projekts Individualsoftware
• hier nicht:
Standardsoftware
(COTS, commercial
• hier: of the shelf)
einmalige Zielverfolgung
• hier (eher) nicht:
dauerhafte Weiterentwicklung
© Andreas Winter 27.10.2010 Softwaretechnik 16
Grundlegende Begriffe
Software
o ist eine Menge von Programmen oder Daten zusammen
mit begleitenden Dokumenten, die für ihre Anwendung
notwendig oder hilfreich sind.
Projekt
o ist die zeitlich begrenzte, einmalige Verfolgung eines
vorgegebene Ziels, die zu einem definierten Ergebnis
führt.
Produkt
o ist ein i. Allg. für einen Auftraggeber erstelltes, in sich
abgeschlossenes Ergebnis eines erfolgreich
durchgeführten Projekts.
[Hesse et al., 1984] [Balzert, 2001, S. 23ff]
© Andreas Winter 27.10.2010 Softwaretechnik 17
Aktivitäten der
Software-Entwicklung
Softwaresystem Softwaresystem
• •Prozess-
Program-
Modelle
Lastenheft
Pflichten-
Akezptanz-
Software-
konstruk-
entwickeln weiterentwickeln
•mieren
modelle
Architektur
heft
sicherung
Wartung
tive
Projekt-
Modellie-
imder
•Kleinen
Software-
kalkulation
Qualitäts-
moderne
Schulung
Software-
rungs- Softwareprojekt
• •Program-
entwicklung
Spezifi-
strukturierte
Evolution
sicherung
Projektplan
Software-
Sichten planen
• •Aktivitäten
ierricht-linien
Analyse
kation
abnahme
Programm-
Team
visuelle
analytische
• •Entwurfs-
der
Modellie-
verstehen
Qualitäts-
Objekt- Anforderungen
muster
Software-
orientierte
rungs-
sicherung erheben
• entwicklung
Analyse
sprachen
Messen Softwaresystem
• Testen entwerfen
• Verifizieren
Softwaresystem
realisieren

Softwaresystem
einführen

© Andreas Winter 27.10.2010 Softwaretechnik 18


Themen der Vorlesung
o Aktivitäten der Software- o Qualitätssicherung
Entwicklung o Qualitätskriterien,
o Objektorientierte o Testen
Modellierung mit UML o Reviews

o Metamodellierung o Software-Evolution
o Software-Wartung
o Anforderungserhebung
o Reverse-Engineering
o Vision
o Reengineering
o Anforderungen
o Anforderungsdefinition
o Vorgehensmodelle und
Management von
o Software-Systementwurf
Software-Projekten
o Architektur
o Unified Process
o Architektur- und Designmuster
o Extreme Programming
o Schnittstellen
o Softwarespezifikation
© Andreas Winter 27.10.2010 Softwaretechnik 19
Nicht Thema dieser Vorlesung
o Kommunikationstechniken
o Präsentationstechniken
o Erhebungstechniken
(Befragung, Interview, Gruppendiskussion)
o Semantik von Modellierungssprachen
o formale Methoden der Softwaretechnik
o Codierung
(Programmieren, Algorithmik)
o Projektmanagement

© Andreas Winter 27.10.2010 Softwaretechnik 20


1.2 Literatur

© Andreas Winter 27.10.2010 Softwaretechnik 21


Literatur

Lehrbücher
o Ian Sommerville: Software Engineering, Addison-Wesley
Longman, Amsterdam, 9. Auflage, 2011.
o Jochen Ludewig, Horst Lichter: Software Engineering,
Dpunkt, 2. Auflage, 2006.
o Helmut Balzert: Lehrbuch der Software-Technik,
Basiskonzepte und Requirements Engineering, Spektrum,
Heidelberg, 3. Auflage, 2009.
o Helmut Balzert: Lehrbuch der Software-Technik, Band 2:
Software-Management, Spektrum, Heidelberg, 2008.
© Andreas Winter 27.10.2010 Softwaretechnik 22
Literatur
ergänzende Literatur
o Carlo Ghezzi, Mehdi Jazayeri, Dino Mandrioli: Fundamentals of
Software Engineering, Prentice Hall, New York, 1991.
o John McDermid: Software Engineer´s Reference Book,
Butterworth and Heinemann, Oxford, 1991.
o Helmuth Partsch: Requirements-Engineering systematisch,
Modellbildung für softwaregestützte Systeme, Springer, Berlin,
1998.
o Gustav Pomberger, Günter Blaschek: Software Engineering,
Prototyping und objekt-orientierte Software-Entwicklung,
Hanser, München, 1993.
o Roger S. Pressmann, Darrel Ince: Software Engineering,
A Practitioner´s Approach, European Adaption,
McGraw-Hill, London, 5. ed., 2000.

© Andreas Winter 27.10.2010 Softwaretechnik 23


Literatur
Zeitschriften
o IEEE Transactions on Software Engineering, IEEE Computer
Society, (seit 1975).
o Software Engineering Notes, ACM Special Interest
Group on Software Engineering, (seit 1976).
o Softwaretechnik-Trends, Gesellschaft für Informatik,
Fachgruppen Softwaretechnik, Ada, Requirements-Engineering,
Test, Analyse und Verifikation von Software, Objektorientierte
Software Entwicklung, Software-Reengineering (seit 1980).
o IEEE Software, IEEE Computer Society, (seit 1984).
o ACM Transcations on Software Engineering and Methodology,
Accociation for Computing Machinery, (seit 1992).

© Andreas Winter 27.10.2010 Softwaretechnik 24


1.3 Software-Fehler

© Andreas Winter 27.10.2010 Softwaretechnik 25


Software-Fehler
Fehler
o Bei der rechnergestützten Auswertung der OB-Wahl in
Neu-Ulm 1994 wurde zunächst eine Wahlbeteiligung von
104% festgestellt.
Ursache
o In der Auswertungs-
software hatte sich ein
Faktor 2 eingeschlichen.
Folge
o Neuauszählung

[Partsch, 1998, S. 1]
© Andreas Winter 27.10.2010 Softwaretechnik 26
Software-Fehler
Fehler
o vollständiger Batterieausfall in Fahrzeugen eines
deutschen Automobil-Herstellers
Ursache
o Fehler in der Software-
gesteuerten
Innenbeleuchtung
Folge
o Rückrufaktion mit
einem (geschätzten)
Schaden von
mehreren Millionen DEM
[Partsch, 1998, S. 1]
© Andreas Winter 27.10.2010 Softwaretechnik 27
Software-Fehler
Fehler (2.8.2007)
o Online-Übermittlung eines Papers zur Veröffentlichung in
einem Konferenzband wird trotz korrekter Eingabe nicht
akzeptiert
Ursache
o Software-Entwickler hat "Our programmer changed
am Tag zuvor "etwas" something simple yesterday for
geändert und war dann the front matter that is causing this
in Urlaub gefahren. problem, and he's out for a
personal reason today."
Folge (aus der Fehlermail)

o manuelle Übermittlung aller


Beiträge per Mail.

© Andreas Winter 27.10.2010 Softwaretechnik 28


Software-Fehler
Fehler:
o Netzwerk stürzte bei Xerox
mehrfach komplett ab.
Ursache:
o Inkompatibilität zwischen
Microsoft Windows XP (beta)
und Cisco 5000 Routers.
Folge:
o Warnung an alle 50.000 U.S. Mitarbeiter von Xerox
"not to install XP betas without permission or they´d
face disciplinary action".
[ACM SIGSOFT Software Engineering Notes, vol. 26, no 4, (2001), S.6]
© Andreas Winter 27.10.2010 Softwaretechnik 29
Software-Fehler
Fehler:
o Ausfall der Aktienhandels-
Website von Charles Schwab
& Co am 24.2.1999, 5 min
nach Eröffnung des Handels
an der NYSE.
Ursache:
o Fehlgeschlagenes Software Upgrade in einem neuen
Mainframe System in Phoenix.
Folge:
o weitere Fehler in anderen Online-Aktienhandel-Systemen
(E-Trade, Waterhouse,
[ACM SIGSOFT Software Engineering
Ameritrade, Datek) Notes, vol. 24, no 3, (1999), S.25]
© Andreas Winter 27.10.2010 Softwaretechnik 30
Software-Fehler
Fehler
o USS Yorktown treibt während
eines Manövers im September
1997 manövrierunfähig bei
Cape Charles, VA.
Ursache
o Fehler in einer Routine zum Abfangen einer Division
durch Null in einer Windows NT Applikation.
o Die "Null" wurde als manuelle Eingabe einer enormen
Datenmenge interpretiert.
Folge
o "Atlantic Fleet officials said the ship was dead in water
for about 2 hours and 45 minutes." [ACM SIGSOFT Software Engineering
Notes, vol. 24, no 1, (1999), S.31]

© Andreas Winter 27.10.2010 Softwaretechnik 31


Software-Fehler
Fehler:
o Ariane 5 kommt auf ihrem Jungfernflug
501 vom Kurs ab.
Ursache:
o Software zur Überwachung der Flugbahn
(SRI) wurde teilweise aus Ariane 4
übernommen.
o SRI rechnete nach dem Start weiter, obwohl
Ergebnisse nicht mehr benötigt wurden.
o Flugbahnberechnung erzeugte Überlauf wodurch wichtige Flugdaten
überschrieben wurden.
o Das SRI-System und sein Backupsystem schalteten sich aufgrund
des Fehlers ab.
Folge:
o Aufruf der Selbstzerstörung der Rakete
(Verlust: 500 000 000 USD) [Pfleeger, 1998, S.37]
© Andreas Winter 27.10.2010 Softwaretechnik 32
Software-Fehler
Fehler:
o Patriot-Rakete verfehlt im
2. Golf-Krieg eine abzu-
schießende Scud-Rakete
und schlägt in eine US-Kaserne in Dhahran ein.
Ursache:
o Patriot war ursprünglich nicht als Anti-Raketen-Rakete konzipiert
o Steuercomputer lief 4 Tage statt maximal 14 Stunden ununterbrochen.
o internes 24 Bit Register lief über und verursachte Rundungsfehler bei
der Bahnberechnung.
o Timerintervall von Manager von 1/8 sec auf 1/10 sec geändert. Ohne
diese Änderung wäre der Überlauf nicht aufgetreten.
Folge:
[ACM SIGSOFT Software Engineering
o 28 Tote Notes, vol. 16, no 3, (1991), S.19f]
© Andreas Winter 27.10.2010 Softwaretechnik 33
Fehlerursachen (Zusammenfassung)
o typische Programmierfehler (z.B. Speicherüberläufe)
o fehlende Qualitätssicherung (z.B. Test nach Erweiterung)
o Inkompatibilitäten verschiedener Systemkomponenten
o inkorrekte/unvollständige Fehlerbehandlung
o Wiederverwendung von Code, der unter anderen
Voraussetzungen entwickelt wurde, und deren
Verwendungsvoraussetzungen unklar waren.
o Eingriffe in Softwaresysteme durch unqualifizierte
Mitarbeiter
o Fehlerhafte Nutzung

© Andreas Winter 27.10.2010 Softwaretechnik 35


Folgerungen
für die Software-Entwicklung (1)
o Anforderungen an ein Softwaresystem sind
präzise, nachprüfbar, und möglichst eindeutig
festzulegen.
o Vorgehensweisen und Zuständigkeiten zur
Software-Entwicklung sind genau festzulegen.
o Entwurfsentscheidungen sind für spätere
Weiterentwicklungen und Wiederverwendungen
zu dokumentieren.
o Rahmenbedingungen der Softwarenutzung sind
festzulegen und zu dokumentieren
© Andreas Winter 27.10.2010 Softwaretechnik 36
Folgerungen
für die Software-Entwicklung (2)
o Tatsächliche Realisierung der gestellten
Anforderungen durch das Softwaresystem ist zu
überprüfen.
o Korrektes Zusammenspiel aller System-
komponenten ist sicherzustellen.
o Softwaresysteme sind gegen typische
Programmierfehler abzusichern
(Vorsicht: Fehler in Fehlerbehandlungsroutinen)
o Software ist soweit wie möglich gegen
Fehlbedienungen abzusichern.
© Andreas Winter 27.10.2010 Softwaretechnik 37