Feil i Norton-oppdatering

[abene]

Symantec er klar med oppdatering for brukere som er blitt rammet.

 

Les mer

[Malvado]

Jøss, la merke til at norton ikke lenger var i systemstatusfeltet i dag og joda, det fungerte ikke å re-starte tjenesten. Heldigvis så forsvann tjenesten i natt og ikke flere dager siden.

 

Og dette på et "clean" system som nettop har blitt innstallert, så unnskyldningen til Norton er bullshit.

[Gjest Slettet-Pqy3rC]

Ifølge Cecilia Daclan fra Symantec er det usikkert hva som kan ha forårsaket problemet

En smule underlig at de ikke vet hva som forårsaker feilen dersom de allerede har rettet den...

[oysteinsor]

Ifølge Cecilia Daclan fra Symantec er det usikkert hva som kan ha forårsaket problemet

En smule underlig at de ikke vet hva som forårsaker feilen dersom de allerede har rettet den...

 

Vil bare gjøre oppmerksom på at jeg har ved flere anleninger klart å rette feil i et program uten å vite hva som egentlig er årsak til feilen.

 

Men jeg tviler sterkt på at hvilken som helst representant i Symantech vet hva som var feil.

 

Det vesentlige for de som bruker programmet er vel at programmet er fikset, er ikke det det?

 

 

hilsen Systemutvikler.

[Gjest Slettet-Pqy3rC]

Vil bare gjøre oppmerksom på at jeg har ved flere anleninger klart å rette feil i et program uten å vite hva som egentlig er årsak til feilen.

Det er i tilfelle svært godt gjort.

La meg her bemerke følgende:

Dersom man skriver om hele eller deler av et program fordi man vet at det finnes en feil et eller annet sted i koden man bytter ut er ikke dette å regne som feilretting. En slik endring vil isteden klassifiseres som generell utvikling (versjonsøkning).

Det er kun i de tilfellene man finnet ut hvordan feilen oppstår og dermed direkte kan løse det bestemte problemet, uten å endre annen logikk, at du har en "bugfix".

Men jeg tviler sterkt på at hvilken som helst representant i Symantech vet hva som var feil.

Enhver som ikke vet noe burde rett og slett oppgi dette faktum og ikke isteden komme med en eller annen meningsløs teori. Dette gjelder egentlig i enhver sammenheng.

Det vesentlige for de som bruker programmet er vel at programmet er fikset, er ikke det det?

Joda, forsåvidt. De fleste gir vel katta så lange endringen ikke påvirker UI'et.

[oysteinsor]

Vil bare gjøre oppmerksom på at jeg har ved flere anleninger klart å rette feil i et program uten å vite hva som egentlig er årsak til feilen.

Det er i tilfelle svært godt gjort.

La meg her bemerke følgende:

Dersom man skriver om hele eller deler av et program fordi man vet at det finnes en feil et eller annet sted i koden man bytter ut er ikke dette å regne som feilretting. En slik endring vil isteden klassifiseres som generell utvikling (versjonsøkning).

Det er kun i de tilfellene man finnet ut hvordan feilen oppstår og dermed direkte kan løse det bestemte problemet, uten å endre annen logikk, at du har en "bugfix".

Men jeg tviler sterkt på at hvilken som helst representant i Symantech vet hva som var feil.

Enhver som ikke vet noe burde rett og slett oppgi dette faktum og ikke isteden komme med en eller annen meningsløs teori. Dette gjelder egentlig i enhver sammenheng.

Det vesentlige for de som bruker programmet er vel at programmet er fikset, er ikke det det?

Joda, forsåvidt. De fleste gir vel katta så lange endringen ikke påvirker UI'et.

 

Hvis en har laget et program som skjelden blir lenger enn noen tusen linjer og det ikke er avhengig av tredjeparts kode for å fungere, ja da er det kanskje ganske rart å kunne rette feil, uten å vite hvorfor. Men da lurer jeg på hvilken type erfaring du har med utvikling av programvare, som svarer slik.

 

Feilretting internt i et program vil veldig skjeldent komme ut som kundeinfo, rett og slett fordi det er av teknisk art og gir ingen allmennytting info.

 

I tillegg så har som oftest brukerene ikke noe med de interne tekniske detaljer i et program, og et program som antivirusprogram bør aldri gi noen teknisk info om hvorfor ting krasje, rett og slett fordi det vil bli utnyttet av de som ønsker at norton antivirus skal krasje.

[Gjest Slettet-Pqy3rC]

Hvis en har laget et program som skjelden blir lenger enn noen tusen linjer og det ikke er avhengig av tredjeparts kode for å fungere, ja da er det kanskje ganske rart å kunne rette feil, uten å vite hvorfor. Men da lurer jeg på hvilken type erfaring du har med utvikling av programvare, som svarer slik.

Er det feil i tredjeparts kode bør jo helst tredjeparten rette feilen. Dersom en gjør grep for å omgå problemet (om det er mulig) betyr dette vanligvis omskriving og ikke feilretting.

Gruppering av endringer som enten feilretting eller omskriving har forøvrig egentlig mest å gjøre med testbehovet som følger. En feilretting trenger kun konkret testing, mens omskriving krever standard testing (på linje med mer generell utvikling).

Feilretting internt i et program vil veldig skjeldent komme ut som kundeinfo, rett og slett fordi det er av teknisk art og gir ingen allmennytting info.

Riktig det, men info om endringen har nytte som internt i utviklingsavdelingen, både da den gjøres og i ettertid. Denne informasjonen bør inneholde både problembeskrivelse, årsak og løsningsvalg.

Utad trenger man ikke, som du nevner, gjøre annet enn å evt. bekrefte at problemet er fjernet (uten å presentere årsaks eller løsning) eller ikke oppgi noe som helst. Dette endres jo selvsagt dersom løsningen på problemet skulle påvirke brukerens arbeidsrutiner på noen måte.

[oysteinsor]

Hvis en har laget et program som skjelden blir lenger enn noen tusen linjer og det ikke er avhengig av tredjeparts kode for å fungere, ja da er det kanskje ganske rart å kunne rette feil, uten å vite hvorfor. Men da lurer jeg på hvilken type erfaring du har med utvikling av programvare, som svarer slik.

Er det feil i tredjeparts kode bør jo helst tredjeparten rette feilen. Dersom en gjør grep for å omgå problemet (om det er mulig) betyr dette vanligvis omskriving og ikke feilretting.

Gruppering av endringer som enten feilretting eller omskriving har forøvrig egentlig mest å gjøre med testbehovet som følger. En feilretting trenger kun konkret testing, mens omskriving krever standard testing (på linje med mer generell utvikling).

Feilretting internt i et program vil veldig skjeldent komme ut som kundeinfo, rett og slett fordi det er av teknisk art og gir ingen allmennytting info.

Riktig det, men info om endringen har nytte som internt i utviklingsavdelingen, både da den gjøres og i ettertid. Denne informasjonen bør inneholde både problembeskrivelse, årsak og løsningsvalg.

Utad trenger man ikke, som du nevner, gjøre annet enn å evt. bekrefte at problemet er fjernet (uten å presentere årsaks eller løsning) eller ikke oppgi noe som helst. Dette endres jo selvsagt dersom løsningen på problemet skulle påvirke brukerens arbeidsrutiner på noen måte.

 

Jeg savner fremdeles et svar som sier noe om din erfaring innen progamutvikling siden du kan svare så selvsikkert på hva som må til ved programendringer og feilrettinger, og hvorfor det er så stor forskjell på de to.

 

Og ikke minst om størrelsen på de programmeringsprosjektene du har befatning med. Antar faktisk at du har erfaring, siden du svarer på den måten du gjør.

 

Det vil ikke gi mening å gi ut info til brukerene om en endring er en omskriving eller bare en liten feilretting. Hvorfor skulle sluttbruker være interessert i det?

 

Hvis det får programmet til å fungere, ja så er det nok for de fleste brukerne.

 

mvh

[Gjest Slettet-Pqy3rC]

Jeg savner fremdeles et svar som sier noe om din erfaring innen progamutvikling ...

Og ikke minst om størrelsen på de programmeringsprosjektene du har befatning med ...

Personlige spørsmål vil jeg ikke besvare og du vil jo uansett ikke kunne kontrollere svarene dersom jeg hadde gitt noen.

Avsnittene under indikerer vel uansett at jeg jobber med systemer som er rettet mot bedrifter/organisjasjoner og ikke "singleuser".

Det vil ikke gi mening å gi ut info til brukerene om en endring er en omskriving eller bare en liten feilretting. Hvorfor skulle sluttbruker være interessert i det?

Sannsynligvis er ikke sluttbrukeren veldig interessert i denne typen klassifisering, nei. Dog finnes det ulike typer brukere fra en utviklers ståsted; drift, ledelse og frontend. Disse vil muligens ønske litt ulik informasjon.

 

Som utviklere gir vi en ganske detaljert endringsliste til testere (listen er dessuten ganske nyttig for oss i ettertid). Jeg mener det er viktig at testere vet hva de skal fokusere på under testing mht endringer. Derfor blir skillet mellom "bugfix", omskriving og videreutvikling ganske markant i denne typen liste.

Endret 28. september 2009 av Slettet-Pqy3rC

[oysteinsor]

Jeg savner fremdeles et svar som sier noe om din erfaring innen progamutvikling ...

Og ikke minst om størrelsen på de programmeringsprosjektene du har befatning med ...

Personlige spørsmål vil jeg ikke besvare og du vil jo uansett ikke kunne kontrollere svarene dersom jeg hadde gitt noen.

Avsnittene under indikerer vel uansett at jeg jobber med systemer som er rettet mot bedrifter/organisjasjoner og ikke "singleuser".

Det vil ikke gi mening å gi ut info til brukerene om en endring er en omskriving eller bare en liten feilretting. Hvorfor skulle sluttbruker være interessert i det?

Sannsynligvis er ikke sluttbrukeren veldig interessert i denne typen klassifisering, nei. Dog finnes det ulike typer brukere fra en utviklers ståsted; drift, ledelse og frontend. Disse vil muligens ønske litt ulik informasjon.

 

Som utviklere gir vi en ganske detaljert endringsliste til testere (listen er dessuten ganske nyttig for oss i ettertid). Jeg mener det er viktig at testere vet hva de skal fokusere på under testing mht endringer. Derfor blir skillet mellom "bugfix", omskriving og videreutvikling ganske markant i denne typen liste.

 

Flott at du svarte. Mitt prinsipp i denne saken er først og fremst at det finnes mangen måter å gjøre ting på i forhold til systemutvikling og at din skråsikre måte å skrive om hva som er naturlig å gjøre, kanskje er naturlig in din organisasjon, men ikke i en annen.

 

Applikasjonssystemer baserer seg på ulik grad av 3.parts utvilkete deler.

Applikasjonssystemer har ulik grad av kompleksitet.

Applikasjonssystemer er rettet mot ulike kundesegmenter. ( f.eks personlig, small business, enterprise )

+++

 

Alle faktorene over pluss mangen andre vil påvirke hvilke prosesser som utviklingsprosessen har og det finnes derfor ingen fasit på hva som er 'korrekt' metode for utvikling og testing av programsystemer. Og i tillegg så vil det påvirke i hvilken grad kunden får vite om hva som faktisk er fikset og eventuelt hvordan.