Specifikáció, garancia szoftverfejlesztési szerződésben

 ( bodnarj | 2018. január 25., csütörtök - 20:25 )

Sziasztok.

Van egy szoftverfejlesztési szerződés egy új munkára, melyben a garanciára vonatkozó részbe a következőt fogalmaztam meg:


a. Nem tekinthető hibának a Specifikációban nem rögzített, pontatlanul vagy hiányosan
megfogalmazott követelmény miatti nem megfelelő működés. Ebben az esetben a Specifikáció és a Szoftver módosítása szükséges. Ennek módosítása külön megállapodás útján történhet.
d. A Specifikáció minél pontosabb – részletes leírással, esettanulmánnyal, példákkal, diagramokkal, folyamatábrákkal, képernyőtervekkel - elkészítése a Megrendelő felelőssége, a Fejlesztő ebben a Megrendelőt segíti.

A megrendelő ezt a következőre szeretné cserélni:


A megrendelő feladata a fejlesztési irány specifikálása, ami teljes egészében kimerül az elvárások átadásával a fejlesztő felé, a fejlesztő nem hivatkozhat nem megfelelően specifikált irányra, feladatra.
A fejlesztő legjobb tudása szerint az igénymeghatározást köteles azt legjobb tudása szerint segíteni, a nem specifikált igények nem késleltethetik a végrehajtást. A feladat végrehajtása kimerül a specifikált igények fejlesztésében. A fejlesztő köteles a fejlesztési igény meghatározásánál jelezni a számára nem egyértelmü feladatmeghatározást, ennek elmaradása esetén jelen körülményre nem hivatkozhat a fejlesztés időbeni csúszása esetén

Mi erről a véleményetek? Az én olvasatomban a fent leírtak szerint bármikor bármit kérhet akár a határidő előtt 2 nappal is amit nekem határidőre le kell fejleszteni.
Illetve ha menet közben rájött mégsem úgy van az üzleti folyamat ahogy ő elmondta akkor írja újra a teljes alkalmazást, az eredeti költségekért eredeti határidővel.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

A szöveg alapján szerintem kiköti, hogy amit ő átad az egyeztetési fázis után, azt teljesnek KELL elfogadnod (még ha nem is az), vita nincs.

A szerződés az egy jogi "munka", amit jogvita esetén jogászok fognak szavanként szétcincálni. Még az se garancia semmire, ha nagyon jó jogásszal készítteted a szerződést, de a mi véleményünk jogértelmezésünk aztán abszolút nem ér semmit.

Erre jó pl. a waterfall modell. Először közösen írtok egy specifikációt. Ha neki eszébe jut valami, beleírjátok. Ha te rájössz, hogy valahol hiány van, rákérdezel, beleírjátok. Egy ponton azt mondjátok, hogy kész, és ezt közösen aláírjátok. (Ez már lehet egy fizetési mérföldkő is.) Innen kezdve egyik fél se hivatkozhat hiányos specifikációra. És csak ezután indul a fejlesztés. Így nem lesz nyújtva a dolog, mint a rétestészta, könnyebb becsülni a fejlesztés hátralevő részét, stb. (Persze speckómódosítás közben is lehet, külön árazással, külön egyeztetéssel, stb.) Akkor van baj, ha bénák vagytok, és végül a specifikált termék egyáltalán nem teszi boldoggá az ügyfelet :).

+1

Lényegében én is ezt írtam bele a szerződésbe. Hogy specifikáljunk pontosan! De onnantól kezdve kész a specifikáció, az alapján megy a fejlesztés. De ha nincs benne a specifikációban egy funkció mert az ügyfél elfelejtette kérni, és már a kész szoftvernél derül ki hogy az kimaradt, vagy ha egy üzleti folyamatot rosszul modellezett le és a kész szoftvernél derül ki és emiatt a szoftver 60%-át újra kell írni az nem a fejlesztő felelőssége legyen.
Itt szerintem alapvetően az a gond hogy a megrendelő sincs tisztában azzal mit is akar (tapasztalat, már dolgoztunk nekik).
Egyszerű példával élve fejlesztetni akar egy pontos lőfegyvert de még nem tudja hogy milyet. Úgy gondolja most kell neki egy hatlövetű revolver, de ha később meggondolja magát hogy egy gépfegyver kell az is férjen bele a szerződésbe.

Azért nem egészen, te azt írtad, hogy a speckó a megrendelő felelőssége. Szerintem ez jobb úgy, ha te írod, ő adja az inputot, és ő bólint rá, illetve közös felelősség. És fontos kiemelni, hogy a specifikáció elfogadása mivel jár, hogy hat a határidőre, esetleg a végső árat is ez határozhatja meg, stb. Ez kicsit közelebb van ahhoz, amit a másik fél írt. Valahol a kettő között lenne az igazság. De a te fogalmazásod és az övé is nagyon pongyola. Ez így szerződésnek szerintem kicsit kevés.

Sztem irreális elvárás, hogy olyan folyamatok specifikációjáért vállaljon felelősséget a fejlesztő, ami nem az ő szakterülete (pl. iparági szabványok ismerete stb). Ellenkezőleg: a megrendelőtől elvárható, hogy a saját bizniszéről képes legyen megfelelő specifikációt adni a fejlesztő számára. A fejlesztőtől az sem várható el, hogy felismerje, hogy a specifikáció többértelmű lehet. Ha létezik olyan megoldás ami a specifikációnak megfelel, de az üzleti folyamatnak nem, akkor ennek hátrányos következményei a megrendelőt kell hogy terheljék.

Mobilon olvastam es lusta volam kommentelni. Nekem az jott le, hogy a fejleszto mindent az ugyfelre tol, az ugyfel meg mindent a fejlesztore. Meg kell tallani az arany kozeputat, es akkor win-win szerzodes lesz (aka uzlet), maskulonben az egyik fel kihasznalja a masikat (aka nem uzlet).

-
Kiterjesztések írása Go nyelvi környezetben

-1, nemhiaba szokott neha lenni egy business analyst a ket fel kozott. A megrendelo lehet egy zseni a szakteruleteben, de erthetoen, tomoren, jol strukturaltan osszefoglalni az igenyeket mar egy teljesen mas szakterulet. A ket fel kozul alapesetben a fejlesztotol lehetne elvarni, hogy legyen valamennyire kompetens a specko osszeallitasaban is, hiszen elvileg mar rengeteg ilyent latott, sot, ez az egyik kulonbseg a "fejleszto", es kodolo majom kozott.

----------------------
"ONE OF THESE DAYS I'M GOING TO CUT YOU INTO LITTLE PIECES!!!$E$%#$#%^*^"
--> YouTube csatornám

A specifikáció összeállításával nincs is gondom. Nekem az a bajom mikor a fejlesztés vége felé közlik, hogy jó lenne ha lehetne mindenhol cipőméretre szűrni, és bele is kerülne a cipőmétert minden kimutatásba. De addig szó nem volt cipőméretről.
A fenti szövegezés szerint akár ezt is kérheti a megrendelő az eredeti kereteken belül. És jogosan várja el a fejlesztő, hogy ezt az igényt jelezzék felé. Mindegy ki,a megrendelő vagy egy business analyst de ennek a specifikációban benne kell lenni, mert enélkül nem lehet megvalósítani a fejlesztés során, mert senkinek nem volt tudomása róla, hogy ilyen kell. Véleményem szerint megrendelő megfogalmazása szerint erre a fejlesztőnek kell gondolnia és a fejlesztő hibája ha erre nem gondolt, de ha kiderül, hogy ez mégis kell akkor meg kell valósítania és kész.

+1

Erre szokás felbérelni egy tervezőcéget, aki készít egy prototípust, ami alapján az ügyfél el tudja dönteni, ez kell-e neki, a prototípusból pedig a tervezőcég készít specifikációt, és akkor már nyugiban lehet szerződni. A tervezőcég garizza hogy a speckó egyértelmű, és akárhogy rakod össze, abból akkor lesz tank ha a protón is tank szerepel. Akkor le lehet írni hogy az lesz ami a speckóban van

Sose értettem amúgy, ha egyszer az építészetben a felülnézeti (alap-) rajzot meg a különböző metszeteket "terv"-nek hívják, akkor ugyanezt miért hívják az informatikában specifikációnak...

Azért a mi speckóinkat nem igazán lehet kétféleképpen értelmezni. Ez néha előny, néha hátrány...

well said

Erre találták ki az agilis módszertanokat (e.g. Scrum).

Főleg, ha már tudod, hogy jellemző az ügyfélre, hogy munka közben meggondolja magát...

2 hetes iterációk, minden iteráció elején az ügyféllel közösen meghatározva és priorizálva a scope (sprint backlog ... stb. ahogy éppen ma hívják :) ), wireframe-ekkel (ha van olyan UI), amit az ügyfél _aláír_, hogy ezt akarja. Ha később rájön, hogy mégsem ezt akarja, akkor:
- abortálhatja a sprintet, és akkor új sprint kezdődik a tervezéstől újrakezdődik (természetesen ez fizetési kötelezettséggel jár számára)
- a módosítási igényei új feature-ként bekerülnek a backlogba, amit a következő tervezéskor be lehet emelni a következő sprintbe
- nyilván lehet rugalmasnak lenni, ha az adott módosítás megkönnyíti de legalábbis nem nehezíti a munkát - de ez a ti döntésetek legyen, a default az a következő sprint.

A szerződésben ezt a munkamódszert, a kommunikáció módját (pl. hogy kölcsönösen elfogadjátok az emailt, ne kelljen pöcsétes papír két tanúval, elég ha visszaír egy OK-t) kell meghatározni.

Ja, na, kéthetente UI-t tervezni... mi csináljuk, bár most már 3 hetes UI ciklusaink vannak (van ennek egy gyönyörű sprint menetrendje, public-ba nem rakom ki de szívesen megmutatom), de azokat a tapasztalat szerint úgyse 3 hét megírni (nyilván nem 1 db képernyőt kapsz hanem egy komplett featureset / use-case csomag - Scrum nevén epic - összefüggő képernyőrendszerét)

De agilisan implementálgatni lehet. Mi néha megjelenünk egy csomag backlog itemmel, grooming meetingen feldobjuk, hogy ezekről lesz szó majd valamikor két sprinttel arrébb, és nézzétek meg, van-e kérdés, majd planningen beméretezzük amikor arra kerül a sor.

A legtöbb helyen mostanában amúgy user story-ként definiáljuk a követelményeket, acceptance criteria-kkal. De ettől még kell ugye az a szakembergárda, aki meg tudja fogalmazni a működést ebben a formátumban úgy, hogy ettől még az ügyfél értelmes rendszert kapjon a végén.

Ha van egy nagyobb, bonyolult rendszer, akkor ott miből indultok ki? Ezeket a 2-3 hetes sprinteket mi alapján kezditek el? Ott nem kéne egybe látni először a dolgot és utána szétbontatni sprintekre? Gondolok itt mondjuk egy folyamat irányítási rendszerre.

De, az alap első sprint kutatási sprint, van amikor ez másfél hónap, pl. az orvosi ügyvitelinél annyi volt. Egy kis webshopnál ez egy hét alatt lezavarható viszont...

Ilyenkor terepinterjúk mennek (beutaztam ezek miatt már a fél világot), meg konkurenciavizsgálat (van ennek egy módszertana, de nyilván VM-ben futó trial változatok, bemutató videók és user manualok az alapjai, meg az amit a usereknél látunk futni).

Ja, meg szabályozási környezet ismerete... a pénztárgép törvényt már kezdem pl unni :)

Utána épül fel csak a projektterv, akkor már látjuk, mik lesznek a rendszer hangsúlyai, mik a moduljai, és az első sprint rendszerint valami fő funkció köré szervezve az alap layout lerakásáról is szól.

Mondjuk ha Android Material van akkor a layouton nincs mit gondolkozni, de az ügyvitel még jórészt desktop.

Visszük ezekre néha a fejlesztőket is, hogy egy nyelvet beszéljünk, és ne legyen derült égből villámcsapás ha mondjuk közöljük, hogy a fűrésztelep folyamatirányításában nem érdemes csipogással figyelmeztetni a usert, úgyse hallja...

Értem, köszönöm.

Értem, köszönöm.

"A megrendelő feladata a fejlesztési irány specifikálása, "

na ez az, amibe én nem mennék bele. Mi az, hogy a fejlesztési *irány* specifikálása?

Nekem az a gyanús, hogy mindketten tapasztalat alapján akarjátok ezt belevenni. Ők úgy érezhették, hogy nem vagytok elég rugalmasak, ti meg úgy, hogy túl sokat engedtetek így is. Nem tűnik harmonikusnak a viszony...

+1, tapasztalatlansag miatti bizalmatlansagot erzek, egy agilis, iterativ folyamat kene ide, de azt a fejleszto urnak meggyozoen kene prezentalnia az ugyfelnek.

----------------------
"ONE OF THESE DAYS I'M GOING TO CUT YOU INTO LITTLE PIECES!!!$E$%#$#%^*^"
--> YouTube csatornám

Ja, és a specifikációról annyit, hogy az emberi nyelven megírt specifikáció sosem fed le mindent. (A program specifikációja végsősoron a kód (meg a rendszer amin fut) maga.)

Pont az a művészet a szakmánkban, hogy a specifikálatlan dolgokat úgy kell megoldani, hogy az pont jó legyen (és akkor a megrendelőnek esetleg eszébe sem jut, hogy te valamivel dolgoztál, mert neki ami nem probléma, hanem megoldás, az nem tűnik fel).

Mindenre kiterjedő pontos specifikációt írni pontosan annyi ideig tart, mint magát a programot megírni, ugyanis a kettő ugyanaz. A specifikáció ha még nem program, akkor még nem teljes.

Az egész folyamat végsősoron csakis úgy működik, ha mindkét fél részéről megvan a rugalmasság.

A megrendelő feladata a fejlesztési irány specifikálása... a fejlesztő nem hivatkozhat nem megfelelően specifikált irányra

Ez valami lángelme lehet...