Codenames für Software/Hardware
-
Wenn die lustigen Marketingidioten damit erreichen wollten, dass ihre Projekte niemand mehr kennt oder kennen lernen will, haben sie es bei mir geschafft. "Was hältst du von XYZ?" - "Kenn ich nicht, mir auch egal." Völlig wurscht, ob es sich dabei nun um Hardware oder Software handelt.
-
chrische5 schrieb:
Hallo
Was soll denn dann "Oracle" für das neue VS. Das heißt doch so, oder?
chrische
Wenn das so ist, dann wundere ich mich schon sehr das ORACLE noch nichts dagegen
unternommen hat.
-
chrische5 schrieb:
Hallo
Ich verbinde damit eher Klamauk oder etwas in dieser Richtung.
chrische
ein blick in die wikipedia würde dich eines besseren belehren. http://de.wikipedia.org/wiki/Orakel
Chew-Z schrieb:
chrische5 schrieb:
schrieb:
HalloWas soll denn dann "Oracle" für das neue VS. Das heißt doch so, oder?
chrische
Wenn das so ist, dann wundere ich mich schon sehr das ORACLE noch nichts dagegen
unternommen hat.
ein codename an sich ist ja nur eine interne bezeichnung, kein produkt- oder markenname. und es handelt sich ja auch nicht um einen kunstnamen den man eindeutig auf ein produkt oder eine marke zurückführen könnte.
-
Das neue VS heißt Orcas und nicht Oracel!.
Das mit den Codenamen ist ganz praktisch zum entwickeln, gerade wenn man noch nicht weiß wie das endgültige Produkt nun wirklich heißt. Außerdem sind Namen leichter zu merken als irgendwelche Nummernkombinationen.
-
Codenamen können ganz praktisch sein. Für Entwickler, die ständig mit irgendwas hantieren, ist es wesentlich angenehmer, sich über die Unterschiede zwischen Foo und Bar zu unterhalten, als über 3.3.15b und 3.4.7a oä.
Und für End-User ist das oft auch nicht allzu unpraktisch, meine Mutter weiß, dass sie MacOS X Tiger verwendet, und dass Jaguar älter ist, auch wenn sie keine Ahnung hat, welche Versionsnummern die jeweiligen Systeme haben.
-
nman schrieb:
Codenamen können ganz praktisch sein. Für Entwickler, die ständig mit irgendwas hantieren, ist es wesentlich angenehmer, sich über die Unterschiede zwischen Foo und Bar zu unterhalten, als über 3.3.15b und 3.4.7a oä.
mal abgesehen davon dass man oft den namen des produktes erst spaeter festlegt wenn man den vollen funktionsumfang kennt, zielgruppen analysiert hat, etc.
-
Shade Of Mine schrieb:
mal abgesehen davon dass man oft den namen des produktes erst spaeter festlegt wenn man den vollen funktionsumfang kennt, zielgruppen analysiert hat, etc.
Klar. Wobei das natürlich im Falle von MacOS X, Java oä wegfällt.
-
Shade Of Mine schrieb:
mal abgesehen davon dass man oft den namen des produktes erst spaeter festlegt wenn man den vollen funktionsumfang kennt, zielgruppen analysiert hat, etc.
Sollte das nicht eignetlich vor der Fertigstellung des Produkts bekannt sein?!

-
junix schrieb:
Shade Of Mine schrieb:
mal abgesehen davon dass man oft den namen des produktes erst spaeter festlegt wenn man den vollen funktionsumfang kennt, zielgruppen analysiert hat, etc.
Sollte das nicht eignetlich vor der Fertigstellung des Produkts bekannt sein?!

Was? Der Codename kommt doch vor der Fertigstellung. O_o
-
Lügner schrieb:
junix schrieb:
Sollte das nicht eignetlich vor der Fertigstellung des Produkts bekannt sein?!

Was?
Das:
Shade Of Mine schrieb:
[...]den vollen funktionsumfang kennt, zielgruppen analysiert hat, etc.
-
junix schrieb:
Shade Of Mine schrieb:
mal abgesehen davon dass man oft den namen des produktes erst spaeter festlegt wenn man den vollen funktionsumfang kennt, zielgruppen analysiert hat, etc.
Sollte das nicht eignetlich vor der Fertigstellung des Produkts bekannt sein?!

Marktanalyse sollte auf jeden Fall vorher gemacht werden, denn sonst produziert man u.U. am Markt vorbei und verursacht nur unnötige Kosten. Was aber am Schluss im Programm drin ist, ich bin mir nicht sicher, ob das was im Projektplan drinsteht dann auch im Projekt ist, oder ob sogar mehr im Projekt ist als im Projektplan, weil dem Kunden mal wieder was eingefallen ist.
EDIT: Ich kann die Zahl zwar nicht mit Quellen belegen, aber IIRC scheitern 60-70% aller IT-Projekte in Deutschland wegen mangelnder Planung.

MfG
GPC
-
GPC schrieb:
[...]ich bin mir nicht sicher, ob das was im Projektplan drinsteht dann auch im Projekt ist,
Weniger im Projektplan als viel mehr im Pflichtenheft. Und das Pflichtenheft sollte doch eigentlich verbindlich sein?
-
junix schrieb:
GPC schrieb:
[...]ich bin mir nicht sicher, ob das was im Projektplan drinsteht dann auch im Projekt ist,
Weniger im Projektplan als viel mehr im Pflichtenheft. Und das Pflichtenheft sollte doch eigentlich verbindlich sein?
Um, jaaa, sowohl Pflichten - als auch Lastenheft bindet ja beide Seiten, jedoch habe ich es schon mehrfach erlebt, dass Leistungen nicht erbracht wurden. Diese nicht erbrachte Leistung wird dann halt nicht bezahlt. Sense.
-
Oder das zusätzliche Leistungen erbracht werden sollen die eine vorherige Planung zu nichte machen. Man kann dem Kunden ja auch nicht ständig das Pflichtenheft vor die Nase halten wenn er "kleine" Änderungen haben will.
-
Chris++ schrieb:
Man kann dem Kunden ja auch nicht ständig das Pflichtenheft vor die Nase halten wenn er "kleine" Änderungen haben will.
Aber sicher doch. Immer zusammen mit einer Kostenrechnung für die Extrawünsche. Sonst hört das nämlich niemals auf. Wenn jede kleine Änderung einfach so ausgeführt wird, gibt das ein ewiges Projekt.