Die IT-Abteilungen brauchen innovative und flexible Methoden, mit denen sie Anwendungssoftware entwickeln, pflegen und auf ihre Geschäftsanforderungen zuschneiden können. Traditionelle Verfahren der Softwareentwicklung kalkulieren mit relativ langen Entwicklungszeiten und hohem Ressourcenverbrauch. Dabei werden Termine häufig nicht gehalten, und/oder die Kosten ufern aus. Die Folge: Die IT verbleibt in einem reaktiven Modus und schafft keinen zusätzlichen Wert für das Unternehmensgeschäft.

Der Software-Factory-Ansatz soll deshalb den Gedanken der Industrialisierung auf die Softwareentwicklung und -pflege übertragen. Projekte zum Entwickeln und Betreuen von Anwendungssoftware werden wie Fließbandarbeit betrachtet. So können sie unter einem konstanten, planbaren Budgetrahmen abgewickelt werden. Gleichzeitig lassen sich die Entwicklungszyklen reduzieren und eine hohe Qualität erreichen.

Der wesentliche Unterschied zu den traditionellen Verfahren besteht darin, dass Zeit und Ressourcen konstant gehalten und die Entwicklungsanforderungen variabel erfüllt werden - jeweils gestaffelt nach Größe und Priorität. Dies geschieht termingerecht mit Hilfe fest zusammengesetzter Teams. Realisiert wird diese Vorgehensweise mittels des so genannten Timebox-Verfahrens, das eine iterative Softwareentwicklung erlaubt.

Fest stehen Zeit und Ressourcen

Eine Timebox wird definiert durch eine vorgegebene Zeit und Anzahl von Ressourcen, die zur Verfügung steht. Zur Umsetzung der Projekte werden die Anforderungen (Entwicklungsaufgaben) zunächst so weit in kleinere Teilanforderungen zerlegt, bis diese innerhalb einer Timebox realisiert werden können. Die Zuordnung zu den Timeboxen erfolgt über eine Priorisierung der Teilanforderungen.

Da sich in diesem Verfahren die vorgegebenen Ressourcen und die Zeit - also der Fertigstellungstermin - nicht ändern, kann es vorkommen, dass eine Anforderung in einer Timebox nicht komplett fertig gestellt werden kann. Die weitere Bearbeitung erfolgt somit in einer nachfolgenden Timebox. Daher müssen nach jeder Zeiteinheit von beispielsweise sechs Wochen die noch ausstehenden Teilanforderungen nach Wichtigkeit geordnet werden. Für größere Projekte bietet sich das Verfahren auch geschachtelt an. Dabei werden große Timeboxen in einem eigenen Projekt in kleinere zerlegt.

Anforderungen priorisieren

Der Fokus dieser Methode liegt also auf festen, planbaren Ressourcen und klaren Fertigstellungsterminen. Anforderungen sind immer wieder neu zu priorisieren. Dabei wird unterschieden zwischen:

• Must-have-Anforderungen: Essenzielle Anforderungen mit fundamentaler Bedeutung für die zu entwickelnde Software. Werden sie nicht erfüllt, funktioniert die Anwendung nicht. Diese Anforderungen definieren die Funktionen, die in jedem Fall implementiert werden müssen.

• Should-have-Anforderungen: Wichtige Anforderungen, für die es in der kurzzeitigen Implementierung zunächst aber einen Workaround gibt. Diese Anforderungen werden bei einem nicht zeitlich begrenzten Entwicklungsverfahren üblicherweise als Pflichtanforderungen klassifiziert. Jedoch funktioniert die Anwendung beziehungsweise Software auch ohne diese Anforderungen.

• Could-have-Anforderungen: Anforderungen, die ohne Probleme aus der Entwicklung herausgelassen werden können.

• Want-to-have-but-won’t-have-this-time-round-Anforderungen: Wertvolle Anforderungen, für die es jedoch eine Alternative beziehungsweise einen manuellen Ersatz gibt. Sie werden von vornherein auf spätere Entwicklungsschritte verschoben.

Diese so genannte MoSCoW-Regel - bezeichnet nach den jeweiligen Anfangsbuchstaben - ist ein wesentliches Instrument der Priorisierung für Entwicklungsarbeiten, die schnell zu einem marktfähigen Ergebnis kommen müssen. Zusammengefasst sind die wichtigsten Aspekte beim Entwicklungsverfahren in der Software Factory:

• die Zerlegung in Teilprojekte;

• Priorisierung anhand der MoSCoW-Regeln und

• iterative Entwicklung über das Timebox-Verfahren.

Geeignet ist die beschriebene Vorgehensweise nicht nur für größere Projekte (Neuentwicklungen, Migrationen und/oder Legacy-Transformation, Release-Wechsel). Sie kann auch im Rahmen der Pflege und Weiterentwicklung von Anwendungen eingesetzt werden. Auch dabei werden alle Anforderungen zunächst priorisiert und dann in Timeboxes entwickelt. Können diese nicht mit entsprechenden Aufgaben gefüllt werden, da es sich um viele kleine Anforderungen handelt, werden sie gebündelt. Dabei entstehen Releases, die dann in regelmäßigen Abständen als neues Anwendungs-Release (analog zu einer Neuentwicklung) in den Produktivbetrieb übernommen werden.

So können einerseits alle Anforderungen in kurzer Zeit produktiv geschaltet werden, andererseits wird die Betreuungsmannschaft für die jeweilige Anwendung gleichmäßig ausgelastet. Da alle Anforderungen - gegebenenfalls in einem der jeweils nachfolgenden Releases - produktiv geschaltet werden, ist eine permanente Weiterentwicklung der Anwendung in der Pflegephase gewährleistet.

Doch nicht nur die angewandten Verfahren tragen zum Erfolg einer Software Factory bei, entscheidend ist auch deren Aufbau und Organisation. Der Ablauf orientiert sich an anerkannten Methoden und Prozessen (Itil, CMMI etc.). Das Projekt-Management ist an der Methodik des Project Management Institute (PMI) ausgerichtet. Dies bedeutet unter anderem, dass die Projektteams konzentriert an einem Ort zusammenarbeiten. Kurze Kommunikationswege und effizienter Know-how-Austausch sind damit sichergestellt.

Teamarbeit ist wichtig

Bei IBM kommt hier das Konzept der Delivery Center zum Tragen. In solchen global verteilten Zentren wird eine Software Factory speziell für dedizierte Projekte eingerichtet. Sie deckt die drei Phasen Design, Build und Deploy aus dem Lebenszyklus von Anwendungen ab.

Die Entwickler arbeiten gemeinsam in Teams, die gezielt Aufgaben und Kunden zugeordnet sind. Diese Kernteams setzen sich aus Experten mit hohem fachbezogenem Wissen zusammen. Der Vorteil: Bedingt durch das vorhandene Spezialwissen ist die Einarbeitungszeit kurz. Für eine gleichmäßige Auslastung in der Software Factory sorgen flexible Teams. Sie verstärken bei Bedarf einzelne Projekte, arbeiten für unterschiedliche Kunden und sind in verschiedenen Delivery Centern tätig. Auf diese Weise können Leerlaufzeiten in der Entwicklung ausgeglichen und gering gehalten werden.

Als dritte Komponente verstärken erweiterte Teams die Mannschaft. Sie gehören globalen Delivery Centern an und agieren auch von dort. An diese erweiterten Teams werden insbesondere klar abgrenzbare Entwicklungsaufgaben gegeben, die keine Präsenz beim Kunden vor Ort erfordern und besonders kostengünstig erfolgen sollen.

Die Leistungserbringung kann demnach on-site beim Kunden, nearsite oder nearshore aus dem nächstgelegenen Delivery Center oder offshore erfolgen. Dies gewährleistet individuell auf die jeweiligen Kundenbedürfnisse abgestimmte Services mit maximaler Wertschöpfung und günstiger Kostenstruktur.

Das Modell der Software Factory hat folgende Vorteile:

• planbarer, konstanter Budgetrahmen für die (Weiter)entwicklung;

• überschaubare Größenordnungen einzelner Entwicklungspakete;

• mögliche Parallelisierung der Arbeiten bei geringerer Komplexität;

• konsequente Fokussierung auf die notwendigen Anforderungen;

• reduzierte Entwicklungszyklen und hohe Qualität.

Wird eine Software Factory im Rahmen eines Delivery-Center-Konzepts realisiert, hat dies darüber hinaus die Vorteile, dass

• Know-how und Skills durch kontinuierliche Zuordnung eingesetzter Mitarbeiter sichergestellt sind;

• eine verlässliche Budgetplanung erzielt wird;

• flexible Teams bei Bedarf um weitere Mitarbeiter mit Spezialwissen ergänzt werden können;

• das Risiko der Ressourcenauslastung nicht auf der Kundenseite liegt.

Das Konzept der Software Factory empfiehlt sich für Kunden insbesondere ab einer Projektlaufzeit von zirka drei Jahren oder einem permanenten Weiterentwicklungsaufwand für eine Mannschaft von zirka zehn Mitarbeitern. Unter diesen Randbedingungen ist das Konzept durchaus auch für Unternehmen mittlerer Größe interessant.