ACIS

1. ACIS Desarrollar proyectos de software y “evitar” el fracaso ? Intro Por Bernardo Díaz Arias berdiaz@yahoo.com

2. N1: Gerencia de Proyectos - PMI • Overview de PMI • Actividades de Inicio • Actividades de Planeación • Comunicación • HR • Administración del Alcance • Actividades de Monitoreo y Ctrl • Admin. de Riesgos • Ctrl. de cambios • Toma de Decisiones • Alcance de la Calidad • Actividades de Cierre Primer paso: “Aprenda a coordinar un proyecto”

3. N1: Gerencia de Proyectos - PMI

4. El objetivo de un proyecto es generar un producto según los requerimientos pactados. La planeación es la base La administración de riesgos y el monitoreo brindan estabilidad al proceso. Los proyectos son de elaboración Progresiva (nadie nace aprendido. El éxito del proyecto no debe “depender” de los expertos sino que estos deben ser herramientas para normalizar el trabajo realizado). Promueve la autonomía del Project Manager (PM) como figura que integra todos los elementos involucrados El éxito de un proyecto es equilibrar la triple restricción (Q-$-t)->S Las causas más comunes de fallo en proyectos de software son: Falta de administración del alcance (S) Comunicación con el cliente (Comm) El manejo de los recursos humanos (HR) N1: Gerencia de Proyectos - PMI Áreas de Conocimiento (9)

5. 1. Actividades de Inicio Se debe estimar el alcance de los términos contractuales con base en información histórica (a nivel de módulo) Implicaciones del tipo de contrato del proyecto: Precio Fijo (FP). Es el más riesgoso. Se debe controlar formalizando de antemano restricciones, riesgos del proyecto y precondiciones (requerimientos vs. tiempo, costos y recursos). Subcontratos. Cada etapa del proceso se maneja como un subcontrato, y al final de este se sustenta el alcance del siguiente. Brinda mejores garantías a las partes. Tiempo y Materiales (T&M). Se recomienda que lo “ejecute” una empresa CMMI 4 (o con infraestructura similar) ya que demanda cuantificar y controlar el esfuerzo de desarrollo del proyecto. No se comprometa con proyectos no viables (Pet Projects) N1: Gerencia de Proyectos - PMI

6. 2. Actividades de Planeación - Comunicación Asegurese de contar con los siguientes roles: Sponsor Coordinador Funcional - Cliente Usuarios Técnicos Usuarios Funcionales Formalice mecanismos de comunicación para cada tipo de rol, sin mezclarlos. Establezca el plan de comunicación con base en reuniones de seguimiento, mecanismos de revisión y mecanismos de aceptación (p.e. actas). En cualquier caso maneje comunicación formal e informal (envíe el e-mail pero llame para verificar que lo recibieron…). No subestime la retroalimentación informal con los diferentes participantes del proyecto (no deje de último a los miembros de su equipo…). Todos los eventos relevantes deben formalizarse por escrito. Con un margen de 1-3 días max. Identifique el tipo de organización del cliente (orientada a proyectos, funcional, matricial <fuerte, débil, balanceada>) así como sus prioridades (Q-S-$-t) Establezca las reglas del proyecto y del equipo en la reunión de inicio (kickoff) Asigne responsabilidades a los involucrados en el proyecto para que se integren como parte del mismo. N1: Gerencia de Proyectos - PMI

7. 2. Actividades de Planeación - Manejo de los recursos humanos (HR) “El proyecto lo implementan los recursos del equipo..” Proceso de selección: Evaluación de Conocimientos (pruebas técnicas) Evaluación de Experiencia (años de experiencia específica) Evaluación de Actitud (pruebas psicológicas + 2 entrevistas cruzadas (PM, HR) ) Las Pruebas Psicológicas se deben diseñar con base en el perfil y el cargo: Ingeniero de Desarrollo = Concentración + Pensamiento lógico-analítico Arquitecto = Pensamiento Abstracto + Capacidad de aprendizaje e investigación. Especificación de requerimientos y pruebas = Organizado, metódico, orientado al detalle. PM = Liderazgo + Comunicación (verbal y escrita), visión global. * Estadísticamente a 1 y 2 le faltan las características de 3 y 4 y viceversa. Motivación es el arte y la ciencia de identificar y potenciar lo mejor de cada persona de su equipo, independiente de su cargo, preferencias y relaciones personales. Mantenga un ritmo de trabajo alto y constante, priorice el inicio del proyecto ya que existen más incertidumbre y riesgos. N1: Gerencia de Proyectos - PMI

8. 2. Actividades de Planeación – Administración del Alcance Las entradas mínimas para estimar son la especificación funcional y técnica. La herramienta más usada es Function Points Una técnica alternativa es el uso de Información Histórica: Comience por registrar los tiempos (min-prom-max) de sus equipos progresivamente: Pantallas / módulo CU / módulo Componentes / CU Clases / paquete Cada elemento tiene complejidad 1-5. A la información histórica NO se le debe calcular holgura (ya la incluye) La recolección de información termina al generar las tablas de performance de la organización Es más sencillo y flexible planear de forma progresiva – (Plan proyecto + plan detallado por iteración) Duración recomendada para las iteraciones = 4 – 8 semanas WBS, base de la planeación? N1: Gerencia de Proyectos - PMI

9. 2. Actividades de Planeación – Administración del Alcance Plan de Aceptación Plan de Comunicación Planeación Iterativa Tipo de contrato Juegue con reglas claras: Incluya en sus planes riesgos, restricciones y precondiciones. Revisiones Periódicas Formales (semanales – fase, técnicas, funcionales y administrativas) Su compromiso: entregables Fechas de cierre por fase Formalice todo N1: Gerencia de Proyectos - PMI

10. 3. Actividades de Monitoreo y Control Durante la ejecución el equipo se debe concentrar en “desarrollar” el producto. Durante esta fase las labores del PM se concentran en Monitoreo y Ctrl. Medición del Progreso. Medición de Esfuerzo + Medición de Costo = (EVA) Medición de la Calidad. Defectos/KLOC Medición de la Productividad. KLOC/hora Medición de la Estabilidad del Proceso. Cantidad de cambios registrados al alcance (requerimientos, ajustes al cronograma, controles de cambio, etc..) Identifique el esfuerzo en entrenamiento.Oriente y cuantifique los resultados hacia sus necesidades (Quiz, paper, prueba de concepto?). N1: Gerencia de Proyectos - PMI

11. 4. Actividades de Administración de Riesgos Identifique y agrupe los riesgos: De proyecto Técnicos Funcionales Documento Pendientes. Genere un formato de hoja de cálculo donde cada miembro del equipo registre (día a día) la información pendiente para cumplir su trabajo. Debe incluir tipo, descripción, fecha ingreso, estado, responsable, respuesta. El manejo de riesgos es netamente preventivo y como tal se debe informar e involucrar activamente al cliente. N1: Gerencia de Proyectos - PMI

12. 5. Control de Cambios Conviva con ellos, son típicos para proyectos ejecutados en contratos de precio fijo (FP). Maneje dos tipos, interno al equipo del proyecto o contractuales con el cliente. Acuerde previamente con el cliente que escenarios “dispararían” un control de cambio contractual. Si un evento genera un control de cambio que afecte el alcance del proyecto, alguien debe asumir el costo. Si no es su culpa, no la asuma…, recuerde que todo debe estar sustentado con “hechos y datos”. N1: Gerencia de Proyectos - PMI

13. N1: Gerencia de Proyectos - PMI 6. Toma de Decisiones Se debe basar en una metodología que evite conflictos de intereses personales como Weighted Scoring Model: • Identifique en consenso los factores que intervienen en la decisión y asigneles un peso o prioridad • Asigne un puntaje a cada factor • Sume el total de cada alternativa. • Se escoge la alternativa con mayor puntaje acumulado

14. 7. Calidad (Q) El costo de la calidad “TOTAL” es muy alto (no se puede identificar que es peor, la cura o la enfermedad). En proyectos de software, calidad es sinónimo de estabilidad no de mejoras o adiciones a los requerimientos acordados (Gold Plating). 8. Actividades de Cierre PMI recomienda que en cada ciclo terminado de un proyecto se registren las lecciones aprendidas (embarradas cometidas). N1: Gerencia de Proyectos - PMI

15. Disciplinas Ejecución Iterativa Fases (tiempo) Adaptación del RUP Metodología de Modelamiento Normalización Arquitectónica QA & QC Admin. de la Config. N2: Metodología de Desarrollo - RUP Segundo paso: “Aprenda a construir software”

16. “No dejar nada al azar”. Obliga a desarrollar software considerando todos los elementos necesarios o Disciplinas principales: Business Modeling Requirements Analisis & Design Implementation Testing Y las disciplinas complementarias: Project Management (*** PMI se puede integrar acá) Config & Change Mgmt Environment Mgmt Deployment La planeación y control del proyecto se simplifica al dividirlo en Iteraciones cortas (4-8 semanas). El resultado de cada iteración debe ser una versión ejecutable del sistema. El cliente percibe resultados más rápido y puede retroalimentar de forma más efectiva. N2: Metodología de Desarrollo - RUP

17. N2: Metodología de Desarrollo - RUP

18. En el tiempo el proyecto se divide en fases con objetivos definidos: Incepción (aprox. 5 – 20% total). Planeación detallada del proyecto. Conocimiento del negocio Especificación funcional y técnica Elaboración (aprox. 15 – 30% total). Definir la arquitectura de referencia. Implementar Pruebas de Concepto (Verificación Arquitectura) Diseño detallado Definir estrategia de implementación Implementar módulos utilitarios (seguridad, auditoria, pantalla principal) Construcción (aprox. 30 – 50% total). Desarrollo de los módulos del sistema, distribuidos según prioridad, complejidad y dependencias. Transición (aprox. 15 - 30% total). Entrega del sistema. Pruebas funcionales Pruebas de aceptación con los usuarios Pruebas técnicas (carga, estrés, volumen, seguridad, concurrencia, etc.) Pruebas de instalación Documentación manuales Capacitación Usuarios Entrega a producción (cierre proyecto) Cada fase consta de iteraciones de su mismo tipo (p.e. IC1, IC2, IC3, corresponden a iteraciones de la fase de construcción). N2: Metodología de Desarrollo - RUP

19. N2: Metodología de Desarrollo - RUP • Todas las actividades de modelamiento del sistema se pueden clasificar en funcionales o técnicas. • De forma complementaria RUP define Roles, Actividades y Artefactos-Entregables. • RUP incluye un set de plantillas de artefactos para cada disciplina y flujos generales de las actividades pero no define un flujo detallado para el proceso de desarrollo. • RUP en esencia es un framework genérico que debe ser adaptado a las necesidades y condiciones de cualquier proyecto de software. La metodología como tal NO especifica como adaptarlo. El framework puede resultar muy “pesado” e ineficiente si no se sabe adaptar. • La métrica recomendada para adoptar RUP es usar las disciplinas en proyectos cortos hasta institucionalizarla en la compañía. • Un ejemplo sería iniciar usando las disciplinas de administración en un primer proyecto. • En un segundo proyecto incluir el grupo de business Modeling y Requirements. • En un tercer proyecto adicionar Analisis & Design • En un cuarto proyecto adicionar Implementation & Testing • En un quinto proyecto usar todas las disciplinas.

20. N2: Metodología de Desarrollo - RUP • El PM debe conocer en detalle la metodología de desarrollo. • El arquitecto debe conocer el grupo de disciplinas principales. • El equipo de trabajo debe entender la filosofía de RUP para poder interiorizarla. • Como tal, RUP no es prescriptivo con el uso de una herramienta de modelamiento (aunque las plantillas de ejemplo se basan en UML). Los usos recomendados para UML son: Especificación • D. de CU. Para representar procesos del sistema • ***D. de Actividades. Para representar la dinámica interna y relaciones entre procesos Macro Diseño • D. de Deployment. Para representar los subsistemas y sus dependencias • D. de Clases para representar el modelo de Entidades y relaciones del sistema (MER) • D. de Componentes. Para representar las capas y componentes del sistema (arquitectura) y sus dependencias. Diseño Detallado • D. de Paquetes para representar las capas y grupos de componentes • D. de Clases. Para representar las clases de implementación (clases de control, de entidad, de interfase y utilitarias). • ***D. de Secuencias. Para representar el paso de mensajes entre clases al ejecutar un proceso del sistema. *** Permiten anticipar requerimientos y reglas de negocio complejas antes de escribir código.

21. N2: Metodología de Desarrollo - RUP

22. N2: Metodología de Desarrollo - RUP *** Normalización Arquitectónica. Verifica que el diseño detallado sea definido en términos de un modelo de patrones de diseño y capas (propio de la tecnología de implementación). Los procesos del sistema se implementan a “lo largo” de este modelo (p.e. desde la capa cliente hasta la capa de persistencia para J2EE). • El desacoplamiento entre clases y componentes no debe interpretarse como una característica opcional y deseable del modelo sino como un requerimiento. • Pensar en grande, hacer en pequeño. La arquitectura debe ser genérica siempre, el desarrollo del sistema debe implementar los requerimientos. • Similar al concepto de normalización relacional en 12 niveles de CODD. • Los frameworks simplifican la tarea de normalización por que internamente se basan en patrones y buenas prácticas. • Existe la tendencia equivocada de sobre-crear patrones y por principio estos no son patrones. • Las evoluciones de OOP son COP, IOC, SOC y las corrientes más prometedoras son AOP, MDA, SOA. • Todas las metodologías de modelamiento de software se pueden abstraer en una única metodología (basada en meta-patrones y roles). • Cuando se “llegue” a ese nivel de madurez se podrá automatizar la generación de código a partir del modelo requerimientos (ver GeneXus).

23. N2: Metodología de Desarrollo - RUP

24. QA (metodologías y buenas prácticas) y QC (Evaluación del producto, Testing) Tipos de Pruebas *** De código Unitarias Revisión entre compañeros Code Profiling Funcionales Técnicas De GUI / Usabilidad De instalación De seguridad De concurrencia / transaccionalidad De volumen, carga y stress Niveles de Prueba Unitario Integrado (módulo/subsistema) Sistema (*Regresión) Fases de Prueba (ciclos y estados del producto) Alfa (generalmente se alcanza al final de la fase de construcción) Beta (primer ciclo estable de pruebas funcionales de transición) Aceptación (“verificación/checklist” de las pruebas anteriores) Pruebas de Instalación (checklist de entrega a producción) Artefactos Requeridos Plan de Pruebas Plan de Aceptación Casos y escenarios de Prueba Reporte de Defectos Resumen Ciclo de Pruebas N2: Metodología de Desarrollo - RUP

25. N2: Metodología de Desarrollo - RUP Configuration & Change Management = Administración del CVS • Agrupe todos los documentos de la organización por áreas, súbalos y adminístrelos en el repositorio de CVS. • Para cada evento del proyecto (entrega de iteración, control de cambio o estabilización de un ciclo de pruebas) genere un “baseline” que identifique esa versión del sistema.

26. N3: Individual - PSP • Antecedentes • Elementos • Herramienta para la madurez? • Conclusiones “Que pasaría si la liebre fuera tan organizada, juiciosa y constante como la tortuga?...” Tercer paso: “Toda organización es fruto de su gente…”

27. N3: Individual - PSP Antecedentes • Falencias tipificadas • Dispersión • Estimaciones individuales incorrectas (afectan el plan general = incumplimiento) • Cualquier tipo de actividad puede tener un ciclo Plan-Do-Check-Act *** PSP es el pilar de un modelo de madurez en una empresa de software. • Reporte de Esfuerzo. Mide el esfuerzo individual y permite estimar el del proyecto y la compañía. • Cronograma Individual. Mide la variación entre la duración real y estimada de las actividades del cronograma • Métricas y reportes periódicos.

28. N3: Individual - PSP Conclusiones • Es una herramienta para planear y organizar de forma efectiva la jornada de trabajo (más de 9X5 ???). • Empresa organizada vs. Empresa dream-team ? • La estabilidad de las partes aportan a la estabilidad del todo • No se comprometa a realizar algo sobre lo cual no posee información y por tanto no puede garantizar • “Competir con calidad y cantidad” Calidad = Interiorizar la cultura del mejoramiento continuo Cantidad = Supere el mito del “esclavo” • Saque el mejor partido de sus habilidades e intereses. No todo desarrollador debería “terminar”como PM o arquitecto.

29. N4: Corporativo - CMMI • Antecedentes • Generalidades • Conclusiones Cuarto paso: “La organización debe tener un rumbo claro…”

30. N4: Corporativo - CMMI

31. N4: Corporativo - CMMI Antecedentes: “La madurez del proceso es relativa a la madurez de la compañía…” • Metodología para lograr la madurez en el proceso de desarrollo de software (CMM-S). • Formalizada por el SEI a partir de trabajos previos del DOD, la NASA, IBM y la U. de Carnegie Mellon. • Dado su éxito en la práctica, se aplicaron cambios menores y se generalizó para diferentes tipos de procesos e industrias (CMMI).

32. N4: Corporativo - CMMI Generalidades: • Se basa en 5 Niveles o fases de evolución y estos contienen áreas de procesos (PA). • Cada PA contiene políticas de calidad, de mejoramiento, métricas, mecanismos de revisión y control, procesos y actividades. De igual forma que los niveles, cada PA se califica de 1-5. • N0 = Nivel indeterminado o heroico • N1 = Se aplican buenas prácticas • N2 = Se estandariza la metodología / proyecto • N3 = Se “institucionaliza” la metodología a lo largo de la organización • N4 = Cuantificado y administrado • N5 = Optimizado, mejoramiento continuo • Se pueden escoger 2 rutas de mejoramientopara llegar a N5. Evolucionar por nivel (todas las PA del nivel deben ser nivel 5 - CMM). Evolucionar por PA (se define un plan de evolución donde se priorizan unas PA de diferentes niveles según conveniencia - CMMI).

33. El esfuerzo corporativo debe iniciar a partir de una decisión de la dirección. La implementación del modelo debe iniciar en el staff gerencial. La estructura de una empresa de software debería empezar de forma orientada a proyectos. Cuando la empresa genere un producto comercial se incluyen elementos de organización funcional. A medida que se adopta el modelo CMMI se alcanza una organización de tipo Matriz Balanceada. Se recomienda conformar de forma separada la Oficina de Proyectos de la Gerencia de Tecnología. (Inicialmente compuestas por comités de gerentes y arquitectos hasta que la evolución de la compañía amerite un encargado por área.) Conclusiones CMMI:

34. La compañía debe tener un “norte” anual representado en su Plan Estratégico: Mercados, industrias y clientes a “atacar” Generación de nuevos productos o estrategias de comercialización de los existentes Plan de calidad (mejoramiento continuo) Plan de costos Plan de Capacitación ***Crecimiento proyectado (mejorar vs. crecer) Modelo Propuesto: PSP RUP PMI CMMI Six Sigma (corresponde a una metodología integral de optimización de procesos con una base estadística, alcanza su máxima utilidad al nivel 5 de CMMI) CMMI vs. ISO ??? Conclusiones CMMI:

35. Siglas y Abreviaturas I PMI = Project Management Institut PM = Project Manager Q-$-t = Triple Restricción (calidad-Costo-Tiempo) Proc = Procurement = adquisiciones y compras HR = Recursos Humanos COMM = Comunicación EVA = Earned Value Analisys FP = Fixed Price, contratos a precio fijo T&M = Contratos donde el cliente paga al final de cada etapa según el tiempo y materiales invertidos en desarrollar el producto. KLOC = K = mil, LOC = Líneas de código RUP = Rational Unified Process (Modelo Unificado de desarrollo propuesto por Rational Corp.) CU = Caso de Uso PSP = Personal Software Process SEI = Software Engineering Institut CMMI = Capability Maturity Model – Integration

36. Siglas y Abreviaturas II OOP = Object Oriented Programming. COP = Component Oriented Programming. SOC = Separation Of Concerns. IOC = Inversion Of Control. MDA = Model Driven Architecture. SOA = Service Oriented Architecture. AOP = Aspect Oriented Programming.

37. Finalmente… Muchas Gracias por su tiempo !!!