Új hozzászólás Aktív témák
-
Ribi
nagyúr
Ezt a részt nem értem: "algoritmusokkal, definíciókkal bizonyíthatóan működő tervet készíteni"
Meg kellene tanulni valamit, de mire megtanulod már elavult, de úgy hogy még nem tanult meg semmit, tervezzen meg valamit. Erre jó a tapasztalat. Vagy akkor ennek hogy kellene működnie? -
cucka
addikt
Olyan embereket akik képesek egy adott szakterületen algoritmusokkal, definíciókkal bizonyíthatóan működő tervet készíteni egy adott feladat megoldására. Ez a bizonyíthatóság ma teljesen hiányzik az IT "tervezés" 99,99999%-ából.
Ebből az jön le, hogy van egy elképzelésed a szoftveriparról, aminek köze nincs a valósághoz.
A szoftverek nagy része tágabb értelemben véve üzleti szoftver. Üzleti igényeket kell kielégíteni. Ha az elképzelésed alapján készülne a szoftver, akkor
1. A szoftver fejlesztési költségeihez beírhatnál egy 5x-ös szorzót. Nem fizetné ki senki, mert nem hoz annyit a konyhára, mint amennyibe kerül.
2. Az üzleti igények folyamatosan változnak, tehát a specifikációd is folyamatosan változna, a szoftver karbantartása szintén 5x annyiba kerülne
3. Ez a legfontosabb: semmi sem garantálná, hogy az általad leírt matematikai specifikáció valóban megoldja a megrendelő problémáját és kielégíti az üzleti igényekeit. A megrendelő szempontjából az egésznek nincs semmilyen haszna.Persze, vannak területek, ahol ez nem érvényes, pl. űrhajók vagy atomerőművek vezérlő szoftverét le kell specifikálni. De az átlag üzleti szoftvernél, ami a szoftveripar 98%-a, egyszerűen haszontalan.
-
bambano
titán
egyrészt az it gyors változása valóban probléma, be kellene húzni a kéziféket, és egy hosszabb időszakban újabb funkciók bevezetése nélkül ki kellene takarítani a hibákat. de debuggolni senki nem szeret, így inkább újabb dolgok kódolásával verik el az idejüket.
másrészt az it azért több részből és rétegből is áll. először ki kell találnod az algoritmust, valamilyen pszeudonyelven megfogalmazni, bizonyítani, majd utána valamilyen aktuális környezetben lekódolni. ebből az algoritmuselmélet rész egyáltalán nem változik olyan gyorsan, sőt, leginkább semennyire se. ennek a bizonyítása lenne a tudományos része az it fejlesztésnek. utána következik a favágó része, amikor kódgenerátorral meg kézzel favágó módjára krampácsolod befelé a metódusokat. ez gyorsan változik, de nem is erre készít fel az egyetem.
"Az egyetem feladata szerintem az lenne, hogy mérnököket képezzen.": melyik egyetem? mert a bme az pl. klasszikusan olyan egyetem, ami mérnököket képez. az elte meg nem. a mérnökök fölött is van még egy szint: az elte programtervező matematikusa.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
cucka
addikt
Garanciát szokás vállalni, aminek keretében kijavítottátok azokat a hibákat, amiket a megrendelő észrevett, és amelyek a szerződés szerint is hibának tekinthetőek. Itt eddig matematikai helyesség-bizonyításokról volt szó, ez nagyon távol áll attól. Plusz garantált, hogy a garanciális hibák mellett volt még százszor annyi hiba és hibásan működő edge case, amit az ügyfél nem vett észre, vagy nem terjedt ki rá a szerződés, és ezért ott van most is benne a kódban.
Worfklow diagramokat, meg egyebeket is szokás készíteni, ha ezt pszeudokódnak tekinted, akkor igen, van pszeudokód.
Amire ott utaltam, az a feltételezés, hogy bárki bárhol fejlesztés előtt kitalálná az algoritmust és leírná pszeudokódban. Ez nem szokott megtörténni, az említett diagramok ennél sokkal magasabb szintű absztrakciót képviselnek.[ Szerkesztve ]
Új hozzászólás Aktív témák
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Promenade Publishing House Kft.
Város: Budapest