Software-Qualitätsmanagement - Kurzanleitung

Qualitätssoftware bezieht sich auf eine Software, die einigermaßen fehler- oder fehlerfrei ist, rechtzeitig und innerhalb des angegebenen Budgets geliefert wird, die Anforderungen und / oder Erwartungen erfüllt und wartbar ist. Im Kontext der Softwareentwicklung spiegelt die Softwarequalität beides widerfunctional quality ebenso gut wie structural quality.

• Software Functional Quality - Es gibt an, wie gut es einem bestimmten Design entspricht, basierend auf den funktionalen Anforderungen oder Spezifikationen.

• Software Structural Quality - Es befasst sich mit dem Umgang mit nicht funktionalen Anforderungen, die die Erfüllung der funktionalen Anforderungen unterstützen, wie z. B. Robustheit oder Wartbarkeit, und dem Grad, in dem die Software korrekt erstellt wurde.

• Software Quality Assurance- Software Quality Assurance (SQA) ist eine Reihe von Aktivitäten zur Sicherstellung der Qualität von Softwareentwicklungsprozessen, die letztendlich zu hochwertigen Softwareprodukten führen. Die Aktivitäten legen die Prozesse fest und bewerten sie, aus denen Produkte hergestellt werden. Es beinhaltet prozessorientiertes Handeln.

• Software Quality Control- Software Quality Control (SQC) ist eine Reihe von Aktivitäten zur Sicherstellung der Qualität von Softwareprodukten. Diese Aktivitäten konzentrieren sich auf die Ermittlung der Mängel der tatsächlich hergestellten Produkte. Es beinhaltet produktorientiertes Handeln.

Die Software Quality Challenge

In der Softwareindustrie werden die Entwickler niemals erklären, dass die Software fehlerfrei ist, im Gegensatz zu anderen Herstellern industrieller Produkte. Dieser Unterschied ist auf folgende Gründe zurückzuführen.

Produktkomplexität

Dies ist die Anzahl der Betriebsarten, die das Produkt zulässt. Normalerweise erlaubt ein Industrieprodukt nur weniger als einige tausend Betriebsarten mit unterschiedlichen Kombinationen seiner Maschineneinstellungen. Softwarepakete ermöglichen jedoch Millionen von Betriebsmöglichkeiten. Die korrekte Sicherstellung all dieser Betriebsmöglichkeiten ist daher eine große Herausforderung für die Softwareindustrie.

Produktsichtbarkeit

Da die Industrieprodukte sichtbar sind, können die meisten ihrer Mängel während des Herstellungsprozesses erkannt werden. Auch das Fehlen eines Teils in einem Industrieprodukt kann im Produkt leicht festgestellt werden. Die Mängel an Softwareprodukten, die auf Disketten oder CDs gespeichert sind, sind jedoch unsichtbar.

Produktentwicklung und Produktionsprozess

In einem Industrieprodukt können Fehler in den folgenden Phasen erkannt werden:

• Product development - In dieser Phase überprüfen und testen die Designer und Mitarbeiter der Qualitätssicherung (QS) den Produktprototyp, um seine Mängel festzustellen.

• Product production planning- In dieser Phase werden der Produktionsprozess und die Werkzeuge entworfen und vorbereitet. Diese Phase bietet auch die Möglichkeit, das Produkt zu inspizieren, um die Fehler zu erkennen, die während der Entwicklungsphase unbemerkt blieben.

• Manufacturing- In dieser Phase werden QS-Verfahren angewendet, um Fehler von Produkten selbst zu erkennen. In der ersten Herstellungsphase festgestellte Mängel am Produkt können in der Regel durch eine Änderung des Produktdesigns oder der Materialien oder der Produktionswerkzeuge behoben werden, um solche Mängel bei künftig hergestellten Produkten zu beseitigen.

Bei Software ist die Entwicklungsphase die einzige Phase, in der Fehler erkannt werden können. Bei Software sind keine Planungs- und Fertigungsphasen für die Produktproduktion erforderlich, da die Herstellung von Softwarekopien und das Drucken von Softwarehandbüchern automatisch durchgeführt werden.

Die Faktoren, die die Erkennung von Fehlern in Softwareprodukten im Vergleich zu anderen Industrieprodukten beeinflussen, sind in der folgenden Tabelle aufgeführt.

Charakteristisch	Softwareprodukte	Andere Industrieprodukte
Komplexität	Millionen von Betriebsoptionen	tausend Betriebsoptionen
Sichtbarkeit des Produkts	Unsichtbares Produkt Schwer zu erkennende Defekte durch Sicht	Sichtbares Produkt Effektive Erkennung von Fehlern durch Sicht
Art des Entwicklungs- und Produktionsprozesses	kann Defekte in nur einer Phase defekt sein	kann Fehler in allen folgenden Phasen erkennen Produktentwicklung Produktproduktionsplanung Manufacturing

Diese Eigenschaften von Software wie Komplexität und Unsichtbarkeit machen die Entwicklung von Methoden zur Qualitätssicherung von Software und deren erfolgreiche Implementierung zu einer hochprofessionellen Herausforderung.

Die verschiedenen Faktoren, die die Software beeinflussen, werden als Softwarefaktoren bezeichnet. Sie können grob in zwei Kategorien unterteilt werden. Die erste Kategorie der Faktoren umfasst diejenigen, die direkt gemessen werden können, beispielsweise die Anzahl der logischen Fehler, und die zweite Kategorie umfasst diejenigen Faktoren, die nur indirekt gemessen werden können. Zum Beispiel muss die Wartbarkeit, aber jeder der Faktoren gemessen werden, um den Inhalt und die Qualitätskontrolle zu überprüfen.

Im Laufe der Jahre wurden verschiedene Modelle von Softwarequalitätsfaktoren und deren Kategorisierung vorgeschlagen. Das von McCall vorgeschlagene klassische Modell von Softwarequalitätsfaktoren besteht aus 11 Faktoren (McCall et al., 1977). In ähnlicher Weise wurden Modelle, die aus 12 bis 15 Faktoren bestehen, von Deutsch und Willis (1988) sowie von Evans und Marciniak (1987) vorgeschlagen.

Alle diese Modelle unterscheiden sich nicht wesentlich von McCalls Modell. Das McCall-Faktormodell bietet eine praktische, aktuelle Methode zur Klassifizierung von Softwareanforderungen (Pressman, 2000).

McCalls Faktormodell

Dieses Modell klassifiziert alle Softwareanforderungen in 11 Softwarequalitätsfaktoren. Die 11 Faktoren sind in drei Kategorien unterteilt: Produktbetrieb, Produktrevision und Produktübergangsfaktoren.

• Product operation factors - Korrektheit, Zuverlässigkeit, Effizienz, Integrität, Benutzerfreundlichkeit.

• Product revision factors - Wartbarkeit, Flexibilität, Testbarkeit.

• Product transition factors - Portabilität, Wiederverwendbarkeit, Interoperabilität.

Qualitätsfaktoren der Produktbetriebssoftware

Nach dem Modell von McCall umfasst die Produktbetriebskategorie fünf Softwarequalitätsfaktoren, die sich mit den Anforderungen befassen, die sich direkt auf den täglichen Betrieb der Software auswirken. Sie sind wie folgt -

Richtigkeit

Diese Anforderungen betreffen die Richtigkeit der Ausgabe des Softwaresystems. Dazu gehören -

• Ausgangsmission

• Die erforderliche Genauigkeit der Ausgabe, die durch ungenaue Daten oder ungenaue Berechnungen negativ beeinflusst werden kann.

• Die Vollständigkeit der Ausgabeinformationen, die durch unvollständige Daten beeinträchtigt werden können.

• Die Aktualität der Informationen, definiert als die Zeit zwischen dem Ereignis und der Antwort durch das Softwaresystem.

• Die Verfügbarkeit der Informationen.

• Die Standards für die Codierung und Dokumentation des Softwaresystems.

Verlässlichkeit

Zuverlässigkeitsanforderungen betreffen Servicefehler. Sie bestimmen die maximal zulässige Ausfallrate des Softwaresystems und können sich auf das gesamte System oder auf eine oder mehrere seiner separaten Funktionen beziehen.

Effizienz

Es befasst sich mit den Hardwareressourcen, die zur Ausführung der verschiedenen Funktionen des Softwaresystems erforderlich sind. Es umfasst Verarbeitungsfunktionen (in MHz angegeben), Speicherkapazität (in MB oder GB angegeben) und Datenkommunikationsfunktionen (in MBPS oder GBPS angegeben).

Es befasst sich auch mit der Zeit zwischen dem Aufladen der tragbaren Einheiten des Systems, z. B. Informationssystemeinheiten in tragbaren Computern oder meteorologischen Einheiten im Freien.

Integrität

Dieser Faktor betrifft die Sicherheit des Softwaresystems, dh die Verhinderung des Zugriffs auf nicht autorisierte Personen sowie die Unterscheidung zwischen der Gruppe von Personen, denen eine Lese- und Schreibgenehmigung erteilt werden soll.

Benutzerfreundlichkeit

Die Usability-Anforderungen beziehen sich auf die Personalressourcen, die zur Schulung eines neuen Mitarbeiters und zum Betrieb des Softwaresystems erforderlich sind.

Qualitätsfaktoren für Produktrevisionen

Nach dem Modell von McCall sind drei Softwarequalitätsfaktoren in der Produktrevisionskategorie enthalten. Diese Faktoren sind wie folgt:

Wartbarkeit

Dieser Faktor berücksichtigt die Anstrengungen, die Benutzer und Wartungspersonal benötigen, um die Gründe für Softwarefehler zu ermitteln, die Fehler zu beheben und den Erfolg der Korrekturen zu überprüfen.

Flexibilität

Dieser Faktor befasst sich mit den Fähigkeiten und Anstrengungen, die zur Unterstützung adaptiver Wartungsaktivitäten der Software erforderlich sind. Dazu gehört die Anpassung der aktuellen Software an zusätzliche Umstände und Kunden, ohne die Software zu ändern. Die Anforderungen dieses Faktors unterstützen auch perfekte Wartungsaktivitäten wie Änderungen und Ergänzungen der Software, um deren Service zu verbessern und sie an Änderungen im technischen oder kommerziellen Umfeld des Unternehmens anzupassen.

Testbarkeit

Die Anforderungen an die Testbarkeit betreffen sowohl das Testen des Softwaresystems als auch dessen Betrieb. Es enthält vordefinierte Zwischenergebnisse, Protokolldateien sowie die automatische Diagnose, die vom Softwaresystem vor dem Start des Systems durchgeführt wird, um festzustellen, ob alle Komponenten des Systems funktionsfähig sind, und um einen Bericht über die erkannten Fehler zu erhalten. Eine andere Art dieser Anforderungen betrifft automatische Diagnoseprüfungen, die von den Wartungstechnikern durchgeführt werden, um die Ursachen von Softwarefehlern zu ermitteln.

Qualitätsfaktor der Produktübergangssoftware

Nach dem Modell von McCall sind drei Softwarequalitätsfaktoren in der Produktübergangskategorie enthalten, die sich mit der Anpassung von Software an andere Umgebungen und ihrer Interaktion mit anderen Softwaresystemen befassen. Diese Faktoren sind wie folgt:

Portabilität

Portabilitätsanforderungen tendieren dazu, ein Softwaresystem an andere Umgebungen anzupassen, die aus unterschiedlicher Hardware, unterschiedlichen Betriebssystemen usw. bestehen. Die Software sollte in verschiedenen Situationen weiterhin dieselbe Basissoftware verwenden können.

Wiederverwendbarkeit

Dieser Faktor betrifft die Verwendung von Softwaremodulen, die ursprünglich für ein Projekt in einem neuen Softwareprojekt entwickelt wurden, das derzeit entwickelt wird. Sie können auch zukünftigen Projekten ermöglichen, ein bestimmtes Modul oder eine Gruppe von Modulen der aktuell entwickelten Software zu verwenden. Durch die Wiederverwendung von Software sollen Entwicklungsressourcen eingespart, die Entwicklungsdauer verkürzt und Module mit höherer Qualität bereitgestellt werden.

Interoperabilität

Die Anforderungen an die Interoperabilität konzentrieren sich auf die Erstellung von Schnittstellen zu anderen Softwaresystemen oder zur Firmware anderer Geräte. Beispielsweise ist die Firmware der Produktionsmaschinen und Prüfgeräte mit der Produktionssteuerungssoftware verbunden.

Software Quality Assurance(SQA) ist eine Reihe von Aktivitäten zur Qualitätssicherung in Softwareentwicklungsprozessen. Es stellt sicher, dass die entwickelte Software die definierten oder standardisierten Qualitätsspezifikationen erfüllt und erfüllt. SQA ist ein fortlaufender Prozess innerhalb des Software Development Life Cycle (SDLC), der die entwickelte Software routinemäßig überprüft, um sicherzustellen, dass sie die gewünschten Qualitätsmaßnahmen erfüllt.

SQA-Praktiken werden in den meisten Arten der Softwareentwicklung implementiert, unabhängig vom zugrunde liegenden Softwareentwicklungsmodell. SQA enthält und implementiert Softwaretestmethoden zum Testen der Software. Anstatt nach Abschluss die Qualität zu überprüfen, testet SQA die Qualität in jeder Entwicklungsphase, bis die Software vollständig ist. Mit SQA geht der Softwareentwicklungsprozess erst dann in die nächste Phase über, wenn die aktuelle / vorherige Phase den erforderlichen Qualitätsstandards entspricht. SQA arbeitet im Allgemeinen an einem oder mehreren Industriestandards, die bei der Erstellung von Qualitätsrichtlinien und Implementierungsstrategien für Software hilfreich sind.

Es umfasst die folgenden Aktivitäten:

• Prozessdefinition und -implementierung
• Auditing
• Training

Prozesse könnten sein -

• Softwareentwicklungsmethode
• Projektmanagement
• Konfigurationsmanagement
• Anforderungsentwicklung / -management
• Estimation
• Software-Design
• Testen usw.

Sobald die Prozesse definiert und implementiert wurden, hat die Qualitätssicherung die folgenden Verantwortlichkeiten:

• Identifizieren Sie die Schwachstellen in den Prozessen
• Korrigieren Sie diese Schwachstellen, um den Prozess kontinuierlich zu verbessern

Komponenten des SQA-Systems

Ein SQA-System kombiniert immer eine Vielzahl von SQA-Komponenten. Diese Komponenten können in die folgenden sechs Klassen eingeteilt werden:

Komponenten vor dem Projekt

Dies stellt sicher, dass die Projektverpflichtungen unter Berücksichtigung der erforderlichen Ressourcen, des Zeitplans und des Budgets klar definiert wurden. und die Entwicklungs- und Qualitätspläne wurden korrekt festgelegt.

Komponenten der Bewertung der Projektlebenszyklusaktivitäten

Der Projektlebenszyklus besteht aus zwei Phasen: der Entwicklungslebenszyklusphase und der Betriebs- und Wartungsphase.

Die Komponenten der Entwicklungslebenszyklusphase erkennen Entwurfs- und Programmierfehler. Die Komponenten sind in folgende Unterklassen unterteilt: Reviews, Expertenmeinungen und Softwaretests.

Zu den SQA-Komponenten, die während der Betriebs- und Wartungsphase verwendet werden, gehören spezielle Wartungskomponenten sowie Komponenten für den Entwicklungslebenszyklus, die hauptsächlich für Funktionen zur Verbesserung der Wartungsaufgaben verwendet werden.

Komponenten zur Verhinderung und Verbesserung von Infrastrukturfehlern

Das Hauptziel dieser Komponenten, die im gesamten Unternehmen angewendet werden, besteht darin, die Fehlerrate auf der Grundlage der gesammelten SQA-Erfahrung des Unternehmens zu beseitigen oder zumindest zu verringern.

Komponenten des Software-Qualitätsmanagements

Diese Klasse von Komponenten befasst sich mit mehreren Zielen, wie der Kontrolle von Entwicklungs- und Wartungsaktivitäten und der Einführung frühzeitiger Maßnahmen zur Unterstützung des Managements, die hauptsächlich Zeitplan- und Budgetfehler und deren Ergebnisse verhindern oder minimieren.

Komponenten der Standardisierung, Zertifizierung und SQA-Systembewertung

Diese Komponenten implementieren internationale Fach- und Managementstandards innerhalb der Organisation. Die Hauptziele dieser Klasse sind die Nutzung des internationalen Fachwissens, die Verbesserung der Koordination der organisatorischen Qualitätssysteme mit anderen Organisationen und die Bewertung der Leistungen von Qualitätssystemen nach einer gemeinsamen Skala. Die verschiedenen Standards können in zwei Hauptgruppen eingeteilt werden: Qualitätsmanagementstandards und Projektprozessstandards.

Organisation für SQA - die menschlichen Komponenten

Die SQA-Organisationsbasis umfasst Manager, Testpersonal, die SQA-Einheit und die an Softwarequalität interessierten Personen wie SQA-Treuhänder, SQA-Komiteemitglieder und SQA-Forummitglieder. Ihre Hauptziele sind die Initiierung und Unterstützung der Implementierung von SQA-Komponenten, das Erkennen von Abweichungen von den SQA-Verfahren und -Methoden sowie das Vorschlagen von Verbesserungen.

Softwarequalitätskomponenten vor dem Projekt

Diese Komponenten tragen dazu bei, die vor dem Start eines Projekts unternommenen vorbereitenden Schritte zu verbessern. Es beinhaltet -

• Vertragsprüfung
• Entwicklungs- und Qualitätspläne

Vertragsprüfung

Normalerweise wird eine Software für einen mit einem Kunden ausgehandelten Vertrag oder für einen internen Auftrag zur Entwicklung einer Firmware entwickelt, die in ein Hardwareprodukt eingebettet werden soll. In all diesen Fällen verpflichtet sich die Entwicklungseinheit zu einer vereinbarten Funktionsspezifikation, einem Budget und einem Zeitplan. Daher müssen Vertragsüberprüfungsaktivitäten eine detaillierte Prüfung des Projektvorschlagsentwurfs und der Vertragsentwürfe umfassen.

Zu den Aktivitäten zur Vertragsüberprüfung gehören insbesondere:

• Klärung der Kundenanforderungen

• Überprüfung des Zeitplans und des Ressourcenbedarfs des Projekts

• Bewertung der Fähigkeit des Fachpersonals zur Durchführung des vorgeschlagenen Projekts

• Bewertung der Fähigkeit des Kunden, seinen Verpflichtungen nachzukommen

• Bewertung von Entwicklungsrisiken

Entwicklungs- und Qualitätspläne

Nach Unterzeichnung des Softwareentwicklungsvertrags mit einer Organisation oder einer internen Abteilung derselben Organisation wird ein Entwicklungsplan des Projekts und seiner integrierten Qualitätssicherungsaktivitäten erstellt. Diese Pläne enthalten zusätzliche Details und erforderliche Überarbeitungen auf der Grundlage früherer Pläne, die die Grundlage für den aktuellen Vorschlag und Vertrag bildeten.

Meistens dauert es mehrere Monate zwischen der Einreichung des Angebots und der Unterzeichnung des Vertrags. Während dieses Zeitraums können sich Ressourcen wie die Verfügbarkeit des Personals und die beruflichen Fähigkeiten ändern. Die Pläne werden dann überarbeitet, um den in der Zwischenzeit eingetretenen Änderungen Rechnung zu tragen.

Die im Projektentwicklungsplan behandelten Hauptthemen sind:

• Schedules
• Erforderliche Personal- und Hardwareressourcen
• Risikobewertungen
• Organisatorische Probleme: Teammitglieder, Subunternehmer und Partnerschaften
• Projektmethodik, Entwicklungswerkzeuge usw.
• Pläne zur Wiederverwendung von Software

Die Hauptprobleme, die im Qualitätsplan des Projekts behandelt werden, sind:

• Qualitätsziele, ausgedrückt in den entsprechenden messbaren Begriffen

• Kriterien für den Start und das Ende jeder Projektphase

• Listen mit Überprüfungen, Tests und anderen geplanten Überprüfungs- und Validierungsaktivitäten

Software-Metriken können in drei Kategorien eingeteilt werden:

• Product metrics - Beschreibt die Eigenschaften des Produkts wie Größe, Komplexität, Designmerkmale, Leistung und Qualitätsniveau.

• Process metrics - Diese Eigenschaften können verwendet werden, um die Entwicklungs- und Wartungsaktivitäten der Software zu verbessern.

• Project metrics- Diese Metriken beschreiben die Projekteigenschaften und die Ausführung. Beispiele hierfür sind die Anzahl der Softwareentwickler, das Personalmuster über den Lebenszyklus der Software, Kosten, Zeitplan und Produktivität.

Einige Metriken gehören zu mehreren Kategorien. Beispielsweise sind die In-Process-Qualitätsmetriken eines Projekts sowohl Prozessmetriken als auch Projektmetriken.

Software quality metricssind eine Teilmenge von Softwaremetriken, die sich auf die Qualitätsaspekte des Produkts, des Prozesses und des Projekts konzentrieren. Diese sind enger mit Prozess- und Produktmetriken verbunden als mit Projektmetriken.

Softwarequalitätsmetriken können weiter in drei Kategorien unterteilt werden -

• Produktqualitätsmetriken
• In-Process-Qualitätsmetriken
• Qualitätsmetriken für die Wartung

Produktqualitätsmetriken

Diese Metriken umfassen Folgendes:

• Mittlere Zeit bis zum Ausfall
• Fehlerdichte
• Kundenprobleme
• Kundenzufriedenheit

Mittlere Zeit bis zum Ausfall

Es ist die Zeit zwischen Ausfällen. Diese Metrik wird hauptsächlich für sicherheitskritische Systeme wie Flugsicherungssysteme, Avionik und Waffen verwendet.

Fehlerdichte

Es misst die Fehler in Bezug auf die Softwaregröße, ausgedrückt als Codezeilen oder Funktionspunkte usw., dh es misst die Codequalität pro Einheit. Diese Metrik wird in vielen kommerziellen Softwaresystemen verwendet.

Kundenprobleme

Es misst die Probleme, auf die Kunden bei der Verwendung des Produkts stoßen. Es enthält die Perspektive des Kunden auf den Problembereich der Software, der die nicht fehlerorientierten Probleme zusammen mit den Fehlerproblemen enthält.

Die Problemmetrik wird normalerweise in Form von ausgedrückt Problems per User-Month (PUM).

PUM = Total Problems that customers reported (true defect and non-defect oriented 
problems) for a time period + Total number of license months of the software during 
the period

Wo,

Number of license-month of the software = Number of install license of the software × 
Number of months in the calculation period

Die PUM wird normalerweise für jeden Monat nach Markteinführung der Software sowie für monatliche Durchschnittswerte pro Jahr berechnet.

Kundenzufriedenheit

Die Kundenzufriedenheit wird häufig anhand von Kundenumfragedaten anhand der Fünf-Punkte-Skala gemessen.

• Sehr zufrieden
• Satisfied
• Neutral
• Dissatisfied
• Sehr unzufrieden

Die Zufriedenheit mit der Gesamtqualität des Produkts und seinen spezifischen Abmessungen wird normalerweise durch verschiedene Methoden der Kundenumfrage erreicht. Basierend auf den Fünf-Punkte-Daten können je nach Zweck der Analyse mehrere Metriken mit geringfügigen Abweichungen erstellt und verwendet werden. Zum Beispiel -

• Prozent voll zufriedener Kunden
• Prozent der zufriedenen Kunden
• Prozent der unzufriedenen Kunden
• Prozent der unzufriedenen Kunden

Normalerweise wird diese prozentuale Zufriedenheit verwendet.

In-Process-Qualitätsmetriken

In-Process-Qualitätsmetriken befassen sich für einige Unternehmen mit der Verfolgung der Fehlerankunft während formeller Maschinentests. Diese Metrik enthält -

• Fehlerdichte beim Maschinentest
• Fehlerankunftsmuster während des Maschinentests
• Phasenbasiertes Fehlerbeseitigungsmuster
• Wirksamkeit der Fehlerbeseitigung

Fehlerdichte beim Maschinentest

Die Fehlerrate während des formalen Maschinentests (Test nach Integration des Codes in die Systembibliothek) korreliert mit der Fehlerrate vor Ort. Höhere Fehlerraten während des Testens sind ein Indikator dafür, dass die Software während ihres Entwicklungsprozesses eine höhere Fehlerinjektion erfahren hat, es sei denn, die höhere Fehlerrate beim Testen ist auf einen außergewöhnlichen Testaufwand zurückzuführen.

Diese einfache Metrik der Fehler pro KLOC oder Funktionspunkt ist ein guter Indikator für die Qualität, während die Software noch getestet wird. Es ist besonders nützlich, nachfolgende Versionen eines Produkts in derselben Entwicklungsorganisation zu überwachen.

Fehlerankunftsmuster während des Maschinentests

Die Gesamtdefektdichte während des Testens liefert nur die Zusammenfassung der Defekte. Das Muster der Fehlerankünfte liefert weitere Informationen zu verschiedenen Qualitätsstufen im Feld. Es enthält die folgenden -

• Die während der Testphase gemeldeten Fehlerankünfte oder Fehler nach Zeitintervall (z. B. Woche). Hier werden alle keine gültigen Mängel sein.

• Das Muster der gültigen Fehlerankünfte, wenn die Problembestimmung für die gemeldeten Probleme durchgeführt wird. Dies ist das wahre Defektmuster.

• Das Muster der Überstunden des Fehlerrückstands. Diese Metrik wird benötigt, da Entwicklungsorganisationen nicht alle gemeldeten Probleme sofort untersuchen und beheben können. Dies ist sowohl eine Workload-Anweisung als auch eine Qualitätserklärung. Wenn der Defektstau am Ende des Entwicklungszyklus groß ist und noch viele Korrekturen in das System integriert werden müssen, wird die Stabilität des Systems (daher seine Qualität) beeinträchtigt. Ein erneuter Test (Regressionstest) ist erforderlich, um sicherzustellen, dass die angestrebten Produktqualitätsniveaus erreicht werden.

Phasenbasiertes Fehlerbeseitigungsmuster

Dies ist eine Erweiterung der Fehlerdichtemetrik während des Tests. Zusätzlich zum Testen werden die Fehler in allen Phasen des Entwicklungszyklus verfolgt, einschließlich der Entwurfsprüfungen, Code-Inspektionen und formalen Überprüfungen vor dem Testen.

Da ein großer Prozentsatz der Programmierfehler mit Designproblemen zusammenhängt, werden durch die Durchführung formaler Überprüfungen oder Funktionsüberprüfungen zur Verbesserung der Fehlerbehebungsfähigkeit des Prozesses am Front-End Fehler in der Software reduziert. Das Muster der phasenbasierten Fehlerbeseitigung spiegelt die allgemeine Fehlerbeseitigungsfähigkeit des Entwicklungsprozesses wider.

In Bezug auf die Metriken für die Entwurfs- und Codierungsphase verwenden viele Entwicklungsorganisationen zusätzlich zu den Fehlerraten Metriken wie Inspektionsabdeckung und Inspektionsaufwand für das In-Process-Qualitätsmanagement.

Wirksamkeit der Fehlerbeseitigung

Es kann wie folgt definiert werden:

$$DRE = \frac{Defect \: removed \: during \: a \: development\:phase }{Defects\: latent \: in \: the\: product} \times 100\%$$

Diese Metrik kann für den gesamten Entwicklungsprozess, für das Front-End vor der Code-Integration und für jede Phase berechnet werden. Es wird genanntearly defect removal bei Verwendung für das Frontend und phase effectivenessfür bestimmte Phasen. Je höher der Wert der Metrik ist, desto effektiver ist der Entwicklungsprozess und desto weniger Fehler werden in die nächste Phase oder in das Feld übertragen. Diese Metrik ist ein Schlüsselkonzept des Fehlerbeseitigungsmodells für die Softwareentwicklung.

Qualitätsmetriken für die Wartung

Obwohl in dieser Phase nicht viel getan werden kann, um die Qualität des Produkts zu ändern, werden im Folgenden die Korrekturen aufgeführt, die durchgeführt werden können, um die Fehler so schnell wie möglich mit ausgezeichneter Fixierungsqualität zu beseitigen.

• Fix Backlog und Backlog Management Index
• Korrigieren Sie die Reaktionszeit und die Reaktionsfähigkeit
• Prozentuale kriminelle Korrekturen
• Qualität korrigieren

Fix Backlog und Backlog Management Index

Der Fixstau hängt mit der Rate der Fehlerankünfte und der Rate zusammen, mit der Fixes für gemeldete Probleme verfügbar werden. Es ist eine einfache Zählung der gemeldeten Probleme, die am Ende eines jeden Monats oder jeder Woche bestehen bleiben. Wenn diese Metrik im Format eines Trenddiagramms verwendet wird, kann sie aussagekräftige Informationen für die Verwaltung des Wartungsprozesses liefern.

Der Backlog Management Index (BMI) wird verwendet, um den Rückstand offener und ungelöster Probleme zu verwalten.

$$BMI = \frac{Number \: of \: problems \: closed \: during \:the \:month }{Number \: of \: problems \: arrived \: during \:the \:month} \times 100\%$$

Wenn der BMI größer als 100 ist, bedeutet dies, dass der Rückstand verringert wird. Wenn der BMI unter 100 liegt, hat sich der Rückstand erhöht.

Korrigieren Sie die Reaktionszeit und die Reaktionsfähigkeit

Die Metrik für die feste Antwortzeit wird normalerweise als mittlere Zeit aller Probleme vom Öffnen bis zum Schließen berechnet. Eine kurze Reaktionszeit führt zur Kundenzufriedenheit.

Die wichtigen Elemente für die Reaktionsfähigkeit sind die Kundenerwartungen, die vereinbarte Fixzeit und die Fähigkeit, das Engagement für den Kunden zu erfüllen.

Prozentuale kriminelle Korrekturen

Es wird wie folgt berechnet:

$Percent \:Delinquent\: Fixes =$

$\frac{Number \: of \: fixes \: that\: exceeded \: the \:response \:time\:criteria\:by\:ceverity\:level}{Number \: of \: fixes \: delivered \: in \:a \:specified \:time} \times 100\%$

Qualität korrigieren

Die Fixqualität oder die Anzahl der fehlerhaften Fixes ist eine weitere wichtige Qualitätsmetrik für die Wartungsphase. Ein Fix ist fehlerhaft, wenn das gemeldete Problem nicht behoben wurde oder wenn das ursprüngliche Problem behoben wurde, aber ein neuer Fehler aufgetreten ist. Bei unternehmenskritischer Software wirken sich fehlerhafte Korrekturen nachteilig auf die Kundenzufriedenheit aus. Die Metrik der prozentualen fehlerhaften Korrekturen ist der Prozentsatz aller Korrekturen in einem fehlerhaften Zeitintervall.

Ein fehlerhafter Fix kann auf zwei Arten aufgezeichnet werden: Aufzeichnen in dem Monat, in dem er entdeckt wurde, oder Aufzeichnen in dem Monat, in dem der Fix geliefert wurde. Das erste ist eine Kundenmaßnahme; Die zweite ist eine Prozessmaßnahme. Der Unterschied zwischen den beiden Daten ist die Latenzzeit des fehlerhaften Fixes.

Je länger die Latenz ist, desto mehr Kunden sind normalerweise betroffen. Wenn die Anzahl der Fehler groß ist, zeigt der kleine Wert der prozentualen Metrik ein optimistisches Bild. Das Qualitätsziel für den Wartungsprozess ist natürlich, dass keine fehlerhaften Korrekturen ohne Delinquenz durchgeführt werden.

Messen ist die Aktion, etwas zu messen. Es ist die Zuordnung einer Nummer zu einem Merkmal eines Objekts oder Ereignisses, das mit anderen Objekten oder Ereignissen verglichen werden kann.

Formal kann definiert werden als der Prozess, durch den Zahlen oder Symbole Attributen von Entitäten in der realen Welt zugewiesen werden, so dass sie nach klar definierten Regeln beschrieben werden.

Messung im Alltag

Die Messung wird nicht nur von professionellen Technologen verwendet, sondern auch von uns allen im Alltag. In einem Geschäft dient der Preis als Maß für den Wert eines Artikels. In ähnlicher Weise stellen Höhen- und Größenmessungen sicher, ob das Tuch richtig passt oder nicht. Die Messung hilft uns daher, einen Artikel mit einem anderen zu vergleichen.

Die Messung nimmt die Informationen über die Attribute von Entitäten auf. Eine Entität ist ein Objekt wie eine Person oder ein Ereignis wie eine Reise in die reale Welt. Ein Attribut ist ein Merkmal oder eine Eigenschaft einer Entität, wie z. B. die Größe einer Person, die Kosten einer Reise usw. In der realen Welt messen wir, obwohl wir daran denken, die Dinge zu messen, tatsächlich die Attribute dieser Dinge.

Attribute werden meist durch Zahlen oder Symbole definiert. Zum Beispiel kann der Preis in Rupien oder Dollar angegeben werden, die Kleidungsgröße kann in Form von klein, mittel und groß angegeben werden.

Die Genauigkeit einer Messung hängt vom Messgerät sowie von der Definition der Messung ab. Nachdem wir die Messungen erhalten haben, müssen wir sie analysieren und Schlussfolgerungen über die Entitäten ableiten.

Die Messung ist eine direkte Quantifizierung, während die Berechnung eine indirekte ist, bei der wir verschiedene Messungen unter Verwendung einiger Formeln kombinieren.

Messung in der Softwareentwicklung

Software Engineering umfasst das Verwalten, Kalkulieren, Planen, Modellieren, Analysieren, Spezifizieren, Entwerfen, Implementieren, Testen und Warten von Softwareprodukten. Daher spielt die Messung eine wichtige Rolle in der Softwareentwicklung. Für die Messung der Eigenschaften eines Softwareprodukts ist ein strenger Ansatz erforderlich.

Für die meisten Entwicklungsprojekte

• Wir setzen keine messbaren Ziele für unsere Softwareprodukte
• Wir verstehen und quantifizieren die Komponentenkosten von Softwareprojekten nicht
• Wir quantifizieren oder prognostizieren nicht die Qualität der von uns hergestellten Produkte

Zur Steuerung von Softwareprodukten ist daher die Messung der Attribute erforderlich. Jede Messaktion muss durch ein bestimmtes Ziel oder einen bestimmten Bedarf motiviert sein, der klar definiert und leicht verständlich ist. Die Messziele müssen spezifisch sein und versucht werden, was Manager, Entwickler und Benutzer wissen müssen. Die Messung ist erforderlich, um den Status des Projekts, des Produkts, der Prozesse und der Ressourcen zu bewerten.

In der Softwareentwicklung ist die Messung für die folgenden drei grundlegenden Aktivitäten unerlässlich:

• Um zu verstehen, was während der Entwicklung und Wartung passiert
• Um zu steuern, was im Projekt passiert
• Prozesse und Ziele verbessern

Die gegenständliche Messtheorie

Die Messung gibt uns die Regeln an, die die Grundlage für die Entwicklung und Argumentation aller Arten von Messungen bilden. Es ist die Abbildung von der empirischen Welt auf die formale Beziehungswelt. Folglich ist ein Maß die Nummer oder das Symbol, die bzw. das einer Entität durch diese Zuordnung zugewiesen wird, um eine Entität zu charakterisieren.

Empirische Beziehungen

In der realen Welt verstehen wir die Dinge, indem wir sie vergleichen und nicht indem wir ihnen Zahlen zuweisen.

Um beispielsweise die Höhe zu vergleichen, verwenden wir die Begriffe "größer als", höher als ". Somit sind diese "größer als", höher als "empirische Beziehungen für die Höhe.

Wir können mehr als eine empirische Beziehung auf derselben Menge definieren.

Zum Beispiel ist X größer als Y. X, Y sind viel größer als Z.

Empirische Beziehungen können unär, binär, ternär usw. sein.

X ist groß, Y ist nicht groß sind unäre Beziehungen.

X ist größer als Y ist eine binäre Beziehung.

Empirische Beziehungen in der realen Welt können auf eine formale mathematische Welt abgebildet werden. Meist spiegeln diese Beziehungen die persönlichen Vorlieben wider.

Einige der Mapping- oder Bewertungstechniken, die verwendet werden, um diese empirischen Beziehungen auf die mathematische Welt abzubilden, sind folgende:

Likert-Skala

Hier erhalten die Nutzer eine Erklärung, der sie zustimmen oder nicht zustimmen müssen.

For example - Diese Software funktioniert gut.

Stimme voll und ganz zu	Zustimmen	Weder zustimmen noch abstreiten	Nicht zustimmen	Stark disgaree

Erzwungenes Ranking

Ordnen Sie die angegebenen Alternativen von 1 (am besten) bis n (am schlechtesten).

Zum Beispiel: Ordnen Sie die folgenden 5 Softwaremodule nach ihrer Leistung.

Name des Moduls	Rang
Modul A.
Modul B.
Modul C.
Modul D.
Modul E.

Verbale Frequenzskala

For example - Wie oft schlägt dieses Programm fehl?

Immer	Häufig	Manchmal	Selten	noch nie

Ordnungsskala

Hier erhalten die Benutzer eine Liste mit Alternativen und müssen eine auswählen.

For example - Wie oft schlägt dieses Programm fehl?

• Hourly
• Daily
• Weekly
• Monthly
• Mehrmals im Jahr
• Einmal oder zweimal im Jahr
• Never

Vergleichsskala

Hier muss der Benutzer eine Nummer angeben, indem er die verschiedenen Optionen vergleicht.

Very superiorAbout the sameVery inferior

12345678910

Numerische Skala

Hier muss der Benutzer eine Nummer entsprechend seiner Wichtigkeit angeben.

UnimportantImportant

12345678910

Die Regeln der Zuordnung

Um das Mapping durchzuführen, müssen wir die Domäne, den Bereich sowie die Regeln für das Mapping angeben.

For example - Domain - Reale Welt

• Range - Mathematische Welt wie ganze Zahlen, reelle Zahlen usw.

• Rules - Zum Messen der Höhe, Schuhe, die getragen werden sollen oder nicht

Ebenso ist bei Softwaremessung die Checkliste der Anweisung in die anzugebenden Codezeilen aufzunehmen.

Die repräsentative Messbedingung

Die Darstellungsbedingung besagt, dass eine Messabbildung erfolgt (M) müssen Entitäten in Zahlen und empirische Beziehungen in numerische Beziehungen so abbilden, dass die empirischen Beziehungen durch numerische Beziehungen erhalten bleiben und erhalten bleiben.

Zum Beispiel: Die empirische Beziehung 'größer als' wird auf die numerische Beziehung '>' abgebildet. X is taller than Y, if and only if M(X) > M(Y)

Da es auf einer bestimmten Menge viele Beziehungen geben kann, hat die Repräsentationsbedingung auch Auswirkungen auf jede dieser Beziehungen.

Für die unäre Beziehung 'ist groß' könnten wir die numerische Beziehung haben

X > 50

Die Darstellungsbedingung erfordert dies für jede Maßnahme M,

X is tall if and only if M(X) > 50

Schlüsselstufen der formalen Messung

Die wichtigsten Messphasen lassen sich wie folgt zusammenfassen:

Modelle sind nützlich, um das Verhalten der numerischen Elemente der realen Entitäten zu interpretieren und zu messen. Um den Messprozess zu unterstützen, sollte das Modell der Zuordnung auch durch ein Modell der Zuordnungsdomäne ergänzt werden. Ein Modell sollte auch angeben, wie diese Entitäten mit den Attributen zusammenhängen und wie sich die Merkmale beziehen.

Es gibt zwei Arten von Messungen:

• Direkte Messung
• Indirekte Messung

Direkte Messung

Dies sind die Messungen, die ohne Beteiligung einer anderen Entität oder eines anderen Attributs gemessen werden können.

Die folgenden direkten Maßnahmen werden üblicherweise in der Softwareentwicklung verwendet.

• Länge des Quellcodes nach LOC
• Dauer des Testzwecks nach verstrichener Zeit
• Anzahl der während des Testprozesses durch Zählen der Fehler entdeckten Fehler
• Die Zeit, die ein Programmierer für ein Programm verbringt

Indirekte Messung

Dies sind Messungen, die anhand einer anderen Entität oder eines anderen Attributs gemessen werden können.

Die folgenden indirekten Maßnahmen werden üblicherweise in der Softwareentwicklung verwendet.

$$\small Programmer\:Productivity = \frac{LOC \: produced }{Person \:months \:of \:effort}$$

$\small Module\:Defect\:Density = \frac{Number \:of\:defects}{Module \:size}$

$$\small Defect\:Detection\:Efficiency = \frac{Number \:of\:defects\:detected}{Total \:number \:of\:defects}$$

$\small Requirement\:Stability = \frac{Number \:of\:initial\:requirements}{Total \:number \:of\:requirements}$

$\small Test\:Effectiveness\:Ratio = \frac{Number \:of\:items\:covered}{Total \:number \:of \:items}$

$\small System\:spoilage = \frac{Effort \:spent\:for\:fixing\:faults}{Total \:project \:effort}$

Messung zur Vorhersage

Um dem Projekt die entsprechenden Ressourcen zuzuweisen, müssen wir den Aufwand, die Zeit und die Kosten für die Entwicklung des Projekts vorhersagen. Die Messung zur Vorhersage erfordert immer ein mathematisches Modell, das die vorherzusagenden Attribute mit einem anderen Attribut in Beziehung setzt, das wir jetzt messen können. Daher besteht ein Vorhersagesystem aus einem mathematischen Modell zusammen mit einer Reihe von Vorhersageverfahren zum Bestimmen der unbekannten Parameter und zum Interpretieren der Ergebnisse.

Messskalen sind die Abbildungen, die zur Darstellung des empirischen Beziehungssystems verwendet werden. Es ist hauptsächlich von 5 Arten -

• Nominalskala
• Ordnungsskala
• Intervall-Skala
• Verhältnisskala
• Absolute Skala

Nominalskala

Es platziert die Elemente in einem Klassifizierungsschema. Die Klassen werden nicht bestellt. Jede Entität sollte basierend auf dem Wert des Attributs in eine bestimmte Klasse oder Kategorie eingeordnet werden.

Es hat zwei Hauptmerkmale -

• Das empirische Beziehungssystem besteht nur aus verschiedenen Klassen; Es gibt keine Vorstellung von einer Reihenfolge zwischen den Klassen.

• Jede eindeutige Nummerierung oder symbolische Darstellung der Klassen ist ein akzeptables Maß, aber es gibt keinen Größenbegriff, der mit den Zahlen oder Symbolen verbunden ist.

Ordnungsskala

Es platziert die Elemente in einem geordneten Klassifizierungsschema. Es hat die folgenden Eigenschaften -

• Das empirische Beziehungssystem besteht aus Klassen, die in Bezug auf das Attribut geordnet sind.

• Jede Zuordnung, die die Reihenfolge beibehält, ist akzeptabel.

• Die Zahlen geben nur die Rangfolge wieder. Daher haben Addition, Subtraktion und andere arithmetische Operationen keine Bedeutung.

Intervall-Skala

Diese Skala erfasst die Informationen über die Größe der Intervalle, die die Klassifizierung trennen. Daher ist es leistungsfähiger als die Nominalskala und die Ordnungsskala.

Es hat die folgenden Eigenschaften -

• Es bewahrt die Ordnung wie die Ordnungsskala.

• Es bewahrt die Unterschiede, aber nicht das Verhältnis.

• Addition und Subtraktion können auf dieser Skala durchgeführt werden, jedoch nicht Multiplikation oder Division.

Wenn ein Attribut auf einer Intervallskala messbar ist, und M und M’ Sind Zuordnungen, die die Darstellungsbedingung erfüllen, können wir immer zwei Zahlen finden a und b so dass,

M = aM '+ b

Verhältnisskala

Dies ist die nützlichste Messskala. Hier besteht eine empirische Beziehung zur Erfassung von Verhältnissen. Es hat die folgenden Eigenschaften -

• Es handelt sich um eine Messzuordnung, bei der die Reihenfolge, die Größe der Intervalle zwischen den Entitäten und das Verhältnis zwischen den Entitäten erhalten bleiben.

• Es gibt ein Nullelement, das das völlige Fehlen der Attribute darstellt.

• Die Messzuordnung muss bei Null beginnen und in gleichen Intervallen, sogenannten Einheiten, zunehmen.

• Alle arithmetischen Operationen können angewendet werden.

Hier hat die Zuordnung die Form

M = aM’

Wo ‘a’ ist ein positiver Skalar.

Absolute Skala

Auf dieser Skala gibt es nur ein mögliches Maß für ein Attribut. Daher wird die einzig mögliche Transformation die Identitätstransformation sein.

Es hat die folgenden Eigenschaften -

• Die Messung erfolgt durch Zählen der Anzahl der Elemente im Entitätssatz.

• Das Attribut hat immer die Form "Anzahl der Vorkommen von x in der Entität".

• Es gibt nur eine mögliche Messabbildung, nämlich die tatsächliche Anzahl.

• Alle arithmetischen Operationen können mit der resultierenden Zählung ausgeführt werden.

Empirische Untersuchungen umfassen die wissenschaftliche Untersuchung von Werkzeugen, Techniken oder Methoden. Diese Untersuchung enthält hauptsächlich die folgenden 4 Prinzipien.

• Auswahl einer Untersuchungstechnik
• Angabe der Hypothese
• Beibehaltung der Kontrolle über die Variable
• Die Untersuchung aussagekräftig machen

Auswahl einer Untersuchungstechnik

Die Schlüsselkomponenten der empirischen Untersuchung in der Softwareentwicklung sind -

• Survey
• Fallstudie
• Formales Experiment

Umfrage

Umfrage ist die retrospektive Untersuchung einer Situation, um Beziehungen und Ergebnisse zu dokumentieren. Dies erfolgt immer nach dem Eintreten eines Ereignisses. In der Softwareentwicklung können beispielsweise Umfragen durchgeführt werden, um zu bestimmen, wie die Benutzer auf eine bestimmte Methode, ein bestimmtes Werkzeug oder eine bestimmte Technik reagiert haben, um Trends oder Beziehungen zu bestimmen.

In diesem Fall haben wir keine Kontrolle über die aktuelle Situation. Wir können eine Situation aufzeichnen und mit einer ähnlichen vergleichen.

Fallstudie

Hierbei handelt es sich um eine Forschungstechnik, bei der Sie die Schlüsselfaktoren identifizieren, die das Ergebnis einer Aktivität beeinflussen können, und dann die Aktivität dokumentieren: ihre Eingaben, Einschränkungen, Ressourcen und Ausgaben.

Formales Experiment

Es handelt sich um eine streng kontrollierte Untersuchung einer Aktivität, bei der die Schlüsselfaktoren identifiziert und manipuliert werden, um ihre Auswirkungen auf das Ergebnis zu dokumentieren.

Eine bestimmte Untersuchungsmethode kann nach folgenden Richtlinien gewählt werden:

• Wenn die Aktivität bereits stattgefunden hat, können wir eine Umfrage oder Fallstudie durchführen. Wenn dies noch nicht geschehen ist, kann eine Fallstudie oder ein formales Experiment ausgewählt werden.

• Wenn wir ein hohes Maß an Kontrolle über die Variablen haben, die das Ergebnis beeinflussen können, können wir ein Experiment verwenden. Wenn wir keine Kontrolle über die Variable haben, wird die Fallstudie eine bevorzugte Technik sein.

• Wenn eine Replikation auf höheren Ebenen nicht möglich ist, ist ein Experiment nicht möglich.

• Wenn die Replikationskosten niedrig sind, können wir Experimente in Betracht ziehen.

Angabe der Hypothese

Um die Entscheidung für eine bestimmte Untersuchungstechnik zu verbessern, sollte das Ziel der Forschung als Hypothese ausgedrückt werden, die wir testen möchten. Die Hypothese ist die vorläufige Theorie oder Annahme, die der Programmierer für das Verhalten hält, das er untersuchen möchte.

Kontrolle über Variablen behalten

Nachdem wir die Hypothese aufgestellt haben, müssen wir als nächstes die verschiedenen Variablen entscheiden, die ihre Wahrheit beeinflussen, sowie wie viel Kontrolle wir darüber haben. Dies ist wichtig, da der Hauptdiskriminator zwischen dem Experiment und den Fallstudien der Grad der Kontrolle über die Variable ist, die das Verhalten beeinflusst.

Eine Zustandsvariable, die den Faktor darstellt, der das Projekt charakterisieren und auch die Bewertungsergebnisse beeinflussen kann, wird verwendet, um die Kontrollsituation von der experimentellen im formalen Experiment zu unterscheiden. Wenn wir die Kontrolle nicht vom Experiment unterscheiden können, wird die Fallstudientechnik bevorzugt.

Wenn wir beispielsweise feststellen möchten, ob eine Änderung der Programmiersprache die Produktivität des Projekts beeinträchtigen kann, ist die Sprache eine Statusvariable. Angenommen, wir verwenden derzeit FORTRAN, das wir durch Ada ersetzen möchten. Dann wird FORTRAN die Kontrollsprache und Ada die experimentelle sein.

Die Untersuchung aussagekräftig machen

Die Ergebnisse eines Experiments sind normalerweise verallgemeinerbarer als Fallstudien oder Umfragen. Die Ergebnisse der Fallstudie oder Umfrage können normalerweise nur auf eine bestimmte Organisation angewendet werden. Die folgenden Punkte belegen die Effizienz dieser Techniken zur Beantwortung einer Vielzahl von Fragen.

Übereinstimmende Theorien und konventionelle Weisheit

Fallstudien oder Umfragen können verwendet werden, um die Wirksamkeit und Nützlichkeit der herkömmlichen Weisheit und vieler anderer Standards, Methoden oder Werkzeuge in einer einzigen Organisation anzupassen. Ein formales Experiment kann jedoch die Situationen untersuchen, in denen die Behauptungen im Allgemeinen zutreffen.

Beziehungen erkunden

Die Beziehung zwischen verschiedenen Attributen von Ressourcen und Softwareprodukten kann durch eine Fallstudie oder Umfrage vorgeschlagen werden.

Eine Umfrage unter abgeschlossenen Projekten kann beispielsweise ergeben, dass eine in einer bestimmten Sprache geschriebene Software weniger Fehler aufweist als eine in anderen Sprachen geschriebene Software.

Das Verständnis und die Überprüfung dieser Beziehungen ist für den Erfolg zukünftiger Projekte von entscheidender Bedeutung. Jede dieser Beziehungen kann als Hypothese ausgedrückt werden, und ein formales Experiment kann entworfen werden, um zu testen, inwieweit die Beziehungen bestehen. Normalerweise wird der Wert eines bestimmten Attributs beobachtet, indem andere Attribute konstant gehalten oder unter Kontrolle gehalten werden.

Bewertung der Genauigkeit von Modellen

Modelle werden normalerweise verwendet, um das Ergebnis einer Aktivität vorherzusagen oder um die Verwendung einer Methode oder eines Werkzeugs zu steuern. Es stellt ein besonders schwieriges Problem dar, wenn ein Experiment oder eine Fallstudie entworfen wird, da ihre Vorhersagen häufig das Ergebnis beeinflussen. Die Projektmanager setzen die Vorhersagen häufig in Ziele für die Fertigstellung um. Dieser Effekt tritt häufig auf, wenn die Kosten- und Zeitplanmodelle verwendet werden.

Einige Modelle wie Zuverlässigkeitsmodelle haben keinen Einfluss auf das Ergebnis, da die als mittlere Zeit bis zum Ausfall gemessene Zuverlässigkeit erst bewertet werden kann, wenn die Software vor Ort einsatzbereit ist.

Maßnahmen validieren

Es gibt viele Softwaremaßnahmen, um den Wert eines Attributs zu erfassen. Daher muss eine Studie durchgeführt werden, um zu testen, ob eine bestimmte Kennzahl die Änderungen des Attributs widerspiegelt, das erfasst werden soll. Die Validierung erfolgt durch Korrelation einer Kennzahl mit einer anderen. Zur Validierung sollte ein zweites Maß verwendet werden, das auch ein direktes und gültiges Maß für den Einflussfaktor ist. Solche Maßnahmen sind nicht immer verfügbar oder einfach zu messen. Außerdem müssen die verwendeten Maßnahmen den menschlichen Vorstellungen des gemessenen Faktors entsprechen.

Der Rahmen für die Softwaremessung basiert auf drei Prinzipien:

• Klassifizierung der zu untersuchenden Unternehmen
• Ermittlung relevanter Messziele
• Ermittlung des Reifegrades, den die Organisation erreicht hat

Klassifizierung der zu untersuchenden Entitäten

In der Softwareentwicklung existieren hauptsächlich drei Klassen von Entitäten. Sie sind -

• Processes
• Products
• Resources

Alle diese Entitäten haben sowohl interne als auch externe Entitäten.

• Internal attributessind solche, die nur anhand des Prozesses, des Produkts oder der Ressourcen selbst gemessen werden können. Zum Beispiel: Größe, Komplexität, Abhängigkeit zwischen Modulen.

• External attributessind solche, die nur in Bezug auf ihre Beziehung zur Umwelt gemessen werden können. Beispiel: Die Gesamtzahl der Fehler, die bei einem Benutzer aufgetreten sind, die Zeit, die zum Durchsuchen der Datenbank und zum Abrufen von Informationen benötigt wird.

Die verschiedenen Attribute, die für jede der Entitäten gemessen werden können, sind wie folgt:

Prozesse

Prozesse sind Sammlungen softwarebezogener Aktivitäten. Im Folgenden sind einige der internen Attribute aufgeführt, die direkt für einen Prozess gemessen werden können:

• Die Dauer des Prozesses oder einer seiner Aktivitäten

• Der mit dem Prozess oder einer seiner Aktivitäten verbundene Aufwand

• Die Anzahl der Vorfälle eines bestimmten Typs, die während des Prozesses oder einer seiner Aktivitäten auftreten

Die verschiedenen externen Attribute eines Prozesses sind Kosten, Kontrollierbarkeit, Effektivität, Qualität und Stabilität.

Produkte

Produkte sind nicht nur die Artikel, zu deren Lieferung sich das Management verpflichtet hat, sondern auch alle Artefakte oder Dokumente, die während des Software-Lebenszyklus erstellt wurden.

Die verschiedenen internen Produktattribute sind Größe, Aufwand, Kosten, Spezifikation, Länge, Funktionalität, Modularität, Wiederverwendung, Redundanz und syntaktische Korrektheit. Unter diesen sind Größe, Aufwand und Kosten relativ einfach zu messen als die anderen.

Die verschiedenen externen Produktattribute sind Benutzerfreundlichkeit, Integrität, Effizienz, Testbarkeit, Wiederverwendbarkeit, Portabilität und Interoperabilität. Diese Attribute beschreiben nicht nur den Code, sondern auch die anderen Dokumente, die den Entwicklungsaufwand unterstützen.

Ressourcen

Dies sind Entitäten, die für eine Prozessaktivität erforderlich sind. Es kann eine beliebige Eingabe für die Softwareproduktion sein. Es umfasst Personal, Materialien, Werkzeuge und Methoden.

Die verschiedenen internen Attribute für die Ressourcen sind Alter, Preis, Größe, Geschwindigkeit, Speichergröße, Temperatur usw. Die verschiedenen externen Attribute sind Produktivität, Erfahrung, Qualität, Benutzerfreundlichkeit, Zuverlässigkeit, Komfort usw.

Ermittlung relevanter Messziele

Eine bestimmte Messung ist nur dann nützlich, wenn sie zum Verständnis des Prozesses oder eines der daraus resultierenden Produkte beiträgt. Die Verbesserung des Prozesses oder der Produkte kann nur durchgeführt werden, wenn das Projekt klar definierte Ziele für Prozesse und Produkte hat. Ein klares Verständnis der Ziele kann verwendet werden, um vorgeschlagene Metriken für ein bestimmtes Projekt im Kontext eines Prozessreife-Frameworks zu generieren.

Das Ziel-Frage-Metrik-Paradigma (GQM)

Der GQM-Ansatz bietet einen Rahmen, der die folgenden drei Schritte umfasst:

• Auflistung der Hauptziele des Entwicklungs- oder Wartungsprojekts

• Ableiten der Fragen aus jedem Ziel, die beantwortet werden müssen, um festzustellen, ob die Ziele erreicht werden

• Entscheiden Sie, was gemessen werden muss, um die Fragen angemessen beantworten zu können

Um das GQM-Paradigma zu verwenden, drücken wir zunächst die allgemeinen Ziele der Organisation aus. Anschließend generieren wir die Fragen so, dass die Antworten bekannt sind, damit wir feststellen können, ob die Ziele erreicht werden. Analysieren Sie später jede Frage dahingehend, welche Messung wir benötigen, um jede Frage zu beantworten.

Typische Ziele werden in Bezug auf Produktivität, Qualität, Risiko, Kundenzufriedenheit usw. ausgedrückt. Ziele und Fragen sind in Bezug auf ihre Zielgruppe zu konstruieren.

Um die Ziele, Fragen und Kennzahlen zu generieren, hat Basili & Rombach eine Reihe von Vorlagen bereitgestellt.

• Purpose - (Prozess, Produkt, Modell, Metrik usw.) zu charakterisieren, zu bewerten, vorherzusagen, zu motivieren usw., um zu verstehen, zu bewerten, zu verwalten, zu konstruieren, zu lernen, zu verbessern usw. Example: Das Produkt charakterisieren, um es zu lernen.

• Perspective - Untersuchen Sie die (Kosten, Effektivität, Richtigkeit, Mängel, Änderungen, Produktmaßnahmen usw.) aus Sicht des Entwicklers, Managers, Kunden usw. Example: Untersuchen Sie die Mängel aus Sicht des Kunden.

• Environment - Die Umgebung besteht aus folgenden Elementen: Prozessfaktoren, Personenfaktoren, Problemfaktoren, Methoden, Tools, Einschränkungen usw. Example: Die Kunden dieser Software sind diejenigen, die keine Kenntnisse über die Tools haben.

Messung und Prozessverbesserung

Normalerweise ist die Messung nützlich für -

• Prozess und Produkte verstehen
• Festlegen einer Basislinie
• Zugriff auf und Vorhersage des Ergebnisses

Je nach Reifegrad des von SEI vorgegebenen Prozesses unterscheiden sich die Art der Messung und das Messprogramm. Im Folgenden sind die verschiedenen Messprogramme aufgeführt, die für jeden Reifegrad angewendet werden können.

Level 1: Ad hoc

Auf dieser Ebene sind die Eingänge schlecht definiert, während die Ausgänge erwartet werden. Der Übergang von Eingabe zu Ausgabe ist undefiniert und unkontrolliert. Für diesen Prozessreifegrad sind Basislinienmessungen erforderlich, um einen Ausgangspunkt für die Messung bereitzustellen.

Level 2: Repeatable

Auf dieser Ebene sind die Ein- und Ausgaben des Prozesses, der Einschränkungen und der Ressourcen identifizierbar. Ein wiederholbarer Vorgang kann durch das folgende Diagramm beschrieben werden.

Die Eingabemaßnahmen können die Größe und Volatilität der Anforderungen sein. Die Ausgabe kann in Bezug auf die Systemgröße, die Ressourcen in Bezug auf den Personalaufwand und die Einschränkungen in Bezug auf Kosten und Zeitplan gemessen werden.

Level 3: Defined

Auf dieser Ebene werden Zwischenaktivitäten definiert und ihre Ein- und Ausgänge sind bekannt und verstanden. Ein einfaches Beispiel für den definierten Prozess ist in der folgenden Abbildung beschrieben.

Der Input zu und der Output aus den Zwischenaktivitäten kann untersucht, gemessen und bewertet werden.

Level 4: Managed

Auf dieser Ebene kann das Feedback aus den frühen Projektaktivitäten verwendet werden, um Prioritäten für die aktuellen Aktivitäten und später für die Projektaktivitäten festzulegen. Wir können die Wirksamkeit der Prozessaktivitäten messen. Die Messung spiegelt die Merkmale des Gesamtprozesses und der Interaktion zwischen und über wichtige Aktivitäten hinweg wider.

Level 5: Optimizing

Auf dieser Ebene werden die Maßnahmen aus Aktivitäten verwendet, um den Prozess zu verbessern, indem Prozessaktivitäten entfernt und hinzugefügt werden und die Prozessstruktur als Reaktion auf Messungsrückmeldungen dynamisch geändert wird. Somit kann die Prozessänderung sowohl die Organisation und das Projekt als auch den Prozess beeinflussen. Der Prozess fungiert als Sensoren und Monitore, und wir können den Prozess als Reaktion auf Warnzeichen erheblich ändern.

Bei einem bestimmten Reifegrad können wir die Messungen für diesen und alle darunter liegenden Stufen erfassen.

Ermittlung des Reifegrades

Die Prozessreife schlägt vor, nur das zu messen, was sichtbar ist. Die Kombination von Prozessreife mit GQM bietet daher die nützlichsten Maßnahmen.

• Beim level 1Das Projekt wird wahrscheinlich schlecht definierte Anforderungen haben. Auf dieser Ebene ist die Messung von Anforderungsmerkmalen schwierig.

• Beim level 2sind die Anforderungen genau definiert und die zusätzlichen Informationen wie der Typ jeder Anforderung und die Anzahl der Änderungen an jedem Typ können gesammelt werden.

• Beim level 3Zwischenaktivitäten werden mit Eintritts- und Austrittskriterien für jede Aktivität definiert

Die Ziel- und Fragenanalyse ist dieselbe, aber die Metrik variiert mit der Reife. Je ausgereifter der Prozess ist, desto reicher sind die Messungen. Das GQM-Paradigma wurde zusammen mit der Prozessreife als Grundlage für verschiedene Tools verwendet, die Manager bei der Gestaltung von Messprogrammen unterstützen.

GQM hilft zu verstehen, wie wichtig es ist, das Attribut zu messen, und die Prozessreife legt nahe, ob wir in der Lage sind, es auf sinnvolle Weise zu messen. Zusammen bieten sie einen Kontext für die Messung.

Die Validierung der Messung des Softwaresystems umfasst zwei Schritte:

• Validierung der Messsysteme
• Validierung der Vorhersagesysteme

Validierung der Messsysteme

Kennzahlen oder Messsysteme werden verwendet, um eine vorhandene Entität durch numerische Charakterisierung eines oder mehrerer ihrer Attribute zu bewerten. Eine Kennzahl ist gültig, wenn sie das Attribut, das sie zu messen behauptet, genau charakterisiert.

Bei der Validierung eines Softwaremesssystems wird sichergestellt, dass die Messung eine ordnungsgemäße numerische Charakterisierung des beanspruchten Attributs darstellt, indem gezeigt wird, dass die Darstellungsbedingung erfüllt ist.

Für die Validierung eines Messsystems benötigen wir sowohl ein formales Modell, das Entitäten beschreibt, als auch eine numerische Zuordnung, bei der das zu messende Attribut erhalten bleibt. Wenn es beispielsweise zwei Programme P1 und P2 gibt und wir diese Programme verketten möchten, erwarten wir jede Maßnahmem von Länge, um das zu befriedigen,

m (P1 + P2) = m (P1) + m (P2)

Wenn ein Programm P1 hat mehr Länge als Programm P2, dann jede Maßnahme m sollte auch befriedigen,

m (P1)> m (P2)

Die Länge des Programms kann durch Zählen der Codezeilen gemessen werden. Wenn diese Anzahl die obigen Beziehungen erfüllt, können wir sagen, dass die Codezeilen ein gültiges Maß für die Länge sind.

Die formale Voraussetzung für die Validierung einer Kennzahl besteht darin, nachzuweisen, dass sie das angegebene Attribut im Sinne der Messtheorie charakterisiert. Die Validierung kann verwendet werden, um sicherzustellen, dass die Messgeräte richtig definiert sind und mit dem realen Verhalten der Entität übereinstimmen.

Validierung der Vorhersagesysteme

Vorhersagesysteme werden verwendet, um einige Attribute einer zukünftigen Entität vorherzusagen, die ein mathematisches Modell mit zugehörigen Vorhersageverfahren beinhalten.

Das Validieren von Vorhersagesystemen in einer gegebenen Umgebung ist der Prozess des Ermittelns der Genauigkeit des Vorhersagesystems durch empirische Mittel, dh durch Vergleichen der Modellleistung mit bekannten Daten in der gegebenen Umgebung. Es beinhaltet Experimente und Hypothesentests.

Der für die Validierung akzeptable Genauigkeitsgrad hängt davon ab, ob das Vorhersagesystem deterministisch oder stochastisch ist, sowie von der Person, die die Bewertung durchführt. Einige stochastische Vorhersagesysteme sind stochastischer als andere.

Beispiele für stochastische Vorhersagesysteme sind Systeme wie Softwarekostenschätzung, Aufwandsschätzung, Zeitplanschätzung usw. Um ein Vorhersagesystem formal zu validieren, müssen wir entscheiden, wie stochastisch es ist, und dann die Leistung des Vorhersagesystems mit bekannten Daten vergleichen.

Softwaremetriken sind ein Messstandard, der viele Aktivitäten enthält, die einen gewissen Grad an Messung beinhalten. Es kann in drei Kategorien eingeteilt werden: Produktmetriken, Prozessmetriken und Projektmetriken.

• Product metrics Beschreiben Sie die Merkmale des Produkts wie Größe, Komplexität, Designmerkmale, Leistung und Qualitätsniveau.

• Process metricskann verwendet werden, um die Softwareentwicklung und -wartung zu verbessern. Beispiele hierfür sind die Wirksamkeit der Fehlerbeseitigung während der Entwicklung, das Muster des Testens der Fehlerankunft und die Reaktionszeit des Behebungsprozesses.

• Project metricsBeschreiben Sie die Projekteigenschaften und die Ausführung. Beispiele hierfür sind die Anzahl der Softwareentwickler, das Personalmuster über den Lebenszyklus der Software, Kosten, Zeitplan und Produktivität.

Einige Metriken gehören zu mehreren Kategorien. Beispielsweise sind die In-Process-Qualitätsmetriken eines Projekts sowohl Prozessmetriken als auch Projektmetriken.

Umfang der Software-Metriken

Softwaremetriken enthalten viele Aktivitäten, darunter:

• Kosten- und Aufwandsschätzung
• Produktivitätsmaßnahmen und -modell
• Datensammlung
• Mengenmodelle und Maßnahmen
• Zuverlässigkeitsmodelle
• Leistungs- und Bewertungsmodelle
• Struktur- und Komplexitätsmetriken
• Fähigkeit - Reifegradbewertung
• Verwaltung nach Metriken
• Bewertung von Methoden und Werkzeugen

Die Softwaremessung ist eine vielfältige Sammlung dieser Aktivitäten, die von Modellen zur Vorhersage der Kosten von Softwareprojekten in einer bestimmten Phase bis hin zu Messungen der Programmstruktur reicht.

Kosten- und Aufwandschätzung

Der Aufwand wird als Funktion einer oder mehrerer Variablen ausgedrückt, z. B. der Größe des Programms, der Leistungsfähigkeit der Entwickler und des Wiederverwendungsgrades. Es wurden Kosten- und Aufwandsschätzungsmodelle vorgeschlagen, um die Projektkosten in frühen Phasen des Software-Lebenszyklus vorherzusagen. Die verschiedenen vorgeschlagenen Modelle sind -

• Böhms COCOMO-Modell
• Putnams schlankes Modell
• Albrechts Funktionspunktmodell

Produktivitätsmodell und Maßnahmen

Produktivität kann als Funktion des Wertes und der Kosten betrachtet werden. Jedes kann in verschiedene messbare Größen, Funktionen, Zeit, Geld usw. zerlegt werden. Verschiedene mögliche Komponenten eines Produktivitätsmodells können im folgenden Diagramm ausgedrückt werden.

Datensammlung

Die Qualität eines Messprogramms hängt eindeutig von einer sorgfältigen Datenerfassung ab. Die gesammelten Daten können in einfache Diagramme und Grafiken umgewandelt werden, damit die Manager den Fortschritt und das Problem der Entwicklung verstehen können. Die Datenerfassung ist auch für die wissenschaftliche Untersuchung von Beziehungen und Trends von wesentlicher Bedeutung.

Qualitätsmodelle und Maßnahmen

Es wurden Qualitätsmodelle zur Messung der Qualität des Produkts entwickelt, ohne die Produktivität bedeutungslos ist. Diese Qualitätsmodelle können mit dem Produktivitätsmodell kombiniert werden, um die richtige Produktivität zu messen. Diese Modelle sind normalerweise baumartig aufgebaut. Die oberen Zweige enthalten wichtige Qualitätsfaktoren wie Zuverlässigkeit und Benutzerfreundlichkeit.

Der Begriff des Divide and Conquer-Ansatzes wurde als Standardansatz zur Messung der Softwarequalität implementiert.

Zuverlässigkeitsmodelle

Die meisten Qualitätsmodelle enthalten Zuverlässigkeit als Komponentenfaktor. Die Notwendigkeit, Zuverlässigkeit vorherzusagen und zu messen, hat jedoch zu einer separaten Spezialisierung auf Zuverlässigkeitsmodellierung und -vorhersage geführt. Das Grundproblem in der Zuverlässigkeitstheorie besteht darin, vorherzusagen, wann ein System irgendwann ausfallen wird.

Leistungsbewertung und Modelle

Es umfasst extern beobachtbare Systemleistungsmerkmale wie Antwortzeiten und Abschlussraten sowie die interne Funktionsweise des Systems wie die Effizienz von Algorithmen. Es ist ein weiterer Aspekt der Qualität.

Struktur- und Komplexitätsmetriken

Hier messen wir die strukturellen Eigenschaften von Darstellungen der Software, die vor der Ausführung verfügbar sind. Anschließend versuchen wir, empirisch prädiktive Theorien zu etablieren, um die Qualitätssicherung, Qualitätskontrolle und Qualitätsvorhersage zu unterstützen.

Bewertung der Fähigkeitsreife

Dieses Modell kann viele verschiedene Entwicklungsattribute bewerten, einschließlich der Verwendung von Werkzeugen, Standardpraktiken und mehr. Es basiert auf den Schlüsselpraktiken, die jeder gute Auftragnehmer anwenden sollte.

Verwaltung nach Metriken

Für die Verwaltung des Softwareprojekts spielt die Messung eine wichtige Rolle. Um zu überprüfen, ob das Projekt auf dem richtigen Weg ist, können sich Benutzer und Entwickler auf das messungsbasierte Diagramm verlassen. Der Standardsatz von Messungen und Berichtsmethoden ist besonders wichtig, wenn die Software in ein Produkt eingebettet ist, in dem die Kunden normalerweise nicht mit der Software-Terminologie vertraut sind.

Bewertung von Methoden und Werkzeugen

Dies hängt vom experimentellen Design, der richtigen Identifizierung von Faktoren ab, die das Ergebnis beeinflussen können, und der angemessenen Messung von Faktorattributen.

Softwaremetriken sind ein Messstandard, der viele Aktivitäten enthält, die einen gewissen Grad an Messung beinhalten. Der Erfolg bei der Softwaremessung liegt in der Qualität der gesammelten und analysierten Daten.

Was sind gute Daten?

Die gesammelten Daten können als gute Daten angesehen werden, wenn sie die Antworten auf die folgenden Fragen liefern können:

• Are they correct? - Daten können als korrekt angesehen werden, wenn sie gemäß den genauen Regeln der Definition der Metrik erfasst wurden.

• Are they accurate? - Genauigkeit bezieht sich auf die Differenz zwischen den Daten und dem tatsächlichen Wert.

• Are they appropriately precise? - Präzision behandelt die Anzahl der Dezimalstellen, die zum Ausdrücken der Daten benötigt werden.

• Are they consistent? - Daten können als konsistent angesehen werden, wenn sie keinen wesentlichen Unterschied von einem Messgerät zum anderen aufweisen.

• Are they associated with a particular activity or time period? - Wenn die Daten einer bestimmten Aktivität oder einem bestimmten Zeitraum zugeordnet sind, sollten sie in den Daten eindeutig angegeben werden.

• Can they be replicated?- Normalerweise werden Untersuchungen wie Umfragen, Fallstudien und Experimente häufig unter verschiedenen Umständen wiederholt. Daher sollten die Daten auch leicht zu replizieren sein.

Wie definiere ich die Daten?

Es gibt zwei Arten von Daten, die zu Messzwecken gesammelt werden:

• Raw data- Rohdaten ergeben sich aus der anfänglichen Messung von Prozessen, Produkten oder Ressourcen. Zum Beispiel: Wöchentliche Arbeitszeittabelle der Mitarbeiter in einer Organisation.

• Refined data - Verfeinerte Daten resultieren aus dem Extrahieren wesentlicher Datenelemente aus den Rohdaten, um Werte für Attribute abzuleiten.

Daten können gemäß den folgenden Punkten definiert werden:

• Location
• Timing
• Symptoms
• Endresultat
• Mechanism
• Cause
• Severity
• Cost

Wie sammle ich Daten?

Das Sammeln von Daten erfordert menschliche Beobachtung und Berichterstattung. Manager, Systemanalysten, Programmierer, Tester und Benutzer müssen Zeilendaten in Formularen aufzeichnen. Um genaue und vollständige Daten zu sammeln, ist es wichtig, -

• Halten Sie die Verfahren einfach

• Vermeiden Sie unnötige Aufnahmen

• Schulung der Mitarbeiter in der Notwendigkeit, Daten aufzuzeichnen, und in den anzuwendenden Verfahren

• Stellen Sie den ursprünglichen Anbietern die Ergebnisse der Datenerfassung und -analyse unverzüglich und in einer nützlichen Form zur Verfügung, die sie bei ihrer Arbeit unterstützt

• Überprüfen Sie alle an einer zentralen Sammelstelle gesammelten Daten

Die Planung der Datenerfassung umfasst mehrere Schritte:

• Entscheiden Sie anhand der GQM-Analyse, welche Produkte gemessen werden sollen

• Stellen Sie sicher, dass das Produkt unter Konfigurationskontrolle steht

• Entscheiden Sie genau, welche Attribute gemessen werden sollen und wie indirekte Maßnahmen abgeleitet werden sollen

• Sobald der Satz von Metriken klar ist und der Satz von zu messenden Komponenten identifiziert wurde, erstellen Sie ein Schema zum Identifizieren jeder am Messprozess beteiligten Aktivität

• Richten Sie ein Verfahren für die Bearbeitung der Formulare, die Analyse der Daten und die Berichterstattung über die Ergebnisse ein

Die Datenerfassungsplanung muss mit Beginn der Projektplanung beginnen. Die eigentliche Datenerfassung erfolgt in vielen Entwicklungsphasen.

For example - Einige Daten, die sich auf das Projektpersonal beziehen, können zu Beginn des Projekts erfasst werden, während andere Datenerfassungen, z. B. der Aufwand, zu Beginn des Projekts beginnen und sich über Betrieb und Wartung fortsetzen.

Speichern und Extrahieren von Daten

In der Softwareentwicklung sollten Daten in einer Datenbank gespeichert und mit einem Datenbankmanagementsystem (DBMS) eingerichtet werden. Ein Beispiel für eine Datenbankstruktur ist in der folgenden Abbildung dargestellt. In dieser Datenbank werden die Details verschiedener Mitarbeiter gespeichert, die in verschiedenen Abteilungen einer Organisation arbeiten.

Im obigen Diagramm ist jedes Feld eine Tabelle in der Datenbank, und der Pfeil kennzeichnet die Viele-zu-Eins-Zuordnung von einer Tabelle zu einer anderen. Die Zuordnungen definieren die Einschränkungen, die die logische Konsistenz der Daten bewahren.

Sobald die Datenbank entworfen und mit Daten gefüllt ist, können wir die Datenmanipulationssprachen verwenden, um die Daten für die Analyse zu extrahieren.

Nachdem wir relevante Daten gesammelt haben, müssen wir sie in geeigneter Weise analysieren. Bei der Auswahl der Analysetechnik sind drei Hauptaspekte zu berücksichtigen.

• Die Art der Daten
• Der Zweck des Experiments
• Entwurfsüberlegungen

Die Natur der Daten

Um die Daten zu analysieren, müssen wir auch die größere Population betrachten, die durch die Daten dargestellt wird, sowie die Verteilung dieser Daten.

Stichprobe, Grundgesamtheit und Datenverteilung

Bei der Stichprobe wird ein Datensatz aus einer großen Population ausgewählt. Die Stichprobenstatistik beschreibt und fasst die Maßnahmen einer Gruppe von Versuchspersonen zusammen.

Populationsparameter stellen die Werte dar, die erhalten würden, wenn alle möglichen Probanden gemessen würden.

Die Population oder Stichprobe kann durch die Maße der zentralen Tendenz wie Mittelwert, Median und Modus sowie die Maße der Streuung wie Varianz und Standardabweichung beschrieben werden. Viele Datensätze werden normal verteilt, wie in der folgenden Grafik dargestellt.

Wie oben gezeigt, werden die Daten gleichmäßig über den Mittelwert verteilt. Das sind die wesentlichen Merkmale einer Normalverteilung.

Es gibt auch andere Verteilungen, bei denen die Daten so verzerrt sind, dass sich auf einer Seite des Mittelwerts mehr Datenpunkte befinden als auf der anderen. Beispiel: Wenn die meisten Daten auf der linken Seite des Mittelwerts vorhanden sind, können wir sagen, dass die Verteilung nach links verschoben ist.

Der Zweck des Experiments

Normalerweise werden Experimente durchgeführt -

• Eine Theorie bestätigen
• Eine Beziehung erkunden

Um jedes dieser Ziele zu erreichen, sollte das Ziel formell in Form der Hypothese ausgedrückt werden, und die Analyse muss sich direkt mit der Hypothese befassen.

Eine Theorie bestätigen

Die Untersuchung muss darauf ausgelegt sein, die Wahrheit einer Theorie zu erforschen. Die Theorie besagt normalerweise, dass die Verwendung einer bestimmten Methode, eines bestimmten Werkzeugs oder einer bestimmten Technik einen bestimmten Effekt auf die Probanden hat und sie auf irgendeine Weise besser macht als auf eine andere.

Es sind zwei Fälle von Daten zu berücksichtigen: normal data und non-normal data.

Wenn die Daten aus einer Normalverteilung stammen und zwei Gruppen zu vergleichen sind, kann der t-Test des Schülers zur Analyse verwendet werden. Wenn mehr als zwei Gruppen verglichen werden müssen, kann eine allgemeine Varianzanalyse mit der Bezeichnung F-Statistik verwendet werden.

Wenn die Daten nicht normal sind, können die Daten mithilfe des Kruskal-Wallis-Tests analysiert werden, indem sie eingestuft werden.

Eine Beziehung erkunden

Untersuchungen dienen dazu, die Beziehung zwischen Datenpunkten zu bestimmen, die eine Variable oder mehrere Variablen beschreiben.

Es gibt drei Techniken, um die Fragen zu einer Beziehung zu beantworten: Box-Plots, Streudiagramme und Korrelationsanalyse.

• EIN box plot kann die Zusammenfassung des Bereichs eines Datensatzes darstellen.

• EIN scatter plot repräsentiert die Beziehung zwischen zwei Variablen.

• Correlation analysis verwendet statistische Methoden, um zu bestätigen, ob zwischen zwei Attributen eine echte Beziehung besteht.

  • Verwenden Sie für normalverteilte Werte Pearson Correlation Coefficient um zu überprüfen, ob die beiden Variablen stark korreliert sind oder nicht.

  • Ordnen Sie die Daten für nicht normale Daten ein und verwenden Sie die Spearman Rank Correlation Coefficientals Maß für die Assoziation. Ein weiteres Maß für nicht normale Daten ist dasKendall robust correlation coefficient, der die Beziehung zwischen Datenpunktpaaren untersucht und eine partielle Korrelation identifizieren kann.

Wenn das Ranking eine große Anzahl gebundener Werte enthält, a chi-squared testAuf einer Kontingenztabelle kann die Zuordnung zwischen den Variablen getestet werden. Ähnlich,linear regression kann verwendet werden, um eine Gleichung zu generieren, um die Beziehung zwischen den Variablen zu beschreiben.

Für mehr als zwei Variablen gilt multivariate regression kann verwendet werden.

Entwurfsüberlegungen

Das Design der Untersuchung muss bei der Auswahl der Analysetechniken berücksichtigt werden. Gleichzeitig kann die Komplexität der Analyse das gewählte Design beeinflussen. Mehrere Gruppen verwenden F-Statistiken anstelle des Student-T-Tests mit zwei Gruppen.

Für komplexe faktorielle Designs mit mehr als zwei Faktoren ist ein differenzierterer Test der Assoziation und Signifikanz erforderlich.

Statistische Techniken können verwendet werden, um die Auswirkung eines Satzes von Variablen auf andere zu berücksichtigen oder um das Timing oder die Lerneffekte zu kompensieren.

Interne Produktattribute beschreiben die Softwareprodukte auf eine Weise, die nur vom Produkt selbst abhängig ist. Der Hauptgrund für die Messung interner Produktattribute besteht darin, dass die Produkte während der Entwicklung überwacht und gesteuert werden können.

Messung interner Produktattribute

Die wichtigsten internen Produktattribute umfassen size und structure. Die Größe kann statisch gemessen werden, ohne dass sie ausgeführt werden muss. Die Größe des Produkts gibt Auskunft über den Aufwand, der für die Erstellung erforderlich ist. Ebenso spielt die Struktur des Produkts eine wichtige Rolle bei der Gestaltung der Wartung des Produkts.

Größe messen

Die Softwaregröße kann mit drei Attributen beschrieben werden:

• Length - Es ist die physische Größe des Produkts.

• Functionality - Es beschreibt die Funktionen, die das Produkt dem Benutzer bietet.

• Complexity - Komplexität ist von unterschiedlicher Art, wie z.

  • Problem complexity - Misst die Komplexität des zugrunde liegenden Problems.

  • Algorithmic complexity - Misst die Komplexität des zur Lösung des Problems implementierten Algorithmus

  • Structural complexity - Misst die Struktur der Software, die zur Implementierung des Algorithmus verwendet wird.

  • Cognitive complexity - Misst den Aufwand, der zum Verständnis der Software erforderlich ist.

Die Messung dieser drei Attribute kann wie folgt beschrieben werden:

Länge

Es gibt drei Entwicklungsprodukte, deren Größenmessung nützlich ist, um den für die Vorhersage erforderlichen Aufwand vorherzusagen. Sie sind Spezifikation, Design und Code.

Spezifikation und Design

Diese Dokumente kombinieren normalerweise Text, Grafiken und spezielle mathematische Diagramme und Symbole. Die Spezifikationsmessung kann verwendet werden, um die Länge des Entwurfs vorherzusagen, was wiederum ein Prädiktor für die Codelänge ist.

Die Diagramme in den Dokumenten haben eine einheitliche Syntax, z. B. beschriftete Digraphen, Datenflussdiagramme oder Z-Schemata. Da Spezifikations- und Konstruktionsdokumente aus Texten und Diagrammen bestehen, kann ihre Länge anhand eines Zahlenpaars gemessen werden, das die Textlänge und die Diagrammlänge darstellt.

Für diese Messungen sind die Atomobjekte für verschiedene Arten von Diagrammen und Symbolen zu definieren.

Die atomaren Objekte für Datenflussdiagramme sind Prozesse, externe Entitäten, Datenspeicher und Datenflüsse. Die atomaren Einheiten für algebraische Spezifikationen sind Sortierungen, Funktionen, Operationen und Axiome. Die atomaren Einheiten für Z-Schemata sind die verschiedenen Linien, die in der Spezifikation erscheinen.

Code

Code kann auf verschiedene Arten erzeugt werden, wie z. B. prozedurale Sprache, Objektorientierung und visuelle Programmierung. Das am häufigsten verwendete traditionelle Maß für die Länge des Quellcode-Programms sind die Lines of Code (LOC).

Die Gesamtlänge,

LOC = NCLOC + CLOC

dh

LOC = Non-commented LOC + Commented LOC

Neben der Codezeile können auch andere Alternativen wie die von Maurice Halsted vorgeschlagene Größe und Komplexität zur Messung der Länge verwendet werden.

Halsteads Software-Wissenschaft versuchte, verschiedene Attribute eines Programms zu erfassen. Er schlug drei interne Programmattribute wie Länge, Wortschatz und Volumen vor, die unterschiedliche Ansichten der Größe widerspiegeln.

Er begann mit der Definition eines Programms Pals eine Sammlung von Token, die von Operatoren oder Operanden klassifiziert werden. Die grundlegenden Metriken für diese Token waren:

• μ₁ = Anzahl der eindeutigen Operatoren

• μ₂ = Anzahl der eindeutigen Operanden

• N₁ = Gesamtzahl der Operatoren

• N₂ = Anzahl der eindeutigen Operatoren

Die Länge P kann definiert werden als

$$N = N_{1}+ N_{2}$$

Der Wortschatz von P ist

$$\mu =\mu _{1}+\mu _{2}$$

Das Programmvolumen = Anzahl der mentalen Vergleiche, die zum Schreiben eines Längenprogramms erforderlich sind Nist

$$V = N\times {log_{2}} \mu$$

Die Programmebene eines Programms P des Volumens V ist,

$$L = \frac{V^\ast}{V}$$

Wo, $V^\ast$ ist das potentielle Volumen, dh das Volumen der Implementierung mit minimaler Größe von P

Die Umkehrung des Niveaus ist die Schwierigkeit -

$$D = 1\diagup L$$

Nach der Halstead-Theorie können wir eine Schätzung berechnen L wie

$${L}' = 1\diagup D = \frac{2}{\mu_{1}} \times \frac{\mu_{2}}{N_{2}}$$

In ähnlicher Weise beträgt die geschätzte Programmlänge: $\mu_{1}\times log_{2}\mu_{1}+\mu_{2}\times log_{2}\mu_{2}$

Der Aufwand zur Erzeugung von P ist gegeben durch:

$$E = V\diagup L = \frac{\mu_{1}N_{2}Nlog_{2}\mu}{2\mu_{2}}$$

Wo die Maßeinheit E ist elementare mentale Diskriminierung erforderlich, um zu verstehen P

Die anderen Alternativen zur Längenmessung sind -

• In Bezug auf die Anzahl der für den Programmtext erforderlichen Bytes an Computerspeicher

• In Bezug auf die Anzahl der Zeichen im Programmtext

Die objektorientierte Entwicklung schlägt neue Wege zur Längenmessung vor. Pfleeger et al. fanden heraus, dass eine Anzahl von Objekten und Methoden zu genaueren Produktivitätsschätzungen führte als diejenigen, die Codezeilen verwendeten.

Funktionalität

Der Umfang der einem Produkt innewohnenden Funktionalität gibt das Maß für die Produktgröße an. Es gibt so viele verschiedene Methoden, um die Funktionalität von Softwareprodukten zu messen. Wir werden eine solche Methode - die Albrechtsche Funktionspunktmethode - im nächsten Kapitel diskutieren.

Funktionspunktmetriken bieten eine standardisierte Methode zum Messen der verschiedenen Funktionen einer Softwareanwendung. Es misst die Funktionalität aus Sicht des Benutzers, dh auf der Grundlage dessen, was der Benutzer anfordert und als Gegenleistung erhält. Die Funktionspunktanalyse ist eine Standardmethode zur Messung der Softwareentwicklung aus Anwendersicht.

Das ursprünglich von Albrecht konzipierte Funktionspunktmaß wurde mit der Gründung der International Function Point Users Group (IFPUG) im Jahr 1986 immer beliebter. Im Jahr 2002 wurden IFPUG-Funktionspunkte zu einem internationalen ISO-Standard - ISO / IEC 20926.

Was ist ein Funktionspunkt?

FP (Function Point)ist die am weitesten verbreitete Metrik für Funktionstypen, die zur Quantifizierung einer Softwareanwendung geeignet ist. Es basiert auf fünf vom Benutzer identifizierbaren logischen "Funktionen", die in zwei Datenfunktionstypen und drei Transaktionsfunktionstypen unterteilt sind. Für eine bestimmte Softwareanwendung wird jedes dieser Elemente quantifiziert und gewichtet, wobei seine charakteristischen Elemente wie Dateireferenzen oder logische Felder gezählt werden.

Die resultierenden Zahlen (nicht angepasstes FP) werden in hinzugefügte, geänderte oder gelöschte Funktionssätze gruppiert und mit dem Wertanpassungsfaktor (VAF) kombiniert, um die endgültige Anzahl von FP zu erhalten. Für jeden Zählungstyp wird eine eigene endgültige Formel verwendet: Anwendung, Entwicklungsprojekt oder Erweiterungsprojekt.

Anwendung der Albrechtschen Funktionspunktmethode

Lassen Sie uns nun verstehen, wie die Albrechtsche Funktionspunktmethode angewendet wird. Das Verfahren ist wie folgt:

Bestimmen Sie die Anzahl der Komponenten (EI, EO, EQ, ILF und ELF).

• EI- Die Anzahl der externen Eingänge. Dies sind elementare Prozesse, bei denen abgeleitete Daten die Grenze von außen nach innen überschreiten. Geben Sie in einem Beispielbibliotheksdatenbanksystem die Bibliotheksausweisnummer eines vorhandenen Benutzers ein.

• EO- Die Anzahl der externen Ausgaben. Dies sind elementare Prozesse, bei denen abgeleitete Daten die Grenze von innen nach außen überschreiten. Zeigen Sie in einem Beispielbibliotheksdatenbanksystem eine Liste der Bücher an, die einem Benutzer ausgecheckt wurden.

• EQ- Die Anzahl der externen Abfragen. Dies sind elementare Prozesse mit Eingabe- und Ausgabekomponenten, die zum Abrufen von Daten aus einer oder mehreren internen logischen Dateien und externen Schnittstellendateien führen. Bestimmen Sie in einem Beispielbibliotheksdatenbanksystem, welche Bücher derzeit an einen Benutzer ausgecheckt werden.

• ILF- Die Anzahl der internen Protokolldateien. Hierbei handelt es sich um vom Benutzer identifizierbare Gruppen logisch zusammengehöriger Daten, die sich vollständig innerhalb der Anwendungsgrenze befinden und über externe Eingaben verwaltet werden. In einem Beispielbibliotheksdatenbanksystem die Datei der Bücher in der Bibliothek.

• ELF- Die Anzahl der externen Protokolldateien. Hierbei handelt es sich um vom Benutzer identifizierbare Gruppen logisch zusammengehöriger Daten, die nur zu Referenzzwecken verwendet werden und sich vollständig außerhalb des Systems befinden. In einem Beispielbibliotheksdatenbanksystem die Datei, die Transaktionen im Abrechnungssystem der Bibliothek enthält.

Berechnen Sie die Anzahl der nicht angepassten Funktionspunkte (UFC).

• Bewerten Sie jede Komponente als low, average, oder high.

• Für Transaktionen (EI, EO, and EQ)basiert die Bewertung auf FTR und DET.

  • FTR - Die Anzahl der aktualisierten oder referenzierten Dateien.

  • DET - Die Anzahl der vom Benutzer erkennbaren Felder.

  • Basierend auf der folgenden Tabelle wird ein EI das auf 2 Dateien und 10 Datenelemente verweist, würde als eingestuft average.

FTRs	DETs
	1-5	6-15	>15
0-1	Niedrig	Niedrig	Durchschnittlich
2-3	Niedrig	Durchschnittlich	Hoch
>3	Durchschnittlich	Hoch	Hoch

• Für Dateien (ILF and ELF)Die Bewertung basiert auf dem RET und DET.

  • RET - Die Anzahl der vom Benutzer erkennbaren Datenelemente in einem ILF oder ELF.

  • DET - Die Anzahl der vom Benutzer erkennbaren Felder.

  • Basierend auf der folgenden Tabelle wird ein ILF das enthält 10 Datenelemente und 5 Felder würden als eingestuft high.

RETs	DETs
	1-5	6-15	>15
1	Niedrig	Niedrig	Durchschnittlich
2-5	Niedrig	Durchschnittlich	Hoch
>5	Durchschnittlich	Hoch	Hoch

• Konvertieren Sie Bewertungen in UFCs.

Bewertung	Werte
	EO	EQ	EI	ILF	ELF
Low	4	3	3	7	5
Average	5	4	4	10	7
High	6	5	6	15	10

Berechnen Sie die endgültige Funktionspunktzahl (FPC).

• Berechnen Sie den Wertanpassungsfaktor (VAF) basierend auf 14 allgemeinen Systemmerkmalen (GSC).

Allgemeine Systemmerkmale		Kurze Beschreibung
GSC 1	Datenkommunikation	Wie viele Kommunikationsmöglichkeiten stehen zur Verfügung, um die Übertragung oder den Austausch von Informationen mit der Anwendung oder dem System zu unterstützen?
GSC 2	Verteilte Datenverarbeitung	Wie werden verteilte Daten und Verarbeitungsfunktionen behandelt?
GSC 3	Performance	Wurde die Antwortzeit oder der Durchsatz vom Benutzer benötigt?
GSC 4	Stark genutzte Konfiguration	Wie stark wird die aktuelle Hardwareplattform genutzt, auf der die Anwendung ausgeführt wird?
GSC 5	Transaktionsrate	Wie häufig werden Transaktionen täglich, wöchentlich, monatlich usw. ausgeführt?
GSC 6	Online-Dateneingabe	Wie viel Prozent der Informationen werden online eingegeben?
GSC 7	Effizienz des Endbenutzers	War die Anwendung auf Effizienz des Endbenutzers ausgelegt?
GSC 8	Online-Update	Wie viele ILFs werden durch Online-Transaktionen aktualisiert?
GSC 9	Komplexe Verarbeitung	Verfügt die Anwendung über eine umfangreiche logische oder mathematische Verarbeitung?
GSC 10	Wiederverwendbarkeit	Wurde die Anwendung entwickelt, um die Anforderungen eines oder mehrerer Benutzer zu erfüllen?
GSC 11	Einfache Installation	Wie schwierig ist die Konvertierung und Installation?
GSC 12	Bedienungsfreundlichkeit	Wie effektiv und / oder automatisiert sind Start-, Sicherungs- und Wiederherstellungsverfahren?
GSC 13	Mehrere Seiten	Wurde die Anwendung speziell für die Installation an mehreren Standorten für mehrere Organisationen entwickelt, entwickelt und unterstützt?
GSC 14	Veränderung erleichtern	Wurde die Anwendung speziell entwickelt, entwickelt und unterstützt, um Änderungen zu erleichtern?

• Wiegen Sie jeden GSC auf einer Skala von 0 bis 5 basierend darauf, ob es keinen Einfluss auf starken Einfluss hat.

• Berechnen Sie die FPC wie folgt -

  FPC = UFC * (0,65+ (Summe ()GSC) * .01))

Komplexität

Komplexität ist eine separate Komponente der Größe. Es gibt zwei Arten -

• Complexity of a problem - Dies ist die Menge an Ressourcen, die für eine optimale Lösung des Problems erforderlich sind.

• Complexity of a solution- Es sind die Ressourcen, die zur Implementierung einer bestimmten Lösung benötigt werden. Es hat zwei Aspekte. Sie sind wie folgt -

  • Time complexity - Die Ressource ist Computerzeit.

  • Space complexity - Die Ressource ist Computerspeicher.

Komplexität messen

Ein Aspekt der Komplexität ist die Effizienz. Es misst jedes Softwareprodukt, das als Algorithmus modelliert werden kann.

Zum Beispiel: Wenn ein Algorithmus zum Lösen aller Instanzen eines bestimmten Problems erforderlich ist f(n) Berechnungen also f(n) ist asymptotisch optimal, wenn für jeden anderen Algorithmus mit Komplexität g das Problem gelöst wird f ist O(g). Dann ist die Komplexität des gegebenen Problems groß -O des asymptotisch optimalen Algorithmus für die Problemlösung.

Die Messung der strukturellen Eigenschaften einer Software ist wichtig für die Abschätzung des Entwicklungsaufwands sowie für die Wartung des Produkts. Die Struktur von Anforderungen, Design und Code hilft dabei, die Schwierigkeiten zu verstehen, die bei der Konvertierung eines Produkts in ein anderes, beim Testen eines Produkts oder bei der Vorhersage der externen Softwareattribute aus frühen internen Produktmaßnahmen auftreten.

Arten von Strukturmaßnahmen

Die Struktur der Software besteht aus drei Teilen. Sie sind -

• Control-flow structure - Dies ist die Reihenfolge, in der Anweisungen in einem Programm ausgeführt werden.

• Data-flow structure - Es ist das Verhalten der Daten, wenn sie mit dem Programm interagieren.

• Data structure - Es ist die Organisation der Datenelemente in Form von Listen, Warteschlangen, Stapeln oder anderen genau definierten Strukturen zusammen mit einem Algorithmus zum Erstellen, Ändern oder Löschen.

Messung der Kontrollflussstruktur

Die Kontrollflussmaße werden normalerweise mit einem gerichteten Graphen modelliert, wobei jeder Knoten oder Punkt Programmanweisungen entspricht und jeder Bogen oder jede gerichtete Kante den Kontrollfluss von einer Anweisung zur anderen anzeigt. Diese Diagramme werden als Kontrollflussdiagramm oder gerichtetes Diagramm bezeichnet.

Wenn ‘m’ ist ein strukturelles Maß, das im Hinblick auf das Flussdiagrammmodell und das if-Programm definiert ist A ist strukturell komplexer als Programm B, dann das Maß m(A) sollte größer sein als m(B).

Datenflussstruktur messen

Der Datenfluss oder Informationsfluss kann intermodular (Informationsfluss innerhalb der Module) oder intramodular (Informationsfluss zwischen einzelnen Modulen und dem Rest des Systems) sein.

Je nachdem, wie sich Daten durch das System bewegen, können sie wie folgt klassifiziert werden:

• Local direct flow - Wenn entweder ein Modul ein zweites Modul aufruft und Informationen an dieses weitergibt oder das aufgerufene Modul ein Ergebnis an den Aufrufer zurückgibt.

• Local indirect flow - Wenn das aufgerufene Modul Informationen zurückgibt, die anschließend an ein zweites aufgerufenes Modul übergeben werden.

• Global flow - Wenn Informationen über eine globale Datenstruktur von einem Modul zum anderen fließen.

Die Komplexität des Informationsflusses kann nach Henry und Kafura ausgedrückt werden als:

Information flow complexity (M) = length (M) × fan-in (M) × (fan-out (M))²

Wo,

• Fan-in (M) - Die Anzahl der lokalen Flüsse, die bei M + enden, die Anzahl der Datenstrukturen, aus denen die Informationen von M abgerufen werden.

• Fan–out (M) - Die Anzahl der lokalen Flüsse, die von M + ausgehen, die Anzahl der Datenstrukturen, die von M aktualisiert werden.

Datenstruktur messen

Datenstruktur kann beides sein local und global.

Locallywird der Strukturbetrag in jedem Datenelement gemessen. Ein graphentheoretischer Ansatz kann verwendet werden, um die Eigenschaften einzelner Datenstrukturen zu analysieren und zu messen. Dabei werden einfache Datentypen wie Ganzzahlen, Zeichen und Boolesche Werte als Primzahlen betrachtet und die verschiedenen Operationen berücksichtigt, mit denen wir komplexere Datenstrukturen erstellen können. Datenstrukturmaße können dann hierarchisch als Werte für die Primzahlen und Werte definiert werden, die den verschiedenen Operationen zugeordnet sind.

Globallywird eine Zählung der Gesamtzahl der benutzerdefinierten Variablen gemessen.

An der Entwicklung von SQA-Standards waren mehrere nationale und internationale Normungsinstitute, professionelle und branchenorientierte Organisationen beteiligt.

Die folgenden Institute und Organisationen sind die Hauptentwickler von SQA- und Software-Engineering-Standards -

• IEEE (Institut für Elektro- und Elektronikingenieure) Computer Society
• ISO (Internationale Organisation für Normung)
• DOD (US-Verteidigungsministerium)
• ANSI (American National Standards Institute)
• IEC (International Electro Technical Commission)
• UVP (Electronic Industries Association)

Diese Organisationen bieten aktualisierte internationale Standards für die Qualität der professionellen und Managementaktivitäten, die in Softwareentwicklungs- und Wartungsorganisationen durchgeführt werden.

Sie bieten auch eine SQA-Zertifizierung durch unabhängige professionelle Qualitätsprüfungen. Diese externen Audits bewerten die Erfolge bei der Entwicklung von SQA-Systemen und deren Implementierung. Die Zertifizierung, die nach den regelmäßigen Audits erteilt wird, ist nur bis zum nächsten Audit gültig und muss daher erneuert werden. Derzeit ist der ISO 9000-Zertifizierungsdienst der bekannteste Anbieter von SQA-Zertifizierungen in Europa und anderen Ländern.

Sie bieten auch die Tools zur Selbstbewertung des SQA-Systems und des Betriebs eines Unternehmens. Das vom Software Engineering Institute (SEI) der Carnegie Mellon University und ISO / IEC Std 15504 entwickelte Capacity Maturity Model (CMM) sind Beispiele für diesen Ansatz.

SQA-Standards

Software-Qualitätssicherungsstandards können in zwei Hauptklassen eingeteilt werden -

• Standards für das Qualitätssicherungsmanagement von Software, einschließlich Zertifizierungs- und Bewertungsmethoden (Qualitätsmanagementstandards)

• Standards für Softwareprojektentwicklungsprozesse (Projektprozessstandards)

Qualitätsmanagement-Standards

Diese konzentrieren sich auf das SQA-System, die Infrastruktur und die Anforderungen des Unternehmens und überlassen die Auswahl der Methoden und Tools dem Unternehmen. Mit Qualitätsmanagementstandards können Unternehmen kontinuierlich sicherstellen, dass ihre Softwareprodukte ein akzeptables Qualitätsniveau erreichen.

Example - ISO 9000-3 und das Capability Maturity Model (CMM)

Projektprozessstandards

Diese konzentrieren sich auf die Methoden zur Implementierung der Softwareentwicklungs- und Wartungsprojekte. Diese Standards umfassen Folgendes:

• Die Schritte, die unternommen werden müssen
• Anforderungen an die Konstruktionsdokumentation
• Inhalt der Konstruktionsunterlagen
• Entwurfsprüfungen und Überprüfungsprobleme
• Durchzuführende Softwaretests
• Themen testen

Natürlich können aufgrund ihrer Eigenschaften viele SQA-Standards in dieser Klasse als Software-Engineering-Standards dienen und umgekehrt.

Die Merkmale dieser beiden Normenklassen sind in der folgenden Tabelle zusammengefasst.

Eigenschaften	Qualitätsmanagement-Standards	Projektprozessstandards
Die Zieleinheit	Management der Softwareentwicklung, -wartung und der spezifischen SQA-Einheiten	Ein Projektteam für Softwareentwicklung und -wartung
Das Hauptaugenmerk	Organisation von SQA-Systemen, Infrastruktur und Anforderungen	Methoden zur Durchführung von Softwareentwicklungs- und Wartungsprojekten
Das Ziel des Standards	"Was" zu erreichen	"Wie man ausführt
Das Ziel des Standards	Sicherstellung der Softwarequalität des Lieferanten und Bewertung seiner Softwareprozessfähigkeit	Sicherstellung der Softwarequalität des Lieferanten und Bewertung seiner Softwareprozessfähigkeit Sicherstellung der Qualität eines bestimmten Softwareprojekts.
Beispiele	KMG nach ISO 9000-3 SEI	ISO / IEC 12207 IEEEStd 1012-1998

ISO 9001-Zertifizierung

ISO (die Internationale Organisation für Normung) ist ein weltweiter Verband nationaler Normungsgremien. Technische Komitees der ISO bereiten die internationalen Standards vor. ISO arbeitet in allen Fragen der elektrotechnischen Normung eng mit der Internationalen Elektrotechnischen Kommission (IEC) zusammen.

Internationale Standards werden gemäß den Regeln der ISO / IEC-Richtlinien, Teil 2, entworfen. Der Entwurf der von den technischen Komitees angenommenen internationalen Standards wird den Mitgliedsgremien zur Abstimmung übermittelt. ISO 9001 wurde vom Technischen Komitee ISO / TC 176, Qualitätsmanagement und Qualitätssicherung, Unterausschuss SC 2, Qualitätssysteme, erstellt.

Prozessansatz

Diese Internationale Norm fördert die Annahme eines Prozessansatzes bei der Entwicklung, Implementierung und Verbesserung der Wirksamkeit eines Qualitätsmanagementsystems, um die Kundenzufriedenheit durch Erfüllung der Kundenanforderungen zu steigern. Damit eine Organisation effektiv funktionieren kann, muss sie zahlreiche verknüpfte Aktivitäten ermitteln und verwalten. Eine Aktivität oder eine Reihe von Aktivitäten, die Ressourcen verwenden und verwaltet werden, um die Umwandlung von Eingaben in Ausgaben zu ermöglichen, kann als Prozess betrachtet werden.

Oft bildet die Ausgabe von einem Prozess direkt die Eingabe zum nächsten. Die Anwendung eines Prozesssystems innerhalb einer Organisation sowie die Identifizierung und Interaktion dieser Prozesse und deren Verwaltung zur Erzielung des gewünschten Ergebnisses können als bezeichnet werden“process approach”.

Ein Vorteil des Prozessansatzes ist die fortlaufende Kontrolle über die Verknüpfung der einzelnen Prozesse innerhalb des Prozesssystems sowie über deren Kombination und Interaktion. Bei Verwendung in einem Qualitätsmanagementsystem unterstreicht ein solcher Ansatz die Bedeutung der folgenden Punkte:

• Anforderungen verstehen und erfüllen
• Die Prozesse müssen im Hinblick auf den Mehrwert berücksichtigt werden
• Erhalten Sie die Ergebnisse der Prozessleistung und -effektivität
• Kontinuierliche Verbesserung von Prozessen basierend auf objektiven Messungen

ISO 9001 - Anwendung auf Software: die TickIT-Initiative

TickIT wurde Ende der 1980er Jahre von der britischen Softwareindustrie in Zusammenarbeit mit dem britischen Ministerium für Handel und Industrie eingeführt, um die Entwicklung einer Methodik zur Anpassung von ISO 9001 an die Merkmale der Softwareindustrie zu fördern, die als TickIT-Initiative bekannt ist.

TickIT ist außerdem auf Informationstechnologie (IT) spezialisiert. Es deckt das gesamte Spektrum der kommerziellen Softwareentwicklungs- und Wartungsdienste ab. TickIT, das jetzt von der DISC-Abteilung des BSI (British Standards Institute) verwaltet und gewartet wird, ist für die Zertifizierung von IT-Organisationen in Großbritannien und Schweden akkreditiert.

Seine Aktivitäten umfassen -

• Veröffentlichung des TickIT-Leitfadens, der die Bemühungen der Softwareindustrie zur Verbreitung der ISO 9001-Zertifizierung unterstützt. Der aktuelle Leitfaden (Ausgabe 5.0, TickIT, 2001), der Verweise auf ISO / IEC 12207 und ISO / IEC 15504 enthält, wird an alle TickIT-Kunden verteilt.

• Durchführung von prüfungsbasierten Bewertungen von Softwarequalitätssystemen und Beratung von Organisationen zur Verbesserung der Softwareentwicklungs- und -wartungsprozesse zusätzlich zu deren Verwaltung.

• Führen Sie ISO 9000-Zertifizierungsaudits durch.

TickIT-Prüfer, die prüfungsbasierte Bewertungen und Zertifizierungsprüfungen durchführen, sind im International Register of Certified Auditors (IRCA) registriert. Registrierte IRCA-Auditoren müssen unter anderem Erfahrung im Management und in der Softwareentwicklung haben. Sie müssen auch einen Auditorenkurs erfolgreich absolvieren.

Registrierte leitende Auditoren müssen nachweislich Erfahrung in der Durchführung und Leitung von TickIT-Audits haben.

Eine Softwareprozessbewertung ist eine disziplinierte Prüfung der von einer Organisation verwendeten Softwareprozesse auf der Grundlage eines Prozessmodells. Die Bewertung umfasst die Identifizierung und Charakterisierung aktueller Praktiken, die Identifizierung von Stärken und Schwächen sowie die Fähigkeit aktueller Praktiken, signifikante Ursachen für schlechte (Software-) Qualität, Kosten und Zeitplan zu kontrollieren oder zu vermeiden.

Es gibt drei Arten von Software-Bewertungen (oder Audits).

• EIN self-assessment (first-party assessment) wird intern vom eigenen Personal einer Organisation durchgeführt.

• EIN second-party assessment wird von einem externen Bewertungsteam durchgeführt oder die Organisation wird von einem Kunden bewertet.

• EIN third-party assessment wird von einer externen Partei durchgeführt oder (z. B. wenn ein Lieferant von einem Dritten bewertet wird, um seine Fähigkeit zu überprüfen, Verträge mit einem Kunden abzuschließen).

Softwareprozessbewertungen werden in einer offenen und kollaborativen Umgebung durchgeführt. Sie dienen der Organisation zur Verbesserung ihrer Softwareprozesse, und die Ergebnisse sind für die Organisation vertraulich. Die zu bewertende Organisation muss Mitglieder im Bewertungsteam haben.

Bewertung der Softwareprozessreife

Der Umfang einer Softwareprozessbewertung kann alle Prozesse in der Organisation, eine ausgewählte Teilmenge der Softwareprozesse oder ein bestimmtes Projekt abdecken. Die meisten standardbasierten Ansätze zur Prozessbewertung basieren ausnahmslos auf dem Konzept der Prozessreife.

Wenn das Bewertungsziel die Organisation ist, können die Ergebnisse einer Prozessbewertung unterschiedlich sein, selbst bei aufeinanderfolgenden Anwendungen derselben Methode. Es gibt zwei Gründe für die unterschiedlichen Ergebnisse. Sie sind,

• Die untersuchte Organisation muss bestimmt werden. Für ein großes Unternehmen sind mehrere Definitionen der Organisation möglich, und daher kann der tatsächliche Umfang der Bewertung bei aufeinanderfolgenden Bewertungen unterschiedlich sein.

• Selbst in scheinbar derselben Organisation kann die Stichprobe der Projekte, die zur Darstellung der Organisation ausgewählt wurden, den Umfang und das Ergebnis beeinflussen.

Wenn sich die Zielbewertungseinheit auf Projektebene befindet, sollte die Bewertung alle wichtigen Faktoren enthalten, die zum Erfolg oder Misserfolg des Projekts beitragen. Es sollte nicht durch festgelegte Dimensionen eines bestimmten Prozessreife-Modells begrenzt werden. Hier werden der Umsetzungsgrad und deren Wirksamkeit anhand der Projektdaten bewertet.

Die Prozessreife wird relevant, wenn eine Organisation beabsichtigt, eine allgemeine Strategie zur langfristigen Verbesserung zu entwickeln. Softwareprojektbewertungen sollten unabhängige Bewertungen sein, um objektiv zu sein.

Bewertungszyklus für Softwareprozesse

Laut Paulk und Kollegen (1995) verwendet der CMM-basierte Bewertungsansatz einen sechsstufigen Zyklus. Sie sind -

• Team auswählen - Die Mitglieder des Teams sollten Fachleute sein, die sich mit Softwareentwicklung und -verwaltung auskennen.

• Die Vertreter der zu bewertenden Site füllen den Standardfragebogen zur Prozessreife aus.

• Das Bewertungsteam führt eine Analyse der Fragebogenantworten durch und identifiziert die Bereiche, die eine weitere Untersuchung erfordern, gemäß den CMM-Schlüsselprozessbereichen.

• Das Bewertungsteam führt einen Besuch vor Ort durch, um ein Verständnis des Softwareprozesses zu erlangen, dem der Standort folgt.

• Das Bewertungsteam erstellt eine Liste mit Ergebnissen, in der die Stärken und Schwächen des Softwareprozesses des Unternehmens ermittelt werden.

• Das Bewertungsteam erstellt eine KPA-Profilanalyse (Key Process Area) und präsentiert die Ergebnisse dem entsprechenden Publikum.

Beispielsweise muss das Bewertungsteam von einem autorisierten SEI Lead Assessor geleitet werden. Das Team muss aus vier bis zehn Teammitgliedern bestehen. Mindestens ein Teammitglied muss aus der zu bewertenden Organisation stammen, und alle Teammitglieder müssen die Einführung des SEI in den CMM-Kurs (oder einen gleichwertigen Kurs) und den CBA IPI-Team-Schulungskurs des SEI absolvieren. Die Teammitglieder müssen auch einige Auswahlrichtlinien erfüllen.

In Bezug auf die Datenerfassung stützt sich das CBA IPI auf vier Methoden:

• Der Standard-Laufzeitfragebogen
• Einzel- und Gruppeninterviews
• Dokumentprüfungen
• Feedback aus der Überprüfung der Ergebnisentwürfe mit den Bewertungsteilnehmern

SCAMPI

Die Standard-CMMI-Bewertungsmethode zur Prozessverbesserung (SCAMPI) wurde entwickelt, um die Anforderungen des CMMI-Modells zu erfüllen (Software Engineering Institute, 2000). Es basiert auch auf dem CBA IPI. Sowohl das CBA IPI als auch das SCAMPI bestehen aus drei Phasen -

• Planen und vorbereiten
• Führen Sie die Bewertung vor Ort durch
• Ergebnisse melden

Die Aktivitäten für die Plan- und Vorbereitungsphase umfassen:

• Identifizieren Sie den Bewertungsumfang
• Entwickeln Sie den Bewertungsplan
• Bereiten Sie das Bewertungsteam vor und schulen Sie es
• Machen Sie eine kurze Einschätzung der Teilnehmer
• Verwalten Sie den CMMI-Bewertungsfragebogen
• Untersuchen Sie die Antworten auf den Fragebogen
• Führen Sie eine erste Dokumentenprüfung durch

Die Aktivitäten für die Bewertungsphase vor Ort umfassen:

• Führen Sie ein Eröffnungsmeeting durch
• Führen Sie Interviews durch
• Informationen konsolidieren
• Bereiten Sie die Präsentation der Ergebnisentwürfe vor
• Präsentieren Sie den Entwurf der Ergebnisse
• Konsolidieren, bewerten und bereiten Sie die endgültigen Ergebnisse vor

Die Aktivitäten der Berichtsergebnisphase umfassen:

• Präsentieren Sie die endgültigen Ergebnisse
• Führen Sie eine Exekutivsitzung durch
• Schließen Sie die Bewertung ab

Die IEEE-Definition für die Softwarequalitätssicherung lautet wie folgt:

"Ein geplantes und systematisches Muster aller Maßnahmen, die erforderlich sind, um ein ausreichendes Vertrauen in die Übereinstimmung eines Artikels oder Produkts mit den festgelegten technischen Anforderungen zu schaffen. Eine Reihe von Aktivitäten zur Bewertung des Prozesses, mit dem die Produkte entwickelt oder hergestellt werden."

Ziele der SQA-Aktivitäten

Die Ziele der SQA-Aktivitäten sind folgende:

In der Softwareentwicklung (prozessorientiert)

• Gewährleistung eines akzeptablen Vertrauens, dass die Software den funktionalen technischen Anforderungen entspricht.

• Gewährleistung eines akzeptablen Maßes an Vertrauen, dass die Software den Planungs- und Budgetanforderungen des Managements entspricht.

• Initiieren und Verwalten von Aktivitäten zur Verbesserung und Effizienz der Softwareentwicklung und der SQA-Aktivitäten.

In der Softwarewartung (produktorientiert)

• Mit akzeptablem Vertrauen sicherstellen, dass die Softwarewartungsaktivitäten den funktionalen technischen Anforderungen entsprechen.

• Sicherstellen, dass die Softwarewartungsaktivitäten mit akzeptablem Vertrauen den Planungs- und Budgetanforderungen des Managements entsprechen.

• Initiieren und Verwalten von Aktivitäten zur Verbesserung und Steigerung der Effizienz von Softwarewartungs- und SQA-Aktivitäten. Dies beinhaltet die Verbesserung der Aussichten, funktionale und Managementanforderungen zu erfüllen und gleichzeitig die Kosten zu senken.

Organisation zur Qualitätssicherung

Der organisatorische Rahmen für die Qualitätssicherung, der innerhalb der Organisationsstruktur funktioniert, umfasst die folgenden Teilnehmer:

Manager

• Führungskräfte des Top-Managements, insbesondere die direkt für die Software-Qualitätssicherung zuständige Führungskraft

• Abteilungsleiter für Softwareentwicklung und -wartung

• Abteilungsleiter für Softwaretests

• Projektmanager und Teamleiter von Entwicklungs- und Wartungsprojekten

• Leiter von Software-Testteams

Tester

• Mitglieder von Software-Testteams

SQA-Profis und interessierte Praktiker -

• SQA-Treuhänder
• Mitglieder des SQA-Komitees
• Mitglieder des SQA-Forums
• Mitglieder des SQA-Einheitenteams

Nur die Manager und Mitarbeiter der Softwaretestabteilung sind in Vollzeit mit der Ausführung von SQA-Aufgaben beschäftigt. Die anderen widmen einen Teil ihrer Zeit Qualitätsproblemen, sei es während der Erfüllung ihrer Führungsaufgaben oder beruflichen Aufgaben oder als Freiwillige in anderen, meistens als SQA-Komitee, SQA-Forum oder als SQA-Treuhänder.

Grundsätzlich gibt es in Softwareentwicklungsorganisationen eine dreistufige Managementstruktur -

• Top-Management
• Abteilungsleitung
• Projektmanagement

Verantwortlichkeiten des Top-Managements in Bezug auf Softwarequalität

Im Folgenden sind die Verantwortlichkeiten des Top-Managements bei der Sicherstellung der Softwarequalität aufgeführt:

• Sicherstellung der Qualität der Softwareprodukte und Softwarewartungsdienste des Unternehmens

• Kommunizieren Sie den Mitarbeitern auf allen Ebenen die Bedeutung der Produkt- und Servicequalität sowie die Kundenzufriedenheit

• Gewährleisten Sie ein zufriedenstellendes Funktionieren und die vollständige Einhaltung der Kundenanforderungen

• Stellen Sie sicher, dass Qualitätsziele für das SQA-System des Unternehmens festgelegt und dessen Ziele erreicht werden

• Initiieren Sie die Planung und überwachen Sie die Umsetzung der Änderungen, die zur Anpassung des SQA-Systems an wichtige interne und externe Änderungen in Bezug auf Kunden, Wettbewerb und Technologie des Unternehmens erforderlich sind

• Intervenieren Sie direkt, um die Lösung von Krisensituationen zu unterstützen und Schäden zu minimieren

• Stellen Sie die Verfügbarkeit der für SQA-Systeme erforderlichen Ressourcen sicher

Die folgenden Schritte können vom Top-Management unternommen werden, um seine Verantwortung zu erfüllen:

• Festlegen und Aktualisieren der Softwarequalitätsrichtlinie des Unternehmens.

• Beauftragung eines der Führungskräfte, z. B. des Vice President für SQA, als Verantwortlicher für Probleme mit der Softwarequalität

• Durchführung regelmäßiger Managementüberprüfungen der Leistung in Bezug auf Softwarequalitätsprobleme

Software-Qualitätsrichtlinie

Die Softwarequalitätsrichtlinie des Unternehmens sollte die folgenden Anforderungen enthalten:

• Konformität mit dem Zweck und den Zielen der Organisation

• Verpflichtung zu allgemeinen Konzepten zur Software-Qualitätssicherung

• Verpflichtung zu den von der Organisation festgelegten Qualitätsstandards

• Verpflichtung, angemessene Ressourcen für die Qualitätssicherung von Software bereitzustellen

• Verpflichtung zur kontinuierlichen Verbesserung der Qualität und Produktivität des Unternehmens

Der für Softwarequalität zuständige Geschäftsführer

Die Verantwortlichkeiten der für Softwarequalitätsprobleme zuständigen Führungskraft können wie folgt klassifiziert werden:

• Verantwortung für die Erstellung eines jährlichen SQA-Aktivitätenprogramms und Budgets

• Verantwortung für die Erstellung von SQA-Systementwicklungsplänen

• Gesamtkontrolle der Umsetzung des jährlichen SQA-Programms für reguläre Aktivitäten und der geplanten SQA-Entwicklungsprojekte

• Präsentation und Befürwortung von SQA-Themen gegenüber der Geschäftsleitung

Verantwortung für die Vorbereitung des jährlichen SQA-Aktivitätenprogramms

Dies erfordert, dass die Exekutive -

• Legen Sie die SQA-Ziele des Systems für das kommende Jahr fest

• Überprüfen Sie die von der SQA-Abteilung ausgearbeiteten Vorschläge für das jährliche Aktivitätenprogramm und überprüfen Sie das Potenzial des Vorschlags, die für das SQA-System festgelegten Ziele zu erreichen

• Stellen Sie fest, ob das Aktivitätenprogramm den Merkmalen und dem Umfang der für das kommende Jahr geplanten Dienstleistungen und Softwarekäufe von Subunternehmern entspricht

• Bestimmen Sie die Angemessenheit der Arbeitskräfte und anderer Ressourcen, die für die Umsetzung des SQA-Programms geplant sind

• Genehmigung der endgültigen Fassung des jährlichen SQA-Aktivitätenprogramms und des jährlichen Budgets

Verantwortung für die Erstellung von SQA-Systementwicklungsplänen

Diese Pläne müssen an die Veränderungen der technologischen sowie der Kundenanforderungen und des Wettbewerbs anpassbar sein. Die Verantwortlichkeiten umfassen -

• Überprüfung von Trends, die sich voraussichtlich in naher Zukunft auf die Softwarequalität des Unternehmens auswirken werden

• Überprüfen Sie Vorschläge für SQA-Anpassungen, z. B. die Vorbereitung neuer Verfahren, die den neuen Tools und SQA-Standards entsprechen

• Vorbereitung von Schulungsprogrammen für erfahrene Softwareentwicklungsteams und neu eingestellte Teammitglieder

• Entwicklung von Softwarequalitätsmetriken, die für die Bewertung der neuen Tools und Standards sowie für den Erfolg der Schulungsprogramme geeignet sind

• Genehmigung der endgültigen Version der geplanten SQA-Entwicklungsprojekte einschließlich ihrer Zeitpläne und Budgets

Gesamtkontrolle der Umsetzung des jährlichen SQA-Programms

Die verantwortliche Führungskraft ist verantwortlich für -

• Allgemeine Überwachung des jährlichen Aktivitätenprogramms

• Überprüfung des Fortschritts der SQA-Anpassungsprojekte

• Allgemeine Überwachung der Maßnahmen zur Verwirklichung der Qualitätsleistungen, die von den Zielen der Teams vorgegeben werden (basierend auf regelmäßigen Berichten)

• Überprüfung der Einhaltung der SQA-Verfahren und -Standards auf der Grundlage interner Qualitätsprüfungen

• Allgemeine Weiterverfolgung der Einhaltung von Zeitplänen und Budgets für Softwareentwicklungsprojekte

• Allgemeine Weiterverfolgung der Bereitstellung hochwertiger Wartungsdienste für externe und interne Kunden

Präsentation und Befürwortung von SQA-Fragen an die Geschäftsleitung

Um die Qualität zu fördern und die Schwierigkeiten des SQA-Systems zu lösen, sind Folgendes erforderlich:

• Präsentation zur endgültigen Genehmigung des vorgeschlagenen jährlichen Aktivitätenprogramms und des Budgets

• Präsentation zur endgültigen Genehmigung geplanter SQA-Anpassungsprojekte zusammen mit den entsprechenden Budgets

• Initiierung und Leitung von regelmäßigen Management-Review-Meetings, die der Softwarequalität des Unternehmens gewidmet sind

• Initiierung von Diskussionen auf Managementebene, die speziellen Ereignissen in Bezug auf Softwarequalität gewidmet sind, z. B. schwerwiegende Qualitätsmängel, Bedrohungen für den erfolgreichen Abschluss von Projekten aufgrund schwerwiegender Fachkräftemängel, Managementkrisen in der SQA-Abteilung usw.

Verantwortlichkeiten der Abteilungsleitung für SQA

Zu den Aufgaben der Qualitätssicherung des mittleren Managements gehören:

• Management des Software-Qualitätsmanagementsystems (qualitätssystembezogene Aufgaben)

• Verwaltung von Aufgaben im Zusammenhang mit Projekten und Dienstleistungen, die von Einheiten oder Teams unter der Autorität des jeweiligen Managers ausgeführt werden (projektbezogene Aufgaben)

Verantwortlichkeiten im Zusammenhang mit dem Qualitätssystem

Dazu gehören SQA-Aktivitäten, die auf Abteilungsebene durchgeführt werden sollen -

• Vorbereitung des jährlichen SQA-Aktivitätenprogramms und -budgets der Abteilung auf der Grundlage des von der SQA-Einheit erstellten empfohlenen Programms

• Erstellung der SQA-Systementwicklungspläne der Abteilung auf der Grundlage des von der SQA-Einheit erstellten empfohlenen Plans

• Kontrolle der Leistung des jährlichen SQA-Aktivitätenprogramms und der Entwicklungsprojekte der Abteilung

• Präsentation der SQA-Probleme der Abteilung vor dem Top-Management

Projektbezogene Verantwortlichkeiten

Diese variieren je nach den Verfahren und der Verteilung der Befugnisse der Organisation. sie beinhalten normalerweise -

• Kontrolle der Einhaltung der Qualitätssicherungsverfahren in den Abteilungen der Abteilung, einschließlich der CAB-, SCM- und SCCA-Stellen

• Detaillierte Weiterverfolgung der Ergebnisse der Vertragsüberprüfung und der Genehmigung von Vorschlägen

• Überprüfung der Leistung der geplanten Überprüfungsaktivitäten; Genehmigung von Projektdokumenten und Abschluss der Projektphase

• Follow-up von Softwaretests und Testergebnissen; Genehmigung der Softwareprodukte des Projekts

• Verfolgung des Fortschritts von Zeitplänen für Softwareentwicklungsprojekte und Budgetabweichungen

• Beratung und Unterstützung von Projektmanagern bei der Lösung von Zeitplan-, Budget- und Kundenbeziehungsproblemen

• Nachverfolgung der Qualität der Bereitstellung von Wartungsdiensten

• Detaillierte Nachverfolgung der Projektrisiken und ihrer Lösungen

• Verfolgung der Einhaltung der Kundenanforderungen und der Kundenzufriedenheit durch das Projekt

• Genehmigung großer Software-Änderungsaufträge und erheblicher Abweichungen von den Projektspezifikationen

Verantwortlichkeiten des Projektmanagements für die Softwarequalität

Die meisten Verantwortlichkeiten für das Projektmanagement sind in Verfahren und Arbeitsanweisungen definiert. Der Projektmanager ist dafür verantwortlich, dass alle Teammitglieder die genannten Verfahren und Anweisungen einhalten.

Zu seinen Aufgaben gehören professionelle praktische und Managementaufgaben, insbesondere die folgenden:

• Professional hands-on tasks

  • Erstellung von Projekt- und Qualitätsplänen und deren Aktualisierungen

  • Teilnahme am gemeinsamen Kunden-Lieferanten-Ausschuss

  • Enge Überwachung der Mitarbeiter des Projektteams, einschließlich der Einstellung, Schulung und Unterweisung

• Management tasks

  Projektmanager befassen sich mit den Folgeproblemen wie -

  • Durchführung von Überprüfungsaktivitäten und die daraus resultierenden Korrekturen

  • Leistungs-, Integrations- und Systemtestaktivitäten der Softwareentwicklungs- und Wartungseinheit sowie Korrektur- und Regressionstests

  • Durchführung von Abnahmetests

  • Softwareinstallation an entfernten Kundenstandorten und Ausführung des Softwaresystems durch den Kunden

  • SQA-Schulung und Unterweisung der Mitglieder des Projektteams

  • Zeitpläne und Ressourcen für Projektaktivitäten

  • Kundenwünsche und Zufriedenheit

  • Entwicklung von Projektentwicklungsrisiken, Anwendung von Lösungen und Kontrolle der Ergebnisse

Die Struktur der SQA-Einheit variiert je nach Typ und Größe der Organisation. Die folgende Abbildung zeigt ein Beispiel einer Standardstruktur und aller Komponenten unter einer SQA-Einheit. In diesem Kapitel werden die Rollen und Verantwortlichkeiten der einzelnen Untereinheiten erläutert.

Aufgaben, die vom Leiter der SQA-Einheit ausgeführt werden

Der Leiter der SQA-Einheit ist für alle Qualitätssicherungsaufgaben verantwortlich, die von der SQA-Einheit und ihren Untereinheiten ausgeführt werden. Diese Aufgaben können in folgende Kategorien eingeteilt werden:

• Planungsaufgaben
• Verwaltung der Einheit
• SQA berufliche Aktivitäten

Planungsaufgaben

• Vorbereitung des vorgeschlagenen jährlichen Aktivitätsprogramms und des Budgets für die Einheit

• Planung und Aktualisierung des Software-Qualitätsmanagementsystems des Unternehmens

• Vorbereitung der empfohlenen jährlichen SQA-Aktivitätsprogramme und SQA-Systementwicklungspläne für die Abteilungen Softwareentwicklung und -wartung

Verwaltungsaufgaben

• Management der Aktivitäten des SQA-Teams

• Überwachung der Umsetzung des SQA-Aktivitätsprogramms

• Nominierung von Teammitgliedern, SQA-Komiteemitgliedern und SQA-Treuhändern

• Erstellung von speziellen und regelmäßigen Berichten, z. B. dem Status von Softwarequalitätsproblemen innerhalb des Unternehmens und monatlichen Leistungsberichten

SQA Professionelle Aktivitäten

• Teilnahme an gemeinsamen Projektausschüssen
• Teilnahme an formellen Designprüfungen
• Überprüfung und Genehmigung von Abweichungen von den Spezifikationen
• Beratung mit Projektmanagern und Teamleitern
• Teilnahme an SQA-Komitees und Foren

Projektlebenszyklus SQA

SQA-Aufgaben, die sich auf die Untereinheit des Projektlebenszyklus beziehen, können in zwei Gruppen eingeteilt werden:

• „Reine“ Management-Follow-up- und Genehmigungsaufgaben (Projektlebenszyklus-Kontrollaufgaben)

• "Hands-on" oder aktive Teilnahme an SQA-Aktivitäten des Projektteams, bei denen professionelle Beiträge erforderlich sind (Teilnahmeaufgaben)

Aufgaben zur Steuerung des Projektlebenszyklus

• Weiterverfolgung der Einhaltung der SQA-Verfahren und Arbeitsanweisungen durch das Entwicklungs- und Wartungsteam

• Genehmigung oder Empfehlung von Softwareprodukten gemäß den einschlägigen Verfahren

• Überwachung der Bereitstellung von Softwarewartungsdiensten für interne und externe Kunden

• Überwachung der Kundenzufriedenheit und Aufrechterhaltung des Kontakts zu den Vertretern der Qualitätssicherung des Kunden

Teilnahmeaufgaben

Diese Aufgaben umfassen die Teilnahme an -

• Vertragsüberprüfungen
• Vorbereitung und Aktualisierung von Projektentwicklungs- und Qualitätsplänen
• Formale Designprüfungen
• Formale Entwurfsprüfungen von Subunternehmern
• Softwaretests, einschließlich Kundenakzeptanztests
• Software-Abnahmetests für Softwareprodukte von Subunternehmern
• Installation neuer Softwareprodukte

Aufgaben für den Betrieb von SQA-Infrastrukturen

SQA-Systeme verwenden eine Vielzahl von Infrastrukturkomponenten, um reibungslos zu funktionieren, nämlich -

• Verfahren und Arbeitsanweisungen
• Unterstützung von Qualitätsgeräten (Vorlagen, Checklisten)
• Schulung, Unterweisung und Zertifizierung des Personals
• Vorbeugende und korrigierende Maßnahmen
• Konfigurationsmanagement
• Dokumentationskontrolle

Insbesondere umfassen die Aufgaben der SQA-Untereinheit in Bezug auf diese Komponenten:

• Veröffentlichung aktualisierter Versionen von Verfahren, Arbeitsanweisungen, Vorlagen, Checklisten usw. sowie deren Verbreitung in Papierform und / oder auf elektronischem Wege

• Übermittlung von Schulungen und Anweisungen zur Einhaltung und Anwendung von SQA-Verfahren, Arbeitsanweisungen und ähnlichen Elementen an neue und aktuelle Mitarbeiter

• Unterweisung von SQA-Treuhändern unter anderem in Bezug auf neue und überarbeitete Verfahren sowie Entwicklungswerkzeuge und -methoden

• Überwachung und Unterstützung der Umsetzung neuer und überarbeiteter SQA-Verfahren

• Weiterverfolgung der Zertifizierungsaktivitäten des Personals

• Vorschlag von Themen, die vorbeugende und korrigierende Maßnahmen erfordern, einschließlich der Teilnahme an CAB-Ausschüssen

• Follow-up der Konfigurationsmanagementaktivitäten, einschließlich der Teilnahme an CCA-Komitees

• Weiterverfolgung der Einhaltung der Dokumentationsverfahren und Arbeitsanweisungen

Interne Audit- und Zertifizierungsaufgaben von SQA

Die Arten von SQA-Audits, die in oder von Softwareorganisationen durchgeführt werden, können wie folgt klassifiziert werden:

• Interne Audits

• Audits von Subunternehmern und Lieferanten zur Bewertung ihrer SQA-Systeme

• Externe Audits durch Zertifizierungsstellen

• Externe Audits von Kunden, die das SQA-System bewerten möchten, bevor sie die Organisation als Lieferanten akzeptieren

Die ersten beiden Prüfungsklassen werden von der SQA-Untereinheit initiiert und durchgeführt, die letzten beiden von externen Stellen.

Die SQA-Einheit führt die folgenden Aufgaben für interne SQA-Audits aus

• Vorbereitung von Jahresprogrammen für interne SQA-Audits

• Durchführung interner SQA-Audits

• Weiterverfolgung von Korrekturen und Verbesserungen, die von den geprüften Teams und anderen Einheiten durchzuführen sind

• Erstellung regelmäßiger zusammenfassender Berichte über den Stand der Prüfungsergebnisse, einschließlich Empfehlungen für Verbesserungen

Die SQA-Einheit führt die folgenden Aufgaben für Audits von Subunternehmern und Lieferanten aus:

• Vorbereitung des Jahresprogramms für SQA-Audits von Subunternehmern und Lieferanten

• Durchführung von SQA-Audits von Subunternehmern und Lieferanten

• Nachverfolgung von Korrekturen und Verbesserungen durch die geprüften Subunternehmer und Lieferanten

• Erhebung von Daten zur Leistung von Subunternehmern und Lieferanten aus internen und externen Quellen

• Regelmäßige Bewertung der SQA-Systeme der zertifizierten Subunternehmer und Lieferanten der Organisation auf der Grundlage von Prüfungsberichten und Informationen, die aus anderen internen und externen Quellen gesammelt wurden. Der Bewertungsbericht enthält -

  • Empfehlungen zur Zertifizierung von Subunternehmern und Lieferanten

  • Externe Audits, die von Zertifizierungsstellen durchgeführt werden, umfassen die folgenden Aufgaben:

    • Koordination des Inhalts und des Zeitplans des Zertifizierungsaudits

    • Vorbereitung der von den Zertifizierungsstellen festgelegten Dokumente

    • Unterweisung der geprüften Teams und Durchführung der für Zertifizierungsaudits erforderlichen Vorbereitungen

    • Teilnahme an Zertifizierungsaudits

    • Stellen Sie sicher, dass die erforderlichen Korrekturen und Verbesserungen durchgeführt werden

SQA-Audits, die von den Kunden des Unternehmens durchgeführt werden, beinhalten folgende Aufgaben:

• Koordination der Inhalte und des Zeitplans der Prüfung

• Vorbereitung der vom Wirtschaftsprüfer des Kunden festgelegten Unterlagen

• Einweisung der geprüften Teams und Durchführung der Vorbereitungen, die für die SQA-Prüfungen durch die Kunden der Organisation erforderlich sind

• Teilnahme an den Audits

• Stellen Sie sicher, dass die erforderlichen Korrekturen und Verbesserungen durchgeführt werden

SQA-Supportaufgaben

Die meisten Verbraucher von SQA-Supportdiensten befinden sich innerhalb der Organisation. Dazu gehören Projektmanager, Teamleiter und SQA-Treuhänder. Ihre Aufgaben umfassen -

• Erstellung von Projektplänen und Projektqualitätsplänen

• Personalüberprüfungsteams

• Auswahl von Maßnahmen zur Lösung identifizierter Softwareentwicklungsrisiken

• Auswahl von Maßnahmen zur Behebung von Zeitplanverzögerungen und Budgetüberschreitungen

• Auswahl an SQA-Metriken und Softwarekostenkomponenten

• Verwendung des SQA-Informationssystems

• Auswahl von Entwicklungsmethoden und -werkzeugen, die die von der SQA-Einheit gesammelten Daten zur Fehlererfahrung widerspiegeln

Aufgaben zu SQA-Standards und -Verfahren

Die SQA-Untereinheit ist eng in die Entscheidung eingebunden, welche SQA-Standards übernommen werden, sowie in die Entwicklung und Aufrechterhaltung der Verfahren der Organisation. Um die damit verbundenen Verpflichtungen zu erfüllen, muss die SQA-Einheit -

• Bereiten Sie ein Jahresprogramm für die Entwicklung neuer Verfahren und Verfahrensaktualisierungen vor

• Seien Sie verantwortlich für die Entwicklung neuer Verfahren und Verfahrensaktualisierungen unter Teilnahme an geeigneten Ausschüssen und Foren

• Weiterverfolgung der Entwicklungen und Änderungen der SQA- und Software-Engineering-Standards; Einführung zusätzlicher organisationsrelevanter Verfahren und Änderungen

• Initiieren Sie Aktualisierungen und Anpassungen von Verfahren als Reaktion auf Änderungen der beruflichen Standards, einschließlich der Annahme oder Löschung von Standards, die von der Organisation angewendet werden

SQA Engineering-Aufgaben

Das Follow-up des beruflichen Fortschritts, die Lösung betrieblicher Schwierigkeiten und die fachmännische Analyse von Fehlern sind die unmittelbaren Ziele dieser SQA-Untereinheit.

Daher umfassen die wichtigsten technischen Aufgaben Folgendes:

• Testen von Qualitäts- und Produktivitätsaspekten in Bezug auf neue Entwicklungstools und neue Versionen der derzeit verwendeten Entwicklungstools

• Bewertung der Qualität und Produktivität neuer Entwicklungs- und Wartungsmethoden sowie Methodenverbesserungen

• Entwicklung von Lösungen für Schwierigkeiten bei der Anwendung der derzeit verwendeten Softwareentwicklungstools und -methoden

• Entwicklung von Methoden zur Messung der Softwarequalität und der Teamproduktivität

• Bereitstellung von technologischer Unterstützung für CAB-Komitees bei der Analyse von Softwareentwicklungsfehlern und der Formulierung vorgeschlagener Lösungen

Aufgaben von SQA-Informationssystemen

SQA-Informationssysteme sollen die Funktionsweise von SQA-Systemen erleichtern und verbessern. Die damit verbundenen Aufgaben umfassen -

• Entwicklung von SQA-Informationssystemen für Softwareentwicklungs- und Wartungseinheiten für

  • Sammlung von Aktivitätsdaten

  • Verarbeitung von beispielsweise periodischen Berichten, Listen, Ausnahmeberichten und Abfragen

  • Verarbeitung von beispielsweise periodischen Berichten, Listen, Ausnahmeberichten und Abfragen

• Entwicklung von SQA-Informationssystemen, die die Verarbeitung von Informationen durch Softwareentwicklungs- und Wartungseinheiten durch die SQA-Einheit erleichtern, einschließlich Schätzungen der Softwarequalitätsmetriken und der Softwarequalitätskosten

• Aktualisieren von SQA-Informationssystemen

• Entwicklung und Wartung der SQA Internet / Intranet Site der Organisation

SQA-Treuhänder und ihre Aufgaben

SQA-Treuhänder sind diejenigen Mitglieder, die hauptsächlich an der Förderung der Softwarequalität beteiligt sind. Diese Mitglieder bieten die interne Unterstützung, die für die erfolgreiche Implementierung von SQA-Komponenten erforderlich ist.

Ihre Aufgaben können je nach Organisation variieren. Dementsprechend kann es sich um einheitenbezogene und / oder organisationsbezogene Aufgaben handeln.

Einheitenbezogene Aufgaben

• Unterstützung der Kollegen bei der Lösung der Schwierigkeiten bei der Implementierung von Softwarequalitätsverfahren und Arbeitsanweisungen

• Unterstützung des Abteilungsleiters bei der Ausführung entsprechender SQA-Aufgaben

• Förderung der Einhaltung und Überwachung der Umsetzung von SQA-Verfahren und Arbeitsanweisungen durch Kollegen

• Melden Sie der SQA-Abteilung wesentliche und systematische Verstöße

• Melden Sie schwerwiegende Softwarequalitätsfehler an die SQA-Einheit

Organisationsbezogene Aufgaben

• Auslösen von Änderungen und Aktualisierungen von organisationsweiten SQA-Verfahren und Arbeitsanweisungen

• Auslösen von Verbesserungen der Entwicklungs- und Wartungsprozesse in der Organisation

• Initiieren Sie beim CAB Anträge bezüglich Lösungen für wiederkehrende Fehler, die in den jeweiligen Einheiten beobachtet wurden

• Identifizieren Sie den SQA-Schulungsbedarf im gesamten Unternehmen und schlagen Sie ein geeignetes Schulungs- oder Unterrichtsprogramm vor, das von der SQA-Einheit durchgeführt werden soll

SQA-Komitees und ihre Aufgaben

SQA-Ausschüsse können entweder permanent oder ad hoc sein. Die Aufgaben können von Organisation zu Organisation erheblich variieren.

• Permanent committees befassen sich üblicherweise mit SCC (Software Change Control), CA (Korrekturmaßnahmen), Verfahren, Methodenentwicklungstools und Qualitätsmetriken.

• Ad hoc committees In der Regel werden bestimmte Fälle von allgemeinem Interesse behandelt, z. B. das Aktualisieren eines bestimmten Verfahrens, die Analyse und Lösung eines Softwarefehlers, das Ausarbeiten von Softwaremetriken für einen bestimmten Prozess oder ein bestimmtes Produkt, das Aktualisieren der Softwarequalitätskosten und der Datenerfassungsmethoden für ein bestimmtes Problem.

Ständige SQA-Ausschüsse sind integraler Bestandteil des SQA-Organisationsrahmens. Ihre Aufgaben und ihr Betrieb werden normalerweise in den SQA-Verfahren der Organisation definiert.

Ad-hoc-Ausschüsse werden kurzfristig pro Problem eingerichtet. Die Mitglieder werden von der für Softwarequalitätsfragen zuständigen Exekutive, dem Leiter der SQA-Abteilung, den SQA-Untereinheiten, ständigen SQA-Ausschüssen oder einem anderen initiierten Gremium ernannt seine Bildung und hat ein Interesse an der Arbeit. Dieses Gremium definiert auch die Aufgaben des Ad-hoc-Ausschusses.