gildot

Topo
Sobre
FAQ
Tópicos
Autores
Preferências
Artigos
Sondagens
Propor artigo


8/3
gildicas
9/30
jobs
10/9
perguntas
10/25
press

 
Want to Sue over Buggy Code?
Contribuído por BladeRunner em 01-10-03 21:02
do departamento money-it's-a-gas
Bug jazzy escreve "Ia eu a surfar na crista de uma onda, quando deparei com este artigo de opinião acerca da responsabilização das por bugs de software.
No final do artigo, o autor questiona-se acerca das razões que levam a que (especialmente) grandes corporações e governos aceitem as clausulas (abusivas na opinião dele) das EULAs que normalmente acompanham o software."

Mãe, sem mãos! | Verisign à moda portuguesa!?  >

 

gildot Login
Login:

Password:

Referências
  • artigo de opinião
  • Mais acerca Bug
  • Também por BladeRunner
  • Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário.
    responsabilização, qualidade et al (Pontos:5, Interessante)
    por cgd em 02-10-03 10:44 GMT (#1)
    (Utilizador Info) http://pagpessoais.iol.pt/~mz17929a
    Oi, este tópico já foi debatido algumas vezes aqui no gil. Basicamente parece-me que existem duas correntes por cá, antagónicas e um pouco extremadas: manter as coisas as is ou impor responsabilização, criar mecanismos de qualidade no processo de criação de SW.

    Coisas as is (- mau, + bom):
    - buggy code
    - problemas de segurança (logo falta de "reliability")
    - enormes custos escondidos associados (segundo um relatorio do NIST, nos estados unidos em 2002, os custos com mau software podem ter chegado aos 60 mil milhoes de $, o que dá qq coisa como 450 contos por mes por pessoa a trabalhar na area)
    + crescimento "exponencial" de funcionalidade

    Processos de qualidades, responsabilizacao:
    - funcionalidade e inovacao crescem muito mais lentamente
    - custos explicitos mais elevados (o SW fica mais caro out of the box)
    + SW mais confiável e seguro

    Pessoalmente tenho uma postura mais intermédia. Identifico estes grandes problemas na produção tradicional de SW:

  • desenvolvimento tipicamente não liga a questões de segurança
  • perspectiva de que o utilizador final conformar-se-á (ver microsoft, por exemplo)
  • foco está na funcionalidade
  • melhorias contínuas são raras

    Alguns principios que podem combater alguns destes defeitos são os seguintes:

  • adoptar métodos leves de desenvolvimento (ex: extreme programming - xp)
  • usar sistemas de controlo de versões eficientemente (e para o que eles servem de facto -- acreditem que o pessoal consegue ser realmente imaginativo com o uso que consegue dar ao CVS por exemplo)
  • automatizar todos os aspectos possíveis dos projectos, desde os óbvios (builds and deploy), mas tb partes de código repetitivas devem ser geradas automaticamente
  • usar ferramentas de validação/auditoria de código integradamente *enquanto* se desenvolve (tipo lint ou as novas gerações de checkers-- checkstyle para java; ou big expensive tools: devpartner da compuware)

    cya


  • Re:responsabilização, qualidade et al (Pontos:4, Interessante)
    por DomusOnline em 02-10-03 17:20 GMT (#2)
    (Utilizador Info) http://bandalarga.domus.online.pt/
    De facto isto é um tema recorrente...

    Eu provavelmente estou numa posição que consideras extremada, mas pelo menos é clara ;)

    Do que conheço do desenvolvimento de software que reconheço desde já que é pouco, não me parece aceitável a responsabilização dos fornecedores. Por vários aspectos:

    1- Não me parece que o software seja uma "engenharia" no verdadeiro sentido da palavra.
    2- Permitir essa responsabilização só iria como alguém escreveu aqui da última vez enriquecer os advogados. Passaria a ser um negócio... tinhas uma empresa em mau estado, pegas num software, descobres um BUG, fazes asneiras e culpas o software ;) É romanceado, mas penso que serve para ilustrar a ideia.

    Na minha actividade profissional deparo-me com muitos BUGs em produtos comerciais, e em alguns casos fico bastante por dentro dos detalhes... E isto permite-me dizer que há "bichos" do arco da velha... desde os mais "toscos" aos mais estranhos e que acontecem uma vez na vida... E isto em software que usa controlo de versões a sério, que sofre testes unitários e de integração sempre que é feito uma alteração etc.

    Nota... Não quero com isto dizer que ache que está tudo bem como está... Mas penso que a qualidade dos produtos deve medir-se entre outras coisas pelo impacto que os seus BUGs tem. E isso deve ser medido pelos clientes. O CoO (Cost of Ownership) foi "inventado" pelos fornecedores para apresentações Powerpoint, mas os clientes já deviam ter percebido que só eles o podem medir, e quais as vantagens de o fazerem. E pela minha experiência não o fazem. Ou seja, o mecanismo de mercado não funciona bem nesta área.

    Cumprimentos

     

     

    [ Topo | FAQ | Editores | Contacto ]