ESRI User Forum Schw eiz Fachgruppe ArcObjects Workshop und Präsentation 23.03.2005 14.00-17.00 Universität Zürich I rchel Präsentation Jochen Manegold (Co-Autor des Buches "ArcMAP - Programmierung mit VBA )
Produkt- und Softw areenw icklung Projektmanagement Die 5 Phasen des Product Life Cycles
Übersicht Unterschied Produkt - Applikation Product Life Cycle Vision Planung Entw icklung Qualitätssicherung Verteilung 3
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
Merkmale eines Produkts Ausführbarer Code Executable Libraries (Extensions) Name Dokumentation Gedruckt ( Handbuch) Digital ( Online Hilfe) Beispiele z.t. mit Daten Lizensierung Verpackung 5
Merkmale eines Produkts Marketing Materialien Demo Materialien Technischen Support Training 6
Unterschied VBA - Komponenten VBA: Skripting Dokument Nicht kompiliert Nur eine Enw icklungsumgebung Komponenten: Development Bibliothek Kompiliert Viele verschiedene Entw icklungsumgebungen 7
Product Life Cycle Applikation VBA sehr eingeschränkt Komponenten bedingt notw endig Produkt absolut notw endig 8
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
5 Phasen des Product Life Cycles Vision Planung Entw icklung Qualitätssicherung Verteilung 10
11
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
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
Phase 2: Planung Funktionale Anforderungen definieren Architektur der Lösung festlegen Entw icklungsumgebung identifizieren Dokumentation planen Tests planen Release planen Marketing planen 14
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
Release Plan Funktionale Spezifikation Master Projektplan Master Terminplan Erw eitertes Dokument zur Riskiobehandlung 16
Phase 3 - Entwicklung Kodierung Testen Dokumentation Marketing Materialien Herstellungsprozess 17
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
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
Gutes Design Was heißt gutes Design? Einfach Effizient Wartbar Prototyp ( Proof of concept ) Wird niemals Produkt Code Design Objekt Modell Review 20
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
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
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
Test Strategie zur Qualitätssicherung Kein einmaliges Ereignis Kontinuierlicher Prozess Betrifft alle Beteiligten 24
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
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
Testplan Test Daten Unterschiedliche Formate Unterschiedliche Datenmengen Test Formate und Vorlagen Standards Systemumgebungen Ländereinstellungen 27
Testarten UNI T GUI Holistic Checklist Performance Skalierung Usability 28
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
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
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
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
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
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
Erstellen eines Setups Produkt Name Produkt Version I nstallationsverzeichnis Systemvorraussetzungen OS ArcGI S 35
Testen eines Setups Testumgebung Clean mashine Dirty mashine Testinhalt I nstallation Vergleich Deinstallation Vergleich Mit verschiedenen Systemrechten 36
Phase 3 - Ergebnisse Beta 1 Release ( feature complete) Training Materialien Dokumentation Marketing Materialien Erw eiterte Dokumente Master Produktplan Master Terminplan Dokument zur Riskiobehandlung 37
Phase 4: Qualitätssicherung Beta 1 Release PreRealease Release Bug Management Testen ( Beta Programm) Daily Builts Dokumentation Marketing Materialien Produktion 38
Phase 4 - Ergebnisse Final Release Code Dokumentation Verpackung Lizenzierung Technischer Support Marketing Materialien Erw eiterte Dokumente Master Produktplan Master Terminplan Dokument zur Riskiobehandlung 39
Phase 5: Verteilung Produktion Shipping Support Patch Release 40
Numerierung von Versionen Was bedeutet die Release Nummer? 1.0 Major Release 1.1 Verbesserungen 1.1.1 Bug Fix Service Packs und Patches 41
Behandlung von Fehlern Fehler treten auf Priorisierung Patch erstellen Möglichst ohne Einfluß auf die aktuelle Entw icklung Getrennte Code Verw altung 42
43
Denk an das magische Dreieck Resources Ship Date Features 44