¿Que metodologías usas para el analisis y diseño?

[[Delphius]]

Como dice el título: que ¿Metodología usas para el analisis y diseño?

Estuve pensando desde la segunda mitad del año pasado si es posible vencer la frase: "No hay metodología cien por cien exacta y aplicable para un software específico". Y esto me llevó a buscar un tema para mi futura tesis (que deberé presentar el año que viene): una metodolgía para el análisis y diseño de software que sea lo más flexible y adaptable a cualquier software por desarrollar. Mi profe de la cátedra de Sistemas II (cursada el año pasado) nos dijo: "el 40% de los software fracasan por un mal análisis y diseño". ¿Tanta verdad tiene?Lo dudo... esto me reforzó la idea de tratar de buscar una manera de lograr esa metodología "flexible"; obvio: diferente a las actuales pero con vista hacia el presente y el futuro.

En dicha cátedra sólo tuve la oportunidad de ver el Analisis Estructurado Moderno y este año en Ingeniería de Software ando viendo UML (algo que yo por cuenta propia ya había empezado a investigar), pero creo que tengo la astucia mental como para entender y lograr una metodología por lo menos básica.

Actualmente llevo ya unas 16 hojas ( y todavía falta volcar lo que tengo en mente y en borrador) sobre mi idea: todo basado de lo que pude investigar hasta el presente y sumando de la experiencia (poca pero con excelentes resultados) que he tenido en dicha área.

Como ya dije anteriormente, ahora estoy viendo UML y acabo de darme cuenta (a mi entender, al Salir de Clases de Ingeniería de Software) que acabo de reinvertar tanto UML como USDP.¡Mi metodología y lenguaje sin similares; si bien tienen sus diferencias, presiento que si sigo tirando más ideas llegaré a lo mismo!

Entonces, para evitarme el embrollo y gastos de neuronas en buscar una solución o de lograr "reinventar la rueda" he decido lanzar esta pregunta/encuesta para ver si sigo con esto... o busco otra cosa en que pensar (todavía no he presentado la propuesta).

Lo ideal sería que esta encuesta la respondan aquellas personas que tiene una larga formación profesional o que entiendan mucho del asunto, de todas formas esto es libre y puede responder cualquier persona que esté interesado en esto.

Encuesta:
A. ¿Que metodología/Lenguaje usa para el análisis y diseño?
1. Analisis Estructurado Moderno
2. UML/USDP
3. Una "propia"
4. Otra

Si respondió afirmativamente a la opción 2, responda:
1. ¿Cree que UML vino para quedarse?
2. ¿Si existiese otra metodología (supuestamente flexible y adaptable a cualquier tipo software a desarrollar), la pondría a prueba?

B. ¿Cree que sea posible desarrollar dicha metodología?.

Gracias a todos los foristas que hayan dedicado un poco de su valioso tiempo para leer este hilo.

[mamcx]

¿Cree que UML vino para quedarse?

UML ya esta aqui y ya se quedo...

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

[[Delphius]]

Gracias por tu aporte...
Resulta muy interesante tu punto de vista (del cual estoy de acuerdo, en gran parte) ....

Esperaba que esta encuesta/hilo fuera mas enriquecedora (y participativa). El objetivo de esto era poder ver que tan factible es este sector de la informática (pues allí quisiera especializarme).

Se que para lograr UML se requierió de años, y yo no voy a lograr lo que lograron estos 3 gurus.... pero sigo soñando que con la experiencia que pueda adquirir logre encontrar algo (no pido que sea mejor) pero que ofrezca otra alternativa aparte de UML.

El año pasado fue a una jornada que se realizan todos los años(JAIIO) y me llamó algo la atención: programación orientada a aspectos. ¡Algo nuevo para mi! ¿Porqué no buscar algo una metodología que basada en el modelo OA (orientado a aspectos)? quien sabe... a lo mejor ese es el futuro. UML -> OO, ¿porqué no "ALGO" -> OA.?

Se que en definitiva depende de la persona y que muchas veces imponerle a las personas una forma de hacer las cosas no traen las mejores soluciones, pero creo que el objetivo no es de imponerle algo sino de ofrecerle un punto base, entendible, estandar, un protocolo que todos entendamos para que el intercambio de información, manejo, etc sea más fácil....
¿Que acaso no es eso lo que se espera: FACILIDAD?

Bueno, así es como lo veo... no quiero ponerme en contra tuya... es sólo una opiníon.

[mamcx]

Entones la gracia es como hacer para que la gente se motive a hacer algo y que no lo sientan como una imposicion.

Es dificil vender la idea de usar UML... siesque muchos se resienten a DISEÑAR antes de codificar! Lo que pasa es que falta integracion. Lo que hace Borland ahora con together tiene mucha gracia... el programador NO hace el UML, el uml se saca en vivo del codigo y si se altera el diseño, se altera el codigo. COsas integradas y automatizadas si llaman la atencion...

Por ejemplo, estan los bugs. Hay que usar una herramienta de bugs, pero salir del IDE? No es dificil pero es inconveniente... ahora si estuviera dentro como un TODO LIST...

Me parece que para entrar con cualquier metodologia hay que hacerlo por etapas... Si se tiene la meta de llegar a un desarrollo estructurado en vez de espantar a la gente, es empezar generando un cambio a lavez.

Primero, vender el control de codio fuente... una vez hecho, el paso a builds diarios es casi directo. De hay a unit testing... luego UML. Es ir mostrando como mejora la productividad sin introducir de golpe todo..

[[Delphius]]

mamcx
Es dificil vender la idea de usar UML... siesque muchos se resienten a DISEÑAR antes de codificar!

A la manera en que lo dices, parece que el trabajo del añalista está de moño. No creo que sea tan así, me parece obvio que todo software sigue una línea (en línea generales): análisis, diseño, codificación, prueba, manteniminento. ¿Como es posible que se llegue entonces a la codificación si no hubo una etapa anterior de diseño aunque sea mínima?
¿Entonces para que gastaron años estos 3 locos si nadie la usa desde un principio?

mamcx
el programador NO hace el UML, el uml se saca en vivo del codigo

Me parece fabuloso, pero no le veo sentido hacer UML del código cuando en realidad lo que debería hacerse es el paso inverso: de UML al código.

mamx
Me parece que para entrar con cualquier metodologia hay que hacerlo por etapas... Si se tiene la meta de llegar a un desarrollo estructurado en vez de espantar a la gente, es empezar generando un cambio a lavez.

Primero, vender el control de codio fuente... una vez hecho, el paso a builds diarios es casi directo. De hay a unit testing... luego UML. Es ir mostrando como mejora la productividad sin introducir de golpe todo..

Se supone que este cambio no debería producirse. ¿Que acaso no se le enseña a usar UML en las universidades?¿Si realmente se les enseñaron estos conceptos, a que tanto le tienen miedo?
En todo caso lo que falta no es la integración, sino la enseñanza. ¿Si se enseñaran bien las cosas, no habría golpes no crees?

[mamcx]

Empezado por Delphius

A la manera en que lo dices, parece que el trabajo del añalista está de moño.
No creo que sea tan así, me parece obvio que todo software sigue una línea (en línea generales): análisis, diseño, codificación, prueba, manteniminento. ¿Como es posible que se llegue entonces a la codificación si no hubo una etapa anterior de diseño aunque sea mínima?

No deberia ser asi, lo se. Pero es la realidad. Una vez alguien tiene una idea (ej: Haz un software de facturacion) la gran mayoria inmediatamente nos sentamos a codificar sin hacer ninguno tipo de analisis serio, confiando en que en el camino se resolveran las cosas. Y digo "nos sentamos" porque en lineas generales es mi propia experiencia y de lo que conozco de la mayoria de la gente en varias empresas de software. De hecho, es la tendencia mundial.

Empezado por Delphius

¿Entonces para que gastaron años estos 3 locos si nadie la usa desde un principio?

Precisamente, porque nadie lo hace y por eso Rational es una empresa que gana millones de dolares vendiendo un modelo, unas herramientas y consultorias.

Empezado por Delphius

Me parece fabuloso, pero no le veo sentido hacer UML del código cuando en realidad lo que debería hacerse es el paso inverso: de UML al código.

Es lo ideal, pero la mayoria del codigo ya esta hecho y se necesita comprenderlo. Sin una ayuda automatica, queda muy dicil documentar un desarrollo existente.

Por otro lado, si miras las ideas que propone la programacion extrema, el orden es codigo y si hay tiempo, UML. El UML no es absolutamente indispensable y se puede diseñar directamente en codigo... pero si es una excelente y mejor herramienta para hacerlo. Obvio que habra quienes piensen otra cosa y ese es el problema...

Empezado por Delphius

Se supone que este cambio no debería producirse. ¿Que acaso no se le enseña a usar UML en las universidades?¿Si realmente se les enseñaron estos conceptos, a que tanto le tienen miedo?
En todo caso lo que falta no es la integración, sino la enseñanza. ¿Si se enseñaran bien las cosas, no habría golpes no crees?

Desafortunadamente la enseñanza al respecto no es muy buena. Y el punto es, estamos hablando de quienes, programadores o analistas o ingenieros o??? Si como es el caso de muchos, que iniciamos como programadores, si tenemos de forma caotica los procesos mas elementales, como la manera de mantener las versiones de nuestro propio codigo, de poco o nada sirve el UML.

Haciendo una analogia, es como construir una casa. Obvio que tener los planos es indispensable, pero si los albañiles no saben organizar las herramientas y cada cual tiene su "estilo" de pegar ladrillos, el beneficio de tenerlos se diluira.

A lo que voy con todo esto y apuntando al objetivo que tienes, es reconocer que el desarrollo de software es en general, muy caotico. No se cumplen los tiempos pactados, la mayoria no sabe como estimarlos, no se satisfacen los requerimientos del cliente y muchas veces, ni siquiera los tecnicos. La calidad de los desarrollos es variable pero no es muy comun un programa de buena calidad de primera vez, y asi por el estilo.

El tener las herramientas es indispensable. Mantener:

- El codigo
- Lo que ese codigo debe hacer (requerimientos)
- El diseño del codigo, en otro lenguaje (UML)
- Lo que ese codigo no hace bien (bugs)
- Los archivos anexos, como manejo de los clientes
- etc...

de forma manual es muy tediosa...y ante el problema, la mayoria de los codificadores elegirian solo mantener el codigo. Agrava el hecho que muchas empresas se NIEGAN a "gastar" tiempo diseñando y se NIEGAN a tener requerimientos por ESCRITO y actualizar los mismos.

En mi experiencia en varias empresas de desarrollo, es lo que se ve. De hecho en una que estoy de consultor ahora, practicamente a la fuerza he puesto en marcha el manejo de codigo fuente, una base de datos de bugs y hacer releases en un click. Aun estando en el proceso de certificacion ISO 9000, la administracion NO quiere pagar para tener un proceso mejor... no hay herramienta gratuita que soporte todo lo que la ISO exige y que lo haga bien (y si la hay, diganmelo!).

Y sabes? mi persona ha estado en varios simposios de esto, de ISO, de CMM y de calidad. Mi equipo de desarrollo sabe muy bien UML y todo lo demas. Y sin embargo.. no es suficiente.

Por otro lado, ten en cuenta que la mayoria de las personas que usan UML se limitan a hacer diagramas de clases, y los que medianamente entendemos para que sirven los otros, no es que le veamos tanta aplicabilidad. Y estoy hablando de gente con capacitacion.

Pero Delphius, eso es una gran oportunidad. El UML es parte de un proceso, y hacer que tengo un rol importante seria muy bueno, pero es dificil. De hecho Borland, MS e IBM esperan obtener GRANDES dividendos con sus respectivas plataformas que integran todo eso.

En mi opinion, el UML tiene una aplicacion limitada a la hora de diseñar... o sea, haciendo la analogia con la arquitectura, de hecho un plano no lo cuenta todo y hay varios tipos de planos necesarios para hacer un panorama mas completo y aun asi, se requiere de experiencia practica para unirlo todo.

Para mi diseñar un software reune:

1- Una lista detallada y desmenuzada de requerimientos funcionales. Al menos deberian estar los conocidos, porque obviamente muchos no estan.
2- Un cronograma
3- Una lista de errores
4- Una suite de testing
5- Una representacion de a)Las clases b)Los procesos en tiempo de ejecucion y la interaccion y c)Como se comunican las clases

Hacer solo una de esta sin las otras hace el proceso muy debil. De hecho contra la arquitectura creo que es parecido

1- Que es lo que se va a construir y cuales son los recursos
2- El cronograma
3- Los planos