Softwareerstellung: Wie kann man sein Design bewerten und produktiver sein?

Die Bewertung und Bezifferung des Softwaredesigns, insbesondere des Umfangs, des Aufwands, der Kosten und der beteiligten Zeiträume, ist häufig die Quelle lebhafter Diskussionen unter Softwarebewertern. Für diese Tätigkeit sind in der Regel die Projektmanager verantwortlich.

Die Softwareentwicklung konzentriert mehrere verschiedene Aktivitäten, die Spezialwissen erfordern, z. B. Erfassung, Erstellung und Auswertung von Daten.Analyse und Verwaltung von Anforderungen; Softwaredesign, Codierung und unabhängige Verifizierung und Validierung (IV&V); Implementierung, Einsatz, Installation und Inbetriebnahme. Jede dieser Aktivitäten wird von einer qualifizierten Person durchgeführt, die dabei auf verschiedene, mehr oder weniger komplexe Werkzeuge zurückgreift.

Alle Software Vendor Software ansehen

Was ist Produktivität? Definition

Produktivität ist definiert als die Produktionsrate bei gegebenen Inputs. Die Produktivität wird in "soundsoviel Produktionseinheiten pro Tag" oder "soundsoviel Produktionseinheiten pro Stunde" ausgedrückt. Die Produktivität wird auch als das Verhältnis zwischen Inputs und Outputs definiert.

Im Kontext dieses Artikels bezieht sich die Produktivität auf die Rate, mit der eine Outputeinheit mithilfe einer Reihe von Inputs für eine bestimmte Zeit produziert.

Probleme bei der Bewertung der Größe einer Software

Innerhalb der heutigen IT-Industrie gibt es verschiedene Einheiten, um die Größe einer Software zu messen. Zu diesen Einheiten gehören z. B. Funktionspunkte, Use Case Points (UCP), Objektpunkte, Funktionspunkte, Internetpunkte, Testpunkte, Funktionspunktanalyse (FPA), Codezeilen (LOC) etc. Es gibt kein festgeschriebenes Maß, mit dem die Größe einer Software in eine dieser Einheiten umgerechnet werden kann.

Seltsamerweise wird bei diesen Messungen die Größe der Software angepasst (erhöht oder verringert), abhängig von Faktoren wie der Komplexität. Dennoch ist die Größe ein unveränderliches Merkmal. Ein Kilo Käse wird zum Beispiel nicht schwerer oder leichter, wenn die Person, die es wiegt, mehr oder weniger Erfahrung im Wiegen hat oder wenn die Waage mechanisch oder elektronisch ist. Nehmen wir ein anderes Beispiel: Ein Kilometer bleibt ein Kilometer, egal ob ein junger oder ein älterer Mensch diese Strecke zu Fuß zurücklegt oder ob die Strecke auf einer Autobahn oder einer belebten Straße gemessen wird.

Allerdings ändert sich die Geschwindigkeit, mit der die Ergebnisse erzielt werden. Wenn man die obigen Beispiele heranzieht, wird der ältere Mensch den Kilometer sicherlich langsamer zurücklegen als der jüngere. Außerdem legt man einen Kilometer auf der Autobahn schneller zurück als in der Stadt.

Darüber hinaus besteht keine Einigkeit darüber, wie LOCs gezählt werden sollen. Sollten logische oder physische Aussagen gezählt werden? Und wie behandelt man Online-Dokumentation? Sollte sie berücksichtigt werden oder nicht?

Dies sind einige der Hauptprobleme bei der Bewertung der Größe einer Software.

Bedenken hinsichtlich der Produktivität

Die Softwarebranche ist besessen von der Möglichkeit, eine einzige, empirische Produktivitätsrate zu nennen, die alle Aktivitäten zusammenfasst.

Es wurden Versuche unternommen, die Produktivität als 10 Personenstunden pro Funktionspunkt zu definieren, wobei jedoch behauptet wird, dass die Produktivitätsrate in der Praxis nicht höher ist als in der Praxis.Die Einheit Personenstunde pro Funktionspunkt kann jedoch je nach Größe des Produkts, des Teams und anderer Faktoren zwischen 2 und 135 variieren. "Produktivität definieren" bedeutet, eine Zahl zuzuordnen, die den Aufwand in Personenstunden darstellt, der für die Entwicklung einer Software-Größeneinheit erforderlich ist, um die Software-Größe (in Funktionspunkten) in Entwicklungsaufwand (in Personenstunden) umrechnen zu können. Manchmal werden Intervalle gewählt, z. B. fünfzehn bis dreißig Stunden pro CPU. Zu anderen Zeiten werden empirische Formeln auf der Grundlage einer Reihe von Faktoren erstellt, wie im Fall des "constructive cost model" (COCOMO).

Das Problem dieser Produktivitätsmaße ist, dass sie alle Aktivitäten - Bedarfsanalyse, Design, Review, Tests usw. - in einem einzigen Maßstab zusammenfassen. - in einer einzigen Messung zusammengefasst werden. Dabei sind die für diese Aufgaben erforderlichen Fähigkeiten ebenso unterschiedlich wie die verwendeten Werkzeuge, der Input und der Output. Sie unter dem Titel "Softwareentwicklung" zusammenzufassen und ein einziges Maß für die Produktivität anzugeben, kann nur eine sehr grobe und niemals eine genaue Schätzung ermöglichen.

Software besser und schneller entwickeln: Wie kann man produktiver werden?

Bei der Softwareentwicklung kommen folgende Aktivitäten zum Einsatz:

• Aktivitäten zur Vorbereitung des Projekts, z. B. Machbarkeitsstudien, Finanzbudgetierung und Projektfreigabe (finanzielle und technische Genehmigung sowie "Projektstart").
• Aktivitäten zur Einleitung des Projekts, wie die Identifizierung des Projektleiters, die Bildung eines Projektteams und die Einrichtung der Entwicklungsumgebung ; die Projektplanung; die Einrichtung verschiedener Protokolle, d. h. Service Level Agreements (SLAs) und Schritte in Bezug auf Fortschrittsberichte; projektbezogene Schulungen.
• Software-Engineering-Aktivitäten, einschließlich der Analyse der Nutzerbedürfnisse; Software-Anforderungsanalyse; Software-Design, Codierung und Unit-Tests.; verschiedene Arten von Integrationstests, Funktionstests, Negativtests, System- und Akzeptanztests; Erstellung der Dokumentation.
• Einsatzaktivitäten, einschließlich der Installation der Hardware und des Systems; Erstellung der Datenbank; ?Installation der Anwendungssoftware; Durchführung von Pilotversuchen; Schulung der Nutzer; Parallelphase und tatsächliche Bereitstellung.
• Aktivitäten zum Abschluss des Projekts, einschließlich der Dokumentation guter und schlechter Praktiken; Analyse des Projekts (Projektabschluss); Archivierungsunterlagen; Veröffentlichung von Ressourcen; Entlassung des Projektleiters aus seinen Verpflichtungen; Beginn der Softwarewartung.

Wenn wir über die "Grundregeln" der Industrie (akzeptierte Verfahren, die auf gesundem Menschenverstand beruhen) in Bezug auf die Produktivität sprechen, ist es schwierig, die Aktivitäten zu bestimmen, die in die Produktivitätsrate einbezogen werden. Niemand würde auf die Messung der Produktivität wetten, obwohl es sich dabei um eine Grundregel der Branche handelt.

Werfen wir einen Blick auf die Art dieser Aktivitäten :

1. Anforderungsanalyse: Verstehen und Dokumentieren, was der Benutzer braucht, was er will und was er erwartet, damit die Softwareentwickler es vollständig verstehen und ein System unter strikter Einhaltung der genannten Anforderungen entwerfen können. Die Abhängigkeit von externen Faktoren ist hoch.
2. Software-Design: Berücksichtigung der verschiedenen Optionen für Hardware, Systemsoftware und Entwicklungsplattform; optimale Auswahl für jede Option; Entwurf einer Architektur, die den genannten Anforderungen und den Erwartungen der Kunden entspricht. Die Architektur muss mit der aktuellen Technologie kompatibel sein und das Design muss so dokumentiert werden, dass die Programmierer es verstehen und ein Produkt liefern, das den ursprünglichen Spezifikationen des Benutzers entspricht. Es gibt mehrere Alternativen, und da die Softwareentwicklung eine wichtige und strategische Aktivität ist, haben Fehler schwerwiegende Folgen.
3. Codierung: Entwicklung eines Softwarecodes, der mit dem Entwurf übereinstimmt und möglichst wenige Fehler enthält (es ist so leicht, unbeabsichtigt "Bugs" darin zu hinterlassen).
4. Code-Review: Studieren Sie den von einem anderen Programmierer geschriebenen Code, entschlüsseln Sie seine Funktionalität und versuchen Sie, Fehler vorherzusagen, auf die der Kunde bei der Nutzung der Software stoßen könnte.
5. Testen: Versuchen, alle Fehler zu entdecken, die in der Software zurückgelassen werden könnten. Allerdings ist es unmöglich, fast alle Fehler zu finden. Außerdem ist das Testen der gesamten Software eine unpraktische Tätigkeit.

Da die Art dieser Tätigkeiten so unterschiedlich ist, liegt es auf der Hand, dass die Produktivität für jede dieser Tätigkeiten nicht einheitlich ist (und daher nicht mit der gleichen Zahl beschrieben werden kann). Das Arbeitstempo ist für jede dieser Tätigkeiten unterschiedlich.

Sie hängen nicht von der Menge des produzierten Codes ab, sondern von anderen Faktoren, wie z. B. :

1. Anforderungen, die von der Effizienz und Klarheit ihrer Quelle (Benutzer oder Dokumentation) abhängen.
2. das Design, das von der Komplexität der Verarbeitung, den verfügbaren Alternativen und den Einschränkungen abhängt, nach denen die Funktionalität gestaltet werden soll.
3. die Überarbeitung des Codes, die vom Codierungsstil abhängt
4. die Kontrolle, die davon abhängt, wie der Code geschrieben wird (je mehr Fehler es gibt, desto mehr Zeit wird für das Testen und erneute Testen benötigt).
5. die Codierung selbst, die von der Qualität des Designs abhängt.

Daher müssen wir für jede dieser Tätigkeiten unterschiedliche Produktivitätszahlen festlegen.

Versuchen wir, eine Parallele für die Industrie zu ziehen, zum Beispiel mit dem Stanzen. Die durchzuführenden Tätigkeiten sind: 1) Einrichten der Maschine; 2) Einrichten der Werkzeuge; 3) Laden der Aufgabe; 4) Stanzen des Lochs; 5) Entgraten des Lochs; 6) Reinigen; 7) Liefern des Bogens für den nächsten Arbeitsgang.

Wenn mehrere Löcher gestanzt werden, verringert sich die Zeit "pro Loch", da es sich bei den Konfigurationsaktivitäten um punktuelle Tätigkeiten handelt.

Betrachtet man also beispielsweise die Codierung einer Einheit, so könnten die auszuführenden Aktivitäten sein: 1) Anweisungen erhalten; 2) das Designdokument studieren; 3) die Einheit codieren; 4) die Einheit auf die spezifische Funktionalität testen und debuggen; 5) die Einheit für einen bestimmten Zweck testen und debuggen.Einheit für eine beliebige Verwendung; 6) Entfernen von unnötigem Code aus der Einheit; 7) Durchführen eines Regressionstests der Einheit; 8) Übertragen der Einheit in den nächsten Schritt.

Ebenso können wir für jede Phase der Softwareentwicklung Mikroaktivitäten vorschlagen.

Zahlen im Zusammenhang mit der Produktivität: empirisch oder auf der Grundlage einer methodischen Studie?

Jede der oben genannten Aktivitäten zeigt eine andere Erfolgsquote. Für jede dieser Aktivitäten sollten Standardzeiten festgelegt werden. Sobald dies geschehen ist, sollten Arbeitsstudientechniken wie die Synthese oder die analytische Schätzung verwendet werden, um die Gesamtdauer des Auftrags zu schätzen.

Unabhängig davon, ob Zeitstudientechniken zur Durchführung individueller Produktivitätsstudien oder zum Sammeln empirischer Daten verwendet werden, ist die Softwareentwicklung weder völlig mechanisch noch völlig kreativ. Es ist auch unrealistisch, Aktivitäten mit einer starken kreativen Komponente zu planen; Arbeitsstudienmethoden berücksichtigen diesen Aspekt der Softwareentwicklung. Es wird viel über die "Produktivität von Führungskräften" geforscht, und vielleicht wird es in Zukunft Methoden geben, um die Produktivität bei der Softwareentwicklung zu "timen". Derzeit scheinen empirische Daten das Mittel der Wahl zu sein.

Woher bekommen wir empirische Daten? Die erste Möglichkeit ist über Zeitstudien, die Techniken des Industrial Engineering verwenden. Die andere, einfachere und zuverlässigere Möglichkeit besteht darin, sich auf historische Daten zu stützen, die von Zeitschnipseln geliefert werden.

Die meisten Zeiterfassungsprogramme, die in der Industrie eingesetzt werden, sind auf die Lohn- und Gehaltsabrechnung ausgerichtet. Sie sammeln keine Daten auf der untersten Ebene, um Produktivitätstrends zu ermitteln. Die meisten dieser Programme protokollieren zwei oder drei Ebenen von Daten, zusätzlich zu Datum und Uhrzeit. Ein Projekt wird immer auf der ersten Ebene eingetragen, und die zweite und dritte Ebene kann von einem Modul und einer Komponente, einer Komponente und einer Aktivität oder einer ähnlichen Kombination eingenommen werden. Neben dem Datum und der Uhrzeit, zu der der Mitarbeiter anwesend ist, sollten die Stundenzettel fünf Datenebenen erfassen: das Projekt, das Modul, die Komponente, die Entwicklungsphase und die erledigte Aufgabe. Auf diese Weise wären Daten verfügbar, um Produktivitätsmaße empirisch und realistisch zu erstellen.

Gegenwärtig liegt der Schwerpunkt der Softwareentwicklung auf der Makroproduktivität. Dieser Trend muss sich ändern, und wir müssen von der Makro- zur Mikroproduktivität übergehen. Dazu müssen wir unsere Software für Stundenzettel und die Tiefe der von uns gesammelten Daten ändern.

Die Produktivität auf der Mikroebene zu untersuchen, hat folgende Vorteile:

• Bessere Vorhersehbarkeit der Softwareentwicklung.
• Bessere Schätzungen zur Verbesserung der Preisgestaltung während der Projektentwicklung und der Abschlussphasen.
• Präzisere Zielsetzungen bei der Aufgabenverteilung, wodurch das Vertrauen der Softwarehersteller gestärkt wird.
• Genauere Kostenschätzungen

Alle Software Vendor Software ansehen

Schlussfolgerung

Es ist wichtig, den Unterschied zwischen den Begriffen Produktivität und Kapazität zu verstehen. Produktivität ist die Erfolgsquote einer Mikroaktivität; Kapazität ist die Erfolgsquote einer Anlage (Fabrik, Organisation usw.), und mehrere Aktivitäten sind im Kapazitätsschema enthalten. Zu Zwecken der Software-Evaluierung sollte sich der Schwerpunkt von der Makroproduktivität (Kapazität) auf die Produktivität (für die Mikroaktivität) verlagern. Die Sammlung empirischer Daten wird bevorzugt, um Produktivitätsmaße für die verschiedenen Aktivitäten der Softwareentwicklung zu erhalten, da die Techniken derStudien zu Fristen und Aufgaben keine zufriedenstellenden Ergebnisse liefern können, wenn die Aufgabe einen hohen Grad an Kreativität aufweist (was bei der Softwareentwicklung der Fall ist). Um empirische Daten zu sammeln, muss die Software zur Zeiterfassung verbessert werden. Wir empfehlen diese Vorgehensweise, um Produktivitätszahlen auf allen Mikroebenen zu berechnen.

Über die Autoren

Murali Chemuturi ist Experte für Industrietechnik an der Indian Institution of Industrial Engineering. Er war über dreißig Jahre lang in Wirtschaftsverbänden tätig, darunter ECIL, TCS, Metamor und Satyam. Zunächst arbeitete er in der Fertigung, dann im IT-Bereich. Derzeit leitet er Chemuturi Consultants und interessiert sich besonders für Software für die Softwareentwicklungsindustrie. Er hat mehrere firmeninterne Schulungsprogramme für das Management von Softwareprojekten und die Bewertung von Software geleitet.

Sarada Kaligotla hat ihren Master in Computeranwendungen abgeschlossen und ist zertifizierte Projektmanagerin (PMP) des Project Management Institute (PMI) sowie zertifizierte Analystin für Softwarequalität (CSQA) des Quality Assurance Institute (QAI). Derzeit arbeitet sie für Blue Cross Blue Shield in Massachusetts. Sarada hat sechs Jahre Erfahrung in der Softwareindustrie sowie im Projekt- und Entwicklungsmanagement.