 |
| Imagen de: Picasa Web Albums |
En el mundo de la informática, los clientes e inclusive nuestros Gerentes y Directores, esperan que cuando nos presenten un problema de ingeniería de software estemos en capacidad de responder de inmediato ¿para qué fecha cree usted que podría estar desarrollado y entregado?
Sin embargo, debe tenerse extremo cuidado al proporcionar fechas, pues los desarrollos de software suelen presentar muchos imponderables, que deben ser cuidadosamente analizados.
Una de las peores situaciones que se le pueden presentar a un analistas-programador de software, arquitecto, líder de equipo o Gerente de proyecto, es darse cuenta en la mitad de la ejecución, que actividades críticas no fueron consideradas cuando se planificó y comunicó una fecha de entrega.
En este artículo, se exploran una serie aspectos con frecuencia omitidos, pero que deben considerarse en la planificación de todo desarrollo de software. Van desde los tiempos para aprobaciones de los diseños, integraciones de códigos, instalación de ambientes de prueba, entre otros.
Para ayudar a los analistas-programadores, líderes de grupo y Gerentes de Proyectos de Software en esta tarea, presentamos a continuación las actividades críticas que no deben faltar en un plan de desarrollo de software.
Introducción
La planificación toma tiempo de realizar, tratar de acelerarla es incrementar innecesariamente los riesgos de proyectos de software, los cuales de por sí ya son de alto riesgo debido a los retos que suelen enfrentar.
Las actividades que debe incluir un plan de desarrollo de un software son conocidas por la comunidad informática, Análisis, Diseño, Desarrollo, Pruebas e Implementación.
La secuencia en que se ejecutan puede cambiar dependiendo del enfoque metodológico, si es predictivo, iteraciones planeadas, o ágil. Estas actividades macro esconden aspectos críticos que deben ser anticipados y gestionados para llevar a feliz término el proyecto.
Las actividades expuestas a continuación, deben ser consideradas en la planificación de tiempo o (el cronograma) y de recursos del proyecto, es decir tiempo y esfuerzo de analistas-programadores, analistas de pruebas u otros integrantes.
Lectura recomendada
La Guía del PMBOK 6ta edición en Español
Autor: Project Management Institute
>> Latinoamérica (Amazon.com)
>> España (amazon.es)
Reseña del PMBOK 6ta edición en Español
Las últimas actualizaciones a los fundamentos para la dirección de proyectos definida por el Project Management Institute (PMI). Entre los aspectos novedosos está que cada área de conocimientos incluye una sección dedicada a describir como integrar enfoques ágiles, iterativos y adaptativos al proyecto, mayor énfasis en los conocimientos estratégicos y del negocio, incluyendo información sobre el triangulo del talento del PMI y las habilidades que necesita el gerente de proyectos para tener éxito.
Actividades críticas a incluir en todo plan de proyecto de desarrollo de software
1.- Lapsos de correcciones y aprobación de los diseños de software
Al recibirse un diseño del software, debe asumirse que presentará errores o dudas, por lo que es necesario considerar tiempos para revisarlo, comunicar las correcciones, realizaras y volver a revisar.
Adicionalmente, el diseño debe ser aprobado, lo cual puede suponer enviar un correo o documento físico y buscar las firmas. Entre más larga sea la lista de involucrados, más puede tardar la aprobación. Por supuesto, siempre se podrá comenzar a desarrollar para no retrasar el proyecto, sin embargo, si se solicita algún cambio después podría implicar retrabajo.
2.- Instalación del ambiente de desarrollo
La instalación del ambiente de desarrollo para cada analista programador, así como de los servidores de aplicación, base de datos o de otro tipo compartidos por el equipo es una actividad predecesora obligatoria para comenzar el desarrollo.
Se puede realizar en paralelo con el análisis y diseño, sin embargo, debe tomarse en cuenta que depende de recursos como equipos de computación y personal del área de tecnología e implica configuraciones de aplicaciones, bases de datos y de otro tipo que pudieran tener incertidumbre en su duración.
Adicionalmente, si es un desarrollo complejo con múltiples desarrolladores, podría implicar la habilitación de un controlador de versiones, descarga de las últimas fuentes de código, homologación de fuentes de código y bases de datos con el ambiente de producción.
3.- Dudas sobre los diseños que se presenten durante el desarrollo
No existe el diseño de software que sobreviva intacto la fase de desarrollo, siempre surgirán dudas funcionales y técnicas, sobre las cuales será necesario hacer comunicaciones y esperar respuestas de personas, las cuales, al no estar dedicadas al proyecto, pudieran ocasionar retraso. Por ende, se debe asumir en la planificación que las dudas sobre el diseño se presentarán, asignando tiempo y esfuerzo para su resolución.
4.- Integraciones de código de distintos desarrolladores
Durante el desarrollo, múltiples trabajos podrían estarse realizando en paralelo por distintos analistas programadores en distintas capas (por ejemplo Bases de datos, aplicación y presentación). Cada una de estas partes será probada, pero ¿Qué hay de la integración? y ¿no debemos probar después de integrar?.
Deben contemplarse tiempos para integraciones de código y las pruebas de esa integración antes de entregarlo al equipo de pruebas.
5.- Integraciones de código de otros proyectos
En el punto anterior abarcamos las integraciones de código de un mismo proyecto, pero, ¿qué ocurre si tenemos varios proyectos en paralelo sobre un mismo sistema o aplicación?, o por ejemplo si algún otro equipo de desarrollo realizó una implementación en producción durante la ejecución de nuestro proyecto. Será necesario integrar con la última fuente de código y homologar nuevamente los ambientes de bases de datos.
Asimismo, ¿qué ocurre cuando existen varios proyectos paralelos?, pues debe analizarse la hoja de ruta del conjunto de proyectos, verificando la fecha de implementación en producción, decidiendo en función de esto las integraciones a realizar, tomando en consideración que esto crea dependencias entre proyectos.
6.- Instalación del ambiente de pruebas
El hecho que el producto desarrollado este empaquetado y entregado al equipo de pruebas no significa que estas pueden comenzar, primero se necesita realizar la instalación o despliegue (dependiendo de la tecnología en que se desarrolle) en el ambiente de pruebas.
Si se trata de un ambiente compartido en la organización, esto podría implicar solicitar tiempo al administrador en horario no laborable, realizar la instalación, probar, corregir posibles errores de despliegue, entre otras actividades. Por ende, es recomendable contemplar las mismas en la planificación.
7.- Preparación de pruebas
¿Y qué hay de la preparación de las pruebas?, en cuanto al diseño de casos y recopilación de los datos de prueba. ¿Qué ocurriría si esperamos a que el desarrollo esté entregado para comenzar a hacer esto?, ¿no retrasaría esto el proyecto? Por ende, lo recomendable es contemplar la actividad en la planificación y comenzar a ejecutarla en paralelo con el desarrollo, para que esté terminada al momento de iniciar las pruebas.
8.- Correcciones de errores (bugs)
¿Podemos asumir que la ejecución de pruebas ocurrirá sin errores?, consideramos que no, de hecho, la experiencia indica que algunos errores pueden ser difíciles de analizar y corregir, e inclusive tardar más en ser remediados que la prueba en sí.
Debe considerarse en la planificación los tiempos y recursos (léase tiempo de los analistas-programadores) para corregir estas incidencias. Usualmente, se pueden calcular como una fracción o porcentaje de la ejecución de pruebas.
9.- Cambios de alcance
La teoría del desarrollo de sistemas y de la gerencia de proyectos nos dice que si ocurre un cambio de alcance, el impacto del mismo debe ser considerado en tiempo y recursos, resultando en muchos casos en un incremento del presupuesto y movimiento de la fecha, pero, ¿ocurre así en la realidad?, ¿está dispuesto un cliente final a aprobarle un cambio en la fecha o presupuesto?, ¿Qué ocurre si son muchos cambios de bajo esfuerzo?.
Usualmente este tipo de situaciones resultan en negociaciones con el cliente, en la cual se dicen cosas como, ¿no se realizó una fase de análisis del proyecto?, ¿Por qué es un cambio de alcance, no debió haber sido identificado en esa fase?, ¿No es el trabajo del Gerente de Proyectos el prevenir estas situaciones?
En todo caso, los proyectos de desarrollo de software por su naturaleza intangible están sujetos a tener cambios cuando el cliente los prueba, por ende, ¿Por qué no considerar dichos posibles cambios en la planificación?, (por ejemplo como una holgura para ajustes y modificaciones).
Cabe destacar que los enfoques de desarrollo ágil atiende este tema de forma muy eficiente, al incorporar la elaboración progresiva que permite al cliente realizar cambios a su producto de software.
10.- Período de soporte posimplantación
¿El desarrollo del software termina con su puesta en producción?, ¿qué hay del llamado período de estabilización de la solución?, ¿Quién atiende las dudas de los usuarios con el uso del producto?, ¿Quién evalúa si se están reportando falsos errores?, o ¿Cómo se responde ante un error real?.
En todo caso, y dado que el software por lo general se produce bajo períodos de garantía, es necesario contemplar en la planificación la ocupación de analistas programadores y analistas de pruebas, quienes brindarán soporte durante el período de estabilización. Durante este período, se realizará la transferencia de conocimientos al equipo de soporte de la organización, hasta que esté en capacidad de brindar dicho soporte y termine el período de garantía.
Conclusión
Las actividades que se han mencionado son con frecuencia omitidas en la planificación, sobre todo cuando es preparada de forma apresurada y no se le da tiempo suficiente al desarrollador, al equipo de trabajo y al Gerente de proyectos de analizar todas las premisas, ocasionando la no identificación de todos los recursos y riesgos antes de presentar una fecha de entrega.
¿Y qué opinas tu?, ¿En tu ámbito profesional se da suficiente tiempo para hacer la planeación de proyecto?, ¿Cuáles errores has observado en la planificación?, ¿agregarías alguna actividad a esta lista?. Te invitamos a participar en nuestro foro (en la oficinaproyectosinformatica.blogspot.com) y a suscribirse al blog por los distintos canales, tales como lista de correo, RSS y Twitter.
¿Buscas información de gerencia de proyectos?
¿Quieres obtener completamente gratis y directamente en tu correo electrónico plantillas, artículos y contenidos de Gerencia de Proyectos, entonces suscríbete a continuación.
También puedes seguirnos vía Twitter, Facebook o Linkedin:
Otros artículos en “La Oficina de Proyectos de Informática”
Gerencia de Desarrollo de Software
>> 5 errores comunes de programación
>> Los pasos para resolver incidentes en el período de estabilización de un desarrollo de software
>> Ambientes de pruebas integrales de software: Buenas prácticas
>> Ambientes de desarrollo de software: Buenas prácticas
>> Algunas prácticas de desarrollo de aplicaciones web para asegurar calidad, mantenibilidad, escalabilidad y seguridad
>> Herramientas de software para gestión de proyectos de desarrollo ágil
>> Acciones preventivas para evitar retraso y retrabajo en proyectos de tecnología de información (TI)
>> Las preguntas que debe hacer al encargarse de un proyecto de Tecnología de Información (TI) en ejecución
Aspectos Generales
>> Habilidades interpersonales cada vez más demandadas en los profesionales de Tecnologías de Información
>> Las Habilidades y Conocimientos más buscados en el área de Tecnología de Información (TI)
>> Las reuniones de trabajo: más productividad, menos reuniones
Gerencia de Proyectos
>> Como hacer el seguimiento de los riesgos en proyectos
>> Plantilla para la Gestión de Riesgos en proyectos: Actualización Octubre 2012
Sin embargo, debe tenerse extremo cuidado al proporcionar fechas, pues los desarrollos de software suelen presentar muchos imponderables, que deben ser cuidadosamente analizados.
Una de las peores situaciones que se le pueden presentar a un analistas-programador de software, arquitecto, líder de equipo o Gerente de proyecto, es darse cuenta en la mitad de la ejecución, que actividades críticas no fueron consideradas cuando se planificó y comunicó una fecha de entrega.
En este artículo, se exploran una serie aspectos con frecuencia omitidos, pero que deben considerarse en la planificación de todo desarrollo de software. Van desde los tiempos para aprobaciones de los diseños, integraciones de códigos, instalación de ambientes de prueba, entre otros.
Para ayudar a los analistas-programadores, líderes de grupo y Gerentes de Proyectos de Software en esta tarea, presentamos a continuación las actividades críticas que no deben faltar en un plan de desarrollo de software.
Introducción
La planificación toma tiempo de realizar, tratar de acelerarla es incrementar innecesariamente los riesgos de proyectos de software, los cuales de por sí ya son de alto riesgo debido a los retos que suelen enfrentar.
Las actividades que debe incluir un plan de desarrollo de un software son conocidas por la comunidad informática, Análisis, Diseño, Desarrollo, Pruebas e Implementación.
La secuencia en que se ejecutan puede cambiar dependiendo del enfoque metodológico, si es predictivo, iteraciones planeadas, o ágil. Estas actividades macro esconden aspectos críticos que deben ser anticipados y gestionados para llevar a feliz término el proyecto.
Las actividades expuestas a continuación, deben ser consideradas en la planificación de tiempo o (el cronograma) y de recursos del proyecto, es decir tiempo y esfuerzo de analistas-programadores, analistas de pruebas u otros integrantes.
Lectura recomendada
Autor: Project Management Institute
>> Latinoamérica (Amazon.com)
>> España (amazon.es)
Reseña del PMBOK 6ta edición en Español
Las últimas actualizaciones a los fundamentos para la dirección de proyectos definida por el Project Management Institute (PMI). Entre los aspectos novedosos está que cada área de conocimientos incluye una sección dedicada a describir como integrar enfoques ágiles, iterativos y adaptativos al proyecto, mayor énfasis en los conocimientos estratégicos y del negocio, incluyendo información sobre el triangulo del talento del PMI y las habilidades que necesita el gerente de proyectos para tener éxito.
1.- Lapsos de correcciones y aprobación de los diseños de software
Al recibirse un diseño del software, debe asumirse que presentará errores o dudas, por lo que es necesario considerar tiempos para revisarlo, comunicar las correcciones, realizaras y volver a revisar.
Adicionalmente, el diseño debe ser aprobado, lo cual puede suponer enviar un correo o documento físico y buscar las firmas. Entre más larga sea la lista de involucrados, más puede tardar la aprobación. Por supuesto, siempre se podrá comenzar a desarrollar para no retrasar el proyecto, sin embargo, si se solicita algún cambio después podría implicar retrabajo.
2.- Instalación del ambiente de desarrollo
La instalación del ambiente de desarrollo para cada analista programador, así como de los servidores de aplicación, base de datos o de otro tipo compartidos por el equipo es una actividad predecesora obligatoria para comenzar el desarrollo.
Se puede realizar en paralelo con el análisis y diseño, sin embargo, debe tomarse en cuenta que depende de recursos como equipos de computación y personal del área de tecnología e implica configuraciones de aplicaciones, bases de datos y de otro tipo que pudieran tener incertidumbre en su duración.
Adicionalmente, si es un desarrollo complejo con múltiples desarrolladores, podría implicar la habilitación de un controlador de versiones, descarga de las últimas fuentes de código, homologación de fuentes de código y bases de datos con el ambiente de producción.
3.- Dudas sobre los diseños que se presenten durante el desarrollo
No existe el diseño de software que sobreviva intacto la fase de desarrollo, siempre surgirán dudas funcionales y técnicas, sobre las cuales será necesario hacer comunicaciones y esperar respuestas de personas, las cuales, al no estar dedicadas al proyecto, pudieran ocasionar retraso. Por ende, se debe asumir en la planificación que las dudas sobre el diseño se presentarán, asignando tiempo y esfuerzo para su resolución.
4.- Integraciones de código de distintos desarrolladores
Durante el desarrollo, múltiples trabajos podrían estarse realizando en paralelo por distintos analistas programadores en distintas capas (por ejemplo Bases de datos, aplicación y presentación). Cada una de estas partes será probada, pero ¿Qué hay de la integración? y ¿no debemos probar después de integrar?.
Deben contemplarse tiempos para integraciones de código y las pruebas de esa integración antes de entregarlo al equipo de pruebas.
5.- Integraciones de código de otros proyectos
En el punto anterior abarcamos las integraciones de código de un mismo proyecto, pero, ¿qué ocurre si tenemos varios proyectos en paralelo sobre un mismo sistema o aplicación?, o por ejemplo si algún otro equipo de desarrollo realizó una implementación en producción durante la ejecución de nuestro proyecto. Será necesario integrar con la última fuente de código y homologar nuevamente los ambientes de bases de datos.
Asimismo, ¿qué ocurre cuando existen varios proyectos paralelos?, pues debe analizarse la hoja de ruta del conjunto de proyectos, verificando la fecha de implementación en producción, decidiendo en función de esto las integraciones a realizar, tomando en consideración que esto crea dependencias entre proyectos.
6.- Instalación del ambiente de pruebas
El hecho que el producto desarrollado este empaquetado y entregado al equipo de pruebas no significa que estas pueden comenzar, primero se necesita realizar la instalación o despliegue (dependiendo de la tecnología en que se desarrolle) en el ambiente de pruebas.
Si se trata de un ambiente compartido en la organización, esto podría implicar solicitar tiempo al administrador en horario no laborable, realizar la instalación, probar, corregir posibles errores de despliegue, entre otras actividades. Por ende, es recomendable contemplar las mismas en la planificación.
7.- Preparación de pruebas
¿Y qué hay de la preparación de las pruebas?, en cuanto al diseño de casos y recopilación de los datos de prueba. ¿Qué ocurriría si esperamos a que el desarrollo esté entregado para comenzar a hacer esto?, ¿no retrasaría esto el proyecto? Por ende, lo recomendable es contemplar la actividad en la planificación y comenzar a ejecutarla en paralelo con el desarrollo, para que esté terminada al momento de iniciar las pruebas.
8.- Correcciones de errores (bugs)
¿Podemos asumir que la ejecución de pruebas ocurrirá sin errores?, consideramos que no, de hecho, la experiencia indica que algunos errores pueden ser difíciles de analizar y corregir, e inclusive tardar más en ser remediados que la prueba en sí.
Debe considerarse en la planificación los tiempos y recursos (léase tiempo de los analistas-programadores) para corregir estas incidencias. Usualmente, se pueden calcular como una fracción o porcentaje de la ejecución de pruebas.
9.- Cambios de alcance
La teoría del desarrollo de sistemas y de la gerencia de proyectos nos dice que si ocurre un cambio de alcance, el impacto del mismo debe ser considerado en tiempo y recursos, resultando en muchos casos en un incremento del presupuesto y movimiento de la fecha, pero, ¿ocurre así en la realidad?, ¿está dispuesto un cliente final a aprobarle un cambio en la fecha o presupuesto?, ¿Qué ocurre si son muchos cambios de bajo esfuerzo?.
Usualmente este tipo de situaciones resultan en negociaciones con el cliente, en la cual se dicen cosas como, ¿no se realizó una fase de análisis del proyecto?, ¿Por qué es un cambio de alcance, no debió haber sido identificado en esa fase?, ¿No es el trabajo del Gerente de Proyectos el prevenir estas situaciones?
En todo caso, los proyectos de desarrollo de software por su naturaleza intangible están sujetos a tener cambios cuando el cliente los prueba, por ende, ¿Por qué no considerar dichos posibles cambios en la planificación?, (por ejemplo como una holgura para ajustes y modificaciones).
Cabe destacar que los enfoques de desarrollo ágil atiende este tema de forma muy eficiente, al incorporar la elaboración progresiva que permite al cliente realizar cambios a su producto de software.
10.- Período de soporte posimplantación
¿El desarrollo del software termina con su puesta en producción?, ¿qué hay del llamado período de estabilización de la solución?, ¿Quién atiende las dudas de los usuarios con el uso del producto?, ¿Quién evalúa si se están reportando falsos errores?, o ¿Cómo se responde ante un error real?.
En todo caso, y dado que el software por lo general se produce bajo períodos de garantía, es necesario contemplar en la planificación la ocupación de analistas programadores y analistas de pruebas, quienes brindarán soporte durante el período de estabilización. Durante este período, se realizará la transferencia de conocimientos al equipo de soporte de la organización, hasta que esté en capacidad de brindar dicho soporte y termine el período de garantía.
Conclusión
Las actividades que se han mencionado son con frecuencia omitidas en la planificación, sobre todo cuando es preparada de forma apresurada y no se le da tiempo suficiente al desarrollador, al equipo de trabajo y al Gerente de proyectos de analizar todas las premisas, ocasionando la no identificación de todos los recursos y riesgos antes de presentar una fecha de entrega.
¿Y qué opinas tu?, ¿En tu ámbito profesional se da suficiente tiempo para hacer la planeación de proyecto?, ¿Cuáles errores has observado en la planificación?, ¿agregarías alguna actividad a esta lista?. Te invitamos a participar en nuestro foro (en la oficinaproyectosinformatica.blogspot.com) y a suscribirse al blog por los distintos canales, tales como lista de correo, RSS y Twitter.
¿Buscas información de gerencia de proyectos?
¿Quieres obtener completamente gratis y directamente en tu correo electrónico plantillas, artículos y contenidos de Gerencia de Proyectos, entonces suscríbete a continuación.
También puedes seguirnos vía Twitter, Facebook o Linkedin:
Otros artículos en “La Oficina de Proyectos de Informática”
Gerencia de Desarrollo de Software
>> 5 errores comunes de programación
>> Los pasos para resolver incidentes en el período de estabilización de un desarrollo de software
>> Ambientes de pruebas integrales de software: Buenas prácticas
>> Ambientes de desarrollo de software: Buenas prácticas
>> Algunas prácticas de desarrollo de aplicaciones web para asegurar calidad, mantenibilidad, escalabilidad y seguridad
>> Herramientas de software para gestión de proyectos de desarrollo ágil
>> Acciones preventivas para evitar retraso y retrabajo en proyectos de tecnología de información (TI)
>> Las preguntas que debe hacer al encargarse de un proyecto de Tecnología de Información (TI) en ejecución
Aspectos Generales
>> Habilidades interpersonales cada vez más demandadas en los profesionales de Tecnologías de Información
>> Las Habilidades y Conocimientos más buscados en el área de Tecnología de Información (TI)
>> Las reuniones de trabajo: más productividad, menos reuniones
Gerencia de Proyectos
>> Como hacer el seguimiento de los riesgos en proyectos
>> Plantilla para la Gestión de Riesgos en proyectos: Actualización Octubre 2012
No hay comentarios :
Publicar un comentario