Software-Entwicklung gemäß IEEE/ISO/IEC-Standard Software-Lebenszyklus nach Standard 12207:2017

Hinter dem Titel „Systems and Software Engineering – Software Life Cycle Processes“ verbirgt sich der IEEE-Standard 12207. Das Dokument schafft ein gemeinsames Rahmenwerk für Software-Lebenszyklus-Prozesse mit genau definierten Begriffen.

Anbieter zum Thema

PresseBox - unn | UNITED NEWS NETWORK GmbH

FIS Informationssysteme und Consulting GmbH

Der Standard ISO/IEC/IEEE 12207:2017 definiert eine umfassende Reihe von Prozessen, die den gesamten Lebenszyklus eines Softwaresystems abdeckt. Dabei bleibt vom ersten Konzept bis zur Stilllegung der Software nichts unberücksichtigt.

Der Standard legt eine Reihe von Prozessen fest, die sich wiederum aus Aktivitäten zusammensetzen. Diese bestehen wiederum aus Aufgaben. Die Prozesse können als Grundlage für das Erstellen von wirtschaftlichen Umgebungen dienen, so etwa Methoden, Prozeduren, Techniken, Werkzeugen und geschultes Personal.

Der Anhang A des kostenpflichtigen Dokuments (Nichtmitglieder zahlen 145 US-Dollar) stellt eine normgebende Anweisung für das fachgerechte Zuschneiden dieser Software-Lifecycle-Prozesse zur Verfügung. Die Prozesse lassen sich grob in drei Kategorien unterteilen:

• Primäre Lifecycle-Prozesse,

• Unterstützende Lifecycle-Prozesse und

• Organisatorische Lifecycle-Prozesse

Der Standard 12207:2017 lässt sich auf den Erwerb von System- und Softwareprodukten und -Services anwenden. Er deckt aber auch Lieferung, Entwicklung, Betrieb, Wartung und Pflege sowie die Stilllegung von Softwareprodukten und den Software-Teil eines Systems ab, ganz gleich ob sie inner- oder außerhalb einer Organisation ausgeführt wird. Zum Begriff „Software“ wird auch der Software-Teil von Firmware gezählt.

Die Prozesskategorien

• 1. Zu den Primären Lifecycle-Prozessen zählen: Akquise, Lieferung, Entwicklung, Betrieb, Wartung und Pflege.

• 2. Unterstützende Lifecycle-Prozesse sind: Auditierung, Konfigurationsmanagement, Gemeinsame Prüfung, Dokumentation, Qualitätssicherung, Problembehebung, Verifizierung und Validierung.

• 3. Organisatorische Lifecycle-Prozesse sind: Management, Infrastruktur, Verbesserung, Schulung.

Der Entwicklungsprozess umfasst mehrere Prozesse, die innerhalb des DevOps-Paradigmas, das nach dem Prinzip der „Continuous Delivery“ arbeitet, zunehmend Bedeutung erlangen. An dieser Stelle soll keine bestimmte Entwicklungsmethode befürwortet werden, beispielhaft seien genannt: Agile Unified Process (AUP), dessen Nachfolger Disciplined Agile Delivery (DAD), das Scaled Agile Framework (SAFe) oder auch Large Scale Scrum (LeSS).

Zu den allgemeinen Praktiken des Software Development Lifecycle laut Standard 12207:2017 gehören u.a.

• Application Lifecycle Management (ALM),

• Application Release Automation (ARA),

• Continuous Configuration Automation (CCA),

• Continuous Integration (CI) und

• Configuration Management (s.o. unter Punkt 2).

Für einen professionellen DevOps-Nutzer ist es von Vorteil, diese Kategorien und ihre Prozesse zu kennen.

Application Lifecycle Management

ALM umfasst den Produktlebenszyklus von Programmen hinsichtlich Entwicklung, Governance und Wartung. Er umfasst Anforderungsmanagement, Softwarearchitektur, Programmierung, Testen, Wartung und Pflege, Change Management, Continuous Integration, Projektmanagement und Release Management. ALM erstreckt sich also über die Phasen des Software Developments hinaus bis zur Stilllegung der Software und kann mehrere SDLCs (Systems Development Life Cycles) umspannen. Diese Komponenten werden vollkommen vom IEEE-Standard 12207-2017 und seinen diversen Anhängen abgedeckt (s.o.).

Application Release Automation

Tools für Application Release Automation (ARA) sind ein fester Bestandteil der Continuous Delivery Toolchain. Application Release Automation (ARA) bezeichnet laut Wikipedia.org den Prozess des Verpackens und Bereitstellens einer fertigen Applikation oder ihres Updates durch die Entwicklungsabteilung. Dies erfolgt über verschiedene IT-Umgebungen hinweg und führt schließlich zu Inbetriebnahme der App oder ihres Updates.

Um ihre Aufgabe erfüllen zu können, müssen ARA-Werkzeuge mehrere Fähigkeiten aufweisen, die über die reine Entwicklung hinausgehen, aber Teil des DevOps-Zyklus sind. Gemäß der Definition der Forrester Group müssen ARA-Tools, die in die Continuous Delivery eingebunden sind, gewisse Mindestanforderungen erfüllen.

Dazu gehört zunächst die Integration mit Tools für Continuous Integration (CI). Darunter ist die Praxis zu verstehen, Quellcode mehrmals pro Tag in ein gemeinsames Repository einzuchecken und ihn jedes Mal zu testen.

Continuous Configuration Automation

Tools für Continuous Configuration Automation (CCA) sind Teil der DevOps-Toolchain. Mit CCA wird insbesondere die Konfiguration von Einstellungen und Software für die Deployment-Umgebung automatisch sichergestellt. CCA-Werkzeuge verwenden ein programmierbares Framework für Konfiguration und Orchestrierung, indem dabei programmiert, geplant und schrittweise Richtlinien umgesetzt werden.

Entwickler und Admins erhalten entsprechend einen Einblick in die physische und virtuelle Infrastruktur innerhalb ihres Unternehmens. CCA-Lösungen werden allgemein als Erweiterungen der „Infrastruktur als Code“-Frameworks angesehen. Zu den CCA-Tools zählen Ansible, Puppet, Chef, Otter, Rudder und SaltStack. Manche dieser Tools nutzen Agenten, andere basieren auf Push & Pull, aber alle stellen eine interaktive Benutzeroberfläche bereit.

Software Release Life Cycle und Management

Bevor eine neue Software in Betrieb genommen werden kann, muss sie einen Release Life Cycle durchlaufen. Dabei werden ihre Eigenschaften validiert (sind es die vorgesehenen?), auf Funktionsfähigkeit getestet, um Fehler erleichtert und schließlich beim Kunden in Vorabprogrammen genutzt. Der Release Candidate wird „Silver“-Kopie genannt, die Endversion „Gold“. Die Freigabe von Firmen-Software erfolgt in der Regel unter höchster Geheimhaltung. Daher folgt der Release-Ablauf strikten Vorgaben.

Erst nach Aufnahme von Verbesserungsvorschlägen und einem nochmaligen Durchlaufen des Lebenszyklus kann die Software zum RTM-Termin (RTM: ready to manufacture) bereitgestellt und schließlich für Firmennutzung, Privatnutzung oder im Web (GA: General Availability) freigegeben werden. Früher mussten noch Speichermedien wie etwa CDs mit Kopien versehen werden, aber heute wird praktisch jede Software online bereitgestellt.

Zum Life-Cycle-Management gehört zunächst der Support mithilfe von Patches, Service Releases und Service Packs, die nicht nur Fehler beseitigen und Schwachstellen schließen, sondern auch zusätzliche Funktionalität liefern. Als letzte Stufe im Release Life Cycle tritt „End of Life“ (EOL) ein. Der Entwickler liefert keine weiteren Updates und Bugfixes mehr und kündigt dies mit einem End of Life Announcement (EOLA) an.

Ein Datum für die letztmögliche Bestellung (Last order date) wird angegeben, bevor der EOL eintritt. Das muss aber nicht das Ende der Nutzung bedeuten. Liebhaber des Personal Computers Atari ST haben dessen grafische Software noch Jahre nach dem EOL-Datum weitergenutzt, weil der Windows-PC noch nicht so weit entwickelt war und der Umstieg auf einen Apple Mac ihnen zu kostspielig erschien.

Die Vorteile des IEEE-Standards 12207:2017

Der firmeninterne Vorteil des internationalen Standards liegt in der vereinheitlichten Festlegung der für den System- und Softwarelebenszyklus notwendigen Prozesse. Intern erleichtert dies zudem die Kommunikation zwischen Käufern, Zulieferern und den Shareholdern dieser Prozesse und Produkte. Extern können sich freie Entwickler, Integratoren, Operateure, Wartungspersonal, Verwalter, Qualitätssicherer und nicht zuletzt die Benutzer auf dieser Ebene verständigen und die Vorgaben des Standards bzw. seiner einzelnen Komponenten umsetzen.

Der Standard stellt es jedem Nutzer frei, ob eine Einzelorganisation (Unternehmen, Institut, Privatkunde usw.) den Standard als Vorgabe umsetzt oder sich mehrere Seiten bzw. Organisationen darauf einigen. Auch wird offengelassen, wie stark die vertragliche Bindung sein soll oder darf: Vom Handschlag und Ehrenwort bis zum notariell beglaubigten Vertrag ist alles erlaubt.

Die im Standard beschriebenen Prozesse – besonders die in Anhang A - lassen sich dazu heranziehen, um geschäftliche Umgebungen aufzubauen, so etwa Methoden, Vorgehensweisen, Techniken, Werkzeuge und geschultes Personal. Besonders Anhang A stellt normative Direktiven hinsichtlich der individuellen Anpassung diese Software-Lifecycle-Prozesse zur Verfügung.

Ob Anwendungen in agilen oder Wasserfall-orientierten Methoden realisiert werden, ist jeder Entwicklungsorganisation selbst überlassen. Aber der Standard dient als „lingua franca“, mit der man nicht nur mit anderen Entwicklern kommunizieren kann, sondern als Richtschnur, welche Prozesse als Mindestvoraussetzung für standardisierte Software vorliegen müssen.

(ID:45203585)