MOSS Development Prozess auf Basis der SPALM Vorgehensweise

1.490 Aufrufe

Veröffentlicht am

SPALM - SharePoint Applikation Lifecycle Management - ist ein bei Steria Mummert Consulting entwickeltes Prozessmodell zur effizienten SharePoint Entwicklung. SPALM wird unterstützt durch verschiedene von Steria Mummert Consulting erstellte Tools wie SharePoint Software Factory (SPSF) und SharePoint Cop (SPCop). Der Vortrag vermittelt praktische Erfahrungen bei der Entwicklung mit Microsoft Team Foundation Server, Visual Studio und SharePoint und zeigt auf, wie SPALM zur Standardisierung von Methoden und Tools beitragen kann.
Autor: Torsten Mandelkow, Steria Mummert

Veröffentlicht in: Technologie
0 Kommentare
0 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Keine Downloads
Aufrufe
Aufrufe insgesamt
1.490
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
26
Aktionen
Geteilt
0
Downloads
19
Kommentare
0
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

MOSS Development Prozess auf Basis der SPALM Vorgehensweise

  1. 1.  www.steria-mummert.de SPALM - SharePoint Application Lifecycle  Management Praxisbeispiele für durchgängige SharePoint Entwicklungsprozesse © Steria Mummert Consulting AG
  2. 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: torsten.mandelkow@steria-mummert.de  www.steria-mummert.de 21.01.2010 3 © Steria Mummert Consulting AG
  3. 3. Das Unternehmen  Steria: Beratung, IT- und Outsourcing Services Belgien Dänemark Präsenz in Deutschland 16 Ländern ... Frankreich Hongkong Präsenz in Europa Indien Luxemburg Marokko Norwegen Österreich Vor Ort in Polen Off-/Nearshore in Asien Singapur Indien, Osteuropa Spanien und Schweden Marokko Schweiz UK  www.steria-mummert.de 21.01.2010 4 © Steria Mummert Consulting AG
  4. 4. Das Unternehmen  Ein Top 10 Player in Europa 1,8 Mrd. € Umsatz (Top 10 in Europa) 19.000 Mitarbeiter in Europa Präsenz 25% Mitarbeiter in Indien (größter Anteil für ein europäisches Unternehmen) Vor Ort in Off-/Nearshore in Asien Indien, Osteuropa und Marokko  www.steria-mummert.de 21.01.2010 5 © Steria Mummert Consulting AG
  5. 5. Das Unternehmen  Leistungsstarke, kundennahe Organisation Präsenz in Deutschland und Österreich… Präsenz in Europa Berlin Düsseldorf Frankfurt Hamburg Köln Vor Ort in Leipzig Off-/Nearshore in Asien München Indien, Osteuropa Münster und Wien Marokko  www.steria-mummert.de 21.01.2010 6 © Steria Mummert Consulting AG
  6. 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 1) Bis 05/2008 Booz Allen Hamilton GmbH, Veränderung SMC_Unternehmen_20091202.ppt  www.steria-mummert.de 21.01.2010 7 durch Split des Unternehmens beeinflusstt 2) OhneSteria Mummert Consulting AG © IT-Beratung und Systemintegration 3) Umsatz inkl. Erfolgshonorare
  7. 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  www.steria-mummert.de
  8. 8. SPALM  SPALM = SharePoint ALM  Durchgängiger SharePoint Entwicklungsprozess Designer Developer  Automatisierung wiederkehrender Architect Tester Prozesse  Nachvollziehbarkeit aller Änderungen Business Project Analyst Manager  www.steria-mummert.de 21.01.2010 9 © Steria Mummert Consulting AG
  9. 9. SPALM  SPALM = SharePoint ALM  Durchgängiger SharePoint Entwicklungsprozess Designer Developer  Automatisierung wiederkehrender Architect Tester Prozesse  Nachvollziehbarkeit aller Änderungen Business Project Analyst Manager  www.steria-mummert.de 21.01.2010 10 © Steria Mummert Consulting AG
  10. 10.  Agenda Ausgangspunkte ALM Anforderungen  Besonderheiten im SharePoint Umfeld  Wie weit hilft eine Deployment Architektur Unterstützung durch VS 2010  Was muss man noch manuell oder automatisiert Quality machen Development Assurance Test  www.steria-mummert.de 21.01.2010 11 © Steria Mummert Consulting AG
  11. 11.  Agenda Anforderungen Anforderungen Deployment Architektur Quality Development Assurance Test  www.steria-mummert.de 21.01.2010 12 © Steria Mummert Consulting AG
  12. 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  www.steria-mummert.de 21.01.2010 13 © Steria Mummert Consulting AG
  13. 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  www.steria-mummert.de 21.01.2010 14 © Steria Mummert Consulting AG
  14. 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.)  www.steria-mummert.de 21.01.2010 15 © Steria Mummert Consulting AG
  15. 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  www.steria-mummert.de 21.01.2010 16 © Steria Mummert Consulting AG
  16. 16. Anforderungserhebung  Best Practice: Abfrageraster  Abstrakte Einordung der Anforderungen mit Hilfe des SMC Informationrasters Abfragebereich Beschreibung Information aufbereiten Information für die Zielgruppen bearbeiten, überarbeiten und mit einem geeigneten Layout versehen. Anwendersicht Information verwalten Information strukturieren und organisieren. (Hierarchie, Metadaten,..) Information verteilen Aufbereitete Information den Zielgruppen zur Nutzung bereitstellen. Information suchen/finden Gewünschte Information finden und nutzen. (Suche, Navigation usw.) Information austauschen Interaktiver Informationsaustausch zwischen Anwendern. Information integrieren Information mit anderen Systemen über eine technische Systemsicht Schnittstelle austauschen. Information schützen Unberechtigten Zugriff auf Information verhindern. Information sammeln Zugriff auf Informationen protokollieren und aufbereiten.  www.steria-mummert.de 21.01.2010 17 © Steria Mummert Consulting AG
  17. 17. Anforderungserhebung  Best Practise: Anforderungsschablone  Abstrakte Einordung der Anforderungen mit Hilfe des SMC Informationrasters - muss <Objekt & Das fähig sein Ergänzung des <Prozesswort> System Objekts> 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.  www.steria-mummert.de 21.01.2010 18 © Steria Mummert Consulting AG
  18. 18.  Agenda Architektur Anforderungen Deployment Architektur Quality Development Assurance Test  www.steria-mummert.de 21.01.2010 19 © Steria Mummert Consulting AG
  19. 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  www.steria-mummert.de 21.01.2010 20 © Steria Mummert Consulting AG
  20. 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)  www.steria-mummert.de 21.01.2010 21 © Steria Mummert Consulting AG
  21. 21.  Agenda Development Anforderungen Deployment Architektur Quality Development Assurance Test  www.steria-mummert.de 21.01.2010 22 © Steria Mummert Consulting AG
  22. 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)  www.steria-mummert.de 21.01.2010 23 © Steria Mummert Consulting AG
  23. 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  www.steria-mummert.de 21.01.2010 24 © Steria Mummert Consulting AG
  24. 24. Development  Demo Vorstellung „SPSF SharePoint Software Factory“ (Eigenentwicklung, basierend auf Microsoft Guidance Automation Extension (GAX))  www.steria-mummert.de 21.01.2010 25 © Steria Mummert Consulting AG
  25. 25.  Agenda Build Anforderungen Deployment Architektur Quality Development Assurance Test  www.steria-mummert.de 21.01.2010 26 © Steria Mummert Consulting AG
  26. 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  www.steria-mummert.de 21.01.2010 27 © Steria Mummert Consulting AG
  27. 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  www.steria-mummert.de 21.01.2010 28 © Steria Mummert Consulting AG
  28. 28. Build  Demo Vorstellung „SPSF SharePoint Software Factory“ Erstellung eines Setuppackages  www.steria-mummert.de 21.01.2010 29 © Steria Mummert Consulting AG
  29. 29.  Agenda Testing Anforderungen Deployment Architektur Quality Development Assurance Test  www.steria-mummert.de 21.01.2010 30 © Steria Mummert Consulting AG
  30. 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  www.steria-mummert.de 21.01.2010 31 © Steria Mummert Consulting AG
  31. 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  www.steria-mummert.de 21.01.2010 32 © Steria Mummert Consulting AG
  32. 32. Testing  Demo Vorstellung: Durchführung von parametrisierbaren Webtests (basierend auf VS.NET Webtests und MSBuild/MSTest.exe)  www.steria-mummert.de 21.01.2010 33 © Steria Mummert Consulting AG
  33. 33.  Agenda Quality Assurance und Anforderungen Code Analyse Deployment Architektur Quality Development Assurance Test  www.steria-mummert.de 21.01.2010 34 © Steria Mummert Consulting AG
  34. 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)  www.steria-mummert.de 21.01.2010 35 © Steria Mummert Consulting AG
  35. 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)  www.steria-mummert.de 21.01.2010 36 © Steria Mummert Consulting AG
  36. 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  www.steria-mummert.de 21.01.2010 37 © Steria Mummert Consulting AG
  37. 37. Code Analyse  Demo Toolbasierte Code Analyse auf Basis einer Eigenentwicklung „ShareCop“  www.steria-mummert.de 21.01.2010 38 © Steria Mummert Consulting AG
  38. 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  www.steria-mummert.de 21.01.2010 39 © Steria Mummert Consulting AG
  39. 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“)  www.steria-mummert.de 21.01.2010 40 © Steria Mummert Consulting AG
  40. 40. Code Analyse  Demo Toolbasierte Überprüfung von Entwicklungscode auf Basis einer Eigenentwicklung „ShareLog“  www.steria-mummert.de 21.01.2010 41 © Steria Mummert Consulting AG
  41. 41.  Agenda Deployment Anforderungen Deployment Architektur Quality Development Assurance Test  www.steria-mummert.de 21.01.2010 42 © Steria Mummert Consulting AG
  42. 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  www.steria-mummert.de 21.01.2010 43 © Steria Mummert Consulting AG
  43. 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)  www.steria-mummert.de 21.01.2010 44 © Steria Mummert Consulting AG
  44. 44. Deployment  Demo Vorstellung MSBuild Deployment Designer (Eigenentwicklung)  www.steria-mummert.de 21.01.2010 45 © Steria Mummert Consulting AG
  45. 45.  Zusammenfassung  ALM ist wichtig für professionelle Anforderungen Entwicklung im Unternehmen  VS 2010 ist Deployment Architektur unabdingbar für Entwicklung im Team und für große Projekte  Besonderheiten von SharePoint machen durchgängiges ALM Quality Development Assurance schwierig  VS.NET 2010 bringt gute Unterstützung in Test einigen Bereichen  www.steria-mummert.de 21.01.2010 46 © Steria Mummert Consulting AG

×