Especialización en Desarrollo de SoftwareCohorte Trece

Es una aplicación Web que permite gestionar activos de software para su reutilización en proyectos de desarrollo.

Los tipos de activos son cualquier artefacto generado en el ciclo de vida del desarrollo del software como:

1. Modelos2. Diagramas3. Componentes4. Librerías5. Código fuente.

¿QUÉ ES GEAS?

PROYECTO

Director Proyecto

Analistas Requisitos Desarrolladores Arquitectos

Funcional

integraciones

CMO SQA

Coordinador Proyecto

Estructura de Roles

Principales actividades realizadas

• Plan de la Configuración• Establecimiento y administración del

repositorio.• Sistema de Control de los cambios.• Despliegue de las aplicaciones en los

distintos ambientes (Desarrollo, Calidad, Producción).

• Definición de herramientas, habilitación de ambiente e infraestructura, Ver más

PROYECTO

ALCANCE FUNCIONAL

Se definieron 19 Casos de uso divididos en 5 grupos : • Activos de software• Aportes• Búsquedas• Administración• Integraciones

MÉTRICAS DEL PROYECTO

1. Duración Real vs Duración estimada

2. Volumen de incidencias reportadas en Desarrollo

Métricas 1

• Duración Real vs Duración estimadaCasos de Uso

Duración Estimada

Duración Real

Activos de softwareCU-1. Catalogar activos de software 4 7CU-3. Administrar dependencias activos de software 5 5CU-4. Administrar tipos de activos 5 2CU-6. Administrar atributos específicos activos de software 4 1CU-7. Gestionar la evolución del activo: 2 7CU-11. Consultar Activo de software 13 13

AportesCU-2. Administrar aportes de uso de activos de software 4 2CU-5. Cualificar un activo de software 3 2CU-10. Consultar experiencia de uso de un activo de software: 4 5

BúsquedasCU-8. Buscar estructuradamente 5 6CU-9. Buscar semánticamente activos de software 5 6

Métricas 1

• Duración Real vs Duración estimadaCasos de Uso

Duración Estimada

Duración Real

AdministraciónCU-13. Administrar usuarios 5 4CU-14. Administrar roles usuarios 5 3CU-15. Administrar Auditoria 34 2CU-12. Administrar maestros 5 5

IntegracionesCU-16. Consultar historial de cambios 7 9CU-17. Consultar historial de errores: 7 9CU-18. Consultar petición de cambios: 1 9Atención Bugs 33TOTALES 118 130

Convención1 Día = 3 Horas/Hombre

Métricas 2

• Volumen de incidencias reportadas en Desarrollo

–Total incidencias: 45–Incidencias abiertas: 5

SISTEMA GEAS

CO

NC

EO

TU

AL

LÓ

GIC

A

FIS

ICA

IMP

LEM

EN

TA

CIÓ

N

Entorno tecnológico, asignaturas, laboratorios

VISTAS ARQUITECTÓNICAS

ARQUITECTURA

Actividades desarrollas

1. Repositorio en Google Code.

2. Plan de Gestión de la Configuración.

3. Matriz de Ítems de Configuración

4. Usuarios y Perfiles en el repositorio

5. Estructura Interna del Repositorio.

GESTIÓN DE LA CONFIGURACIÓN

GESTIÓN DE LA CALIDAD

Proceso• El modelo de calidad que utilizo para el desarrollo del plan

de calidad se baso en las áreas de proceso que cubre CMMI Nivel 3

Herramientas• Se utilizaron formatos de auditoria para hacer seguimiento

de las etapas de construcción y transición del ciclo de vida del proyecto.

Técnicas •Se busco la aplicación del plan de QA para los siguientes elementos de software: Código Fuente, Scripts de Base de Datos, Documento de Configuración de los Ambientes, Plan de Aseguramiento de la Calidad, Plan de Evaluación, Plan de Pruebas, Casos de Pruebas, Documento de Preparación de Ambiente, Documento de Software Requerido, Documento de Instalación y configuración del software.

Metodología• Se realizaron auditorias a los objetos desarrollados y se

realizaron mas de 45 pruebas integrales que buscaban probar los casos de uso identificados

LESIONES APRENDIDAS

ANÁLISIS• POSITIVO: Durante el

desarrollo del proyecto GEAS, pudimos aprender y ejecutar varias técnicas de análisis. También aprendimos a clasificar los resultados de una manera adecuada y escalable.

• NEGATIVO: Los requisitos nunca fueron validados ni expuestos a los demás grupos de trabajo ni con el cliente.

• A MEJORAR: Incluir más al cliente o los Stakeholders en los próximos proyectos, ya que no se debe asumir nada por el cliente, se debe preguntar y validar con él las interpretaciones hechas.

DISEÑO• POSITIVO: La experiencia

adquirida permitió obtener conocimiento y desarrollar habilidades de modelado que me han sido de gran utilidad en mi desempeño profesional

• NEGATIVO: Las interfaces fueron cambiadas en su mayoría por la ventaja que daba el framework Marte para desarrollarlas.

• A MEJORAR: Debería haber un enfoque más práctico en la manera como se enseña el modelado de una solución. Es decir explicar cómo se pasa del modelo obtenido al código fuente.

DESARROLLO• POSITIVO: El ahorro en

tiempo y esfuerzo que nos dio la herramienta de Marte con PHP, pues permitió generar código sin codificación alguna.

• NEGATIVO: Marte es una herramienta MDD la cual no puede convertir el código en diagrama UML, por lo cual una vez modificado el código base, este no se podía devolver

• A MEJORAR: Hay que tener un alto grado de claridad de que es lo que se desea construir, y no mirarlo como una pieza de código individual sino como un Todo.

LESIONES APRENDIDAS

TRANSICIÓN • POSITIVO: El Servidor puesto a

disposición por la universidad para el desarrollo del proyecto.

• A MEJORAR: La participación de la Universidad como sponsor de estos proyectos. .

GESTIÓN DE CONFIGURACIÓN• POSITIVO: Se siguieron los lineamientos

para seleccionar las herramientas de trabajo descritas en el plan de la gestión de la configuración.

• NEGATIVO: Esta es una de las actividades que debe hacerse al principio de un proyecto no cuando se está a punto de empezar la etapa de implementación

• A MEJORAR: Las actividades de la gestión de la configuración deberían ser las primeras actividades antes que la parte de análisis.

LESIONES APRENDIDAS

GESTIÓN DEL PROYECTO• POSITIVO: En GEAS, pudimos observar

como la creación de un calendario de actividades y recursos asignados facilito notoriamente la ejecución de las tareas de La planeación de un proyecto no se hace cuando este está terminando la fase de diseño.

• NEGATIVO: La planeación de un proyecto no se hace cuando este está terminando la fase de diseño.

• A MEJORAR: Definir roles en el grupo desde el comienzo del proyecto. Esto beneficiara la integración del grupo en las entregas y avance en las diferentes etapas y no solo en la última etapa del proyecto.

GESTIÓN DE CALIDAD• POSITIVO: La definición de Google Apps

como sistema de gestión de errores, el cual está integrado con los usuarios ya registrados facilito la asignación y reporte de los errores los cuales llegan de forma inmediata al correo personal de Gmail

• NEGATIVO: La calidad solo la enfocaron al producto, no al proceso de desarrollo.

• A MEJORAR: Para desarrollar de manera correcta unas pruebas es fundamental que exista una documentación “Casos de uso” que describan como deberá ser el comportamiento del sistema. . .

¿Quieres saber como funcionó?