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:
|
Empezado por mamx
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.
|
Yo siempre, desde que tuve Lenguajes I, cada vez que se me ha dicho que "hagan este software", he buscado la manera de analizar y comprender muy bien lo que debe hacer y no lo que debo hacer antes de sentarme a programar. ¿Esto cambiará cuando entre a trabajar a alguna empresa?
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:
|
Empezado por mamx
Precisamente, porque nadie lo hace y por eso Rational es una empresa que gana millones de dolares vendiendo un modelo, unas herramientas y consultorias.
|
Cita:
|
Empezado por mamx
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...
|
Rational es Rational, y no cualquier empresa tiene para pagar lo que ofrece Rational. ¿Que hay de aquellas empresas que apenas tienen lo necesario para sobrevivir? Si es muy difícil que éstas apliquen UML, pero si quieren tener un producto de calidad que pueda competir lo mas seguro es que busquen la manera de llegar a ello, ¿A que recurren si no tienen experiencia?Lo más seguro es que tiendan a usar algo comprobado: UML/USDP un poco de CMM o MSF, no creo que se las pasen intentando poner a diseñar un método propio ya que en definitiva esto les terminan perjudicando (tanto en dinero, como en tiempo).
¿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:
|
Empezado por mamx
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.
|
Tienes razón, la enseñanza no es muy buena. Precisamente por ello, lo que mejor aprendí es lo que investigué por cuenta propia más que por lo que me enseñaron. ¿De quién es la culpa? Pues tanto del establecimiento educativo, de los profesores, de los alumnos, de todos. Si se desea que hayan PROFESIONALES, todos deben poner el 200% de su ganas y fuerzas para conseguirlo. El mayor problema no es que se enseña mal, sino que el estudiante aprende mal (sin olvidar de que es este quien debe poner el máximo empeño, el esfuerzo). No olvidemos también que son los estudiantes quienes deben exigir que se les enseñe bien. Te doy un ejemplo que yo he vivido: En la facultad de ingeniería e informática de mi universidad no se tenía un concurso de profesores desde hace años, y los mismos se limitaban a enseñar menos que lo básico. ¿Que hicimos? Exigimos que se llamen a concursos, que se cambien a los profesores, que las exigiencias sean más duras. Hoy, me siento orgulloso de ser parte del equipo que está haciendo que se enseñe como se debe en una universidad. Si muchos estudiantes (los ingresantes) se están quejando de las exigencias, pero es que hacía falta una mano dura.
Si no se pone orden a lo enseñado, obvio que no sirve de nada aplicar UML.
Cita:
|
Empezado por mamx
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.
|
Precisamente para ello está UML, para impedir que haya varios estilos. Que haya algo que todos entendamos. Volviendo a lo anterior, si los futuros profesionales han aprendido a organizarse como se debe, aplicar UML desde un principio resulta más útil.
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:
|
Empezado por mamx
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.
|
Obvio, Nadie dijo que es fácil, de hecho nada lo es. Yo nunca dije que sea fácil, es más la poca práctica que tuve me ha vastado para darme cuenta de que esto requiere de dedicación de equipo, tiempo, organización y muchas cosas más.
Cita:
|
Empezado por mamx
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.
|
Entiendo bien que es tedioso, pero es NECESARIO. Si las empresas quieren tener productos de buena calidad, dentro de sus políticas DEBERÍAN figurar lo que tu expresas. ¿Entonces de que sirve que pongan ganas en buscar algo que no figuran dentro de sus planes?
Cita:
|
Empezado por mamx
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.
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.
|
¿No es suficiente o es que les cuesta sacarle provecho?
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.