Академический Документы
Профессиональный Документы
Культура Документы
Conclusiones
Margen de atraso para 20% la actividad Nivel de dedicacin Requerida TOTAL 20% 100%
0.2 1 2.2
1 1 5
2. Proceso de Desarrollo
MDA
Modelo del Sistema de Informacin Modelo de Integracin Modelo de Plataforma Tecnolgica
Arquitectura de Referencia Modelo de Datos e Interfaces
Subsistemas y mdulos
rbol de Procesos
Workflow de Actividades
2. Proceso de Desarrollo
Sistema Admon Captura Campo
Editar Pedido Admin Pedido Consultar Pedidos Crear Pedido
Vendedor
Admin Clientes
Consultar Clientes
Admin Cartera
Consultar Cartera
Admin Precios
Consultar Precios
Admin Productos
Consultar Inventario
Admin Visitas
Consultar Visitas
2. Proceso de Desarrollo
TESTING:
2. Proceso de Desarrollo
Pruebas Internas Pruebas Externas 1. Equipo Cliente 2. Aceptacin Usuario Final 3. Piloto Productivo
2. Proceso de Desarrollo
Pese a su aparente falta de rigurosidad, las Pruebas de Guerrilla son la herramienta ms gil de encontrar defectos. Se recomienda que se agrupen por tipos: 1. 2. 3. 4. 5. 6. 7. Pruebas de Validacin (por campo) Pruebas de Control (por forma/pantalla/proceso) Pruebas de lgica (workflow del caso de uso) Pruebas de lgica inversa (flujos alternos o de excepcin) Pruebas de navegacin (entre pantallas y opciones men) Pruebas de interaccin funcional (otros mdulos) Pruebas de consistencia / integralidad (de los datos)
2. Proceso de Desarrollo
Administracin de publicaciones
Cam estndar o pequeo bio
Rechazo
Administracin de cambios
Administrador de cambios
Cam bio grande o im portante
Administrador de cambios
2. Proceso de Desarrollo
Repositorio de artefactos Polticas de Versionamiento y Lneas Base:
[MajorRelease].[Phase].[iter/test-cycle] (pe. 1.1.1, 2.1.0)
tems de Configuracin.
Identificar Relaciones Seguimiento control y bloqueo
3. Gestin Cuantificada
3. Gestin Cuantificada
1. Esfuerzo: Total Horas Invertidas 2. Progreso: Variacin entre tiempo estimado vs. esfuerzo 3. Productividad: KLOC/hora 4. Calidad: defectos/KLOC 5. Estabilidad: Cantidad de modificaciones al producto
3. Gestin Cuantificada
1. Indica como establecer equipos de trabajo autnomos y productivos 2. Cada miembro debe tener habilidad en PSP 3. Ensea a los PM como acompaar y motivar a sus equipos para lograr mxima productividad y cohesin. 4. La unidad de control es la semana (EVA) 5. Introduce el concepto de Revisiones de Cdigo formales. 6. El equipo es participe y responsable de la planeacin del proyecto.
3. Gestin Cuantificada
3. Gestin Cuantificada
4000
Si EAC est por encima de BAC, indica que se espera terminar con un sobrecosto(VAC<0), si todo sigue como va Si EAC est por debajo de BAC, indica que se espera terminar con un un costo inferior al planeado(VAC>0), si todo sigue como va
BAC $ 3,775 EAC
VAC= $270
3500
$ 3,505
3000
2500 COSTOS($)
2000
AC (ACWP)
500
0 0 2 4 6 8 10 12 14 16 18 TIEMPO(DAS)
3. Gestin Cuantificada
Por tamao
TIPOS DE PROYECTOS
PROYECTOS PEQUEOS PROYECTOS MEDIANOS Entre 6 y 12 meses PROYECTOS GRANDES Entre 12 y 24 meses o ms.
ASPECTOS
DURACIN
Entre 2 y 6 meses
Menos de 20 personas
Por naturaleza
Esta clasificacin depender del tipo de empresa y se obtendr una definicin propia y adaptada a la razn de ser de la misma. Para orientar la definicin de los proyectos por naturaleza se deber partir del modelo de procesos de la organizacin PROVEEDORES
Insumos
PROCESO
Bienes o Servicios
CLIENTE
1. Capacitar a la Organizacin 2. Viabilidad, Priorizacin y Aprobacin de Proyectos 3. Asesora en Gestin de Proyectos 4. Interventora de Proyectos 5. Gestin Integrada del pool de Recursos 6. Toma de Decisiones entre Proyectos (DAR) 7. Control y Aseguramiento
Seguimiento Peridico Integrado entre proyectos (Comit) Evidenciable (Actas) Medible (EVA KPIs/Reportes)
4. Madurez Corporativa
4. Madurez Corporativa
4. Madurez Corporativa
4. Madurez Corporativa
4. Madurez Corporativa
Definicin de Procesos Comit de Procesos Equipo Operativo
Gerentes de Proyecto Lder Engineering Lder Project Management(PMO) Lder Process Mgmt
4. Madurez Corporativa
4. Madurez Corporativa
PMO 1 PMO 2 PMO 3
Conclusiones Generales
4. Conclusiones Generales
1. La meta es clara: La ingeniera de software debe convertirse en una ciencia (precisa, formal, detallada) = predecible Las metodologas son herramientas, su xito depende de cmo las usemos Desafortunadamente cada metodologa enfoca solo parte del problema y este debe atacarse de forma integral. Profundizar en aspectos de la prctica que no son detallados por las metodologas.
2.
3.
4.
4. Conclusiones Generales
No se pretende dictar un curso de PMI, RUP, PSP/TSP, o CMMI sino exponer un modelo integrado, basado en la experiencia del uso de estas. Simplificar y agilizar la curva de aprendizaje de gerentes y arquitectos.
4. Conclusiones Generales
Tendencias y fallas latentes en la ingeniera de Software:
Formalizacin de una metodologa de anlisis y diseo (MDA ser la respuesta???) Formalizacin de una metodologa de normalizacin de requerimientos (normalizacin???) Formalizar una especificacin para productos de Business Integration (SOA ???) Y despus, que nuevos problemas soluciones, retos y paradigmas vendrn ????
Finalmente