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.
Tetszett a bejegyzés?
Megköszönöm, ha nyomsz rá egy like-ot vagy megosztod másokkal:
RustyRush
2010. október 17. — 21:34:58
“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!
dave
2010. október 17. — 21:42:36
é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)
azAttis
2010. október 17. — 22:09:36
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.
Athos
2010. október 17. — 22:15:20
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.
Andrei
2010. október 17. — 22:22:56
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. 🙂
[re=6062483]Athos[/re]: Köszi. Nem ismertem. http://hu.wikipedia.org/wiki/Scrum
slink
2010. október 18. — 08:18:36
Prototípus! Iteráció!
Mefi
2010. október 18. — 11:48:16
[re=6062480]RustyRush[/re]: 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.
[re=6062481]dave[/re]: 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.
[re=6062482]azAttis[/re]: ez teljesen jogos.
[re=6062483]Athos[/re]: scrum jóság, pont mostanában kezdtem el olvasgatni én is.
[re=6062484]Andrei[/re]: ó igen, meg a másik hasonló kedvenc kategória az a bank, ott vannak még vicces dolgok.
[re=6062485]slink[/re]: szekvencia!
saxus
2010. október 19. — 03:35:00
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.
Mefi
2010. október 19. — 13:05:33
[re=6062490]saxus[/re]: 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.
boci
2010. október 25. — 16:56:43
Ilyenkor mindig eszembejut Joel bacsi 🙂
http://hungarian.joelonsoftware.com/
http://js.hu/jos/