Reengineering als Projektthema - sinnvoll?

[craile]

Guten Morgen,

Ich habe jetzt im Sommer '13 meine IHK-Prüfung und habe gerade von der Abteilung das Thema, welches ich bearbeiten soll/kann/muss bekommen.

Dabei handelt es sich um einen Prozess auf Java-Basis (welcher momentan "quick and dirty" runtergeschrieben wurde) der optimiert werden soll (reengineered) - im Hinblick auf MVC, Objektorientierung, etc.

Das bedeutet: es gibt kein GUI und kein wirkliches Programm mit dem ein Benutzer in irgendeiner Weise interagieren kann, es sei denn es handelt sich um einen Entwickler der selber weitere Änderungen am Quellcode durchführen möchte.

Jetzt frage ich mich ob das ein geeignetes Thema für das IHK-Projekt ist. Natürlich kann man recht viel dazu schreiben und es existiert sowohl ein Ausgangs- als auch ein Zielzustand, aber so Sachen wie Benutzerhandbuch & Co. kann ich als Anlagen nicht hinzufügen.

Habt ihr damit Erfahrungen oder Tipps? Würde mich über jegliche Hilfe freuen.

Beste Grüße

[gimbo]

Klar, wieso nicht? Ich finde, dass das ein sehr gutes Thema ist.

Ich denke, dass es bei Software-Einführungen meist folgende Konstellationen gibt:

1. Eine händische Lösung wird gegen eine Software-Lösung ersetzt.

2a. Eine veraltete Software wird gegen eine neue Software-Lösung ersetzt.

2b. Eine mangelhafte Software wird gegen eine neue Software-Lösung ersetzt.

Gegen 2b ist m.E. nichts einzuwenden. Abgesehen von der Ausgangssituation ist der Rest doch ziemlich gleich. Vorhandene Benutzerhandbücher oder Leitfäden müssten ebenfalls aktualisiert oder ganz ersetzt werden. Ob man das als Teil des Projekts betrachtet oder diesen Punkt aus Zeitgründen vom Projekt abgrenzt, ist dir ja überlassen.

[a3quit4s]

Klar ginge das, es muss nicht immer etwas fuer den Endkunden sein.

aber so Sachen wie Benutzerhandbuch & Co. kann ich als Anlagen nicht hinzufügen.

Du kannst aber eine Dokumentation fuer deine Entwicklerkollegen erstellen, falls diese dort nochmal reingreifen muessen. Da wuerden unter anderem Schnittstellendefinitionen drinstehen, nur so als Beispiel.

[craile]

Klar ginge das, es muss nicht immer etwas fuer den Endkunden sein.

Du kannst aber eine Dokumentation fuer deine Entwicklerkollegen erstellen, falls diese dort nochmal reingreifen muessen. Da wuerden unter anderem Schnittstellendefinitionen drinstehen, nur so als Beispiel.

Da hast du natürlich recht, Danke für den Vorschlag!

Ich habe bei der Thematik eben nur daran gezweifelt, ob das wirklich so in Ordnung ginge wenn quasi ein bestehender Code einfach nur modernisiert wird (wie ich das bereits oben aufgeführt habe), bzw. das Projekt einen Prozess thematisiert, der quasi nur Informationen weiterreicht und priorisiert - im Grunde also nie "sichtbar" ist.

Bearbeitet 26. Februar 2013 von craile
s. post #6

[gimbo]

Ach so, stimmt. Die Frage, ob es einen internen oder externen Kunden gibt, ist ebenfalls kein Hinderungsgrund für ein Projekt. Das Vorgehen ist im Prinzip gleich, auch wenn viele Dinge im Innenverhältnis natürlich etwas lockerer gesehen werden als wenn man einen realen Kunden gegenüber hat.

[craile]

Ach so, stimmt. Die Frage, ob es einen internen oder externen Kunden gibt, ist ebenfalls kein Hinderungsgrund für ein Projekt. Das Vorgehen ist im Prinzip gleich, auch wenn viele Dinge im Innenverhältnis natürlich etwas lockerer gesehen werden als wenn man einen realen Kunden gegenüber hat.

Ok, so hatte ich mir das gedacht.

Jetzt ergibt sich allerdings, dass der Prozess ziemlich umfangreich ist und scheinbar in den gegebenen 70 Stunden nicht umgeschrieben werden kann - nun steht im Raum, dass ich nur die Analyse und die Restrukturierung der Architektur vornehme (ohne aber in den Quellcode einzugreifen, eben nur auf dem Papier) - da sehe ich jetzt das größte Problem, da ich nun noch weniger Themen zur Verfügung habe die ich abarbeiten kann, abgesehen von UML-Diagrammen.

[gimbo]

So etwas wie ein Proof-of-Concept wird zwar nicht so häufig gemacht, aber grundsätzlich ist das möglich. Es sollte im Projektantrag dann nur unmissverständlich klar gemacht werden, wo das Projekt anfängt und wo es aufhört. Stichwörter dazu: Muss-Kriterien, Soll-Kriterien, Kann-Kriterien, Abgrenzungskriterien. Die Frage ist z.B., ob es einen Prototypen geben soll oder nicht. Wenn es unklar ist, dann würde ich es bei den Kann-Kriterien einordnen und wenn es zeitlich nicht umgesetzt werden kann, dann sagt man eben, dass es in der nächsten Version oder der nächsten Phase realisiert wird, die aber natürlich nicht mehr Teil des Projekts ist.