Estimationtool / Schätzungstool

Re: Estimationtool / Schätzungstool

Huhu @00Schneider,

der Part mit den geschätzten Aufwandszeiten für mich an als verwendet ihr Agile ;)
Spaß beiseite.

Grundsätzlich kann man mit Dynpro einen Report bauen mit welchem man mehr als nur die ollen Selektionskriterien verwenden kann. Das wirst du auf jedenfall brauchen (also Dynpros ;) ) um dem Benutzer zu ermöglichen Daten einzugeben.

Ich habe Schwierigikeiten deinen Ablauf nach zu vollziehen da "Echtzeit" und "Anzahl der User" aufgrund der reaktiven Ablaufweise von ABAP bzw der Anzeige nicht ganz so funktioniert - vielleicht stelle ich es mir auch nur falsch vor. Was mein Gedanke war: Das ABAP Programm wartet immer auf Eingabe und hängt bei Dynpro in einer Schleife aus PAI und PBO fest. Dazwischen kannst du mit Code agieren bzw auf Inputs reagieren/Outputs vorbereiten. PBO (Process before Output) ist der Code-Abschnitt, in welchem du Daten aus der Vorhereigen Anzeige verarbeiten kannst oder die nachfolgende Ausgabe befüllst. PAI (Process after Input) ist die Gegenstelle. Hier wird verarbeitet was eingegeben wurde. Wenn du mal mit C# etwas zu tun hattest kann man sich PAI als den Eventhandler vorstellen und PBO als ne Art Konstruktur. Da man aber (während das Programm auf die Eingaben des Users wartet) in der Anzeige des Dynpros die angezeigten Daten nicht wirklich dynamisch updaten kann fällt bei mir die "Echtzeit" etwas auf die Füße. Wie gesagt, vielleicht stell ich mir was ganz anderes vor als das, was du eigentlich meinst.

Grundsätzlich würde ich als Herangehensweise (und ich versuche das so technologieunabhäng wie möglich zu beschreiben, so dass die Aufgabe theoretisch auch in Perl gelöst werden kann ;) ) folgenden Ansatz wählen:
Es wird für jede Aufgabe oder Projekt (je nachdem wie groß der Scope sein soll) ein "Projekt" erstellt. Diesem Projekt können sich dann User subscriben. Ähnlich wie eine Anmeldeliste. Dieses Projekt bekommt dann schöne Metadaten wie Beschreibung, Zeitraum, Ressourcen, was auch immer zugeordet. Wenn sich die User dann eingetragen haben kann man in einem separaten Dialog. Hier gibt man dann seinen geschätzen Aufwand an und schließt ihn. Auf den Eintrag bzw den Dialog kann jederzeit wieder zugegriffen werden und bei einer Änderung wird dieser Wert in die Tabelle weg geschrieben. Was auch gut ist, in seinem eigenen "Profil" eine List aller Projekte zu haben mit Filter auf den Status des Projektes, den eigenen Subscribe Status und was einem noch einfällt. Wenn man auf einen Eintrag klickt kommt man direkt in die Übersicht und von da aus in die Abstimmung. Man könnte noch den Overhead sich bauen und ne Art Berechtigungssystem bauen dass der Ersteller des Projektes der Projektleiter ist und der dann das alleinige Bearbeitungsrecht des Projektes hat und ebenfalls die Abstimmungen abschließen kann wonach keine Änderungen mehr eingetragen werden können. Und solange die Abstimmung für das Projekt "offen" ist kann man sich die Auswertung (also den durchschnittlichen Aufwand) nicht anschauen. Abhängig davon wie transparent die Abstimmergebnisse sein sollen kann dem Projektleiter (PL) nur angezeigt werden wie viele Subs es gibt und wie viele abgestimmt haben. Das müsste dann aber (glaub ich) mit HR abgesprochen werden. Wie genau man das mit dem Subben macht müsstet ihr für euch klären. Hinsichtlich der Userverwaltung kann man den Weg gehen und sich eine Mini-Verwaltung nur für die Anwendung basteln, da trägt man alle Devs ein und in dieser Verwaltung managed man den Status ob PL oder Dev (kommt auch wieder darauf an ob bei euch das eine weiche oder harte Abgrenzung sein soll - weich meint organisatorisch aka nur der Abteilungsleiter bzw tatsächlich PL erstellt Projekte - hart meint fix mit User X ist PL und nur der darf erstellen). Um jetzt nicht vom hundertsten ins tausendste zu kommen überlass ich dir die Entscheidung ;)

Das Ganze in Stichpunkten:
- PLs erstellen ein Projekt und füttern es mit Meta Daten
- Devs haben eine Liste von Projekten sowie Filterkriterien
- Devs melden sich für ein Projekt an
- PL öffnet Abstimmung und jeder kann eintragen bis die Abstimmung geschlossen ist
- PL schließt die Abstimmung und ab da kann man sich zu dem Projekt nur noch die Ergebnisse in beliebig komplizierten Auswertungen ansehen

Für die Auswertung selber kann es ein Kuchendiagramm sein welches die Eingaben auf Genauigkeit X gruppiert, bspw die Eingabeform ist eine Textbox mit Stunden dann gruppiert man alles zwischen 1h und 2h, >2h und 4 usw. und zeigt die Verteilung an. Hier stellt sich natürlich die Frage wie offen willst du sein. Willst du eine Art Template verwenden? Also man kann beim Erstellen des Projektes auswählen welche Art von Auswertung man machen will oder soll es immer die gleiche Form sein? Abhängig davon ob das in der Zukunft auch mal geändert werden soll kann man die Richtung Template gehen. IMO einfach nur auszugeben |Die durchschnittlich geschätzte Zeit ist { lv_durchschnittsZeit }| auf einer ganzen Seite wäre mir persönlich etwas zu wenig ;) .

Um auf deine konkreten Fragen nocheinmal einzugehen:
- Wie würdet ihr an diese Aufgabe herangehen?
--> Wie oben beschrieben
- Welche Methoden, Technologien oder Tools könnte ich nutzen?
--> Bei den Methoden würde ich abklären welche Art von mathematischen Modell für die Endberechnung verwendet werden soll. Dabei auch darauf achten welche Werte gültig sein können und welche nicht (um eventuelle Runtime Errors zu vermeiden. Bspw negative Zeiten machen keinen Sinn, daher bei der Eingabe auf invalide Werte prüfen. Bei den Technologien bist du nur darauf beschränkt auf was du machen willst (Stichpunkt welche konkreten Auswerungen - Kuchendiagramme und so) angezeigt werden soll. Soweit ich weiß/gegooglet habe kann man mit ABAP irgendwie zeichnen. Ich kenn mich mit C# z.B. recht gut aus, da ist der Support für Zeichnen extrem praktisch, habe mich allerdings dahingehen noch nicht genug mit dem SAP Kosmos auseinander gesetzt. Eine Implementation in einem anderen System könnte dazu führen, dass man einen rück-Import ins SAP machen muss. An deiner Stelle am besten abklären ob etwas grundsätzliches dagegen spricht es außerhalb von SAP zu machen oder nicht. Wenn es außerhalb funktioniert steht die die Welt offen. Es gibt für jede Sprache etliche UI/Drawing Libs
- Welche zusätzlichen Features wären sinnvoll?
--> Ich denke fest, das ist primär eine Frage, die du an deine Firma stellen solltest. Denn nur ihr (du und deine Kollegen bzw die Zahlenfestischisten vom CO) wissen was sinnvoll ist. Und was nicht.
- Habt ihr Tipps für die Benutzerfreundlichkeit oder die Integration in SAP-Systeme?
--> Meiner 11 Jährigen Erfahrung als Softwareentwickler (5 davon im SAP Umfeld) ist: Nur weil es sich für dich gut und einfach anhört mag das Feature nicht intuitiv für andere sein. Halt Rücksprache mit deinen Kollegen ob die damit zurecht kommen oder was sie für Vorschläge haben wie man es lösen könnte.
- Wie kann ich Fehler verhindern?
--> Defensives Programmieren ist das A und O. Versuch schon beim schreiben der Software zu denken wie ein DAU und überlege welche Werte eingegeben werden können und welche Sinn machen. Programmier so, dass gar kein sinnloser Wert eingegeben werden kann. Außerdem: Es dauert immer länger als man denkt ;)

Lg Radinator

Da du am Ende sagst, dass du noch am Anfang deiner Krarriere als Softwareentwicker stehst kann ich nur sagen: Hut ab! Dass du dir so ein Projekt ausgesucht hast :)