• Keine Ergebnisse gefunden

Vorlesung Informatik 1

N/A
N/A
Protected

Academic year: 2022

Aktie "Vorlesung Informatik 1"

Copied!
14
0
0

Wird geladen.... (Jetzt Volltext ansehen)

Volltext

(1)

Vorlesung Informatik 1

Fachhochschule für Technik Esslingen Studiengang Wirtschaftsinformatik

Projektspielregeln

Dr. rer. nat. Andreas Rau

http://www.hs-esslingen.de/~rau andreas.rau@hs-esslingen.de

(2)

Ziel des Projekts ist es, die in Informatik 1 erworbenen und in Informatik 2 vertieften Kenntnisse im Rahmen zu Nutzen, um gemeinsam im Team ein sinnvolles und funktionierendes Programm zu entwickeln. Dabei sind neben programmiertechnischen Aspekten auch die Erfahrung bzgl. Zusammenarbeit im Team wichtig (in der Industrie gibt es keine Einzelgänger).

Die Projektaufgaben werden so gestaltet, dass am Ende der Mühen aller Wahrscheinlichkeit ein Erfolg steht. Dadurch soll neben der Sicherung der Motivation (Spass durch kleine Erfolgserlebnisse) auch Vertrauen in die eigenen Fähigkeiten aufgebaut werden. Jeder Student sollte am Ende auf sein Ergebnis stolz sein.

Soft-Skills werden zusätzlich durch die Rollenverteilung im Projekt, insbesondere die Festlegung eines Projektleiters, sowie die Abschlusspräsentation gefördert (es reicht nicht gut zu sein, man muss es auch rüberbringen!).

Aufgabe des Dozenten ist es einerseits, in der Rolle des Kunden Anforderungen vorzugeben oder zu steuern und andererseits in der Rolle des Coaches bei Problemen mit Rat und Tat zur Stelle zu sein um den Projekterfolg zu sichern.

Ziel des Projekts

(3)

Jedes Team sollte idealerweise aus 2-3 Personen bestehen. Oberhalb dieser Zahl ist eine sinnvolle Verteilung und Koordination der Aufgaben schwierig, darunter schwindet der Teamaspekt und die Arbeitslast steigt.

Die Aufgabe wird dem Kenntnisstand des Teams angepasst, sollte aber in keinem Fall zu trivial sein (Fairness und fehlender Stolz am Ende). Nach oben sind dem Ehrgeiz dagegen (fast) keine Grenzen gesetzt...

Besonders in gemischten Teams aus starken und schwachen Mitgliedern ist auf eine gleichmäßige Aufgabenverteilung zu achten. Starke Programmierer stehen ihren schwachen Kollegen mit Rat und Tat zur Seite, nehmen Ihnen aber nicht das Programmieren ab (es sitzt immer der Schwache an der Tastatur damit er das Tempo bestimmen kann und mitkommt, notfalls gibt es

"Programmierverbot"!). Schwache Programmierer arbeiten am Besten zu zweit (4 Augen sehen mehr).

Die Aufgaben jedes Teammitglieds müssen definiert sein. Jedes Teammitglied muss am Ende über sein Arbeitsergebnis berichten können (wird geprüft).

Teamstruktur

(4)

Gesamtsystem (3-Tier) Benutzeroberfläche (MVC)

Swing, Java2D, Listener

Programmlogik Daten, Events, Threads

Datenhaltung JDBC, Serialisierung

Rahmenwerk

Aufruf lokal oder über Netzwerk

Aufruf lokal oder über Netzwerk

D ok u me n tati on E nt w ür fe , K om m ent are , H andbuc h

O rgan is ati on A nf or de runge n, Z ei tpl an, ...

(5)

Für den zeitlichen Ablauf werden ca. 14-tägige Meilensteine vorgegeben um die Projekte "einheitlich zu takten", Verschleppungen zu vermeiden und frühzeitig auf Verzug reagieren zu können.

Geplante Aktivitäten sollen ca. 14-Tage im voraus festgelegt werden Durchgeführte Aktivitäten sollen im Kalender nachdokumentiert werden Eine wöchentliche Regelkommunikation wird dringend empfohlen

Die Planung/Nachdokumentation ist wichtig für die Projektsteuerung bzw. die Nachgelagerte Analyse (Soll/Ist-Vergleich) und die daraus abzuleitenden Erkenntnisse.

Ziel ist, Schritt für Schritt von der Idee zum fertigen System zu kommen und dabei immer ein greifbares und funktionsfähiges Zwischenergebnis zu haben.

Neue Erkenntnisse aus der Vorlesung sollen zuerst mit Hilfe von Übungen gesichert werden bevor sie in das Projekt übernommen werden (keine Experimente / Technologiebaustellen im Produkt!).

Zeitlicher Ablauf(1)

(6)

Zeitlicher Ablauf(2)

Themenfindung Technologie

Recherche GUI Entwurf Preview Version

(nur GUI)

Finale Version (Gesamtfunktion)

Alpha Version (Grundfunktion)

Beta Version (Gesamtfunktion) GUI Übung 1

GUI Übung 2 Technologie Übung 1 Technologie Übung 2 GUI Theorie 1

GUI Theorie 2

Technologie Übung 3 Threads

Datenbanken Netzwerke Vertiefung Coaching

(7)

Zeitlicher Ablauf(3) Vorbereitung

Steckbrief, Anforderungen, Arbeitspakete,Zeitplan,

GUI Entwurf, Entwurf

Umsetzung

Programm (Stil, Javadoc, ...) Pflege Arbeitspakete/Zeitplan

Nachbereitung

Handbuch, Präsentation, CD

Implementierung der Funktionen in mehreren Schritten

Experimente

Neue Technologien vor Einbau separat und einzeln evaluieren

(8)

Zeitlicher Ablauf(4)

Prüfung!

Juli Januar

April

Februar

März

Mai

Juni

August

September Oktober November

Dezember

you are here

WS SS

Projekt fängt gemütlich an

"Wird schon nicht so schwer"

Aber Achtung: Das Ganze ist mehr als die Summe der Teile

Prüfungen? Ich hab doch mein Buch dabei.

Trotzdem: Informatik ist irgendwie anders

Die Prüfungen waren anstrengend Die Ferien sind viel zu kurz

Das Nachholen fällt noch kürzer aus

In der Praxis ist es doch nicht so einfach. Erste Probleme aber noch kein Stress (wird schon).

Abgabetermin rückt näher, die Prüfung(en) auch. Verdammt, wie ging das nochmal. Jetzt wird es langsam doch stressig. Aua!

Stress und Blutdruck steigen. Die Tage werden länger, die Nächte kürzer. Der Kaffeekonsum steigt, die Augenringe werden größer.

Ich hab schon drei Tage vorher gelernt!

Huch, warum sind die 90min schon um?

Orientierung im Studienalltag Grau ist alle Theorie

Die Übungen klappen nicht oder sind weniger lustig als die Spiele im Pool.

Macht nix, die Prüfung ist noch weit.

I have long enjoyed asking

candidate programmers, "Where is next November?". [...] The really good programmers have strong spatial senses; they usually have geometric models of time [...]

Frederick P. Brooks

"No Silver Bullet" Refired

Prüfung!

Noch ne Prüfung Wo war das noch gleich im Skript?

(9)

Folgende Inhalte müssen am Ende des Projekts vorliegen (Checkliste!)

Planung: Projektsteckbrief, ca. 1 DIN A4 Seite mit Beschreibung Thema / Kernfunkt.

Planung: Anforderungen, mind. 10 Anforderungen

Planung: Arbeitspakete, mind. 3 Arbeitspakete pro Teammitglied Planung: Zeitplan, siehe vorhergehende Folien bzw. Vorlage

Planung: GUI Entwurf, elektronisch oder Papier (später einscannen)

Planung: Entwurf, Zerlegung des Systems als UML, Blockschaltbild oder Text Programm: Funktionalität, Hauptfunktionen ohne Absturz

Programm: Ergonomie, z.B. Oberfläche und Benutzerführung

Programm: Strukturierung, z.B. Trennung zwischen Logik und Oberfläche Programm: Formatierung/Stil, Einrückung und Namensgebung

Dokumentation: JavaDoc, für Klassen und public-Methoden

Dokumentation: Handbuch, mit Screenshots und ggf. Installationsanleitung Dokumentation: Präsentation, Foliensatz

Projekt: CD-Modul, Verzeichnisse und HTML-Dateien

Geforderte Inhalte

(10)

Neben der Abgabe der geforderten Artefakte am Ende müssen folgende Kriterien zum Erwerb des Scheins erfüllt werden:

Einhaltung der Meilensteine (3x verpasst = verpatzt!)

Vorlage vor-/nachausgefüllter Zeitplan (Leistungsnachweis!) bei jedem Meilenstein Beantwortung von allgemeinen Fragen zum Programm (jeder soll alles verstehen!) Beantwortung von speziellen Fragen zum eigenen Arbeitspaket

Hinweis:

Die aktive Teilnahme am Projekt ist maßgeblich für den Schein und außerdem eine gute Vorbereitung auf die Prüfung (Programmiererfahrung!). Gegenstand der Prüfung ist jedoch nicht das Projekt, sondern der behandelte Lehrstoff, der in den Projekten je nach gewählter Aufgabenstellung mehr oder weniger stark zum Tragen kommt.

Übungszeiten können für Besprechungen und Arbeiten zum Projekt genutzt werden. Es wird jedoch empfohlen, auf jeden Fall die Übungsaufgaben zum Vorlesungsstoff durchzuarbeiten, ggf. eben zuhause.

Abnahmekriterien

(11)

Die Abschlusspräsentation soll die folgenden Inhalte abdecken Vorstellung der Aufgabe

Hintergrund / Quelle der Idee Beschreibung der Idee

Rückblick über Projektverlauf

Vorgehensweise bei der inhaltlichen Planung Vorgehensweise bei der Abstimmung im Team Vorgehensweise bei der technischen Umsetzung Was hat besonders gut geklappt ( ca. 3 Punkte ) Was hat nicht so gut geklappt ( ca. 3 Punkte ) Vorstellung des Endprodukts

Kurze Vorführung oder Screenshots

Vergleich mit der ursprünglichen Planung / Design Ausblick ( Weiterenwicklung, Nutzung, ...? )

Abschlusspräsentation

(12)

1. Klare Arbeitsteilung im Team (z.B. GUI, Datenbank, Handbuch, ...) und Aufteilung des Systems in Klassen / Dokumente so dass jeder sein "eigenes" Teil hat und Konflikte bei Änderungen vermieden werden.

2. Von Anfang an auf sprechende Namen, saubere Einrückung und klare Schnittstellen achten. Jede Minute die hier investiert wird kommt später doppelt wieder rein (leichteres Verständnis, besserer Überblick, leichtere Integration, ...). Nachbessern ist schwer!

3. GUI fertigstellen (die Oberfläche muss eigentlich alle Anforderungen wiederspiegeln bzw. "einen Knopf für jede Funktion" haben – jedoch erstmal ohne Wirkung).

4. Funktionen Zug um Zug einbauen, Kernfunktionen zuerst. Es wird nix implementiert ohne dass eine entsprechende Anforderung vorliegt (Anforderungen ggf. nachziehen).

5. Das Programm muss zu jedem Zeitpunkt lauffähig sein; keine Grossbaustelle Ein Mitarbeiter (der PL?) ist verantwortlich für das zusammenführen der Teile zu einem Ganzen. Nich funktionierende Teile werden abgelehnt.

6. Neue Technologien zuerst anhand von Beispielen/Übungsaufgaben und mit kleineren Prototypen ausprobieren, dann erst einbauen (copy-paste ist dabei erlaubt bzw. normal).

Tipps zum Vorgehen

(13)

Pflicht (Kopf - Technik) 1. Grafische Oberfläche

Windows (J2SE) Webbrowser (J2EE) Handy/PDA (J2ME)

2. Datenspeicherung bzw. Datentransfer

Verwaltung in einer Datenbank oder in Dateien Transfer über ein Netzwerk

3. Algorithmischer Anteil

Umwandlung bzw. Aufbereitung von Daten, z.B. als HTML Report oder Grafik Kür (Herz - Leidenschaft, Motivation)

4. Ein Programm für den eigenen Einsatz Kenntnis des Anwendungsbereichs 5. Ein cooles Programm (zum vorzeigen!)

Eigene Aha-Effekte, Entwicklerstolz und positives Feedback von Dritten

Kriterien zur Themenwahl

(14)

Im Projekt gibt es vielfältige Aufgaben zu erfüllen. Entscheidend für den Projekterfolg ist u.a. die richtige Rollenverteilung der Projektmitglieder. Dabei gilt es unterschiedliche Charaktertypen zu beachten.

Beispiele:

Visionär – kann andere für Ideen begeistern und Leidenschaft entfachen

Organisator – sorgt für Ordnung, Abstimmung und Einhaltung von Terminen

Tüftler – liebt es Probleme auf elegante Weise zu lösen, auch wenn es dauert

Kreativer Gestalter – erstellt mit Hingabe Benutzeroberflächen und Dokumente

Sachlicher Denker – hält Produkt und Spezifikation zusammen, bleibt cool

Bastler – liebt schnelle Lösungen (die aber nicht immer 100%ig funktionieren)

Perfektionist – baut und testet langsam aber sorgfältig

...

Aufgabe: Führen Sie eine (geheime) Selbsteinschätzung durch und besprechen sie anschließend die Rollenverteilung im Projekt und bewerten beides am Ende.

Rollen(verteilung) im Projekt

Referenzen

ÄHNLICHE DOKUMENTE

Diese kann sich naturgemäß nicht über Nacht einstellen, man muß schon etwas (Frei)zeit investieren!. Die Umstellung wird durch die Tatsache weiter erschwert, daß sich

Insbesondere werden alle Instanzen des Problems durch denselben Algorithmus gelöst (es gibt jedoch auch Algorithmen für Teilprobleme). Wichtig: Ein Algorithmus ist unabhängig

Die Sortierung ist sozusagen nur eine Vorstufe davon, da man in sortierten Daten schneller suchen kann. Bei der Bewertung von Suchalgorithmen zählt vor

Damit die Objekte einer Klasse später auch in Collections (Datenstrukturen – wie Arrays, nur komfortabler) verwendet werden können, muss daneben für die Methoden equals()

Glücklicherweise muß man dies nicht manuell implementieren: Über das Interface Serializable können beliebige Klassen für die automatische Ein-/Ausgabe markiert

Während es im textbasierten Programm eine eigene Ablaufsteuerung (meist in Form einer Schleife) gibt, die Benutzereingaben wartet und diese verarbeitet, wartet

Fehler und die Leute die sie machen sind im allgemeinen nicht sehr beliebt?. ABER: Fehler sind nicht so schlimm, wie manche

Variablen, Ausdrücke, Kontrollstrukturen Klassen, Kapselung, Interfaces, Vererbung. überschreiben vs überladen