SWTPRA VL1 Motivation-Aufgabenstellung · PDF fileSoftware(technik)praktikum: Vorlesung 1 Eric...

1

Software(technik)praktikum: Vorlesung 1

Eric Bodden Christopher Gerking, Johannes Geismann, Philipp Schubert

Software(technik)praktikum SS 2016


Betreuung des Softwaretechnik- und Software-Praktikums 2015

■ Leitung ■ Prof. Dr. Eric Bodden

■ Organisation ■ Christopher Gerking, Johannes Geismann, Philipp Schubert ■ E-Mail: [email protected]

■ Tutoren ■ Paul Börding, Julian Heinovski, Roman Kober, Ralph Menne, Jan-Hendrik Schwarz

■ Programmierberatung ■ Mario Treiber

3Software(technik)praktikum: Vorlesung 1

Die Aufgabenstellung und Organisatorisches werden zum Ende der heutigen Vorlesung bekanntgegeben.

mailto:[email protected]?subject=


1. Eigenschaften von Software

2. Herausforderungen der Softwareentwicklung

3. Ziele des Praktikums

Einführung


Programm vs. Software

Software >> Programm

5

Ist sehr viel mehr als

Ist sehr sehr viel mehr als

Softwareentwicklung >>> Programmierung


Analogie bzgl. Programm vs. Software

6

ProgrammProgrammiererProgrammieren

Software SoftwareentwicklerSoftwareentwicklungWenn jemand nur Hütten bauen

kann, würden wir ihn keinen Wolkenkratzer bauen lassen. Wenn jemand dagegen programmieren kann, lassen wir ihn oft bedenkenlos Software entwickeln.


Softwareentwicklung ist …

■ … deutlich mehr als Programmierung

■ … analytische und konzeptuelle Arbeit

■ … ein sozialer Prozess

■ … eine Disziplin mit bewährten Konzepten, Methoden, Notationen und Werkzeugen

■ … und immer wieder neuen Technologien

7


Software ist komplex!

■ Software kann heute nicht mehr von einer einzelnen Person „programmiert“ werden

■ Software kann nicht mehr nur von einer einzelnen Person in ihrer Gesamtheit verstanden werden!

■ In vielen Projekten und Produkten ist die Entwicklung der Software ein maßgeblicher Kostenfaktor ■ Entwicklungsaufwände von 10 oder 100 Personenjahren (PJ) sind keine Seltenheit.

8


Software ist komplex!■ Softwaresysteme müssen mehr und mehr Aufgaben erfüllen

■ aufgrund von Kundenwünschen bzw. Marktanforderungen ■ Software ist heute oft maßgeblicher Innovationstreiber

■ Software-Systeme sind miteinander vernetzt ■ Plattform-Interoperabilität (z.B. Smartphone & PC) notwendig

■ Softwaresysteme bestehen typischerweise aus einer Vielzahl von Komponenten ■ Komponenten sind oft verteilt ■ Kommunizieren über komplexe Protokolle

9 8Software(technik)praktikum: Vorlesung 1


Software ist komplex!■ Softwareprojekte sind heute meist interdisziplinär

■ Eingebettete Systeme / Mechatronik ■ Betriebliche Informationssysteme (Bank, Produktion, Logistik)

■ Software muss oft sicherheitskritische Aufgaben erfüllen ■ in Transportsystemen ■ in medizinischen Geräten ■ im Finanzbereich

■ Ausführliche Analysen werden wichtiger & zugleich aufwändiger ■ Manuelles Testen ■ Automatisches Testen (JUnit) ■ Automatische Schwachstellenanalysen ■ Automatisches Beweisen (Model Checking)



Charakteristika der Softwareentwicklung

■ Software unterliegt häufigen Änderungen

■ Re-Engineering notwendig

■ Software unterliegt hohen Qualitätsmaßstäben (Angriffssicherheit, Korrektheit, Robustheit, Wartbarkeit, Interoperabilität, ...)

■ Softwareproduktion ist ein industrieller Prozess

■ Kosten/Nutzen-Abschätzung sehr wichtig

■ Eingesetzte Techniken

■ Objektorientierter Entwurf

■ Qualitätssicherung durch

■ Standardisierten Prozess und zugehörige Dokumente

■ Versions-/Konfigurationsverwaltung (z.B. Git)

■ Änderungskontrolle (z.B. Trac)

■ (Code-) Reviews

■ Kosten-/Nutzen Analyse durch systematische Aufwandserfassung

11


Software ist nie fertig

Problem • Software lebt lange (Jahr-2000-Problem, Banksoftware > 40 Jahre)

und muss permanent gewartet werden bei stets hoher Qualität • Wissen über die ausgelieferte Software (& deren Technologien)

sinkt

Idee • Softwareprodukt: guter Programmcode + explizites Wissen • Entwicklungsprozesse sorgen für die systematische Persistenz

Konsequenz • Wartbarkeit bereits bei der Entwicklung beachten

• Ausführliche Dokumentation (nachverfolgbare Anforderungen, Systemkontext, Entwurfsentscheidungen, Architektur)

• Sauberer Code und Code-Kommentare • Testfälle

12


Software erfordert Erfahrung

■ Softwareentwicklung erfordert viel Erfahrung!

■ Diese Erfahrung ■ ... muss man selbst machen! ■ ... wird im Software(technik)praktikum vermittelt!

■ Unser Praktikum ist eine Kombination aus: ■ Projektorientiertem Lernen ■ Unterstützt durch Vorlesung(en)

13


Analogie bzgl. Erfahrung sammeln

14

Die Erfahrung eines großen, komplexen und verteilten Projektes kann nicht durch viele kleine Projekte erreicht werden.

SoPraGP1-, GP2-Aufgaben SWTPra


Erfahrung anderer nutzen

■ Prozess- bzw. Vorgehensmodelle ■ sind die „zusammengeronnenen“

Erfahrungen erfolgreicher Softwareprojekte

■ Beispiel: V-Modell ■ Beschreiben zweckmäßiges Vorgehen

& passende Dokumente ■ Ermöglichen Wiederholbarkeit und

Kontrollierbarkeit ■ Wann ist ■ was ■ wie zu tun?


Bekannt aus der Vorlesung

Softwareentwurf


Fähigkeiten von Softwareentwicklern

■ Heutige Entwickler müssen sehr gut ausgebildet sein und viele Fähigkeiten besitzen

■ Wir unterscheiden in

■ Hard-Skills

■ Fachkompetenzen

■ Benötigt um selbstständig und eigenverantwortlich zu arbeiten

■ Soft-Skills

■ Soziale Kompetenzen

■ Wichtig zur Interaktion mit dem Team und dem Kunden

16


Notwendige Hard-Skills

Programmieren Abstrahieren & Modellieren

Konzepte erarbeiten & anwenden, Alternativen bewerten

Lösungen dokumentieren und

Notationen einsetzen

Technologien kennen und schnell in

neue Technologie einarbeiten

Kosten und Aufwände

abschätzen

17

Hard-Skills haben Sie zum Teil bereits in GP1, GP2, GPS, DuA und SE erlernt. Im Praktikum werden Sie diese vertiefen.


Notwendige Soft-Skills zur Interaktion mit Kollegen & Kunden

Zuhören und Probleme verstehen

Probleme/Lösungen kommunizieren

(auch in Form von Dokumenten)

Argumentieren und Kompromisse finden

Eigeninitiative ergreifen &

Verantwortung übernehmen

Eigene Stärken kennen, einsetzen

und reflektieren

Stärken von anderen erkennen und nutzen

18

Soft-Skills wollen wir im Praktikum trainieren.


Softwareentwicklung ist Teamarbeit

Problem • Software kann nicht von Personen entwickelt werden, die

Experte für alles sind • Einzelne Personen können die Gesamtheit der Software nicht

mehr verstehen

Idee • Aufgabenaufteilung auf mehrere Personen (Rollen) • Jede Person muss nur Experte für ihre Aufgabe sein

Vorteil • Komplexität wird handhabbar & Produkt ist schneller entwickelt

Herausforderung • Missverständnisse, Soft-Skills, Unvollständiges Wissen, ...

Konsequenz • Software-Management (Zeit und Qualität) und

Entwicklungsprozesse einführen

19


Einige beteiligte Rollen

20

Projektmanager verfolgt und leitet Projektverlauf

Domänen-analyst

nimmt Kunden-anforderungen auf und verfolgt deren Ein-haltung

Software-architekt

konzipiert das Gesamt-system

Software-entwickler

programmiert einzelne Komponenten der Software

Tester

erstellt Testfälle und führt diese aus

Plattform-experte

konfiguriert die Software für die jeweilige Plattform

Kunde stellt (sich wechselnde ☺) Anforderungen und nimmt das fertige Produkt ab


Kommunikation zwischen den Rollen ist wichtig

21


Mögliche Rollenverteilung im V-Modell

22

Domänenanalyst

Softwarearchitekt

Softwareentwickler

Tester

Plattformexperte

Domänenanalyst

Im Praktikum sollen Sie möglichst viele Rollen trainieren.


Fazit: Ziele des SWTPra / SoPra■ Hard- und Soft-Skills in der Softwareentwicklung lernen und

verbessern

■ Entwicklung eines Softwaresystems im Team ■ Anwendung des Gelernten aus GP1, GP2, GPS, SE und DuA ■ Ausführung eines Softwareentwicklungsprozesses von der

Anforderungsdefinition bis zur Realisierung ■ Projektmanagement ■ Sammeln von Programmiererfahrung ■ Erstellen von sinnvollen Modellen und Dokumenten ■ Einsatz von Technologien und Werkzeugen ■ Qualitätssicherung

23


Organisatorisches & Aufgabenstellung


Aufgabenstellung

■ Entwicklung eines verteilten Quarto-Brettspiels

25


Aufgabenstellung

■ Entwicklung eines verteilten Quarto-Brettspiels

26

■ „Erweiteres“ Quarto-Spiel ■ mehr Spielsteine ■ komplexeres Spielfeld

■ Verteilte Anwendung ■ Client-Server Architektur

■ Konfigurationsmöglichkeiten ■ Spielfeld ■ Anzahl / Aussehen der Steine


Aufgabenstellung

Zur Erstellung der Spielkonfigurationen

• Mensch spielt via Smartphone

• Künstliche Intelligenz spielt vollautomatisch

Spielverlauf lässt sich via PC & Smartphone beobachten

• Leitet das Spiel • Verwaltet Clients • Überwacht Ein-haltung der Regeln

2707.04.2015

Aufgabenstellung

Komitee bestimmt die Interfaces

2807.04.2015



Vorgaben bzgl. Technologien und Entwicklungswerkzeuge

29


Entwicklungsprozess & Rollen

■ Das System wird nach dem V-Modell entwickelt ■ Das Orga-Team ist der Kunde ■ Sie übernehmen alle weiteren Rollen

30


Artefakte und Ereignisse während des Praktikums

31

Messe

TurnierAbschlusspräsentation

Angebot

Pflichtenheft

Lastenheft

Analyse- & Entwurfsdokument inkl. Interfacedefinition

ImplementierungsabgabeAbschlussdokumentation

Erhalten Sie diese Woche.


Interface-Komitee

■ Ziel ■ Definition der Interfaces zwischen

■ Spielkonfigurator & Spiel-Engine ■ Server & Clients

■ Teilnehmer ■ je Team ein Mitglied

■ Mehrheitsentscheidung ■ Vorsitzender (leitet Komitee, von Beauftragten gewählt)

■ Berater des Komitees: Programmierberater ■ Versionen

■ 1.0: erste vorläufig finale Fassung für Analyse- & Entwurfsdokumente ■ 2.0: für Änderungen während der Implementierungsphase

■ Endabgabe und Turnier halten sich an Version 2.0

32

Ereignis: Messe

■ SWTPra- und SoPra-Gruppen tauschen kostenlos Komponenten ■ SWTPra-Gruppen geben ihren Spielkonfigurator und den PC-Beobachter ab ■ SoPra-Gruppen geben ihren Smartphone-Beobachter ab

33 Software(technik)praktikum: Vorlesung 1

Ereignis: Turnier

■ KI-Spieler der Teams treten gegeneinander an ■ Dazu kommen auch Spiel-Engine und Beobachter zum Einsatz

34 Software(technik)praktikum: Vorlesung 1


Wöchentliche Meetings

■ Jedes Team hat ein wöchentliches, zweistündiges Meeting ■ Es besteht Anwesenheitspflicht ■ Anfangszeitpunkte PAUL entnehmen

35

Mo Di Mi Do Fr

9:00 -11:00SWTPra 1

N3.211 Roman

SoPra 1 N5.235

Jan-Hendrik

11:00-13:00SWTPra 8

N3.211 Roman

14:00-16:00SWTPra 5

D1.312 Roman

16:00-18:00SWTPra 2

O1.252 Paul

SoPra 4 O1.258

Jan-Hendrik

SWTPra 3 O1.252 Julian

SWTPra 7 N2.228 Roman

SWTPra 4 NW1.701

Paul

SoPra 3 N1.101 Ralph

SWTPra 6 H3.223 Julian

18:00-20:00SoPra 2 E0.143 Ralph


Aufgabe der Tutoren

■ Jedes Team hat einen Tutor, der bei den wöchentlichen Meetings dabei ist und per Mail erreichbar ist

■ Nicht die Aufgabe des Tutors ■ die Arbeit machen (das macht das Team) ■ die Gruppe leiten, das Meeting vorbereiten & moderieren (das macht der

Projektleiter) ■ der Kunde sein (das ist das Orga-Team) ■ Technikprobleme lösen (hierfür berät Sie der Programmierberater)

■ Aufgabe des Tutors ■ ein Berater und Coach sein (Consultant) ■ Fragen klären ■ ggf. auf Probleme hinweisen & Zwischenreviews durchführen

36


Entwicklerrollen der Teams

Projektmanager Koordiniert Aufgabenverteilung, Projektplan, Agenda (bei 12er Teams: 2 Rollen)

Domänenanalyst & Architekturmanager

Koordiniert Pflichtenheft sowie Analyse und Entwurf (bei 11er/12er Teams: 2 Rollen)

Modellierungsexperte Experte für Metamodellierung, EMF, OCL, Entwurfsmuster, Architekturmuster

Technologieexperte Experte für Eclipse PDE, GEF/Graphiti, Android, JSON

Implementierungsmanager Koordiniert Teilproduktimplementierung & Integration zum Gesamtprodukt

Qualitätsmanager Koordiniert Dokument- & Code-Reviews, betreut Bugtracker

Testmanager Koordiniert Erstellung und Ausführung manueller und automatischer Tests

Produktmanager Koordiniert Abschlusspräsentation, Webseite, Messe

Werkzeugbeauftragter Experte im Umgang mit Eclipse, Latex, Git, Trac

Dokumentationsmanager Koordiniert Endabgabe, Javadoc, Handbuch

37


Programmierberater und bereitgestellte Technik

■ Neben den Tutoren gibt es einen Programmierberater ■ Dieses Jahr: Mario Treiber ■ Berät Sie bei Programmierproblemen ■ Wöchentliche Sprechstunde auf Anfrage ■ Sonst nur über das Kommunikations-Forum Koala erreichbar ■ Bitte immer konkrete Fragen stellen ■ Bei Problemen bitte immer den problematischen Code und ggf. Fehlermeldungen

und Stacktraces angeben

■ Jedes Team bekommt folgende Technik bereitgestellt ■ eigenes Versionsverwaltungssystem (Git)

■ inkl. Bug- & Feature-Tracker und Wiki ■ eigenen Mailverteiler


Nr. Task Name Anfang Ende Dauer

1 Software(technik)praktikum Mon 11.04.16 Fre 29.07.16 80 Tage2 Beginn der Vorlesungszeit Mon 11.04.16 Mon 11.04.16 1 Tag3 Vorlesung (4 Termine) Mon 11.04.16 Don 14.04.16 4 Tage4 Kick-Off der Teams Mon 18.04.16 Fre 22.04.16 5 Tage5 Abgabe Angebot Fre 29.04.16 Fre 29.04.16 1 Tag6 Abgabe Pflichtenheft Mon 16.05.16 Mon 16.05.16 1 Tag7 Abgabe Interfaces Mon 23.05.16 Mon 23.05.16 1 Tag8 Abgabe Analyse- & Entwurfsdokument Mit 01.06.16 Mit 01.06.16 1 Tag9 Abgabe Implementierung (Messeversion) Mit 15.06.16 Fre 17.06.16 3 Tage10 Messe Mon 20.06.16 Mon 20.06.16 1 Tag11 Abgabe Implementierung (Turnierversion) Fre 15.07.16 Fre 15.07.16 1 Tag12 Endabgabe Mon 18.07.16 Mon 18.07.16 1 Tag13 Abschlusspräsentationen Mon 18.07.16 Fre 22.07.16 5 Tage14 Ende der Vorlesungszeit Fre 22.07.1615 Turnier Mon 25.07.16 Mon 25.07.16 1 Tag16 Klausur Fre 29.07.16 Fre 29.07.16 1 Tag

11.04

29.0416.05

23.0501.06

17.0620.06

15.0718.07

25.0729.07

11 18 25 02 09 16 23 30 06 13 20 27 04 11 18 25Apr '16 Mai '16 Jun '16 Jul '16

Abgabeplan SWTPra/SoPra 2015

■ Abgabeplan definiert harte Deadlines


Abgabeplan

39

Deadlines / Meilensteine


Anmeldung

■ Alle Teilnehmer mussten sich in PAUL zur Veranstaltung anmelden ■ Prüfungsanmeldung erfolgt in PAUL bzw. im jeweiligen Prüfungssekretariat

■ Gruppeneinteilung erfolgte ebenfalls über PAUL ■ Ort der Meetings ist in PAUL einzusehen ■ Ziel: Gleichmäßig große Gruppen

■ Voraussetzung für die Teilnahme ■ Modul l.1.1 bzw. E1721: Programmiertechnik

■ Grundlagen der Programmierung 1 und 2 (GP1 und GP2) ■ Modul l.1.2 bzw. E1722: Softwaretechnik

■ Softwareentwurf (SE)



Gruppeneinteilung Aktueller Stand

■ SWTPra ■ 78 Teilnehmer

■ SoPra ■ 45 Teilnehmer

41

Gruppe Termin Teilnehmer

SWTPra 1 Mo, 9-11 8

SWTPra 2 Mo, 16-18 10

SWTPra 3 Mi, 16-18 10

SWTPra 4 Do, 16-18 10

SWTPra 5 Fr, 14-16 8

SWTPra 6 Do, 16-18 9

SWTPra 7 Mi, 16-18 10

SWTPra 8 Mo, 11-13 9

SWTPra 9 —- 4

SoPra 1 Mo, 9-11 11

SoPra 2 Di, 18-20 10

SoPra 3 Do, 16-18 11

SoPra 4 Mo, 16-18 11

SoPra 5 —- 2


Bestehen der Veranstaltung

■ Der Veranstalter kann Zwischenprüfungen mit einzelnen Studenten durchzuführen, falls Zweifel an der erfolgreichen Teilnahme an der Veranstaltung bestehen.

■ Voraussetzung für das Bestehen ■ Aktive Teilnahme an der Projektarbeit ■ Anwesenheitspflicht bei den Gruppenmeetings eingehalten ■ Einhaltung der Abgabetermine ■ Klausur bestanden

■ Termin TBA ■ Ggf. bestandene Zwischenprüfung

à Die Veranstaltung ist die Prüfung

42

Softwaretechnik

Häufig gestellte Fragen & häufig gegebene Antworten

43

■ Das Praktikum unterscheidet sich von den „üblichen“ Lehrveranstaltungen die sie bereits kennen.

■ Es erfordert daher eine andere Herangehensweise und Mentalität.

■ Legen Sie neue Maßstäbe an!

Softwaretechnik

Häufig gestellte Fragen & häufig gegebene Antworten (1)

44

Das V-Modell ist nicht mehr zeitgemäß, da es bei Google nicht zur Anwendung kommt.

Google verfolgt ein grundverschiedenes Geschäftsmodell.

Das V-Modell ist industrieller Standard für die Entwicklung sicherheitskritischer Softwaresysteme.

Softwaretechnik


45

Können wir nicht einfach Dropbox benutzen?

Der Umgang mit einem Versionsverwaltungssystem ist industrieller Alltag und daher Lehrinhalt des Praktikums.

Softwaretechnik


46

Warum gibt es Seitenlimits?

Viel zu schreiben ist doch gut.

Seitenlimits gehören zum Tagesgeschäft (z.B. bei der Einreichung wissenschaftlicher Veröffentlichungen).

Sich knapp und präzise auszudrücken ist eine Kunst die es zu lernen gilt.

Softwaretechnik47

Manuell zu programmieren ist doch viel einfacher als Framework X zu benutzen.

Das Praktikum ist auch eine Lehrveranstaltung.

Es heißt Softwaretechnikpraktikum und nicht Programmierpraktikum.

Softwaretechnik bedeutet ingenieurmäßiges Vorgehen bei der Softwareentwicklung.


Softwaretechnik


48

Wir müssen unbedingt die neuartige Technologie X benutzen, denn die hat viele Vorteile.

Wissen wir in der Regel ☺ Für das Praktikum nutzen wir marktübliche Technologien.

Kundenwünsche schließen oft eine Abwärtskompatibilität ein. Mit gegebenen Mitteln zurecht zukommen ist industrieller Alltag.

Softwaretechnik


49

Der Programmierberater ist unfähig, denn er konnte unser Problem nicht lösen.

Nein.

Der Programmierberater zeigt nur Lösungsmöglichkeiten auf.

Lösungsmöglichkeiten müssen selbstständig exploriert werden, ohne Garantie auf Erfolg.

Softwaretechnik


50

Der Programmierberater ist unfair, denn er gibt die Musterlösung nicht heraus.

Nein.

Wir führen ein Projekt durch.

Es gibt in der Regel keine Musterlösung!

Softwaretechnik


51

In der Abschlusspräsentation zeigen wir unser wahres Gesicht und geben der Orga zurück was sie uns angetan hat!

Keine gute Idee.

Die Präsentation dient als Projektabschluss und wird entsprechend bewertet.

Softwaretechnik


52

In der Abschlusspräsentation weisen wir uns gegenseitig die Schuld zu.

Keine gute Idee.

Selbstreflexion ist nur ein Bestandteil der Präsentation!

Softwaretechnik


53

Der Zeitaufwand ist viel höher als bei Vorlesung X.

Ja. Siehe ECTS.

Der tatsächliche Aufwand ist stark abhängig von der Selbstorganisation innerhalb der Gruppe.

Webseite

54

https://www.hni.uni-paderborn.de/swt/lehre/softwaretechnik-softwarepraktikum-ss-2016/

• Fragen und Diskussionen im Koala

• Regelmäßig besuchen • Regelmäßig E-Mails lesen



IMT-Einstellungen

55

Muss aktiviert sein, um Zugang zu den Repositories und Mailverteilern zu erhalten

https://benutzerverwaltung.uni-paderborn.de/

GitLab

56

https://git.cs.uni-paderborn.de/

Erstmaliger Login aktiviert Dienstnutzung


Viel Spaß beim diesjährigen Software(technik)-Praktikum! ☺

… und bis morgen um 9 Uhr!

58

Date post:	06-Feb-2018
Category:	Documents
Upload:	dodat
View:	220 times
Download:	2 times

SWTPRA VL1 Motivation-Aufgabenstellung · PDF fileSoftware(technik)praktikum: Vorlesung 1 Eric...

Documents