Acciones preventivas para evitar retraso y retrabajo en proyectos de tecnología de información (TI) - La Oficina de Proyectos de Informática

jueves, 9 de agosto de 2012

Acciones preventivas para evitar retraso y retrabajo en proyectos de tecnología de información (TI)

Imagen Obtenida de: Picasa Web Albums
Un aspecto importante a la hora en que seamos participes en proyectos de tecnología de información (TI) o desarrollo de software, es que nuestro día a día tomemos acciones preventivas que nos permitan evitar retrabajos y anticipar situaciones que puedan causarnos retrasos en desarrollos y entregas.

En este artículo exploraremos distintas acciones preventivas que podemos tomar en proyectos de TI, que van desde identificar todos los requerimientos de todas las áreas implicadas desde la fase de análisis, hasta prevenir situaciones con los entornos y ambientes de base de datos.

Las acciones preventivas se clasifican por cada fase del ciclo de desarrollo (Análisis, Diseño, Desarrollo e Implantación), independientemente que estas se ejecuten de forma secuencial (metodologías de ciclo de vida tradicional) o en paralelo (como en desarrollo ágil).

>> Más información sobre enfoque tradicional dedesarrollo de software
>> Más información sobre enfoque iterativo /evolutivo
>> Más información sobre desarrollo de software ágil

Acciones preventivas – análisis y diseño de sistemas

  • El análisis y diseño debe involucrar a todas las áreas de la organización. Cuando se desarrolla para grandes empresas suele existir múltiples áreas de negocio y áreas técnicas como por ejemplo pruebas de TI, Base de datos, Sistemas operativos, Seguridad, entre otros. 
  • Partir de una definición general de que está en el alcance y que no, para moderar las reuniones de levantamiento de información. 
  • Realizar minutas de todas las reuniones técnicas, difundir las mismas en el menor tiempo posible después de las reuniones y obtener la aprobación por escrito (vía correo) de todos los participantes. Esto evitará divergencias en el entendimiento de lo que se va a hacer entre las partes.
  • Elaborar el diseño de pruebas durante la fase de análisis y diseño del sistema, para anticipar de esta forma los requerimientos de pruebas con antelación.
  • Determinar con antelación todos los requisitos de documentación, incluyendo planillas de control de cambio, formatos, solicitudes.
  • Determine con antelación los requisitos de usuarios de base de datos y sistema operativo, incluyendo los privilegios de acceso (Por ejemplo SYS, DBA, Consulta, Modificación y eliminación). 
  • Determine con antelación los parámetros de configuración de componentes de software y sistemas (Por ejemplo: Properties, parámetros de Shell Scripts, entre otros). 
  • Identifique los requisitos de estaciones de trabajo del equipo: Identifique por adelantado requisitos de software, plugins, componentes (ej. Maquina virtual Java, Componentes Active X) que necesitan las estaciones de trabajo tanto de desarrolladores como del equipo de pruebas.
  • Cuando se solicité información a terceros, recordar hacer seguimiento a las solicitudes. Registrar una bitácora de pendientes. 
  • Mantener un control de versiones sobre toda la documentación de análisis y diseño. Difundir lo antes posible las últimas versiones y alertar a todo el equipo. 

>> Más información sobre como minimizar riesgos en diseño y desarrollo en paralelo

¿Buscas más información de gerencia informática?

¿Quieres obtener completamente gratis y directamente en tu correo electrónico plantillas, artículos y otros recursos de gerencia informática?, entonces presiona "suscríbete" a continuación.

Suscríbete a la lista de correo electrónico:


Vía FeedBurner, se abrirá una nueva ventana

También puedes seguirnos vía Twitter, Facebook o Linkedin:

  

Acciones preventivas – desarrollo

  • Ante la existencia de múltiples áreas técnicas (desarrollo, implantación, pruebas, base de datos, seguridad), defina con antelación los roles y responsabilidades en las comunicaciones (que comunicar y a quien). 
  • Defina con antelación quien es responsable de los ambientes, por lo general, las áreas de desarrollo, pruebas y producción son cada una responsable de sus ambientes. 
  • Si se está trabajando en paralelo el diseño y desarrollo, como ocurre en proyectos Fastrack, es conveniente realizar reuniones constantes con el cliente, en especial con las áreas técnicas (desarrollo, pruebas, base de datos, producción). 
  • Las cuentas de usuario a utilizar en el desarrollo deben ser homólogos a los que se usaran en ambiente de desarrollo, pruebas y producción, con los mismos nombres, configuración y privilegios de acceso. Aplica para usuarios de sistema operativo, base de datos y aplicación. 
  • Solicitar con antelación la creación de usuarios de sistema y base de datos que sean homólogos a los que se usaran en pruebas y producción, no utilizar otros usuarios con configuraciones distintas. 
  • Los parámetros de configuración (Por ejemplo: Properties, parámetros de Shell script) a usar en el desarrollo deben ser lo más homólogos posible a los de los ambientes de testing y producción, esto evitará errores al transferir el desarrollo a otros ambientes. 
  • Los lineamientos del área de seguridad deben ser considerados en el desarrollo, por ejemplo manejo de contraseñas de usuarios de sistema utilizados por los componentes de software. 
  • Antes de hacer una entrega a ambiente de pruebas o producción, asegurar que la documentación de control de cambios está elaborada correctamente. Buscar el apoyo de las áreas técnicas implicadas (Base de datos, Implantación, Sistemas operativos). 
  • Al instalar en ambiente de pruebas, debe revisarse si existen diferencias en el entorno o base de datos en cuanto a los usuarios del sistema operativo y sus privilegios. 
  • Al instalar en ambiente de pruebas, debe verificarse si existen diferencias en las bases de datos, solicitando y revisando copia de las estructuras de base de datos. 
  • Si existen diferencias entre ambientes de base de datos, es necesario solicitar con suficiente antelación instrucciones respecto a una de las siguientes opciones: Modificar desarrollo para poder instalar en entorno de pruebas u homologar las bases de datos. 

Acciones preventivas – pruebas (Antes de iniciar las pruebas)

  • Cuando las pruebas sean extremo a extremo (end-to-end) deben incluirse casos de prueba de todo componente intermedio, esto incluye configuraciones, Scripts de instalación en base de datos y pruebas sobre componentes de plataforma (por ejemplo transferencias de archivos vía FTP o procesos Batch ejecutados en horas específicas).
  • Solicitar con antelación los usuarios requeridos (Ver sección de análisis y diseño de este artículo) por los componentes desarrollados. Los nombres y privilegio de usuario deben ser homólogos en ambientes de desarrollo, pruebas y producción para garantizar la integridad de las pruebas. 
  • Los usuarios con privilegios especiales (por ejemplo SYS o DBA) deben solicitarse con mayor antelación. 
  • Asegurar que las estaciones de trabajo cumplen los requisitos (Ver sección de análisis y diseño de este artículo). 
  • Solicitar con suficiente antelación los usuarios de la herramienta de gestión de pruebas. 
  • Solicitar con suficiente antelación la creación y configuración de los usuarios de las distintas aplicaciones, bases de datos y sistemas operativos en el ambiente de pruebas. Esto incluye la solicitud de privilegios de acceso. 
  • Identificar y solicitar con antelación la configuración de opciones de funcionalidad, por ejemplo en caso de existir funcionalidades habilitadas o deshabilitadas vía base de datos. ¿
  • En caso de una instalación fallida en ambiente de pruebas, reversar todos los cambios y dejar operativo el ambiente para evitar retrasos en otros equipos de proyectos. 
En conclusión

Esta es sólo una lista inicial de acciones preventivas para evitar retrabajos en proyectos de TI, les invitamos a dejar sus comentarios sobre el artículo y compartir con la comunidad sus acciones preventivas.

Artículos relacionados

>> Las preguntas que debe al hacerse cargo de un proyecto de Tecnología de Información (TI) en ejecución
>> Las 10 recomendaciones a seguir al tomar vacaciones 
>> Plantilla para documentar lecciones aprendidas
>> ITIL y el desarrollo de software

1 comentario :

  1. Interesante post y útil, ya que al final es inevitable tener atrasos en el proyecto, lo cual no ocurre siempre que hay atrasos en alguna tarea en concreto. Por ello creo que para complementar este post es importante saber cuando hay un atraso y cuando no. Comparto un enlace que trata este tema

    http://www.recursosenprojectmanagement.com/esta-el-proyecto-atrasado/

    ResponderEliminar

Pmoinformatica.com," La Oficina de Proyectos de Informática ", es un participante en el Programa de Servicios de Amazon Associates LLC, un programa de publicidad de afiliación diseñado para proporcionar un medio para que sitios web puedan ganar honorarios por la publicidad y enlaces a amazon.com y amazon.es.