especialización en desarrollo de software cohorte trece
TRANSCRIPT
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ó?