Prinzipien f r die erfolgreiche Applikationsentwicklung

1. Prinzipien f�r die erfolgreiche Applikationsentwicklung Klaus Rohe klaus.rohe@microsoft.com Microsoft Deutschland GmbH

2. Ziel der Pr�sentation Darstellung von praktischen Prinzipien, die sich bei der Entwicklung von Softwaresystemen bew�hrt haben. Die Prinzipien selbst sind unabh�ngig von der Technologie Beispiele, wie man diese Prinzipien auf der Microsoft Plattform umsetzen kann. Kein Anspruch auf Vollst�ndigkeit! Erfolgreiche Applikationsentwicklung: Zeit- und Kostenrahmen eingehalten Anforderungen werden erf�llt

3. Die Prinzipien �Die Benutzer wissen h�ufig nicht genau was sie haben wollen� Schnell einen Prototypen liefern Das Rad nicht neu erfinden Bew�hrte L�sungsans�tze nutzen (�Best Practices�) Die Zukunft ist nicht vorhersehbar Services unabh�ngig 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 h�ufig 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 f�r Anforderungsdokumente Anforderungsdokument: Formale Beschreibung der Systemanforderung bis auf die Detailebene Wer erstellt es?

5. Die Benutzer wissen h�ufig 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 Enth�lt 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 pr�zisieren => M�glichst fr�h 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 Benutzeroberfl�che Kritischer Durchstich Visual Studio hat die Tools zum rapid Prototyping von grafischen Benutzeroberfl�chen: Windows Presentation Foundation Windows Forms Office (Word, Excel, Outlook) als Basis-GUI ASP.NET Webforms und WebParts Mashups mit PopFly

9. PowerShell f�r Prototypen Die Microsoft Windows PowerShell ist ein Scripting-Werkzeug f�r Windows XP, Vista, Windows Server 2003 und 2008 Basiert auf .NET 2.0 .NET 3.X Klassenbibliotheken k�nnen genutzt werden. PowerShell kann f�r Prototyping genutzt werden Kein Kompilieren notwendig Komplette .NET (2.0 � 3.x) Klassenbibliothek verf�gbar

10. Die Prinzipien �Die Benutzer wissen h�ufig nicht genau was sie haben wollen� Schnell einen Prototypen liefern Das Rad nicht neu erfinden Bew�hrte L�sungsans�tze nutzen (�Best Practices�) Die Zukunft ist nicht vorhersehbar Services unabh�ngig 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 H�ufige 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 f�r die geplante Applikation bringen?

13. Beispiele f�r �neu erfundene R�der� Entwicklung von Infrastrukturfunktionen, die schon durch Middleware bzw. Betriebssystem bereitgestellt wird. Entwicklung von Klassenbibliotheken und Werkzeugen, die allgemeine Querschnittsfunktionalit�ten betreffen: Workflow Datenzugriff, Caching Logging, Instrumentierung, Exception handling �

14. Die Kosten �neu erfundener R�der� 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 f�r WCF Services Hosten von WCF Services Server selber implementieren? IIS als Server nutzen? IIS 7.0 hat viele neue Funktionen f�r WCF Windows Process Activation Service Unterst�tzung aller WCF-Transportprotokolle: Http, Tcp, Named pipes,MSMQ Management, Health Monitoring, �

18. Windows Workflow Foundation Werkzeugkasten f�r Softwareentwickler Die Workflow Foundation (WF) vereinfacht: Implementierung langlaufender & wiederanlauff�higer Komponenten Monitoring und Tracking von Komponenten Grafische Komposition aus bestehenden Services / Aktivit�ten Implementierung von Gesch�ftsregeln Implementierung von flexiblen leichter �nderbaren Komponenten Was WF nicht ist: Server-Produkt, vergleichbar oder Ersatz f�r 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 f�r Querschnittsfunktionen

21. Die Herausforderung von Multi-Core CPUs Applikationen mit herk�mmlichen Methoden entwickeln, die Multi-Core CPUs ausnutzen, ist sehr schwer und fehlertr�chtig: Multi-Threading, Locking, Testen, � Neue Werkzeuge f�r die Programmierung multi-core f�higer 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 Verf�gung 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 h�ufig nicht genau was sie haben wollen� Schnell einen Prototypen liefern Das Rad nicht neu erfinden Bew�hrte L�sungsans�tze nutzen (�Best Practices�) Die Zukunft ist nicht vorhersehbar Services unabh�ngig halten Trau den Clients nicht Das Unsichtbare sichtbar machen Alles protokollieren Die Daten kennen Die Grenzen des Systems kennen Nicht am Erfolg scheitern

25. Bew�hrte L�sungsans�tze nutzen (�Best Practices�) Dies ist eine Erg�nzung 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 f�r die Unterst�tzung 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/ Unterst�tzt 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 Unterst�tzung 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/ Enth�lt Programme, Implementierung von Algorithmen und Beschreibungen von L�sungen 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) f�r den Datenbankzugriff und OR-Mapper, der die folgenden Datenbanken unterst�tzt: 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 Urspr�nglich 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 h�ufig nicht genau was sie haben wollen� Schnell einen Prototypen liefern Das Rad nicht neu erfinden Bew�hrte L�sungsans�tze nutzen (�Best Practices�) Die Zukunft ist nicht vorhersehbar Services unabh�ngig 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 Zuverl�ssige Kristallkugeln sind sehr rar!! Einplanung von �nderungen an der Infrastruktur �nderung der physischen Konfiguration, Verteilung und Deployment der Anwendung Einplanung von �nderungen der Funktionalit�t Neue Funktionalit�t einbauen Neue Datenbanken integrieren Integration mit anderen Anwendungen Fazit: Anwendung m�glichst �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 l�sst. Logische Struktur (xoml-Datei) des Workflows und Code der Aktivit�ten sind getrennt!

36. Flexible Architektur mit CAB, WCF, �

37. Die Prinzipien �Die Benutzer wissen h�ufig nicht genau was sie haben wollen� Schnell einen Prototypen liefern Das Rad nicht neu erfinden Bew�hrte L�sungsans�tze nutzen (�Best Practices�) Die Zukunft ist nicht vorhersehbar Services unabh�ngig 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 unabh�ngig halten (1) Services stellen definierte Funktionalit�ten zur Verf�gung. Services, welche von zu vielen Komponenten ab h�ngen, erh�hen 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 unabh�ngig halten (2) In WCF kann ein Service �ber verschiedene Transportprotokolle aufgerufen werden. Z. B. NamedPipes f�r Service - Service Kommunikation, wenn sie auf dem gleichen Rechner sind

40. Die Prinzipien �Die Benutzer wissen h�ufig nicht genau was sie haben wollen� Schnell einen Prototypen liefern Das Rad nicht neu erfinden Bew�hrte L�sungsans�tze nutzen (�Best Practices�) Die Zukunft ist nicht vorhersehbar Services unabh�ngig 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 b�swilligen Attacken rechnen: SQL- und Skript-Injection Eingabe von Suchkriterien, welche die Datenbank �berm��ig belasten Grunds�tzlich sollte man untersuchen, ob Eingaben von Clients Schaden anrichten k�nnen: Steuerungs- und Kontrollsysteme, Medizintechnik, usw. Plausibilit�tspr�fung der eingegeben Daten! Syntaktisch korrekt (Datumsformat, Email-Adresse, �) Semantisch korrekt, im einfachsten Fall Bereichspr�fung, �

42. Trau den Clients nicht (2) Unterst�tzung zur L�sung bietet der �Validation Application Block� der Enterprise Library: Validierung mit Attributen, Konfiguration und Regeln Integration mit Windows Form, ASP.NET, und WCF

43. Keine Plausibilit�tspr�fungNASA 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 Plausibilit�tsberechnung h�tte die Fehler aufgedeckt. Folge: Totalverlust der Sonde, ca. 83 Millionen USD schaden

44. Die Prinzipien �Die Benutzer wissen h�ufig nicht genau was sie haben wollen� Schnell einen Prototypen liefern Das Rad nicht neu erfinden Bew�hrte L�sungsans�tze nutzen (�Best Practices�) Die Zukunft ist nicht vorhersehbar Services unabh�ngig 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 w�hrend des Betriebs Anforderungen des Betriebs (Operating): Laufzeitdiagnose von Anwendungen => Instrumentierung der Anwendung => �Health-Model� f�r die Anwendung entwickeln Instrumentierung mit Windows Management Instrumentation (WMI) Unterst�tzung durch das .NET Framework und Visual Studio WMI basiert auf dem Standard Web Based Enterprise Management (WBEM)

46. Die Prinzipien �Die Benutzer wissen h�ufig nicht genau was sie haben wollen� Schnell einen Prototypen liefern Das Rad nicht neu erfinden Bew�hrte L�sungsans�tze nutzen (�Best Practices�) Die Zukunft ist nicht vorhersehbar Services unabh�ngig 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 n�tzlich: Bei der Fehlersuche in Verteilten Applikationen, w�hrend Entwicklung und Betrieb Erstellen von Nutzungsprofilen Aus Gr�nden der Sicherheit Datenschutzrichtlinien beim Logging beachten! Wenn m�glich Logging im Produktionsbetrieb nicht abschalten Server wie SQL Server und BizTalk bieten eingebaute Logging-Funktionalit�t.

48. Alles protokollieren (2) Logging f�r .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 h�ufig nicht genau was sie haben wollen� Schnell einen Prototypen liefern Das Rad nicht neu erfinden Bew�hrte L�sungsans�tze nutzen (�Best Practices�) Die Zukunft ist nicht vorhersehbar Services unabh�ngig 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 verf�gbar Abbildung der Unternehmensdaten auf Business Entities BizTalk zur Integration?

51. Die Prinzipien �Die Benutzer wissen h�ufig nicht genau was sie haben wollen� Schnell einen Prototypen liefern Das Rad nicht neu erfinden Bew�hrte L�sungsans�tze nutzen (�Best Practices�) Die Zukunft ist nicht vorhersehbar Services unabh�ngig 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 verh�lt sich das System bei einer gro�em Anzahl von Benutzern? Wie verh�lt sich das System, wenn die Datenbank gro�e Datenmengen enth�lt? 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 f�r Web-Applikationen: Constant Load Profile: konstante Anzahl Clients Step Load Profile: Anzahl der Clients wird schrittweise und definierten Zeitintervallen erh�ht Goal-based Profile: Last wir solange erh�ht, bis eine Ressource einen kritischen Wert erreicht F�r WCF: http://www.codeplex.com/WCFLoadTest

54. Die Prinzipien �Die Benutzer wissen h�ufig nicht genau was sie haben wollen� Schnell einen Prototypen liefern Das Rad nicht neu erfinden Bew�hrte L�sungsans�tze nutzen (�Best Practices�) Die Zukunft ist nicht vorhersehbar Services unabh�ngig 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 l�nger als erwartet oder werden in gr��erem Umfang genutzt als geplant: Applikation so entwerfen, dass sie skalierbar und flexibel ist. Beispiel aus der Microsoft-Welt: Access-Applikationen, h�ufig 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 durchf�hren 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. Gr�nde f�r das Scheitern von Softwareprojekten Unrealistische Projektziele Falsche oder ungenaue Ermittlung der ben�tigten 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 f�r Architekten Architecture Guidance Documents http://www.microsoft.com/practices The Architecture Journal Erscheint 4 mal pro Jahr, Themen aus dem Bereichen IT-Architektur Autoren: Unabh�ngige Anwender von Microsoft Technologien Microsoft Mitarbeiter Registrieren unter: www.ArchitectureJournal.net

59. Ressourcen f�r 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 NASA�s 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