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

[Franco Catrin L.]

El dom, 30-11-2008 a las 10:38 -0300, Horst H. von Brand escribió:
> Franco Catrin L. <fcatrin en tuxpan.com> wrote:

[...]

> > En general, en mi experiencia, no hay muchas opciones al respecto, casi
> > siempre el entorno te encamina hacia una tecnología.
> 
> Cierto, hay (natural y necesaria!) inercia de "sigamos con lo que
> conocemos", pero esta la ley de Moore: A los 5 an~os definitivamente estas
> haciendo cosas completamente diferentes, el problema es como llegamos
> alla...

Cuando me refería al entorno en realidad no me refería al entorno
global, me refería al entorno de operación del producto final. Uno no
puede llegar y decir "pongamos foo", donde "foo" es muy distinto a lo
que ya tienen en operación.  Por ejemplo no puedo llegar con una
solución .NET+SQL Server en una organización que tiene todo con J2EE
+Oracle.

> 
> >                                                        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.
> 
> Es facil decirlo, dificil de llevar adelante...

Se puede.  Vivo de eso ;-)

Explicado en pocas palabras :  Un asunto es el problema a resolver y
otro asunto es la tecnología usada para resolverlo.  Si logras abstraer
la tecnología de tal forma que se pueda presentar como algo
conocido/estandard lo suficiente como para enfocarse en el problema a
resolver, puedes cambiar de tecnología sin impactar fuertemente al
"desarrollador final".

Claro que para que eso funcione, la organización tiene que estar
alineada y debe considerar el costo/esfuerzo que se necesita, y que los
resultados son a largo plazo.  Personalmente creo que ahi fallan muchos,
tratando de hacer las cosas "de cualquier forma" y "para ayer".


> > 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.
> 
> Mish... "cliente-servidor" le llamaban a /esa/ pomada en los '80 ;-)

En conceptos muy simples si.  Pero es una mezcla de los 80 y los 90.  El
cliente ya no es una aplicación nativa instalada en un PC ('80) con
todos los problemas de deployment y seguridad asociados, sino que es una
aplicación independiente de la plataforma, actualizable en forma
automática, disponible en forma transparente y provista desde un
servidor ('90).  Por otra parte el servidor no es un proveedor de datos
con acceso directo a ellos y restringido a las decisiones de diseño tras
él ('80), sino que es un proveedor de servicios de alto nivel, también
operando con protocolos estándares, independiente de la plataforma y con
esquemas de seguridad a nivel de transporte ('90/'00).

Lo que quiero decir es que hoy se ha combinado lo mejor de ambos
enfoques, y no se puede decir simplemente que hemos vuelto a lo que
había en los '80.  

(Si, si... también habian servicios publicados via DCOM/CORBA en épocas
anteriores, pero nunca tomaron mucho vuelo, además de las limitaciones
que tenían).


> 
> [...]
> 
> > > > ¿¿¿ 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.
> 
> Disculpa, estas hablando del _espiritu_ de CMMI. En la practica, para
> _certificarte_ en CMMI tienes que tener un monton de papeles que demuestran
> que reportaste el bug, que quedo registrado, que hay "alguien" responsable
> de revisar que los bugs se reporten, ...

Espero responder sin violar ningún NDA.

En el ejemplo dado no es necesario ningún montón de papeles.  La
evidencia que describes está en la misma herramienta, o la tienes o no
la tienes. 

En mi experiencia, el costo en esfuerzo de una evaluación CMMI depende mucho del estado de la organización.

Hay cosas que no haces, otras que si, y otras en donde no haces lo
suficiente.  No es necesario "hacer de más", sólo tienes que preocuparte
de hacer lo que necesitas.  Vuelvo al caso anterior y conocido por
todos: un proyecto de software  de código abierto se vería en graves
problemas si no tiene un sistema de control de versiones que cumpla con
requisitos mínimos, lo mismo para el seguimiento de bugs.   Tener menos
que eso hace que todo sea más difícil, y al mismo tiempo, hacer más que
eso no tiene sentido si no aporta al producto final, y además hace que
todo sea más complejo, le agrega "grasa" al proceso.


> Como lo que vi alguna vez en un aeropuerto: Ibamos por un amplio pasillo, y
> de repente esas cuerdas para cerrar el paso + guardias. Un fenomenal taco,
> reclamos, ... consultas posteriores indicaron que era "por la certificacion
> ISO", no se permite que se mezclen pasajeros que vienen llegando con los
> que van saliendo. Solucion: Pasan igual por pasillos que se cruzan, pero
> los segregamos con guardias y barreras temporales. Se certifica "de
> calidad", pero es cualquier cosa ridicula lejana de lo que cualquiera
> entiende por eso.
> 
> Demasiadas de las certificaciones son, como alguien dijo, "We do everything
> following the prescription to the letter, but we still just make shit".

Bueno, ese será el mundo de las certificaciones ISO + organizaciones que
lo hacen por tener un timbre y no porque lo consideren un aporte.

> 
> [...]
> 
> > > 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.
> 
> Para eso hay computadores... y la diferencia entre el excelente y el
> mediocre es que el excelente sabe usar las herramientas.

No me refería a desarrolladores mediocres.  Yo hacía la distinción entre
los desarrolladores excelentes y los buenos desarrolladores.

Se necesita de un buen desarrollador para entender y aplicar lo que le
entrega un desarrollador excelente.   Un desarrollador mediocre lo puede
hacer mal aunque le pases la mejor herramienta.  (Yo sé que tu lo sabes
muy bien, es para el resto de los que están mirando esta conversación)

-- 
Franco Catrin L.  TUXPAN Software S.A.
http://www.tuxpan.com/fcatrin