|
|
 |
 |
|
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
12-04-2005
|
||||
|
||||
¿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
12-04-2005
|
||||
|
||||
|
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
16-04-2005
|
||||
|
||||
|
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
16-04-2005
|
||||
|
||||
|
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
17-04-2005
|
||||
|
||||
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
18-04-2005
|
||||
|
||||
|
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.
|
|
#7
23-04-2005
|
||||||||
|
||||||||
|
Muchas gracias.... mas dudas
Gracias por tu enriquecedor aporte mamx, me has dejado sin palabras... bueno casi sin palabras.
Pensaba que esto no sería productivo ni enriquecedor, pero resulto todo lo contrario: aprendí de tus escritos algo que yo no veía: la práctica y la visión real. Lo que me ha pasado es que hasta el momento no tuve oportunidad de ver como es la actividad en una empresa/consultora en forma práctica, sino más bien en un ambiente controlado y simulado durante las horas de clases. Dentro de poco tiempo tengo que ir a realizar una práctica laboral en una empresa muy reconocida en Salta (Argentina), y lo bueno del puesto (si es que me lo dan) es que voy a tener que ver cómo elaborar las políticas, ver el desarrollo de la actividad, controlar, analizar su ritmo, su cultura, etc... etc... en pocas: Analizar el proceso productivo. Espero que en esta práctica pueda ver lo que tu brindaste a traves de este hilo. Veo que tu experiencia en el ámbito te ha permitido comprender muy bien a lo que me voy a enfrentar dentro de unos años (¡Que pensamiento tan optimista!). He leído los enlaces que has expuesto y me gustó muchísimo su contenido. Me tomé el tiempo (obligadamente por cuestiones de salud) para analizar y comprender lo que es realmente la Ingeniería de Software, y me gusta mucho... y estoy más decido que nunca que quiero especializarme en ello. Bueno, disculpa pero tengo algunas opiniones, que hacerte. Mas que opiniones son dudas: Cita:
Decir tendencia mundial, a mi me suena algo exagerado. No creo que en varios lugares sea así, para mí esto de "Programación sin análisis" sólo se produce en aquellos lugares en donde se valora (y por tanto tienen poder de mercado, de mano de obra, herramientas, conocimientos, y disponibilidades) la programación rápida y en donde el software tiene ciclos de ciclo de vida de entre tres y seis meses. Es decir que la tendencia a elaborar productos a la máxima velocidad y donde lo que vale es el tiempo ante del análisis es en países desarrollados: el Hemisferio Norte (y estoy siendo generoso). En el hemisferio sur no creo que sea así la cosa: ¡América del Sur apenas está entrando en el mercado! Cita:
Cita:
¿Entiendes mi punto de vista? Lo que tu manifiestas, es muy aplicable (de hecho lo obvio es que sea así) para aquellas empresas que tienen dominio, experiencia y poder. ¿Que hay para las otras?¿A que recurren? Cita:
Si no se pone orden a lo enseñado, obvio que no sirve de nada aplicar UML. Cita:
Que existan las herramientas para obtener UML desde el código, se debió (a mi entender) a la falta de cohesión que yo ya he comentado, mas que a ayudar a la optimización/automatización. ¿Realmente es necesario buscar herramientas automáticas para desarrollar el análisis (obvio, descartando el Unit Testing)? Cita:
Cita:
Cita:
Claro que UML es parte de un proceso. La ingeniería de Software evoluciona, y si... UML es sólo una de las tantas herramientas que hay. A lo que voy es que no es que UML no sirva, sino que hace falta sacarle mucho mas provecho. Por eso es que busco una metodología/lenguaje, ofrecer lo que UML no puede ofrecer al 100%. Lo que estan haciendo Borland, MS e IBM es dar una solución parcial y rápida al asunto: ¿Que crees que pase cuando se descubra que sus plataformas ya no sirvan?¿Haran otras?¿No crees que resulte mas barato hacer una metodología/lenguaje que sea mas sutil, flexible a los cambios, evolutiva y con la capacidad de ampliarse; antes que gastar más en diseñar plataformas? Se que lo que pretendo es difícil, ¿imposible? no lo se. Otra cuestión es como hacer que lo que pretendo realizar sea reconocido y aceptado por todos. Última edición por Delphius fecha: 23-04-2005 a las 21:30:27. Razón: corrección de etiquetas
|
|
#8
28-08-2010
|
||||
|
||||
|
5 años despues... GRACIAS por compartir sus puntos de vista, experiencias y conocimientos en este tema.
me lo volveré a leer mañana con menos sueño... 
__________________
Buena caza y buen remar... http://mivaler.blogspot.com
|
|
#9
28-08-2010
|
||||
|
||||
|
No me había dado cuenta de la fecha
 No recuerdo haber visto este tema, qué pena. Pero por si acaso el amigo Delphius sigue todavía dándole vueltas al asunto, yo soy partidario de una metodología "propia". Cuando iniciamos un nuevo proyecto lo que hacemos es tomar notas muy claras y detalladas de TODO el programa, hablamos sobre cada cosa que pueda surgir, de cada campo, de qué tipo de ser, por qué, qué casos pueden darse que no sean "los normales", qué problemas y beneficios, etc. O sea, el análisis y diseño es primordial, obligatorio, necesario, decisivo, capital, principal, básico, crucial, fundamental... a la hora de desarrollar un software, es como los planos de un arquitecto que tienen que estar listos antes de hacer el edificio. En mi experiencia puedo poner un ejemplo de proyecto: Anáilsis y diseño 3 meses Desarrollo del programa hasta tener una versión funcional: 4 meses Finalización y entrega del mismo: 2 meses. O sea, de 9 meses total, los 3 primeros fueron de análisis y diseño. Estoy de acuerdo en muchísimas cosas que ha comentado el amigo mamcx, salvo en uml, me parece que es un embrollo terrible y estoy convencido que desaparecerá.
__________________
 La otra guía de estilo | Búsquedas avanzadas | Etiquetas para código Únete al grupo Teaming clubdelphi | Colabora mediante Paypal
|
|
#10
28-08-2010
|
||||
|
||||
|
¡Hola!
Vaya que se han puesto a revivir un hilo viejo. Ya estaba acumulando polvo  Les comento que con el tiempo me di cuenta de que es inútil intentar buscar el modo de formar un nuevo lenguaje genérico... lo único que veía es que estaba reinventando la rueda. En estos últimos años he cambiado la forma de ver esto, al comienzo iba con la idea de que se empleaban paradigmas puros como USDP pero luego empecé a darme cuenta que resulta mucho más valioso el conseguir un proceso que vaya madurando y que sea constante. Este proceso se establece y se desarrolla en base a la propia experiencia del equipo por tanto es un modelo único y propio. Es mucho más probable un enfoque mixto de diversos paradigmas, y agregarle condimentos propios... a esa conclusión he llegado. Después de todo en realidad los paradigmas de desarrollo no establecen paso a paso como han de hacerse las cosas sino más bien que PROPONEN un esquema o marco de trabajo en general y en como han de ordenarse las macro-actividades. Las actividades reales se definen teniendo en cuenta cada proyecto en forma particular. Las herramientas con que cuenten es de menos, mientras con ellas puedan llegar al producto final. Disculpa que te lleve la contraria Casimiro, pero al igual que Mario considero que UML llegó para quedarse. No va a desaparecer... más bien evolucionará, de no ser ser así no existiría UML 2.0 y tengo entendido que ya están en proceso de borrador de 2.5. UML está hecho para quienes deseen hacerlo. No a todos les gusta, ni les resulta. En lo particular considero que es una buena herramienta de trabajo. No es fácil adoptar UML, sobre todo si uno lleva años sobreviviendo sin él. Debe haber una total puesta de conciencia: si vas a utilizarlo, utilízalo bien sino déjalo. Esta misma idea va para cualquier otra cosa: si vas a encarar un proceso de control de versión hazlo bien, no a medias... sino mejor ahórrate el trabajo. El cambio no debe hacerse obligadamente brusco, puede ser gradual. Pero la idea tras esto es que si uno quiere adoptar una herramienta que la use, pero no porque quiera probar si con ello tendrá más suerte y logrará aumentar la productividad y la calidad... sino porque tiene la confianza suficiente de que con su uso su trabajo le resulta ventajoso. Con el tiempo, consciente o inconscientemente, uno va desarrollando un proceso gradual y toma nota de las armas que les agrada y le resulta útil. A mi me gusta UML, defiendo su uso. He estado llevando (y llevo) un proceso de aprendizaje y de maduración. Del mismo modo estoy en una fase en donde estoy aprendiendo y asimilando ideas de como ordenar la casa: en lo que hace a organización de actividades, de documentación, de testeo, etc. No interesa si haces código o UML primero, eso dependerá de las necesidades y la forma en como uno encara el proyecto. El asunto está en que si utilizas UML, le saques el provecho. Y no es para volverse loco haciendo mil diagramas, no... así no es... ¡haz lo que consideres que te ayudan a aclarar ideas! Ni más ni menos. Al comienzo tenía la idea de que todo debía hacerse bien formal, estructurado, rígido, con pasos bien definidos... "que debía hacerse si o si de esa forma". Pero luego empecé a relajarme de esta idea... y entiendo que no necesariamente hay que hacer todo y de todo. Actividades más sueltas, ligeras, flexibles, dinámicas pueden ofrecer mejores resultados sin estar presionando demasiado. Lo importante es lograr un proceso que nos lleve a los resultados, empleando las herramientas que nos aporten utilidad. Saludos,
|
|
#11
28-08-2010
|
||||
|
||||
|
Amigo Delphius, te aconsejo que leas esto (por qué uml no sirve) cuando puedas, es de Javier Smaldone, un paisano tuyo al que admiro bastante.
Yo también andaba con la idea de aprender a usar uml, lo pedían en todos los trabajos que veía, debe ser algo fabuloso... pensé. Pero estuve echándole un vistazo, haciendo pruebas, leyendo documentación, etc. y me parecia que algo no encajaba "con la vida real". La lectura de ese documento me hizo desistir de uml
__________________
La otra guía de estilo | Búsquedas avanzadas | Etiquetas para código Únete al grupo Teaming clubdelphi | Colabora mediante Paypal
|
|
#12
28-08-2010
|
||||
|
||||
|
Bueno, desde entonces aplico casi al 80% todo lo que dije.
Ahora sigo mas bien las ideas de http://gettingreal.37signals.com/. Para lo de los bugs/ideas estoy usando www.pivotaltracker.com y la verdad es muy intuitivo. Junto a la metodologia scrum (lo mas importante: Se planea a maximo 1/2 semanas al futuro). Al iniciar estoy haciendo wireframing & sketchs basicos en un tablero de esos que se escriben con marcador. Sin embargo, creo que este metodo funciona mas para quienes creamos productos que no son tomados de un cliente (o sea, creamos productos desde 0 sin consultar a nadie). Para cuando es un desarrollo a la medida, no se que tan valido sea...
__________________
El malabarista.
|
|
#13
28-08-2010
|
||||
|
||||
|
Cita:
Se que no debería sacar conclusión apresurada pero me voy a aventurar el porqué UML no funciona (y es en parte algo de lo he dicho en el post anterior): UML, como cualquier otra herramienta de trabajo, funciona si uno le pone trabajo y le da valor agregado. Está consciente de ello, puede sacarle provecho. Si uno no lo toma con total seguridad, seriedad y dedicación entonces... ¿de que manera puede llegar a sacar una buena conclusión? Saludos,
|
|
#14
29-08-2010
|
||||
|
||||
|
Cuéntame cuando lo leas
__________________
La otra guía de estilo | Búsquedas avanzadas | Etiquetas para código Únete al grupo Teaming clubdelphi | Colabora mediante Paypal
|
|
#15
29-08-2010
|
||||
|
||||
|
Hola,
Bueno, me he leído el artículo... es un tanto viejo. Con todo respeto amigo, si yo fuera el profesor de Javier lo mando a primer año de la carrera.... ¡no pudo haber dicho lo que dijo! Confundir y mezclar UML con el Proceso Unificado es... no se, no se me ocurren palabras. Admito que es común equivocarse cuando uno recién está estudiando el tema... pero... de alguien que ya lo conoce y lo ha estudiado... ¡no tiene perdón! De allí en adelante no tiene sentido seguir avanzando... el Mencino en sus comentarios lo ha puesto muy en claro. Quizá de una forma un tanto brusca, pero en fin... aclara todo... no tengo más que corregir porque el se encargó de explicar punto a punto los temas. Hay que tener en cuenta que la carta del dichoso estudiante también se ha expresado teniendo como base a UML 0.8 y 0.9 cuando recién se estaba formalizando... inicialmente tuvo sus fallas, lo reconozco, pero en la 1.0 ya salio maduro y tuvo una amplia revisión en la 1.5. Al día de hoy quizá su opinión al respecto ha cambiado. El artículo de Javier es del año 2006... para ese entonces ya estaba la versión 1.5... Es totalmente incongruente que haya dicho semejante cosa. Quizá Javier sepa mucho, pero en ese artículo orinó muy fuera del tarro, con todo respeto. UML es muy bueno, si alguien lo usa y aprende a usarlo. Habrá gusto para todo, si alguien lo usa y le sirve, perfecto... si alguien prefiere no utilizarlo y le va bien... perfecto. Esto vengo diciendo desde hace dos post. Pero de aquí no me venderán la idea de que no sirve. Por ello digo, y sostengo, con toda seguridad, de que uno debe ir encontrando las herramientas que le sean de ayuda. Admito que UML ofrece un amplio abanico de diagramas, una semántica rica y eso lo puede hacer parecer bastante complejo y amplio pero el propósito de ello es brindar la mayor posibilidades de expresión de las ideas. Ideas que nacieron para ayudar al programador. Luego queda en el programador en saber elegir cuando, como y cuanto utilizarlas. Dicho sea de paso, UML es lo suficientemente flexible como para no indundar de redundancias a nuestros diagramas. Muchos elementos de los diagramas son opcionales, y se le deja la posibilidad al diseñador de utilizarlos cuando este lo crea conveniente para aclarar algunos puntos que pueden introducir ciertas ambiguedades. UML quizá no sea perfecto, pero es una herramienta más que uno está en la absoluta libertad de usarla o no. Si Javier, en el momento de escribir ese artículo no lo ha entendido, es problema suyo. Me falta terminar de leer los últimos comentarios, voy por el comentario de Sam del 25 de junio del 2008... voy a ver si ha respondido a sus críticas. Lo siento Casi si te molesta que haya tirado algunos palos a esa persona que estimas amigo. Saludos,
|
|
#16
29-08-2010
|
||||
|
||||
|
Cita:
Yo te considero amigo... aunque te guste windows
__________________
La otra guía de estilo | Búsquedas avanzadas | Etiquetas para código Únete al grupo Teaming clubdelphi | Colabora mediante Paypal
|
|
#17
29-08-2010
|
||||
|
||||
|
Cita:
Respecto a Windows... bueno, no se si me gusta... pero es el que me presentaron y me resulta sencillo de utilizar. Quizá si me hubieran introducido al mundillo de la informática con Linux la cosa posiblemente hubiera sido distinta la cosa. Tengo cuentas pendientes de aprender Linux, que tarde o temprano, tengo que aprender a utilizarlo... en lo personal y profesional. Saludos,
|
|
#18
29-08-2010
|
||||
|
||||
|
Cita:
y se usaba en las medianas empresas como sustituto "barato" de los mainframes porque era mucho más económico. Si se le puede llamar barato a algo así como 20.000 euros de hace 25 años  .Después me fui moviendo entre OS9, amigaOS (estilo mac), CPM y varios sistemas similares a Unix, hasta que llegué al propio Unix. Cuando conocí el MSDOS me pareció "simpático", era una especie de versión muy reducida de un sistema Unix de aquella época, no tenía casi nada, era lo más básico que podía tener para funcionar, monousuario, monotarea, sólo manejaba 640 Kb, discos de 20 Megas, sin gráficos, sin sonidos, sin colores, sin nada Luego llegó windows y de entrada no me gustó todas las máquinas donde se instalaba windows, no sé lo que les pasaba, pero se convertían de golpe en cacharros leeeeeeentos que no paraban de dar errores incontrolables e incomprensibles Acabé odiando windows Por eso, al principio de usar Linux lo hacía siempre sin entorno gráfico, me costó mucho dejar la consola porque me daba la sensación de que iba a "petar" por todos lados... pero no, por suerte no tiene nada que ver Cita:
__________________
La otra guía de estilo | Búsquedas avanzadas | Etiquetas para código Únete al grupo Teaming clubdelphi | Colabora mediante Paypal
|
|
#20
24-09-2010
|
|||
|
|||
|
Cita:
Cita:
|
|
|
|
 |
|
Mode Lineal
