Standardprozesse in der Software- und Systementwicklung

Manchmal sind Entwickler so in gewohnten Methoden festgefahren, dass sie nicht merken, wie langsam es vorangeht. Dabei können neue Prozesse frischen Wind in die Systementwicklung bringen.

Anbieter zum Thema

MicroConsult Microelectronics Consulting & Training GmbH

Parasoft® Deutschland GmbH

RTI Real-Time Innovations

Method Park Software AG

Die Zeiten ändern sich – wie immer – nur etwas schneller. Die Welt, und damit auch die Produkte, werden komplexer – wie schon immer, also nichts Neues. Um den Veränderungen und zusätzlichen Anforderungen Genüge zu tun, müssen die Unternehmen ihre Entwicklungsumgebungen immer wieder erneuern.

Das hat man in vielen Unternehmen auch schon mehrmals getan. Es stellt sich nur die Frage: Kann man das Umstellen auf neue Entwicklungsumgebungen und Arbeitsmethoden zeitlich optimieren? Was können wir aus eigenen und anderen „Lessons Learned“ mitnehmen? Der folgende Artikel soll einige Lösungsansätze aufzeigen. Und nein, die Probleme liegen nicht in den technischen Details. Wir sind gelernte Fachkräfte, Techniker und Ingenieure! Die technischen Schwierigkeiten können wir immer lösen. Die Probleme liegen woanders: in der Gefahr, in einer Optimierungsschleife festzuhängen.

Bildergalerie

Veränderungen erzwingen Anpassungen

Betrachten wir folgendes Beispiel: Ein wichtiger Kunde fordert tiefere Dokumentation, die gesetzlichen Rahmenbedingungen haben sich geändert oder die eigene Geschäftsführung will die Entwicklung optimieren. Das und andere Gründe führen dazu, dass Arbeitsmethoden und Werkzeuge angepasst oder ganz ausgetauscht werden müssen.

Welche Bereiche sind von der Veränderung betroffen? Um dies zu veranschaulichen, dient als Beispiel ein Systemzulieferer: typisch deutscher Mittelstand, Marktführer in seinem Bereich, mit sich und der Welt zufrieden.

Wir produzieren komplexe Systeme in optimaler Qualität und es gibt eigentlich keinen Grund, daran etwas zu verändern. Eigentlich. Nur hat sich mittlerweile die Umgebung geändert. Unsere Kunden und gesetzliche Bestimmungen verlangen einen detaillierteren Nachweis der gelieferten Qualität. Unser hochwertiges Produkt alleine ist nicht mehr ausreichend, wir sind aufgefordert zusätzlich nachzuweisen, auf welche Weise wir dieses Produkt entwickeln. Das ist nicht so neu, wird allerdings von „Weltmarktführern“ immer noch gerne ignoriert.

Allerdings ist mittlerweile die Haftungsfrage, die der Endkunde im Schadensfall gerne wie den Schwarzen Peter im Kartenspiel an seinen Zulieferer weitergibt, oft finanziell weit wichtiger als das eigentliche Produkt. Eine umfassende ALM-Lösung (Application Lifecycle Management), die den gesamten Entwicklungsprozess abdeckt, wird benötigt. Unser Produkt muss damit nicht unbedingt besser werden, nur ist es ohne diese Dokumentation nicht mehr verkaufbar.

Das muss man persönlich nicht gut finden, es sind aber die aktuellen Spielregeln. Beachtet man die Empfehlungen zu folgenden Themen, dann lässt sich der Aufwand deutlich minimieren.

Dokumentation – ungeliebt, aber unumgänglich

Unser gesamter Produkt-Entstehungsprozess muss mitdokumentiert werden. Die Erstellung dieser Nachweise behandeln wir wie einen weiteren Teil unseres Produktes, mit eingeplanten Arbeitsaufwänden und Prüfungen, um damit die Relevanz für alle beteiligten Personen zu unterstreichen.

Eine weitere Frage ist: Wer soll Wann diese Dokumentation erstellen? Und damit indirekt: Wo fallen die Kosten dafür an? Klassische Lösungen mit getrennten Abteilungen und Silo-Denken sehen zwar kurzfristig einfach aus, verhindern aber jegliche Zusammenarbeit. Gleichzeitig wird das Reporting sehr aufwändig und ist niemals up-to-date. Deswegen arbeiten wir in einem großen Team und haben nur gemeinsame Aufgaben. Die Dokumentation wird von unseren Spezialisten selbst, direkt während des Abarbeitens ihrer Fachaufgabe, durchgeführt. Punkt. Erster Aufschrei. Berechtigt.

Change Management – Wie holt man die Mitarbeiter ins Boot?

Was nun? Das meist unterschätzte und immer vernachlässigte Thema: Change Management. Wir müssen und wollen unsere Mitarbeiter mitnehmen und motivieren. Das geht nur über offene Kommunikation. Da sich viel ändert, ist auch viel Kommunikation nötig. Wir sagen unseren Kollegen offen und etwas ausführlicher als hier dargestellt: „Wegen der Änderungen im Umfeld müssen wir dies und das verändern und manches zusätzlich tun. Das möchten wir mit Euch allen gemeinsam machen. Ja, dabei werden sich Tätigkeiten und Jobs ändern. Und ganz wichtig, die bisherige Arbeitsweise war gut für die bisherigen Anforderungen, aber jetzt brauchen wir einen neuen Ansatz.“

Zum Change Management gehört natürlich noch viel mehr: Begründung, Motivation, Umstiegshilfen, Training – das volle Programm. Umstellungen scheitern nicht an den technischen Problemen, sie scheitern an mangelnder Projektdurchführung und an Menschen, die nicht richtig eingebunden werden. Wie viel Aufwand wir dafür auch immer einplanen werden, im Nachhinein betrachtet werden wir feststellen, mehr wäre besser und effektiver gewesen.

Richtlinien festlegen – Compliance out-of-the Box

Gemäß der an die eigenen Unternehmens- oder Abteilungswünsche angepassten Best-Practice-Arbeitsweise ist es für Systemhersteller üblich, diese zusätzlichen Richtlinien manuell in ihre bestehenden Prozesse einzubringen. Die Entwicklung der Prozesse und Arbeitsmethoden gehört jedoch weder zum Kerngeschäft noch zum Know-how der Unternehmen. Deswegen wird der Aufwand für Erarbeitung und Test dieser Anpassung fast immer erheblich unterschätzt.

Nicht, dass wir so etwas nicht könnten. Aber immer alles selbst zu machen, ist nicht besonders effizient. Jeder selbstdefinierte Prozess muss entwickelt, im Werkzeug eingerichtet, getestet, korrigiert und beschrieben werden. Erfahrungsgemäß nimmt dies bis zu Dreiviertel der Einführungszeit in Anspruch.

Für fast alle Industriebereiche gibt es sehr gute, vordefinierte Vorlagen und Umsetzungen in den Werkzeug-Templates, wie zum Beispiel Automotive SPICE und die ISO 26262 für sicherheitskritische Bereiche im Automotive Umfeld. Das gleiche gilt für Luft- und Raumfahrt, Schienenverkehr und Medizintechnik, wie etwa die IEC 62304 für Medizingeräte-Software. Damit muss man Prozesse und Methoden nicht mehr selbst entwickeln.

Die Einführung von Entwicklungsprozessen ist bedeutend schneller umzusetzen, wenn vorgefertigte Werkzeug-Templates verwendet werden. Und die eingesparte Entwicklungszeit bei dieser Template-Empfehlung multipliziert sich mit allen beteiligten Arbeitsdomänen unserer ALM-Lösung: Requirement, Architecture, Test, Configuration, Task und Change Management.

Für die Anpassung der Arbeitsmethoden und Werkzeug-Templates gilt: reduzieren gerne, erweitern nur, wenn es wirklich unbedingt sein muss. Für jeden zusätzlichen Prozessschritt oder jedes weitere Attribut muss ein „Sponsor“ bereitstehen, der den Schritt ausführt, protokolliert oder die Information im Attribut pflegt. Wenn sich niemand für die Datenpflege bereit erklärt, ist diese Information unwichtig. Ein externer Prozess-Spezialist ohne unsere internen Scheuklappen ist hierbei durchaus hilfreich.

Schreib- und Leserechte – Wer darf Wo Was tun?

Wir führen eine kurze Diskussion um veraltetes Silo-Denken und stellen fest: Am einfachsten ist es im Zeitalter der Collaboration, wenn jeder alles lesen darf. Das Prozessmodell gibt die ToDo-Rollen vor und im Template sind diese analog vorhanden, das übernehmen wir gerne.

Ein kurzer Satz zu Varianten: Deren Verwaltung ist extrem aufwändig. Deswegen lassen wir das zunächst einmal bleiben. Nur dann, wenn es wirklich nötig ist, werden wir sehr professionelles Variantenmanagement betreiben.

Desweiteren überzeugen wir unsere verschiedenen Unternehmensbereiche davon, sich auf eine einheitliche Arbeitsweise zu einigen – auch das spart Zeit und funktioniert. Punkt. Nächster Aufschrei. Reaktion siehe oben.

Anforderungsmanagement – Traceability mit Struktur

Praktisch alle modernen Prozessmodelle fordern eine durchgängige Verlinkung von den Anforderungen zu den Architekturmodellen, Testfällen und Software- oder Systemkomponenten. Wir benötigen ein „Spinnennetz“, das sich über unser Informationsmodell spannt, aber mit Struktur.

Praxisauszug Anforderungsmanagement und deren Schnittstellen: Wir sind Automobilzulieferer. Also ist Automotive SPICE bei uns gesetzt. Wie bei allen auf dem V basierenden Modellen gibt es hier empfohlene Ebenen für Anforderungen. Die übernehmen wir so, wie sie im Model definiert sind. Das gleiche gilt für alle weiteren Arbeitsdomänen, wir haben keine Zeit das Rad neu zu erfinden. Die Vorteile sind: in der Praxis erprobt, schnell kopiert oder schon in Templates vorhanden und out-of-the Box für Audits verwendbar.

Wo wird Welche Information abgelegt? Besser ist, wir teilen die Informationen auf. Zu einer Anforderung gehören nur deren direkte Informationen, nicht der Test und auch nicht der Umsetzungsauftrag an die Entwickler. Damit machen wir unser Informationsmodel unabhängiger und können die Daten leichter wiederverwenden. Eine Anforderung kann so eine 1-n Beziehung zu mehreren Testfällen haben. Die Anforderung dagegen können wir zu 100 Prozent für ähnliche Produkt wiederverwenden. Der Umsetzungsauftrag ist dagegen für eine Produktentwicklung abgearbeitet, quasi verbraucht.

Die aufgesplitteten Informationseinheiten müssen allerdings miteinander verknüpft werden. Wenn unsere gesamte Entwicklung in einem geschlossenen, großen Werkzeugkasten liegt, lässt sich eine Anforderung einfach mit einer weiteren in der nächsten Ebene verlinken und ebenso mit dem zugehörigen Testfall.

Tool-Auswahl – Das richtige Werkzeug zum richtigen Zweck

Für den Prozess ist die Umsetzungsmethode frei wählbar, auch Papier und Bleistift, Stecknadeln und Bindfaden sind erlaubt. Wir wollen aber effizient arbeiten. Unsere Dokumentation soll die Arbeit übersichtlicher machen und nicht behindern. Deswegen brauchen wir eine gute Werkzeugkette mit einem Template für Systems Engineering und zum Beispiel Automotive SPICE. Eine Option ist ein großes Werkzeug, das alle ALM-Bereiche abdeckt und meist eine 80/20 Lösung zulässt – das ist für uns ausreichend und schnell eingerichtet.

Brauchen wir dagegen eine bzw. mehrere Schnittstellen nach außen oder verwenden wir einzelne Werkzeuge für die unterschiedlichen Arbeitsdomänen, wird es aufwändiger. Unsere Daten müssen miteinander kommunizieren können. OSLC (Open Service for Lifecycle Collaboration) ist mittlerweile zu einem beliebten Industriestandard herangewachsen. Haben beide Seiten eine OSLC-Schnittstelle, ist nicht nur die Integration schnell installiert, auch das User-Interface wird mitgeliefert, danke.

Vorsicht, nicht ganz so schnell: OSLC hat verschiedene Dialekte, für jede Arbeitsdomäne einen anderen. Es gibt je einen für Anforderung zu Anforderung, Anforderung zu Architektur-Element, Anforderung zu Testfall und so weiter.

Reporting – Wer bekommt Wann Was, und Wie?

Meist zu spät kümmert man sich jedoch um das Reporting. Deswegen drehen wir eine weitere Runde und fragen: Wem müssen wir Welche Daten Wie aufbereitet liefern? Den Kollegen für die nächsten Arbeitsschritte, unserem Projektleiter, der Geschäftsführung und unserem Kunden. Die Schlauen setzen das Reporting ganz an den Anfang, da dieses Thema entscheidenden Einfluss auf das Informationsmodell hat.

Wie aufwändig darf das Reporting sein? Eine Lösung, bei der die Reports und die Dokumentation auf Knopfdruck aus dem System generiert werden, wäre schon sehr praktisch und würde viel bei der täglichen Arbeit einsparen. Wenn wir aus den Reports heraus dann auch über eine Art klickbare Dashboard-Ansicht direkt weiterarbeiten können – noch besser.

Bei der „Alles aus einer Box“-Lösung sollte das einfach zu realisieren sein. Sind die Daten dagegen über mehrere Werkzeuge verteilt, empfehlen sich Anbieter von OSLC-Plattformen. Hier können alle Informationseinheiten in einem gemeinsamen Daten-Container abgelegt werden und sind so über eine zentrale Stelle für Reports auswertbar.

Pilot und Roll-out – Fertig für den Produktlaunch

Nachdem das ganze System aufgesetzt worden ist und man es mit Hilfe eines Piloten optimiert hat, können wir es schrittweise ausrollen. Damit die Umstellung möglichst reibungslos abläuft, werden wir zusätzlich in Training und Coaching investieren. Unsere Mitarbeiter sollen ja weiterhin unsere Produkte produzieren und nicht selbst herausfinden müssen, wie die neue Arbeitsumgebung funktioniert.

Eine ausführliche Beschreibung der Arbeitsmethoden und Werkzeugbedienung ist dafür sehr hilfreich. Da wir eine bekannte Prozess-Schablone und ein bestehendes Werkzeug-Template verwendet haben, dürfte diese Beschreibung schon vorhanden sein.

Mit dieser Einstellung kann man schnell sehr weit kommen, Unternehmen müssen jedoch ihre Scheuklappen ablegen und akzeptieren: Es gibt unterschiedliche Entwicklungsprozesse. Faszinierenderweise funktionieren alle davon: unser bisheriger, aber andere ebenso. Und auch unser Zukünftiger wird es tun.

Fazit – Immer die Ressourcen im Auge behalten

Nein, die Umsetzung einer umfassende ALM-Lösung ist nicht auf zweieinhalb Seiten erledigt. Aber ja, mit der Reduzierung auf das Nötigste, einer durchdachten Werkzeugauswahl und dem konsequenten Einsatz vorgefertigter Templates kann die Lösung sehr effizient erreicht werden.

Unternehmen müssen erkennen, dass sie sich ihre Arbeit sehr erleichtern und effizienter gestalten, wenn sie die Arbeitsweise vereinheitlichen und auf Standards zurückgreifen. Fangen sie an, Musterprozesse, -methoden und -werkzeuge an ihre ganz spezifischen Bedürfnisse anzupassen oder sogar komplett selbst zu entwickeln, dann laufen sie Gefahr, in einer endlosen Optimierungsschleife festzuhängen. Dies bindet unnötig interne Ressourcen, die im Projektalltag dann nicht verfügbar sind und die Fertigstellung der Produkte verzögern. Oder andersherum: Der Prozess wird nie zu Ende definiert, da die Spezialisten wegen ihrer hohen Auslastung dafür keine Zeit haben. Tayloring ist nur eine Option, kein Muss.

Und last but not least: Immer an das Change Management denken!

Change-Management: Was Unternehmen falsch machen, wenn sie agil sein wollen

Alptraum Legacy Code – Wie Profis damit umgehen

Dieser Beitrag ist erschienen im Sonderheft Embedded Softwar Engineering der ELEKTRONIKPRAXIS (Download PDF)

* Robert Genzinger ist Senior Consultant und Trainer bei Method Park in München.

(ID:46165614)