Archiv des Autors: Breno Pinheiro

A SPICE #3 – Anpassungen der “Vorgaben” aus ASPICE sind nicht gestattet

Veröffentlicht am 10. November 2023 von und
2

Willkommen zurück in unserer Blogserie, in der wir uns in die Welt von Automotive SPICE (ASPICE) vertiefen. In den vorherigen Teilen haben wir uns auf Mythen des Automotive SPICE Standards konzentriert, und heute möchten wir einen häufigen Mythos aufklären: Die Unmöglichkeit, Anpassungen an den “Vorgaben” des ASPICE-Standards vorzunehmen.

Es ist ein Mythos, dass die Vorgaben im Automotive SPICE starr und unveränderlich sind. In unseren Kundenprojekten erleben wir immer wieder, dass jede Abweichung von den „Automotive SPICE-Vorgaben“ zu Nichtkonformität führt. Dies kann jedoch dazu führen, dass Entwicklungsteams und Unternehmen die Flexibilität verlieren, die notwendig ist, um sich an die dynamischen Bedürfnisse des Marktes bzw. Unternehmens anzupassen.

Weiterlesen →

A SPICE #2 – Prozessgruppen entsprechen Architekturebenen des “Systems of Interest”

Veröffentlicht am 13. Oktober 2023 von und
Antworten

Im zweiten Teil unserer Artikelserie rund um Automotive SPICE möchten wir einen weiteren Mythos aufdecken. Es handelt sich um die Annahme, dass Prozessgruppen in Automotive SPICE 1:1 den Architekturebenen des Systems of Interest entsprechen.

In unseren Kundenprojekten erleben wir immer wieder, dass die Prozessgruppen in Automotive SPICE direkt den verschiedenen Architekturebenen des Systems of Interest zugeordnet werden. Demnach würde jeder Prozess im Rahmen der Systementwicklung nur genau einmal durchlaufen werden (siehe Abbildung 1), abgesehen von Iterationen für das gesamte System of Interest. Das Problem hierbei ist, dass es in der Realität aufgrund der umfangreichen Systeme häufig mehr als eine System- und eine Softwareebene gibt, entlang dieser Ebenen Verantwortlichkeiten verteilt werden und das Zusammenarbeitsmodell wesentlich durch die Architektur bestimmt wird.

Weiterlesen →

A SPICE löst Probleme in der Entwicklung

Veröffentlicht am 30. August 2023 von und
Antworten

Teil 1 unserer Artikel-Serie über A SPICE.
Lesen Sie auch unseren Einführungsartikel Drei Mythen rund um A SPICE.

Bevor wir im ersten Teil der Serie in die Tiefe gehen, gibt es eine wichtige Denkweise bzw. Betrachtungsweise, die wir im Vorfeld näher betrachten möchten:

Dr. Gerhard Wohland [1], grandioser Systemtheoretiker, Autor des Buchs “Denkwerkzeuge der Höchstleister” und Leiter des Instituts für dynamikrobuste Organisation (IdO) unterscheidet zwischen der blauen Welt stabiler, vorhersehbarer Umgebungen mit festen Prozessen und der roten Welt unsicherer, dynamischer Umgebungen, die Flexibilität erfordern.
In der blauen Welt steht Effizienz durch standardisierte Regeln im Vordergrund.
Die rote Welt erfordert Anpassungsfähigkeit und den Umgang mit Ungewissheit und Überraschungen. In beiden Welten tauchen Probleme auf… Aber was genau sind Probleme?

Probleme werden, von Dr. Gerhard Wohland, als Signale beschrieben, die man nicht ignorieren kann. Wenn man sie trotzdem ignoriert, kann das später zu Schwierigkeiten führen. Das bedeutet, wir müssen uns mit solchen Problemen auseinandersetzen.

Wie werden Probleme in der blauen und/oder roten Welt gesehen?

  • Die blaue Welt und Probleme:

In der blauen Welt werden Probleme oft als Störungen des normalen Betriebs betrachtet. Die idealisierte Annahme ist, dass, wenn alles nach Plan läuft, es keine roten Probleme geben sollte. Es gibt häufig vorgefertigte Lösungswege oder Richtlinien, wie mit bestimmten Problemen umzugehen ist. Die Lösung der blauen Probleme erfolgt mithilfe von Wissen, das z.B. in Prozessen, Methoden oder Arbeitsanweisungen konserviert ist.

  • Die rote Welt und Probleme:

In der roten Welt werden Probleme oft als Gelegenheiten für Lernen und Weiterentwicklung gesehen. Das Auftreten eines Problems signalisiert, dass es etwas Neues zu entdecken oder zu verstehen gibt. Anstatt auf vorgefertigte Lösungen zurückzugreifen, werden in dieser Welt kreative und innovative Ansätze zur Problemlösung benötigt und gefördert. Die Person, die eine Lösung für das Problem, zu dem es noch kein Wissen geben kann, erarbeiten soll, ist entscheidend. Rote Probleme lassen sich nur durch Können und nicht durch Wissen lösen.

Weiterlesen →

Drei Mythen rund um A SPICE

Veröffentlicht am 4. August 2023 von und
Antworten

In unserer neuen Serie möchten wir Ihnen über A SPICE erzählen.
Den Anfang machen wir mit einer kurzen Einführung und Allgemeinen Informationen . Das A steht übrigens für Automotive :-)
Den Rest erfahren Sie natürlich auch.

Also klären wir doch erstmal die Frage: “Was ist Automotive SPICE?“.

Automotive Software Process Improvement and Capability Determination, kurz Automotive SPICE, ist zweifellos ein wichtiges Werkzeug zur Verbesserung der Systementwicklungsprozesse in der Automobilindustrie. Es bietet eine strukturierte und standardisierte Herangehensweise, um die Qualität und Effizienz in der Entwicklung zu steigern.

Die Kernbedeutung von Automotive SPICE lautet zusammengefasst:

Weiterlesen →

FURPS+

Veröffentlicht am 17. Juli 2023 von
Antworten

Was ist das?
Was kann das?

FURPS+: Ein Framework für Qualitätsanforderungen in der Softwareentwicklung

In der Welt der Softwareentwicklung spielen Qualitätsanforderungen eine entscheidende Rolle. Um sicherzustellen, dass Softwareprodukte den Anforderungen der Nutzenden gerecht werden und die gewünschten Funktionalitäten bieten, bedarf es einer strukturierten Herangehensweise speziell im Bereich des Nicht-funktionalen. In diesem Blogbeitrag stellen wir ein bewährtes Modell zur Bewertung und Verbesserung der Software-Qualitätsanforderungen vor.

Was ist FURPS+?

FURPS steht für Functionality (Funktionalität), Usability (Benutzerfreundlichkeit), Reliability (Zuverlässigkeit), Performance (Leistungsfähigkeit) und Supportability (Wartbarkeit). Das “+” in FURPS+ hilft uns auch bei der Berücksichtigung von weiteren Aspekten wie:

• Designanforderungen
• Implementierungsanforderungen
• Schnittstellenanforderungen
• Physische Anforderungen

Es handelt sich um ein umfassendes Framework, das von Robert Grady bei Hewlett-Packard entwickelt wurde und als Leitfaden für die Entwicklung von Softwareprodukten dient.

Funktionalität (Functionality):

Die Funktionalität einer Software bezieht sich auf die Erfüllung der funktionalen Anforderungen. Das bedeutet, dass die Software die gewünschten Aufgaben und Funktionen erfüllen muss, um den Anforderungen der Nutzenden gerecht zu werden. Ein Schwerpunkt liegt auf der Spezifikation, Implementierung und Prüfung der Funktionalität, um sicherzustellen, dass sie korrekt und vollständig ist. Beispielsweise die funktionale Vollständigkeit oder auch die funktionale Adäquatheit ist hierzu sinnvoll mit Anforderungen zu spezifizieren.

Benutzerfreundlichkeit (Usability):

Benutzerfreundlichkeit bezieht sich auf die einfache und intuitive Bedienung einer Software. Hier ist eine sorgfältige Gestaltung der Benutzeroberfläche entscheidend, damit Nutzende die Software effizient und effektiv verwenden können. Aspekte wie Navigation, Anordnung der Funktionen und die Verständlichkeit der Benutzeroberfläche spielen dabei eine wichtige Rolle. Zu spezifizierende Anforderungen können beginnen bei generellen Bedienkonzepten bis hin zu konkret designten Oberflächen (UI, GUI) bspw. mittels Prototypen (Wireframen oder Mockups).

Zuverlässigkeit (Reliability):

Zuverlässigkeit ist ein kritischer Aspekt jeder Software. Hier geht es um die fehlerfreie Arbeitsweise und die Erfüllung der gestellten Aufgaben. Die Identifizierung und Behebung von Fehlern sowie die Vermeidung von Abstürzen oder Datenverlusten sind zentral. Tests und Überwachungsmechanismen tragen dazu bei, die Zuverlässigkeit sicherzustellen. Anforderungen hierzu sollten immer spezifische Werte enthalten – achten Sie also darauf, keinerlei Adjektive/Adverbien in Ihrer Anforderungsspezifikation zu verwenden.

Leistungsfähigkeit (Performance):

Leistungsfähigkeit bezieht sich auf die Geschwindigkeit, Antwortzeit und Skalierbarkeit einer Software. Eine optimierte Codebasis und Algorithmen sind entscheidend, um eine schnelle und effiziente Arbeitsweise zu gewährleisten. Die Messung und Überwachung der Leistung helfen dabei, Engpässe zu identifizieren und die Leistung zu verbessern. Anforderungen können einerseits spezifisch zu einzelnen Funktionen formuliert werden oder andererseits als recht generische Performance-Klassen als Stellvertreter für eine Gruppe von Funktionen (dies spart viel Zeit beim Anforderungen spezifizieren).

Wartbarkeit (Supportability):

Wartbarkeit beschreibt die Fähigkeit, eine Software effizient zu warten und zu aktualisieren. Eine modulare und gut strukturierte Softwarearchitektur erleichtert Entwicklern Änderungen und Fehlerbehebungen. Dokumentation, Kommentierung und bewährte Entwicklungspraktiken spielen hierbei eine wichtige Rolle. Beachten Sie hierbei, dass nicht die „üblichen Verdächtigen“ Stakeholder wie fachlich orientierte EndanwenderInnen diese Anforderungen benennen, sondern Beteiligte Personen aus den Bereich IT-Betrieb und -Service oder auch -Test.

Das FURPS+ Framework bietet einen umfassenden Ansatz zur Qualitätssteigerung Ihrer Anforderungsspezifikationen in der Softwareentwicklung. Es unterstützt Entwickler dabei, die Anforderungen an (Qualität der) Funktionalität, Benutzerfreundlichkeit, Zuverlässigkeit, Leistungsfähigkeit und Wartbarkeit zu erfüllen. Durch die Anwendung dieses Frameworks können Softwareentwicklungsprojekte effizienter gestaltet werden, da die Qualitätsanforderungen von Anfang an vollständiger berücksichtigt werden. Die Verwendung dieses Frameworks ermöglicht es Ihnen, Softwareprodukte von hoher Qualität zu liefern, die den Erwartungen der Benutzenden hinsichtlich vor allem nicht-funktionaler Aspekte zielgerichtet entsprechen.

Quellen:

FURPS+ von Robert Grady, Hewlett Packard:
https://www.researchgate.net/figure/Mccalls-Triangle-Quality-FURPS-SOFTWARE-QUALITY-MODEL-The-FURPS-model-was-initially_fig1_331305223

Arc42:
FURPS+ for Classifying Requirements:
https://quality.arc42.org/articles/quality-models#eeles