E N D
1. Prinzipien fr die erfolgreiche Applikationsentwicklung Klaus Rohe
klaus.rohe@microsoft.com
Microsoft Deutschland GmbH
2. Ziel der Prsentation Darstellung von praktischen Prinzipien, die sich bei der Entwicklung von Softwaresystemen bewhrt haben.
Die Prinzipien selbst sind unabhngig von der Technologie
Beispiele, wie man diese Prinzipien auf der Microsoft Plattform umsetzen kann.
Kein Anspruch auf Vollstndigkeit!
Erfolgreiche Applikationsentwicklung:
Zeit- und Kostenrahmen eingehalten
Anforderungen werden erfllt
3. Die Prinzipien Die Benutzer wissen hufig nicht genau was sie haben wollen
Schnell einen Prototypen liefern
Das Rad nicht neu erfinden
Bewhrte Lsungsanstze nutzen (Best Practices)
Die Zukunft ist nicht vorhersehbar
Services unabhngig halten
Trau den Clients nicht
Das Unsichtbare sichtbar machen
Alles protokollieren
Die Daten kennen
Die Grenzen des Systems kennen
Nicht am Erfolg scheitern
4. Die Benutzer wissen hufig nicht genau was sie haben wollen (1) Problem: Endbenutzer (Kunden) haben meist nur eine grobe Vorstellung, was das neue Softwaresystem leisten soll.
Meistens keine genauen Vorstellung ber die Details
Keine Experten fr Anforderungsdokumente
Anforderungsdokument:
Formale Beschreibung der Systemanforderung bis auf die Detailebene
Wer erstellt es?
5. Die Benutzer wissen hufig nicht genau was sie haben wollen (2) Man kann von den Kunden ein detailliertes Anforderungsdokument verlangen, aber:
Anforderungsdokument wird auf Biegen und Brechen fertig gestellt
Enthlt eventuell irrelevante Anforderungen, nur um ein finales, detailliertes Dokument abzuliefern
Schlechte Strategie:
Penetrant darauf bestehen, dass mit der Softwareentwicklung erst nach der Freigabe des Anforderungsdokuments begonnen werden kann.
6. Iterativer Prozess zur Anforderungsermittlung
7. Schnell einen Prototypen liefern Anforderungen durch Rapid Prototyping przisieren =>
Mglichst frh mit einem Prototypen herauskommen
Anhand des Prototypen sind die Kunden besser in der Lage, Anforderungen weiter zu detaillieren.
Kunden sind die besten Tester!!
Mit dem Kunden zusammen den Prototypen testen.
Funktionierender Code schafft vertrauen!
8. Schnell einen Prototypen liefern Umfang des Prototypen
Benutzeroberflche
Kritischer Durchstich
Visual Studio hat die Tools zum rapid Prototyping von grafischen Benutzeroberflchen:
Windows Presentation Foundation
Windows Forms
Office (Word, Excel, Outlook) als Basis-GUI
ASP.NET Webforms und WebParts
Mashups mit PopFly
9. PowerShell fr Prototypen Die Microsoft Windows PowerShell ist ein Scripting-Werkzeug fr Windows XP, Vista, Windows Server 2003 und 2008
Basiert auf .NET 2.0
.NET 3.X Klassenbibliotheken knnen genutzt werden.
PowerShell kann fr Prototyping genutzt werden
Kein Kompilieren notwendig
Komplette .NET (2.0 3.x) Klassenbibliothek verfgbar
10. Die Prinzipien Die Benutzer wissen hufig nicht genau was sie haben wollen
Schnell einen Prototypen liefern
Das Rad nicht neu erfinden
Bewhrte Lsungsanstze nutzen (Best Practices)
Die Zukunft ist nicht vorhersehbar
Services unabhngig halten
Trau den Clients nicht
Das Unsichtbare sichtbar machen
Alles protokollieren
Die Daten kennen
Die Grenzen des Systems kennen
Nicht am Erfolg scheitern
11. Das Rad nicht neu erfinden Hufige Gegenargumente:
Die Anforderungen an die zu entwickelnde Applikation sind einzigartig!
Wir haben nicht genug Zeit bzw. Geld zum recherchieren, ob es schon Komponenten bzw. Produkte gibt, welche uns die Arbeit erleichtern.
Wir haben keine Zeit uns in die Nutzung existierender Komponenten einzuarbeiten
Aber es ist genug Zeit und Geld da, um etwas komplett neu zu entwickeln, zu testen usw.!!
12. Kaufen oder neu Entwickeln? Microsoft Dynamics CRM 4.0?
Microsoft Dynamics Axapta?
Office Business Applications (OBA) in Betracht ziehen
Nutzung der Office Programme Word, Excel als Basis-Clients, applikationsspezifische Erweiterung mit selbstentwickelten .NET Komponenten
Welchen Mehrwert kann Microsoft Office Sharepoint Server 2007 fr die geplante Applikation bringen?
13. Beispiele fr neu erfundene Rder Entwicklung von Infrastrukturfunktionen, die schon durch Middleware bzw. Betriebssystem bereitgestellt wird.
Entwicklung von Klassenbibliotheken und Werkzeugen, die allgemeine Querschnittsfunktionalitten betreffen:
Workflow
Datenzugriff, Caching
Logging, Instrumentierung, Exception handling
14. Die Kosten neu erfundener Rder Studien haben ergeben, das Programmierer 40 50 % ihrer Zeit damit verbringen, Code zu produzieren, den es schon gibt!
http://spectrum.ieee.org/sep05/1685
Folgen:
Wiederholung von Fehlern
Design & Entwurf
Implementierung
Ressourcenverschwendung
15. Was ist der Mehrwert der Applikation? Separation of Concerns
16. Auf der Microsoft Windows Plattform
17. IIS 7.0 als skalierbarer Server fr WCF Services Hosten von WCF Services
Server selber implementieren?
IIS als Server nutzen?
IIS 7.0 hat viele neue Funktionen fr WCF
Windows Process Activation Service
Untersttzung aller WCF-Transportprotokolle:
Http, Tcp, Named pipes,MSMQ
Management, Health Monitoring,
18. Windows Workflow Foundation Werkzeugkasten fr Softwareentwickler
Die Workflow Foundation (WF) vereinfacht:
Implementierung langlaufender & wiederanlauffhiger Komponenten
Monitoring und Tracking von Komponenten
Grafische Komposition aus bestehenden Services / Aktivitten
Implementierung von Geschftsregeln
Implementierung von flexiblen leichter nderbaren Komponenten
Was WF nicht ist:
Server-Produkt, vergleichbar oder Ersatz fr BizTalk
19. BizTalk als Integration-, Message- und Service- Broker Skalierbarer Integration-Broker & Workflow Engine =>
BizTalk Server 2006:
Workflow zwischen Applikationen
If you are integrating multiple applications with some interaction that involves system workflow you should use BizTalk Server
If you want runtime scalability, fault tolerance and administration tools you should use BizTalk Server
Nicht BizTalk mit der Windows Workflow Foundation neu implementieren!
20. Enterprise Library fr Querschnittsfunktionen
21. Die Herausforderung von Multi-Core CPUs Applikationen mit herkmmlichen Methoden entwickeln, die Multi-Core CPUs ausnutzen, ist sehr schwer und fehlertrchtig:
Multi-Threading, Locking, Testen,
Neue Werkzeuge fr die Programmierung multi-core fhiger Applikationen:
Parallel Extensions for .NET 3.5
CTP Download: http://www.microsoft.com/downloads/details.aspx?FamilyID=e848dc1d-5be3-4941-8705-024bc7f180ba&displaylang=en
22. TPL Beispiel
23. Software + Services Der Trend geht dahin, bestimmte Softwarefunktionen als (Web-) Service zur Verfgung zu stellen. Beispiele:
Microsoft Life Services, MapPoint & Virtual Earth, Amazon Web-Services,
http://msdn2.microsoft.com/en-us/architecture/aa699384.aspx
Kann die Applikationsentwicklung mit Hilfe solcher Services vereinfacht werden?
24. Die Prinzipien Die Benutzer wissen hufig nicht genau was sie haben wollen
Schnell einen Prototypen liefern
Das Rad nicht neu erfinden
Bewhrte Lsungsanstze nutzen (Best Practices)
Die Zukunft ist nicht vorhersehbar
Services unabhngig halten
Trau den Clients nicht
Das Unsichtbare sichtbar machen
Alles protokollieren
Die Daten kennen
Die Grenzen des Systems kennen
Nicht am Erfolg scheitern
25. Bewhrte Lsungsanstze nutzen (Best Practices) Dies ist eine Ergnzung zum vorher behandelten Prinzip
Recherchieren, wie andere hnliche Applikationen implementiert haben:
Welche Architektur?
Welche Muster?
Was sollte man auf keinen Fall machen?
.
User Groups, Spezielle Web-Sites, Literatur,
26. Microsoft Patterns & Practices Anleitungen, Empfehlungen und Source-Code fr die Untersttzung der Entwicklung unterschiedlichster Applikationsszenarien auf der Microsoft Windows Plattform mit .NET:
Architektur
Kodierung, Test
Verteilung & Betrieb
Best Practices aus Microsoft internen und Partner Projekten
http://msdn2.microsoft.com/en-us/practices/default.aspx
27. CodePlex CodePlex ist eine von Microsoft betriebene Web-Site: http://www.codeplex.com/
Untersttzt die Entwicklung von Open Source Projekten im .NET Umfeld:
Wikis
Source Code Kontrolle auf der Basis des Team Foundation Servers
Diskussionforen
Projekt- und Probelmverfolgung
RSS Untersttzung
Enterprise Library
http://www.codeplex.com/entlib
Composite UI Application Block
http://www.codeplex.com/smartclient/Wiki/View.aspx?title=Composite%20UI%20Application%20Block
28. Weitere Web-Sites The Code Project: http://www.codeproject.com/
Enthlt Programme, Implementierung von Algorithmen und Beschreibungen von Lsungen aus den Bereichen .NET, SQL Server, BizTalk,
Newsletter
Source Forge: http://sourceforge.net
Viele Open Source Projekte aus dem .NET Bereich
Beispiel: MyGeneration http://sourceforge.net/projects/mygeneration
MyGeneration ist ein Code-Generator (C#, VB.NET) fr den Datenbankzugriff und OR-Mapper, der die folgenden Datenbanken untersttzt:
Microsoft SQL Server, Access
Oracle, IBM DB2
PostgreSQL, MySQL, .
29. Composite UI Application Block (CAB) CAB ist ein Framework zur Entwicklung von Clients mit Windows Forms und WPF
Ursprnglich Entwickelt von der Patterns & Practice Gruppe, jetzt auf CodePlex
http://www.codeplex.com/smartclient/Wiki/View.aspx?title=Composite%20UI%20Application%20Block
Das CAB Entwicklungsmodell basiert Use Cases, genannt WorkItems und Patterns
Lose Kopplung zwischen den Use Cases
Kommunikation ber einen Eventbroker
Faktorisierung Querschnittsfunktionen in CAB interne Service
30. Architektur und Funktion von CAB
32. Die Prinzipien Die Benutzer wissen hufig nicht genau was sie haben wollen
Schnell einen Prototypen liefern
Das Rad nicht neu erfinden
Bewhrte Lsungsanstze nutzen (Best Practices)
Die Zukunft ist nicht vorhersehbar
Services unabhngig halten
Trau den Clients nicht
Das Unsichtbare sichtbar machen
Alles protokollieren
Die Daten kennen
Die Grenzen des Systems kennen
Nicht am Erfolg scheitern
33. Die Zukunft ist nicht vorhersehbar Zuverlssige Kristallkugeln sind sehr rar!!
Einplanung von nderungen an der Infrastruktur
nderung der physischen Konfiguration, Verteilung und Deployment der Anwendung
Einplanung von nderungen der Funktionalitt
Neue Funktionalitt einbauen
Neue Datenbanken integrieren
Integration mit anderen Anwendungen
Fazit: Anwendung mglichst nderungsfreundlich / flexibel bauen!
34. Flexible Architektur durch WCF 3-Schichten-Architektur auf der Basis von WCF
nderung der Konfiguration ist einfach!!
35. Flexible Komponenten mit der Windows Workflow Foundation (WF) Mit WF kann man Komponenten entwickeln, deren Verhalten sich ohne Kompilation anpassen lsst.
Logische Struktur (xoml-Datei) des Workflows und Code der Aktivitten sind getrennt!
36. Flexible Architektur mit CAB, WCF,
37. Die Prinzipien Die Benutzer wissen hufig nicht genau was sie haben wollen
Schnell einen Prototypen liefern
Das Rad nicht neu erfinden
Bewhrte Lsungsanstze nutzen (Best Practices)
Die Zukunft ist nicht vorhersehbar
Services unabhngig halten
Trau den Clients nicht
Das Unsichtbare sichtbar machen
Alles protokollieren
Die Daten kennen
Die Grenzen des Systems kennen
Nicht am Erfolg scheitern
38. Services unabhngig halten (1) Services stellen definierte Funktionalitten zur Verfgung.
Services, welche von zu vielen Komponenten ab hngen, erhhen die Gefahr von impliziten Kopplungen zwischen Services
Services, die andere Services nutzen, sollten dies ber die offizielle Service-Schnittstelle tun nicht auf Implementierungsdetails nutzen. The Four Tenets of Service Orientation:
Boundaries Are Explicit
Services Are Autonomous
Services share Schema and Contracts
Compatibility Is Policy-Based
39. Services unabhngig halten (2) In WCF kann ein Service ber verschiedene Transportprotokolle aufgerufen werden.
Z. B. NamedPipes fr Service - Service Kommunikation, wenn sie auf dem gleichen Rechner sind
40. Die Prinzipien Die Benutzer wissen hufig nicht genau was sie haben wollen
Schnell einen Prototypen liefern
Das Rad nicht neu erfinden
Bewhrte Lsungsanstze nutzen (Best Practices)
Die Zukunft ist nicht vorhersehbar
Services unabhngig halten
Trau den Clients nicht
Das Unsichtbare sichtbar machen
Alles protokollieren
Die Daten kennen
Die Grenzen des Systems kennen
Nicht am Erfolg scheitern
41. Trau den Clients nicht (1) Speziell bei Web-Applikationen muss man mit bswilligen Attacken rechnen:
SQL- und Skript-Injection
Eingabe von Suchkriterien, welche die Datenbank bermig belasten
Grundstzlich sollte man untersuchen, ob Eingaben von Clients Schaden anrichten knnen:
Steuerungs- und Kontrollsysteme, Medizintechnik, usw.
Plausibilittsprfung der eingegeben Daten!
Syntaktisch korrekt (Datumsformat, Email-Adresse, )
Semantisch korrekt, im einfachsten Fall Bereichsprfung,
42. Trau den Clients nicht (2) Untersttzung zur Lsung bietet der Validation Application Block der Enterprise Library:
Validierung mit Attributen, Konfiguration und Regeln
Integration mit Windows Form, ASP.NET, und WCF
43. Keine PlausibilittsprfungNASA Verlust des Mars Climate Orbiter Finale Bahnkorrektur der NASA Sonde Mars Climate Orbiter falsch:
Einheiten der Datenbasis waren Imperial Units und nicht metrische, wie von der NASA gefordert. (Faktor 4,5 zu gro)
Relativ einfache Plausibilittsberechnung htte die Fehler aufgedeckt.
Folge: Totalverlust der Sonde, ca. 83 Millionen USD schaden
44. Die Prinzipien Die Benutzer wissen hufig nicht genau was sie haben wollen
Schnell einen Prototypen liefern
Das Rad nicht neu erfinden
Bewhrte Lsungsanstze nutzen (Best Practices)
Die Zukunft ist nicht vorhersehbar
Services unabhngig halten
Trau den Clients nicht
Das Unsichtbare sichtbar machen
Alles protokollieren
Die Daten kennen
Die Grenzen des Systems kennen
Nicht am Erfolg scheitern
45. Das Unsichtbare sichtbar machen berwachung der Applikation whrend des Betriebs
Anforderungen des Betriebs (Operating): Laufzeitdiagnose von Anwendungen
=> Instrumentierung der Anwendung
=> Health-Model fr die Anwendung entwickeln
Instrumentierung mit Windows Management Instrumentation (WMI)
Untersttzung durch das .NET Framework und Visual Studio
WMI basiert auf dem Standard Web Based Enterprise Management (WBEM)
46. Die Prinzipien Die Benutzer wissen hufig nicht genau was sie haben wollen
Schnell einen Prototypen liefern
Das Rad nicht neu erfinden
Bewhrte Lsungsanstze nutzen (Best Practices)
Die Zukunft ist nicht vorhersehbar
Services unabhngig halten
Trau den Clients nicht
Das Unsichtbare sichtbar machen
Alles protokollieren
Die Daten kennen
Die Grenzen des Systems kennen
Nicht am Erfolg scheitern
47. Alles protokollieren (1) Logging ist ntzlich:
Bei der Fehlersuche in Verteilten Applikationen, whrend Entwicklung und Betrieb
Erstellen von Nutzungsprofilen
Aus Grnden der Sicherheit
Datenschutzrichtlinien beim Logging beachten!
Wenn mglich Logging im Produktionsbetrieb nicht abschalten
Server wie SQL Server und BizTalk bieten eingebaute Logging-Funktionalitt.
48. Alles protokollieren (2) Logging fr .NET Applikationen:
Logging Application Block der Enterprise Library
Apache Log4net, Portierung von log4j auf Microsoft .NET
http://logging.apache.org/log4net/
49. Die Prinzipien Die Benutzer wissen hufig nicht genau was sie haben wollen
Schnell einen Prototypen liefern
Das Rad nicht neu erfinden
Bewhrte Lsungsanstze nutzen (Best Practices)
Die Zukunft ist nicht vorhersehbar
Services unabhngig halten
Trau den Clients nicht
Das Unsichtbare sichtbar machen
Alles protokollieren
Die Daten kennen
Die Grenzen des Systems kennen
Nicht am Erfolg scheitern
50. Die Daten kennen Business Entitities sind in allen Schichten verfgbar
Abbildung der Unternehmensdaten auf Business Entities
BizTalk zur Integration?
51. Die Prinzipien Die Benutzer wissen hufig nicht genau was sie haben wollen
Schnell einen Prototypen liefern
Das Rad nicht neu erfinden
Bewhrte Lsungsanstze nutzen (Best Practices)
Die Zukunft ist nicht vorhersehbar
Services unabhngig halten
Trau den Clients nicht
Das Unsichtbare sichtbar machen
Alles protokollieren
Die Daten kennen
Die Grenzen des Systems kennen
Nicht am Erfolg scheitern
52. Die Grenzen des System kennen Der Integrationstest zeigt, dass die einzelnen Teile und Komponenten des Systems zusammen funktionieren. Keine Aussage ber:
Wie verhlt sich das System bei einer groem Anzahl von Benutzern?
Wie verhlt sich das System, wenn die Datenbank groe Datenmengen enthlt?
Was passiert wenn a) und b) geleichzeitig auftreten?
Die Antworten liefern Lasttests!
53. Lasttests mit Visual Studio Team System Visual Studio Team System bietet eine reihe Lasttestszenarien fr Web-Applikationen:
Constant Load Profile: konstante Anzahl Clients
Step Load Profile: Anzahl der Clients wird schrittweise und definierten Zeitintervallen erhht
Goal-based Profile: Last wir solange erhht, bis eine Ressource einen kritischen Wert erreicht
Fr WCF: http://www.codeplex.com/WCFLoadTest
54. Die Prinzipien Die Benutzer wissen hufig nicht genau was sie haben wollen
Schnell einen Prototypen liefern
Das Rad nicht neu erfinden
Bewhrte Lsungsanstze nutzen (Best Practices)
Die Zukunft ist nicht vorhersehbar
Services unabhngig halten
Trau den Clients nicht
Das Unsichtbare sichtbar machen
Alles protokollieren
Die Daten kennen
Die Grenzen des Systems kennen
Nicht am Erfolg scheitern
55. Nicht am Erfolg scheitern Manchmal leben Applikationen lnger als erwartet oder werden in grerem Umfang genutzt als geplant:
Applikation so entwerfen, dass sie skalierbar und flexibel ist.
Beispiel aus der Microsoft-Welt:
Access-Applikationen, hufig als Einzelplatzanwendung konzipiert, werden aber von ganzer Abteilung genutzt.
Fazit: Besser gleich mit einer .NET-Applikation starten, deren Architektur entsprechende Erweiterungen erlaubt. (WCF drei Schichten )
56. Zusammenfassung Es wurden einige Prinzipien aufgezeigt, die beachten sollte, wenn man Softwareprojekte erfolgreich durchfhren will.
Die Abbildung dieser Prinzipien auf Microsoft Technologien wurde dargestellt
Die dargestellten Prinzipien waren technologischer Natur.
Softwareprojekte scheitern aber nicht nur an der Technik, dies soll zum Abschluss kurz dargestellt werden.
57. Grnde fr das Scheitern von Softwareprojekten Unrealistische Projektziele
Falsche oder ungenaue Ermittlung der bentigten Ressourcen
Schlecht definierte Systemanforderungen
Fehlendes Risikomanagement
Schlechtes Projektmanagement
Unzureichende Kommunikation zwischen Entwicklern, Kunden und Endbenutzern
Nutzung nicht ausgereifter Technologien
Schlampige Entwicklungspraxis
Wirtschaftlicher Druck und politische Spielchen
58. Microsoft Ressourcen fr Architekten Architecture Guidance Documents
http://www.microsoft.com/practices
The Architecture Journal
Erscheint 4 mal pro Jahr, Themen aus dem Bereichen IT-Architektur
Autoren:
Unabhngige Anwender von Microsoft Technologien
Microsoft Mitarbeiter
Registrieren unter: www.ArchitectureJournal.net
59. Ressourcen fr Entwickler und Architekten Microsoft Patterns & Practices
http://msdn2.microsoft.com/en-us/practices/default.aspx
Softwarearchitektur
http://msdn2.microsoft.com/en-us/architecture/default.aspx
CodePlex
http://www.codeplex.com/
60. Weitere Informationen (1) Ronald Mak
The Martian Principles for Successful Enterprise Systems, 20 Lessons Learned from NASAs Mars Exploration Rover Mission
Indianapolis 2006
ISBN-10: 0-471-78965-8
ISBN-13: 978-0-471-78965-9
61. Weitere Informationen (2) Why Software Fails
http://spectrum.ieee.org/sep05/1685
Reinventing the wheel
http://techblog.41concepts.com/2007/07/
http://smoothspan.wordpress.com/2007/09/04/70-of-the-software-you-build-is-wasted-part-1-of-series-of-toolplatform-rants/
Denkfallen und Programmieren:
http://www2.hs-fulda.de/~grams/Denkfallen/SystemHaupt.htm
62. Weitere Informationen (3) Software-Desasters
http://www5.informatik.tu-muenchen.de/~huckle/bugs.html
http://www-aix.gsi.de/~giese/swr/index.html
http://www.ganssle.com/articles/disaster.htm
http://www.zdnet.co.uk/misc/print/0,1000000169,39290976-39001115c,00.htm
http://www.cs.tau.ac.il/~nachumd/horror.html