ESRI User Forum Schw eiz Fachgruppe ArcObjects

Größe: px

Ab Seite anzeigen:

Download "ESRI User Forum Schw eiz Fachgruppe ArcObjects"

Ida Lorentz
vor 8 Jahren
Abrufe

1 ESRI User Forum Schw eiz Fachgruppe ArcObjects Workshop und Präsentation Universität Zürich I rchel Präsentation Jochen Manegold (Co-Autor des Buches "ArcMAP - Programmierung mit VBA )

00 Universität Zürich I rchel Präsentation Jochen

2 Produkt- und Softw areenw icklung Projektmanagement Die 5 Phasen des Product Life Cycles

3 Übersicht Unterschied Produkt - Applikation Product Life Cycle Vision Planung Entw icklung Qualitätssicherung Verteilung 3

4 Unterschied Produkt - Applikation Produkt: viele Nutzer Product Life Cycle Release Management Konsistenz Applikation: ein/ e Nutzer/ Organisation ein one off deliverable maßgeschneidert Dynamik 4

5 Merkmale eines Produkts Ausführbarer Code Executable Libraries (Extensions) Name Dokumentation Gedruckt ( Handbuch) Digital ( Online Hilfe) Beispiele z.t. mit Daten Lizensierung Verpackung 5

6 Merkmale eines Produkts Marketing Materialien Demo Materialien Technischen Support Training 6

7 Unterschied VBA - Komponenten VBA: Skripting Dokument Nicht kompiliert Nur eine Enw icklungsumgebung Komponenten: Development Bibliothek Kompiliert Viele verschiedene Entw icklungsumgebungen 7

8 Product Life Cycle Applikation VBA sehr eingeschränkt Komponenten bedingt notw endig Produkt absolut notw endig 8

9 Product Life Cycle Rational s Unified Process Microsoft s Solutions Framework 5 Phasen der Softw are Entw icklung Methode Schlüsselelemente Meilensteine Feature Complete Betas Zero Defect Methology Shipping 9

are Entw icklung Methode Schlüsselelemente

10 5 Phasen des Product Life Cycles Vision Planung Entw icklung Qualitätssicherung Verteilung 10

11 11

12 Phase 1: Vision Produkt Vision w as ist das Produkt? wie soll es heißen? wie baue ich es? für wen baue ich es? wie Lizensiere ich es? Geschäftsmodell Projekt-Ziele, -Märkte, -Kunden Proof of Concept Prototyp Story Boards Use Case Scenarios 12

13 Phase 1: Vision Deliverables Vision ( Vision Document) Projekt Struktur ( Project Structur Document) Risiko Behandlung ( Risk Assessment Document) identifizieren analysieren zuweisen PRO- AKTIV Projektmanagement = Risikomanagement rechtzeitig Risiken identifizieren, analysieren, priorisieren, planen, terminieren, zuweisen, dokumentieren, kontrollieren und daraus lernen 13

PRO- AKTIV Projektmanagement = Risikomanagement rechtzeitig Risiken identifizieren,

14 Phase 2: Planung Funktionale Anforderungen definieren Architektur der Lösung festlegen Entw icklungsumgebung identifizieren Dokumentation planen Tests planen Release planen Marketing planen 14

15 Release planen Produktspezifikation Minimal Shipping Product ( MSP) Wissen, wie viel man machen muß Feature Creep kontrollieren Versionierung Releaseplan, Phasenplan diese Funktion kommt in der nächsten Version 15

Feature Creep kontrollieren Versionierung

16 Release Plan Funktionale Spezifikation Master Projektplan Master Terminplan Erw eitertes Dokument zur Riskiobehandlung 16

17 Phase 3 - Entwicklung Kodierung Testen Dokumentation Marketing Materialien Herstellungsprozess 17

18 Entw icklungsumgebung Für oder mit welchem ESRI Produkt? Desktop ArcMap, ArcCatalog, ArcGlobe Engine Server Mit w elcher Programmiersprache? C++ COM Java.Net Für welche Plattform? UNIX Windows 18

19 Entw icklungsprozess Use Case Driven Software Architektur Patterns Konzepte Hohe Abstraktion Software Design Klassen und Schnittstellen Sequenzdiagramme Zustandsdiagramme Software Implementierung Kleine Teams (2-5 Personen) Incl. Testen War Room Quality Bar Code Sharing 19

Sequenzdiagramme Zustandsdiagramme Software Implementierung Kleine

20 Gutes Design Was heißt gutes Design? Einfach Effizient Wartbar Prototyp ( Proof of concept ) Wird niemals Produkt Code Design Objekt Modell Review 20

21 Effizientes Entwickeln Kleine Team (2 5 Personen) Keine vorgeschriebene Methode jedes Team entscheidet, w as für sie die Beste ist Wenige Standards Was die Wartbarkeit betrifft ( Dokumentation) Was das Testen betrifft ( Automation) Was die Lokalisierung betrifft ( Ressourcen) 21

22 Effizientes Entwickeln Stabile Systemumgebung Keine Betriebssystem Updates ( OS Patch) Keine Softw are Updates ( ArcGI S Patch) Keine Kompiler Updates ( VB Patch) Source Code Management I st sehr wertvoll Source Code Management System Backups Code Sharing Konkurrierende Entw icklungen ( Mainstream Branch) 22

23 Effizientes Entwickeln Daily Build Zu jeder Zeit eine stabile Version verfügbar Grundlage der holistic Tests Grundlage für die Entw icklung des Setups Entw icklungs-rhythmus Ansporn für die Entwickler, täglich einen erfolgreichen Build zu produzieren 23

24 Test Strategie zur Qualitätssicherung Kein einmaliges Ereignis Kontinuierlicher Prozess Betrifft alle Beteiligten 24

25 Was ist Testen? Maßstab für das Erreichen einer bestimmten Qualität Stellt sicher, dass dies ein Teil der Produktentw icklung ist Stellt sicher, dass das Produkt auch das tut, w as es soll Deckt Fehler und Mängel im Design auf Gehört zur täglichen Routinearbeit und ist integrierter Bestandteil des gesamten Entw icklungszyklus Beginnt so früh wie möglich es muss noch keine Zeile Code existieren Jeder ist für Tests mitverantw ortlich 25

26 Testplan I ntegrierter Bestandteil des Projektplans Legt fest Wie wird getestet Inhaltlich funktional Technisch Wer ist verantw ortlich Was heißt erfolgreich getestet Test Ressourcen Hardw are, Softw are 26

27 Testplan Test Daten Unterschiedliche Formate Unterschiedliche Datenmengen Test Formate und Vorlagen Standards Systemumgebungen Ländereinstellungen 27

28 Testarten UNI T GUI Holistic Checklist Performance Skalierung Usability 28

29 Test und I ssue Tracking I ntegtation der Testumgebung in das I ssue Tracking Verknüpfung der fehlerhaften Testabläufe mit den entsprechenden I ssues Spezielle Testläufe für behobene Fehler Schw ierig Zahlt sich auf lange Sicht hin aus 29

30 I ssue Tracking Zwei Arten von Bugs Fehler ( Defects) Erw eiterungen ( Enhancements) Standardformulare für die Erfassung Status erfaßt klassifiziert zugew iesen gefixt geprüft 30

31 Klassifizierung Priority Wie wichtig ist es, den Fehler zu beheben 1 es kann nicht weitergearbeitet oder getestet werden 2 es muss bis zur Auslieferung gefixt sein 3 es sollte bis zur Auslieferung gefixt sein 4 wird im nächsten Release gefixt Severity Wie schwerwiegend ist der Fehler 1 Absturz oder Datenfehler 2 Betrifft eine sehr wichtige Funktionen 3 Betrifft eine nicht so wichtige Funktionen 4 Verbesserungsvorschlag 31

32 Klassifizierung Severity/ Priority entscheidet, welcher Fehler gefixt w erden muss Zw ei Alternativen den Fehler zu adressieren damit er gefixt wird den Fehler nicht zu adressieren Klassifizierung nicht adressierter Fehler I st schon gefixt Wird schon gefixt Das ist so by design Wird nicht gefixt 32

33 Bugfix Meilensteine sind zw ingend Alle Priority 1 und 2 Bugs müssen gefixt sein Bug-Analyse gibt Aufschluß über den aktuellen Qualitätsstand 33

34 Setup und I nstallation Muss ebenfalls geplant werden Setzt mit dem Software Build ein Sammelt alle I nformationen Komponenten Dateien Änderungen an der Registry 3rd Party Softw are oder Komponenten Lizensierung 34

35 Erstellen eines Setups Produkt Name Produkt Version I nstallationsverzeichnis Systemvorraussetzungen OS ArcGI S 35

36 Testen eines Setups Testumgebung Clean mashine Dirty mashine Testinhalt I nstallation Vergleich Deinstallation Vergleich Mit verschiedenen Systemrechten 36

37 Phase 3 - Ergebnisse Beta 1 Release ( feature complete) Training Materialien Dokumentation Marketing Materialien Erw eiterte Dokumente Master Produktplan Master Terminplan Dokument zur Riskiobehandlung 37

38 Phase 4: Qualitätssicherung Beta 1 Release PreRealease Release Bug Management Testen ( Beta Programm) Daily Builts Dokumentation Marketing Materialien Produktion 38

39 Phase 4 - Ergebnisse Final Release Code Dokumentation Verpackung Lizenzierung Technischer Support Marketing Materialien Erw eiterte Dokumente Master Produktplan Master Terminplan Dokument zur Riskiobehandlung 39

40 Phase 5: Verteilung Produktion Shipping Support Patch Release 40

41 Numerierung von Versionen Was bedeutet die Release Nummer? 1.0 Major Release 1.1 Verbesserungen Bug Fix Service Packs und Patches 41

42 Behandlung von Fehlern Fehler treten auf Priorisierung Patch erstellen Möglichst ohne Einfluß auf die aktuelle Entw icklung Getrennte Code Verw altung 42

43 43

44 Denk an das magische Dreieck Resources Ship Date Features 44

Ähnliche Dokumente

Grundlagen Software Engineering

Grundlagen Software Engineering Rational Unified Process () GSE: Prof. Dr. Liggesmeyer, 1 Rational Unified Process () Software Entwicklungsprozess Anpassbares und erweiterbares Grundgerüst Sprache der