Prinzipien fr die erfolgreiche Applikationsentwicklung Klaus Rohe klaus

  • Slides: 63
Download presentation
Prinzipien für die erfolgreiche Applikationsentwicklung Klaus Rohe klaus. rohe@microsoft. com Microsoft Deutschland Gmb. H

Prinzipien für die erfolgreiche Applikationsentwicklung Klaus Rohe klaus. rohe@microsoft. com Microsoft Deutschland Gmb. H

Ziel der Präsentation Darstellung von praktischen Prinzipien, die sich bei der Entwicklung von Softwaresystemen

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

Die Prinzipien „Die Benutzer wissen häufig nicht genau was sie haben wollen“ Schnell einen

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

Die Benutzer wissen häufig nicht genau was sie haben wollen (1) Problem: Endbenutzer (Kunden)

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?

Die Benutzer wissen häufig nicht genau was sie haben wollen (2) Man kann von

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.

Iterativer Prozess zur Anforderungsermittlung High-Level Anforderungen Mock-up: rudimentärer (Wegwerfprototyp) der Benutzeroberfläche Mock-up des UIs

Iterativer Prozess zur Anforderungsermittlung High-Level Anforderungen Mock-up: rudimentärer (Wegwerfprototyp) der Benutzeroberfläche Mock-up des UIs bauen Anforderungen verfeinern Mock-up mit Endbenutzer evaluieren

Schnell einen Prototypen liefern Anforderungen durch Rapid Prototyping präzisieren => Möglichst früh mit einem

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!

Schnell einen Prototypen liefern Umfang des Prototypen Benutzeroberfläche Kritischer Durchstich Visual Studio hat die

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 Web. Parts Mashups mit Pop. Fly

Power. Shell für Prototypen Die Microsoft Windows Power. Shell ist ein Scripting-Werkzeug für Windows

Power. Shell für Prototypen Die Microsoft Windows Power. Shell 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. Power. Shell kann für Prototyping genutzt werden Kein Kompilieren notwendig Komplette. NET (2. 0 – 3. x) Klassenbibliothek verfügbar

Die Prinzipien „Die Benutzer wissen häufig nicht genau was sie haben wollen“ Schnell einen

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

Das Rad nicht neu erfinden Häufige Gegenargumente: Die Anforderungen an die zu entwickelnde Applikation

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. !!

Kaufen oder neu Entwickeln? Microsoft Dynamics CRM 4. 0? Microsoft Dynamics Axapta? Office Business

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?

Beispiele für „neu erfundene Räder“ Entwicklung von Infrastrukturfunktionen, die schon durch Middleware bzw. Betriebssystem

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 …

Die Kosten „neu erfundener Räder“ Studien haben ergeben, das Programmierer 40 – 50 %

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/sep 05/1685 Folgen: Wiederholung von Fehlern Design & Entwurf Implementierung Ressourcenverschwendung Erzeugter Mehrwert "Rad neu erfinden"

Was ist der Mehrwert der Applikation? Separation of Concerns Querschnittsfunktionalitäten Eigentliche Applikationslogik oder Kernfunktionalität

Was ist der Mehrwert der Applikation? Separation of Concerns Querschnittsfunktionalitäten Eigentliche Applikationslogik oder Kernfunktionalität Kommunikation Workflow Datenzugriff (Mehrwert für den Kunden!) Caching Sicherheit Exception Handling “Middleware” Web Server Service Host Integration Broker Message Broker Service Broker … Logging Instrumentierung

Auf der Microsoft Windows Plattform Querschnittsfunktionalitäten Eigentliche Applikationslogik oder Kernfunktionalität Kommunikation Workflow Caching Sicherheit

Auf der Microsoft Windows Plattform Querschnittsfunktionalitäten Eigentliche Applikationslogik oder Kernfunktionalität Kommunikation Workflow Caching Sicherheit Exception Handling “Middleware” Biz. Talk Server Workflow Foundation Datenzugriff (Mehrwert für den Kunden!) Internet Information Service (IIS) WCF … Logging Instrumentierung Enterprise Library

IIS 7. 0 als skalierbarer Server für WCF Services Hosten von WCF Services Server

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 WCFTransportprotokolle: Http, Tcp, Named pipes, MSMQ Management, Health Monitoring, … Architektur des IIS 7. 0

Windows Workflow Foundation Werkzeugkasten für Softwareentwickler Die Workflow Foundation (WF) vereinfacht: Implementierung langlaufender &

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 Biz. Talk Visual Designer (Visual Studio 2005 / 2008) Ein Workflow Custom Activity Library Windows Workflow Foundation Base Activity Library Runtime Engine Runtime Services

Biz. Talk als Integration-, Message- und Service- Broker Skalierbarer Integration-Broker & Workflow Engine =>

Biz. Talk als Integration-, Message- und Service- Broker Skalierbarer Integration-Broker & Workflow Engine => Biz. Talk Server 2006: Workflow zwischen Applikationen “If you are integrating multiple applications with some interaction that involves system workflow you should use Biz. Talk Server” “If you want runtime scalability, fault tolerance and administration tools you should use Biz. Talk Server” Nicht „Biz. Talk“ mit der Windows Workflow Foundation neu implementieren! Biz. Talk Server Workflow Design Tools Orchestration Messaging Transformation Adapters BAM and Admin Tools

Enterprise Library für Querschnittsfunktionen Data Access Caching Logging Core Cryptography Config Helpers & Design

Enterprise Library für Querschnittsfunktionen Data Access Caching Logging Core Cryptography Config Helpers & Design Plug-in Instrumentation Exception Handling Object Builder Security Policy Injection Validation

Die Herausforderung von Multi-Core CPUs Applikationen mit herkömmlichen Methoden entwickeln, die Multi-Core CPUs ausnutzen,

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. asp x? Family. ID=e 848 dc 1 d-5 be 3 -4941 -8705024 bc 7 f 180 ba&displaylang=en

TPL Beispiel // Ohne TPL void Seq. Matrix. Mult(int size, double[, ] m 1,

TPL Beispiel // Ohne TPL void Seq. Matrix. Mult(int size, double[, ] m 1, double[, ] m 2, double[, ] result) { for (int i = 0; i < size; i++) { for (int j = 0; j < size; j++) { result[i, j] = 0; for (int k = 0; k < size; k++) { result[i, j] += m 1[i, k] * m 2[k, j]; } } // Mit TPL using System. Concurrency; void Par. Matrix. Mult(int size, double[, ] m 1, double[, ] m 2, double[, ] result) { Parallel. For( 0, size, delegate(int i) { for (int j = 0; j < size; j++) { result[i, j] = 0; for (int k = 0; k < size; k++) { result[i, j] += m 1[i, k] * m 2[k, j]; } } }); }

Software + Services Benutzerschnittstelle (Smart Client, Browser, Mobil, …) Service Schnittstellen Workflows Komponenten Datenzugriffslogik

Software + Services Benutzerschnittstelle (Smart Client, Browser, Mobil, …) Service Schnittstellen Workflows Komponenten Datenzugriffslogik Service. Agent Daten Interne Services (ERP, CRM, …) Der Trend geht dahin, bestimmte Softwarefunktionen als (Web-) Service zur Verfügung zu stellen. Beispiele: Microsoft Life Services, Map. Point & Virtual Earth, Amazon Web-Services, … http: //msdn 2. microsoft. com/enus/architecture/aa 699384. aspx Kann die Applikationsentwicklung mit Hilfe solcher Services vereinfacht werden? Externe Services

Die Prinzipien „Die Benutzer wissen häufig nicht genau was sie haben wollen“ Schnell einen

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

Bewährte Lösungsansätze nutzen („Best Practices“) Dies ist eine Ergänzung zum vorher behandelten Prinzip Recherchieren,

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, …

Microsoft Patterns & Practices Anleitungen, Empfehlungen und Source. Code für die Unterstützung der Entwicklung

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: //msdn 2. microsoft. com/enus/practices/default. aspx

Code. Plex ist eine von Microsoft betriebene Web-Site: http: //www. codeplex. com/ Unterstützt die

Code. Plex 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/Vie w. aspx? title=Composite%20 UI%20 Applicatio n%20 Block

Weitere Web-Sites The Code Project: http: //www. codeproject. com/ Enthält Programme, Implementierung von Algorithmen

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, Biz. Talk, … Newsletter Source Forge: http: //sourceforge. net Viele Open Source Projekte aus dem. NET Bereich Beispiel: My. Generation http: //sourceforge. net/projects/mygeneration My. Generation 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 DB 2 Postgre. SQL, My. SQL, ….

Composite UI Application Block (CAB) CAB ist ein Framework zur Entwicklung von Clients mit

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 Code. Plex http: //www. codeplex. com/smartclient/Wiki/View. aspx? ti tle=Composite%20 UI%20 Application%20 Block Das CAB Entwicklungsmodell basiert Use Cases, genannt „Work. Items“ und Patterns Lose Kopplung zwischen den Use Cases Kommunikation über einen Eventbroker Faktorisierung Querschnittsfunktionen in CAB interne Service

Architektur und Funktion von CAB Shell Root Work Item View UI Extension Site Work

Architektur und Funktion von CAB Shell Root Work Item View UI Extension Site Work Item Shared State Shared Events Element Module Catalog

Premier Support for Developer (PSf. D) • Support Account Management • Application Developer Consultant

Premier Support for Developer (PSf. D) • Support Account Management • Application Developer Consultant (ADC) als direkter Ansprechpartner • Service und Ressource Management • Proactive Services • Technologieberatung • Design- , Code- und Architektur Review • Kundenspezifische Workshops • Troubleshooting, Debugging und Profiling • Reactive Problem Resolution Services PSf. D Mission: Proactive and reaktive services to: • • Accelerate your time to market Mitigate development risk Increase your teams’ productivity Provide clear evidence to your marketplace • Priorisierter Problemlösungssupport für alle Microsoft Produkte (24 x 7 x 356) • Emergency On. Site Support • Information Services • Gesicherte Web-Site für Premierkunden • Partner Level Knowledge Base • Product Flashes & Critical Alerts 31 PSf. D Envision Plan Develop Stabilize Deploy

Die Prinzipien „Die Benutzer wissen häufig nicht genau was sie haben wollen“ Schnell einen

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

Die Zukunft ist nicht vorhersehbar Zuverlässige Kristallkugeln sind sehr rar!! Einplanung von Änderungen an

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! Blick in die Kristallkugel ?

Flexible Architektur durch WCF 3 -Schichten-Architektur auf der Basis von WCF Änderung der Konfiguration

Flexible Architektur durch WCF 3 -Schichten-Architektur auf der Basis von WCF Änderung der Konfiguration ist einfach!! Client PC WCF Client Laptop für Außendienst Applikation oder Teile davon müssen offlinefähig gemacht werden WCF Client config Named-Pipes TCP / HTTP WCF Services Server config WCF Services config DB DB

Flexible Komponenten mit der Windows Workflow Foundation (WF) Mit WF kann man Komponenten entwickeln,

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! Code My. Workflow (logische Struktur) . NET Assembly Workflow. Editor Aktivität 1 Anpassen des Workflows durch editieren der xoml-Datei Custom Activities Class Aktivität 1 Class Aktivität 2 Class Aktivität 3 Class Aktivität 4 If. Else. Aktivität < Aktivität 3. NET Assembly Aktivität 2 Base Activities Aktivität 4 My. Workflow. xoml (Beschreibt die logische Struktur)

Flexible Architektur mit CAB, WCF, … CAB EL Geschäftsentitäten Authentication, Authorisation, Logging, …(EL) Web-Client

Flexible Architektur mit CAB, WCF, … CAB EL Geschäftsentitäten Authentication, Authorisation, Logging, …(EL) Web-Client Silverlight / AJAX Smart Part Service Agent mit lokalem Cache HTTP WCF (SOAP) WEB UI (IIS) WCF Services (IIS) Geschäftslogik Data Layer Interface (DLI) Datenbankunabhängigkeit SQLDBLayer ORADBLayer XYDBLayer SQLServer Oracle XYDB Smart Client

Die Prinzipien „Die Benutzer wissen häufig nicht genau was sie haben wollen“ Schnell einen

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

Services unabhängig halten (1) Services stellen definierte Funktionalitäten zur Verfügung. Services, welche von zu

Services unabhängig halten (1) Services stellen definierte Funktionalitäten zur Verfügung. Services, welche von zu vielen Boundaries Are Explicit Komponenten ab hängen, Services Are Autonomous Services share Schema and erhöhen die Gefahr von impliziten Kopplungen Contracts zwischen Services Compatibility Is Policy. Based Services, die andere Services nutzen, sollten dies über die offizielle Service-Schnittstelle tun nicht auf Implementierungsdetails nutzen. The Four Tenets of Service Orientation:

Services unabhängig halten (2) Schnittstelle SOAP HTTP SOAP TCP SOAP Named. Pipe REST Implementierung

Services unabhängig halten (2) Schnittstelle SOAP HTTP SOAP TCP SOAP Named. Pipe REST Implementierung WCF-Service In WCF kann ein Service über verschiedene Transportprotokolle aufgerufen werden. Z. B. Named. Pipes für Service - Service Kommunikation, wenn sie auf dem gleichen Rechner sind

Die Prinzipien „Die Benutzer wissen häufig nicht genau was sie haben wollen“ Schnell einen

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

Trau den Clients nicht (1) Speziell bei Web-Applikationen muss man mit böswilligen Attacken rechnen:

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, …

Trau den Clients nicht (2) Unterstützung zur Lösung bietet der „Validation Application Block“ der

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 [String. Length. Validator(1, 50, Ruleset=" Rule. Set. A", Message. Template="Last Name must be 1 -50 characters ")] public string Last. Name { get { return last. Name; } set { last. Name = value; } } [Regex. Validator(@"w+([-+. ']w+)*@w+([-. ]w+)*. w+([-. ]w+)*" , Message. Template="Invalid e-mail address", Ruleset="Rule. Set. A")] public string Email { get { return email; } set { email = value; } } [Object. Validator("Rule. Set. A", Ruleset="Rule. Set. A")] public Address { get { return address; } set { address = value; } }

Keine Plausibilitätsprüfung NASA Verlust des Mars Climate Orbiter Finale Bahnkorrektur der NASA Sonde Mars

Keine Plausibilitätsprüfung NASA 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 ftp: //ftp. hq. nasa. gov/pub/pao/reports/1999/MCO_report. pdf

Die Prinzipien „Die Benutzer wissen häufig nicht genau was sie haben wollen“ Schnell einen

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

Das Unsichtbare sichtbar machen Überwachung der Applikation während des Betriebs Anforderungen des Betriebs (Operating):

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)

Die Prinzipien „Die Benutzer wissen häufig nicht genau was sie haben wollen“ Schnell einen

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

Alles protokollieren (1) Logging ist nützlich: Bei der Fehlersuche in Verteilten Applikationen, während Entwicklung

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 Biz. Talk bieten eingebaute Logging-Funktionalität.

Alles protokollieren (2) Logging für. NET Applikationen: „Logging Application Block“ der Enterprise Library Apache

Alles protokollieren (2) Logging für. NET Applikationen: „Logging Application Block“ der Enterprise Library Apache Log 4 net, Portierung von log 4 j auf Microsoft. NET http: //logging. apache. org/log 4 net/

Die Prinzipien „Die Benutzer wissen häufig nicht genau was sie haben wollen“ Schnell einen

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

Die Daten kennen Service Schnittstellen Workflows Datenzugriffslogik Daten Komponenten Geschäftsentitäten (Business Entities) Querschnittsfunktionen Benutzerschnittstelle

Die Daten kennen Service Schnittstellen Workflows Datenzugriffslogik Daten Komponenten Geschäftsentitäten (Business Entities) Querschnittsfunktionen Benutzerschnittstelle (Smart Client, Browser, Mobil, …) Business Entitities sind in allen Schichten verfügbar Abbildung der Unternehmensdaten auf Business Entities Biz. Talk zur Integration? Service. Agent Interne Services (ERP, CRM, …) Externe Services

Die Prinzipien „Die Benutzer wissen häufig nicht genau was sie haben wollen“ Schnell einen

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

Die Grenzen des System kennen Der Integrationstest zeigt, dass die einzelnen Teile und Komponenten

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? b) Wie verhält sich das System, wenn die Datenbank große Datenmengen enthält? c) Was passiert wenn a) und b) geleichzeitig auftreten? a) Die Antworten liefern Lasttests!

Lasttests mit Visual Studio Team System bietet eine reihe Lasttestszenarien für Web-Applikationen: Constant Load

Lasttests mit 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/WCFLoad. Test

Die Prinzipien „Die Benutzer wissen häufig nicht genau was sie haben wollen“ Schnell einen

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

Nicht am Erfolg scheitern Manchmal leben Applikationen länger als erwartet oder werden in größerem

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 …)

Zusammenfassung Es wurden einige Prinzipien aufgezeigt, die beachten sollte, wenn man Softwareprojekte erfolgreich durchführen

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.

Gründe für das Scheitern von Softwareprojekten Unrealistische Projektziele Falsche oder ungenaue Ermittlung der benötigten

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

Microsoft Ressourcen für Architekten Architecture Guidance Documents http: //www. microsoft. com/practices The Architecture Journal

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. Architecture. Journal. net

Ressourcen für Entwickler und Architekten Microsoft Patterns & Practices http: //msdn 2. microsoft. com/enus/practices/default.

Ressourcen für Entwickler und Architekten Microsoft Patterns & Practices http: //msdn 2. microsoft. com/enus/practices/default. aspx Softwarearchitektur http: //msdn 2. microsoft. com/enus/architecture/default. aspx Code. Plex http: //www. codeplex. com/

Weitere Informationen (1) Ronald Mak The Martian Principles for Successful Enterprise Systems, 20 Lessons

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

Weitere Informationen (2) Why Software Fails http: //spectrum. ieee. org/sep 05/1685 Reinventing the wheel

Weitere Informationen (2) Why Software Fails http: //spectrum. ieee. org/sep 05/1685 Reinventing the wheel http: //techblog. 41 concepts. com/2007/07/ http: //smoothspan. wordpress. com/2007/09/04/7 0 -of-the-software-you-build-is-wasted-part-1 -ofseries-of-toolplatform-rants/ Denkfallen und Programmieren: http: //www 2. hsfulda. de/~grams/Denkfallen/System. Haupt. htm

Weitere Informationen (3) Software-Desasters http: //www 5. informatik. tumuenchen. de/~huckle/bugs. html http: //www-aix. gsi.

Weitere Informationen (3) Software-Desasters http: //www 5. informatik. tumuenchen. 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, 100000016 9, 39290976 -39001115 c, 00. htm http: //www. cs. tau. ac. il/~nachumd/horror. html

© 2007 Microsoft Corporation. All rights reserved. Microsoft, Windows Vista and other product names

© 2007 Microsoft Corporation. All rights reserved. Microsoft, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U. S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.