PHP-Scripte verschlüsseln leicht gemacht...

PHP-Scripte verschlüsseln leicht gemacht... (20 Beiträge, 187 Mal gelesen)

Du bist nicht angemeldet. [ Login/Registrieren ]

hi @all
an alle PHP freaks die PHP scripten den besseren schutz verpassen wollen will ich auf diesem wege meine persönliche erfahrung mitteilen...

motivation: mir war es leid meine DB-Passwörter in plaintext abzulegen und ich wollte meinen kunden trialware (zeit limitierte software) anbieten können ohne der gefahr zu laufen dass wer auf die dumme idee kommt ein sicherheits-backup der scripte zu erstellen...

ich war auf der suche nach einer PHP-Verschlüsselung (encoding) und habe mehrere systeme unter die lupe genommen...

die 3 kandidaten waren:
IonCube ( http://www.ioncube.com/  )
Zend ( http://www.zend.com/store/products/zend-safeguard-suite.php  )
SourceGuardian ( http://www.sourceguardian.com  )

ich will jetzt nicht alle vor und nachteile aufzählen aber;

IonCube
+ sehr günstig
+ viele funktionen
- man muss den ApacheServer neustarten und in der php.ini herum pfuschen
- da ich den INODE server nicht rebooten durfte konnte ich es nichmal testen

Zend
- sehr teuer
- nicht alle encoder versionen sind mit allen PHP versionen kompatibel

- nicht alle encoder versionen sind mit dem hauseigenen Zend Optimizer kompatiebel

- wollte einfach nicht funktionieren (PHP version war zu alt)
+ verdammt gute verschlüsselung
+ dateien sind im binary format
+ PHP Acceleration
+ alle funktionen die sich ein developer wünscht

SourceGuardian
+ preis ist im grünen bereich
+ gute funktionen
+ mit 4 klicks sind die dateien servierfertig (hehe SERV(i)ER-FERTIG

)
+ hat auf anhieb am server funktioniert
+ verschlüsselung ist gut
+ funktioneiert unter linux, windows, mac os x, freebsd und sun
+ man muss keine zusätzliche software am server installieren oder gar http-server restarten

+ kleine updates sind gratis
- um die backupfiles muss man sich selbst kümmern (dateien werden sonst überschreiben)
- die funktionen sind zwar gut aber eher unflexiebel...
- man kann nach der encodierung nur händisch copyright infos hinzufügen
- keine PHP Acceleration, im gegenteil wird es unbedeutend wenig langsamer

Fazit: SourceGuardian ist gut und bietet genug schutz... also viel spass beim ENCODIEREN

lg.
Ice-Tea (mit Zitrone)

Wunschdomain noch frei?

"Es gibt 3 Stadien der Verblödung. Im ersten merkt man es nur selber, im zweiten merken es auch die anderen und im dritten merken es nur noch die anderen. Dann ist es wieder schön. Bei mir ist es schön."

na das hört sich ja gut an

aber wieviel kostet das SourceGuardian eigentlich ??

Spedi

...mehr Power...

Laut Homepage 250$

Suche im Forum
Suche im Internet (Google)
Was ist?
Forums-FAQ
Kino 2005

UFFF....

noch immer ganz schön happig...
Für einen Heimanwender eigentlich unzahlbar

Wäre interessant ob es da auch kostenfreie Versionen gibt, welche zumindest die pseudo-Kopierer aufhält.

Spedi

...mehr Power...

Für Heimanwender auch völlig sinnlos. Ist ja nur für jemanden interessant, der Skripte für andere erstellt.

Suche im Forum
Suche im Internet (Google)
Was ist?
Forums-FAQ
Kino 2005

Intessant. Wie funktioniert das eigentlich?

Suche im Forum
Suche im Internet (Google)
Was ist?
Forums-FAQ
Kino 2005

aus [ ? php phpinfo() ?]

wird

include(ixed_pass("2R0",'g5SDeWGYNLnjW63TT69I82NdM0K75-xyybnNDNEehHoiEhWIi0F4j w0dlBt4H4nRcyVhgZzkchx+yIVzyFrK90f2141uekcTx0yGWsJDx9ycJy4Q+3ngf5QBOld-oisOAuuyF YLutUX7-EhJa-2TJxQpDyV4LI07pK6ka+EAopORN2I27mcqTzz08PY95M6yRU+K+ObCOfBLA-VuHh +sBu+IpgdiW66VYtzKCDP04aLhZOIANitVI21Uv4dJFmUx+QZvnsL20oxgs1aNAUBtF+F7oDXJJyrNX 56j6c4rBVO7SeuR+oTOUgpxshjfcHi1NbdRjgj8Uy2ys8s4gsuFrLgfH4FLV1aOCkvr5L3yl5bOkFr5046 WeObz9qurEJIZ6t4NAkVr6+72Tk6572LMCM-2cckg2m+D5i+vgvKSQAXPUb4LaWkc6VL2qSygaYT CqTMQAwDqkWZebO3-AJFQAWmBXYAA6APpTRu2EIfY+E9JxXekygCb3y+6-2FVy5ou9PFa6FMP5 a5DMh72hDD0K39c3w9OCjWwXV+PE2+3tZ9E+Ifp4VizG6+BnRX2hRgiPdRxsKpL5KzdNs9YdOUuQN hozLw6F64F3gdQVGZyVBykQ-uV676lCUF8mA2UPimKsWVGi7W-QTaBWB72823y-ZMHYvBtK2Axc rRob9YVH2sA53DLJjWIE4HP9P882Bp2zs7YCoECaI9NNuMeYaCWY2G8w1z4pL0XufOKe9ocCZe2Q QIkpAKH45fBptkNO87Slyvylr8J8bQREOllB14500e2nSungjgVaUFhWo7VZt8Ld2qox5U5JZSeC4+QB CjhwTeigoHNx1qNqaoFE+5ekKEPP20FV607E+Ug1lMNghRUYea2y9ZUHDsNl+SJkqctrDImViwLg2CG mxytAu6NVaOm-iwiV-gIhW50b07S2egUqGNgd2rq5VV7bI4cWr8AFZgUpLOiJEYXZinZroUqa4mhr5D gk2TvC0xQwDUTpuhcEhxtX0niYBYzDqQd5Lrc7lJbuJb6miZWOBNc52kSLs6A0lcYIEsOIiqx-jkLXhqyP sy0gROMt2k3rro+kS2Kb5RvVZqLzxRyjAklaGVbg5hXlXGSHPkYm2VfgRGzmjMDtHBFcp0EU4v21ERLp 5Wf9fmSOi5pReDbL2Al1iqnalGJt6M-EMNujYq2RhIDo3R0d0aAnyYg0i7mAyvSNRlQV81Cyueaw82sY LyibByC9nlE0F+xNp0xWXnRKOphnSX4iH5AqOYrdUw9wEu2WATHLSMGCWb-t-4ZLc5at20dJqZro2 XLtNN6SMe-wmTi-6YTNdF8llkojIB015PRuO2pknAYbSvOEPlFPgMV9s9iCp2xEkSMdftmVDh3gJkfpiD eBegg0tKM+NH3wL2Zq43yD7aDvwRMXoUEhfrC6Ov9Jyi2p4zBUXZmOwHsJkY5xj0yeCK3O4Bspjg LMApkxhrTmyoDe1D5na3fjjXHVJFlAzuip+4JU2CfEXG7Y0k8bHuSfOZ-8sJTt1HbmwxOw3LL8Lf yo8e019xO5gkgHNSx4YjK+OpljIG0k3drGie6Bc6CFWE2IllPoaM2BQImLTr0lqJVZ2IDk33+Njwo7 OGmK4ASz9TyQbHLvqBrMrWIBmZznJg4+2Vp8Tm5dd3LNXzyAnhbwHgOR5bA35-xc3x5LzreW s+rP2bJPomdNmYs4iBLhRcq00EiVOTF+xPnozQpGXIRgSt9Ni1SJNJetTeDlbgYGd1DlZ-OYE9TyP GPTS3+-7P8-fcJo2260E7x53+7uKba5r5xgugysxn9vvzNBia6+9b01WbGSyKLPrN7ylm29NVNsaU YBRViYupwBHLdZsEnkk4W6DlvWOWzI-wT3fT3P-51FoRiHxjy6WukEGoP+TyBDJ2W2BeXMy0Jfh BvVRRbF2VYqotfUQ9ijwKrTew2XgwIy2cHrsqk2OO6V9u1PdtGP0lk-neqXdAO7Hqw9QpN3Ll2rk7 -r6bv22OurkSQMSGEzRQN3boSqVD2tWSjxyelNrfe2vvNjHtTB2RXtJOUi4xfKR-3jOMogJr2--ktaA wXxv-znKze-o82fyvvHdQeRiFPlFpWhow9DfQi3YgS43YWDHIHIyYRc10oF2RpR-cOKcsMo72z+b DDHaD2xLIXX42X49kt8v7k8XFcWOCOwkcJ0URyZdA31Kc5rl5ix2o0WRqaq2hM7nYCBrFu-yzpqs aT2YX09j-n6RN9k4Xi-V8gDnevDIoohbcTyacYV2MCJdsqmCEcjD7SkI-MU6tOy6nAcezhSqbRku HsNVK6aOqxPyf+PMr1CV6ohsbe35jiPf2tktbrC4Q-PodFyoWfmiQA1cEhpP8f5X6L5squh8dyQTu0 hAYOtRo-EKanINmIMO3s8kt05GL-ES9e+Zc-t56O+OlX0mZyK4qclgQAGp1d-2Dpc7ChsLqIaG7R 1kRExkqiXlSoAtEikhdYsJht7qdfpy5Gg-585xSWXJZKRg3JzgjivbjyaF377+8WnJfEMdhlv2OC71hW KZTznIQn7-tmkil2+nktMDkiEP6pZfgkDFobMOog9axqC1TzDUg889ppCDJ2KNrEImZ9Y61egPq1yr KAHO6uYQTmgsMPnSGfcvuA+7o2TqbbsPYVq3caRUyHXf2s4238JN7zLZYg-9mZRFX-2wb+H Mjzn6T2Qqc1DNELu02w91jnCJ2sFLj-y5CqkBBm28P9GC27obI8d0HORewNJIiifH699R9pZ3wHqU FHhzRCyTPNzphdXhYN2JxEOBtnPGyBMve10HsIaIfzntmjQ7E+OGnA-0BzLkCGXcO0G4Tdnp24T Vi7fOAO-VzF2gOBWjbdiKOwCVUIXU0TVHRQkDpKREOcRXlvRahMB7FOa4S3WdSn2df+M5fUSoT jBWXk6FQZBSyh5nOcZwC9fezTWKLW8FPuOHzjszwnkpVFME4-PJBXF32Xa16Hz-uTRgNpJAC3p unCypSp4+Kiqu1pQcWkOyTkwb2F2KxHMG8OXpICs3j5jT4-21YNzjwquKEXnakuCzKKJpiwhIvGgs hVSJNodiJMt9MEOolOhCOBWD2pYRS6h1jGHROG7Kf+s4L5crW5-gAL3IgLy'));?]

ist zwar nicht platzsparend aber mann muss ja nicht alle PHP dateien Encoden

achja, in diesem verschlüsseltem text verbergen sich auch lizensinformationen, ein ablaufsdatum, domain-sprerre, IP-sperre und meldungen die nach ablauf der trialphase eingeblendet werden... also vielmehr informationen als in der originalfassung...

lg.
Ice-Tea (mit Zitrone)

Wunschdomain noch frei?

17.03.2005, 13:25 Uhr - Editiert von Ice-Tea, alte Version: hier

Hi !

Erinnert mich beim ersten hinsehen an etwas ähnliches wie crypt(3):
Das erste Argument als Salt und der Rest als Data ?

Ist das eigentlich bei Standard-PHP dabei oder muß man Serverseitig was installieren ?
In erstem Fall glaub ich, daß man das nach einem Wochenende (weil SRC verfügbar) mit viel Kaffee gelöst hat

es sollte im root-ordner eine "ixed" ordner erstellt werden und die gegenschlüssel dateien abgelegt werden

z.B.: ixed.lin.4.2.2.pxp

diese dateien können von PHP gelesen werden und bilden einen gegenschlüssel...

lg.
Ice-Tea (mit Zitrone)

Wunschdomain noch frei?

Ok...

Dann klingt's nach Public/Private-Key oder einen Offset zum Gegenschlüssel.

So oder so:
Wenn standard-PHP das lesen kann, dann ist im Source erkennbar, wie die ixed_-Func genau mit dem Umgeht.

Wenn der Kunde dann beides (Gecrypteter Source-Gegenschlüsseldatei) hat (was ja so ist), dann kann man sich was bauen...

So oder so:
Wenn standard-PHP das lesen kann, dann ist im Source erkennbar, wie die
ixed_-Func genau mit dem Umgeht.

Wenn der Kunde dann beides (Gecrypteter Source-Gegenschlüsseldatei) hat (was
ja so ist), dann kann man sich was bauen...

habs zwar nicht probiert aber die dateien könnte man glaube ich auch ausser reichweite reinstellen.

lg.
Ice-Tea (mit Zitrone)

Wunschdomain noch frei?

Außer Reichweiote von wem? - Vom Kunden, auf dessen Server das ganze laufen soll?

lg
mIstA

Außer Reichweiote von wem? - Vom Kunden, auf dessen Server das ganze laufen
soll?

im falle das der kunde keinen eigenen server hat wollte ich sagen. ich denke sowieso dass auch wenn die dateien im root verzeichniss liegen der kunde damit wenig anfangen wird. wenn die kundschaft so schlau wäre hätte sie meine dienste garnicht in anspruch nehmen brauchen

lg.
Ice-Tea (mit Zitrone)

Wunschdomain noch frei?

Hi !

Also für mich klingt das ganz anders, als du beschreibst:
[1] dachte ich immer, daß Zend im Prinzip den Source in einen P-Code übersetzt und u.a. damit die Performance erhöht. Dann hast aber deinen Source net verschlüsselt sondern maximal verschleiert. Die Frage wäre - kannst sicher schnell ausprobieren - ob man mit einem trivialen "strings" net einfach auf die Kennwörter kommt.

[2] Versteh' ich die Aufgabe net (Klartext-DB-Kennwörter) und so.
Unterscheiden wir Szenarien:
S1: Webserver bei dir
S2: Webserver bei Kunde, DB-Server bei dir
S3: Alles beim Kunden, dedizierter Server
S4: Alles beim Kunden, deine App ist eine von vielen.

S1:
es geht dir also darum, deinen Rechner zu schützen, falls die böse Eve ihn heimsuchte.
Nun denn, dann bleibt uneinsichtig, warum irgendein user (außer www) auf die Dateien Zugriff haben soll. Ein Plaintext-PW ist net schlecht, wenn net einmal root auf die Datei zugreifen darf. Kurzum: Du hast dann ein gaaanz schlimmes Security-Problem - daß du besser durch die Kombination von 2 anderen Mechanismen löst: SE (um im Betrieb zu schützen) und vercryptete Dateisysteme (um vor dem mit einer Knoppix bewaffneten und physichem Zugriff auf den Rechner habenden zu schützen).

S2:
Wenn nur der Webserver beim Kunden steht - dann würde ich einen User für die ganze Firma verwenden - sodaß du leicht die ganze Firma in ihren Permissions ändern kannst. Das hat den Vorteil, daß du dann leicht die Tabellen benutzer, tabelle, benutzer_tabelle anlegen kannst und die Firma dann ganz leicht durch inserts/updates/deletes (egal wie - du bietest in deiner App natürlich einen Menüpunkt dafür an) die 3 Tabellen warten kann und die Firma sich leicht neue Benutzer mit eingeschränketen Rechten anlegen kann. Die Security (daß sich eine Firma net mehr Rechte gibt als sie soll) kannst dann bequem durch ein paar
ON INSERT/UPDATE/DELETE INTO ... DO INSTEAD... - Rules abfackeln.

S3: Alles beim Kunden, dedicated Server
Das ist mein persönlicher "Standardfall". Den erschlag' ich in der Regel so, daß ich die komplette Systemwartung übernehme. Mit ein bißchen Redundanz der üblichen Verdächtigen (RAID, Netzteile, ..) kannst bei HW-Ausfällen Reaktionszeit gewinnen.

S4: Alles beim Server, du bist net root, ...
Auch das macht i.d.R. keinen Streß.
Meine PHP-Scripts sind in der Regel nur die Userinterfaces (ähnlich wie andere gerne Access als Frontend verwenden). Die Business Logic hat am Frontend IMHO eh' nix zu suchen, denn dann mußt sie doppelt warten (Jeden denkbaren Constraint bau' ich in die DB ein - das erspart viel Streß nachher) - in der DB und am Frontend. Im Endeffekt findet das ganze "schützenswerte" eh' in den Stored Procedures in der DB statt - und der Kunde soll sich seine eigenen Kennwörter ausdenken (die ich net mal wissen will). Wenn es ein Prob gibt, soll er dir temporär ein Kennwort geben und du dann remote oder lokal einsteigen. Das "Timeout" für die Testphase hast dann bequem in einer der DO INSTEAD-Rules verpackt...

Ich persönlich mag Verschlüsselung net. Aus der Praxis: Die Masse der Leutchen (will net auf dich anspielen) schreibt irgendeinen Schrott, verschlüsselt den und liefert aus. Du als Endkunde hast dann das Problem, daß du net einfach ermitteln kannst, warum denn in deinem Fall das Ding net so läuft wie dokumentiert. Oft hast dann einen Riesenaufwand (gdb, [sl]trace, ...) nur um zu ermitteln, wo der Coder den genau Schrott baute um einen Workaround)

Also für mich klingt das ganz anders, als du beschreibst:
[1] dachte ich immer, daß Zend im Prinzip den Source in einen P-Code übersetzt
und u.a. damit die Performance erhöht. Dann hast aber deinen Source net
verschlüsselt sondern maximal verschleiert. Die Frage wäre - kannst sicher
schnell ausprobieren - ob man mit einem trivialen "strings" net einfach auf
die Kennwörter kommt.

zend hat mehrere produkte. Zend Optimizer oder Accelerator (wie der name schon sagt) optimiert und gibt gas.
mit einem trivialen string kommt man nicht auf den quellcode der php datei weil zend SafeGuard erstelt aus den normalen PHP dateien eine Binere ausführbare datei die nur die Zend Engine entschlüsseln kann.

S1:
es geht dir also darum, deinen Rechner zu schützen, falls die böse Eve ihn
heimsuchte.
Nun denn, dann bleibt uneinsichtig, warum irgendein user (außer www) auf die
Dateien Zugriff haben soll. Ein Plaintext-PW ist net schlecht, wenn net einmal
root auf die Datei zugreifen darf. Kurzum: Du hast dann ein gaaanz schlimmes
Security-Problem - daß du besser durch die Kombination von 2 anderen
Mechanismen löst: SE (um im Betrieb zu schützen) und vercryptete Dateisysteme
(um vor dem mit einer Knoppix bewaffneten und physichem Zugriff auf den
Rechner habenden zu schützen).

es wird hier nicht der server geschützt sonder ganz simple PHP dateien bekommen eine sprerre. man kann die dateien auf bestimmte domains, IP adressen eichen sodass keiner diese irgendwo anders einsetzten kann. es ist sogar möglich (wie bei shareware) das du die PHP aplikationen auf eine bestimmte zeit sperrst. z.B. die aplikation läuft nur bis 1.April 2005 und danach muss der kunde eine lizenz kaufen um diese weiter zu betreiben. du gibst den kunden so die möglichkeit deine programme zu testen (auf auch deren server) ohne das du befürchten musst das sie unerwünschte kopien von deinem geistigen werk machen.

für die restlichen fragen trifft nichts zu weil das mit Serververwaltung nichts zu tun hat.

S4: Alles beim Server, du bist net root, ...
Auch das macht i.d.R. keinen Streß.
Meine PHP-Scripts sind in der Regel nur die Userinterfaces (ähnlich wie andere
gerne Access als Frontend verwenden). Die Business Logic hat am Frontend IMHO
eh' nix zu suchen, denn dann mußt sie doppelt warten (Jeden denkbaren
Constraint bau' ich in die DB ein - das erspart viel Streß nachher) - in der
DB und am Frontend. Im Endeffekt findet das ganze "schützenswerte" eh' in den
Stored Procedures in der DB statt - und der Kunde soll sich seine eigenen
Kennwörter ausdenken (die ich net mal wissen will). Wenn es ein Prob gibt,
soll er dir temporär ein Kennwort geben und du dann remote oder lokal
einsteigen. Das "Timeout" für die Testphase hast dann bequem in einer der DO
INSTEAD-Rules verpackt...

hat mit kunden kennwörter die in die datenbank kommen nichts zu tun. um mit den PHP anfragen in die datenbank zu gelangen musst du deine datenbank benutzernamen und password in einer "config.php.inc" oder dergleichen angeben. diese und die Quellcodes der PHP dateien gehören gesichert...

lg.
Ice-Tea (mit Zitrone)

Wunschdomain noch frei?

Hi, Ice !

Danke für die Infos...
Wie gesagt, ich _MAG_ verschlüsselte Sachen i.d.R. net, weil sie oft das richtige Mittel für den falschen Zweck sind (oder umgekehrt).

Von Zend kannte ich nur den Optimizer - stimmt. Drum schrieb' ich ja auch "ich glaub"

.
Wobei ein P-Code nie sicher ist - denn der entspricht einer 1:1-Abbildung der Statements. Du hast zwar dann die Variablennamen nicht mehr zur Verfügung - die verschwinden dann in i.d.R. in "&1", "&2", ...-Äquivalente - aber das ist ja kein Hindernis.

Du hast ganz am Anfang deines Postings das "Genug von Klartextpasswörtern" geschrieben - und daran hab' ich mich aufgehängt

Ad "Sperre der IP, Name, Zeit" - wie klappt das eigentlich in einer vm ?
Also mal angenommen, ich recover deinen Code in einer vm mit selben namen, selber IP, selber Mac-Adresse, ... und Patch nur die Systemzeit (die konstant bleiben soll) und die DB (die in ihren spalten einen Trigger DO INSTEAD... INSERT INTO tabelle (id,key,value,time) new.a, new.b, new.c, now() ) erhält ?

Abgesehen davon lieb' ich OpenSource und meine SW ist es auch.
Man verdient mit dem Support und den "Jetzt brauchen wir noch X"-Anfragen eh auch gut...
SW soll frei sein - ist aber nur meine gaaanz persönliche Meinung ohne Relevanz

Ad "Sperre der IP, Name, Zeit" - wie klappt das eigentlich in einer vm ?
Also mal angenommen, ich recover deinen Code in einer vm mit selben namen,
selber IP, selber Mac-Adresse, ... und Patch nur die Systemzeit (die konstant
bleiben soll) und die DB (die in ihren spalten einen Trigger DO INSTEAD...
INSERT INTO tabelle (id,key,value,time) new.a, new.b, new.c, now() ) erhält ?

gleichbleibende systemzeit bedeutet das einige PHP prozesse nicht mehr gesteuert werden können. stell dir ein kleinanzeigenscript vor. die anzeigen würden nie ablaufen. trotz allem wird man deine programierung nicht rekonstruieren können. es geht ja um genau diese einzige sache. geitiges eigentum zu schützen.

bgesehen davon lieb' ich OpenSource und meine SW ist es auch.
Man verdient mit dem Support und den "Jetzt brauchen wir noch X"-Anfragen eh
auch gut...
SW soll frei sein - ist aber nur meine gaaanz persönliche Meinung ohne
Relevanz

ich bin auch ein OpenSource mensch. nur manchmal passiert es, dass kunden wirklich spezielle sachen haben wollen die man in mühevoller arbeit erst erfinden muss. dann wollen die kunden diese erst testen. und genau in dieser angelegenheit wird es ernst. du musst quasi deine arbeit gratis zu verfügung stellen damit sie sich entscheiden können.

lg.
Ice-Tea (mit Zitrone)

Wunschdomain noch frei?

Hehe....

Gleichbleibende Zeit bringt natürlich Streß - je nach Aufgabe.

Wenn man aber um Lizenzen be*PIEP*en will, kriegt man das hin - notfalls durch einen vorgeschalteten Server, der die HTTP-Requests und Antworten parst und dort halt Zeiten setzt bzw. Umleitet.

Mit dem "Kritischen Pfad" hast hingegen natürlich absolut Recht - ist ja nix neues und wird seit Jahrtausenden (zumindest seit Softwareentwicklung) genau analysiert.

Da fänd' ich aus dem Bauch raus Rapid Prototyping weitaus besser (was ich sowieso mag). Er will X - also kriegt er einen X-Prototypen. Kennst es eh:
Wir wollen X, wir können ohne dem net arbeiten/leben/ejakulieren/sonstwas. -> Pflichtenheft (man lernt ja dazu) -> Paßt das so ? -> JAAA! Schnell, wir brauchen das DRINGEND. -> du baust X und lieferst.
2 Tage später:
X ist super, aber wir brauchen Y dazu, wir können ohne Y net...

Prototypen haben mir schon ein paar der 2-Tage-Zyklen erspart

Da fänd' ich aus dem Bauch raus Rapid Prototyping weitaus besser (was ich
sowieso mag). Er will X - also kriegt er einen X-Prototypen. Kennst es eh:
Wir wollen X, wir können ohne dem net arbeiten/leben/ejakulieren/sonstwas. ->
Pflichtenheft (man lernt ja dazu) -> Paßt das so ? -> JAAA! Schnell, wir
brauchen das DRINGEND. -> du baust X und lieferst.
2 Tage später:
X ist super, aber wir brauchen Y dazu, wir können ohne Y net...

Prototypen haben mir schon ein paar der 2-Tage-Zyklen erspart

also nicht nur mir geht es so... LOL

lg.
Ice-Tea (mit Zitrone)

Wunschdomain noch frei?

Dieses Forum ist eine frei zugängliche Diskussionsplattform.
Der Betreiber übernimmt keine Verantwortung für den Inhalt der Beiträge und behält sich das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
Datenschutzerklärung