Nos igen. A bevezetés nálunk nagy ellenállást váltott ki a fejlesztőkből, hiszen a szabványosítással, kötelező szabvány szerinti dokumentálással - ők úgy érezték - a kreativitásuk lett megnyírbálva. Jó 1/2 év kellett ahhoz, hogy megtapasztalják, a kreativitás nem a "zseni rendetlenségében" rejlik. Ezzel szemben a szabványok követői észrevették hogy a számlájukon több pénz gyűlik, mert hatékonyan tudnak eggyütt dolgozni, a munkaidő nem egyeztetéssel telik el lévén szabvány szerint dolgozva passzolni fognak a rutinok, a programok a mások által tervezett adatbázisok, user IF-ek, stb. Ehhez csak jól kitalált szabvány és rengeteg türelem szükséges, az idő meghozza gyümölcsét. :-)
Na igen.
Többször leírtam, hogy NEM módszertant kérek, hanem olyan tapasztalatot, hogy: Mikor nálunk megpróbáltunk bevezetni ilyet, akkor ez meg ez volt a gond, ezen és ezen bukott meg, ez és ez miatt sikerült.
Nem hiszem, hogy keresztül lehet vinni egy hónap alatt - tudod, tanácsot kértem, nem azt mondtam, hogy hülye vagyok.
Nem hiszem, hogy meg tudom mondani a "frankót", de megpróbálok tanácsot adni.
A dolog lényege, hogy még nem találták ki A nagybetűs módszertant. Nincs tökéletes, nincs olyan, amit mindig, minden helyzetben lehet alkalmazni. Az egyedüli járható út, hogy mindenhonnan (több módszertanból) összeszeded azokat a dolgokat, amelyeket hasznosítani tudsz.
A másik nagyon fontos dolog, hogy az alkalmazottakkal meg kell értetni, hogy miért akarsz te most itt bekavarni nekik, amikor eddig is ment minden magától. ;) Ez a fázis nagyon lényeges! Értse az a fejlesztő, hogy miért dolgozik projectben, miért van verziókövetés, és miért gyártasz (keserves munka árán) modulteszteket. Ha nem értik meg, csak kapnak egy utasítást, hogy mostantól így kell csinálni, az önmagában nem ér semmit. :((
Ne hidd azt, hogy ezt majd egy hónap alatt keresztül lehet vinni!
Próbáld meg lépésenként, fokozatosan átalakítani a jelenlegi munkafolyamatokat!
Belső fejlesztések, "legacy" program és adatbázis Oracle-ben, viszonylag nagy rendszer, a projektek közepes méretűek. A megrendelő értelmes, saját magának csináltatja a dolgokat, szeretné ha működnének.
Ezért keresek olyan véleményeket, tapasztalatokat, hogy esetleg programozók, szervezők hogy csinálták, látták, amikor náluk került sor hasonlóra, illetve ők vezetek be ilyen rendszert.
A cég egy szoftverfejlesztő részleg, 8 programozóval, amely önmaga szoftverfejlesztési redszerét próbálja helyrerakni úgy, hogy közben dolgozni is lehessen azért.
Én eddig gyakorlatilag csak egyedül fejlesztettem, csapatban nem, úgyhogy igazából nekem végképp nincs alapom belekotyogni. :) Ugyanezért hajlamos vagyok egy kicsit naív perspektívát felvenni.
Mekkora csapatról, milyen méretű projektekről lenne szó, és mennyire értelmes a megrendelő (cég)?
Szerintem nagyon fontos egy jó szervező és egy jó analyst; ők először is megpróbálnak a megrendelőnél felállított, az információáramlást akadályozó szervezeti korlátokon áttörni, és minél több helyről minél több információt begyűjteni a tényleges feladatról. Ha buta a megrendelő, akkor nem a megfelelő embereket ülteti le a fejlesztőcéggel való tárgyaláshoz, hanem valakit, akinek csak egy kényelmetlen feladat az egész, és nem megoldást akar, csak túl akar lenni rajta. Vagy egyszerűen csak nem látja az előnyeit az informatikai rendszernek. Ilyenkor a szervezőnek (vagy ügyfélkapcsolatosnak ha van ilyen külön) túl kell verekednie magát rajta, és az analystet az arcvonal mögé kell juttatnia, hogy ő ott hatékonyan tudjon felderítőtevékenységet folytatni. :)
Na, itten van egy érdekes kérdés, ami ugyan más síkon közelíti meg a dolgot, de szorosan kapcsolódik.
A feladat roppant "egyszerű": egy szoftverfejlesztéssel foglalkozó cégnél, be kell vezetni egy fejlesztési módszert.
Magyarul a "Nagy álmot" a szervezett szoftverfejlesztést.
Milyen tapasztalatok vannak ezen a téren, milyen buktatókkal, problémákkal találkoztatok eddig az ilyen próbálkozásoknál?
A végcél egy zökkenőmentes, jól szervezett dolog lenne, ahol a dokumentációk nagyjából-egészében időben és megfelelően elkészülnének, nem a programozóknak kéne minden kis hülyeségnek utánnajárniuk, vagy legalábbis ezt szervezett keretek közt tehetnék meg, egységesebb lenne, és ezáltal könnyebben áttekinthető minden kód, és így tovább.
A tudásbázis egy része, amiről beszélsz az az msdn. Értelemszerűen csak microsoft cuccokkal, de pl. a példaprogramok sokszor érdekesek lehetnek más szempontból is.
Sajnos a módszertani dolgokkal kapcsolatos olyan igazi, mindent felölelő oldalt én még nem találtam. :(
Ha esetleg valki tud, linkelhetne párat. ;)
Ne haragudjatok hogy ide írok, de sürgősen kéne valahonnan egy C++ Builderben írodott memória játékprogram. Semmi különöset nem kell tudnia, képek közül párokat találjon, és vmi pontszámlálás legyen benne. Ha valakinek esetleg van ötlete hogy ilyet hol találok a neten, vagy esetleg van készen és meg tudja tenni küldje el erre a címre:
Hmmm, úgylátszik azoka fórumok, melyekhez hozzászólók egyszercsak befulladnak. Többen mintha más dolgokról is beszéltek volna, bosc nem akartam elvenni a kedveteket. Ha meg elvettem, legalább haragudjatok egy kicsit verbálisan is.
Azt hogy igazán még nem látom hol lenne ez jó. A "m. intelligencia" nem találhatja ki a megrendelő helyett a megoldást, a program tervét meg egyszerűbb megérteni (személyesen) és részekre osztani és ahhoz keresni eszközöket, mint megértetni magát a feladatot egy mesterséges intelligenciával.
Szóval nekem ez kicsit futurisztikus. Talán egy példán keresztül levezethetné Zinger (mozis példa a filoprog topicból?). Szerintem általában nem "m. intelligenciára" van szükség, hanem jobban használható eszközökre, s akkor nem lesz a MI-nek ilyen misztikus jellege, ami majd munka nélkül teremt rendet ebben a dzsumbujban amit kialakitott a programozó-társadalom magának.
Amúgy viszont nem vagyok szakértő etéren, csak a józaneszemet járatom rajta. Mintha az strukturált adatok (komponensek, tulajdonságaik, leirásuk) nem a MI területe lenne.
Es mit gondolsz errol az automatikus, mesterseges intelligencias dologrol (amelyikhez hozzacsapunk egy uj elemet, az "bemutatkozik", az alaprendszer azt "megerti", es attol kezdve ugyanugy hasznalja mint az eddig meglevo elemeket)
Szerintem nincs olyan nagy szökség arra, amit Zinger szeretne, a nagyonöszinte objektuomokra, amik képesek magukat bekonferálni. Vagy legalábbis kezdetnek nem, s a gépnek szól vagy embernek szól dilemma igyis megmarad. Inkább az a gond, hogy pld. a Delphi komponenseket tartalmazó sitokon nem lehet összetettebben keresni. Mivel helpet egyszerű összedobni, de nem elég struktúrált, ezért pld. egy komponensről ugy tudhatsz meg valamit ha letöltöd, felrakod, stb. Mag a telepités is túl komplikált, további eszközöket igényel (zip, readme).
Az ideális állapot szerintem az ha legalább okos katalógusok lennének (valaki emlitette a központi konverter listát - ez jó példa) valamint tipikus dolgkat sokkal önnyedébben lehetne megtenni. Komplex kereés, egyszerű telepités, stb. Mindenre, nem csak komponensre, driverre, faq-ra, stb. Szóval szerintem elsősorban nem a tudás-hiány a gond, hanem a könnyed szközök hiánya és emiatt az info-elérés bénasága a gond. És hát ezzel eljutottam a saját vágyprojektemhez...
Ha a Zinger ehgy sokkal jobb objektumtárban kereshetne, legalább a meglévő infot (pld. metóduslista mellett közvetlenül a helpből a megfelelő cikkely / a paraméterekre mutatva nem az jönne be hogy "Integer", hanem megint több info a helpből) és nem szivna olyan sokat a telepitéssel, a megvan-e-nekem, összeakad-e, stb. problémákkal, már akkor is sokkal elégedettebb lenne. Én is...
A Fórum-Tudomány-filozófikus programozás/minden adatbázis témakörben a 67.hozzászólás környékén AndrisK is eljutott addig, hogy egy objektumnak elég a SET() és GET() metódus, és ezzel "minden" lekezelhető.
Én ezt egészíteném ki - a még ismeretlen nevű - "ön help"-el. (Meg még azzal, ami feltétlenül fontos lehet.) De mondhattam volna úgy is, hogy elég csak az "ön help", mert ő meg tudja mondani, hogy milyen további metódusok és változók konstansok meg mifenék érhetőek el kintről. Így meg tudja adni a Set(), a Get() létezéseit is.
A hogyan tegye ezt? : kérdésre megfelelő megoldás lehet az XML. (de az is lehet, hogy nem kell ilyen messzire elmenni)
A mit kell hirdetni? : kérdésre várom a további javaslatokat. Esetleg elkezdhetjük megbeszélni azt, hogy mire szeretném használni. Vagyis a következő lépésből (céljainak megfelelően) próbáljuk meg definiálni ezt a szintet.
Nálam irányadó szempont az un: dinamikus metódusú objektumok kezelhetőségének elérése. Az amikor egy objektum látható felülete nem állandó, hanem változó és ezáltal metódusok és konstansok jelenhetnek meg illetve tünetnek el. Ennek a témának a rövidre zárásához egy sorszámmal szeretném azonosíttatni a felületet és innentől minden mehet tovább.
(Az lehet hogy ez most túl nagy ugrás, de: ) Annyi azonban látszik - a "mit kell hirdetni"-ből -, hogy - bármit is mondok - azt valamihez kötni kell. Ezt a láncot továbbfolytatva eljutunk az axiómákhoz. Tehát én a be épüléskori információcserét egy axióma verziószám és felület állapotszám lekéréssel kezdeném.
Utána a típusok leírásait is melyek az axiómákból építkeznének. Mivel a típusok nincsenek nagyon messze az alap axiómáktól ezért is tehetem meg a fenti kijelentést. Bár az eddig ismert (használt) típusok is lehetnek axiómák (nekem mind1). Ami fontos az az, hogy az axiómakörnek mindenféleképpen nyitottnak kel lennie a bővíthetőségre.
Utána a gyakorlatban már elterjedt, - eddig is megjelenő - adatokat hirdetném (propagálnám) továbbra is.
-Ezeket az alap meghatározásokat fel kéne építeni, hogy a módszert megtanulva tovább lehessen lépni a bonyolultabb fogalmak felé. . . . csíszta XML, csak nem ugyan arról a bázispontról.-
Legvégül pedig a folyamatokról a használhatóságról adnék valamit.
A tartalom még nagyon nyitott kérdés. Egy kis segédlet hozzá.
Az idő definíciója témakörből. . A 7. Hozzászólásából: "Boltzmann szerint egyébként a fizikai akármik definícióját tökéletesen helyettesíti mérésük megadásának mikéntje. " Egy kicsit igazítva rajta én azt mondanám, hogy nem fontos mindent definiálnunk, elég lehet az is ha meg tudjuk mondani a pontos használatát.
E "tervezgetés" során igazolást szeretnék kapni arra, hogy egy-egy fogalom definíciója nem más, mint a kapcsolatrendszere (Vagyis az, ami megmondja azt, hogy milyen a viszonya egy másik fogalomhoz 6és fordítva). Itt egy kicsit el kellene gondolkodni azon, hogy mikor mondjuk valamire azt, hogy: értem.
Egy kis kitérő: Az axiómarendszer adhat lehetőséget arra, hogy az ASIMOV féle robotok alaptörvényi mindig szem előtt legyenek. (HW-be égetném! Reakciókat az AI-s topicba?)
Axiómáknak titulálom
:érték: igen, nem, hely, cím, adat, bármi, üres, bit0, bit1, azonosító, lista, szeparátor, érték, típus, objektum
:művelet: NOT, egy, művelet, eleme, címzés, cél(ja), mindig, soha, állandóság, változás, előtte, utána, értéke, tud(képes), lehet, van, be, ki, ismétlés
:kapcsolat (2 érték közt egy művelet, avagy N3, mint az XML-nél) :
igen-not-nem, not-egy-művelet, eleme-egy-művelet, címzés egy művelet, eleme-not-egy, igen-egy-adat, nem-egy-adat, hely-egy-adat, igen-not-nem, stb…
:használat: Nos ez még kérdéses. Önállóan legyenek felsorolva, vagy az állításokkal (kapcsolatokkal) egyszerre 4. "Paraméterként"?
Szükség lesz az következő fogalmakra is, melyekkel nem tudok mit kezdeni: mutatás, futás, átminősítés, ismétlődés, értékrend, igazságtábla, cselekvés.
Fura dolgok:
Az állításokban minden egyes kötés: művelet, a végpontok pedig adatok? Minden Művelet (programot és ezáltal ) futtatható kódot is takar?
Kapcsolat rendszer + folyamatleírások. Ez most program vagy nem program?
Szeretném ismertetni, hogy én üzenettovábbításos "tüzelésű" objektumokban gondolkodom és a régi folyamatelvnek megfelelően INP-MŰV-OUTP sémának megfelelően. Valamint homályos az egymásba ágyazás és láncolás problémaköre.
. . . hopp. Itt már szétestem. Elfogyott a rend. Most már csak kirakós darabkáim vannak, no meg ráérzések. Kérlek benneteket segítsetek.
Annyi még látszik, hogy: Az ontológiai definíciók (az adatok és a műveletek) később elhagyhatóak, amennyiben kellően teljessé tud válni a szemantikai leíráshalmaz (állítások halmaza=relációk halmaza)
Továbbá az, hogy a szemantikai hálón haladva (mint programon) ami megmondja azt, hogy milyen adatunk legyen és mit csináljunk vele, ezáltal objektumok építhetőek fel, amik alkalmasak lesznek AndrisK SQL szerű lekérdezéseire. Jéé ez . . . csísztára olyan mint a DNS. Az állításban szereplő műveletek a fehérjék (nanorobotok) és egymás után alkalmazva őket előállítanak valamit (RNS-t).
Kiegészítés a robotos példámhoz: Az n3-ban szerepelhet olyan sor, hogy "te-képes_vagy-mozogni". Ez jelentheti azt, hogy használhatja a céljainak elérésére, és az új eszköz mozgatja őt. Bár ez utóbbi mondatot is "át" lehet neki adni. (XYZ_eszköz-mozgat-téged.)
A fentieket egy kicsit végiggondolva belátható, hogy teljesen mindegy, hogy Előre(),Hátra(),Balra(),Jobbra() metódusokon keresztül lehet vezérelni, vagy a SetSebesség() és SetIrány() pozitív és negatív értékeivel, mert a leírások (relációik felsorolása) során kapcsolatba kerülnek a 3Dhely-el, és a mozgás fogalmakkal.
Kedves despil_hun !
Úgy fest, hogy ilyen irányba hald(ok)unk. Vigasztalásként: a megoldási mintákat lehet, hogy nekünk kell majd megadni neki. Én még nem láttam be azt, hogy kreatív lesz.
Kedves NevemTeve !
"Manual-lapok": . . . igen, az embereknek. Most viszont valami mást, egy kicsivel többet szeretnék. Az értelmezéshez és dokumentáláshoz szánt tartalmakat teljesen másféle formátumban.
Nézzük a robotos példámat: "- előre interfész van / nincs:" Van is meg nincs is. Nem probléma mert, a leírás maga a pre-interface, csak még nincs leprogramozva. Ezt fogja megtenni a Mi, és így fog előállni a driver, ami már megfelelően fogja kezelni az elektronikát vagy akármi más objektumot.
Előny: (feltételezett) kevesebb belső hibával, tevékenységre optimalizált programot írhat magának a MI. Ha pedig új tulajdonság vagy kellő tapasztalat jelentkezik, akkor képes legyen újraszerkeszteni és befordítani a megfelelő objektumokat egyéb programokat. Ezért (is) kell a változtatható felület (lásd következő hozzászólásom), hogy az egyik vezérlő (számoló) egységről elvehesse a feladatot és egy gyorsabban működőre rakhassa át.
Amikor az interfész meghirdeti az ismeretanyagát és átjuttatja a fogadó objektumnak (a MI-nek, a "CsakIsLogikusan" alkalmazásnak) akkor, ezzel úgymond megtanítja arra, hogy milye is van. Meg a 'hogyan kell használni'-t is kéne ismertetnie, de ez még ködös (várj a következő hozzászólásra). Az alábbi gondolatsor azért járható.
Továbbá feltételezzük a "felcsatoláskori" helyes működést, és a próba/teszt körök alatt paraméter ellenőrzés és nívószint beállítás történik, később ennek eltérősége (laposabb vagyok, nagyobb az áramfelvétel) adja meg az okot az egyéb (miért van ez?) hibakeresésre, majd az orvoslásra: beavatkozás kerék felfújása.
OFF (Tkp kefele ember van: az egyik a nagy altalanossagokon szeret elmelkedni, es kitalalja a szep dolgokat, a masik meg mindig a franya konkretumok utan erdeklodik es ezzel szetk@rja a jo oteleteket :)
