Marcos Saldivar <[EMAIL PROTECTED]> wrote: > El dÃa 27 de noviembre de 2008 10:56, Ricardo Mun~oz A. > <[EMAIL PROTECTED]> escribió: > [...] > >> ¿Qué tan real es que el sw de mala calidad tiene menor costo v/s un sw > >> de calidad? > > > > buena pregunta. pero para poder responderla hay que primero ponerse de > > acuerdo en que consiste la "calidad" de un software: > > > > Desde mi punto de vista debe cumplir con lo siguiente para ser de calidad. > > - que cumpla con los requerimientos?
> Si, lo debes cumplir Hay una multitud de requerimientos. Casi nunca son "duros"; los hay indispensables, importantes, "nice to have". Y obviamente seran negociables segun su particular posicion en la escala. > > - que se desarrolle dentro de los plazos planificados? > Si, los debe cumplir No hay sofwate de calidad entonces ;-) > > - que haya pasado por X cantidad minima de pruebas de calidad? > Si, los debe cumplir. Define "pruebas de calidad", "pasar prueba", ... > > - que no tenga bugs? > Que minimice al máximo los bugs Nope. Hay distintas categorias, desde problemas de seguridad explotables en forma remota trivialmente (uno de esos anda haciendo estragos ahora...) hasta problemas cosmeticos menores. Igual que arriba, seran negociables. Y vi un comentario por alli (comentando sobre algun sistema interno de AT&T), indicando que si daban la opcion entre mejorar el rendimiento o eliminar los bugs optarian por lo primero (las ranas eran de poca monta, mas una irritacion menor; mientras el rendimiento era critico). > > - que sea seguro? > Si, lo debe cumplir. Define "seguro", define "cumplir con seguridad". Recordar que el comentario standard es que el unico computador 100% seguro esta en un bidon de 200 litros, encastrado en cemento, hundido en el centro de la bahia. Tambien 100% inutil, claro. Siempre hay un compromiso entre "seguridad" y "comododad de uso", "rendimiento" y otras caracteristicas mas. > > - que este documentado? > Si, un sw sin documentar no esta terminado. Hay quienes difieren. Si se requiere documentacion del codigo, el codigo no se entiende y es malo. Si el programa requiere extensa documentacion extra, es demasiado complejo de usar y no sirve. > > - que tenga una bonita interfaz de usuario? > Más que bonita(bonita es relativo) debe ser lo mas clara y facil de > usar por los usuarios finales. Ver arriba. > > - que use tecnologia (lenguaje, etc.) que provee una empresa > > "importante" del rubro como IBM, Oracle, Sun o Microsoft? > Que use la mejor opción para resolver los requirimientos. Como determinas cual es esa? Desde el punto de vista de la comodidad del desarrollador? Del usuario? De quien lo mantendra luego? Del que provee las herramientas (al que le conviene cobrar lo mas caro posible, claro)? Hay que considerar la ultima hornada de TLA y buzzwords? Realmente la ultima pomada de "desarrollo por telepatia con los alienigenas de los planetas recien descubiertos" es mejor que las tradicionales o no? Como se determina eso (particularmente antes que la moda haya sido reemplazada por la de la siguiente temporada)? > >> Nosotros conocemos el caso de Tuxpan ya que somos estudiantes de la > >> UTFSM Sede Viña y en alguna oportunidad ellos hicieron presentaciones, > >> donde por lo menos a mi me quedo claro > >> que si se puede desarrollar sw de calidad. > > como estudiante uno no tiene mayor nocion de la "realidad"... si le > Cual es esa realidad ? Si tienes que preguntar, es que ni la sospechas... > > creiste a unas simples presentaciones creo vas por mal camino como > > futuro empresario, a menos que hayas aprendido algunos tips de como > > hacer buenas presentaciones... ;) > ¿¿¿ Cual seria un buen punto de partida para tener un empresa que cree > sw de calidad ??? Leer a conciencia la literatura /seria/ al respecto (no, no son las cosas que se publican bajo "Ingenieria de Software" precisamente; son clasicos como el libro de Brooks y lo que han publicado Kernighan, Ritchie, Aho, Plaugher, Bentley (la tropa de AT&T tras Unix) y los BSDistas originales; ver los comentarios sobre "buen gusto" de Linus Torvalds, Alan Cox, Al Viro y algunas otras luminarias similares). Conocer los famosos modelos de madurez de desarrollo. Estos ultimos entenderlos lo suficiente para saber que debieran ser quemados ritualmente en una pira [Aportan mucho mas a generar frondosa documentacion y burocracia que buenos resultados]. Aprender a manejar un rango de herramientas (alguna vez usar herramientas "para compiladores" me permitio desarrollar en muy corto tiempo una parte central de un sistema, que de otra forma hubiese tomado unas 5 veces mas). Saber hasta donde puedes llegar, y donde requieres ayuda externa (y saber donde hallarla!) Saber estimar bien; no dejarse tentar por "con $COSTO_IRREAL ganamos el proyecto, de alli nos la arreglamos". Tener presente que la diferencia de productividad entre un desarrollador malo y uno excelente puede facilmente superar las 100 veces. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile 2340000 Fax: +56 32 2797513