Costos de calidad del software [Re: Ley de Presupuesto SW Libre y ACTI]

[Horst H. von Brand]

Marcos Saldivar <baron.rojo.cuerdas.de.acero en gmail.com> wrote:
> El día 27 de noviembre de 2008 10:56, Ricardo Mun~oz A.
> <ricardo74 en gmail.com> 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