81 - bozsineni szarul fogalmaz. A lenyeg, hogy a.classmethod() szabalyosan kiadhato hivas, ahol a egy peldany -- persze ami meghivodik az semmit nem for tidni arrol, hogy milyem lepdany szerepelt a hivasnal ha egyaltalan, es a fordito is csak az osztaly meghatarozasara hasznalja forditasidoben... En ezt nem neveznem az objektum megszolitasanak.
280-ban en nem latok ellentmodast. A peldanymetodusnak at van adva suttyomban a peldany, es ha masik peldanymetodust hivsz belole, akkor ezt passzolja tovabb. A staticnak ilyen nincs, ergo tovabbpasszolni se tudna mit, ergo ezt nem is szabad csinalni.
a fordító nem engedi meg, hogy statikus metódusból(osztálymetódus) példánymetódust hívjunk
Akinek nem triviális, annak ez tényleg félreérthető. Csak a this referenciát használva nem lehet példánymetódust hívni statikus metódusból. Más létező objektumpéldány példánymetódusát természetesen meg lehet hívni.
280. o. alul: "Fontos tudni: a fordító nem engedi meg, hogy statikus metódusból(osztálymetódus) példánymetódust hívjunk, hiszen a statikus metódus futása nem követeli meg a példány létezését, a példánymetódus ezzel szemben csak példányon tud dolgozni. "
Itt megint ellentmondást érzek a két mondat rész között. A második félben szerintem egy "nem" szócska kimaradt a "szemben csak" közül.
Itt világos, hogy mit értesz félre: a példánymetódusnak mindig van egy kötelező paramétere: az, hogy melyik az a példány, amelyikkel csinálnia kell valamit... (this objektum). Amikor egy példánymetódusban vagyunk, használhatjuk a 'másikmetódus(paraméterek)' szintaktikát, az azt fogja jelenteni, hogy 'this.másikmetódus(paraméterek)'. Ha viszont példánymetóduson kívül vagy (pl a main-ben, vagy egy osztálymetódusban, stb), akkor a 'metódus(paraméterek)' egyszerűen nem jelent semmit, mert nincs olyan, hogy 'this'.
Szerintem túl-aggódod a kérdést, a helyzet pontosan az, amit magad is logikusan érzel: az osztály mindig létezik, pontosan egy darab van belőle; példány viszont bármennyi lehet, nulla és végtelen között; ebből ésszerűen következik, hogy a példány használhatja az osztály erőforrásait, de fordítva nem.
Tisztázást szeretnék kérni, a következő problémámra. Angster könyvét tanulmányozom és a következőt találtam:
I. kötet 79.o alul-középen: "A példányváltozókat csak a példánymetódusok érik el, míg az osztályváltozót egyaránt elérik a példánymetódusok és az osztáymetódusok.Ennek az az oka, hogy egy objektumhoz mindig tartozik osztály, de ez fordítva nem mindig igaz: előfordulthat, hogy egy osztálynak adott pillanatban nincs egyetlen előfordulása sem."
Ez tiszta sor, értem.
81.o felül-középen: "Egy osztályt csak osztálymetódussal lehet megszólítani; egy objektumot meg lehet szólítani példánymetódussal és osztálymetódussal egyaránt."
Itt nincs valami ellentmondás? Fennt azt írja, hogy osztály nem hívhat objektumot, hátha nincs is, utána meg azt, hogy mégis.
280. o. alul: "Fontos tudni: a fordító nem engedi meg, hogy statikus metódusból(osztálymetódus) példánymetódust hívjunk, hiszen a statikus metódus futása nem követeli meg a példány létezését, a példánymetódus ezzel szemben csak példányon tud dolgozni. "
Itt megint ellentmondást érzek a két mondat rész között. A második félben szerintem egy "nem" szócska kimaradt a "szemben csak" közül.
Kérném szépen, hogy valaki hozzáértő világosítsa meg számomra a felvetéseim helyességét vagy helytelenségét. Köszönöm.
A többé kevésbé specifikáció az egy nagy kalap semmi!
Oké, megint félreértesz. Ezen a ponton természetesnek vettem, hogy az ügyfél óhaját már tényleg ismerjük. Természetesen ez nem az, amit elmond, hanem amit a programozó abból kitalál. A "többé kevésbé specifikált" tehát azt jelenti (bocs, tényleg félreérthető volt), hogy már elég jól tudjuk, hogy mit akar, de azt még nem, hogy hogyan fogjuk ezt megoldani.
Talán jobb példa egy logisztikai optimalizáló rendszer. Tudjuk, hogy költségcsökkenteni akar, és betartani a hatályos törvényeket. Ez már egy többé-kevésbé specifikált feladat. Nyilvánvaló, hogy nem a megrendelőtől fogjuk megkérdezni, hogy pixelre milyen gui-t akar, és igazad van abban is, hogy a korai kezelőfelület-mutogatással már elindul az a tanulási folyamat, ami leszűkíti a kört.
De itt még nem látjuk, hogy milyen algoritmusok a legmegfelelőbbek a megrendelő dolgainak a kezelésére. Itt jön a vízlépcső második fázisa, ami papíron kiszámíttatja a programozóval a lehető legjobb megoldást. Na ezt érdemes a kódolással együtt csinálni.
Az, hogy a 2 részt összevonod azt jelenti, hogy vannak olyan pillanatok a szoftver kivitelezésénél, mikor még nem látod magad előtt a végterméket, a célt. Ezután kiderülnek dolgok amik borítják az előző tervedet és akkor esetleg dobhatod ki azt amin addig ill. egy dolgoztál.
Pontosan! Ez a lényeg. A papír helyett kódban van a terv. Ez a kód nem a termék része, hanem a terv része, tehát nem kidobom, hanem a tanulságait levonom. Ez még a kidobásnál is komoly eredmény, mert a kész program a tanulságok feldolgozása után már nem fog ebbe a csapdába esni.
Ezért is hangsúlyozom, hogy ez a kód nem teljes, és kizárólag a tervezés szempontjából fontos dolgok szerepelnek benne. Például (fenti példában) ad abszurdum nincs alatta adatbázis, nincs azonosítva semmi, csak az optimalizáló algoritmus valamilyen megvalósítása készül el. Ez azért jobb, mint papíron, mert a megvalósíthatósági kritériumokon nem elméletileg kell agyalni, illetve a hatékonyságot nem becsülni kell, hanem tesztelni. Ezek elég komoly hibalehetőségek. Azonnal tesztelhető a szolgáltatások integrálása, és ebből kinövi magát egy rendszerterv, ami először nyilván pontatlan, de mivel végig ügyeltünk arra, hogy ne fercöljünk túl sok munkát a rendszerbe (tehát nincsenek még fix adatbázisok, nincsenek óriási esetszétválasztásaink, ahogy ezek a végleges kódba esetleg bekerülhetnek), átírni is nagyon könnyű.
Abban természetesen igazad van, hogy hozzáértő kezek kellenek mindehhez. A munka neheze a terv létrehozása (általában), a kódolás már egyértelmű, és könnyű találni megfizethető embert erre a célra. A terv létrehozását akár papíron, akár prototípussal viszont olyan szakembernek kell végeznie, aki tud kód-lehetőségekben gyorsan és precízen gondolkodni, miközben a megrendelő lehetőségeit is átlátja.
"többé-kevésbé specifikált feladatról " " (pl van valami gui/szolgáltatás terv, "
Hello!
Valamit te értesz nagyon félre. A fenti idézetből kiderül, hogy amit példának hozol fel az egy nonszensz. A többé kevésbé specifikáció az egy nagy kalap semmi! Ha ráadásul azt is megnézzük, hogy a GUI tervezés az egy projektnekkb. az utolsó negyedében van, akkor megint csak az jön ki, hogy fordítva ültünk a lóra.
1. Meg kell különböztetni a kívánságlistát a specifikációtól. 2. A megrendelő kívánságlistája nem teljes. Ezt tudni kell. Ebből a halovány kis dologból kiindulva kell(ene) fokozatosan kibontani, hogy MI A FELADAT. Nem tudom elhinni, hogy anélkül lehet jól megoldani egy feledatot, hogy elötte PONTOSAN kiderítettük volna, hogy MI IS AZ!
"A második és a harmadik fázis az, ami szvsz összevonható kényelmesen." Hát ez nagyon függ a feladat nagyságrendjétől. Nem mondom, hogy kisebb projektekben nem lehet összevonni. De mindenesetre ha átfedéssel is működik, akkor is kell egy terv a megvalósítás egészét illetően. Mire a program elkezd készülni a következőket tudni kell.
- Információs folyamtok a leendő rendszeren. - Manuális folyamtok a leendő rendszeren. - Adatbázis felépítése.
- Kritikus területek amelyek külön figyelmet kívánnak a programozótól. - A kész rendszer rugalmassága, továbbfejleszthetősége, modularitása. - és egy sor egyéb dolog.
Az, hogy a 2 részt összevonod azt jelenti, hogy vannak olyan pillanatok a szoftver kivitelezésénél, mikor még nem látod magad előtt a végterméket, a célt. Ezután kiderülnek dolgok amik borítják az előző tervedet és akkor esetleg dobhatod ki azt amin addig ill. egy dolgoztál.
A szervezési módszertanok nem véletlenül osztódnak szakaszokra. Ezeken a szakaszokon végigjutva a programozás fázisában már nem gondolkodsz a célon. Nem kell kitalálni semmit. Szinte csak kézügyesség kell a programozáshoz. Természetesen ehhez az kellene, hogy az informatikai projektekben legyenek hozzértő szervezők. Manapság - kényszerűségből - a programozóknak kell azzal a feladattal is megküzdeni. Nem is mondom, hogy időnként nem előnyös, hogy a szervezés fázisában a programozó is részt vesz. Azt azonban bajnak látom, hogy gyakorlatilag "kipusztultak" (ha egyáltalán létezett igazán) a szervezők. Helyettük a "managerek" és a programozók próbálják lefedni a szervezést és én úgy látom nagyon sok helyen ez egyszerűen nem működik és nem is tudják, hogy nem működik. Nem tudják, hogy nem jó mert szinte mindenhol döcög a dolog és ezért senkinek sem tűnik fel.
Na megint hosszabb lett mint gondoltam. Itt elvágom.
Én már többé-kevésbé specifikált feladatról beszélek. Olyan esetekről beszélek, ahol a feladat és a megrendelő kívánsága már tisztázva van annyira, hogy a szoftvertervezés fázisa megkezdődhet. (pl van valami gui/szolgáltatás terv, de nincs még alá precíz reprezentáció)
Igazad van abban, hogy a megrendelő óhaját is lehet ciklikusan kinyomozni, én nem erről beszélek.
A hagyományos vízlépcső azt mondja, hogy először kinyomozzuk a megrendelő óhaját, aztán leírjuk a szoftvertervet, aztán megvalósítjuk, végül tesztelünk. A második és a harmadik fázis az, ami szvsz összevonható kényelmesen.
Persze ennek nincs igazán értelme olyan favágó projecteknél, ahol csak adatbázist kell tüsszenteni egy webszerver alá, és kész is.
"Tulajdonképpen egy elméleti modell készül el, csak fordítható kód képében. Senki nem akarja piacra dobni az először elkészült kódot, mert az csak skicc, terv. A probléma az, hogy a lustaság sokszor azt súgja, hogy érdemes megtartani minél többet ebből a fázisból."
Előfordulhat, ahogy korábban is volt róla szó (autós példa) amikor vannak olyan kialakult feltételek amikor a prototípus módszer működik.
Kifejezetten informatikai fejlesztésekre (főleg minél nagyobb hangvételű a dolog, annál) kevésbé tudom elképzelni a prototípusos módszert. Persze házi barkácsolásra lehet jó.
DE! Az egész mögött az áll, hogy én mint szervező lusta vagyok felmérni az összes lényeges dolgot. Helyette inkább összedobok valamit (a pontos igények ismerete nélkül) és mutatok valamit. A megrendelő pedig hozzáfűzi (jobb esetben) a megjegyzéseit, a problémáit, amit nem teljesít a rendszer. Ami szerintem nagyon lényeges dolog, hogy ez a kezdeti modell nagyon derterminálja a fejlesztést. A megrendelő csak a modell-hez képest fogja elmondani a differenciákat. Valaószínüleg (és ez az elvárás is tőle) nem fog alapvető változtatásokat igényelni, de még ha kar is valószínűsíthetőleg enyhébb (/erősebb) nyomás alatt lesz, hogy az igényeit formálja át úgy, hogy a prototípus lehetőleg minél jobban lefedje a problémát.
Ennek a megközelítésnek az a célja, hogy minél kevesebb melóval oldjuk meg a feladatot. Ha ez nem így történik, akkor lesz ráfizetéses a dolog és akkor derülne ki ,hogy az alaposabb szervezés hatékonyabb. Ezt a különbséget a megrendelő "terelgetésével" próbálja megoldani a "szállító". A "legérdekesebb" esetekben azt mondja a megrendelőnek, hogy "... azt, úgy nem lehet megcsinálni ...", holott csak arról van szó, hogy a prototípust nem akarja kidobni, csak annyira akr eltérni tőle amennyire muszáj.
A fenti módszer alapja nem az, hogy a megrendelő mit akar kérni (nem is kiváncsi rá), hanem az, hogy mit tud könnyen szállítani.
Ezzel szemben az alapos felmérés és szervezéssel működő fejlesztések messzemenően az ügyfél érdekeit nézik és a projekt kezdeti fázisában mélységeiben próbálják felmérni a lehetőségeket, hogy abból a legjobbat hozzák ki.
Nem valószínű az, hogy a kétféle hozzáállásból hasonló eredmény születne azonos befektetéssel.
Sajnálom, de nem tudom elismerni, hogy a prototípusos módszer az informatikában normális dolog. Kis projekteknél elhiszem, hogy működik, de továbbra is fenntartom, hogy nem profi módszer. Ha valaki tudja, hogy egy projektnek milyen alapvető fázisai vannak, ha ismeri, hogy mit miután lehet megtervezni, akkor tudja, hogy a prototípusos módszerrel visszafele ülünk a lovon.
Természetesen nem mondom, hogy mindenkinek egyet kell értenie. Nekem az egyik diplomám információrendszer-szervezésből van. Az oskolában és a gyakorlati tapasztalataim alapján alakítottam ki a leírt véleményem. Sehol nem tanítják azt, hogy a prototípus módszer rossz. (Megemlítik, hogy van ilyen is.) Viszont jobb módszereket tanítanak kifejezetten tanítanak helyette.
Ha valamiről kiderül, hogy csináltuk, kihagytunk valamit, azért nem vízesésmodell a felelős, hanem rosszul dolgoztunk, nem tartottuk be maradéktalanul a szabályokat.
persze, igazad van, de a módszer jó/rossz volta sem abból származik, hogy lehet-e vele jó programot csinálni, hanem hogy mennyire könnyen. Márpedig az elméleti tervezés úgy, hogy abban ne legyen hiba, jóval nehezebb feladat, mint egy gyors közelítő program összedobása, teszteléssel, inkrementális szolgáltatásbővítéssel, aztán refactoringgal.
Tulajdonképpen egy elméleti modell készül el, csak fordítható kód képében. Senki nem akarja piacra dobni az először elkészült kódot, mert az csak skicc, terv. A probléma az, hogy a lustaság sokszor azt súgja, hogy érdemes megtartani minél többet ebből a fázisból.
Csak többet kell gépelni és fordítani, amit a vízesésmodell kidolgozásakor még azért nem szerettek, mert nagyon lassúak voltak a gépek.
(félreértés ne essék, nem mondom a vízesésmodell rossz, csak hogy ebből a szempontból éppen a többi jobb, és ezt akár el is lehetne ismerni :D)
Nálam a modell és a prototípus 2 külön dolog. Nyilván modell az kell. Ez akár lehet elméleti is. Szerintem ebből fakadt a félreértés. A gyakorlati modell (pl. autó), nagyon drága, elméleti modell nagyon olcsó. Ha valamiről kiderül, hogy csináltuk, kihagytunk valamit, azért nem vízesésmodell a felelős, hanem rosszul dolgoztunk, nem tartottuk be maradéktalanul a szabályokat. Az, hogy egyébként van egy másik módszer aminél, ha hanyagabbak vagyunk akkor sem lesz akkora bukta belőle, az más kérdés. A hanyag szervezőknek ez lehet előny. Nekem spec. ez nem szempont. Na jó, hagyjuk a témát.
Vagy én írok teljesen érthetetlenül (ez esetben elnézést) vagy te értelmezed rosszul (félre, tévesen, hibásan) amit írok: Tervezel egy rendszert, és a tervezésnek része egy modell készítése, aminek elkészítése során kiderült egy olyan dolog, ami egyébként csak implementációs fázisban derült volna ki, tehát ezzel megspóroltad (elkerülted, megúsztad) azt, hogy implementációs (tesztelési, integrációs, üzemeltetési, stb) fázisban kelljen újratervezni a rendszert.
Részemről lezártam ezt a threadet, mert elkezdtünk körbe-körbe járni, ráadásul sok köze nincs az OOP-hoz. Mindenki csinálja azt, amitől a megrendelő boldog lesz és egy talicska pénzt fizet bónuszként.
"És a pazarlás nagyon relatív, ha megspórolsz vele egy újratervezést, ami szintén nem 2 forint, plusz a határidőt is könnyű bukni miatta, akkor lehet jobban jobban jöttél ki."
Ha újra kell tervezni akkor azt nem lehet megspórolni. Ha ezt megsporólja valaki, akkor abból lesz a gányolás. Nem mondom, hogy gányolt rendszert nem lehet eladni, de az mégis valami más mint amiről én beszélek. Ha a projekt nek újratervezésre van szüksége, akkor azt nem lehet megspórolni. Ha meg lehet spórolni, akkor nem volt rá szüksége. Ha mégis megspóroltad, bár igazság szerint újra kellett volna tervezni, akkor gányoltál. Igen lehet olyan, hogy valamit a határidő miatt gányolnak. Ha maradunk az autós példánál, akkor ez lesz a legdrágább megoldás, mert ha valamiben tervezési hiba marad azért mert a határidő vagy más miatt hibák maradtak, akkor az a termék tiszta csőd. Autók visszahívása, javítások, presztizs veszteség, stb...
Az, hogyha projet közben kiderül valamiről, hogy nem tökéletes, de benne hagyjuk a rendszerben, akkor az nem csak arról szól, hogyha nem veszünk róla tudomást, akkor olcsóbban kijövünk, hanem arról is, hogy nem azt fogjuk előállítani amit szerettünk volna. Minőségében mást állítottunk elő. Mintha törvényesítettük volna a selejtet. Mert így kényelmesebb és rövid távon olcsóbb.
Még mindig azt mondom, hogy tervezni a legolcsóbb, újratervezni a legolcsóbb, ha nem itt változtatsz, hanem későbbi fázisban, akkor sokkal többet buksz. A költség minden komolyabb projektben csak nő ehhez képest.
Az, hogy adott esetben mondjuk pontosításokat végzel a korábbi fázisok adataiban (projektfájl) az nem jelenti azt, hogy nagyon megugrodtak a költségeid. (Akár 2 forint is lehet :) )
"Egy nagyon fontos dolog van és szerintem ez a lényeg. A legolcsóbb dolog egy projet során - ha valami változás van -, hogy a papírkáinkon, a terveinken módosítunk." Ezt senki sem vitatja. Pl. report02-3.pdf Table 1-5 (1-13. oldal).
"Én is épp azt mondtam x hozzászólás óta, hogy nem hatékony. Borzasztóan pazarló." Dehogynem hatékony. És a pazarlás nagyon relatív, ha megspórolsz vele egy újratervezést, ami szintén nem 2 forint, plusz a határidőt is könnyű bukni miatta, akkor lehet jobban jobban jöttél ki.
"A protitípus modellnek az adja meg a létjogosultságát, hogy egy-egy projekt folyamán, a projekt kezdeti részén nagyon kínos az a "csend" amit a megrendelő érez." Ennyire nem egyszerű a dolog, és ezzel együtt is lehet kínos a csend. És nem csak azok csinálják így, akik nem értenek hozzá vagy képtelenek beszélni az ügyféllel.
Valószínűleg nem járok sikerrel, de azért megpróbálom:)
Szóval ha bárki küldene az email címemre uml diagramot, bármilyen jó - Pl.: Üzleti folyamat diagram Követelmé ny diagram Használati-eset diagram Osztálydiagram Állapot-átmeneti diagram Aktivitásdiagram - azt nagyon megköszönném.
Életszerű, igazi, működö program diagramjai sokat segítenének nekem a megértésben. Előre is köszönöm.
Mondjuk nekem ilyen típusú munkáról nagyon kevés tapasztalatom van, de eddig mindig azt láttam, hogy a megrendelő általában szeret beszélgetni a tervezési fázisban fontos dolgokról is. Ha jól kommunikáló ember tartja a kapcsolatot a megrendelővel, el lehet érni azt is, hogy ne érezze, hogy nem halad a munka, mert "az embereink kitalálták, hogy hogyan oldható meg a probléma, amiről múlt héten beszéltünk" típusú, nem programozási, hanem tervezési lépésekből is lehet prezentálni.
A vízesés modell hátulütője nem elsősorban az, hogy a megrendelő eleinte nem lát semmit, hanem ha nem jó a kommunikáció, akkor attól, hogy eleinte nem lát semmit, eleinte nem is jön rá, hogy más készül mint amire gondolt. A jó kommunikáció ezen elég sokat segíthet. No meg szerencse a megrendelővel :D
A másik dolog a vízesésben, hogy az olyan feladatokhoz való, amikor egy megrendelő egyszer kér valamit, vár, és aztán megkapja. Esetleg plusz support, természetesen, de most nem ez a lényeges. (nevezzük el ezt szekvenciális esetnek)
A körkörös modellek pedig akkor jók, ha a "megrendelő" felvesz programozókat, és azt mondja nekik, hogy a cég munkájához gyártsanak valami szoftvert, amit aztán folyamatosan igazítanak a munkához.
A kétféle munka között talán több a különbség, mint a közös vonás. A szekvenciális esetben a specifikációt valóban érdemes a kódolás előtt nagyon megcsiszolni, mert a kód teszteléssel együtt optimálisan egyszer készül el. A ciklikus esetben természetes, hogy a kód nem állandó, mindenképpen változni fog minden kódrészlet valamikor, tehát a specifikációval nem kell annyira pontosan foglalkozni, elég hozzávetőlegesen, ha ez sokat gyorsít a verzióváltásban. Ha nem jó, hát úgyis megváltozik hamarosan, és addig is van valami, ami működik, és segíti a feladat folytatását.
A szekvenciális eset nem okoz különösebb fejfájást semmilyen rendszerben, a ciklikushoz viszont jó ha van a kéznél valami OOP támogatás.
"Meglepődnél, ha tudnád, mennyi pénzt költenek ilyen célokra. És nem csak a szoftveriparban, pl. az autóiparban jellemzően ilyen célra megy el jónéhány autó a tervezés során, és azok darabja nagyságrendekkel többe kerül, mint a sorozatgyártott változatok. Ugyanis bármilyen jó emberi és számítógépes szimulációk vannak, egyelőre még semmi nem helyettesít egy jó prototípust."
Igen. Elhiszem, hogy rengeteg pént költenek ilyen célokra. Egyébként nem is vitatkozom, azzal, hogy a gyakorlatban sokszor nem úgy működnek a dolgok ahogy annak lennie kellen. De lássuk: Minden ilyen próbálkozás célja, hogy egy olyna -a projekt számára fontos ember meggyőzésére irányul - akinek a hozzértése (valamilyen szempontból) nem megfelelő. Legalábbis nincs rá lehetőség/idő/stb. arra, hogy a döntéseit megalapozott információk alpján hozza. Ekkor kell elővenni a prototípusos módszert. Nem mondom, hogy nem volt hasonló életem során. Ennek leglátványosabb és egyben (szerintem) legsajnálatraméltóbb véglete, amikor nincs is mutatni semmit, de néhány jól sikerült slide-al és komoly arccal jó benyomást keltve pozitív döntést lehet kicsiholni. Ugyanakkor nem gondolom, hogy azért mert olyan emberek keverednek egy projektbe - lehet, hogy szükségszerűen - akik nem mélységében értenek ahhoz amiben dönteniük kell, úgy akkor az a legjobb megoldás amivel őket meg lehet győzni.
Értem én, hogy ettől függetlenül ez a valóság. Én csak az mondom, hogy akár ez a valóság akár nem, nem ez a legproduktívabb módszer. Az autóipari példa meg arra jó, hogy lássuk: Nem nulláról indul egy autó fejlesztése. Rengeteg olyan információ létezik a korábbi autók fejlesztéséből, amire nem is kell szót fecsérelni, mert evidencia. Ha még azt is meggondoljuk, hogy alapjában véve az autógyártás (célja és a meghajtás technológiája) 100 éve alapvetően nem változott, hiszen ugyanazt a technológiát csiszolgatják/fényezik akkor nem csoda, hogy ilyen körülmények - és egy csomó általam nem említett - feltétel mellett működik a prototípus módszer.
Egy nagyon fontos dolog van és szerintem ez a lényeg. A legolcsóbb dolog egy projet során - ha valami változás van -, hogy a papírkáinkon, a terveinken módosítunk. Ez nem kerül szinte semmibe. Ha a módosítás a tervezéséi fázis után következik be, akkor az már jelentősebb kültség. Nyilván minél később derül ki valami annál költségesebb lehet ugyanaz a módosítás.
"Meglepődnél, ha tudnád, mennyi pénzt költenek ilyen célokra. "
Pontosan így van. Erről van szó. Rengetegbe kerül. Tökéletesen egyetértünk! Én is épp azt mondtam x hozzászólás óta, hogy nem hatékony. Borzasztóan pazarló. Nyilván, ha van miből pazarolni, és semmi sem drága, akkor ez egy tökéletes módszer! :) Vannak olyan helyzetek, példák, ahol a költség nem a legfontosabb tényezője a projektnek. Így tehát működhet.
A vízesés modell pont azért működik, mert ha rendesen megcsinálja valaki, akkor a végén azt kapja, ami a cél. Ha a cél közben változik, akkor azon a prototípus nem segít, hisz akkor az a prototípus nem azt fogja szolgálni amit a megrendelő a változtatotás után igényel.
Visszatérve az informatikára. A protitípus modellnek az adja meg a létjogosultságát, hogy egy-egy projekt folyamán, a projekt kezdeti részén nagyon kínos az a "csend" amit a megrendelő érez. Ilyenkor semmi látványos dolog nem készül. A szervező dolgozik, papírokat gyárt, de semmi látványos dolog nem képződik. Legalábbis a megrendelő nem érzi, hogy történne valami. Teljesen tipikus pl. (10 esetből sajnos 9-ben így történik,) hogy egy informatikai fejlesztés korai sszakszában vesznek számítógépet (szekrényt) és beállítják a gépterembe. Ezek után már meg lehet mutatni a "főnöknek", hogy lám-lám, halad a dolog íme itt van a számítógép ami a rendszerhez kell. A szörnyű az egészben az, hogy előbb fel kellene mérni, hogy mi az a pontosan mit meg kell oldani, milyen lehetőségek vannak hozzá, milyen kész programokat lehetne felhasználni, ezekhez a programok milyen környezetben futnak a leghatékonyabban, milyen operációs rendszeren és milyen vason és egy sor egyéb dolog. Ehhez azért kell idő, hogy végigelemezze valaki és beszerezze a technológiai/piaci onformációkat ami alapján felelős javaslatot tesz. Mire szegény informatikaus ebbe a fázis ba jutna, addigra a nagyokosok bevásároltak és innentől már nem az a kérdés, hogy miképp lenne, a legjobb, hanem az, hogy ebből az erősen bekorlázozott, helyzetből mit lehet kihozni.
Mindezt csak azért mondtam el, mert szerintem a fenti probléma és a prototípus modell megoldás is egy tőről fakad: a "mutassunk már valamit" érzésből, ami sajnos nem jó, hogy így van. A projekt pont akkor megy jó úton, ha a kezdeti fázisban semmi látványos dolog nem történik. Sajnos azonban ezt elmagyarázni a közgazdagi ismeretekkel rendelkező embereknek és a korai fázisban megtartani a bizalmat, tényleg nem egy könnyű feladat prototípus vagy bármi más SHOW szerű elem nélkül.
"Én pedig el sem tudok képzelni jobbat, mint a víesés modell." És mit teszel akkor, ha az ügyfél gyakorlatilag naponta változtatja a specifikációt, és ami még rosszabb lehet, az alattad levő frameworkot, amire a te projekted épül? Kidobod?
"Dolgozni valamin amit lehet, hogy nagyrész kidobsz?" Az, hogy te még nem találkoztál vele, nem jelenti azt, hogy nem is létezik. Attól, hogy hűlyeségnek gondolod, még lehet jó.
"Ha nem kötsz szerződést akkor milyen szintig" Szerintem alapvetően félreérted a dolgot. A prototípusgyártás a projekt része, van költségvetése, határideje, célja. Szó sincs róla, hogy a kivitelező céltalanul elkezd játszadozni, mert éppen unatkozik. Meglepődnél, ha tudnád, mennyi pénzt költenek ilyen célokra. És nem csak a szoftveriparban, pl. az autóiparban jellemzően ilyen célra megy el jónéhány autó a tervezés során, és azok darabja nagyságrendekkel többe kerül, mint a sorozatgyártott változatok. Ugyanis bármilyen jó emberi és számítógépes szimulációk vannak, egyelőre még semmi nem helyettesít egy jó prototípust.
"Az a megoldás, hogy "Csinálok valamit és ha nem jó legfejjebb az egészet újra kezdem előről..." , az nekem nem egy komoly módszertan." Annak ellenére, hogy neked nem komoly, néha ez az egyetlen megoldás. A megrendelők halmaza végtelen, és nem az a jó szakember, aki bármire is azt mondja, hogy hűlyeség vagy komolytalan, hanem az, aki a lehető legtöbb módszert ismeri és azok közül ki tudja választani az adott feladathoz legmegfelelőbbet (még akkor is, ha az ellen személyes ellenszenve van), vagy akár többet is össze tud kombinálni.
"Látni kell (és ez csak tapasztalat útján lehet, de szerintem nem is kell hozzá sokat tapasztalni)" Leírtad a lényeget. Vannak dolgok, amiket papíron nem lehet megtapasztalni.
"akkor le kellene fektetni egy egyértelmű módszertant arra vonatkozólag, hogy miképp lehet eldönteni/kiválasztani, hogy adott esetben melyik az egyértelműen üdvözítő módszertan az datt projektre." Vannak próbálkozások, de általánosan működő recept nincs, mert ez már a művészet kategóriájába tartozik. Van aki megérzi, van aki nem. A meteorológia és a pénzügyi elemzés keveréke.
"Nemhiszem, hogy a "megrendelő" fogalma nálam más lenne mint másnál." Szerintem szerencsés ember vagy. De hidd el, hogy mindenkinek nincs lehetősége tökéletes megrendelőkkel dolgozni, és bizony előfordul, hogy a leggondosabb felmérés és tervezés ellenére kiderül, hogy a) a Close gomb nem zöld, hanem piros kell legyen vagy b) a termék műszakilag nem kivitelezhető a megtervezett módon vagy c) akármi más. És hidd el, másoknak sem az a célja, hogy egy elégedetlen ügyfelet hagyjon hátra egy csődbement projekttel.
A fentiek egyáltalán nem azt jelentik, hogy rossz ez a módszertan, hanem azt, hogy van ahol nagyon jól működik, és van, ahol nagy tévedés lenne alkalmazni.
