Lizzy

In welcher Hinsicht sollte dies ein Problem darstellen? "Ausserhalb oder innerhalb der DMZ" sehe ich nicht wirklich als Entscheidungsspielraum an. *hust* Also 'nen 2003er Server hab ich hier laufen auf 'ner Hardware, die man nicht mehr im Laden bekommt und ein Keyserver sollte nicht unbedingt viel Ressourcen verschlingen. Ich IMHO nicht. Komplexitaet fehlt, Entscheidung fehlt, sorry. Gruesse, Lizzy

Das ist schon in Ordnung so Die Raute (Diamond) bei Entscheidungen (Decision node) benoetigt an den Pfeilen die Beschreibung der Bedingungen. In diesem Fall handelt es sich aber um einen Verbindungsknoten (Merge node). Hier werden die bei der Entscheidung geteilten Aktionsfluesse wieder zusammengefuehrt. An der Stelle wird nur der Diamond ohne jeglichen Text benutzt. Du koenntest sogar die beiden Pfeile, die in die Aktion "Augenzahl ueberpruefen" durch einen weiteren Verbindungsknoten zusammenlaufen lassen, aber das ist nicht zwingend vorgeschrieben. Ebenso koennte man den Verbindungsknoten auch weglassen und mit 3 Pfeilen in die Aktion "Augenzahl ueberpruefen" gehen, da die Verbindungsknoten nicht zwingend sind, sondern eher der Verdeutlichung dienen und - meine persoenliche Meinung - es sieht huebscher aus ;-) Gruesse, Lizzy

Da stellt sich erst einmal die Frage, was Du genau unter "verstehen" der schnellen Fouriertransformation definierst. Soweit verstehen, dass Du aus der mathematischen Beschreibung einen Algorithmus implementieren kannst oder wirklich verstehen, warum die FFT genau auf diese Weise funktioniert? In letzterem Fall wirst Du um eine Beschaeftigung mit Fourier-Reihen nicht herum kommen. Dazu natuerlich nicht unwichtige Voraussetzung sind Grundkenntnisse im Bereich Trigonometrie, Differential- und Integralrechnung, evtl. komplexe Zahlen. Was ich empfehlen kann, Du bist ja Student, mal an der Uni etwas Ausschau zu Vorlesung wie "Praktische Mathematik fuer Ingenieure" zu halten. Auch interessant Vorlesungen zu Regelungstechnik oder Signal- und Systemtechnik. Unter Umstaenden findet man dort sehr gute Vorlesungsskripte, die Schritt fuer Schritt in die Thematik einfuehren. Absolut zu empfehlen auch, wenn es diesbezueglich Praktika gibt, in denen direkt am Rechner mit Matlab oder aehnlichem gearbeitet wird - ist fuer das Verstaendnis sehr hilfreich mal praktisch eine Rechteckkurve aus Sinus-Schwingungen "zusammenzubasteln" . Zur Not mal bei Professoren oder Mitarbeitern einfach nachfragen. Gruesse, Lizzy

Sind auf jeden Fall ein paar Nachbesserungen noetig, um daraus ein korrektes UML-Aktivitaetsdiagramm zu machen. Mal im Einzelnen: - das Vorruecken fehlt. Wenn "Vorruecken" und "Strasse betreten" eine Aktion sein sollen, wuerde ich das auf jeden Fall auch so in den Knoten schreiben - die Bedingungen fuer die Entscheidungsknoten werden in eckigen Klammern an die nachfolgenden Pfeile geschrieben und nicht (voellig falsch) als Aktionsknoten. "Strasse bereits verkauft" ist keine Aktion, ebenso wenig "6 gewuerfelt" und "JA" und "NEIN". Schau Dir dazu am besten mal Beispiele fuer Entscheidungen in Aktivitaetsdiagrammen an. - in der Regel treten Fork- und Join-Nodes paarweise auf. Der Balken ueber dem "6 gewuerfelt" steht als Join ganz alleine da. Das geht gar nicht. Joins fuehren nebenlaeufige Aktionsfluesse zusammen. Da es keinen Fork gibt, existieren keine nebenlaeufigen Fluesse - ergo muss der Join falsch sein. Siehe Punkt 2, sollte in einem Beispiel mit Entscheidungsknoten klar werden, was dort hin muss. Hoffe das hilft Dir weiter. Gruesse, Lizzy

Hier posten waere auch eine nette Loesung

Faulheit scheint auch irgendwie keine Grenzen zu kennen. Ich find's ja schon dreist Aufgabenstellungen zu posten und nicht mal ansatzweise zu zeigen, dass man sich mit der Problemstellung auseinandergesetzt hat und an welchen Stellen es konkrete Probleme gibt. Aber hallo? Aufgabenzettel durch eine OCR jagen und nicht einmal auch nur etwas am Text feilen... "Auf Verpackungen von Waren benden sich haug Strichcodes" -- Ohne Witz: Ich dacht erst, das wär holländisch. Grüsse, Lizzy

Ganz unabhaengig vom Programm, fuer das Du Dich entscheidest, alleine aus den vielen Anforderungen ergeben sich doch schon ganz konkrete Punkte, die konfiguriert werden muessen: - Wie wird festgelegt, welche Softwarepakete auf welche Clients verteilt werden? - Wann wird welche Software auf welche Software zu welchen Clients verteilt? - Was wird ueberhaupt verteilt und wie wird es aufbereitet? Einige Software muss erstmal entsprechend paketiert werden, um ueberhaupt automatisiert verteilt werden zu koennen. - Wer darf ueberhaupt neue Softwarepakete einpflegen und verteilen lassen? Meiner Meinung nach ist das Projekt fuer 'nen Umfang von 35 Stunden viel zu gross, um anschliessend auch nur ansatzweise brauchbare Ergebnisse zu haben. Wenn Du wirklich innerhalb dieses Zeitrahmens die komplette Softwareverteilung inkl. Rollout der Rechner ueber mehrere Standorte hinweg revolutionieren kannst (und das sogar inkl. Integration in eine Produktivumgebung): Hut ab! Also ich wuerde mich auf den Vergleich / die Auswahl einer entsprechenden Softwareverteilungsloesung anhand der vorgegebenen Kriterien, Aufsetzen einer Testumgebung und Paketierung einer Beispielsoftware beschraenken. Keine Ahnung, wie das die IHK-Pruefer sehen, aber wenn das gut und sauber durchgefuehrt wird, ist das IMHO schon ausreichend anspruchsvoll fuer's Abschlussprojekt. Just my 2 Cents, Gruesse, Lizzy

Dann liegt in der Regel schon ein Planungsfehler vor. Wenn ich eine komplexe Funktion implementiere, die viel Zeit in Anspruch nimmt, muss ich Zwischenstaende abspeichern koennen, auch wenn sie nicht kompilierbar sind. Dann laesst sich auch bei Nutzung einer Ramdisk kein nennenswerter Geschwindigkeitsvorteil erreichen. 300 KB/s bei Netzlaufwerken, bei lokalen Laufwerken doppelt so schnell hiesse 600 KB/s. Ergo: Flaschenhals kann nicht der Datenspeicher sein. Jede halbwegs aktuelle Festplatte hat einen weitaus hoeheren Datendurchsatz. Da braucht man nicht viel ueberlegen. Vorgabe sind 70h. Sorry... geht gar nicht. Bei komplexen Projekten lohnt sich ein SCM bei Teams > 0 Entwickler.

Verstehe ich das richtig? Ihr habt 150MB Source-Code und die liegen zentral in einer Netzwerkfreigabe und jeder bearbeitet Dateien auf dieser Freigabe und kompiliert aus dieser heraus? *hust* kein SCM?

10 Seiten find ich fuer 'nen Projektantrag eigentlich schon arg laaang...

Die Aussage halte ich fuer gewagt. Ich kann mir sehr gut Projekte vorstellen, bei denen bestehende Software oder einzelne Module, die nicht Vista-tauglich sind, umgestellt werden sollen. Und das ist in der Regel kein stures "ich uebersetz das mal eben nach Vista", sondern oftmals auch mit einigen Entscheidungen verbunden. Fuehrt ja meist mehr als ein Weg nach Rom ;-)

Wow. Sowas lese ich zum ersten Mal. Alleine die Formulierung "nur der Form halber" klingt fuer mich ganz schoen uebel. Hoert sich an wie: "Da gibt's nichts Positives zu berichten. Unpuenktlich, Unzuverlaessig, Unehrlich". Just my 2 cents

Drohungen hier im Forum? Das ist doch verboten, oder? :confused: Ja nee, is klar. Sehr guter Tipp jemandem zum Medienwechsel zu raten, der/die schon inhaltlich nicht genau weiss, was neben Einleitung, Ist-Analyse und Soll-Konzept noch fuer die Praesi relevant sein koennte. Am besten noch in Stein meisseln ;-). Flipchart, Tabula rasa und Steintafel sind IMHO absolute Koenigsdisplinen. Ohne Frage - das kann einen sehr guten Eindruck machen, aber wenn man eh schon unsicher ist, sollte man bei Beamer oder Overhead-Projektor bleiben. Siehe oben. "Live-Praesentation" und "Hardware rumzeigen" sind (wieder IMHO) Koenigsdisiplinen. Das kann unter Umstaenden sehr beeindruckend sein, aber auch derbe nach hinten los gehen. Gruesse, Lizzy

Sorry fuer meine Unwissenheit, aber kann mir das bitte mal wer uebersetzen?

Dir ist schon aufgefallen, dass ich da nur die Punkte aufgelistet habe, bei denen ich direkt die vollen Punkte abziehen wuerde? Zugegeben nach strenger Bewertung. Man koennte schliesslich z.B. bei Resourcen- und Zeitplanung auch ein Auge zudruecken und 3 oder 4% geben, da die Zeiten durch das Installationsprotokoll "bedingt erschliessbar", aber augenscheinlich "nicht geplant" sind (so die Beschreibungen in den mir vorliegenden Bewertungsboegen). Die Bewertungspunkte, die ich als weniger offensichtlich ansehe, hab ich komplett ausgelassen und nur abgeschaetzt, was dort noch an Punktabzug dazukommt. Das soll den "versierten Pruefern" uebrig bleiben (und die Anfuehrungszeichen sind hier Zitat und nicht Ironie). Da masse ich mir keine Kompetenz an bzw. behalte meine Meinung weitestgehend fuer mich. Dass auch die aeussere Form dieser Arbeit nicht passt liegt auf der Hand, aber da moechte ich gar nicht zwischen 0 und 5 Prozenten verteilen muessen. Und nun mal unter uns 2 Gebetsschwestern: Worin liegt eigentlich der Sinn dieses Forums? Wahrung des Bildes der IHK-Pruefer oder Hilfestellung fuer angehende Fachinformatiker? Bewerte selbst, ob mein oder Dein Beitrag fuer den Threadstarter hilfreicher sein koennte. Gruesse, unversierter Lizzy ;-) P.S.: 15% sind bei mir nach weiterem Durchgehen der mir vorliegenden Bewertungskriterien absolutes Minimum fuer diese Doku. Und Du liegst wirklich unter den von mir angesetzten 20-30%?

Keine Prozesschnittstellen und Projektumfeld: -10% Keine Resourcen und Zeitplanung: -10% Keine Entscheidungssituationen: -5% Keine Qualitaetssicherung: -10% Kundendokumentation vollkommen unangemessen: -10% Projektabnahme u. Bereitstellung fehlt: -5% Keinerlei Reflexion (Soll/Ist-Vergleich, Wirtschaftlichkeit): -10% Wenn ich Pruefer waere und die Doku bewerten sollte, waeren das schonmal knackige 60%, die ich sofort abziehen wuerde. Da bleibt nicht mehr viel und in den uebrigen Beurteilungspunkten gehen auch hier und da noch so einige % drauf. Duerften so ungefaehr 20-30% uebrig bleiben sorry. Mein Tipp: Ein paar fremde (gute) Arbeiten und die Handreichungen zur Pruefung lesen und Dich dann fragen, warum Du das nicht vorher gemacht hast. Gute Dokus kann man meiner Meinung nach nur dann schreiben, wenn man schon mal eine solche gesehen und sich auch mal mit den Bewertungskriterien befasst hat. Und: Bitte dringend mal hier vorbeischauen. Vielleicht siehst Du ja kleine Unterschiede zwischen Deinem "Netzplan" in Kapitel 7 und der Art, wie ALLE ANDEREN Netzplaene erstellen. Gruesse, Lizzy

Das ist aber wirklich auch nur ein Punkt. Meiner Meinung nach waere da auch mit einem geeigneteren Projekt und offener ersichtlichen eigenstaendigen Entscheidungen Hopfen und Malz verloren gewesen - Sorry, Siddy... So wichtig diese Entscheidungsfindung seitens der Prueflinge auch sein moegen und so oft es hier auch betont wird, ist es ja nicht einzige, was eine Projektdoku ausmacht. Um genau zu sein 10%, wenn man nach der Bewertungsmatrix geht. Ich wundere mich immer, warum auf genau diesen einen Punkt der absolute Schwerpunkt bei Kritiken gelegt wird. Gibt schliesslich an genau diesem Beispiel schon ordentlich Punkte, die eigentlich fast geschenkt sind und ueberhaupt nicht beachtet wurden: Projektumfeld und Prozess-Schnittstellen Mehr oder weniger komplett ignoriert in dieser Dokumentation. Das sind meines Erachtens TOTAL verschenkte Punkte. Ein paar Saetze ueber die Gegebenheiten am Arbeitsplatz zu schreiben, welche Mittel zur Verfuegung standen, Ansprechpartner etc. ist nicht wirklich schwer. Resourcen- und Vorgehensplanung Personalmittel zu planen ist auch relativ einfach, darf aber auch ruhig mal kurz in einem Satz erwaehnt werden. Bei der Zeitplanung wurde der Hinweis in der Handreichung, dass die blosse Angabe von Stundenzeiten nicht ausreichen, sondern genaue oder relative Daten sowie definierte Meilensteine gefordert sind einfach nicht beachtet. Ebenso Kostenplanung: Ich kann kein Euro-Symbol in der ganzen Doku entdecken. Ein Punkt, den ich sogar fuer das spaetere Berufsleben fast genauso wichtig finde wie die Findung eigener Entscheidungen. Manche Kunden haben konkrete Vorstellungen, wie etwas umgesetzt werden soll und sind nicht daran interessiert, ob ich eigene Entscheidungen treffe. Die wollen aber dann vorab ungefaehr wissen, was dafuer auf den Tisch gelegt werden muss. Abnahme und Projektuebergabe Wird auch nirgendwo in dieser Doku erwaehnt. IMHO leicht verdiente Punkte. Reflektion des Projektverlaufs Z.B. keine Gegenueberstellung der geplanten und der wirklich benoetigten Zeiten fuer die einzelnen Projektphasen ist ersichtlich. Ganz abgesehen von einer eigenen Beurteilung, ob die Vorgangsweise im Nachhinein betrachtet gut war oder in Zukunft anders sein sollte. Auch in meinen Augen ein sehr wichtiger Punkt. Niemand verlangt nach 3 Jahren Ausbildung, dass im Abschlussprojekt alles perfekt laeuft. Erwartet wird aber, dass man darueber nachdenkt. Und dass darf - nein, sollte - auch in der Projektdoku zum Ausdruck kommen. ... Das sind jetzt nur mal ein paar Punkte, die mir spontan in's Auge gefallen sind. Und deshalb bin ich der Meinung, man sollte nicht nur auf fachliche Aspekte und die Eignung des Projektthemas abzielen. Sehr viele Punkte sind auch in den Feinheiten der Dokumentation versteckt. Rechtschreibung und ein ansprechendes Erscheinungsbild ist uebrigens auch noch so eine "Feinheit" und wird nicht zu Unrecht mit bewertet. Fuer eine interne Projektdokumentation mag das eine untergeordnete Rolle spielen, so lange ein exzessiv ausgelebter Free-Jazz in Sachen Rechtschreibung die Verstaendlichkeit nicht beintraechtigt... aber man muss davon ausgehen, wenn die Sorgfalt in dieser Hinsicht bei Vorlage an den Pruefungsausschuss schon nicht vorhanden ist, dann sieht's bei Dokumenten fuer den Kunden selten anders aus. Korrekturlesen koenne da meist auch Verwandte oder Bekannte, die nicht einmal ueber besonderes Fachwissen verfuegen muessen. Soweit nur meine 2 Cents zur Bewertung dieser Projektdoku. Mein Rat an Siddy: Les Dir mal 2-3 Beispieldokus von anderen FISIs durch und vor allem auch die Handreichungen genauer. Da laesst sich einiges an Punkten gut machen. Viel Erfolg! Gruesse, Lizzy