[Ara]

Ursprungligen postat av Doctor.Data

sidan ska funka till 100% nar jag far den i mina hander

Det finns INGET som funkar till 100%, testar man bara tillräckligt mycket hittar man buggar...

[Conny Westh]

När man skriver avtal på fastpris så måste man ha med de krav som ska uppfyllas så att tredje part eller oberoende testare i acceptanstestet kan avgöra; - Uppfylls kravet? (Ja/Nej). Varje krav ska dessutom vara atomärt, dvs odelbart. Varje krav måste ha en textuell beskrivning, eventuellt kompletterad med en bild som illustrativt exempel. Men det är det textuella kravet som gäller vid tolkningstvister.

Krav kan delas in i några övergripande kategorier:

- Funktionella krav (dvs verksamhets helt otekniska krav)
- Tekniska krav (som databasmiljö, utvecklingsverktyg, programspråk, integration med andra system, programmeringsstandard m.m.)
- Tidsmässiga krav (start och sluttidpunkter, deadlines)
- Processkrav (hur man går tillväga, ordningsföljd, avstämningstillfällen, acceptanstexter, delleveranser, styrning, problemhantering, överföring mellan olika faser, utbildning m.m.)
- Resurskrav (kompetenskrav på personal, Omfattning (dvs hur mycket personal behövs), maskinutrustning, kommunikationsutrustning, programlicenser)
- Finansiella krav (Arvoden, kostnader, betalningstillfällen)
- Juridiska/avtalstekniska krav (avtalets fullständighet, ändringar, om part hamnar i obestånd under avtalstien, force majeure, tvister, skadestånd, viten m.m.)


Det brukar även kräva att man har med en testspecifikation i kravet. Då är det lätt att avgöra om kravet uppfylls eller inte och det blir mindre tvister. Då kan leverantören själv testa om de uppfyller kravet eller inte, annars blir det subjektiva tolkningar och då blir det garanterat konflikter.

Det blir helt enkelt så att man som beställare måste tänka iogenom vilka krav man har redan innan man beställer och småsaker som man inte specificerar kan man inte hävda är kontraktsbrott.

Man ska också tänka på att det är vanligt att man beställer komponenter som inte kan köras självständigt utan som bara är en delmängd av ett system. Vill man ha ett komplett ystem som kan fungera självständigt så är det viktigt att man specificerar det.

Det är faktiskt rätt sällan jag har haft helhetsansvaret för ett system utan för det mesta har det varit leveranser av komponenter eller delmängder av gigantiska system med 100-tals utvecklare och annan personal/konsulter/leverantörer.

Det brukar då finnas specifikation hur de olika komponenterna ska kommunicera sins emellan genom s.k. interfacespecifikationer.

[marsii]

Oavsett hur hårt man styr upp med ett kontrakt, har en beställare mycket svårt att komma åt "kladdig kod".

Även om beställaren hyr in en oberoende kodgranskare, är det alltid en mer eller mindre subjektiv bedömning som måste göras och mycket är beroende av hur noggrann och pedantisk granskaren är.

Alla erfarna programutvecklare vet att all programkod kan skrivas på många sätt. Om man "endast" siktar på att uppfylla kontraktskrav, kan man förenkla arbetet genom att exempelvis skriva mycket "hårdkodat". Det fungerar enligt kraven, men blir tidskrävande att modifiera och underhålla.

Om man skriver underhållsvänlig och begriplig kod, kan tidsåtgången bli betydligt större, vilket få beställare förstår nyttan av eller vill betala för.

Eftersom det är så svårt att komma åt detta problem, är det nog det enda som fungerar (?) att det finns en tillit mellan beställare och leverantör.

Beställaren måste lita på att leverantören inte blåser honom på pengar och att de levererar en (tillräckligt) bra produkt i alla avseenden. Vilket alla framgångsrika programutvecklare har lärt sig.

[studiox]

Att strö salt i såren lär ju knappast hjälpa frågeställaren. Detta är ju inte första tråden i ämnet och det är ju lätt att säga att "dumma idiot du får skylla dig, jag själv är så intelligent och smart att jag ALDRIG gör några misstag själv".

Du pratar alltså om mindre än 100.000 investerat i kod, det är faktiskt otroligt lite pengar och, om du säger att du fått ett bra pris kanske motsvarande kostat 500-600.000 om du anlitat svenska programmerare - Detta kanske du redan kommit fram till då du investerat i svenska konsulter som tittat på koden.

Ingen här kommer kunna ta ställning till om du ska kasta koden eller börja om igen utan att ha sett koden, och den lär du ju inte visa för någon.

Du får helt enkelt fundera över om du ska lyssna på dom svenska konsulterna som du haft inne för utvärdering av koden eller om du kanske ska ta in någon till för att få en "2:th opinion".

[Conny Westh]

Ursprungligen postat av studiox

Du pratar alltså om mindre än 100.000 investerat i kod, det är faktiskt otroligt lite pengar och, om du säger att du fått ett bra pris kanske motsvarande kostat 500-600.000 om du anlitat svenska programmerare - Detta kanske du redan kommit fram till då du investerat i svenska konsulter som tittat på koden.

Normalt bör man nog räkna med att lägga ca 100 000-200 000 enbart på att ta fram en ordentlig kravspec för ett mindre system.

Säg att det tar ca 120 timmars jobb att ta fram verksamhetsmässig kravspec.

Sen beror det på om man har en arkitektur som är färdig eller om man ska bygag en helt ny arkitektur som i sig kan kosta allt från 500 -30 000 arbetstimmar.

Systsemet kanske tar 500-1000 arbetstimmar att utveckla om man har en bra arkitektur och sen tar det 200 timmar att acceptanstesta.

Då pratar vi om et tganska litet system i alla fall.

[tartareandesire]

Ursprungligen postat av studiox

Att strö salt i såren lär ju knappast hjälpa frågeställaren. Detta är ju inte första tråden i ämnet och det är ju lätt att säga att "dumma idiot du får skylla dig, jag själv är så intelligent och smart att jag ALDRIG gör några misstag själv".

Tror inte någon menar detta, åtminstone inte jag. Tvärtom är det ju bra att ge tips och råd om hur man undviker att råka ut för något liknande i framtiden. Det gynnar inte bara honom utan alla som någon gång kommer att befinna sig i en liknande situation.

[Conny Westh]

Ursprungligen postat av tartareandesire

Tror inte någon menar detta, åtminstone inte jag. Tvärtom är det ju bra att ge tips och råd om hur man undviker att råka ut för något liknande i framtiden. Det gynnar inte bara honom utan alla som någon gång kommer att befinna sig i en liknande situation.

Håller med om det.

Varken leverantör, beställare eller någon annan gynnas av havererade projekt. Möjligen gynnas beställarens konkurenter.