Check alle échte Black Friday-deals Ook zo moe van nepaanbiedingen? Wij laten alleen échte deals zien

Wanneer is er sprake van een wanprestatie bij software?

Pagina: 1
Acties:
  • 2.549 views

  • StM
  • Registratie: Februari 2005
  • Laatst online: 07:15
De vraag van wanneer er sprake is van wanprestatie komt voort uit een huidig project dat ik voor een klant uitvoer en waar ik graag eens een discussie op gang over wil brengen. Als allereerste wil ik benadrukken dat ik ook niet foutvrij ben en dat iedere software fouten zal bevatten maar naar mijn mening is er een bepaalde grens tot wat acceptabel is.

De case dit ik hier nu heb ik is een relatief grote webwinkel ontwikkeld door een professionele internet dienstverlener. Ik ben door de eigenaar gevraagd om dit systeem eens onder de loop te nemen, met name omdat de Google ranking gewoon dramatisch is. Uiteindelijk wilde ze gewoon een totaal rapport met mijn mening over het systeem. De ontwikkeling loopt sinds 2007 en het is geschreven in PHP.

Naast de vele kleinere dingetjes zijn er ook een aantal hard aan te wijzen punten, voornamelijk op het gebied van beveiliging:

- Volledig procedurele code zonder enige scheiding van opmaak en code
- Geen parameterized query's (MYSQL extensie ipv MYSQLi of PDO)
- SQL injection op verschillende plaatsen mogelijk
- XSS op verschillende plaatsen mogelijk (oa in het bestel systeem, wat wss ook getoond wordt in de backend)
- CSRF
- MD5 passwords zonder salt
- Sessie systeem door gebruikersnaam en md5 hash in een cookie te plaatsen (en gaat gewoon weer ongeëscaped een query in, cookies kan je toch niet faken?)
- Externe scripts die de site weer aanroepen en heel effectief de site kunnen DoS'en

Ze worden voor het grootste gedeelte qua sql injectie nog gered door magic quotes, anders vrees ik dat ik onbeperkt had kunnen winkelen (wat misschien nog steeds kan, maar ik heb niet de broncode van de site, slecht van enkele pagina's). Daarnaast zal een specialiseert security bedrijf wss nog wel VEEL meer gaan vinden.

De boel is ook extreem sloom. Het draait op een eigen cluster en de frontpage is gebenched met ab op 17 requests / sec. Dit komt voornamelijk doordat een pagina 265 requests nodig heeft om te laden en omdat er voor ieder plaatje en dingetje een aparte query naar de database gaat. De grote selects zijn gecached maar al die kleine query's niet.

Zoals te verwachten ontkent de leverancier dat er ook maar iets mis is. En hoewel ik geen prijzen weet, zal die site niet goedkoop geweest zijn. Ik vrees dat de meesten hier wel 1 of 2 jaar bereid zijn om fulltime voor dat bedrag te werken ;)

Ik zit me af te vragen wat ik de site eigenaar moet adviseren, maar nog liever zou ik deze discussie ook eens wat algemener voeren. Is er een grens tot waar een leverancier kan gaan waarna je hem gewoon in gebreken kan stellen of eventueel je geld terugeisen? Software kwaliteit is nu niets iets wat makkelijk te meten is en de opdrachtgever heeft er ook niks over afgesproken. Maar je zou toch verwachten dat je kwaliteit krijgt als je zo'n enorme investering doet. De klant heeft zich ook nooit met de kwaliteit beziggehouden behalve "dat het niet goed zat", waarna er maanden aan een update gewerkt is, uiteraard op kosten van de klant die de boel eigenlijk alleen maar verslechterd heeft.

  • Jrz
  • Registratie: Mei 2000
  • Laatst online: 24-11 22:31

Jrz

––––––––––––

Sja lastig... de meeste bedrijven weten niet eens wat ze willen, laat staan dat ze snappen wat performance of een goed ontwerp is.

Het systeem is nog realtief jong, maar sta er niet van te kijken, met name omdat het php is (geen flamebate).

Het is mede de verantwoordelijkheid van het bedrijf om het juiste te vragen aan de ontwikkelaar. Andersom ook natuurlijk, maar if it gets the job done prima.

Als je geen prijzen weet, dan kan je daar ook niets over zeggen. Ik heb een super mooi systeem zien worden verkocht voor 3K... Zijn 3 man 6 maanden fulltime mee bezig geweest.

Daarnaast knijpen de meeste bedrijven toch wel.

Mijn advies: bied een upgrade aan.. anders wil ik het wel doen ;)
Documentjes opstellen etc..

[ Voor 28% gewijzigd door Jrz op 08-04-2011 18:03 ]

Ennnnnnnnnn laat losssssssss.... https://github.com/jrz/container-shell (instant container met chroot op current directory)


  • D-Raven
  • Registratie: November 2001
  • Laatst online: 16-10 10:47
StM schreef op vrijdag 08 april 2011 @ 17:53:
..

Ik zit me af te vragen wat ik de site eigenaar moet adviseren, maar nog liever zou ik deze discussie ook eens wat algemener voeren. Is er een grens tot waar een leverancier kan gaan waarna je hem gewoon in gebreken kan stellen of eventueel je geld terugeisen? Software kwaliteit is nu niets iets wat makkelijk te meten is en de opdrachtgever heeft er ook niks over afgesproken. Maar je zou toch verwachten dat je kwaliteit krijgt als je zo'n enorme investering doet. De klant heeft zich ook nooit met de kwaliteit beziggehouden behalve "dat het niet goed zat", waarna er maanden aan een update gewerkt is, uiteraard op kosten van de klant die de boel eigenlijk alleen maar verslechterd heeft.
Daar zit het probleem.
Natuurlijk heb je helemaal gelijk als je zegt dat ze meer zouden mogen verwachten gezien wat het (waarschijnlijk) financieel gekost heeft. Maar het feit blijft dat jou opdracht gever juridisch gezien geen poot heeft om op te staan puur omdat er in het contract helemaal niks staat vastgelegd mbt de verwachtingen die zij hebben wat betreft performance en beveiliging.

Al moet ik wel zeggen dat beveiliging weer een andere categorie is. Als het bedrijf namelijk geld misloopt doordat de website gehacked wordt, en dit is duidelijk te herleiden tot nalatigheid of onkunde van de ontwikkelaar van de software, dan kun je deze wel degelijk aanklagen.

Al met al, Its a hornets nest. Ik zou gewoon duidelijk en eerlijk je rapport schrijven, met wellicht een onderdeel gewijd aan aanbevelingen van hoe het beter kan. Maar je er daarna proberen ervan te distantiëren.

En dan nu de algemene discussie:
Het komt nog veel voor dat bedrijven zonder verstand van zaken ict projecten laten uitvoeren door 3de partijen. In principe niks mis mee. Maar waar het probleem ligt is dat deze bedrijven vaak niet ver genoeg vooruit denken en eisen omtrent performance, beveiliging en andere moeilijk te kwantificeren onderdelen (risico's ?) niet in een contract opnemen. (moeilijk als in moeilijk voor de opdrachtgever).

Ik ben van mening dat een ICT dienstverlener deze dingen juist bij hun opdrachtgever moeten aankaarten. Helaas gebeurd dit vaak niet.

  • StM
  • Registratie: Februari 2005
  • Laatst online: 07:15
Jrz schreef op vrijdag 08 april 2011 @ 18:02:
Als je geen prijzen weet, dan kan je daar ook niets over zeggen. Ik heb een super mooi systeem zien worden verkocht voor 3K... Zijn 3 man 6 maanden fulltime mee bezig geweest.
Ik weet de schatting van de klant voor een komende uitbreiding (maar er is nog geen offerte binnen) gebaseerd op eerdere uitbreidingen. Naar mijn mening kan het in een paar dagen of maximaal een week gemaakt worden. En met 3k kom je er niet.

  • Megamind
  • Registratie: Augustus 2002
  • Laatst online: 10-09 22:45
StM schreef op vrijdag 08 april 2011 @ 18:07:
[...]


Ik weet de schatting van de klant voor een komende uitbreiding (maar er is nog geen offerte binnen) gebaseerd op eerdere uitbreidingen. Naar mijn mening kan het in een paar dagen of maximaal een week gemaakt worden. En met 3k kom je er niet.
Daar verkijk jeje misschien op, weet niet hoegroot de site is, maar programmeren is niet alleen code kloppen, er zit een heel ontwikkeltraject achter waarvan het programmeren maar een klein onderdeel is.

Maar 3k is natuurlijk peanuts voor een grote webshop, daarnaast hoe kunnen nu 3120 manuren maar 3000 euro opleveren, is het in China gemaakt? :P

Als ik jou was zou ik maar kwetsbaarheden zoeken, en die live presenteren aan de eigenaar, zeker als er geld mee gemoeid is zullen ze er vast wel oren naar hebben.

  • smesjz
  • Registratie: Juli 2002
  • Niet online
D-Raven schreef op vrijdag 08 april 2011 @ 18:07:
En dan nu de algemene discussie:
Het komt nog veel voor dat bedrijven zonder verstand van zaken ict projecten laten uitvoeren door 3de partijen. In principe niks mis mee. Maar waar het probleem ligt is dat deze bedrijven vaak niet ver genoeg vooruit denken en eisen omtrent performance, beveiliging en andere moeilijk te kwantificeren onderdelen (risico's ?) niet in een contract opnemen. (moeilijk als in moeilijk voor de opdrachtgever).

Ik ben van mening dat een ICT dienstverlener deze dingen juist bij hun opdrachtgever moeten aankaarten. Helaas gebeurd dit vaak niet.
Hoewel off-topic: het is de verantwoordelijkheid van de opdrachtgever om genoeg kennis te verzamelen (intern of extern) bij het geven van een opdracht. Het blijft natuurlijk een spel, opdrachtgever wil zo veel mogelijk tegen zo'n lage kosten en opdrachtnemer wil niet meer doen dan afgesproken is en het liefst tegen een hoge prijs.
En die spanning is gezond (tenzij je een overheid bent want dan word je uitgekleed).
Want hoe zie jij het aankaarten van beveiliging/performance etc bij een klant? Je zal wel gek zijn als je aantal requests/sec contractueel vastlegt als je klant er niet over begint.

  • D-Raven
  • Registratie: November 2001
  • Laatst online: 16-10 10:47
smesjz schreef op vrijdag 08 april 2011 @ 18:16:
[...]


Hoewel off-topic: het is de verantwoordelijkheid van de opdrachtgever om genoeg kennis te verzamelen (intern of extern) bij het geven van een opdracht.
Tuurlijk, maar feit blijft dat er een hoop idioten rondlopen. Helemaal als je met wat kleinere bedrijven werkt die geen kaas gegeten hebben van ICT, die gaan echt niet naar een 3de partij om informatie in te winnen.
Het blijft natuurlijk een spel, opdrachtgever wil zo veel mogelijk tegen zo'n lage kosten en opdrachtnemer wil niet meer doen dan afgesproken is en het liefst tegen een hoge prijs.
En die spanning is gezond (tenzij je een overheid bent want dan word je uitgekleed).
Want hoe zie jij het aankaarten van beveiliging/performance etc bij een klant? Je zal wel gek zijn als je aantal requests/sec contractueel vastlegt als je klant er niet over begint.
Natuurlijk moet je niet gaan vastleggen dat je website x aantal requests per seconde moet kunnen verwerken. Het is gewoonweg onrealistisch om aan het begin van zo'n traject zo'n soort eis vast te leggen. Maar wat je wel kan doen is zeggen dat als richtlijn een pagina binnen 1 a 2 seconden op je beeld moet staan.

Dit is een duidelijke indicatie naar de ontwikkelaar toe van wat er verwacht wordt. Maar geeft tegelijkertijd voldoende flexibiliteit.
Mocht het nu zo zijn dat de gemiddelde laadtijd van de website hoger ligt dan dit (laten we zeggen 5 seconden ofzo) dan heeft de opdrachtgever een wapen in hand om de ICT dienstverlener op zijn vingers te tikken.
Maar aan de andere kant als de meeste pagina's keurig binnen de marge geladen wordt (laten we zeggen alles tussen 0 en 3 seconden), en een paar pagina's doen er wat langer over. Dan is er niks aan de hand.

edit: overigens vind ik dit niet echt off-topic. Maar meer een onderdeel van het hoofdonderwerp: Tot hoever mag een ICT dienstverlener gaan m.b.t. het opleveren van slechte software. (waarbij slecht een ruim begrip is)

[ Voor 5% gewijzigd door D-Raven op 08-04-2011 18:30 ]


  • StM
  • Registratie: Februari 2005
  • Laatst online: 07:15
Megamind schreef op vrijdag 08 april 2011 @ 18:16:
[...]

Daar verkijk jeje misschien op, weet niet hoegroot de site is, maar programmeren is niet alleen code kloppen, er zit een heel ontwikkeltraject achter waarvan het programmeren maar een klein onderdeel is.
Dat weet ik, ik programmeer zelf ook al vele jaren. Maar documentatie is er niet. Commentaar staat er niet in de code (op 2 regeltjes na per script ongeveer, uit niet meer bestaande dan "zoekopdracht" etc. En of er van te voren iets wordt ontworpen durf ik sterk te betwijfelen. Voor de uitbreiding hoeft niks grafisch ontworpen te worden.
Megamind schreef op vrijdag 08 april 2011 @ 18:16:
[...]
Als ik jou was zou ik maar kwetsbaarheden zoeken, en die live presenteren aan de eigenaar, zeker als er geld mee gemoeid is zullen ze er vast wel oren naar hebben.
Dat zal ik ook zeker doen.
smesjz schreef op vrijdag 08 april 2011 @ 18:16:
[...]


Hoewel off-topic: het is de verantwoordelijkheid van de opdrachtgever om genoeg kennis te verzamelen (intern of extern) bij het geven van een opdracht. Het blijft natuurlijk een spel, opdrachtgever wil zo veel mogelijk tegen zo'n lage kosten en opdrachtnemer wil niet meer doen dan afgesproken is en het liefst tegen een hoge prijs.
En die spanning is gezond (tenzij je een overheid bent want dan word je uitgekleed).
Want hoe zie jij het aankaarten van beveiliging/performance etc bij een klant? Je zal wel gek zijn als je aantal requests/sec contractueel vastlegt als je klant er niet over begint.
Ik vind desondanks 17/sec KNAP weinig voor een webcluster. Ik heb zelf een communitysite draaien met 100k unieke bezoekers per maand vanaf een (forse) VPS... Die doet er 700/sec.

Naar mijn mening is beveiliging iets dat je altijd goed moet regelen. Deze klant zit zeker niet op zijn geld en investeert zonder problemen grof als er aanleiding voor is. Indien ik voor klanten werk zal de beveiliging altijd zoveel mogelijk op orde zijn en getest ook al zal de klant er niks over zeggen. Dit zit gewoon in de prijs en als de klant dat niet wenst, jammer dan. Ik weiger om gatenkaas af te leveren.
D-Raven schreef op vrijdag 08 april 2011 @ 18:26:
[...]


Tuurlijk, maar feit blijft dat er een hoop idioten rondlopen. Helemaal als je met wat kleinere bedrijven werkt die geen kaas gegeten hebben van ICT, die gaan echt niet naar een 3de partij om informatie in te winnen.
Dit is geen superklein bedrijf maar ook geen ontwikkelfabriek. Ze bestaan al vele jaren en bieden een breed diensten pakket voor het hogere segment van de markt.
D-Raven schreef op vrijdag 08 april 2011 @ 18:26:
[...]
Natuurlijk moet je niet gaan vastleggen dat je website x aantal requests per seconde moet kunnen verwerken. Het is gewoonweg onrealistisch om aan het begin van zo'n traject zo'n soort eis vast te leggen. Maar wat je wel kan doen is zeggen dat als richtlijn een pagina binnen 1 a 2 seconden op je beeld moet staan.

Dit is een duidelijke indicatie naar de ontwikkelaar toe van wat er verwacht wordt. Maar geeft tegelijkertijd voldoende flexibiliteit.
Mocht het nu zo zijn dat de gemiddelde laadtijd van de website hoger ligt dan dit (laten we zeggen 5 seconden ofzo) dan heeft de opdrachtgever een wapen in hand om de ICT dienstverlener op zijn vingers te tikken.
Maar aan de andere kant als de meeste pagina's keurig binnen de marge geladen wordt (laten we zeggen alles tussen 0 en 3 seconden), en een paar pagina's doen er wat langer over. Dan is er niks aan de hand.
Vanuit Nederland ongeveer 5 - 8 seconde en vanuit de USA waar ook veel klanten zitten 12 - 15 seconde.

Volgens Google Sitespeed behoren ze tot de 10% langzaamsten van het web.

  • GlowMouse
  • Registratie: November 2002
  • Niet online
StM schreef op vrijdag 08 april 2011 @ 17:53:
De boel is ook extreem sloom. Het draait op een eigen cluster en de frontpage is gebenched met ab op 17 requests / sec. Dit komt voornamelijk doordat een pagina 265 requests nodig heeft om te laden en omdat er voor ieder plaatje en dingetje een aparte query naar de database gaat. De grote selects zijn gecached maar al die kleine query's niet.
ab laadt helemaal geen plaatjes. Als dit met 1 thread is, zou je het hele performanceprobleem kunnen verhelpen door de plaatjes normaal te gaan serveren.

  • StM
  • Registratie: Februari 2005
  • Laatst online: 07:15
GlowMouse schreef op vrijdag 08 april 2011 @ 18:34:
[...]

ab laadt helemaal geen plaatjes. Als dit met 1 thread is, zou je het hele performanceprobleem kunnen verhelpen door de plaatjes normaal te gaan serveren.
Dat klopt, ab roept echt alleen de frontpage zelf aan. Die doet er zelf 1 - 1.5 alleen al over. Daarnaast in de browser nog 264 andere zaken waaronder 36 js files :)

Dat waren eigenlijk 2 losse dingen die ik een beetje aan elkaar geplakt had...

  • D-Raven
  • Registratie: November 2001
  • Laatst online: 16-10 10:47
StM schreef op vrijdag 08 april 2011 @ 18:28:
[...]


Vanuit Nederland ongeveer 5 - 8 seconde en vanuit de USA waar ook veel klanten zitten 12 - 15 seconde.

Volgens Google Sitespeed behoren ze tot de 10% langzaamsten van het web.
12 tot 15 seconden!! what the flying fuck 8)7 , ik vraag me af wat de latency is vanuit amerika naar hun cluster.
Maargoed 5 tot 8 seconden binnen nederland is ook al veel imho, als gebruiker zijnde zou ik zelf al gaan afvragen of ik wel goed op die submit knop heb gedrukt als het zo lang duurt :P

  • leuk_he
  • Registratie: Augustus 2000
  • Laatst online: 23-11 22:51

leuk_he

1. Controleer de kabel!

D-Raven schreef op vrijdag 08 april 2011 @ 18:26:
[...]


Maar aan de andere kant als de meeste pagina's keurig binnen de marge geladen wordt (laten we zeggen alles tussen 0 en 3 seconden), en een paar pagina's doen er wat langer over. Dan is er niks aan de hand.
Performance (ook als er weinig load is) is(/wordt) ook van belang voor de google ranking:
http://www.seroundtable.com/archives/016469.html (die gaat specifiek over adwords, maar het verbaast me niks als het ook in de gewone ranking gebruikt wordt)

Verder kun je gewoon een rapport schrijven over wat je zelf al aangeeft.
-Beveiliging. ( heeft blijkbaar actie nodig)
-Onderhoudbaarheid van de code.
-performance (ook: schaalbaarheid, kan er simpel een 2e server bij voor meer performance?)
-Gebruikersvriendelijkheid (voor leverancier en klant)
-Kosten uitbreidingen (standaard modules van pakket x of alles 100% maatwerk)
-Stabiliteit ( en hoe wordt dit bewaakt.)


Verder zie ik de kreet "wanprestatie" niet terug. Zijn de tekortkomingen registreerbaar? Tegen wat voor kosten voor wie? Zijn er testen geweest en is het systeem in die staat geaccepteerd?

Need more data. We want your specs. Ik ben ook maar dom. anders: forum, ff reggen, ff topic maken
En als je een oplossing hebt gevonden laat het ook ujb ff in dit topic horen.


  • StM
  • Registratie: Februari 2005
  • Laatst online: 07:15
D-Raven schreef op vrijdag 08 april 2011 @ 18:38:
[...]


12 tot 15 seconden!! what the flying fuck 8)7 , ik vraag me af wat de latency is vanuit amerika naar hun cluster.
Maargoed 5 tot 8 seconden binnen nederland is ook al veel imho, als gebruiker zijnde zou ik zelf al gaan afvragen of ik wel goed op die submit knop heb gedrukt als het zo lang duurt :P
Gewoon de normale latency naar iedere netwerk in Nederland. Iets van 100 ms ofzo. Volgens een onderzoek in opdracht van Akamai dat ik gevonden heb uit 2009 is 40% van de ongerichte bezoekers na 3 seconde al weg. En dat was al een halvering van 3 jaar eerder...
leuk_he schreef op vrijdag 08 april 2011 @ 18:39:
[...]


Performance (ook als er weinig load is) is(/wordt) ook van belang voor de google ranking:
http://www.seroundtable.com/archives/016469.html (die gaat specifiek over adwords, maar het verbaast me niks als het ook in de gewone ranking gebruikt wordt)

Verder kun je gewoon een rapport schrijven over wat je zelf al aangeeft.
-Beveiliging. ( heeft blijkbaar actie nodig)
-Onderhoudbaarheid van de code.
-performance (ook: schaalbaarheid, kan er simpel een 2e server bij voor meer performance?)
-Gebruikersvriendelijkheid (voor leverancier en klant)
-Kosten uitbreidingen (standaard modules van pakket x of alles 100% maatwerk)
-Stabiliteit ( en hoe wordt dit bewaakt.)


Verder zie ik de kreet "wanprestatie" niet terug. Zijn de tekortkomingen registreerbaar? Tegen wat voor kosten voor wie? Zijn er testen geweest en is het systeem in die staat geaccepteerd?
Sinds begin 2010 (uit mn hoofd) neemt Google het mee en is inmiddels een zeer belangrijke factor geworden. Ze gaan dan uit van de Google Sitespeed gegevens die de Google toolbar verzamelt en die de browserlaadtijd van een pagina vastlegt. Volgens deze metingen behoord de site tot de langzaamste 10% van het web. (Men is flink aan het optimaliseren gegaan sinds Google de snelheid meeneemt.)

[ Voor 3% gewijzigd door StM op 08-04-2011 18:46 ]


Verwijderd

Met een 0.0354 s in Nederland en een 0.0425 s overzee en niet het verschil met
wat jij verteld met die secondes dan is er meer aan de hand.

schrijf gewoon wat je ziet en vertel ze dat.

  • F_J_K
  • Registratie: Juni 2001
  • Niet online

F_J_K

Moderator CSA/PB

Front verplichte underscores

smesjz schreef op vrijdag 08 april 2011 @ 18:16:
Hoewel off-topic: het is de verantwoordelijkheid van de opdrachtgever om genoeg kennis te verzamelen (intern of extern) bij het geven van een opdracht.
Deels oneens: het is IMHO ook een taak van de opdrachtnemer om 'dit moet je niet willen' te zeggen. Bijna per definitie heeft de opdrachtnemer op bepaalde gebieden veel meer kennis.

Het is uiteindelijk inderdaad een spel, maar als je als opdrachtnemer niet ook je verantwoordelijkheid neemt (en dan heb ik het niet over het verschil tussen 1.1 en 1.6 seconden, maar over 1.0 of 10.0, en slechte beveiliging) dan is het IMHO ook vooral jouw fout. Behalve als de specs 'maak je geen zorgen over XSS' en 'max 10.1 seconden' zeggen. Gemiddeld 7 seconden is iets dat ik als gebruiker niet zou accepteren.


Dat gezegd hebbende:
Zeggen de specificaties die de opdrachtgever gaf iets over de problemen? Is er geaccepteerd / wat zijn de acceptatiecriteria?

Afhankelijk daarvan is wanprestatie amper tot niet te gebruiken, IMHO. Klinkt wel als prutswerk waar je zo snel mogelijk van moet afstappen.

offtopic:
Zorg dat in je rapport Engelse-ziekte-taalfouten als in de topicstart ontbreken, staat zo onprofessioneel ;)

'Multiple exclamation marks,' he went on, shaking his head, 'are a sure sign of a diseased mind' (Terry Pratchett, Eric)


  • StM
  • Registratie: Februari 2005
  • Laatst online: 07:15
Ik moet eerlijk zeggen dat ik niet weet in hoeverre er specificaties bestaan die op de technische kant in gaan. Ik vrees dat dat beperkt is gebleven tot dit moet het systeem functioneel bieden en regelen jullie maar verder een goed systeem voor ons. Ik kan er weleens naar vragen maar echt interessant voor mijn rapport is het nu niet.
F_J_K schreef op vrijdag 08 april 2011 @ 21:58:
[...]

offtopic:
Zorg dat in je rapport Engelse-ziekte-taalfouten als in de topicstart ontbreken, staat zo onprofessioneel ;)
offtopic:
Ik heb al de afspraak staan met iemand om het rapport te controleren. Nederlands is niet mijn sterkste punt, ook al probeer ik dat naar buiten toe zo goed mogelijk te verbergen.

Verwijderd

ziet er beroerd uit. ik zou de stekker er uit trekken en opnieuw beginnen vanaf de bodem.

  • StephanVierkant
  • Registratie: Mei 2003
  • Laatst online: 05-11 23:08
Hoewel wanprestatie een juridische term is, maar hier wordt al snel over allerlei details gepraat. Volgens mij (correct me if I'm wrong) wil TS meer een discussie omtrent de conformiteit:
  • Had de opdrachtgever (klant) redelijkerwijs kunnen verwachten dat de website aan bepaalde eisen (snelheid, veiligheid, e.d.) zou voldoen? Het hangt er vanaf wat afgesproken is (staan er afspraken over snelheid in het contract?), maar ook wat er van verwacht kan worden: aan een site van k€30 mogen hogere eisen worden gesteld dan een van k€3.
  • Had de opdrachtnemer kunnen vermoeden dat wat hij ontwikkelde niet aan de eisen zou voldoen? Aan een webshop mogen ook hogere eisen worden gesteld dan aan een gastenboek van de lokale b-artiest die drie keer per jaar in het schnabbelcircuit optreedt.

  • YopY
  • Registratie: September 2003
  • Laatst online: 06-11 13:47
Het beveiligingsaspect is in ieder geval onacceptabel, zowel voor de klant als voor de ontwikkelaars. Als het je lukt, probeer eens gegevens van de gebruikers uit de database te halen dvm een SQL injectie of wat voor technieken daar ook maar zijn. Presenteer dat aan de klant / de opdrachtgever / je chef, en leg daarbij de wet bescherming persoonsgegevens naast (bijvoorbeeld).

Maar zoals elders aangegeven wordt, haal het contract / de overeenkomst er eens bij - als daar niks in staat over beveiliging en performance heb je - vanuit juridisch oogpunt - geen poot om op te staan.

Mbt performance kun je sowieso een lijstje met 'quick wins' opstellen, evenals de consequenties voor de belabberde performance (inclusief rankings en gebruikerservaring en het gevolg daarvan op de verkopen).

Mbt de ontwikkelaars zou ik adviseren ze voor een ultimatum te stellen: Of ze verbeteren alles met 5000% zonder extra kosten (afhankelijk van de overeenkomst), of je start het proces om over te stappen op een ander product. Geef hierbij de voorkeur aan een commercieel, uitontwikkeld product, aangezien die zowel goedkoper als beter ontwikkeld zijn. Zorg er ook voor dat je voordat je overstapt de requirements opstelt, waarbij natuurlijk ook beveiliging, performance en vindbaarheid in opgenomen worden.

  • Remus
  • Registratie: Juli 2000
  • Laatst online: 15-08-2021
Stephan4kant schreef op maandag 11 april 2011 @ 21:44:
Hoewel wanprestatie een juridische term is, maar hier wordt al snel over allerlei details gepraat. Volgens mij (correct me if I'm wrong) wil TS meer een discussie omtrent de conformiteit:
  • Had de opdrachtgever (klant) redelijkerwijs kunnen verwachten dat de website aan bepaalde eisen (snelheid, veiligheid, e.d.) zou voldoen? Het hangt er vanaf wat afgesproken is (staan er afspraken over snelheid in het contract?), maar ook wat er van verwacht kan worden: aan een site van k€30 mogen hogere eisen worden gesteld dan een van k€3.
  • Had de opdrachtnemer kunnen vermoeden dat wat hij ontwikkelde niet aan de eisen zou voldoen? Aan een webshop mogen ook hogere eisen worden gesteld dan aan een gastenboek van de lokale b-artiest die drie keer per jaar in het schnabbelcircuit optreedt.
Zelfs als er niks is vastgelegd mbt beveiliging, heeft de opdrachtnemer nog een zekere verantwoordelijkheid om te zorgen voor een goed en veilig systeem zonder (grote) overduidelijke beveiligingsfouten, dat geschikt is voor de wensen en eisen van de opdrachtgever. Overduidelijke en algemeen bekende fouten in de beveiliging doen daar duidelijk afbreuk aan: het is de professionele verantwoordelijkheid van de opdrachtnemer om dat te voorkomen. Dat kan dan vaak ook juridisch standhouden, waarbij de opdrachtnemer het probleem zal moeten herstellen.

Ik denk dat het in dit soort situaties misschien ook wel een idee is om juridisch advies in te winnen.

  • StephanVierkant
  • Registratie: Mei 2003
  • Laatst online: 05-11 23:08
YopY schreef op dinsdag 12 april 2011 @ 11:41:
Maar zoals elders aangegeven wordt, haal het contract / de overeenkomst er eens bij - als daar niks in staat over beveiliging en performance heb je - vanuit juridisch oogpunt - geen poot om op te staan.

Mbt performance kun je sowieso een lijstje met 'quick wins' opstellen, evenals de consequenties voor de belabberde performance (inclusief rankings en gebruikerservaring en het gevolg daarvan op de verkopen).

Mbt de ontwikkelaars zou ik adviseren ze voor een ultimatum te stellen: Of ze verbeteren alles met 5000% zonder extra kosten (afhankelijk van de overeenkomst), of je start het proces om over te stappen op een ander product. Geef hierbij de voorkeur aan een commercieel, uitontwikkeld product, aangezien die zowel goedkoper als beter ontwikkeld zijn. Zorg er ook voor dat je voordat je overstapt de requirements opstelt, waarbij natuurlijk ook beveiliging, performance en vindbaarheid in opgenomen worden.
Je spreekt jezelf nogal tegen. Je zegt dat je geen poot hebt om op te staan, waarom zou de opdrachtnemer ook maar enige moeite doen om iets te verbeteren? Ik denk wel dat je juridisch sterk staat als er echt prutswerk is geleverd: vooral als er niets op papier staat. Sommige dingen mag je nu eenmaal aannemen (juridisch kernbegrip: conformiteit).

Ben het ook niet met je eens dat bestaande applicaties altijd de voorkeur hebben, maar dat totaal ter zijde.

  • F_J_K
  • Registratie: Juni 2001
  • Niet online

F_J_K

Moderator CSA/PB

Front verplichte underscores

Als de klant wegloopt mist de ontwikkelaar toekomstige inkomsten v.w.b. onderhoud etc. Als er geen inkomsten meer verwacht worden dan zal die inderdaad snel 'nee' zeggen. Then again, misschien is het iemand die wel staat voor z'n werk. Als het zo ver zou komen het voor de rechter hard maken van die (non-)conformiteit kost sowieso vast geld en tijd.

Dat alles erg afhangt van wat er op papier is afgesproken mag duidelijk zijn. Het gaat niet alleen om de techniek, dat is "maar" een van de onderdelen van dergelijke vervelende trajecten. De vragen van Stephan4kant in "Wanneer is er sprake van een wanprestati..." zijn idd relevant.
offtopic:
IMHO is op de lange termijn 95 van de 100 keer het inrichten van de juiste standaardapplicatie de beste weg zolang het niet om exotische functionaliteit of afwijkend gebruik gaat, maar dat is hier nogal offtopic.

'Multiple exclamation marks,' he went on, shaking his head, 'are a sure sign of a diseased mind' (Terry Pratchett, Eric)


Verwijderd

Stephan4kant schreef op dinsdag 12 april 2011 @ 13:10:
Ik denk wel dat je juridisch sterk staat als er echt prutswerk is geleverd: vooral als er niets op papier staat. Sommige dingen mag je nu eenmaal aannemen (juridisch kernbegrip: conformiteit).
Ik denk dat je juridisch juist zwak staat als er niets op papier staat :p Ik heb geen enkele juridische achtergrond hoor, maar als ik zie dat je "sommige" dingen nu eenmaal mag aannemen dan zie ik al een enorm getouwtrek voor me over wat dat dan precies inhoudt.

TS, ik zou eerst naar je opdrachtgever gaan en uitzoeken wat hun verwachting was en op welke manier die zo hard mogelijk te maken is met mailwisselingen, specs, telefoongesprekken, gewoon alles. Als je dat weet zou ik het systeem langs die meetlat leggen. Constateren dat de code slecht is heb je al gedaan, maar je moet een verhaal hebben waarmee je opdrachtgever naar die bouwer kan gaan. Ze willen een stok om mee te slaan.

  • iceheart
  • Registratie: December 2005
  • Laatst online: 12-10 18:50
Verwijderd schreef op woensdag 13 april 2011 @ 00:32:
[...]


Ik denk dat je juridisch juist zwak staat als er niets op papier staat :p Ik heb geen enkele juridische achtergrond hoor, maar als ik zie dat je "sommige" dingen nu eenmaal mag aannemen dan zie ik al een enorm getouwtrek voor me over wat dat dan precies inhoudt.

TS, ik zou eerst naar je opdrachtgever gaan en uitzoeken wat hun verwachting was en op welke manier die zo hard mogelijk te maken is met mailwisselingen, specs, telefoongesprekken, gewoon alles. Als je dat weet zou ik het systeem langs die meetlat leggen. Constateren dat de code slecht is heb je al gedaan, maar je moet een verhaal hebben waarmee je opdrachtgever naar die bouwer kan gaan. Ze willen een stok om mee te slaan.
dat is niet waar. de norm is niet "sommige dingen" (wat inderdaad erg zwak zou zijn); de norm is datgene dat impliciet in redelijkheid van een dergelijk systeem verwacht mag worden.

als ik iemand vraag een webshop te bouwen, hoef ik dus *niet* te vermelden dat dat systeem fatsoenlijk beveiligd moet zijn.
als ik wil dat een store bepaalde features heeft in de layout, dien ik dat, waar het van het redelijk minimum afwijkt, te vermelden in de opdracht.


je advies na te gaan wat redelijke verwachtingen zouden zijn geweest is dan wel weer erg correct.
in principe kun je hier (in het kort) gewoon volstaan met de haviltex norm:
De vraag hoe in een schriftelijk contract de verhouding van pp. is geregeld en of dit contract een leemte laat die moet worden aangevuld, kan niet worden beantwoord op grond van alleen maar een zuiver taalkundige uitleg van de bepalingen van dat contract. Voor de beantwoording van die vraag komt het immers aan op de zin die pp. in de gegeven omstandigheden over en weer redelijkerwijs aan deze bepalingen mochten toekennen en op hetgeen zij te dien aanzien redelijkerwijs van elkaar mochten verwachten. Daarbij kan mede van belang zijn tot welke maatschappelijke kringen pp. behoren en welke rechtskennis van zodanige pp. kan worden verwacht.
stom gezegd: niet alleen de letter van de ovk, maar ook de geest en de vanzelfsprekende gevolgen ervan zijn relevant. en daar komen die verwachtingen en dergelijke van jou om de hoek kijken.

Verwijderd

@iceheart Die norm kende ik niet. Het lijkt me een opsteker voor de opdrachtgever en indirect StM. Ik zou mijn opdrachtgever op die Haviltex-norm wijzen, StM. Het is wellicht iets aan of over het randje van je opdracht, maar een beetje meedenken kan geen kwaad natuurlijk :)

  • F_J_K
  • Registratie: Juni 2001
  • Niet online

F_J_K

Moderator CSA/PB

Front verplichte underscores

Je kunt wel uit gaan van Haviltex, maar de gemiddelde rechter is zegmaar niet geschoold op dit gebied. Als het pak-em-beet over auto's of pensioenen gaat is "redelijkerwijs" nog wel te herkennen maar dat wordt lastiger als je CSRF roept. Dat zal hem niet overtuigen, "hackers kunnen er zo in, maar meer dan 100 gelijktijdigde bezoelkers juist niet" ook niet perse.
Als er niets zwart/wit op papier staat en je er op gokt dat jij beter 'nietes' kan uitleggen dan de tegenstander van de klant (ga er van uit dat die wel goed heeft bijgehouden wat er op papier staat) 'welles': hoeveel kosten is hij bereid te maken zonder de zekerheid te winnen? Recht hebben <-> recht krijgen. Hamiltex noemen: ja, maar noem vooral ook uit te zoeken wat er zwart/wit (en wat grijs) op papier staat.

Begrijp me niet verkeerd, wat je beschrijft klinkt als prutswerk en ik zou geen vertrouwen meer hebben in die club. Maar als er werk van wordt gemaakt: roep dat liever met, dan zonder bewijs dat er geen prutswerk is besteld ;)

'Multiple exclamation marks,' he went on, shaking his head, 'are a sure sign of a diseased mind' (Terry Pratchett, Eric)


  • farlane
  • Registratie: Maart 2000
  • Laatst online: 23-11 13:12
YopY schreef op dinsdag 12 april 2011 @ 11:41:
Geef hierbij de voorkeur aan een commercieel, uitontwikkeld product, aangezien die zowel goedkoper als beter ontwikkeld zijn.
Ja want alleen commerciële producten zijn goed en vooral nog goedkoop. |:(

Somniferous whisperings of scarlet fields. Sleep calling me and in my dreams i wander. My reality is abandoned (I traverse afar). Not a care if I never everwake.


  • Creepy
  • Registratie: Juni 2001
  • Laatst online: 24-11 18:26

Creepy

Tactical Espionage Splatterer

Nuttige toevoeging voor een topic van een jaar oud.....

"I had a problem, I solved it with regular expressions. Now I have two problems". That's shows a lack of appreciation for regular expressions: "I know have _star_ problems" --Kevlin Henney

Pagina: 1

Dit topic is gesloten.