FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
Ver Resultados de Encuesta: ¿Que metodología/Lenguaje usa para el análisis y diseño? | |||
Analisis Estructurado Moderno | 6 | 25,00% | |
UML/USDP | 6 | 25,00% | |
Una "propia" | 11 | 45,83% | |
Otra | 3 | 12,50% | |
Encuesta de Elección Múltiple. Votantes: 24. Tú no puedes votar en esta encuesta |
|
Herramientas | Buscar en Tema | Desplegado |
|
#1
|
||||
|
||||
¿Que metodologías usas para el analisis y diseño?
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. |
#2
|
||||
|
||||
Cita:
Cita:
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....
__________________
El malabarista. |
#3
|
||||
|
||||
Gracias por tu aporte
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. |
#4
|
||||
|
||||
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..
__________________
El malabarista. |
#5
|
||||
|
||||
Ya veo...
Cita:
¿Entonces para que gastaron años estos 3 locos si nadie la usa desde un principio? Cita:
Cita:
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? |
#6
|
||||
|
||||
Cita:
Cita:
Cita:
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... Cita:
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
__________________
El malabarista. |
|
|
|