Cita:
|
¿Cree que UML vino para quedarse?
|
UML ya esta aqui y ya se quedo...
Cita:
|
¿Si existiese otra metodología (supuestamente flexible y adaptable a cualquier tipo software a desarrollar), la pondría a prueba?
|
Creo que la clave no es adaptarla a un tipo/cualquier tipo de software, sino a la GENTE. Y como eso es dificil nadie va a lograrlo.
Aunque me parece que Extremme Programing y Agile son dos faciles de adaptar a un grupo pequeño. En mi caso saque ideas de ambos y las estoy usando... poco a poco mientras acomodo.
Teniendo como base el enfoque que Borland y MS le estan dando a las futuras (y en el caso de Borland, presentes) herramientas de software, yo diria que la idea es una mezcla entre XP/Agile junto a
esto
Meterle la filosofia de una metodologia de desarrollo a la gente, simple y llanamente, no da el resultado esperado... Como rayos va un equipo de desarrollo a tirar UML cuando NISIQUIERA puede manejar sus propias versiones de codigo?
ANTES de la metodologia, un desarrollador/equipo debe tener funcionando de forma controlada o cotidiana:
1- Control de codigo fuente. Recomiendo bastante usar
Subversion junto con TortoiseSVN. Pero lo que sea, mientras se use tambien es valido
2- Ser capaza de hacer un release del codigo tan rapido y eficiente como se pueda, sin pasos manuales (del codigo al instalador en 1 click). Para hacer esto bien, OBLIGATORIAMENTE hay que hacer lo primero y OJALA en un equipo distinto a la maquina de desarrollo (en su defecto, como es mi caso, al menos en un disco/directorio diferente). Yo uso
NAnt por razones de mi contratista aunque si pudiera usaria
FinaBuilder. Usar batch tambien cuenta.
3- Tener una lista de errores/tareas por hacer. Hay muchas herramientas y todavia no me decido... Aunque ya uso una y de verdad ayuda bastante. NO HAY FORMA de trabajar sin un TODO-LIST y un BUG-List.
4- Tener un desarrollo que este
enfocado a eliminar errores y corrobore la funcionalidad. Como uso Delphi 2005 ya esta todo integrado pero no es para nada dificil usar Dunit con Delphi 5-7. O sea, para que UML si no se tiene la certeza si el codigo es bueno o no?
El punto es, hay que limpiar la casa ANTES de traerle nuevo decorado. Los puntos anteriores son los mas minimos que un desarrollador/empresa debe tener... sin estos cualquier otra metodologia falla.
Pero !ojo! eso es sola la infraestructura/plataforma de trabajo. ANTES que eso esta:
1- El programador debe ser capaz de escribir codigo que:
- Sea claro y conciso. Nombrado correcto de variables, procedimientos, funciones, propiedades.
- Este bien documentado (nada de i:=0 //Inicializa i a 0) De hecho una excelente documentacion se confirma con un codigo casi SIN documentacion pero que se lea de pe a pa sin estorbos.
- Una organizacion decente de directorios. A parte de utilidades o pruebas, ningun programa debe tener sus archivos todos juntos en un directorio. En mi caso lo hago asi:
Proyectos/Programa (archivo de proyecto)
bin - Ejecutables
Formas
Clases
Otros
dcu - units compilados
Una vez se pasa este punto, ahora si la metodologia va a ayudar. Sin esto, de nada va a servir....