viernes, 20 de diciembre de 2013
viernes, 13 de diciembre de 2013
Recomendaciones para la implementación de una solución
![]() |
La fase de implementación o de transicición puede ser más complicada de lo que aparenta en la planificación. Pero hay recomedaciones que pueden ayudar y que los gerentes deben tomar en cuenta |
Siendo así de incierta, la fase de implementación tiene una particular relevancia de la que es conveniente estar conscientes: hasta que no logre su cometido los usuarios no sentirán (y con razón desde su perspectiva) que el trabajo de desarrollo fue realizado, porque, para todo efecto práctico, una solución que no está operativa es una solución que no existe.
Ante esta complejidad podemos preguntarnos si se puede hacer algo para disminuir los riesgos de tener sorpresas durante la fase de transición. La respuesta es que si, que si bien nunca se pueden eliminar totalmente los riesgos, si se pueden minimizar si se realizan cinco cosas que un gerente debe recordar siempre al momento de planificar la implementación dentro de un proyecto.
Se trata de cinco recomendaciones básicas que podemos hacer para la fase de transición. En esta oportunidad las enumeraremos e introduciremos muy brevemente y dejaremos para siguientes ocasiones la ampliación con más detalles. Las recomendaciones son:
- Establecer explicitamente los criterios de validación
- Validar la aplicación en el servidor de desarrollo
- Comenzar la transición en forma temprana, antes de concluir la construcción.
- Hacer la transición en dos etapas: primero a un servidor de preproducción y luego al servidor de producción
- Considerar que algunos ajustes pueden ser hechos durante la etapa de producción
Establecer explicitamente los criterios de validación
Tener claro los criterios que debe cumplir la solución construida para poder considerar la tarea realizada elimina subjetividad en las decisiones y una peligrosa fuente de malos entendidos entre las personas involucradas.
Tener claro los criterios que debe cumplir la solución construida para poder considerar la tarea realizada elimina subjetividad en las decisiones y una peligrosa fuente de malos entendidos entre las personas involucradas.
Validar la aplicación en el servidor de desarrollo:
Cada cambio de ambiente operativo introduce nuevos posibles puntos de falla e involucra otras personas por lo que es importante tener los criterios de aceptación bien definidos antes de pasar de un ambiente de trabajo a otros.
Comenzar la transición en forma temprana, antes de concluir la construcción:
Hay tareas de transición que pueden hacerse cuando aún se está construyendo y resulta recomendable realizarlas así, cada vez que sea posible.
Hacer la transición en dos etapas: primero a un servidor de preproducción y luego al servidor de producción:
Cuando no hay ambientes de preproducción en las instituciones hay más riesgos. Cuando los hay, se debe usarlos sistemáticamente.
Considerar que algunos ajustes pueden ser hechos durante la etapa de producción:
No se debe jugar al todo o nada. Es importante siempre un poco de flexibilidad en el camino que conduce a una transición plena al ambiente de operaciones final.
Estas cuatro recomendaciones básicas merecen comentarios adicionales. En siguientes oportunidades ampliaremos los detalles…
viernes, 6 de diciembre de 2013
La implementación de una solución
![]() |
Llevar una aplicación desarrollada al ambiente de producción es una tarea que luce simple pero que puede ser bastante compleja |
Con toda una fauna diversa de variables de hardware y de software, de capas y de interdependencias, el hacer que una aplicación de mediana complejidad trabaje en un segundo servidor, en el ambiente de producción de la institución de destino, es un trabajo en el cual pueden surgir imponderables que en ocasiones pueden hacer que una tarea supuesta a realizarse en horas se tenga que realizar en días, incluso en semanas, y luego de vencer toda una serie de dificultades.
El origen de los problemas tiene que ver con que el ambiente de desarrollo, en el cual trabajan los constructores nunca es exactamente igual al ambiente final en el que la solución desarrollada debe operar. La implementación no es copiar archivos, generar las condiciones iniciales en las bases de datos y configuraciones de la aplicación y pulsar un icono de invocación. Muchas veces es así la teoría, pero la práctica puede ser distante de ese desiderátum.
Todos los sistemas tienen versiones y subversiones, las condiciones de uso de una plataforma operativa cambian después que se han instalado y desinstalado capas de software, los discos se llenan, las plataformas de producción pueden implicar múltiples servidores con necesidades adicionales de establecimiento de permisos en ellos, hay cortafuegos y antivirus que pueden están presentes en producción y no haber sido considerados durante el desarrollo, los estándares de la industria al final dependen de sus implementaciones y esto hace que no todos los supuestos estándares siempre se comporten consistentemente, algunos servidores pueden requerir de pasos de configuración que los implementadores no tienen registrados en sus procedimientos, el ambiente de producción tiene una historia previa que es muy diferente de la de los ambientes de producción, la ingenuidad de algunos técnicos los lleva a veces a pensar que un cambio en la subversión de un paquete es algo trivial que debe resultar irrelevante, la burocracia administrativa de la red de destino puede marcar pautas que generan retrasos, en fin, cualquier variable ignorada o de apariencia intrascendente en una planificación puede saltar al momento de implementar lo que ya está desarrollado.
Lo triste del caso es que para los usuarios finales y las contrapartes de los desarrolladores la solución no existe si no está implementada, por muy grande que haya sido el trabajo de los constructores y por muy completa y eficiente que haya sido la fase de desarrollo.
Los componentes básicos de una aplicación moderna incluyen interacciones con el sistema operativo, el sistema de archivos, el sistema de gestión de bases de datos, el servidor de Web, el o los servicios de páginas Web dinámicas, el o los sistemas de mensajería y el uso de determinados clientes Web. Todo ello son posibles puntos que podrían generar dificultades al momento de hacer la transición de una aplicación desarrollada al ambiente de producción. Debido a lo señalado el trabajo de hacer una transición desde el ambiente de desarrollo al de producción es una fase delicada, compleja y llena de posibles puntos de fallas, por lo que tendremos que hablar más sobre ella…
Suscribirse a:
Entradas (Atom)