 |
gildot |
 |
| |
| | Want to Sue over Buggy Code? | | |  | Contribuído por BladeRunner em 01-10-03 21:02
do departamento money-it's-a-gas | |  | |  | | |  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 | | | Referências | | |
| Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário. | | | | 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
|
| | | | | | 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
|
| |
|
