Suche Informationen zur Auswertung von Ticketes von Softwareprojekten

B

Black Panter

0
Moin moin,

für meine Bachelorarbeit beschäftige ich mich momentan mit der Thematik, wie aus vorhandenen Spezifikationen, Test- und Fehlerfällen, in der Softwareentwicklung, Aussagen für zukünftige Projekte getroffen werden können.

Ich bin speziell auf der Suche nach Methoden, statistischen Verfahren o.ä. mit denen ich solche Aussagen treffen kann. Bei meinen Recherchen habe ich bisher keine wirklich passende Methode gefunden bzw. nicht gesehen, wie ich die Methoden anpassen kann. Geschaut habe ich bisher hauptsächlich im Bereich der quantitativen Risikoanalyse (Gefahrenanalyse, Ereignisbaumanalyse,...) und statistischen Methoden (Monte-Carlo-Algorithmen & -Methoden). Die statischen Methoden scheinen auch eher für das Finanz- und Versicherungsbranche gedacht zu sein.

Oder befinde ich mich auf einem Holzweg und muss umdenken? Ich hab so ein bisschen das Gefühl, dass Risikoanalyse eventuell der falsche Suchbegriff ist. Einen anderen Passenderen habe ich bisher nicht gefunden.

Ich bin für jeden Tipp, Schlagwort, Link, Literaturempfehlung o.ä. dankbar.


Viele Grüße
Sören
 
So etwas ist heutzutage Bestandteil der Deployment-Konzepte und Unit-Tests. Ich glaube da betreibt kaum jemand eine statistische Analyse, da das Monitoring der zugehörigen "business processes" und der Aufbau einer vernünftigen Integrationsumgebung, die die Einhaltung selbiger kontrolliert wirtschaftlich wesentlich sinnvoller ist als eine statistische Erhebung der Gefährdungsdaten. Übernimmt man die in vorangegangenen Projekten gewonnenen Erkenntnisse in seine Test- und Deployment-Verfahren, ist ein erneutes Auftreten der gleichen Fehler in zukünftigen Projekten ziemlich ausgeschlossen. Ich denke, dass du darum zu diesem Thema relativ wenig finden wirst.
 
t3rr0r.bYt3 hat gesagt.:
Durch langjährige statistische Analysen hat die Firma, in der ich arbeite, herausgefunden, dass es eine Scheißidee ist, Freitag abend zu deployen!
Zum Vergrößern anklicken....

Dann solltet ihr euren CTO entlassen. Ist ja wohl ein Grundgesetz in jeder Betriebsabteilung, dass min. ein Tag nach dem Deployment noch Entwickler verfügbar sein müssen, was am WE meist nicht gegeben ist.
 
Die Firma für die ich das machen soll möchte diese Daten erheben um beim Schreiben von Angeboten besser Puffer für auftretende Fehler einplanen kann und diese nicht nur nach dem Gefühl schätzen muss.
Also auch wenn man die Erkenntnisse in das Test-Verfahren mit aufnimmt, muss man einen Puffer fürs Testen und Bugfixen einplanen. Die Aussage, die ich mit meiner Arbeit machen möchte, soll bei dem Planen dieses Puffers unterstützen.

Und mein Ziel ist es Entscheidungshilfe zu leisten auf basis vergangener Projekte.

Meine Firma is im IT-Consulting tätig.
 
Zuletzt bearbeitet:
Ich bin eher praktisch veranlagt als theoretisch ;), aber in der Praxis würde ich eine solche Daten-Erhebung immer von 3 wichtigen Faktoren abhängig machen:

1. wie viele Tickets werden nach Projektbeginn noch erstellt und wie lange braucht deren Abarbeitung
2. wie viel Zeit muss bei jedem Projekt in die Deployment- und QA-Infrastruktur gesteckt werden
3. wie verlängert sich der Zeitaufwand von QA und Deployment während des Projekts (mehr Tests = mehr Zeit, geänderte Deployment-Verfahren = mehr oder weniger Zeit)

Misst man diese Parameter, bekommt man einen recht guten Überblick darüber wie viel ungeplante Zeit man in ein Projekt steckt. Das Ganze über mehrere Projekte gemessen und schon hat man brauchbare Daten um zumindest eine Grundaussage über den zusätzlichen Zeit- und Ressourcen-Verbrauch zu treffen.

Will man es richtig genau haben, muss man natürlich auch Dinge wie geänderte Ressourcen (z.B. zusätzlich eingestellte Entwickler, Tester, DevOps etc.) oder projektunabhängige Aktionen wie z.B. grundlegende Umbauten an der Projekt-Infrastruktur etc. beachten.

Ein Monitoring der Geschäftsprozesse ist auf jeden Fall das A und O bei der Projektplanung. Das ist gerade bei der agilen Software-Entwicklung mit Scrum, Kanban etc. nicht immer einfach. Hier muss man z.B. auch Dinge wie den Typ eines Tickets (Bug, Feature Request, Unknown, ...) berücksichtigen um unterscheiden zu können was Teil des eigentlichen Scrum-Prozesses ist und was zusätzlichen Aufwand im Projekt verursacht hat.

Grundlegend denke ich, könnte dir DevOps-Literatur weiterhelfen, denn das Monitoring und die Optimierung von Geschäftsprozessen in der Software-Entwicklung fällt am ehesten in diesen Bereich. Mir wäre allerdings kein zusammenfassendes Werk bekannt und die Praxis hat mir bisher gezeigt, dass die Datenerhebung von Geschäftsprozessen immer sehr abhängig von den eingesetzten Entwicklungsmethoden und den vorhandenen Prozessen ist. Es macht z.B. einen erheblichen Unterschied, ob der Betrieb/Infrastruktur projektgebunden oder projektungebunden arbeitet. Und noch viel erheblicher ist der Unterschied, wenn es um Scrum oder Kanban geht, weil z.B. bei Kanban die zeitlichen Vorabschätzungen von Tasks nicht unbedingt sein müssen u.ä.. Du wirst dich diesbezüglich also eher nach Literatur umsehen müssen, die die Entwicklungsmethoden aus DevOps-Sicht beleuchtet.
 
Die Firma für die ich das machen soll möchte diese Daten erheben um beim Schreiben von Angeboten besser Puffer für auftretende Fehler einplanen kann und diese nicht nur nach dem Gefühl schätzen muss.
Zum Vergrößern anklicken....

Ganz einfach: Geplante Projektzeit + 200% derselben ist ein guter +/- Wert.

Der +/- Wert wird nicht unwesentlich von 3 Faktoren bestimmt: Kunde, Prokjektleiter und sein Team. Die Art des Projektmanagments sehe ich weniger relevant, denn der Erfolg des Konzepts hängt letztlich vom Projektleiter ab.

Im Ernst: Es gibt ein paar gute Bücher bzlg. Projektplanung und Zeitmanagment. Ohne erfahrene Leute wird es ziemlich schwer ein Projekt zeitlich einzuschaetzen. Das schreiben des Codes ist da, nach meiner Erfahrung, maximal 1/3 der gesamten Projektzeit.
 
Um antworten zu können musst du eingeloggt sein.
Zurück
Oben