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

[Franco Catrin L.]

El sáb, 29-11-2008 a las 23:25 -0300, Horst H. von Brand escribió:

> 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.

Hay varios niveles de documentación, no solo el código. Por ejemplo
diseños de alto nivel o API's.  En general, cosas que no se pueden
desprender del código fácilmente.

No estoy hablando de toneladas de manuales inservibles, sino de lo
mínimo necesario para que entender de qué se trata el asunto, para que
ese análisis no me quite un par de días de trabajo.

También está la documentación de los procesos, algo que gracias a las
herramientas actuales se puede hacer de forma bastante simple, indolora
y principalmente UTIL.  Por ejemplo registros de cambios o seguimientos
de bugs.   Estas cosas que son obvias en el mundo del desarrollo de
código abierto no lo son a nivel de desarrollo cerrado.  Obviamente no
estoy hablando de mi caso en particular, estoy hablando del resto de las
empresas incluyendo las grandes.

> > > - 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)?

En general, en mi experiencia, no hay muchas opciones al respecto, casi
siempre el entorno te encamina hacia una tecnología.   Además que para
este tipo de cosas no conviene ponerse inventivo, a la larga provoca mas
dolores de cabeza para todos.  Es muy tentador poner en practica "la
ultima tecnología aprendida" pero con la experiencia se ve que hay que
mezclar el ser conservador y al mismo tiempo explorador de nuevas
tecnologías.

> 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)?

No necesariamente son modas.  En vez de descartar una cosa por otra, se
van encontrando mejoras, yo lo llamaría evolución.

Por ejemplo hasta hace poco era natural pensar en aplicaciones con el
contenido+presentación generado en el servidor (php/asp/jsp, etc), eso
tenía ventajas y desventajas.  Hoy en día es posible hacer aplicaciones
que corren en el lado del cliente, eliminando las desventajas del modelo
previo, pero manteniendo y ampliando sus ventajas.

> > >> 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].

Depende.  El modelo CMMI por ejemplo habla de cosas que deberias tener
como parte de tus practicas, pero queda de tu parte la forma en que las
implementas.  En general las prácticas son cosas que te ayudan y no se
trata de simple burocracia, no creo por ejemplo que alguien en su sano
juicio encuentre que hacer seguimiento de bugs formal es una burocracia,
y cuando me refiero a formal no estoy hablando de llenar un monton de
formularios inútiles, estoy hablando de las mismas prácticas que se
llevan en el desarollo de código abierto.

Se que la recomendación viene de cerca, pero me gustó mucho como quedó
esta artículo sobre el tema:

Madurez Organizacional: No es fanatismo Nerd
http://tinyurl.com/6pjey6


[...]

> Tener presente que la diferencia de productividad entre un desarrollador
> malo y uno excelente puede facilmente superar las 100 veces.

También hay que considerar que un desarrollador excelente no le va a ser
atractivo trabajar en tareas triviales, tener sólo desarrolladores
excelentes hace que nadie sea capaz de llevar a cabo ese tipo de tareas.

Personalmente creo en un mezcla de ambos, en donde un conjunto de
excelencia se encarga de la infraestructura, y otro grupo se encarga de
"las terminaciones".  

--
Franco