10 actividades crÃticas a incluir en todo plan de desarrollo de
Transcription
10 actividades crÃticas a incluir en todo plan de desarrollo de
Facultad de Ciencias Naturales e Ingenierías Tecnología en Desarrollo de Sistemas Informáticos Planeación de Sistemas Informáticos Página 1 de 5 TALLER 1. 2. 3. 4. En grupos de tres personas. Realice la Lectura la lectura que se encuentra a continuación. Hagan una análisis de las actividades y discutan cuales consideran de mayor relevancia. Seleccione 5 que ustedes consideren de mayor importancia y justifique su Respuesta. 10 actividades críticas a incluir en todo plan de desarrollo de un software Tomado de: http://www.pmoinformatica.com/2012/10/10-actividades-criticas-incluir-en-todo.html 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. Estos aspectos 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. Ing. Karina Ramírez Duran [email protected] Facultad de Ciencias Naturales e Ingenierías Tecnología en Desarrollo de Sistemas Informáticos Planeación de Sistemas Informáticos Página 2 de 5 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 analistasprogramadores, analistas de pruebas u otros integrantes. 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. Ing. Karina Ramírez Duran [email protected] Facultad de Ciencias Naturales e Ingenierías Tecnología en Desarrollo de Sistemas Informáticos Planeación de Sistemas Informáticos Página 3 de 5 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 Ing. Karina Ramírez Duran [email protected] Facultad de Ciencias Naturales e Ingenierías Tecnología en Desarrollo de Sistemas Informáticos Planeación de Sistemas Informáticos Página 4 de 5 ¿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 analistasprogramadores) 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). Ing. Karina Ramírez Duran [email protected] Facultad de Ciencias Naturales e Ingenierías Tecnología en Desarrollo de Sistemas Informáticos Planeación de Sistemas Informáticos Página 5 de 5 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. Ing. Karina Ramírez Duran [email protected]