Vorlesung: Softwaretechnik / Software Engineering
Übersicht
Für die Entwicklung von guter und erfolgreicher Software braucht es mehr als nur Programmierkenntnisse. Softwaretechnik (engl. Software Engineering) beschäftigt sich mit der systematischen Verwendung von Prinzipien, Methoden und Werkzeugen für die arbeitsteilige, ingenieurmäßige Entwicklung und Anwendung von umfangreichen Softwaresystemen.
Professionelle Softwareentwickler, -architekten, und -manager müssen folgende Fragen beantworten können:
- Wann ist ein Softwareprodukt gut genug um es auszuliefern?
- Haben wir das entwickelt was der Kunde oder der Nutzer wirklich braucht?
- Was machen wir, wenn wir morgen auf einmal 10 und übermorgen 100 mal mehr Nutzer für unser Softwaresystem haben?
- Wie können wir Änderungen möglichst schnell und sicher in unsere Software einspielen?
- Woran liegt es, dass wir bei der Softwarenetwicklung nicht so gut sind wie andere?
Erfolgreiche Software-Projekte erfordern mehr als nur technisches Fachwissen. Herauszufinden, was der Kunde will, in einem Team zusammenzuarbeiten, Komplexität zu managen, Risiken zu mindern, Zeit- und Budgetvorgaben einzuhalten und unter verschiedenen Einschränkungen zu bestimmen, wann ein Produkt gut genug ist, um ausgeliefert zu werden, sind mindestens ebenso wichtige Themen, die oft eine bedeutende menschliche Komponente haben. Die Vorlesung befasst sich mit diesen Themen und deckt dabei die Grundlagen der modernen Softwaretechnik weitgehend ab.
Wir werden die folgenden Themen untersuchen:
- Prozessbetrachtung in der Software-Entwicklung
(Wie lassen sich Probleme frühzeitig vermeiden? Wann und wie viel ist zu entwerfen? Wann und wie viel ist zu testen? Wann und wie sind die Kunden einzubeziehen? Agile Methoden...) - Anforderungserhebung, -dokumentation und -auswertung
(Wie findet man heraus, was der Kunde wirklich will? Wer hat noch ein Interesse? Wie können wir den Erfolg objektiv messen? Wie können wir Erwartungen zuverlässig dokumentieren? ...) - Software Design und Software Architektur
(Wie können wir ein System so gestalten, dass es für Millionen von Benutzern skalierbar ist? Wie können wir Sicherheit in ein System einbauen?) - Maßnahmen zur Qualitätssicherung inkl. Messung, Inspektion, statische und dynamische Analyse
(Welche Qualitätssicherungsstrategie ist für ein bestimmtes System am besten geeignet? Was können wir automatisieren und wann sollten wir die Menschen auf dem Laufenden halten? Wie viele Tests und welche Art von Tests sollten wir durchführen? Welche Eigenschaften sind wichtig, um über die funktionale Korrektheit hinaus sicherzustellen? Können wir Benutzbarkeit, Skalierbarkeit, Zuverlässigkeit, Leistung bewerten? Wie können wir die Abwesenheit bestimmter Sicherheitsprobleme statisch garantieren? ...) - Empirische Methoden in der Softwaretechnik
(Wie können wir Qualitätsmerkmale wie Leistung, Sicherheit und Zuverlässigkeit messen? Wie können wir messen, wie Benutzer mit dem System interagieren? Wie können wir wissen, ob der Unterschied von Bedeutung ist? ...) - Zeit- und Teammanagement / Netzplan
(Wie schätzt man die Dauer und die Kosten eines Projekts ein? Wie überwacht man Fortschritt und Risiken, um Probleme frühzeitig zu erkennen? Wie koordiniert man Entwickler in einem Team? Wie kann man Teams bilden und entwickeln? Wie wählt man Teammitglieder aus und motiviert sie? Wie geht man mit Teamdynamiken wie Social Loafing um? ...) - Ökonomie der Software-Entwicklung
(Geschäftsmodelle, Outsourcing, Open Source, ...)
Dieser Kurs hat einen starken technischen Schwerpunkt und umfasst Hausaufgaben mit und ohne Programmierung. Die Studierenden sammeln Erfahrungen mit Teammanagement und modernen Software-Engineering-Tools. Der Kurs bereitet die Studierenden optimal auf Führungspositionen in Softwareentwicklungsprojekten vor.
Die Hausaufgaben (zum Großteil Gruppenarbeit) beinhalten:
- Ein Prototyping-Projekt, bei dem jedes Team ein Softwareprojekt plant und ein Minimal Viable Product (MVP) erstellt.
- Ein Anforderungsprojekt, bei dem jedes Team Stakeholder befragt, um Anforderungen für ein Softwaresystem zu ermitteln und zu dokumentieren.
- Ein Architekturprojekt, bei dem jedes Team Architekturalternativen diskutiert, auswertet und teilweise implementiert.
Ein Analyseprojekt, bei dem jedes Team ein bestehendes Open Source System analysiert und bewertet.(entfält dieses Jahr)
Organisation
Die Vorlesung findet Montags und Mittwochs jeweils von 16:00 - 17:30 Uhr als Zoom Meeting statt (Einwahldaten sind im Ilias-Kurs).
Begleitend zur Vorlesung gibt es insgesamt 4 Übungsgruppen. Die Übungen starten am 4.11.20.
Gruppe 1: Montags, 12:00 - 13:30 Uhr (startet erst am 9.11.20)
Gruppe 5: Dienstags, 10:00 - 11:30 Uhr (startet erst am 17.11.20)
Gruppe 2: Mittwochs, 10:00 - 11:30 Uhr
Gruppe 3: Donnerstags, 08:00 - 09:30 Uhr
Gruppe 6: Donnerstags, 14:00 - 15:30 Uhr (fällt aus am 19.11.20)
Gruppe 4: Freitags, 08:00 - 09:30 Uhr
Ansprechpartner
Zeitplan
Datum | Thema | Literatur | Abgabe |
---|---|---|---|
Mo, 02.11.20 | Einführung | ||
Übung | Tools für kollaboratives Arbeiten (Git, GitHub, Git Workflow) | ||
Mi, 04.11.20 | Entwicklungsprozess (Einführung, Planung, Risiko- und Fortschrittskontrolle) | ||
Mo, 09.11.20 | Case Study (Airbus 737 Max) | Seattle Times Artikel zu Boeing 737 Max | |
Übung | Measuring Software Characteristics | ||
Mi, 11.11.20 | Measurement | Buse, Zimmermann. Information Needs for Software Development Analytics. ICSE 2012 | |
Mo, 16.11.20 | Software Archeology | HA1 (Planungsdokumente) | |
Übung | Let's fix some bugs | ||
Mi, 18.11.20 | Requirements (Intro) | ||
Mo, 23.11.20 | Requirements (Elicitation and Documenation) | ||
Übung | Requirements Interviews | ||
Mi, 25.11.20 | Requirements (Validation and Risk) | Sommerville, Software Engineering, Kapitel 10 "Verlässliche Systeme" | HA1 (Code) |
Mo, 30.11.20 | Architecture (Intro) | HA1 (Reflexion) | |
Übung | Architectural Assessement and Decision | ||
Mi, 02.12.20 | Architecture (Documentation, patterns, tactics, evaluation) | Twitter: "New Tweets per second record, and how!" | |
Mo, 07.12.20 | Architecture (Microservices, DevOps) | ||
Übung | Continous Integration and Docker | ||
Mi, 09.12.20 | Quality Assurance (Intro) | ||
Mo, 14.12.20 | Quality Assurance (Inspection and reviews) | ||
Übung | Code Review and Static Analysis | ||
Mi, 16.12.20 | Quality Assurance (Static Analysis) | HA2 (Anforderungen) | |
Mo, 21.12.20 | Interview / AMA Session | Sadowski et al. Lessons from Building Static Analysis Tools at Google. CACM, 2018 | HA2 (Reflexion) |
Mo, 11.01.21 | Quality Assurance (Dynamic Analysis) | ||
Übung | Testing (Unit-Testing, System Testing) | ||
Mi, 13.01.21 | Quality Assurance (Dynamic Analysis) | ||
Mo, 18.01.21 | Process (from Sequential to Iterations) | ||
Übung | Agile Methods ("Paper Airplanes") | ||
Mi, 20.01.21 | Process and Teams (Agile) | ||
Mo, 25.01.21 | Team Dynamics + Team Motivation | Video: D. Pink. Drive: The surprising truth about what motivates us. RSA Talk 2010 | |
Übung | Team Dysfunctions | ||
Mi, 27.01.21 | SE for Machine Learning | HA3 (Design und Microservices) | |
Mo, 01.02.21 | Software Economics and Business Models | Richard Stallman's TEDx Geneva 2014 talk | |
Übung | Open Source Licenses | ||
Mi, 03.02.21 | Data-driven Decision Making | HA3 (Deployment Modifications) | |
Mo, 08.02.21 | SE Ethics | Sourour. The code I’m still ashamed of. Blog post, 2016 | |
Übung | - | ||
Fr, 12.02.21 | Q&A Session | ||
Sa, 13.02.21 | Abschlussklausur (Karnevalssamstag(!!!), vorläufiger Termin) |
Richtlinien
Wir werden Zoom für Vorlesungen und Übungen. Die Vorlesung hat einen ILIAS Kurs für die Folien, die Einreichung von Hausaufgaben, die Benotung, Diskussion, Fragen, Ankündigungen, Vorlesungsaufzeichnungen und ergänzende Dokumente; GitHub wird zur Koordinierung der Gruppenarbeit verwendet. Wir werden Slack für Kommunikation und Gruppenarbeit verwenden. Siehe ILIAS für den Link zur Anmeldung.
Warteliste: Die Vorlesung ist nicht größenbeschränkt.
Vorraussetzungen: Keine formalen Voraussetzungen, aber Sie werden mehr aus dem Kurs herausholen, wenn Sie Erfahrung mit einigen größeren Entwicklungsprojekten haben (z.B. Praktika oder Open-Source-Beiträge). Wir empfehlen außerdem, dass Sie den Programmierkurs, Info I und II, sowie ggf. auch schon das Programmierpraktikum absolviert haben.
Teamarbeit: Teamarbeit ist ein wesentlicher Bestandteil dieses Kurses. Die meisten Aufgaben werden in Teams von 4-6 Studierenden erledigt. Die Teams werden von uns zugewiesen und bleiben für mehrere Aufgaben zusammen. Bei der Zuweisung von Teams werden wir Ihre Verfügbarkeit sowie Background berücksichtigen. Anleitungen zu Teamarbeit, Reflexion und Konfliktlösung werden während des gesamten Semesters gegeben und sind ein wesentlicher Bestandteil des Kurses. Die meisten Aufgaben haben eine Komponente, die in der Gruppe bearbitet wird, und eine Komponente, die individuell bearbeitet wird. Die auf ILIAS veröffentlichte Teamrichtlinie gilt und beschreibt Rollen und Teams und den Umgang mit Konflikten und Ungleichgewichten.
Lehrbuch: Wir haben kein einzelnes Lehrbuch, sondern stellen Vorlesungen aus verschiedenen Quellen zusammen.
Als optionale Ergänzungslektüre betrachten Sie Ian Sommerville, Software Engineering und Ian Sommerville, Engineering Software Products: An Introduction to Modern Software Engineering.
Benotung: Die Benotung erfolgt auf der Grundlage der folgenden Verteilung 50% Hausaufgaben, 50% schriftliche Abschlussprüfung, 5% Reading-Quizzes (Bonus).
Zeitmanagement: Es handelt sich um einen Kurs mit 9 ECTS Punkten. Daher erwarten wir, dass Sie wöchentlich im Schnitt bis zu 12 Stunden für den Kurs aufwenden (9 ECTS* 30 Stunden / 22,5 Wochen). In der Regel werden 6 Stunden pro Woche für Vorlesungen und Übung und 6 Stunden für Lesen und Hausaufgaben aufgewendet. Bitte beachten Sie, dass die meisten Hausaufgaben in Gruppen gemacht werden, also berücksichtigen Sie bitte den Aufwand und die geringere zeitliche Flexibilität, die mit der Gruppenarbeit einhergehen. Bitte zögern Sie nicht, uns Rückmeldung darüber zu geben, wie viel Zeit der Kurs für Sie in Anspruch nimmt.
Verspätete Abgaben: Da bei diesem Kurs stark auf Teamarbeit gesetzt wird, werden Verspätung nicht tolleriert und gelten als "nicht abgegeben". Ausnahmen von dieser Regel werden nur in Ausnahmefällen gemacht, fast immer in Verbindung mit einem familiären oder medizinischen Notfall. Bitte sprechen Sie auch mit Ihrem Team über Zeitfragen.
Professionalität: Ihre Kommiliton*innen sind Ihre Kolleg*innen. Dies gilt insbesondere für diesen Kurs, in dem wir Ihnen Prinzipien, Praktiken, Werkzeuge und Paradigmen vermitteln wollen, die Sie in die Lage versetzen, ein effektiver, praxisnaher Software-Ingenieur zu sein. Wir bitten Sie, einander wie Arbeitskolleg*innen zu behandeln, wie Sie selber eine*r sind oder werden möchten.
Wenn Sie das Gefühl haben, dass jemand gegen diese Prinzipien verstößt (z.B. mit einem Witz, der als sexistisch, rassistisch oder ausgrenzend interpretiert werden könnte), und Sie glauben, dass Sie das Recht dazu haben, dann sprechen Sie sich aus! Seien Sie kein Zuschauer von unprofessionellem Verhalten.
Wenn Sie sich dabei nicht wohl fühlen und/oder wenn das Verhalten andauert, senden Sie eine E-Mail an den Kursleiter, um die Angelegenheit zu besprechen. Wir werden Ihre Anonymität wahren.
Akademische Ehrlichkeit und Zusammenarbeit: Viele der Aufgaben werden in Gruppen erledigt. Wir erwarten, dass die Gruppenmitglieder miteinander zusammenarbeiten, aber dass die Gruppen unabhängig voneinander arbeiten und keine Ergebnisse mit anderen Gruppen austauschen. Innerhalb der Gruppen erwarten wir, dass Sie ehrlich über Ihren Beitrag zur Arbeit der Gruppe sind. Das bedeutet, dass Sie sich nicht mit fremden Federn schmücken und Teammitglieder, die keinen Beitrag zum Team geleistet haben, aktiv darauf ansprechen. Ansonsten sind unsere Erwartungen in Bezug auf akademische Ehrlichkeit und Zusammenarbeit bei der Gruppenarbeit die gleichen wie bei der Arbeit von Einzelpersonen und ersetzen diese durch die Ebene der "Gruppe".
Der Kurs umfasst sowohl Einzelarbeiten als auch einzelne Komponenten von Gruppenarbeiten. Obwohl Ihre Lösungen für einzelne Teile auf dem für den Gruppenteil erstellten Inhalt basieren (z.B. schriftliche Reflexionen über die gelernten Lektionen), behandeln wir einzelne Komponenten von Gruppenaufgaben als gleichwertig zu Einzelaufgaben insgesamt und erwarten, dass Sie solche Komponenten unabhängig von Ihren Gruppenkameraden bearbeiten.