« Hé haver, specifikálj! »

Az van, hogy mikor mondogatták meg írogatták még évekkel ezelőtt, hogy mindig a fejlesztést megelőzően kell leírni mit fog tudni az a program. Ez persze akkor nem feltétlenül igaz, mikor mondjuk saját magunknak írunk valamit, mert a kód pötyögése közben úgyis az agyunkban van mit akarunk majd csinálni és hogyan.

De mikor a megrendelő félszavakban elmondja, mi meg elképzeljük és megvalósítjuk, idővel mindig az lesz, hogy ez így nem, az úgy nem jó. És ezért tényleg nem hibáztatható sem a megrendelő, sem a fejlesztő, egyszerűen annyiról van szó, hogy mindig specifikálni kell a dolgokat. Akár még szabvány meg ilyesmi nélkül is, csak legalább annyit leírva, hogy x menüre kattintva ez történik és ezt lehet csinálni. Majd ezt aláíratni mindenkivel, és utána ne legyen panaszkodás.

Előbb-utóbb mindenki rájön erre, aki ellenzi a specifikációk pötyögését. És persze unalmas és a fejlesztés legrosszabb része, de sokszor életet (és rengeteg időt) tud menteni.

Kommentek RSS ikon
A bejegyzéshez érkezett kommentek, amiket RSS csatornán is követhetsz.
„hogy ez így nem, az úgy nem jó”

Gyűlöltem… de komolyan ezt a részét. Az a legroszabb, amikor utólag jön az „ezt nem lehetne javítani? És ezt? És azt” szöveggel. Aztán a vége egy teljesen új/más dolog… Hihetetlenül nehéz feladatok ezek!
én csak beadandó házit írtam így progból – megterveztem, specifikáltam mindent, algoritmust leírtam formális eszközökkel, ábrák stb…10 oldal lett a specifikáció, de amikor gyakvez meglátta, egyből közölte hogy ezt hadd rakja fel a honapljára specifikáció mintának és hogy egy ilyen után már nem is érdekli annyira a programkód, csak hogy fusson… :D :D (mondjuk tény, hogy amit algoritmust leírok formális eszközökkel/ábrával, azt utána le is tudom kódolni és kb. csak favágás maga a kódolás :D)
Egy jó terv szerintem sok kis forgatókönyvből áll össze. Ez később beilleszthető, hivatkozható, tesztelhető! és rákényszerít a végiggondolására. Az ördög a részletekben lakozik.
A ló túloldala sem optimális, amíg nem automatizálható 99%-ban, addig egyszerűen lehetetlen egy komplex rendszernél A-Z-ig minden elő- és utófeltételt megállapítani, egy-egy eljárásnak az egyikből másikba való biztos eljutását matematikai eszközökkel bebizonyítani. Egy-egy kulcsfontosságú algoritmusnál persze érdemes lehet matekozni, de szvsz a legtöbb esetben egy jól szervezett, könnyen olvasható kód egy intuitív magyarázattal bőven elég annak belátására, hogy a szoftver és a követelmények összhangban vannak (kód review rlz), a precízebb ellenőrzést meg majd megcsinálják az automatikus tesztek. A legújabb divat egyébként a Scrum módszertan, érdemes utánaolvasni, aki nem ismeri, mert ez legalább a gyakorlatban is működőképes, ellentétben az éles szoftverfejlesztést még sosem (vagy utoljára évtizedekkel ezelőtt) látott okosok dogmáival.
Akkor van gáz, ha te megírod a speckót, a megrendelő meg többen van, mint az oszmán sereg, és mindenki főnök akar lenni odaát. Állami szektorban én ezt beszívtam. Szép volt, jó volt, de dobhattam ki a 40 oldalas, keresztbe-hosszába fogalmazot specifikációt. Igazából minél jobban bebiztosítod magad vele, annál jobban átrágja magát rajta a féreg. :)

Athos: Köszi. Nem ismertem. http://hu.wikipedia.org/wiki/Scrum
Prototípus! Iteráció!

RustyRush: megoldható általában, meg szerintem kikerülni sohasem tudod, de ha felkészülsz rá megfelelően, akkor kivédhető a nagy részük.

dave: egyébként az ilyen szintig menő specifikációtól borsódzik a hátam, nem jó értelemben, viszont például imádom bármilyen kódolás előtt a folyamatot megtervezni kockás papíron.

azAttis: ez teljesen jogos.

Athos: scrum jóság, pont mostanában kezdtem el olvasgatni én is.

Andrei: ó igen, meg a másik hasonló kedvenc kategória az a bank, ott vannak még vicces dolgok.

slink: szekvencia!
Haha, mi is ilyen téren próbáljuk rendbeszedni mostanság melóhelyen a dolgokat.

Egyébként legnehezebb dolog a funkcionális specifikáció letisztázása. A műszaki spec már egész egyszerű utána, meg jól összeszokott programozócsapattal nem is kell túlzásba vinni, csak a fontosabb dolgokat.

Másik hiba egyébként, hogy sokan azt gondolják, hogy a megrendelőnek kell kitalálnia a rendszert. Nem, nem szabad. Nem fog menni.

Kell írni egy vázlatos formátumú specifikációt, amibe minden folyamatot, adatot és funkciót össze kell szedni (eleve ez után lehet értelmes ajánlatot tenni), majd utána lehet nekiállni egy részletes, vázlatos képernyőtervekkel kidolgozott specifikációnak (gyk. a vázlat kibővítése).

Lényeg, hogy ez a megrendelő számára is jól értelmezhető legyen. Nem muszáj UML-l teletömni.
saxus: pontosan így. Mi általában úgy szoktuk, hogy: leülünk beszélni a leendő ügyféllel, elmondja mit szeretne. Küldünk egy árajánlatot, benne azzal hogy: „vécépapír-guriga számoló weboldal, funkciók: …, elvárások: …, dizájn: …” a végén pedig az ár. Ha elfogadja, szerződés és nekiállunk fejleszteni. Ez így volt eddig, de amit én módosítani fogok mostantól, hogy szerződés után írok egy kétoldalas specifikációt, amiben amolyan felhasználói kézikönyv szerűen le van írva a főbb funkciókör, aztán azzal lehet variálni még. A leggyengébb pont általában a dizájn egyébként.
Új komment

Itt az adott bejegyzésben elhangzottakhoz szólhatsz hozzá. Ha primitív, csúnya, vagy bunkó erkölcsről teszel tanúbizonyságot, tuti, hogy kimoderállak és rosszat mondok rólad. A hozzászólás nem kötelező, amit írsz vállald föl!

Ezeket az adatokat - ha a böngésződ kezeli a kukikat - csak egyszer kell megadnod, később módosíthatod.

Ha van gravatarod - és a gravataros e-mail-címeddel kommentálsz -, akkor az megjelenik. Ha nincs, vagy nem tudod miaz, akkor olvasd el az útmutatót és regisztrálj.

Neved: E-mail címed (nem jelenik meg): Webszájtod (ha van): Kommented: Mennyi kettő és három összege?
Ez védelmi célokat szolgál, szimplán írd be a fenti összeadás összegét!

A kommentedet írhatod nagyobb mezőbe vagy akár formázhatod is, de ha nem szalonképes, akkor moderálom!

Ajánló
Ebben a témában, esetleg ezen a napon voltak még ilyenek is:

Víz de kvíz! (2008. január 19., 10:39:35)
Nágymádzsár (2007. május 25., 09:50:57)
Ne higgyetek az appeknek (2012. március 25., 11:59:19)

Érdekességek
Száraz számok, pusztán csak tények:

Ez a bejegyzés 586 napja született, 211 szóból, és 987 karakterből áll. Ajánlhatod bizonyos linkgyűjtő oldalaknak: