SPALM - SharePoint Application Lifecycle Management

Transkript

1 SPALM - SharePoint Application Lifecycle Management Praxisbeispiele für durchgängige SharePoint Entwicklungsprozesse

2 Vorstellung Vorstellung Torsten Mandelkow Diplom-Informatiker(FH) Seit 2007 bei Steria Mummert Mehrjährige SharePoint-Erfahrung als Berater, Architekt, Entwickler Kernkompetenzen Architekturen von großen, globalen SharePoint-Farmen Einführung von SharePoint-Entwicklungsprozessen in Unternehmen Kontakt:

3 Das Unternehmen Steria: Beratung, IT- und Outsourcing Services Off-/Nearshore in Indien, Osteuropa und Marokko Präsenz in Europa Belgien Dänemark Deutschland Frankreich Hongkong Vor Ort in Asien Indien Präsenz in 16 Ländern... Luxemburg Marokko Norwegen Österreich Polen Singapur Spanien Schweden Schweiz UK

4 Das Unternehmen Ein Top 10 Player in Europa 1,8 Mrd. Umsatz (Top 10 in Europa) Mitarbeiter Präsenz in Europa 25% Mitarbeiter in Indien (größter Anteil für ein europäisches Unternehmen) Off-/Nearshore in Indien, Osteuropa und Marokko Vor Ort in Asien

5 Das Unternehmen Leistungsstarke, kundennahe Organisation Präsenz in Deutschland und Österreich Off-/Nearshore in Indien, Osteuropa und Marokko Präsenz in Europa Vor Ort in Asien Berlin Düsseldorf Frankfurt Hamburg Köln Leipzig München Münster Wien

6 Das Unternehmen Marktposition Ranking 2008 TOP 15 der Managementberatungs-Unternehmen in Deutschland 2008 Unternehmen Umsatz in Mio. Euro 2008 im Inland 1 McKinsey & Company Inc. Deutschland, Düsseldorf *) 645,0 2 Roland Berger Strategy Consultants GmbH, München *) 398,0 3 The Boston Consulting Group GmbH, Düsseldorf/München *) 369,0 4 Deloitte Consulting GmbH, Hannover 286,0 5 Booz & Company GmbH, Düsseldorf *) 1) 262,0 6 BearingPoint GmbH, Frankfurt am Main *) 246,0 7 Steria Mummert Consulting AG, Hamburg 239,0 8 Capgemini Consulting, Berlin 2) 231,0 9 Oliver Wyman Group, München *) 228,0 10 A.T. Kearney GmbH, Düsseldorf 209,0 11 Bain & Company Germany Inc., München 193,0 12 Droege International Group AG, Düsseldorf *) 3) 122,0 13 Horváth AG (Horváth & Partners-Gruppe), Stuttgart 83,1 14 Simon, Kucher & Partners GmbH, Bonn *) 80,7 15 Mercer Deutschland GmbH, Frankfurt am Main *) 79,5 Quelle: Lünendonk, 2009 *) Daten teilweise geschätzt ) Bis 05/2008 Booz Allen Hamilton GmbH, Veränderung durch SMC_Unternehmen_ ppt Split des Unternehmens beeinflusstt 2) Ohne Steria IT-Beratung Mummert und Systemintegration Consulting AG 3) Umsatz inkl. Erfolgshonorare

7 Das Unternehmen Kompetenz in Microsoft Technologien Steria Mummert Consulting AG Enge Microsoft Partnership Information Worker Custom Development TFS Inner Circle Partner Team System Quality Board member

8 SPALM SPALM = SharePoint ALM Architect Designer Developer Tester Durchgängiger SharePoint Entwicklungsprozess Automatisierung wiederkehrender Prozesse Nachvollziehbarkeit aller Änderungen Business Analyst Project Manager

9 SPALM SPALM = SharePoint ALM Architect Designer Developer Tester Durchgängiger SharePoint Entwicklungsprozess Automatisierung wiederkehrender Prozesse Nachvollziehbarkeit aller Änderungen Business Analyst Project Manager

10 Agenda Ausgangspunkte ALM Besonderheiten im SharePoint Umfeld Wie weit hilft eine Unterstützung durch VS 2010 Was muss man noch manuell oder automatisiert machen Deployment Quality Assurance Anforderungen Architektur Development Test

11 Agenda Anforderungen Anforderungen Deployment Architektur Quality Assurance Development Test

12 Anforderungserhebung Anforderungserhebung Ziele: Detailierte Analyse der Anforderungen Stakeholderanalyse Größtmögliche Abdeckung des strukturierten Systems, Unterschiedliche Systemrollen, Unterschiedliche organisatorische Position, Rechtliche Relevanz (Betriebsrat, Datenschutz etc.). Anforderungsanalyse Anforderungen erfassen (Workshop, Interview, Umfrage) Anforderungen verfeinern (Ist-Analyse, Gap-Analyse, angrenzende Systeme) Anforderungen konsolidieren / reviewen / abstimmen Anforderungen priorisieren (fachlich, technisch, strategisch) Spezifizieren

13 Anforderungserhebung Anforderungserhebung Besonderheiten Technisches Wissen bei Anwendern vorhanden -> Anwender formulieren häufig sehr technisch Homogenität der Plattform: Anforderungen wiederholen oder ähneln sich Generelle Anforderung: Nah am Standard Vermeidung von Zusatzentwicklung, wenn ähnliche Funktion bereits vorhanden Erleichterung einer späteren Migrierbarkeit

14 Anforderungserhebung SMC Best Practices Erhebungsmethoden Einsatz eines abstrakten Abfragerasters (z.b. Informationraster) Formulierung mit Hilfe einer Anforderungsschablone ( Das System muss dem User die Möglichkeit bieten Metadaten einzugeben. ) Funktionales Clustering der Anforderungen (z.b. Dokumenten Management, Personalisierung, Suche, Navigation etc.)

15 Anforderungserhebung RE-Erfahrungen in MOSS Projekten Klaren RE Prozess vereinbaren Frühe Beteiligung der Fachabwendern Demonstration von MOSS Standard vor Fachanwendern vereinfacht RE Prototyping schafft Transparenz der Anforderungen Design und Layout ist die halbe Miete

16 Systemsicht Anwendersicht Anforderungserhebung Best Practice: Abfrageraster Abstrakte Einordung der Anforderungen mit Hilfe des SMC Informationrasters Abfragebereich Information aufbereiten Information verwalten Information verteilen Information suchen/finden Information austauschen Information integrieren Information schützen Beschreibung Information für die Zielgruppen bearbeiten, überarbeiten und mit einem geeigneten Layout versehen. Information strukturieren und organisieren. (Hierarchie, Metadaten,..) Aufbereitete Information den Zielgruppen zur Nutzung bereitstellen. Gewünschte Information finden und nutzen. (Suche, Navigation usw.) Interaktiver Informationsaustausch zwischen Anwendern. Information mit anderen Systemen über eine technische Schnittstelle austauschen. Unberechtigten Zugriff auf Information verhindern. Information sammeln Zugriff auf Informationen protokollieren und aufbereiten

17 Anforderungserhebung Best Practise: Anforderungsschablone Abstrakte Einordung der Anforderungen mit Hilfe des SMC Informationrasters Das System muss - fähig sein <Objekt & Ergänzung des Objekts> <Prozesswort> sollte <wem?> die Möglichkeit bieten Beispiele Das System muss dem Redakteur die Möglichkeit bieten Metadaten einzugeben. Das System sollte eingegebene Metadaten abhängig vom Dokumenttyp prüfen. Das System muss fähig sein Organisationsdaten aus SAP zu importieren

18 Agenda Architektur Anforderungen Deployment Architektur Quality Assurance Development Test

19 Architektur Ziele und Besonderheiten Häufige Ziele Architektur von Lösungen, die nah am Standard sind (Vermeidung von Zusatzentwicklungen) keine Verschlechterung der Performance und Stabilität Abgrenzung zu anderen Lösungen und Reduzierung von Abhängigkeiten Besonderheiten Wiederkehrende Anforderungen müssen umgesetzt werden Viel SharePoint-Fachwissen notwendig Erfahrung wichtig: vieles, was gehen soll, geht doch nicht wie beschrieben ASP.NET Kenntnisse sehr hilfreich

20 Architektur SMC Best Practices Wiederverwendbarkeit von Lösungen ermöglichen Entwicklung im Rahmen von SharePoints Featuremodell (nicht alles in ASP.NET neu machen) Verwendung von Pattern für die Entwicklung (ServiceLocator, RepositoryPattern), analog zu Empfehlung von Microsoft Klassifizierung von Anwendungsfällen (z.b. Contentorientiert, Applikationsorientiert, Listenorientiert usw.) Testbarkeit von Lösungen ermöglichen (z.b. MVP- Pattern für Webparts)

21 Agenda Development Anforderungen Deployment Architektur Quality Assurance Development Test

22 Development Ziele Unterstützung des Entwicklers (Developer Productivity) wichtig Konformität des erstellten Codes zur Microsoft Vorgaben sicherstellen Konformität zu Unternehmensvorgaben (Aufbau der Projekte, Namenskonventionen) sicherstellen Hohe Codequalität (Performance, Stabilität) erreichen Managebarkeit der Lösung sicherstellen (zentrale Komponenten z.b. für Logging, Konfiguration usw. bereitstellen)

23 Development Besonderheiten SharePoint Code besteht aus vielen einzelnen Dateien, die untereinander referenziert sind Code besteht viel aus.xml, der häufig manuell erstellt werden muss Referenzen zwischen Artefakten läuft häufig über Guids, die vom Entwickler (mühsam) ausgelesen werden müssen Stark eingeschränkte Freiheitsgrade innerhalb SharePoint Viel Spezialwissen notwendig

24 Development Demo Vorstellung SPSF SharePoint Software Factory (Eigenentwicklung, basierend auf Microsoft Guidance Automation Extension (GAX))

25 Agenda Build Anforderungen Deployment Architektur Quality Assurance Development Test

26 Build Ziele Zentraler Build einer Lösung Erzeugung eines installierbaren Packages Ablage und Versionierung des Buildergebnisse, um es jederzeit verwenden zu können Build gegen eine Konfiguration analog zur produktiven Farm (keine zusätzlichen DLLs) Build eines Releases (keine Debug-Lösung geht produktiv) Build von den Artefakten zum installierbarem Package

27 Build Besonderheiten Erstellung eines installierbaren Packages häufig sehr aufwändig Häufige Lösung: Erstellung von Batch- Dateien, Konfigurationsdateien für Parameter und URLs u.ä. Erstellung eines MSIs meist nicht zielführend

28 Build Demo Vorstellung SPSF SharePoint Software Factory Erstellung eines Setuppackages

29 Agenda Testing Anforderungen Deployment Architektur Quality Assurance Development Test

30 Testing Ziele Hauptziel: Automatisierung von Tests Regressionstests: Funktionieren noch alle bestehenden Applikationen, wenn neue Applikationen oder ein Patch installiert werden Funktionale Tests: sind die Anforderungen des Business erfüllt Smoke Tests: Minimaler Test, um die Grundfunktionen zu testen, z.b. nach einem Deployment Performance Tests: Wie verändert sich die Performance durch Installation einer Applikation oder Veränderung der Konfiguration

31 Testing Besonderheiten Starke Homogenität von Lösungen Standardtests sind möglich, z.b. Standard TeamSite-Test: Create Subsite, Upload Document, Create List usw Wiederverwendbarkeit von Tests ist möglich SharePoint ist webbasiert Testtool muss entsprechende Funktionen von SharePoint unterstützen (z.b. AJAX, verschiedene UIs, WebDav usw.) Großes Problem: Unittests Unittests sind sehr schwierig bis unmöglich: Mocking von SharePoint-Objekten nur über Drittanbieter, z.b. TypeMock

32 Testing Demo Vorstellung: Durchführung von parametrisierbaren Webtests (basierend auf VS.NET Webtests und MSBuild/MSTest.exe)

33 Agenda Quality Assurance und Code Analyse Anforderungen Deployment Architektur Quality Assurance Development Test

34 Code Analyse Ziele einer Code Analyse Analyse des Codes, z.b. Sicherheitsverstöße (CAS- Policies, RunWith- ElevatedPrivileges) Supportability der SharePoint Farm nicht gefährden Verstöße gegen Best practices (MS-Vorgaben, Erfahrungswerte) Verstöße gegen allgemeine Vorgaben (Unterstützung von Multilanguage, Namenskonventionen)

35 Code Analyse Besonderheiten für SharePoint Entwicklungsergebnis besteht nur zu einem Teil aus C#-Code Großer Teil besteht aus XML (feature.xml, manifest.xml, usw.) Entwicklung ist verteilt auf viele einzelne Artefakten (XML, Bilder, CSS, DLL usw.) Hohe Abhängigkeit zwischen Artefakten, verteilt auf einzelne Dateien (z.b. Feature referenziert einen ContentType)

36 Code Analyse Anwendungsfälle Code Analyse unterstützt z.b. Quality Assurance (Zertifizierung einer WSP- Lösung) Prüfung auf Verwendbarkeit als Sandboxed Solutions, Prüfung auf Supportlevel (Silver, Gold, Platinum) Prüfung auf WSS oder MOSS- Abhängigkeiten Prüfung von Drittanbieterlösungen oder externen WSP

37 Code Analyse Demo Toolbasierte Code Analyse auf Basis einer Eigenentwicklung ShareCop

38 Code Analyse Code Metriken Messbarkeit von SharePoint Applikationen mit Zahlen, z.b. Anzahl von Features, Worflows, ContentTypes etc. Anzahl von externe Abhängigkeiten Anzahl von Dateien in einem WSP- Package Ziele Supportability Erkennen, ab wann wird eine Lösung nicht mehr verwaltbar

39 Code Analyse Dependency Management Verwaltung bzw. Analyse der Abhängigkeiten zwischen Applikationen und Artefakten Notwendig für Aktualisierung von Komponenten oder Deinstallation Beispiel: Feature X aus Applikation Intranet 2.0 referenziert Feature Y aus Applikation Compontents 1.0 Problem: Abhängigkeiten stehen im Code, in XML-Dateien oder sind gar nicht erkennbar (z.b. durch late binding )

40 Code Analyse Demo Toolbasierte Überprüfung von Entwicklungscode auf Basis einer Eigenentwicklung ShareLog

41 Agenda Deployment Anforderungen Deployment Architektur Quality Assurance Development Test

42 Deployment Ziele Automatisierte Verteilung einer Applikation in einer SharePoint Farm Verteilung eines Installationspakets durch mehrere Server (DEV, Staging, Produktion) Deinstallation einer Applikation soll möglich sein (möglichst spurlos) Häufig auch Deployment von Konfigurationsänderungen notwendig Test Integration Produktion

43 Deployment Besonderheiten Applikation besteht häufig aus mehreren WSPs, die deployed werden müssen Installationspaket benötigt häufig Parameter (z.b URLs für das Deployment), deshalb muss das Installationspaket parametrisierbar sein Nachträgliche Konfigurationsschritte sind notwendig, z.b. ActivateFeature, Anpassungen der Suchkonfigurationen o.ä. Bei Aktualisierung eines Applikation (z.b. Version 2.0) sind häufig sehr lang laufende Aktualisierungen notwendig (z.b. zur Aktivierung eines neues Features in allen bestehenden Webs)

44 Deployment Demo Vorstellung MSBuild Deployment Designer (Eigenentwicklung)

45 Zusammenfassung ALM ist wichtig für professionelle Entwicklung im Unternehmen Anforderungen VS 2010 ist unabdingbar für Entwicklung im Team und für große Projekte Deployment Architektur Besonderheiten von SharePoint machen durchgängiges ALM schwierig Quality Assurance Development VS.NET 2010 bringt gute Unterstützung in einigen Bereichen Test