MOSS Development Prozess auf Basis der SPALM Vorgehensweise

 www.steria-mummert.de

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

© Steria Mummert Consulting AG

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

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


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


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


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

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

SPALM

 SPALM = SharePoint ALM

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


 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


 Agenda

Anforderungen
Anforderungen

Deployment Architektur

Quality
Development
Assurance

Test


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


 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



 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


 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



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



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


 Agenda

Architektur
Anforderungen


Quality
Development
Assurance

Test


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


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)


 Agenda

Development
Anforderungen


Quality
Development
Assurance

Test


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)


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


Development

 Demo

Vorstellung „SPSF
SharePoint Software
Factory“ (Eigenentwicklung,
basierend auf Microsoft
Guidance Automation
Extension (GAX))


 Agenda

Build
Anforderungen


Quality
Development
Assurance

Test


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


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


Build

 Demo

Vorstellung „SPSF SharePoint
Software Factory“
Erstellung eines Setuppackages


 Agenda

Testing
Anforderungen


Quality
Development
Assurance

Test


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


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


Testing

 Demo

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


 Agenda

Quality Assurance und
Anforderungen
Code Analyse

Quality
Development
Assurance

Test


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)


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)


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


Code Analyse

 Demo

Toolbasierte Code Analyse auf Basis einer
Eigenentwicklung „ShareCop“


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


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


Code Analyse

 Demo

Toolbasierte Überprüfung von
Entwicklungscode auf Basis einer
Eigenentwicklung „ShareLog“


 Agenda

Deployment
Anforderungen


Quality
Development
Assurance

Test


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

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)


Deployment

 Demo

Vorstellung
MSBuild Deployment
Designer (Eigenentwicklung)


 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


MOSS Development Prozess auf Basis der SPALM Vorgehensweise

Weitere ähnliche Inhalte

Empfohlen

MOSS Development Prozess auf Basis der SPALM Vorgehensweise