Darf man nach einer Woche noch eine „Recap“ zu einem Konferenzbesuch schreiben?
Wir denken schon. 😊
Es war das erste Mal, das SOPHIST auf den IT-Tagen in Frankfurt zugegen war.
Dafür aber gleich richtig mit Messestand und 2 Vorträgen.
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.
WeiterlesenIm 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.
WeiterlesenIn 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:
WeiterlesenWas 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