Los sistemas pueden fallar por volumen de datos y/o usuarios no tomados en cuenta al momento del diseño, dado que al haber un volumen alto de puede poner lento el sistema y procesos que te pueden durar 3 min podrían tomar mas de 10 min y esos números son directamente proporcionales a el volumen.
Mayor volumen --> Menor velocidad--> en casos puede ser ineficiente el trabajo o hacerse tedioso
Yo creo que uno de los principales problemas de lo sistemas actuales son los tiempos de desarrollo. Resulta que el cliente siempre quiere el sistema listo lo antes posible, y los arquitectos y programadores, sabiendo que un sistema entregado a menor tiempo se puede cobrar a un alto precio, aceptan esta condición, pero no miden el tiempo real de desarrollo, lo que desemboca en un sistema incompleto, falto de pruebas, mal implementado, entre otras causas Aqui es donde se aplica el famoso triángulo equilatero, donde sus 3 puntos son: Costo, Tiempo, Eficiencia. Si uno aumenta o disminuye uno de los puntos los otros tambien lo haran. por ejemplo un sistema desarrollado en menor tiempo, costara mas o en su defecto sera menos eficiente, para poder mantener el triángulo equilatero.
Mi intervención estará basada según mi experiencia. El que un sistema falle depende de muchos factores: - Usuario con poca pericia (lo que en el argot de analistas llamamos problema capa 8). - El hardware no es lo suficientemente robusto (Poca memoria, almacenamiento insuficiente...) - Obviamente, y siguiendo la idea de Yair, la codificación apresurada hace que en proyectos de gran envergadura queden cabos sueltos y aspectos que no se tomaron en cuenta. Referente al diseño la mala compresión del analista o la poca comunicación entre las partes. - En un país como Venezuela los picos de electricidad ocasionan desconfiguraciones en servidores que nunca pueden ser apagados. - Las actualizaciones de los sistemas operativos hacen que los sistemas requieran actualización para correr bajo nuevas arquitecturas ya que de lo contrario puede que fallen. El 90% de la veces es así en proyectos grandes. Hablo con propiedad ya que en el hotel Eurobuilding (lugar donde laboro) se hizo cambio de maquinas de Win XP a Win 7 y los sistemas han tenido muchos problemas ya que no son compatibles. Esta intervención está dirigida mas a problemas ocasionados por parte de la implementación ya que es mi dia a dia pero en el caso de diseño y programación estoy totalmente de acuerdo con las intervenciones de mis compañeros y pienso que debe haber un equilibrio entre todo para que los sistemas se mantengan en pie y el fallo sea mucho menor
Si estoy de acuerdo con ustedes, pero sabemos que muchos factores pueden causar fallas en los sistemas, un ejemplo tan simple como que el personal de aseo desenchufe una maquina para enchufar una aspiradora, y no la conecte nuevamente hasta algo mas complejo como seria un mal diseño del sistema.
Por eso siempre debemos de hacer un gran esfuerzo para diseñar y desarrollar una aplicación robusta con pruebas que minimice al máximo las fallas que están en nuestras manos prevenir.
Y por eso es muy bueno entregar un manual de funcionamiento de la aplicación incluyendo la parte de troubleshooting dado que allí le podemos colocar ciertas soluciones como revisar si la maquina esta enchufada.
me parece que cuando hablamos de fallas del sistema no podemos hablar de una falla de hardware, me parece q obviamente el hardware es parte del sistema, pero no creo q eso sea parte del problema aqui planteado me parece que estamos hablando mas, de si como dijo Jose de que tan robusto es el sistema, y poder determinar que cosas pueden fallar Ahora cuando hablamos de fallas generalmente hablamos de error de usuarios (desconectar una maquina por error), pero el programador debería preparar su sistema para esa clase de problemas, como? evitando la perdida de información relevante generando un autoSave por ejemplo pero no creo que esa sea una de las causas por las cuales se plantea "una crisis en el horizonte", a mi parecer esto apunta mas a el punto de el aumento exponencial de usuarios, clientes que solicitan desarrollos en menor tiempo, el no cumplir con todas las pruebas necesarias para ahorrar tiempo y dinero, no levantar la información de forma adecuada y completa, y si hablamos de un cambio de sistemas operativos, no darle el mantenimiento de capas necesario en el caso
Los sistemas pueden fallar por volumen de datos y/o usuarios no tomados en cuenta al momento del diseño, dado que al haber un volumen alto de puede poner lento el sistema y procesos que te pueden durar 3 min podrían tomar mas de 10 min y esos números son directamente proporcionales a el volumen.
ResponderEliminarMayor volumen --> Menor velocidad--> en casos puede ser ineficiente el trabajo o hacerse tedioso
Yo creo que uno de los principales problemas de lo sistemas actuales son los tiempos de desarrollo.
ResponderEliminarResulta que el cliente siempre quiere el sistema listo lo antes posible, y los arquitectos y programadores, sabiendo que un sistema entregado a menor tiempo se puede cobrar a un alto precio, aceptan esta condición, pero no miden el tiempo real de desarrollo, lo que desemboca en un sistema incompleto, falto de pruebas, mal implementado, entre otras causas
Aqui es donde se aplica el famoso triángulo equilatero, donde sus 3 puntos son: Costo, Tiempo, Eficiencia. Si uno aumenta o disminuye uno de los puntos los otros tambien lo haran. por ejemplo un sistema desarrollado en menor tiempo, costara mas o en su defecto sera menos eficiente, para poder mantener el triángulo equilatero.
Mi intervención estará basada según mi experiencia.
ResponderEliminarEl que un sistema falle depende de muchos factores:
- Usuario con poca pericia (lo que en el argot de analistas llamamos problema capa 8).
- El hardware no es lo suficientemente robusto (Poca memoria, almacenamiento insuficiente...)
- Obviamente, y siguiendo la idea de Yair, la codificación apresurada hace que en proyectos de gran envergadura queden cabos sueltos y aspectos que no se tomaron en cuenta. Referente al diseño la mala compresión del analista o la poca comunicación entre las partes.
- En un país como Venezuela los picos de electricidad ocasionan desconfiguraciones en servidores que nunca pueden ser apagados.
- Las actualizaciones de los sistemas operativos hacen que los sistemas requieran actualización para correr bajo nuevas arquitecturas ya que de lo contrario puede que fallen. El 90% de la veces es así en proyectos grandes. Hablo con propiedad ya que en el hotel Eurobuilding (lugar donde laboro) se hizo cambio de maquinas de Win XP a Win 7 y los sistemas han tenido muchos problemas ya que no son compatibles.
Esta intervención está dirigida mas a problemas ocasionados por parte de la implementación ya que es mi dia a dia pero en el caso de diseño y programación estoy totalmente de acuerdo con las intervenciones de mis compañeros y pienso que debe haber un equilibrio entre todo para que los sistemas se mantengan en pie y el fallo sea mucho menor
Si estoy de acuerdo con ustedes, pero sabemos que muchos factores pueden causar fallas en los sistemas, un ejemplo tan simple como que el personal de aseo desenchufe una maquina para enchufar una aspiradora, y no la conecte nuevamente hasta algo mas complejo como seria un mal diseño del sistema.
ResponderEliminarPor eso siempre debemos de hacer un gran esfuerzo para diseñar y desarrollar una aplicación robusta con pruebas que minimice al máximo las fallas que están en nuestras manos prevenir.
Y por eso es muy bueno entregar un manual de funcionamiento de la aplicación incluyendo la parte de troubleshooting dado que allí le podemos colocar ciertas soluciones como revisar si la maquina esta enchufada.
me parece que cuando hablamos de fallas del sistema no podemos hablar de una falla de hardware, me parece q obviamente el hardware es parte del sistema, pero no creo q eso sea parte del problema aqui planteado
ResponderEliminarme parece que estamos hablando mas, de si como dijo Jose de que tan robusto es el sistema, y poder determinar que cosas pueden fallar
Ahora cuando hablamos de fallas generalmente hablamos de error de usuarios (desconectar una maquina por error), pero el programador debería preparar su sistema para esa clase de problemas, como? evitando la perdida de información relevante generando un autoSave por ejemplo
pero no creo que esa sea una de las causas por las cuales se plantea "una crisis en el horizonte", a mi parecer esto apunta mas a el punto de el aumento exponencial de usuarios, clientes que solicitan desarrollos en menor tiempo, el no cumplir con todas las pruebas necesarias para ahorrar tiempo y dinero, no levantar la información de forma adecuada y completa, y si hablamos de un cambio de sistemas operativos, no darle el mantenimiento de capas necesario en el caso