Vorlesung Software-Engineering I



Ähnliche Dokumente
Vorlesung Software-Engineering I

Vorlesung Software-Engineering I

Projektmanagement. Dokument V 1.1. Oliver Lietz - Projektmanagement. Wie kommt es zu einem Projektauftrag? Ausführung

Das Pflichtenheft. Dipl.- Ing. Dipl.-Informatiker Dieter Klapproth Ains A-Systemhaus GmbH Berlin

Unsere Kunden erzählen keine Geschichten. Ursula Meseberg microtool GmbH Berlin

Grundlagen Software Engineering

GEVITAS Farben-Reaktionstest

Vorlesung Software-Engineering I

Übungsaufgaben zum Software Engineering: Management

Informationssystemanalyse Problemstellung 2 1. Trotz aller Methoden, Techniken usw. zeigen Untersuchungen sehr negative Ergebnisse:

Scrum ist ein agiles Framework zur Software-Entwicklung. SCRUM bei Festo. Was ist SCRUM? Frank M. Hoyer, House of Software

Eberhard Lehmann: Projekte im Informatik-Unterricht Software Engineering, Ferd. Dümmlers Verlag, Bonn Inhaltsverzeichnis.

Softwareentwicklungsprozess im Praktikum. 23. April 2015

Agile Vorgehensmodelle in der Softwareentwicklung: Scrum

ÜBUNG. Einführung in das IT- Projektmanagement WS 2012/13. Dr. The Anh Vuong

Gelebtes Scrum. Weg vom Management hin zur Führung

AGROPLUS Buchhaltung. Daten-Server und Sicherheitskopie. Version vom b

Produktionsplanung und steuerung (SS 2011)

Primzahlen und RSA-Verschlüsselung

Praktikum Grundlagen der Programmierung. Diverse Grundlagen. Dr. Karsten Tolle

Informationswirtschaft II Rational Unified Process (RUP)

1. Einführung. 2. Alternativen zu eigenen Auswertungen. 3. Erstellen eigener Tabellen-Auswertungen

Informationswirtschaft II

Projektmanagement in der Spieleentwicklung

Historical Viewer. zu ETC5000 Benutzerhandbuch 312/15

Was macht Layer2 eigentlich? Erfahren Sie hier ein wenig mehr über uns.

«PERFEKTION IST NICHT DANN ERREICHT, WENN ES NICHTS MEHR HINZUZUFÜGEN GIBT, SONDERN DANN, WENN MAN NICHTS MEHR WEGLASSEN KANN.»

Wahlpflichtfach Software Engineering

Software Engineering

Scrum. Übung 3. Grundlagen des Software Engineerings. Asim Abdulkhaleq 20 November 2014

Auktionen erstellen und verwalten mit dem GV Büro System und der Justiz Auktion

Agile Softwareentwicklung in der Versicherungs-IT Fehlschlag oder Heilsbringer?

Projektsteuerung Projekte effizient steuern. Welche Steuerungsinstrumente werden eingesetzt?

IT-Projekt-Management

Prozess-Modelle für die Softwareentwicklung

Das Wasserfallmodell - Überblick

Dr. Hanno Schauer Mons-Tabor-Gymnasium Montabaur. UML-Klassendiagramme als Werkzeug im Unterricht

Willkommen zu unserer Präsentation. Meilensteine. Frescher Eugen Mayankin Yuriy

TTS - TinyTimeSystem. Unterrichtsprojekt BIBI

Christian Kühnel, BMW Group AGILE ENTWICKLUNG VON FAHRERASSISTENZSOFTWARE. AGILE CARS 2014.

Softwareentwicklungspraktikum Sommersemester Grobentwurf

SWE12 Übungen Software-Engineering

Installation OMNIKEY 3121 USB

OEM Von der Idee zum Serienprodukt

Vorlesung Software-Engineering I

Wir erledigen alles sofort. Warum Qualität, Risikomanagement, Gebrauchstauglichkeit und Dokumentation nach jeder Iteration fertig sind.

Wirtschaftsinformatik I Teil 2. Sommersemester Übung

IT-Basics 2. DI Gerhard Fließ. Vorgehensmodelle

Die Entwicklung eines Glossars (oder eines kontrollierten Vokabulars) für ein Unternehmen geht üblicherweise in 3 Schritten vor sich:

Angepasste Software Standards für DLR- Eigenentwicklungen - Die DLR Software Basisstandards -

07. November, Zürich-Oerlikon

Meetings in SCRUM. Leitfaden. Stand:

Wege zur Patientensicherheit - Fragebogen zum Lernzielkatalog für Kompetenzen in der Patientensicherheit

Software Engineering. Sommersemester 2012, Dr. Andreas Metzger

Arbeiten mit UMLed und Delphi

INDIVIDUELLE SOFTWARELÖSUNGEN CUSTOMSOFT CS GMBH

Warum sich das Management nicht für agile Softwareentwicklung interessieren sollte - aber für Agilität

MASTER-BERATUNG. im Fach Kunstgeschichte

Bedienungsanleitung - Webtool

zur Sage New Classic 2015

2. Workshop: Vorgehensmodelle in der Praxis Reife und Qualität

Erstellung von Reports mit Anwender-Dokumentation und System-Dokumentation in der ArtemiS SUITE (ab Version 5.0)

Erfahrungen mit Hartz IV- Empfängern

17 Architekturentwurf Vorgehen und Dokumentation

Softwareentwicklung aus Sicht des Gehirns

Softwareentwicklung bei KMU - Ergebnisse einer Studie zum Entwicklungs-, Projekt- und Qualitätsmanagement

Kapitel 2: Der Software-Entwicklungsprozess

Unsere These: Meilensteindefinitionen sind wichtig für die Projektplanung und die Bewertung des Projektstatus.

Informationssystemanalyse Lebenszyklusmodelle 3 1. Lebenszyklusmodelle sollen hauptsächlich drei Aufgaben erfüllen:

1. Adressen für den Serienversand (Briefe Katalogdruck Werbung/Anfrage ) auswählen. Die Auswahl kann gespeichert werden.

Projekt- Management. Landesverband der Mütterzentren NRW. oder warum Horst bei uns Helga heißt

Durch integriertes Produktmanagement den PM näher an den Markt bringen. Wir machen zukunftsfähig

Kapitel 4 Die Datenbank Kuchenbestellung Seite 1

Menü auf zwei Module verteilt (Joomla 3.4.0)

Ausgangslage, Rolle und Auftrag

Staatssekretär Dr. Günther Horzetzky

IINFO Storyboard

Zufriedene Gäste, Mundpropaganda und begeisterte Stammgäste sind der Schlüssel zum Erfolg Ihres Unternehmens!

IT-SICHERHEIT IM UNTERNEHMEN Mehr Sicherheit für Ihre Entscheidung

Content Management System mit INTREXX 2002.

TISIS - Industrie 4.0. Ereignis, Ort, Datum

-Fachgruppe Geschäftsprozesse. ech-bpm-workshop. 26. Februar von bis Uhr. Ein Gespräch mit

Informationen zur Erstellung des Projektantrags in den IT-Berufen und zum AbschlussPrüfungOnlineSystem (CIC-APrOS)

mit attraktiven visuellen Inhalten

Wir beraten Sie. Wir unterstützen Sie. Wir schaffen Lösungen. Wir bringen Qualität. Wir beraten Sie. Wir unterstützen Sie. Wir schaffen Lösungen

Agiles Design. Dr.-Ing. Uwe Doetzkies Gesellschaft für Informatik mail:

StuPro-Seminar Dokumentation in der Software-Wartung. StuPro-Seminar Probleme und Schwierigkeiten in der Software-Wartung.

ITIL und Entwicklungsmodelle: Die zwei Kulturen

SPC Lehrgang Projektmanagement Basic

Veröffentlichen von Apps, Arbeitsblättern und Storys. Qlik Sense Copyright QlikTech International AB. Alle Rechte vorbehalten.

Protect 7 Anti-Malware Service. Dokumentation

Agile Prozessverbesserung. Im Sprint zu besseren Prozessen

Sobotta Atlas der Anatomie des Menschen

[Customer Service by KCS.net] KEEPING CUSTOMERS SUCCESSFUL

Free your work. Free your work. Wir wollen Ihnen die Freiheit geben, sich auf Ihr Geschäft zu konzentrieren.

So gehts Schritt-für-Schritt-Anleitung

ONLINE-AKADEMIE. "Diplomierter NLP Anwender für Schule und Unterricht" Ziele

Buchhaltung mit WISO EÜR & Kasse 2011

users guide I. KENNENLERNEN 2. BRIEFING 3. REBRIEFING

Systemdenken und Gestaltungsmethodik Einführung und Grundlagen II

Transkript:

Vorlesung Software-Engineering I im 3. und 4. Semester 11. Retrospektive Was lief gut? Was können wir verbessern? http://wwwlehre.dhbw-stuttgart.de/~sto/public/modulplaene/t2inf2003.pdf sto/public/modulplaene/t2inf2003.pdf SW-Engineering I Qualifikationsziele und Kompetenzen Die Studierenden kennen die Grundlagen des Softwareerstellungsprozesses. Sie können eine vorgegebene Problemstellung analysieren und rechnergestützt Lösungen entwerfen, umsetzen und dokumentieren. Sie kennen die Methoden der jeweiligen Phasen und können sie anwenden. Sie können Lösungsvorschläge für ein gegebenes Problem konkurrierend bewerten und korrigierende Anpassungen vornehmen. Die Studierenden können sich mit Fachvertretern über Problemanalysen und Lösungsvorschläge, sowie über die Zusammenhänge der einzelnen Phasen austauschen. Sie können einfache Softwareprojekte autonom entwickeln oder bei komplexen Projekten effektiv in einem Team mitwirken. Sie können ihre Entwürfe und Lösungen präsentieren und begründen. In der Diskussion im Team können sie sich kritisch mit verschiedenen Sichtweisen auseinandersetzen und diese erläutern. Sie bewerten die eingesetzten Technologien und schätzen ihre Folgen ab. Die Studierenden können sich selbsständig in Werkzeuge einarbeiten. Sie verbinden den Softwareentwicklungsprozess mit Techniken des Projektmanagement und beachten während des Projekts Zeit- und Kostenfaktoren. 3

Vorlesungsrückblick Vorlesung: Gruppenarbeit: Tool: 01 Einführung Produktkarton PPT 02 Vorgehensmodelle ConceptMap yed 03 Anforderungserhebung ProductBacklog EXCEL 04 Systematischer ti Architekturentwurf t Modularisierung i yed, EXCEL Schätzverfahren 05 Basiskonzepte (Sichten) Lastenheft Word 06 Datensicht ERM, DataDictionary yed, EXCEL 07 Abläufe Abläufe yed (BPMN) 08 Benutzeroberfläche GUI-Entwurf Pencil, yed 09 Dokumentation Offene-Punkte-Liste EXCEL 10 Präsentation Dokumentation PPT, PDF 11 Rückblick Retrospektive EXCEL 4 01-Einführung: Phasenmodell der Software-Entwicklung Vorgehensmodell // Beschreibung der Abarbeitung der Phasen Idee Auftrag Abnahme Bugfixes Analyse Spezifikation Entwurf Implementierung Test Einführung Wartung Auslauf Lastenheft Pflichtenheft Umsetzungs- Test- Dokumentation Entwurf Plan Dokumentation 5

01-Einführung: Software-Engineering, warum? Definitionen: Software: immateriell, nicht greifbar schnell änderbar => komplex, aufwändig, teuer in der Erstellung Engineering: Ingenieurmäßiges Vorgehen praxisgerecht, bewährt => formalisiert, nachvollziehbar, zielgerichtet => (vollständig, berechenbar, vorhersagbar) Ziel: Erfolgreich bessere Software erstellen! Sehr gute Arbeit! Aber sollten wir hier vielleicht nicht noch ein wenig detaillierter werden? 6 01-Einführung: schädliches Multitasking Typischer Projektstatus: Typischer Projektverlauf : Ergebnis Plan: Prj.1 Prj.2 Prj.3 Kosten Zeit Ist: Prj.1 Prj.2 Prj.3 Prj.1 Prj.2 Prj.3 Prj.1 Prj.2 Prj.3 Termin überschritten, Ergebnis noch nicht erreicht, aber noch Geld (Kosten)übrig. Mehrere Projekte werden parallel bearbeitet. Folge: keines der Projekte wird zum geplanten Termin fertig. Wo wird diese Erkenntnis schon anerkannt? Agile Techniken -> Fokussierung Projekt-Management -> CCPM (Engpassmanagement) Gesunder Menschenverstand bzw. eigene Erfahrung 7

01-Einführung: Der Abgrund zwischen Anwender und Programmierer Fachabteilung IT-Abteilung Problemdomäne Lösungsdomäne? Ideen, Beschreibungen, Prozesse, Dokumente, Hierarchien, Personen, Zuständigkeiten, Lastenheften, Pflichtenheften, Dokumentation, Abläufe, Objektzusammenhänge, Statusübergänge, Datenbanken, Technologien, UML, Sourcecode, 8 01-Einführung: Domänen und ihre Sprachen oder: vom Problem zur Lösung Modell Problem Lösung Programm Die reale Welt mit der Domäne der Fachabteilung Das Modell der Domäne Domänenspezifische Sprache (DSL) Die Problembeschreibung Im Kontext der Domäne Lastenheft Der Lösungsentwurf zur Abdeckung des Problems Pflichtenheft Die Umsetzung des Lösungsentwurfs Sourcecode Problemdomäne Lösungsdomäne 9

02-Vorgehensmodelle: Liste ausgesuchter Vorgehensmodelle Versuch und Irrtum: Cowboy Coding Inkrementell: Wasserfallmodell V-Modell (XT) Inkrementell Iterativ Agile Iterativ: Spiralmodell Rational R l Unified Process (RUP) Agile SW-Entw. (Scrum/XP/Kanban) Besondere Ausprägungen: Prototyping Modellgetriebene SW-Entwicklung (MDD) Feature-Driven-Development (FDD) Test-Driven-Development (TDD) 10 4C s 03-Anforderungserhebung: Typen von Anforderungen 1. Funktionale Anforderungen Anwendungsfälle Benutzeroberfläche Reports, Daten 2. Nicht Funktionale Anforderungen Antwortzeiten Zuverlässigkeit Benutzbarkeit 3. Rahmenbedingungen g Kosten, Termin Infrastruktur Sonstige Vorgaben, Standards Lastenheft Achtung: Abhängigkeiten/Wechselwirkungen sind zwischen den Anforderungs-Typen möglich! Anwendungsfall Anforderung Anforderung Anforderung Rahmenbedingung Anforderung 11

02-Anforderungserhebung: Veränderung von Anforderungen im Projektverlauf Quelle: OOSE 12 03-Schätzverfahren: Dilbert: Aufwandsschätzung LinesOfCode FunctionPoints StoryPoints PersonenTage/Monate/Jahre Oracel, Poker, Wetter Ich mache einen Projektplan um die Ressourcen einzuteilen damit wir unsere Software ändern können. Also ich mache solche Änderungen in 10 Sekunden Fertig! Gute Arbeit! Aber ich wollte doch nur den Projektplan machen Wetter von Gestern 13

Ich steh da vor der weißen Tafel, wie fange ich an? 04-Systematischer Architekturentwurf: Zwiebelmodell wie weit gehe ich da? Theoretisch vom System bis zur Klasse möglich Gastdozenten : Gesamtsystem Markus Völter Michael Stal Sub-Systeme Komponenten Als Architekt gehe ich nur über drei Ebenen. (Nicht bis in unendliche Details abtauchen!) => Architektur vs. Design 14 05-Basiskonzepte: SW-Architektur - Sichten auf das Produkt Abläufe: Daten: Zustände: Entwurf Umsetzung Hierarchien: 06-Datensicht (ERM,DD): 07-Abläufe (BPMN): 08-GUI: Module/Strukturen: 15

09-Dokumentation: Idee -> Übersicht -> Anforderungen -> Software-Architektur Konzept-Map: -> Themengruppen, Zusammenhänge Anforderungsliste: -> Anwendungsfälle Anforderungen, Ideen Produktkarton: -> Zielgruppe, Leistungsmerkmale SW-Architektur: -> Umsetzungsentwurf Module, Daten, GUI, Abläufe, Funktionen 16 09-Dokumentation: Architektur-Review OPL offene Punkte -Liste Problem Lösungsvorschlag Wir treten einen Schritt zurück und betrachten nochmal das Ganze. Sind wir noch auf dem richtigen Weg? 17

09-Dokumentation: Architektur-Dokumentation Übersichtspräsentation (View) Generelles Vorgehen: von der Übersicht zur Detaillierung Dokumentation (Print) 18 and Aufwa Zeit Gruppenarbeit: Software-Engineering I - Gruppenarbeit Modul 1 Team 1: Projekt 1 Modul 2 Team 2: Modul 3 Team 3: Modul 1 Team 4: Projekt 2 Modul 2 Team 5: Modul 3 Team 6: Projekt 3 Modul 1 Team 7: Modul 2 Team 8: 19

11-Retrospektive: Vereinfachte Punktbewertung Die Bewertung erfolgt anhand den Phasendokumente wie Lasten-/Pflichtenheft, SW-Architektur unter Anwendung der entsprechenden Methoden und Darstellungen. 20 http://www.kreative-chaoten.com/metamenu/selbst-checks/chaot-oder-systematiker.html checks/chaot oder systematiker.html Denkstilanalyse: Kreativer Chaot oder Logischer Ordner 21

Vollständig Größtenteils Rudimentär nicht behandelt 10-Retrospektive: Lehrinhalte SW-Engineering I Vorgehensmodelle Phasen des SW-Engineering und deren Zusammenhänge Analyse: Lastenheft Spezifikation: Pflichtenheft, Geschäftsprozesse, SA, Methoden zur Repräsentation von Algorithmen, Datenmodellen, Funktionsweisen, Zustands- und Regelabhängigkeiten Entwurf: SW-Architekturen, Systementwurf, Schnittstellenentwurf, Klassendiagramme Implementierung und Test Codierrichtlinien und Codequalität, Testarten und Testdurchführung, Installation und Einführung Wartung und Pflege Phasenspezifische werden die verschiedenen Arten der Dokumentation behandelt. Labor Ein komplexes Problem wird als Projekt mit allen Phasen von den Studierenden erarbeitet und dokumentiert. 22 Vollständig Größtenteils Rudimentär nicht behandelt 10-Retrospektive: Kenntnisse und Fertigkeiten Software-Engineering I Struktur und Inhalt von Lasten- und Pflichtenheften kennen Verfahren zur Aufwandsschätzung kennen Basiskonzepte (Funktionen, Daten, Abläufe) kennen (Strukturierte Analyse (SA) anwenden) Use Cases erstellen UML Diagramme kennen Entity-Relationship (ER) Diagramme kennen Data Dictionary (DD) erstellen Kontrollstrukturen kennen Entscheidungstabellen kennen Zustandsautomaten kennen Testverfahren kennen (Grundlagen der Software-Ergonomie kennen) Grundlagen der Dokumentation kennen 23

11-Retrospektive: Inhaltsübersicht Software-Engineering I - Noten Die Vorlesung dauert 2 Semester (3. und 4. Semester) Es gibt nur eine Note über beide Semester (1 benotete Prüfungsleistung) g) 3. Semester: Test (30 Min.) 15% Vorgehensmodelle Projektarbeit 35 % Anforderungen und Software-Architektur 4. Semester: Test (30 Min.) 15% Basistechniken (UML) Projektarbeit 35% Umsetzungsentwurf, t Test-Management & TDD, Implementierung und Abnahme 24 11-Retrospektive: Was fehlt: von Anforderungen zu Aufgaben (Umsetzung) Anforderungen (Produkt-Backlog): Epics User Story s funktionale Anforderungen nicht funktionale Anforderungen Aufgaben (Sprint-Backlog): Aufgaben Entwürfe Umsetzungen Tests Dokumentation 1 Beispiel Schätzverfahren Planungspoker Anwendungsfall 1 Aufgabe 1 <Aufwand> Aufgabe 2 <Aufwand> Aufgabe n <Aufwand> Ausleihvorgang Umsetzungsentwurf Ausleihvorgang 0,5 PT Maske Ausleihvorgang umsetzen 1,0 PT Aufruf aus Ausleihliste umsetzen 0,5 PT Test des Ausleihvorgang 0,5 PT Dokumentation der Umsetzung 0,5 PT 25

Retrospektive Warum sollen wir das machen, was ist das Ziel? Wir wollen aus abgeschlossenen Projekten lernen. Ziel ist die kontinuierliche i Verbesserung des Projektablaufs. Inhalt der Retrospektive: 1. Was lief gut? (Was haben wir gelernt und umgesetzt?) 2. Was könne wir verbessern? (Was wollen wir beim nächsten mal besser machen?) Dokumentation: Typ Beschreibung Anmerkung / Vorschlag Wer/bis wann/status t Gut Klare Anforderungen UserStory s im PBL - Ver- Status der Module unklar Kanban-Schulung nächstes Semester bessern 26 Highlights und Flops Höhepunkte: Besuch der Kunden Systematischer Architekturentwurf (Völter/Stal - Architektourpodcast) Gruppenarbeit (3 Projekte = 23 Studenten in 5 Gruppen) Projektpräsentationen Verbesserungen: Einheitliches Dokumenten-Ablagesystem mit Versionierung, Abgabe und Benotung (-> Vorlesungs-Verwaltung) Projektabwicklung mit Scrum + Kanban mehr Zwischenpräsentationen i 47

Dozentenbewertung 48 Ausblick SWE I im 4. Semester Umsetzungsentwurf Test-Management Implementierung Dokumentation Abnahme Prof. Alexander K. Dewdney http://www.csd.uwo.ca/~akd/ Spektrum der Wissenschaft, Computer Kurzweil, 1998; 49

Fragen: 50