Diseño de Sistemas lo que si se debe de hacer...

Desde hace unos cuantos meses he aprendido mucho de lo que no se debe de hacer cuando desarrollamos un sistema. Esto me ha dejado muy en claro el por que México no es una potencia en desarrollo de software, y mucho menos Durango.

Como desarrollador o programador mi trabajo consiste en generar código fuente a partir de diagramas y esquemas cosa que no resulta nada rara, por el contrario, es lo que se ve en todo el curso de la carrera. Sin embargo cuando sales a la vida laboral en México, te topas con que la visión que tienen los empresarios con respecto a las tecnologías de la computación es muy pero muy errónea, la ven como un gasto, en vez de una inversión. No comprenden que automatizando sus procesos les generara una mayor ganancia, debido a la reducción de tiempos. Esto también hace que cuando contraten o requieran de la elaboración de algún sistema computacional, crean que es como hacer papas fritas o una cosa sin chiste, que solamente es picarle a la computadora. Por esa razón suelen esperar que los sistemas estén listos en marcos de tiempo que resultan ciertamente risibles, que de ninguna manera se apegan a la realidad. Por estas y muchas otras razones el mercado mexicano de la industria de tecnologías de la información se ha tenido que moldear, es decir apegarse a todas aquellas aberraciones que suelen tener las empresas.

Todo esto nos ha llevado a tener jefes que ponen metas muy irreales, y en muchos casos a abandonar todas las buenas prácticas del desarrollo de software.

Los Cambios.

Por ahí se comenta que todos los cambios son buenos, y si estoy de cuerdo, puesto que la misma naturaleza nos ha enseñado a lo largo de los milenios que nada es o puede quedarse estático, que siempre habrá un cambio constante y muy posiblemente eterno. Los sistemas informáticos y las computadoras no son la excepción, de lo contrario aun continuaríamos utilizando Windows 1.0 o tendríamos computadoras de bulbos ocupando algunos cuantos cientos de metros cuadrados.

Cuando se comienza a desarrollar un sistema, hay que ser consientes de que siempre habrá cambios por parte del cliente, esto es lo más normal del mundo. Tal vez cuando el encargado de producción tenga una entrevista con el analista, le comente la forma en que ellos realizan un proceso especifico, pero en la semana descubre o nota que si se hiciera de otra manera, sería mas eficiente, o simplemente se da cuenta de que omitió un paso o de plano que metió las patas y le dijo mal algún paso al analista. Entonces le hace una llamada al analista para que este realice los cambios pertinentes en el análisis. En este estado temprano, los cambios no tienen una repercusión tan grande, aunque si ya se esta terminando con el análisis y se pide un cambio radical o estructural muy fuerte, entonces se tendrá que volverá  hacer casi todo de nuevo. Una vez que se concluye con el análisis viene el tiempo del diseño, en el cual se toma en cuenta el resultado del análisis para formar el esbozo del sistema. En esta parte el sistema su existencia aun es meramente teórica, ya que solo existen en diagramas y esquemas, en casos de uso, diagramas de clases, etc. En esta parte del ciclo de vida del sistema, los cambios tienen un impacto mucho mayor,  y dependiendo del los riesgos que se pudieran correr en el sistema, se decide si se hacen dichos cambios o no.

Podria pasar horas hablando de esto, pero creo que por hoy es suficiente.
Les dejo una pequeña presentación de siseño de sistemas.



   





flaaaaaaa