» »

25 najnevarnejših programerskih napak

25 najnevarnejših programerskih napak

SANS - Več kot 30 strokovnjakov iz celotnega sveta je sestavilo seznam 25 najnevarnejših napak, ki jih zagrešijo programerji. Napake so bile ocenjene po splošni nevarnosti za razkritje podatkov v informacijskih sistemih in omogočanju računalniškega kriminala. Največje "odkritje" pa je bilo, da se v večini izobraževalnih programov za bodoče računalniške strokovnjake o teh napakah ne uči praktično ničesar, za njihovo prisotnost pa se pri veliko proizvajalcih programske opreme tudi ne testira.

Kako nevarne pa so te napake, pa pokaže že podatek, da sta bili samo dve izmed teh napak v letu 2008 vzrok za najmanj 1,5 milijona vdorov v spletne strani. Ti vdori pa so se izrabili za zlorabo obiskovalecev, ki so zaradi pomankljive zaščite lastnih računalnikov, postali žrtve zlorabe, njihovi računalniki pa zombiji na razpolago kriminalcem.

Kakšne so pa izkušnje z izobraževanejm pri nas? Ali se o kateri izmed teh napak kdo pogovarja v šoli? V kateri šoli? Zakaj da, zakaj ne?

133 komentarjev

strani: « 1 2 3

strictom ::

Ja normalno saj je testiranje za napake velik strošek. Beta testov pa tudi ne moreš imeti z vsako programsko opremo.
"Violence is the last refuge of the incompetent" - Salvor Hardin

BlueRunner ::

Kaj pa, če lahko večino teh napak polovimo z avtomatiziranimi unit testi? Nekatere napake pa so tudi bližnjice, ki jih programerji delajo/delamo med razvojem. Ali se da normalno delati tudi brez takšnih bližnjic?

srok ::

Mi se o tem prav nič ne učimo...no za zdaj ne (morda pa se še bomo):)

LP

Rok

pegasus ::

BlueRunner: za unit teste moraš najprej vedeti, kakšno napako iščeš. Iz tega sledi, da unit testi niso pravo orodje za izdelavo bugfree programa.
Pravo orodje je izobraževanje programerjev ter fomalno preverljivo programiranje (glej tudi: sparkada).

nekikr ::

Ne, ne učimo se in se niti ne bomo. Kot študent zadnjega letnika na FRIju nisem nikoli slišal nič o kakšni taki zadevi na samem faxu. Sem pa poslušal mnogo stvari, ki jih že cca. 15 let ni nikjer več za videti...razen v zapiskih profesorja, iz katerih se učiš in so stari cca. 15 let... Porazno.

AlexP ::

Kaj pa, če lahko večino teh napak polovimo z avtomatiziranimi unit testi? Nekatere napake pa so tudi bližnjice, ki jih programerji delajo/delamo med razvojem. Ali se da normalno delati tudi brez takšnih bližnjic?



Predavanje za vse tiste, ki ste mislili, da boste z unit testi avtomagično popucali vse buge:
http://www.infoq.com/presentations/fran...

Ne moreš naresti testa, če ne veš kaj točno testirati.

Zgodovina sprememb…

  • spremenil: AlexP ()

BlueRunner ::

OK, unit testi so nezadostni. Formalno pravilno programiranje (naj Spark ADA dodam še Eiffel) pa večini ljudi sploh ni znano. Vprašanje pa je, če bi polovilo npr. SQL injection napake zaradi nepravilne validacije vhoda.

Če se bi to učilo, ali bi to moral biti del kakšnega obstoječega predmeta, ali čisto ločen predmet?

misek ::

Dva programa, s katerimi je možno poloviti kar nekaj napak: Codenomicon DEFENSICS in Klocwork. Nista pa zastonj.

cryptozaver ::

Razvijalci bi morali prevzet odgovornost za posledice zlorab, ki nastanaejo zaradi napak njihovih programerjev. Potem bi več časa porabili za testiranje in izobraževali kader tam kjer to počnejo kot je traba.

Pa bi vsi mirjene spali...

WarpedOne ::

Razvijalci bi morali prevzet odgovornost za posledice zlorab,

Komot, pod pogojem da imam 100x višjo plačo.

Komot je zahtevat bugfree softver, čisto nekaj drugega ga je pa sproducirat.
In tudi Eiffel ni panacea. Pač ti zagotavlja da z neko dograditvijo ne boš podrl kakšne stare zahteve, ne bo pa odkril buga ki izhaja že iz analize al pa zahtev. Tudi to obstaja.

Potem bi več časa porabili za testiranje in izobraževali kader tam kjer to počnejo kot je traba.

Aha, in tole bi bil garant da napak ne bo?

Programiranje je umetnost. Programiranje brez očitnih napak double so.
How do you know what you don't know?

cryptozaver ::

Napake se v življenskem ciklu SW odkrivajo, temu sledijo popravki. Zakaj proizvajalci prodajo izdelek preden dela kot je treba?

Očitno zato, ker se to da. Razumem, da je proces testiranja drag in dolgotrajen. Ampak ko kupiš recimo TV pričakuješ da bo delal in ne da bo treba non-stop nekaj servisirat. Banalen primer, vem da je sw ponavadi dost bolj kompleksen. Ampak uporabniki prevečkrat prevzamejo vlogo testiranja nekega sw. In to brezplačno.

Zvito ni kaj...

jlpktnst ::

Ne, ne učimo se in se niti ne bomo. Kot študent zadnjega letnika na FRIju nisem nikoli slišal nič o kakšni taki zadevi na samem faxu. Sem pa poslušal mnogo stvari, ki jih že cca. 15 let ni nikjer več za videti...razen v zapiskih profesorja, iz katerih se učiš in so stari cca. 15 let... Porazno.


FRI ni faks, FRI je joke. Že itak je stanje v slovenskem visokem šolstvu ogabno, FRI je pa eden najbolj poraznih faksov pri nas. Malo mi je žal, da nisem šel na FERI (čeprav ima tudi ta svoje cvetke), pa se mi zdi vseeno boljši.

BlueRunner ::

Kaj pa FERI naredi boljši od FRI? Oziroma kaj naredi FRI slabši od FERI?

Binji ::

cryptozaver: ti dejansko mislis, da je TV sigurno brez vseh softverskih/hardverskih bugov? Malo morgen... ce ti deluje, to se sploh ne pomeni, da se nekaj ne zalomi, ko recimo nastavljas kanal, zraven pa pritisnes kontrolo glasnosti in takoj zatem se izhod iz menuja ali v kaksni podobno obskurni situaciji.
Ogromno bugov je takih, da razvijalci in testerji ne vedo zanje in se pokazejo sele ko ima softver recimo par sto ali par tisoc uporabnikov, kjer se res preizkusijo vse mogoce kombinacije vhodov.
Kdor ne navija ni Slovenc, hej, hej, hej!

Zgodovina sprememb…

  • spremenil: Binji ()

WarpedOne ::

Zakaj proizvajalci prodajo izdelek preden dela kot je treba?

Nekateri bugi se odkrijo šele po 5ih letih vsakodnevne uporabe. Tak sofver dela kot je treba ali ne?
"Dela kot je treba" je dobro definiran koncept izključno in samo na prvi pogled. Obstajajo stvari, ki se jim reče scenariji uporabe. Njihovo možno število s kompleksnostjo zadeve izjemno hitro narašča. Dodaj še različne možne nabore podatkov in zelo hitro prideš do tega, da enostavno nimaš fizičnih možnosti stvari stestirat niti tako dobro kot bi si želel. Zato jo stestiraš le tako dobro kot si lahko privoščiš in odpraviš tiste buge, ki so najdražji. Kupec namreč nima denarja, da bi si lahko privoščil softver, ki je 100% brez napak.

Ampak ko kupiš recimo TV pričakuješ da bo delal in ne da bo treba non-stop nekaj servisirat.

100% da to pričakuješ, enako kot to pričakuješ od novega avtomobila in zelenjave, ki jo kupiš na tržnici.
Ampak v nobenem primeru stvari niso brez napak. Obstaja meja, ko postanejo morebitne preostale napake cenejše od njihovega iskanja, odpravljanja in preverjanja.
How do you know what you don't know?

BigWhale ::

Kaj pa, če lahko večino teh napak polovimo z avtomatiziranimi unit testi? Nekatere napake pa so tudi bližnjice, ki jih programerji delajo/delamo med razvojem. Ali se da normalno delati tudi brez takšnih bližnjic?


Unit testi se uporabljajo ya regression testing. Unit test vsebuje nekaj vnaprej dolocenih testiranj. S tem poskrbis, da ob spremembi na mestu X v programu ne crkne nekaj na mestu Y. Oziroma, ce crkne, potem to ulovi unit test.

dottie ::

Tut na FERI nismo slišali veliko o teh napakah. Mogoče te kje kakšen asistent opozori, da naredi rajši stored proceduro, kot pa pisat sql stavke v kodo. Se nekaj že pove o teh napakah, kako jih pa odpravit, pa vsaj v večini ne.

BigWhale ::

Mogoče te kje kakšen asistent opozori, da naredi rajši stored proceduro, kot pa pisat sql stavke v kodo. Se nekaj že pove o teh napakah, kako jih pa odpravit, pa vsaj v večini ne.


?!!? A to pol prodaja kot 'good practice'???

darkolord ::

Stored procedure so kul :)
spamtrap@hokej.si
spamtrap@gettymobile.si

vasquez ::

Programiranje je umetnost.


Hehe. Ob tem stavku se vedno spomnim na bivšega direktorja HSL-ja. Je zbral naš oddelek v tisti veliki dvorani in se potem drl na nas, da programiranje ni umetnost ampak štancanje. Saj smo bili res razpuščeni ampak problem ni bil v filozofiji programiranja.

WarpedOne ::

se potem drl na nas, da programiranje ni umetnost ampak štancanje

Tole bi pravzaprav moralo bit na prvem mestu med najnevarnejšimi programerskimi napakami.
Napačna organizacija dela, idioti za šefe ...
How do you know what you don't know?

Matthai ::

Razvijalci bi morali prevzet odgovornost za posledice zlorab,

Komot, pod pogojem da imam 100x višjo plačo.


Niti ne.

Država recimo regulira elektriko (tok mora teči v nekih mejah), vodo (biti mora čista) in ostale stvari. Pa nimata električar in vodovodar blazno velike plače.

IT je pa popolnoma nereguliran...
All those moments will be lost in time, like tears in rain...
Time to die.

Utk ::

Programiranje ni umetnost. Zmeraj pa ni niti štancanje. Ampak, če je vse poštimano tako kot mora bit, potem je štancanje.
Električar in vodovodar imata bolj malo stem kaj teče po ceveh. Inženirji, ki spravijo skupaj avto, so tudi čisto brez regulacije. Avto zabijejo v steno, če se ne totalno razpade, ga lahko prodajajo. Kako zanesljiv in varen je drugač, je čist nepomembno. Program se tudi malo stestira, če pride čez, pride čez. Brez napake sigurno ni noben.

darkolord ::

Država recimo regulira elektriko (tok mora teči v nekih mejah), vodo (biti mora čista) in ostale stvari. Pa nimata električar in vodovodar blazno velike plače.

Ampak to je drugo. Elektro in vodovodno podjetje ničesar ne "proizvajata" (proizvajata v smislu kot produkt IT podjetja (ali kakšnega industrijskega proizvajalca)).
spamtrap@hokej.si
spamtrap@gettymobile.si

BlueRunner ::

Kaj pa če rečemo, da so napake, ki jih je težko ali nemogoče predvideti, in so napake, ki so trivialne za odkriti in se pred njimi zavarovati. Ene se sprejmejo kot nekaj s čemer je potrebno (pre)živeti, druge pa so razlog, da se npr. zahteva odškodnino, ali pa se proizvajalca kaznuje.

Potem pa imamo vprašanje odprtokodnih in brezplačnih (freeware) aplikacij. Te bi s tovrstno zakonodajo dejansko izginile.

Po drugi strani pa bi tu definitivno dvignilo raven kvalitete aplikacij.

Ali pa popolnoma ustavilo razvoj.

Ali pa razvoj usmerilo v inžinerstvo, za razliko od današnje "umetnosti".

Utk ::

Vseeno je kakšne so napake. Program mora delat. Lahko dela malo slabše ali boljše, ampak glavno da dela, zmeraj pa lahko crkne. Programe, ki res ne smejo crknit, se dela na drugačen način, in za drugačno ceno. Če bi hoteli en Office naredit na način, kot delajo programe, ki vozijo letala po zraku, bi to stalo res ogromno. Če hoče nekdo takšno zanesljivost, naj samo pove, jo bo dobil, ampak tudi mastno plačal.
Siol ti tudi ne garantira 100% uptime. Niti če si bolnica, zračna kontrola in ne vem kaj. Lahko pa najemaš nekoga, ki to bo zrihtal praktično 100% povezavo. Samo ne boš več plačeval 18 evrov na mesec.

Zgodovina sprememb…

  • spremenil: Utk ()

WarpedOne ::

Če hoče nekdo takšno zanesljivost, naj samo pove, jo bo dobil, ampak tudi mastno plačal.

A nisi prebral Mathaija? One noče plačat, on bi zanesljivost enostavno uzakonil. Izi.

Ampak pod njegovo komando bi tut v sahari precej hitro peska zmanjkalo.
How do you know what you don't know?

jype ::

WarpedOne> Ampak pod njegovo komando bi tut v sahari precej hitro peska zmanjkalo.

Matthaija za predsednika!

Invictus ::

Zgleda da vsi, ki tukaj filozofirajo, še niso napisali kakega kompleksnega softvera, če sploh kakšnega.

Teoretizirati je lahko, preživeti kot softverski razvijalec pa malo težje. V končni fazi vsi delamo za keš. Če bi nam država dala pavšal plačo 1500 EUR, potem bi mogoče tudi kak bug-free softver prišel ven.

Tako je pa treba prehiteti konkurenco in zaslužiti.

Še zmeraj ni bilo odgovora v čem je FRI slabši od FERI. Mogoče v preveliki zahtevnosti za nekatere ?!?!.

LP I.

Matthai ::

Če hoče nekdo takšno zanesljivost, naj samo pove, jo bo dobil, ampak tudi mastno plačal.

A nisi prebral Mathaija? One noče plačat, on bi zanesljivost enostavno uzakonil. Izi.

Ampak pod njegovo komando bi tut v sahari precej hitro peska zmanjkalo.


Ne bluzit.

Pravim, da je večina stvari reguliranih z vsaj minimalnimi standardi.

Ja, avtomobili so tudi regulirani, vsaj nek osnovni testing mora dati skozi.

Edino pri IT lahko vsakdo prodaja kar hoče in v EULO zapiše, da se izogiba vsakršni odgovornosti.

In BTW, tole ni samo moja ideja, pač pa tako pravijo tudi pri Microsoftu - poznam enega tipa pri Microsoft research in ima še bolj radikalna stališča od mene.
All those moments will be lost in time, like tears in rain...
Time to die.

nekikr ::

Stanje slovenskih faxov je porazno. Vpisal sem se na FRI, ki naj bi bil malo nad standardom, a ko sem odšel za eno leto študirat v tujino (Švedska) sem videl, da je naš celotni šolski sistem nekje na ravni Albanije. Tako ni čudno, da tudi uni. dipl. ing. rač. in inf. (kako lep in dogl naslov ane) nimajo pojma o stvari, ki naj bi se jo učili, ker jih profesorji učijo stvari, katere so se učili sami (pred 15imi leti seveda). So izjeme, seveda, a če potegnem črto se na FRI ne bi ponovno vpisal, saj razen diplome, ne dobiš od njega nič (pa imam lepo povprečno oceno).

cryptozaver ::

Programiranje je umetnost.


Hehe. Ob tem stavku se vedno spomnim na bivšega direktorja HSL-ja. Je zbral naš oddelek v tisti veliki dvorani in se potem drl na nas, da programiranje ni umetnost ampak štancanje. Saj smo bili res razpuščeni ampak problem ni bil v filozofiji programiranja.


Je in ni. S stališča programerja ki uživa v tem verjetno res, pa tudi za koga ki to delo opazuje od daleč z nekim strahospoštovanjem. Tudi jaz osebno spoštujem programerje, sploh tiste ki zadeve obvladajo dosti bolje od mene :-;

Po drugi strani pa je treba bit user oriented, saj se programira za userje in ne le za svoje veselje (kadar gre za denar). Tu se pa da še veliko narest. In hroščavost je samo ena izmed stvari.

O tem govorim.

Matevžk ::

se na FRI ne bi ponovno vpisal, saj razen diplome, ne dobiš od njega nič

Daj se zresni. Večina študentov FRI-ja pred študijem na fakulteti ni vedela praktično nič o podatkovnih strukturah, algoritmih, časovni zahtevnosti, operacijskih sistemih, podatkovnih bazah, arhitekturi računalniških sistemov (tudi sodobnih), umetni inteligenci in data miningu, delovanju telekomunikacijskih omrežij in protokolov, ....

Jaz sem na fakulteto prišel z nadpovprečnim predznanjem, pa sem od nje veliko odnesel. Najbrž se pa da priti skozi tudi z blefiranjem in brezdeljem, ja. Potem pa nič ne odneseš.
lp, Matevžk

BlueRunner ::

Tudi to je verjetno del problema. Skozi večino naših fakultet se da priti tudi z blefiranjem in brezdeljem. Odkar imamo zasebne, pa tudi z dovolj visokim plačilom. Mislim, da FRI tukaj ne izstopa.

Pričakujem pa (iluzorno), da se bi na FRI-ju učilo najmanj o vzrokih in posledicah teh in drugih programerskih napak, ter načinih za omejevanje njihove potencialne škode. Na FERI pa bi pričakoval, da se konkretno izkoreninja in opozarja na tovrstne napake, ki jih študentje delajo med svojim programiranjem.

Tako čez palec, glede na to, da se FRI bolj posveča teoriji računalništva in informatike, FERI pa bolj programerskim znanjem.

Me pa je vedno zanimalo kako si nekdo predstavlja regulacijo. Konec koncev imamo tudi ISO standarde, ki posegajo v način dela (npr. ISO 9001) in ocenjevanje kvalitete opravljenega dela (npr ISO 14598), pa imajo tudi aplikacije, ki so narejene v takšnem okolju še vedno težave s svojo zanesljivostjo in pravilnostjo delovanja.

squngy ::

Programiranje ni umetnost. Zmeraj pa ni niti štancanje. Ampak, če je vse poštimano tako kot mora bit, potem je štancanje.
Električar in vodovodar imata bolj malo stem kaj teče po ceveh. Inženirji, ki spravijo skupaj avto, so tudi čisto brez regulacije. Avto zabijejo v steno, če se ne totalno razpade, ga lahko prodajajo. Kako zanesljiv in varen je drugač, je čist nepomembno. Program se tudi malo stestira, če pride čez, pride čez. Brez napake sigurno ni noben.


Lažeš moj "Hell oWrold" program je brez kakeršne koli napake in noben user mi ga nebo spravil da počne karkoli drugega kot čemur je namenjen!

:P

rockstar1707 ::

Ko je že govora o regulaciji itd. Računalništvo, še posebej programska oprema, je v resnici precej neregulirano in nestandardizirano. Ko so že tako popularne primerjave z avtomobilsko industrijo, ki pa v večini primerov je precej standardizirana. Ko kupiš nov avto veš, da:

    * ga boš lahko vozil po praktično vsaki cesti (brezpotja so druga pesem)
    * ga boš napolnil z bencinom na vsaki črpalki
    * da boš nadomestne žarnice lahko kupil praktično skoraj na vsaki bencinski postaji, in da boš ISTI tip različnih proizvajalcev lahko vedno uporabil
    * pa še kaj bi se našlo.


Kako pa gre to pri programski opremi:

    * ISTI program NE deluje na različnih OS
    * primerljivi programi različnih proizvajalcev ne odpirajo enako ali sploh ne podpirajo STANDARDNIH dokumentov
    * in še dosti drugih stvari.


Skratka, programska oprema je v večji meri NEREGULIRANA in NESTANDARDIZIRANA. V večji meri zato, ker ima MS največji tržni delež, delajo pa večinoma mimo standardov oz. si postavljajo svoje. In s tega vidika, ki je za uporabnika daleč najpomembnejši, je večina odprtokodnih programov DALEČ pred zaprtimi MS produkti. Ko bodo te zadeve enkrat urejene, boš lahko primerljive dokumente enostavno prenašal med različnimi programi (brez izgube kvalitete), praktično isti programi bodo delovali na različnih OS ("multiplatforme" kot so QT, GTK, wxWidgets, FLTK itd so že precej v tej smeri) itd. Predstavljajte si, da si WV omisli svoj način polnjenja goriva, svoje žarnice, večje širine avtomobilov itd....

Nedopustno od javne uprave pa je, da imajo na spletnih straneh obrazce v DOC formatu, za katerega potrebuješ plačljiv program, ki si ga marsikdo uradno ne more privoščiti. In to kljub temu, da obstajajo dosti boljše in zastonj (vsaj za končnega uporabnika) rešitve, kot sta npr. PDF ali ODF. Vem, da načeloma obstaja pregledovalnik DOC datotek, ampak pri najboljši volji zraven teh dokumentov niti enkrat še nisem videl povezave do njega. Nasprotno je pri PDF dokumentih dostikrat še povezava vsaj do Adobe Readerja.

WarpedOne ::

Matthai:
Edino pri IT lahko vsakdo prodaja kar hoče in v EULO zapiše, da se izogiba vsakršni odgovornosti.

Seveda, edino pravilno.
Država mi bo določala kak softver lahk js napišem za lastno potrebo? In ali ga lahko prodam tudi sosedovi micki?
Če bi bil ti predsednik, verjamem da ja. Bi pa hitro moral imet vojsko na meji, da ti komplet populacija ne pobegne.

In BTW, tole ni samo moja ideja, pač pa tako pravijo tudi pri Microsoftu - poznam enega tipa pri Microsoft research in ima še bolj radikalna stališča od mene.


Verjamem da tako pravijo pri MS. Kar je najboljša referenca da je to zanič ideja.
Oni bi namreč 100% imeli veliko besede pri tem kakšni naj bi bili ti standardi. Seveda bi oblikovali takšne, da bi jim oni kar se da ustrezali, konkurenca pa kar se da ne.

Temu se enostavno reče omejevanje konkurence.

Podn :|
How do you know what you don't know?

BlueRunner ::

Analogije z avtomobili in še čem mi niso všeč. Avtomobili so avtomobili, programi so programi. Tukaj ni možno vleči nikakršnih primerjav. Če bi hotel bi lahko rekel, da so programi ql, ker lahko isti program poženem na procesorjih od P4 do i7, pa še AMD-jevih, v bencinarja pa ne morem natočiti kurilnega olja. Skratka metafora je čisto mimo in neuporabna.


Sedaj me pa zanima kaj bo sploh vsebina regulacije. Če se program "Hello World" razsuje, potem je verjetno težava v OS-u ali strojni opremi. Če se Microsoft Word razsuje, pa je težava kje vse? Če je obstoj napake načeloma možno dokazati, kako naj se dokaže odsotnost napake?

Ali imamo teorijo, prakso ali vsaj idejo kako se lahko realno zagotovi vsaj formalna pravilnost delovanja enega izoliranega programa. Za most, ki bo služil javnem prometu, mi lahko statik izračuna, če je varen ali ne. Kdo in predvsem KAKO mi bo za FireFox izračunal, če je varen za uporabo ali ne?

MrStein ::

squngy:
Lažeš moj "Hell oWrold" program je brez kakeršne koli napake

Bom verjel, ko bom videl ;)

Glede kvalitete: Heh, eni zagovarjajo anarhijo. Zanimivo, kako potem trpijo RS in EU z vsemi regulacijami in se rajši ne preselijo v kaki uzbekistan.
Teštiram če delaž - umlaut dela: ä ?

Matthai ::

Matthai:
Edino pri IT lahko vsakdo prodaja kar hoče in v EULO zapiše, da se izogiba vsakršni odgovornosti.

Seveda, edino pravilno.
Država mi bo določala kak softver lahk js napišem za lastno potrebo? In ali ga lahko prodam tudi sosedovi micki?
Če bi bil ti predsednik, verjamem da ja. Bi pa hitro moral imet vojsko na meji, da ti komplet populacija ne pobegne


Brez skrbi, bežali bi samo nesposobni programerji, teh pa itak ne rabimo. :D

Analogija z avtom. Ti sicer lahko narediš lasten avto, vendar če ga hočeš prodajati, mora biti homologiziran, atestiran in kaj vem še vse.

O tem govorim.

Je pa seveda jasno, da bi razni garažni mojstri najraje videli, da izdelajo kakršenkoli avto, ga lepo prodajo, ko pa pride do problemov (nesreče, požara, odpovedi) pa se lepo potuhnejo. A-a fantje. Ne bo šlo.
All those moments will be lost in time, like tears in rain...
Time to die.

MrStein ::

BlueRunner:
Analogije z avtomobili in še čem mi niso všeč. Avtomobili so avtomobili, programi so programi. Tukaj ni možno vleči nikakršnih primerjav.

Seveda je možno:
- dal sem 20.000 € za Megana
- dal sem 200 € za MS Office

- uporabil sem ga, da sem se peljal do strica
- uporabil sem ga, da sem nekaj dokumentov prebral in napisal

- brisalec ne dela, so mi ga popravili v garanciji
- spelčekr ne dela, sem klical support, pa so se mi smejali. Pol sem pisal na forum, pa so mi rekli, da sem neumen, imam napačen hardver, ali pa kar oboje. Pa en je rekel "World Domination!"

Ah res. Ne da se primerjat.
Teštiram če delaž - umlaut dela: ä ?

WarpedOne ::

Ali imamo teorijo, prakso ali vsaj idejo kako se lahko realno zagotovi vsaj formalna pravilnost delovanja enega izoliranega programa.

Neki v tej smeri obstaja ampak je 100% neuporabno za karkoli izven akademskih voda.

Za most, ki bo služil javnem prometu, mi lahko statik izračuna, če je varen ali ne. Kdo in predvsem KAKO mi bo za FireFox izračunal, če je varen za uporabo ali ne?

Kako naj kdorkoli to izračuna, če ni zmožen niti definirat kaj "varen za uporabo" sploh res pomeni?
Vsak ma eno bledo idejo kaj to je, ampak avtomati ne laufajo na blede ideje. Tega pa se le redko kdo "izven industrije" zaveda.

Software se zato piše na podlagi v naprej danih zahtev. Če so te zahteve izpolnjene, je softver sprejemljiv. Ni brez vseh napak ampak sprejemljiv, ker opravlja svojo nalogo in je zato koristen.
How do you know what you don't know?

Zgodovina sprememb…

Liker ::

Se moram povsem strinjati z W1.

Morda se da avtomatsko poloviti preproste napake (sploh pri spletnih aplikacijah), a 100% testirat nekaj tako kompleksnega kot recimo kontrolni sistem velikega obrata z n-stroji in N*100k vrsticami kode je pa nemogoče. Lahko (in tudi se) stestira scenarije ki nam jih naročnik predstavi. Ostalo bi bil finančni samomor, saj bi porabili vsaj kakšen velikostni razred več časa za izdelavo, stranka pa že tako ni navdušena nad ceno...

Poleg tega, o kakšni 'varnosti' sploh govorimo?
O tem da program ne poje nekih podatkov?
Da mi zlobneži ne morejo ukrasti bančnih podatkov?
Da zadeva ne zažge kakšne fabrke?
Eh?
Vsak ki je sodeloval na projektu ki vsebuje 10+ ljudi, traja nekaj mesecev in rezultira v nekaj 10k-100k vrsticah kode bo vedel da je bug free utopija. Nekje na ravni ideje da je komunizem popoln sistem kjer vsi vse imajo...

Da recimo ne omenjamo CPU-jev, kjer so bugi stalnica. In jih prodajajo, nihče ne protestira, pa ti celo lahko povzročijo popoln data loss z 'veliko' sreče.
Kompleksen izdelek == loads of bugs. (velja tudi za avtomobile, letala, z eno besedo vse kar človek izdela)

P.S.: Še to, delam v firmi kjer imamo ISO certifikat (in ga vsako leto tudi obnovimo) in lahko povem da sedaj pač porabimo več kot 50% časa za načrtovanje in organizacijo, a na koncu se po kakšnem mesecu dveh vseeno najdejo bugi.

EDIT: veliko tipkarskih napak
www.firefoxmyths.com
Firefox - Buggier, Slower, Worse

Zgodovina sprememb…

  • spremenilo: Liker ()

BlueRunner ::

BlueRunner:
Analogije z avtomobili in še čem mi niso všeč. Avtomobili so avtomobili, programi so programi. Tukaj ni možno vleči nikakršnih primerjav.

Seveda je možno:

...

Ah res. Ne da se primerjat.

OK, ampak tukaj greva že daleč off-topic. Za programsko opremo mi dostavijo popravke na dom. Za avto moram iti z avtom na servis. Zamenjal sem operacijski sistem (Windows XP na Windows Vista), pa mi program še vedno dela. Na fičota ne morem pritrditi valjarjev iz BMW. Pri programski opremi dobim X, avtomobili pa vsega tega ne znajo/omogočajo/niso sposobni.

Definicija zelo slabe metafore je, da si lahko oba izmisliva poljubno veliko argumentov, ki potrjujeta najini lastni mnenji. Ker so vse najine izjave resnične, to lahko pomeni samo, da korelacija med njimi ni resnična (implikacija ne velja). Korelacija pa je točno tisto, kar naj bi predstavljalo "metaforo". Torej je moj sklep, da metafora ni ustrezna za ta namen.

Naprej o filizofiji metafor se pa pojdiva kregati v ZS. Tukaj je še več drugih on-topic vprašanj.

BlueRunner ::

Moja osebna definicia (za WarpedOne): recimo, da "varen za uporabo" pomeni, "dela natančno tisto, kar naj bi delal, nič več in nič manj". Napake, ki omogočajo zlorabo so "dela nekaj več", napake ki onemogočajo uporabo so "dela nekaj manj".


Morda se da avtomatsko poloviti preproste napake (sploh pri spletnih aplikacijah), a 100% testirat nekaj tako kompleksnega kot recimo kontrolni sistem velikega obrata z n-stroji in N*100k vrsticami kode je pa nemogoče.


Sploh ni potrebno iti v takšno komplekstnost, da bi demonstrirali pomankljivost obstoječih metod testiranja. Če se lahko naslonim na Dijkstro: Vsi vemo, da je iskanje napak že vnaprej obsojeno na neuspeh, vendar pa se teh pristopov še vedno učimo in to še vedno počnemo.

Dijkstrino mnenje je (bilo?), da se je potrebno problema lotiti iz druge strani. Ne iskati napak, temveč dokazovati odsotnost napak. Velika težava vseh tovrstnih teorij za dokazovanje pravilnost, kar jih osebno poznam, pa je njihova praktična neuporabnost. Vse odpovedo že pri FireFix-u (typo intended).


P.S.: Še to, delam v firmi kjer imamo ISO certifikat (in ga vsako leto tudi obnovimo) in lahko povem da sedaj pač porabimo več kot 50% časa za načrtovanje in organizacijo, a na koncu se po kakšnem mesecu dveh vseeno najdejo bugi.

Torej še vedno nekaj delamo/delate narobe. Če imate slučajno ISO 9001, pa moje sožalje. Okoli so že podjetja, ki so se mu odpovedala zato, da lahko zagotovijo višjo kvaliteto svojih produktov - z uporabo drugačne non-ISO metodologije zagotavljanja kakovosti.

Ziga Dolhar ::

Matthai,

Edino pri IT lahko vsakdo prodaja kar hoče in v EULO zapiše, da se izogiba vsakršni odgovornosti.


1. EULA je pogodba. Torej, velja načelo pogodbene avtonomije, v okviru kogentnih zakonskih določb.

2. V vsaki pogodbi se lahko uredi vprašanje odgovornosti.

3. Z nobeno pogodbo se ne more urediti vprašanja odgovornosti za naklep. Če pa se uredi, in je to v nasprotju s kogentno zakonsko ureditvijo, pa poznaš posledice [delne] ničnosti.

4. GPL, CreativeCommons et al ... so pogodbe.
Legal systems are not supposed to be efficient. They are
designed to ensure that innocent people are not found guilty.
If that requires inefficiencies, so be it.

BlueRunner ::

Običajna kritika je, da proizvajalci SW niso odgovorni za napake v svojih produktih, brez te odgovornosti pa ne vlagajo v višjo kvaliteto (manj napak). Licenčna pogodba je samo forma, ki opredeljuje ta odnos.

Seveda bi lahko država tudi regulirala ta odnos, vendar pa je vprašanje kako.

Matthai ::

Jup, ampak naklep je eno, malomarnost pa drugo.

Elektropodjetje odgovarja za malomarnost tudi, če po nesreči poveča napetost na 500V.
All those moments will be lost in time, like tears in rain...
Time to die.

WarpedOne ::

Moja osebna definicia (za WarpedOne): recimo, da "varen za uporabo" pomeni, "dela natančno tisto, kar naj bi delal, nič več in nič manj". Napake, ki omogočajo zlorabo so "dela nekaj več", napake ki onemogočajo uporabo so "dela nekaj manj".

Sej, temu se reče bleda definicija. Na hitro pogledano drži vodo ampak z njo si ne moreš ravno pomagat. Vsak kolikor toliko uporaben software ma ogromno možnih internih stanj in še več možnih vhodov. Ta "kar naj bi delal" pravzaprav pomeni njihov kartezični produkt. Njegov obseg je tako ogromen da si ga nihče ne more niti predstavljat, kaj šele dejansko specificirat oz. točno opredelit kaj naj bi nek softver točno delal.
Kako naj potem ta softver testiraš, če res dela to "kar naj bi delal"? Na tej točki odpade 100% pravilnost in z njo povezani ideali.

Ne pomeni pa to, da se ne da delat "dovolj dobrega" softwera. Kaj je "dovolj dobro" je pa odvisno od ciljnega uporabnika in standardov proizvajalca. Dosega se jo z "mehkimi" tehnikami: različne metode testiranja, specificiranja, izgradnje itd. Tudi objava takega seznama ala "Top 25 programming errors" je pravzaprav metoda izboljšave softvera. Veliko programerjev si bo stvar pogledalo in zato naredilo manj takšnih napak. Svojevrstna evolucija s katero nastaja vseboljši softver.

brez te odgovornosti pa ne vlagajo v višjo kvaliteto (manj napak). Licenčna pogodba je samo forma, ki opredeljuje ta odnos.

Tak očitek je precej faljen.
Kaj so Automatic updates drugega kot vložek v višjo kvaliteto? Kaj je eno leto beta testinga drugo kot vložek v višjo kvaliteto?
Žalostno dejstvo je pač da se vseh napak ne bo nikoli polovilo vnaprej, ampak to ne pomeni da se napak ne lovi in da se izdaja pre-alfa softver. Kupec se mora enostavno zavedat realnosti pa bo.
How do you know what you don't know?

Zgodovina sprememb…

strani: « 1 2 3


Vredno ogleda ...

TemaSporočilaOglediZadnje sporočilo
TemaSporočilaOglediZadnje sporočilo
»

Petindvajset najnevarnejših programerskih napak

Oddelek: Novice / Omrežja / internet
73875 (2329) noraguta
»

25 najnevarnejših programerskih napak (strani: 1 2 3 )

Oddelek: Novice / Varnost
13310872 (5223) MrStein
»

Outlook Express mi prepreci odpiranje prilog.

Oddelek: Pomoč in nasveti
13984 (853) boštjan
»

napaka

Oddelek: Slo-Tech
6697 (470) Tomi
»

MX300 in Linux

Oddelek: Zvok in slika
51022 (935) Nemenej

Več podobnih tem