9 Pasos para un buen y efectivo manejo de un proyecto de desarrollo de software

Con una detallada propuesta y un competente jefe de proyecto para guiar la iniciación del desarrollo del software, existe otro importante elemento dentro de una organización que puede ser muy útil cuando se comienza con un proyecto como estableciendo pasos específicos. Existe una colección de normas prácticas para aprovechar un proyecto de desarrollo de software, establecido por dos profesores universitarios y consultores de negocio con destreza especializada en computación, ingeniería, y ambientes generales de negocio. El Dr. Gordon Scott Gehrs y el Dr. Dorota Huizinga establecen nueve pasos claves para considerar llevar a cabo en un proyecto de desarrollo de software.

Paso1: Descubrir las necesidades de los stakeholders

Entrevistar a los stakeholders con el propósito de descubrir si sus necesidades específicas existen, identificar su necesidad exacta, y determinar si el proyecto propuesto puede factiblemente entregar el desarrollo del software esperado.

Paso2: Analizar y determinar los requerimientos

Un apropiado análisis debería consistir de las entrevistas con los usuarios finales y otras personas quienes estén asociados con el nuevo sistema. Un repaso minucioso y entendimiento de los documentos de los usuarios, roles del negocio, y procesos son claves para la determinación apropiada y necesaria de las características y funcionalidades.

Paso3: Considerar las mejores prácticas

En el momento de definir los procesos de desarrollo del software se debe considerar las mejores prácticas. El Dr. Huizinga recomienda los procesos ágiles con énfasis en la documentación en imágenes, ambos para la documentación técnica y de requerimientos. Es importante seguir plantillas estándares, utilizar una herramienta de gestión de requerimientos y del tiempo.

Paso4: Diseño

Durante la fase de diseño, el arquitecto del software y el desarrollador puede poner junto un documento de diseño detallado resumiendo exactamente como el software satisfacerá los requerimientos específicos. El Dr. Gehrs recomienda el uso de mock-ups para acompañar el documento de diseño como una opción de elementos ilustrativos de la interfaz del usuario.

Paso5: Medición y rastreo de los progresos

Sin la infraestructura de la tecnología apropiada en el lugar, es difícil coleccionar y medir los datos claves del proyecto. Los indicadores del proyecto pueden ayudar asegurar la identificación rápida de los potenciales problemas, que permite que sean reconocidos y corregidos a tiempo. Cuando son observados fuera del periodo, el Dr. Huizinga remarca que los indicadores pueden ser usados para determinar la calidad del producto y despliegue deseado.

Paso6: Desarrollo

La fase de desarrollo, donde el documento de diseño es trasladado a una pieza real de software. Cuando el planeamiento cuidadoso ha sido ejecutado, el software marcará los requerimientos del manejo del negocio que inició la necesidad para el proyecto. El Dr. Gehrs menciona que los ciclos de desarrollo pueden producir varias versiones del software:

-> Alpha: característica preliminar/solamente funcionalidad
-> Beta: usada para el testeo interno o testeo de usabilidad
-> Candidatos de Release: usualmente una construcción estable puede necesitar algunas correcciones.
-> Construcción de producción o Gold Master: listo para el release

Los jefes de proyecto necesitan retroalimentarse con la experiencia de los usuarios, tiempos para completar las tareas, facilidad de uso, y otra información relacionada a la interfaz del usuario y los elementos céntricos del usuario.

Paso7: Automatización

Otro paso clave es asegurar la automatización de tareas repetitivas:

-> Construcción de códigos
-> Escaneo del análisis del código estático
-> Test regresivos

Dr. Huizinga cree que tomar medidas reduce el error propenso de la influencia humana cuando el software es implementado. Esto también facilita el uso de las mejores prácticas y colección de los datos relacionados al proyecto. Ella menciona que “todas las tareas repetitivas y mundanas deberían ser automatizadas cuando sea posible en cualquier parte del ciclo de vida del software”.

Paso8: Testeo

Ahora el siguiente paso es el testeo, Dr. Gehrs menciona que el testeo también puede variar bastante dependiendo de los procedimientos de testeos individuales adoptados por la organización. El testeo puede consistir de varias sub-etapas, como el aseguramiento de la calidad y la realización de las pruebas. Una vez que el software está en uso general, cualquier error encontrado es direccionado a una escala crítica: arreglos urgentes son programados para ser llevados tanto pronto sea posible. Los cambios característicos pueden ser elegidos para futuras versiones de actualizaciones.

Paso9: Prácticas graduales de implementación

El Dr. Huizinga menciona que “la implementación incremental de las prácticas por encima es crítico para poder sobresalir. La aproximación gradualmente a la introducción al cambio grupo por grupo y la práctica por práctica es esencial para alcanzar el cambio de la cultura organizacional, como cambio no es deseado, y siempre hay resistencia al cambio”. Porque la naturaleza compleja de los proyectos del software y la tecnología involucrada, el desarrollo del nuevo software justifica la propuesta sistemática. Entender el rol del líder del proyecto y la importancia de tener planeado un camino efectivo al desarrollo de los procesos puede ser una ventaja competitiva de una compañía dentro de un mercado competitivo.

Herramientas para la integración de Gestión de Cambios y Release (II)

Paso4: El QAE realiza el testeo de actividades.

El Ingeniero de Aseguramiento de Calidad recibe un e-mail de notificación del Rational ClearQuest que el software se encuentra listo para el testeo. Entonces se procede a revisar la información del defecto en el Rational ClearQuest y el cambio asociado (los archivos que fueron cambiados para arreglar el defecto) para planificar las actividades de testeo. Para verificar la etiqueta correcta de construcción y entender el entorno específico requerido para el testeo, se tiene que hacer referencia al BOM del Rational Build Forge.

Después, usar las características de gestión de testeo del Rational ClearQuest para la planificación del testeo. Generar casos de testeo en el Rational ClearQuest para asegurar que la corrección del programador ha corregido el defecto y luego acceder a los archivos modificados dentro del Rational ClearCase para empezar el testeo. Basándonos en los resultados construidos exitosamente Rational Build Forge puede empezar adicionalmente actividades automatizadas de testeo.

Una vez que el testeo ha sido completado, verificar los resultados de la capacidad de gestión del testeo en el Rational ClearQuest. Los resultados expuestos muestran que todos los casos de testeo han pasado. El BOM del Rational Build Forge es actualizado con los últimos resultados de testeo relacionados a la construcción. Las características de gestión de testeo en el Rational ClearQuest unifica el defecto con las actividades de testeo. El registro de un defecto contiene información sobre el defecto, como ¿qué archivos fueron cambiados para arreglar el defecto?, la información construida, ¿qué casos de testeo fueron creados para verificar el arreglo? y los resultados del testeo de aseguramiento de calidad.

Con el testeo concluido exitosamente, Rational ClearQuest continúa para administrar el flujo de trabajo del desarrollo del software con actualizaciones automáticas para el siguiente y último paso, el cuál es la “entrega”.

Paso5: El Ingeniero de Desarrollo entrega el software.

Después del testeo, Rational ClearQuest notifica al Ingeniero de Desarrollo que el software está listo para la construcción final y entrega. A través del Rational Build Forge, se puede acceder a los registros de construcción en el Rational ClearQuest para identificar todos los cambios (defectos, mejora de calidad, etc.) direccionados para ésta construcción en particular y los archivos asociados fuente almacenados dentro del Rational ClearCase. Los tres archivos que fueron modificados para arreglar el defecto actual son incluidos en la construcción del software.

Usando los procesos construidos consistentes y repetibles en el Rational Build Forge, se puede completar exitosamente y rápidamente la construcción, y los resultados de la construcción son automáticamente generados. Rational Build Forge ejecutará procesos adicionales que el equipo ha especificado para la entrega final del software.

Rational ClearCase almacena las unidades de despliegue mientras que el Rational ClearQuest almacena los registros de despliegue. Rational Build Forge soporta una colección diversa de tareas de despliegue, incluyendo mover archivos a la localización deseada, restaurar servidores web, automatización de notificaciones, etc.

Finalmente, Rational ClearQuest completa su gestión de los flujos de trabajo del desarrollo del software con la automatización y actualización del flujo de trabajo hacia el cierre.

Conclusiones

La gestión del cambio, configuración y despliegue son puntos críticos en los procesos de desarrollo y entrega de software de calidad. La integración del software Rational ClearCase, Rational ClearQuest y del Rational Build Forge provee un ambiente de desarrollo de alta integridad con la finalidad de mejorar la entrega del software y la trazabilidad del ciclo de vida de desarrollo del software.

Herramientas para la integración de Gestión de Cambios y Release (I)

El escenario de casos de uso descrito en el paper de IBM que he encontrado, trae la solución de un efecto hacia el desarrollo y entrega del ciclo de vida del proyecto usando la integración de la gestión de cambio y lanzamiento de IBM, cabe mencionar que está orientado a los proyectos de desarrollo de software.

El software IBM Rational ClearCase, IBM Rational ClearQuest e IBM Rational Build Forge pueden apoyar al equipo durante el flujo de trabajo del desarrollo del software y entrega del sistema mediante los siguientes pasos:

Paso1: El QAE identifica y agrega un defecto

Se puede expresar que durante el testeo del sistema, el Ingeniero de Aseguramiento de Calidad (QAE) identifica el defecto, dicho defecto es ingresado al IBM Rational ClearQuest, para que después el equipo del proyecto reciba una notificación del nuevo defecto y poder identificar la prioridad de arreglar éste. Rational ClearQuest permite una configuración flexible y estandarización de los procesos del flujo de trabajo de un proyecto. El líder del equipo después de asignar la actividad a un miembro del equipo de desarrollo, el estado del defecto se convierte en “asignado”; y después puede generar reportes y gráficos sobre la información del proyecto, como por ejemplo: una lista de los defectos con alta prioridad, un gráfico de distribución de defectos en cada estado y un gráfico de defectos a lo largo del tiempo.

Paso2: El programador trabaja en el defecto

Como se ha mencionado anteriormente, el defecto es asignado a cualquier programador del equipo y será notificado por el Rational ClearQuest. El programador necesitará la información sobre el defecto, el cual se encuentra almacenada en el Rational ClearQuest, después se tendrá que agregar notas y acceder al registro construido directamente desde tu IDE usando el Rational Build Forge IDE plug-in, ya que permitirá que se vea fácilmente los archivos log, el entorno de los datos y las versiones del código fuente que ha sido utilizada en la construcción para que se pueda rápidamente aislar la causa del error. Luego conectar el Rational ClearCase directamente de tu IDE para acceder a los archivos del sistema de tu proyecto, para arreglar el defecto en particular se necesita el cambio de tres archivos después de revisarlos se marca algunas actividades al Rational ClearQuest, ya que ayudará ha asegurar que conoces cual de los defectos se debe estar trabajando y su prioridad, luego seleccionar el defecto actual de la lista. Después de haber realizado los pasos, el defecto estará ahora asociado con los tres archivos y el Rational ClearQuest automáticamente actualizará el defecto en el estado “open”, que significa que todos los miembros del equipo conocen que estás trabajando en el defecto. Después se modifica el código para arreglar el defecto.

Paso3: El programador realiza una construcción para verificar la solución

Después de haber realizado los cambios en el código, se necesita saber si las modificaciones realizadas han corregido el error. Normalmente, se debería entregar al equipo de desarrollo y esperar los resultados, pero en el siguiente ejemplo se realizará la construcción porque el Rational ClearQuest y los procesos estandarizados de construcción del auto-servicio en Rational Build Forge están integrados, y se puede ejecutar el proceso de construcción estandarizado y obtener la retro-alimentación en tiempo real para confirmar que tus cambios han corregido el defecto. El Rational Build Forge incluye un adaptador del Rational ClearCase y del Rational ClearQuest para que se pueda automatizar acciones comunes relacionadas a los procesos de construcción. Por ejemplo, el Rational Build Forge puede realizar que las operaciones del Rational ClearCase “file check-out”, “file check-in” y “apply a label” pueda ingresar un registro de construcción en el Rational ClearQuest.

La parte final del paper lo mostraré en el siguiente post…. Hasta pronto!

La Gestión del Riesgo Innovadora

A continuación hablaré sobre un tema muy importante en la actualidad, “la gestión de riesgos”. Una buena gestión de riesgos comprende la identificación de los riesgos, el análisis cualitativo y cuantitativo para saber cual es la probabilidad de ocurrencia y el impacto en nuestro proyecto, el plan de respuesta también llamado el plan de contingencia o mitigación para contrarrestar que el riesgo se convierta en problema, y la supervisión y control de los riesgos del proyecto, según el PMBOK, 2004.

Buscando algún artículo sobre la gestión de riesgos encontré uno sobre la Gestión de Riesgo Innovadora publicado por el Dr. David Hillson PMP FAPM que a continuación compartiré con ustedes.

Si Ud. piensa que “la gestión de proyectos tiene que ver con procesos y gestión de riesgos, y eso es todo el contrario de la innovación”…. Entonces Ud. está equivocado.

El propósito de la gestión del riesgo en proyectos y comercios es buscar incertidumbres significativas y abordarlas de manera proactiva. Es más eficaz cuando la gestión del riesgo considera tanto amenazas como oportunidades, como recomiendan las normas de mejor práctica.

¿Lograr este objetivo requiere mucha innovación?

1. El primer campo donde la creatividad es indispensable es la identificación de riesgos. Esto requiere que uno piense lo impensable, que uno se libere del “plan” y considere otras opciones y alternativas; realizar preguntas como “¿Y si… Por qué no… Si solo...?”

Para la identificación de problemas potenciales (amenazas) y beneficios inesperados (oportunidades) se requiere el uso de una gama de técnicas creativas tales como el brainstorming (la lluvia de ideas), assumptions-busting (poner suposiciones en duda), análisis causa raíz, visualización, análisis de escenarios, o pensar en el futuro.

De hecho probablemente no es posible identificar riesgos sin ser innovador y/o tener nuevos pensamientos.

2. Pero una segunda parte del proceso de riesgo también requiere una nueva manera de pensar, es decir el desarrollo de respuestas a riesgos eficaces.

Según Einstein, “No es posible solucionar un problema usando las mismas ideas que lo crearon.” No es suficiente simplemente identificar riesgos, si la acción apropiada no se toma, ya que luego uno quedará expuesto al riesgo hasta el mismo grado. Sin embargo decidir qué es apropiado para cada riesgo requiere cierta innovación, estar dispuesto a considerar y tomar acciones que antes uno no consideraba necesarias.

Einstein también definió la locura como “hacer lo mismo sin cesar y esperar resultados diferentes”, lo que se podría decir de otra manera así “‘¡Si sigues haciendo lo que siempre hiciste, siempre recibirás lo que siempre recibiste!”

Como dice el proverbio chino, “Si no cambiamos de dirección, es probable que llegamos adonde íbamos.”

Pero la gestión del riesgo moderna es muy diferente. Acoge y aprovecha del cambio activamente, reconociendo que algunos riesgos ofrecen la oportunidad de mejorar el plan original al trabajar “más eficaz, más rápido, más barato” – hay algo positivo tanto como negativo.

“La gestión del riesgo no creativa” es un oxímoron que no puede existir, y la gestión del riesgo sin la innovación sólo repite y documenta lo inevitable.

Conclusiones

Si el objetivo de la gestión del riesgo se percibe como impedir que uno diverja del plan a todo costo, agarrarse desesperadamente al método original y rechazar el cambio, pues es verdad que se ahogarán la creatividad y la innovación.

Para ser eficaz el proceso de riesgo debe abordar ideas innovadoras y creativas tanto en la identificación del riesgo como en el desarrollo de respuestas, buscando de manera proactiva incertidumbres con la potencialidad de ser significativas y abordándolas apropiadamente. Algo menos no merece el nombre de la gestión del riesgo.

Comparando las Metodologías Guiadas y Ágiles

A continuación hablaré sobre un extracto de un paper que he encontrado sobre las ventajas y desventajas en el uso de las metodologías guiadas y ágiles.

Algunas diferencias entre Metodologías

1. SDM vs. PMBOK

Conociendo que el SDM es la metodología de desarrollo de sistemas que ofrece procesos, herramientas y técnicas para el desarrollo de software basado en otros sistemas; mencionaré algunas diferencias con el PMBOK.

-> El PMBOK se enfoca en la gestión de un proyecto cualquiera, mientras que el SDM se enfoca en la producción de un software.
-> El PMBOK responde a las preguntas de ¿Quién?, ¿Qué? y ¿Cuándo? para la gestión de un proyecto, mientras que el SDM ¿Qué producir? y ¿Cómo producir?.

2. Metodologías Guiadas vs. SDM

-> Ambos proveen procesos, herramientas y técnicas.
-> Ambos requieren un enfoque disciplinado al desarrollo del software.
-> Cada uno tiene fortalezas y debilidades.

3. Metodologías Guiadas vs Metodologías Ágiles

-> Las metodologías ágiles dirigen muchas situaciones cuando las metodologías dirigidas no están bien definidas.
-> Las metodologías guiadas enfatiza en las comunicaciones formales y en el control, con la finalidad de ser más predictivo, mientras que las metodologías ágiles enfatiza en las comunicaciones informales continuas y a la reacción en los cambios, con la finalidad de ser mas adaptivo.

Ejemplos de Metodologías Guiadas

-> RUP de IBM
-> Gestión de Proyectos Tradicionales

Ejemplos de Metodologías Ágiles

-> XP (eXtreme Programming)
-> SCRUM
-> FDD (Feature Driven Development)
-> LD (Lean Development)
-> Crystal

¿Cómo elegir la herramienta correcta?

Seleccionando una metodología dependiendo de la situación, ya que la metodología guiada trabaja mejor bajo algunas circunstancias, y la metodología ágil trabaja mejor bajo otras, o tomando componentes y/o técnicas de cada uno, para construir los procesos que trabajen mejor para la situación.

Pero en realidad eso no me define que herramientas escoger ¿?, por eso se debe tomar en cuenta los siguientes factores:

1. Experiencia

Cuando el equipo tiene experiencia con el dominio de problemas, usa la metodología ágil, pero si el equipo tiene poca experiencia, puede utilizar la metodología ágil junto a la metodología guiada. Se debe tener en consideración el uso de:

-> R&D
-> Desarrollo iterativo mientras se está ganando experiencia con factores de realización.
-> Uso de nuevas tecnologías que impacte al equipo, por ejemplo la aplicación de grupos pequeños de trabajo.

2. Madurez del equipo de trabajo

-> Los equipos con poca madurez requieren una estructura adicional de una metodología guiada.
-> Los equipos con alta madurez fácilmente pueden tomar una ventaja ágil.

3. Localización y Tamaño del Proyecto

Si el equipo de trabajo es grande y geográficamente disperso requieren una comunicación formal de la metodología guiada, pero si el equipo es pequeño y localizado debe utilizar una comunicación informal. Es recomendable que los equipos no excedan de 6 a 8 miembros.

4. Cultura Organizacional

Algunas culturas organizacionales y equipos de gestión pueden ser más receptivos de un enfoque de otro.

5. Escalabilidad y Portabilidad

Para la construcción de un robusto sistema para la extrema escalabilidad a lo largo de una variedad de arquitecturas e infraestructuras podrían ser mejor direccionado con los controles de una Metodología Guiada.

6. Producto Comercial

La creación de un producto comercial requiere coordinación con Marketing y Departamentos de Venta, para la preparación de guías de usuario, el desarrollo de programas, y el establecimiento de equipos de producción; el cuál puede ser muy beneficioso utilizando un enfoque de una Metodología Guiada.

7. Combinando Metodologías

Combinando prácticas de ambos tipos de metodologías podría ser beneficial en algunas situaciones. Algunos enfoques son los siguientes:

-> Usar la metodología guiada para un proyecto o programa complejo y después utilizar la metodología ágil para sub-proyectos o sub-componentes.
-> Usar la metodología guiada para cualquier proyecto en general pero usar las técnicas ágiles como la programación en pareja para el esfuerzo de desarrollo.

Conclusiones

Un proceso definido no necesariamente debe ser formal o documentado, solamente debería ser consistente y ajustado.

El término ágil es un enfoque disciplinado al desarrollo de software pero con un énfasis en diferentes aspectos de los procesos.

Los equipos de gestión que trabajan bien con un enfoque de la metodología guiada también tienden a trabajar bien con un enfoque ágil.