IT-Basics 2. DI Gerhard Fließ. Vorgehensmodelle

Größe: px

Ab Seite anzeigen:

Download "IT-Basics 2. DI Gerhard Fließ. Vorgehensmodelle"

Carl Kirchner
vor 8 Jahren
Abrufe

1 IT-Basics 2 DI Gerhard Fließ Vorgehensmodelle

2 Sichtbarkeit Die Sichtbarkeit von Membervariablen und Methoden können durch die folgenden Schlüsselworte geregelt werden: private nur in der eigenen Klasse protected in abgeleiteten Klassen public in allen Klassen

geregelt werden: private nur in der eigenen Klasse

3 Namespaces Namespaces dienen zur Verwaltung der einzelnen Klassen in verschiedenen Bibliotheken und um Namenskonflikte zu vermeiden. Eine Klasse wird mit namespace {...} einem Namensraum zugeordnet. Möchte man einen Namensraum benutzen kann man diesen mit using <Name> einbinden.

Eine Klasse wird mit namespace {...} einem Namensraum zugeordnet.

4 Beispiel Körper z x (1) Quader [3x/50y/2z] (2) Prisma [9x/50y/2z] (3) Zylinder [12x/4y/4z] (4) Prisma [9x/9y/1z] (5) Prisma [9x/3y/1z]

5 Beispiel Körper 4 z z y x (4) Prisma [9x/1y/9z] (5) Prisma [9x/1y/3z] (6) Kegel [14x/11y/11z] (7) Zylinder [60x/11y/11z] (8) Kegel [12x/11y/11z]

6 Beispiel Körper z 33y y x

7 Körper Beispiel Erweiterung Schwerpunkt Verschieben Rotieren

8 IT-Projekte Einführung Rahmenbedingungen

9 Servermigration 10 Windows 2003 auf Windows Vista 200 Workstations greifen darauf zu Buchhaltung, Lagerverwaltung, -Server Neugestaltete Benutzeroberfläche Über 15 Jahre gewachsene Serveranwendung Die Oberfläche soll neu erstellt werden Die User sollen danach effizienter arbeiten können Überarbeitung einer Simulationsanwendung Die Anwendung ist in der Lage Wärmeübergänge zu simulieren Derzeit können Knoten in 2h simuliert werden Benötigt werden Knoten in 1h

werden Die User sollen danach effizienter arbeiten können Überarbeitung einer Simulationsanwendung Die Anwendung ist in

10 Risiken von Projekten Personalmängel Unrealistische Zeit- und Kostenpläne Entwicklung der falschen Funktionalität Unpassende Benutzerschnittstelle Vergolden eines Systems Häufige Änderungen der Anforderungen Qualitätsmängel bei extern vergebenen Komponenten Qualitätsmängel bei extern vergebenen Aufgaben Unzureichende Produktionsleistungen Projektziele an der Grenze des State-of-the-Art

Änderungen der Anforderungen Qualitätsmängel bei extern vergebenen Komponenten Qualitätsmängel

11 Kaufen oder Erstellen Kauf Abänderung Neuerstellung Entspricht Anforderungen Ungefähr (oft viele ungenützte Funktionen oder ein paar fehlende Funktionen) Fast (oft durch technische Grenzen beschränkt) Genau Änderbarkeit Schwierig, da technische Details oft nicht oder schlecht dokumentiert Ausgangsprodukt wurde selbst hergestellt: leicht änderbar, Durch andere hergestellt: schwer änderbar Gut, da Dokumentation dafür ausgerichtet ist Preis Je nach Anforderungen und Verbreitung Durchführung - selbst: billig - durch andere: teuer Teuer

schlecht dokumentiert Ausgangsprodukt wurde selbst hergestellt: leicht änderbar, Durch andere hergestellt: schwer änderbar Gut, da

12 Rahmenbedingungen Qualität Entwicklung Kosten Termine

13 Ein Vorgehensmodell definiert: Abläufe in den verschiedenen Projektphasen Tätigkeiten in den einzelnen Phasen Die Ergebnisse jeder Phase Wann welche Personen eingesetzt werden

14 Wasserfallmodell System Anforderungen Software Anforderungen Gut wenn: Arbeitsschitte gut trennbar Risiko bekannt Bekanntes Umfeld Analyse Entwurf Schlecht wenn: Großen Projekte Hohem Innovatinonsgrad Unklaren Anforderungen Implement. Test. Betrieb.

Umfeld Analyse Entwurf Schlecht wenn: Großen Projekte Hohem

15 V-Modell Anforderungen Inbetriebnahme Design Integrations- Abnahmetests Umsetzung Unit Tests Erweitert Wasserfall um korrespondierende Tests Hat die selben Eigenschaften wie Wasserfall

16 Inkrementelles Vorgehen Analyse Entwurf Implement. Auslieferung. Build 1 Analyse Entwurf Implement. Auslieferung. Build 2 Analyse Entwurf Implement. Auslieferung. Build 3 Analyse Entwurf Implement. Auslieferung. Schrittweise Erstellung, Kunde sieht öffter ein Ergebnis

Build 2 Analyse Entwurf Implement. Auslieferung.

17 Agile Methoden Ziel ist ein schlankeres und flexibleres Vorgehensmodell. Erfordert aber ein konsequentes Team, weil der Prozess offener ist. Werte 1.Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge. 2.Funktionierende Programme sind wichtiger als ausführliche Dokumentation. 3.Die stetige Abstimmung mit dem Kunden ist wichtiger als die ursprüngliche Leistungsbeschreibung in Verträgen. 4.Der Mut und die Offenheit für Änderungen stehen über dem Befolgen eines festgelegten Plans.

Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge. 2.

18 Scrum Ist ein iterativ inkrementeller Prozess mit einfachen aber strikten Regeln

19 Rollen in Scum Team: Das für die Umsetzung zuständige Entwicklungsteam Product Owner: Vertritt den Kundem gegenüber dem Team Scrum Master: wacht darüber, dass der Prozess eingehalten wird

20 Sprints sind Entwicklungszyklen die 2-4 Wochen dauern. Planung Sprintende Retrospektive Planung Sprintende Retrospektive

21 Task Board Übersicht über alle Stories und Tasks Stories Tasks Work Done

Ähnliche Dokumente

PROJEKTMANAGEMENT GRUNDLAGEN_2

PROJEKTMANAGEMENT GRUNDLAGEN_2 Friedrich-Schiller-Universität Jena Fakultät für Mathematik und Informatik Lehrstuhl für Softwaretechnik Dipl. Ing. Gerhard Strubbe IBM Deutschland GmbH Executive Project Manager (IBM), PMP (PMI) gerhard.strubbe@de.ibm.com