SharePoint-Entwicklung mit Application Lifecycle Management unterstützen

Microsofts SharePoint Server (MOSS) erfreut sich seit Version 2007 als Entwicklungsplattform zunehmender Beliebtheit. Das aktuelle Release 2010 wird den Trend in den Unternehmen fortsetzen. Vor allem wegen seiner großen Flexibilität stehen dem Entwickler viele Optionen zur Anpassung und Erweiterung zur Verfügung. Die Funktionsfülle kann allerdings schnell zur Bremse werden. Das SharePoint Application Lifecycle Management (SPALM) mag hierbei Abhilfe schaffen.

Professionelle SharePoint-Entwicklung bedeutet nicht nur, das .NET-Objektmodell zu kennen. Gleichzeitig erfordert es umfassendes Wissen über die hauptsächlich in XML definierten SharePoint Konfigurationsstrukturen. Bevor Entwickler mit ihrer eigentlichen Arbeit beginnen, erwartet sie zunächst ein Rattenschwanz an Vorarbeit, um das Projekt einzurichten und in SharePoint zum Laufen zu bringen. Diese Komplexität lässt sich teilweise aufbrechen. Die Schlüssel heißen Automatisierung, Standardisierung, ein kontrollierter Entwicklungsprozess und regelmäßige Qualitätskontrolle.

Schaut man sich die Entwicklung von SharePoint-Applikationen genauer an, sind jedoch große Lücken im Prozess zwischen den Anforderungen und dem Ergebnis einer Anwendung zu entdecken. Im Austausch beispielsweise mit ALM-Spezialisten stellt man fest, dass der SharePoint-Entwickler im besten Fall eine Versionsverwaltung nutzt. Es fehlen einheitliche Entwicklungsstandards, automatisierte Installations- und Staging-Mechanismen sowie automatisches Testen. Selbst eine kontinuierliche Qualitätskontrolle von SharePoint-spezifischen Regeln sind mühsam manuell durchzuführen und erfordern umfassendes technisches Know-how.

Aus diesen Beobachtungen heraus entstand das SharePoint Application Lifecycle Management (SPALM), ein bei Steria Mummert Consulting entwickeltes Prozessmodell zur SharePoint-Entwicklung. Den Prozess setzen bereits kleine und große Unternehmen in unterschiedlichen Branchen für die Entwicklung von SharePoint-Projekten ein.

Durchgehender Prozess

Die Eckpunkte von SPALM sind ein durchgängiger SharePoint-Entwicklungsprozess, die Etablierung und Automatisierung wiederkehrender Prozesse sowie die Nachvollziehbarkeit aller Änderungen. Die Idee dahinter ist, die klassischen ALM-Rollen Projektleiter und Business-Analyst, Softwarearchitekt und Entwickler sowie Tester und Administrator in Microsofts Team Foundation Server (TFS) auch für die SharePoint-Entwicklung zusammenzubringen. Das methodische Vorgehen unterstützt SPALM zudem operativ mit eigenen Tools. Dazu gehören die SharePoint Software Factory (SPSF), ShareCop für die Code- und ShareLog für die Architekturanalyse.

So wird allgemein üblich ein klassischer ALM-Prozess dargestellt (Abb. 1).

Anforderungsmanagement und Architektur als Basis

Betrachtet man die einzelnen ALM-Schritte genauer, ist zu erkennen, dass die Besonderheiten von SharePoint ein durchgängiges ALM erschweren. Es beginnt eigentlich wie gewohnt. Erst wird ermittelt, welche Personen bei einem SharePoint-Projekt beteiligt sind. Darauf folgt die Aufnahme der fachlichen Anforderungen. Eine Eigenheit bei SharePoint ist, dass die Stakeholder oftmals über ein Basiswissen im SharePoint-Umfeld verfügen. Die Anwender haben häufig schon mal den Begriff Content Type gehört, oder sie wissen, was ein Web Part kann. Das führt dazu, dass sie Anforderungen nicht fachlich, sondern technisch erstellen. Im Ergebnis formulieren die User bereits die technische Umsetzung, ohne genau zu wissen, ob sie später so funktioniert.

Darüber hinaus ist SharePoint eine homogene Plattform. Es fällt auf, dass Anforderungen sich stark wiederholen oder ähnlich ablaufen: Jeder formuliert diese zwar ein wenig anders, im Kern geht es aber immer um die Verarbeitung von Informationen.

SPALM wendet erprobte Methoden der Anforderungsanalyse und Beschreibung an. Ein sich am Lebenszyklus von Informationen orientierendes Abfrageraster hilft für die richtige Einordnung der Anforderung. Der Stakeholder gibt vor, ob er Informationen beispielsweise erfassen, verarbeiten, an eine Zielgruppe verteilen will oder ob es etwa um das Auffinden von Daten geht. Dadurch lassen sich Anforderungen einfach, projektunabhängig erfassen, kategorisieren, und man erkennt schnell die Ähnlichkeiten.

Anschließend werden die Anforderungen je nach Projektvorgehen in einer einheitlichen Syntax formuliert – zum Beispiel mit User Stories. Die Anforderungen lassen sich dazu im Team Foundation Server verwalten.

Verwaltung der Anforderungen im Team Foundation Server 2010 (Abb. 2)

Die Bearbeitung der Anforderungen erfolgt über Excel (Abb. 3).

Beim Erstellen von Architekturen sind Ergebnisse gefragt, die etabliert sind, sich dadurch gut warten und leicht auf der Plattform einführen lassen. Teure Zusatzentwicklungen will jedes Unternehmen vermeiden. Viele Firmen nutzen für in vielen Projekten wiederholt eingesetzte Funktionen eine Basiskomponente, zum Beispiel Log4net für das Logging.

Erst langsam halten Entwurfsmuster Einzug in die SharePoint-Entwicklung. Beispiele sind ServiceLocator, das Repository Pattern oder auch Passive View und Supervising Presenter Patterns für Web Parts. SPALM unterstützt den Entwickler mit Referenzarchitekturen und -implementierungen und definiert Kodierungsvorgehen, Implementierungsrichtlinien und Namenskonventionen. Dadurch ermöglicht es einheitlich strukturierte und implementierte SharePoint-Entwicklungen, die die Weiterentwicklung und Wartung erleichtern sollen.