Fehler im Projekt =S

[Bod]

Hallo,

ich habe mein Doku schon vor langem abgegeben... Schriftliche Prüfung auch bestanden und jetzt bald die mündliche Prüfung...

ein kleines Problem is, das ich ein denormalisertes DB Modell in der Doku habe... leider ist mir dies erst danach aufgefallen... soll heißen, eine Tabelle dient lediglich als QuellTabelle und in die andere werden die daten weggeschrieben..

das programm läuft ja auch , auch ohne fehler... is halt lediglich nich so schick gemacht =S

naja mir is es halt aufgefallen und ich habe mittlerweile das DB Model geändert und die SQL Statements natürlich auch, bezgl Join.

Wie soll ich nun in der Präsi vorgehen ? in der präsi drauf hinweisen das mir gewissermaßen ein fehler unterlaufen ist ? oder die präsi wie in der Doku durchziehen und danach drauf hinweisen ?

P.S. gibt das große abzüge in der DOKU ? das programm wurde ja entwickelt und läuft ja auch alles.. mit was muss ich rechnen ?

bitte um rat

[baba007]

gar nichts sagen und wenn sie fragen stellen, sagste war vom auftraggeber so gewollt. in der präsi verwendest du natürlich auch nur die dinge aus der doku und keinen überarbeiteten schnick schnack.

[Bod]

ich würde gern noch ein paar mehr meinungen hören.. am liebsten wären mir meinungen von leuten die mal im PA waren ...

danke

[djmower]

Es kann immer einmal passieren, dass etwas falsch da steht.

Solltest allerdings mit offenen Karten spielen, denn wenn die da evtl. nachfragen und du wirkst unsicher... vielleicht bohren die da weiter... deswegen würd ich da gleich zu anfangs drauf hinweisen, dass dir da ein kleiner Fehler unterlaufen ist.

Netten Gru$$

DJ Mower

[Bod]

ich hatte mir jetzt überlegt, in der präsentation die richtige Lösung zu erklären bzw zu präsentieren, und wenn ich durch bin mit der präsentation, dann zu sagen ich bin fertig, möchte aber noch etwas hinzufügen..dann den fehler erzählen... oder sollte ich das falsche , also das aus der doku präsentieren und danach(also direkt nach der präsi ) sagen das war falsch da war ein fehler der mir blöder weise erst nach der doku aufgefallen ist, und den ich halt nich mehr in der doku ändern konnte ?

[baba007]

deiner ehrlichkeit in allen ehren, aber das bringt dir nichts. Was versprichst du dir davon? zieh das ding aus der doku durch und gut ist.

nachträgliches ändern bei bereits erfolgter übergabe? kalkulierst du dann auch mit den zusätzlich entstandenen kosten? wird noch mal eine testphase durchlaufen? erfolgt eine weitere abnahme durch den auftraggeber? ist der soll ist zeitvergleich aktualisiert?

das ist ein abschlussprojekt, also handhabe es auch dementsprechend. 70 Stunden, alles super, wenige probleme, kaum abweichungen und mit den fehlern ist der auftraggeber zufrieden.

[Bod]

wenn du mir sagen kannst wie ich eine datenredundanz als super gelaufen verkaufen kann gerne... ich werde dann doch so oder so drauf gelöchert bezgl normalisierung , datenredundanz usw...

die entscheidung is echt schwer

ich brauche eine begründung warum ich das so gemacht hab, und ohne join und normalisierung... die angelegten einträge werden in einer tabelle gespeichert, die andere tabelle dient lediglich der kundenauswahl, zur suche nach einträgen und zur auswahl des kunden beim anlegen eines neuen eintrages.. heisst ich habe in beiden tabellen sowohl eine kundennummer wie auch den kundennamen stehen, in der ersten natürlich noch mehr daten.. jemand ne idee ?

[Dannyboy]

deiner ehrlichkeit in allen ehren, aber das bringt dir nichts. Was versprichst du dir davon? zieh das ding aus der doku durch und gut ist.

nachträgliches ändern bei bereits erfolgter übergabe? kalkulierst du dann auch mit den zusätzlich entstandenen kosten? wird noch mal eine testphase durchlaufen? erfolgt eine weitere abnahme durch den auftraggeber? ist der soll ist zeitvergleich aktualisiert?

das ist ein abschlussprojekt, also handhabe es auch dementsprechend. 70 Stunden, alles super, wenige probleme, kaum abweichungen und mit den fehlern ist der auftraggeber zufrieden.

So sehe ich das auch, ich denke es macht keinen Sinn noch groß da rumzuphilosophieren das an der Stelle ein Fehler passiert ist den du mal eben schnell behoben hast.

Das mag allgemein zwar völlig in Ordnung sein, ist aber bezogen auf Dein Projekt weniger gut, da weitere Kosten entstehen (so wie es baba007 dir auch schön aufgelistet hat)!

Ich denke du könntest einen Hinweis geben, das du das Projekt zur QS fortsetzen wirst (bzw. eben in einem neuen Projekt dies sicherstellst), du allerdings das und das nicht realisieren bzw. sicherstellen konntest da der dir gegebene Zeitrahmen von 70 Stunden für Wunschkriterien nicht ausgereicht hat.

Und trotzdem kann man darauf hinweisen das das bereits Erstellte vom Auftraggeber dennoch den gewünschten Anforderungen entspricht.

wenn du mir sagen kannst wie ich eine datenredundanz als super gelaufen verkaufen kann gerne... ich werde dann doch so oder so drauf gelöchert bezgl normalisierung , datenredundanz usw...

die entscheidung is echt schwer

ich brauche eine begründung warum ich das so gemacht hab, und ohne join und normalisierung... die angelegten einträge werden in einer tabelle gespeichert, die andere tabelle dient lediglich der kundenauswahl, zur suche nach einträgen und zur auswahl des kunden beim anlegen eines neuen eintrages.. heisst ich habe in beiden tabellen sowohl eine kundennummer wie auch den kundennamen stehen, in der ersten natürlich noch mehr daten.. jemand ne idee ?

Das mit der Datenredundanz ist natürlich schon so eine schwierige Sache. Denn normalerweise versucht man ja, Redundanzen zu vermeiden und Speicherplatz zu sparen. Zudem muss bei Datenredundanz sichergestellt sein, das Datenintegrität gegeben ist. Der Punkt referenzielle Integrität spielt natürlich auch eine Rolle, wenn du mehrere Tabellen mit Schlüsselfeldern hast.

Es gibt glaub ich einige wenige Ausnahmen, wo sich Datenredundanzen nicht vermeiden lassen, da es ansonsten eventuell im Verhältnis gesehen mehr Aufwand und Probleme geben könnte, um diese zu unterlassen. Allerdings weiß ich jetzt auf die Schnelle nicht wo das sein könnte. Vielleicht in größeren Personaltabellen, wo es den und den Familiennamen eventuell mehrmals geben könnte?

Wie gesagt, überlege dir gut wie du die Datenredundanz einigermaßen plausibel begründen kannst!

[djmower]

Bin zwar FISI und hab net so die Ahnung vom Programmieren. Aber bezweifel es eh mal ganz stark, dass man einen Fehler noch begründen kann und schön redet, nur weil man es nicht zugeben möchte...

Schließlich hört man ja nicht nach Abgabe der Doku auf zu denken. Da kann immer mal was schiefgehen bzw. kann man Fehler finden, aber solange man das auch zugeben kann und offen drüber reden kann, ist es doch in Ordnung.

Mein Projekt ist aufgrund von Fehlern zur Zeit nicht einsetzbar, natürlich kann man es schön reden. Aber warum... wenn es nun einmal nicht so ist... Das ist halt ein Projekt!

Netten Gru$$

DJ Mower

[Carnie]

eventuell kannst du es mit Performance begründen. Das es halt schneller geht die Informationen aus der einen Tabelle zu holen als eine riesen grosse andere Tabelle zu durchsuchen.

Mich wundert das dein Ausbilder nichts dazu gesagt hat weil für mich klingt es eindeutig nach einer vermurksten Struktur wie du ja selber schon eingesehen hast. Erwähnen beim Ausschuss würde ich es nicht denn ein Verständnis von dem Aufbau einer Datenbank und Normalisierungen gehört mit zur Ausbildung. Sofern es möglich ist würde ich das Thema bei der Präsentation weglassen aber du sollst auf jeden Fall vorbereitet sein falls Fragen kommen.

Eine gewagte andere Lösung wäre es vielleicht den Ausschuss auf etwas anderes zu lenken. Wenn es klappt hast du sehr gute Karten aber da die meisten Prüfer das nicht zum ersten Mal machen merken sie es recht schnell und ignorieren es vielleicht mal. Bei mir war es der Begriff des ROI der sofort auffiel und zu Fragen führte.

[baba007]

Aber warum... wenn es nun einmal nicht so ist... Das ist halt ein Projekt!

Weil es ein Abschlussprojekt ist, deshalb sollte man es schön reden. Das Ding wird einmal bewertet und fertig. Viele Abschlußprojekte landen anschliessend im Müll, die Note bleibt jedoch.

Sollte der Fehler auftauchen und der TE bekommt fragen zum Thema gestellt kann er ganz viel erzählen und somit noch ein gutes Fachgespräch machen.

In jedem anderen, normalen Projekt gibt man den Fehler zu und korrigiert entsprechend, klare Sache.

[P2oldi]

das einzige was mir jetzt zu begründeter Datenredundanz einfallen würde sind immens große Datenmengen in Data Ware Houses, auf die halt sehr langwierige Abfragen schneller laufen, weil Joins gepsart werden, man evtl. ander indizieren kann etc. Aber das bei Dir wahrscheinlich nicht der Fall sein wird, wüde ich auch die Präsentation auf der Doku aufbauen und gut. Und wenn Dein Chef das halt so wollte für ein späteres weiterführendes Projekt, das stellst Du ihm auch ne DB mit redundanten Daten hin (auch wenn Du eigentlich weißt das man das so nicht machen sollte )

[Dannyboy]

das einzige was mir jetzt zu begründeter Datenredundanz einfallen würde sind immens große Datenmengen in Data Ware Houses, auf die halt sehr langwierige Abfragen schneller laufen, weil Joins gepsart werden, man evtl. ander indizieren kann etc. Aber das bei Dir wahrscheinlich nicht der Fall sein wird, wüde ich auch die Präsentation auf der Doku aufbauen und gut. Und wenn Dein Chef das halt so wollte für ein späteres weiterführendes Projekt, das stellst Du ihm auch ne DB mit redundanten Daten hin (auch wenn Du eigentlich weißt das man das so nicht machen sollte )

Du meinst Data Warehouse

Das wäre wahrscheinlich das was ich meinte, der Aufwand zum Weglassen von Redundanzen wäre im Verhältnis gesehen immens, also können Redundanzen schon mal ganz plausibel sein (Carnie hat mit der Performance Begründung natürlich auch einen trifftigen Grund genannt).

Es wird wohl immer an dem eingesetzten DBS liegen.

@ Bod: Stelle dich aber auf jedenfall auf Fragen ein wie "Was verstehen sie unter Normalisierung?", "welche Datenbank Typen kennen sie?", "welche Arten von Beziehungen sind Ihnen geläufig?", "Erklären sie referenzielle Integrität, Datenredundanz, Datensicherheit etc."!

Ich denke das dein PA dich zu dem Thema DB einiges fragen könnte, wobei das mit der entsprechenden Vorbereitung machbar sein sollte. Solange du denen zeigst, dass dir die Materie geläufig ist, musst du auch nicht mit schlimmen Fragen rechnen

[developer]

Also, ich muss mich auch mal zu Wort melden...

Ich finde es meist zu gekünstelt, wenn es immer heißt, 'das Projekt hat genau 70/35 h gedauert', 'es sind keine Fehler aufgetaucht', 'der Kunde war restlos zufrieden' und 'es war total nachhaltig'. Hallo? Wer schon mal produktiv an größeren Projekten teilgenommen hat weiss, dass Theorie und Praxis manchmal weit auseinander driften. Fehler passieren immer! Es kommt darauf an, wie man mit ihnen umgeht: Entweder man schweigt sie tot und hofft, dass es der Kunde nicht mehr bzw. dass es in Produktion niemals zu einem GAU kommt, oder man steht dazu und versucht ihn zu bereinigen.

MEINE Meinung:

Lass erkennen, dass auch du kein Übermensch bist. Dem PA ist der Fehler sicherlich aufgefallen. Ein Bereinigen bevor der PA dich im Fachgespräch darauf anspricht ist meiner Meinung nach die bessere Lösung. Bei mir hättest du damit insgeheim ein paar Punkte gut gemacht zumal du den Fehler gefunden und behoben (!) hast.

Ich kann allerdings auch die Kritiker verstehen. Man möchte ja sein Projekt im besten Licht darstellen. Fehler sind ja im Allgemeinen graue Flecke auf der weißen Weste.

Die Entscheidung selbst kann dir niemand abnehmen. Es gibt in unserer Firma ein Modell, mit dem man ja/nein und ethische Entscheidungen anhand von ein paar Fragen besser fällen kann. Vieleicht hier 2 Fragen für Dich, die Dir helfen könnten:

a) Mit welcher Entscheidung würdest Du Dich besser fühlen? (Bauch-Gefühl)

Wäre es Dir peinlich, wenn Deine Entscheidung/Handeln öffentlich gemacht würde?

Viele Grüße

[Marco S.]

Meine Meinung:

Erstmal dein Projekt vorstellen so wie es ist und im Fazit später den Fehler ansprechen. Das das DB Modfell nicht ganz optimal war usw.

Vorteile:

1. Du kannst nicht gefragt werden warum du es nun falsch gemacht hast. Du nimst damit dem PA quasi den Wind aus den Segeln bezüglich des Fehlers

2. Das Thema wird mit sicherheit im Fachgespräch vertieft => Normalisierung, DB usw werden vermutlich drannkommen und du kannst dich drauf vorbereiten

[Carnie]

zu 1. der Ausschuss kann einfach sagen "Also das mit dem Modell ist mir noch nicht ganz klar könnten sie das vielleicht noch einmal näher erläutern."

Die entscheidente Frage ist ja auch warum er so ein Modell genommen hat . Wenn er selber drauf eingeht und sogar noch sagt das es geändert wurde gesteht er den Fehler und damit mangelndes Wissen ein. Ignoriert er den Fehler und wird drauf angesprochen kann er es begründen mit Performance oder auch das die redunante Tabelle für andere Projekte benötigt wird . (ok würde ich mit ner View machen ). Definitv fit sein solltest du zur Prüfung im Thema Normalisierung.

[Bod]

a) Mit welcher Entscheidung würdest Du Dich besser fühlen? (Bauch-Gefühl)

Wäre es Dir peinlich, wenn Deine Entscheidung/Handeln öffentlich gemacht würde?

Viele Grüße

das is die frage aller fragen, ich denke generell es wär positiv zu zeigen das einem der fehler aufegefallen ist.. ich könnt aber nich sagen warum ich den fehler gemacht habe =S

andererseits, wenn ich nich drauf hinweise, werden die mich denk auch drauf ansprechen.

die frage ist halt, ist es besser nach der präse den fehler anzusprechen, und damit zu zeigen, dass man versteht warum es falsch is, oder ist es besser nix zu sagen, und dann halt die fragen stumpf zu beantworten ?

für was könnte ich eher abzüge erwarten ?

zudem das alte(falsche) präsentieren und nach der präse sagen da war ein fehler ? oder schon in der präsi zeigen so müsste es richtig sein ?

:confused:

[developer]

für was könnte ich eher abzüge erwarten ?

Die Abzüge hast Du, wenn es bemerkt wurde, in der Dokumentation bekommen.

die frage ist halt, ist es besser nach der präse den fehler anzusprechen, und damit zu zeigen, dass man versteht warum es falsch is, oder ist es besser nix zu sagen, und dann halt die fragen stumpf zu beantworten ?

[...]

zudem das alte(falsche) präsentieren und nach der präse sagen da war ein fehler ? oder schon in der präsi zeigen so müsste es richtig sein ?

Du als Prüfling hast nur in den ersten 15 Min Zeit um Dinge zu präsentieren, danach gehört das Wort dem PA. Wenn Du es also ansprechen willst, musst Du es innerhalb der ersten 15 Minuten machen.

Ich würde nicht nochmal den gleichen Fehler präsentieren. Zeige kurz auf, wo der Fehler war und stelle ihn in Deiner Präsentation richtig.

[developer]

Tituliere es vieleicht nicht unbedingt als "Fehler", vieleicht besser "Änderung gegenüber der Projektdokumentation".

[baba007]

Ignoriert er den Fehler und wird drauf angesprochen kann er es begründen mit Performance oder auch das die redunante Tabelle für andere Projekte benötigt wird . (ok würde ich mit ner View machen ). Definitv fit sein solltest du zur Prüfung im Thema Normalisierung.

so würde ich es machen, jedoch tummeln sich hier auch ganz viele PAs, vielleicht auch einer von seinen dann ist sowieso Schicht im Schacht :eek

[Cleo]

Der Vortrag gehört doch zur Dokumentation. In der Dokumentation ist der Fehler enthalten.. Das Projekt "Projektarbeit" ist quasi abgeschlossen..

somit is der Fehler drinne und wird auch mit präsentiert... also so meine

Meinung...

Wenn jemand den Fehler bemerkt und einen darauf anspricht würde ich

sagen, dass dieser Fehler nach Abschluss "aufgeflogen" ist, jedoch

eine Änderung des Modelles unwirtschaftlich wäre, da viele Phasen etc. nochmals durchlaufen werden müssten. Das "Leben" mit dieser doppelten Datenhaltung ist somit günstiger, selbst wenn die Datenbank dadurch wesentlich grösser werden würde.

..oder halt so ähnlich..

aber ich würde auf keinen Fall einen anderen Stand präsentieren oder gar von selber erzählen, dass hinterher nochwas aufgefallen ist...

Möcht ja meine Arbeit als was unglaublich tolles darstellen :floet:

Höchstens im Fazit.. ganz am Ende..