ACIS. Desarrollar proyectos de software y evitar el fracaso?: Conclusiones. Por Bernardo Díaz Arias berdiaz@yahoo.com

Transcripción

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

2 Introducción 1. Conclusiones Gerencia de Proyectos 2. Conclusiones Proceso de Desarrollo 3. Conclusiones Procesos Individuales 4. Conclusiones Procesos Corporativos 5. Conclusiones del Curso

3 1. Gerencia de Proyectos

4 1. Gerencia de Proyectos Problema: El no evaluar la viabilidad de un proyecto, la planeación ligera, la ausencia de monitoreo y retroalimentación permanente minimizan el éxito administrativo de los proyectos de software así todas las demás variables se cumplan Solución Propuesta: El PMI es una organización fundada desde 1969 cuya metodología tiene creciente aceptación mundial y resume las buenas prácticas en Gestión de Proyectos para cualquier industria.

5 1. Gerencia de Proyectos Fortalezas: Promueve la gestión integral (según 9 áreas de procesos). Los procesos de Planeación aplican a cualquier industria Debilidades: No detalla en como se debe ejecutar el proyecto para generar el producto o servicio. (propio de cada industria). No incluye Plantillas Requiere de experiencia para aplicar correctamente los flujos entre procesos.

6 1. Gerencia de Proyectos Oportunidades: Utilizarlo en conjunto con metodologías que definan el proceso de construcción del producto o bien del proyecto. Amenazas: Durante la planeación del proyecto tiende a darse sobrecarga de trabajo para el PM. En nuestro medio no es frecuente que el PM se pueda dedicar tiempo completo a un proyecto así sea complejo / grande.

7 1. Gerencia de Proyectos La gestión de la comunicación es débil, o peor, inexistente en nuestro medio lo que directamente afecta el alcance y entendimiento entre proveedor y cliente. La gestión de la comunicación debe adaptarse según la cultura organizacional del cliente. El éxito del proyecto parte de la evaluación de su viabilidad (administrativa, técnica y funcional) antes de iniciarlo. Es responsabilidad del Gerente Funcional previamente evaluar la viabilidad del proyecto y proveer toda la información administrativa, técnica y funcional a los proveedores. El éxito administrativo en gestionar el alcance se basa en aspectos como: Evaluación de la Viabilidad Plan de comunicación Plan de Gestión de Cambios Plan de Aceptación Administración de riesgos Precondiciones y restricciones contractuales, etc.

8 1. Gerencia de Proyectos El éxito funcional en gestionar el alcance se basa en una adecuada ingeniería de requerimientos. El éxito técnico en gestionar el alcance se basa en tener un conocimiento detallado de la plataforma tecnológica frente a las necesidades del producto. En nuestro medio las empresas proveedoras difícilmente realizan gestión de recursos humanos ya que estos solo se contratan (y rotan) por proyecto. La administración de riesgos es el tema central de las reuniones entre cliente y proveedores desde el inicio al final del proyecto. Los riesgos se pueden gestionar y por tanto comunicar según su grupo: Administrativos Funcionales Técnicos

9 1. Gerencia de Proyectos En la práctica, es un estándar de facto el uso de la herramienta WBS para identificar progresivamente las actividades necesarias para realizar los entregables principales y secundarios del proyecto. En la industria del software se recomienda organizar un WBS según elementos de RUP: Nivel 1. Fase Nivel 2. Disciplina RUP Nivel 3. Entregables. Nivel 4. Macro Actividades Del WBS se deduce el cronograma El esfuerzo final de la planeación es el presupuesto pero este se deduce principalmente del cronograma (actividades+tiempo+recursos). En nuestro medio no es común que el presupuesto incluya gestión de costos indirectos, costo del riesgo y de la holgura del proyecto.

10 1. Gerencia de Proyectos Es recomendable que el Plan del Proyecto se vea como una integración de los subplanes de las 8 áreas de procesos de PMI. Se recomienda que el plan de gestión de la calidad se estructure en 2 grupos: Subplan de Aseguramiento de Calidad (estrategia de implantación de las buenas prácticas de forma particular al proyecto) Subplan de Control de Calidad (Metodología de Pruebas) Las herramientas y técnicas más usadas son: WBS EVA Weighted Scorecard Model

11 2. Proceso de Desarrollo

12 2. Proceso de Desarrollo Problema: La gerencia del proyecto debe conocer el proceso de construcción de software para asegurar que nada se deje al azar, para generar la estratégia de desarrollo adecuada y para la toma de decisiones. El no conocer el cómo se hacen los productos de software crea una brecha mutua entre proveedor y cliente. Solución Propuesta: El Proceso Unificado de Desarrollo, originalmente un enfoque metodológico integral para desarrollar cualquier producto de software (1998) y finalmente un producto de IBM (desde 2002) es la base de diferentes especializaciones como SUN TONE, EUP, Métrica 3, IBM BUP, etc.

13 2. Proceso de Desarrollo Fortalezas: Concebido para ser adaptado a cualquier tipo de desarrollo de software No deja nada al azar (9 disciplinas) Fuerte base conceptual (UML). Orientado a generar resultados de calidad y ágiles para el cliente. Promueve las entregas cortas y ágiles por medio del concepto de desarrollo iterativo, incremental. Implícitamente incluye las dos técnicas más exitosas de optimización de tiempos ( Fasttracking (trabajo progresivo con entregas cortas sucesivas) y Crashing (trabajo en paralelo) ).

14 2. Proceso de Desarrollo Debilidades: La documentación no especifica reglas concretas para tomar la decisión de que plantillas usar en un proyecto particular. La documentación tiene ejemplos generales de cómo adoptarlo (proyecto, compañía) pero no especifica reglas claras de cómo hacerlo en la práctica. El modelamiento por casos de uso no es la alternativa recomendable para proyectos técnicamente complejos y con baja interacción funcional. No es fuerte en administración cuantificada de los procesos. No presenta una solución directa al factor humano como origen de los problemas en proyectos de software. Requiere experiencia y conocimiento para usarlo correctamente Sobrecarga el rol de Arquitecto. El trabajo de cada disciplina se centra en el caso de uso, esta dependencia minimiza la oportunidad de optimizar el trabajo en paralelo.

15 2. Proceso de Desarrollo Oportunidades: Dado que las versiones recientes adoptaron conceptos y terminología PMI se complementan muy bien. Utilizarlo en conjunto con metodologías que definan la administración cuantificada de procesos de software (PSP/TSP). Actualmente la trayectoria práctica permite identificar soluciones a cada una de sus debilidades y amenazas. Amenazas: Su dificultad para ser usado y entendido en la práctica ha generado muchas malinterpretaciones (incluso por expertos ). El hecho de que se halla convertido en producto comercial minimiza su difusión e interpretación metodológica y agrega un factor de costo a su adopción.

16 2. Proceso de Desarrollo Las entregas cortas (Iteraciones) facilitan: Retroalimentación constante con el cliente en aspectos funcionales, administrativos y técnicos del proyecto. Controlar, probar y ajustar productos pequeños (aprox. 4 8 semanas) frente a productos grandes (medidos en meses y años)

17 2. Proceso de Desarrollo Las entregas cortas (Iteraciones) facilitan: Retroalimentación constante con el cliente en aspectos funcionales, administrativos y técnicos del proyecto. Controlar, probar y ajustar productos pequeños (aprox. 4 8 semanas) frente a productos grandes (medidos en meses y años) Los Entregables son el producto (documento o pieza de software) percibido por el cliente frente a una entrega. Los entregables son la medida ideal para centrar la estimación, el monitoreo y control de actividades ya que son los productos finales de la iteración.

18 2. Proceso de Desarrollo Las Fases son etapas de tiempo con objetivos claramente definidos: 1. Incepción: Análisis del negocio/problema, Planeación del proyecto y gestión de requerimientos. 2. Elaboración: Definir y evaluar la arquitectura de referencia, Madurar y detallar los requerimientos como casos de uso. Minimizar los riesgos del proyecto (aprox. 70%). 3. Construcción: Generar una versión completamente funcional y estable del sistema. 4. Transición: Gestiona la adopción del software en la compañía mediante ciclos de pruebas (beta y aceptación), documentación y capacitación acerca del producto (técnica, administrativa y funcional) y finalmente su paso a estado productivo. Las fases ayudan a gestionar el alcance ya que implican que se cierren formalmente etapas en la vida del proyecto.

19 2. Proceso de Desarrollo Cada disciplina RUP consta de: Quién?: Workers/Roles Cuando y Como?: Workflows y Actividades Que?: Artefactos/Plantillas/Entregables

20 2. Proceso de Desarrollo Para simplificar el entendimiento del modelo se recomienda agrupar todos los flujos de actividades de las disciplinas Principales (funcionales, técnicas) y administrativas. El RUP se puede interpretar desde la perspectiva pedagógica de que enseña el como desarrollar productos de software. El RUP se puede interpretar desde la perspectiva práctica de que cada una de las disciplinas debe adoptarse/personalizarse ante las necesidades de cada proyecto. RUP NO obliga a usar toda la carga de artefactos o roles posibles para cada proyecto.

21 2. Proceso de Desarrollo Se recomienda para la adopción práctica de RUP que se identifiquen (por disciplina) los artefactos y roles obligatorios o mínimos para cualquier proyecto, por ejemplo: 1. Visión de Negocio 2. Glosario de Negocio 3. Plan del Proyecto 4. Modelo de Requerimientos 5. Modelo de Casos de Uso 6. Documento de Arquitectura 7. Plan de Pruebas 8. Plan de Administración de la Configuración Según el tamaño del proyecto variaría el contenido de los mismos.

22 2. Proceso de Desarrollo Es un aporte importante de RUP que los roles sean asociados a tipos de actividades específicas ya que facilitan su adopción práctica por que estos pueden ser desde una persona con diferentes roles en diferentes instantes de tiempos (proyectos pequeños) hasta equipos de trabajo por rol (proyectos grandes).

23 2. Proceso de Desarrollo Business Modeling: De forma análoga a la terminología industrial, busca especificar los procesos de información de la organización. Desde la perspectiva del proveedor, es útil para entender el problema organizacional que es causa del proyecto de software. Desde la perspectiva del cliente le sirve para organizar una propuesta de proyecto a partir de un problema.

24 2. Proceso de Desarrollo Requirements: De forma análoga a la terminología industrial, busca especificar los procesos de información del software a partir de identificar y normalizar las necesidades y requerimientos del cliente. Para facilitar su gestión se recomienda agruparlos por subsistemas y módulos. A nivel de industria de software no existe un proceso definido, formal y maduro de normalización de requerimientos. El resultado final de los requerimientos son Casos de Uso (Procesos del Software).

25 2. Proceso de Desarrollo Requirements: Una causa típica de fallos en los proyectos es que se definen como casos de uso macroprocesos/módulos y no procesos específicos (atómicos). A nivel de industria existe el error de definir los Casos de Uso tomando como base el texto, causa frecuente de malintepretaciones entre usuarios y proveedor dada su ambigüedad. En la práctica se recomienda que la definición de los Casos de Uso se base en modelos UML de casos de uso para macroprocesos hasta procesos atómicos. Y diagramas de actividades para modelar el workflow detallado de cada proceso atómico (Caso de Uso).

26 2. Proceso de Desarrollo Analisis & Design: Existe dependencia y centralización del Arquitecto. Desafortunadamente el Análisis y Diseño se basa en el criterio del experto (Arquitecto/Diseñador) ya que no se ha formalizado un proceso que sustente la toma de decisiones de diseño. En la práctica se han desarrollado productos como GeneXus que generan código para cualquier plataforma tecnológica a partir de un modelo de requerimientos. Actualmente se está madurando este concepto en un estándar del OMG llamado MDA (Model Driven Architecture).

27 2. Proceso de Desarrollo Analisis & Design: MDA MDA se basa en tres principios: 1. Modelo de Procesos = Requerimientos 2. Modelo de Integración = a. Modelo de Subsistemas y Módulos b. Modelo de Datos (Conceptual o de dominio y físico) 3. Modelo de la Plataforma tecnológica = Arquitectura de referencia, combinación de capas y patrones de diseño estándar para una plataforma.

28 2. Proceso de Desarrollo Analisis & Design: MDA

29 2. Proceso de Desarrollo Analisis & Design: MDA El resultado o cruce de los tres principios genera el diseño detallado del software. (los procesos son ortogonales a la arquitectura) Finalmente a partir del diseño detallado se genera el código.

30 2. Proceso de Desarrollo Analisis & Design: MDA MDA puede interpretarse desde la perspectiva comercial para definir un estándar de productos CASE. MDA puede aprovecharse desde la perspectiva metodológica para definir un proceso formal y estándar de Análisis y Diseño independiente de la plataforma tecnológica.

31 2. Proceso de Desarrollo Analisis & Design: La industria del software tiene un problema crítico asociado a la alta dependencia del rol de arquitecto frente a la falta de formalización del proceso de análisis y diseño: Se confunde un arquitecto con un desarrollador senior lo cuál afecta el grado de correctitud del producto, así a nivel funcional este cumpla con los requerimientos

32 2. Proceso de Desarrollo Arquitecto: Predomina el pensamiento abstracto y organizado Hábil para estructurar un modelo Evalúa la viabilidad de la solución Actúa de forma independiente de la plataforma tecnológica Evalúa el uso de frameworks Desarrollador Senior: Predomina el pensamiento específico y creativo Hábil para entender código Generalmente es experto y actúa de acuerdo con los lineamientos de una plataforma tecnológica Adopta el uso de frameworks por tendencia

33 2. Proceso de Desarrollo Analisis & Design: Business Integration La globalización ha traído un problema que en este instante la industria del software no ha solucionado de manera formal, definitiva y contundente: Las organizaciones necesitan realizar negocios globales y para ello requieren información consolidada y en tiempo real. Lo anterior implica que los diferentes sistemas de información que conforman la organización se encuentren integrados. A nivel técnico existe una tendencia llamada SOA (Arquitecturas Orientadas a Servicios) que consiste en tipos de productos que intentan solucionar ese problema a partir de dos enfoques el antiguo (mensajería empresarial) y el nuevo (Web Services).

34 3. Procesos Individuales Problema: Un aspecto que origina fracaso en proyectos de software es la falta de habilidades de planeación, organización y productividad de los desarrolladores así como el conocimiento de la gerencia para generarlos La productividad y cumplimiento de un equipo depende de la productividad de las partes Solución Propuesta: Frente a este problema surgío PSP como una propuesta para mejorar la productividad y planeación de los ingenieros. TSP es un set de buenas prácticas especializadas en promover la productividad y empoderamiento de un equipo para lograr los objetivos del proyecto

35 3. Procesos Individuales PSP/TSP: Como moverse de la teoría a la práctica (What To How)? El mejoramiento requiere cambio y promoverlo de forma consistente en actores humanos no es un problema trivial. La metodología se implementa desde dos dimensiones: Parte de la coordinación de un proyecto hacia los miembros Parte de cada miembro hacia el proyecto

36 3. Procesos Individuales En las universidades no se enseña normalmente a como ser productivo Cada persona trabaja según sus convicciones y experiencia en un instante Normalmente cada individuo no acepta ser cuestionado ni se autocuestiona

37 3. Procesos Individuales PSP/TSP => Rapidez + Calidad PSP/TSP => Control cuantitativo PSP/TSP => Cada tipo de actividad debe tener una revisión PSP/TSP => El tiempo de diseño debe ser al menos igual al de desarrollo PSP/TSP => El producto debe entregarse con un 70% de defectos corregidos PSP/TSP => Son la alternativa más ágil para iniciar las buenas prácticas hacia CMMI No dependen/afectan el uso de otras metodologías o herramientas.

38 3. Procesos Individuales (PSP)

39 3. Procesos Individuales (PSP) Se concentra en minimizar tiempo y maximizar calidad => ($) [Deming y Juran (80s)] La mejor manera de incrementar la productividad y calidad de cualquier industria era garantizar el entrenamiento y productividad de las personas PSP se considera un subproducto de CMM [Humphrey *** y Paulk(80s)] Tiene 2 enfoques de implementación: Reactiva y Proactiva. Cada individuo debe medir y controlar su propia productividad

40 3. Procesos Individuales (PSP) 1. Esfuerzo: Total Horas Invertidas 2. Progreso: Variación entre tiempo estimado vs. esfuerzo 3. Calidad: defectos/kloc 4. Productividad: KLOC/hora 5. Estabilidad: Cantidad de modificaciones al producto

41 3. Procesos Individuales (PSP) 1. Objetivo Final [Yield]: En pruebas de aceptación lograr 0.3 defectos/kloc Haber corregido el 70% de los defectos antes de la entrega al cliente 2. Madurez promedio: Después de 4 proyectos. Se realizan estimados confiables a partir de info histórica de 3 últimos proyectos

42 3. Procesos Individuales (PSP) 1. Reporte de Actividades (diario) 2. Plan Detallado (Cronograma) 3. Diseño Detallado (Inventario de clases a desarrollar, Modelos UML clases, secuencias) 4. Reporte de Pruebas Individuales (antes de entregarlo al PM) 5. Resumen de Resultados (métricas y análisis de toda la iteración)

43 3. Procesos Individuales (PSP)

44 3. Procesos Individuales (TSP) A diferencia de PSP es enfático en que el proyecto se cumpla con los costos establecidos. Introduce el concepto de revisiones entre compañeros y revisiones formales al finalizar una etapa (iteración, fase) Dada su complejidad los proyectos actuales son desarrollados por equipos, entre más miembros mayor falta de control. Se deben integrar múltiples roles con visiones diferentes. Se promueve la conciencia de la gerencia y administración a todos los niveles del equipo.

45 3. Procesos Individuales (TSP) Estructura: Team Building & Team Working Incepción Elaboración Construcción Transición

46 3. Procesos Individuales (TSP) Cada fase debe visualizarse entre 2 4 meses Cada Launch está predefinido a 4-5 días (incepción) Cada Relaunch está predefinido a 2-3 días El equipo del proyecto es el directamente responsable de la planeación del proyecto (launch) y la fase (relaunch) La gerencia del proyecto revisa cada plan En cada Launch/relaunch se deben producir planes alternos

47 3. Procesos Individuales (TSP) Teamworking: Manteniendo la productividad adquirida 1. Liderazgo Activo: Asegurarse que cada individuo pueda cumplir los compromisos 2. Comunicación constante de parte de la gerencia 3. Compromiso y motivación de los individuos. Reporte oportuno de incidentes. 4. Disciplina de los individuos (PSP) 5. Los miembros del equipo se apoyan mutuamente 6. Actualizar y balancear las cargas de trabajo 7. Competitividad: Calidad vs. Cantidad

48 3. Procesos Individuales (TSP) TSP Inspections: 1. PSP (Personal Reviews: Manual + Automated) 2. Peer Reviews (Cross Checks) 3. Formal Inspections (por iteración Experto/ disciplina)

49 3. Procesos Individuales (TSP) TSP Inspections: Los 7 pecados capitales Nunca coloque a revisar a alguien que no pueda producir el objeto de revisión. 2. Los participantes no entienden el objetivo de la revisión 3. Los revisores critican el recurso no el producto 4. Las revisiones no se planean y los revisores no están contextualizados 5. Mezclar reuniones de revisión con reuniones de solución 6. Participación de roles no requeridos (Project Manager) 7. El revisor se concentra en la forma no en el contenido

50 4. Procesos Corporativos Problema: Es común que el fracaso en proyectos de software empieze antes de empezar el proyecto debido a la manera artesanal que la empresa proveedora evalúa la viabilidad de los proyectos en los que va a participar, no es consiente de trabajar con buenas prácticas para dar mejores y continuos resultados a sus clientes. Solución Propuesta: El modelo de capacidad y madurez organizacional del SEI tiene vigencia y creciente aceptación desde 1987 como un modelo integrado de procesos basados en buenas prácticas.

51 4. Procesos Corporativos CMM Busca Todas las organizaciones mundiales se administran y operan basadas en sistemas de información La industria del software particularmente tiene bajo desempeño en calidad, cumplimiento y funcionalidad de sus productos. Es artesanal Es un modelo integrado de procesos basados en buenas prácticas Busca lograr la madurez de forma planeada, administrada y medible Se basa en las lecciones aprendidas en la experiencia por metodologías predecesoras Afecta la cultura organizacional Finalmente todos sus procesos estén valorados en capacidad 5. El éxito debe ser predecible

52 4. Procesos Corporativos

53 4. Procesos Corporativos Maturity Level(1-5): Son puntos bien definidos en la evolución de una empresa. 1. Nivel de éxito impredecible / basado en actos heroicos, reactivo Apague los incendios a nivel de proyectos 3. Apagados los incendios defina los procesos para realizar su producto e institucionalizelos en toda la organización 4. Administre sus procesos cuantitativamente 5. Mejore constantemente: Plan Estratégico anual para cada área de procesos, con objetivos, acciones e indicadores.

54 4. Procesos Corporativos

55 4. Procesos Corporativos El modelo continuo es exclusivo de la versión CMMI, CMM en sus diferentes variantes solo incluía la representación por niveles (1-5). Capability (0-5): Los procesos indican el Que hago?, la capacidad indica Como lo estoy haciendo? El objetivo es que todos los procesos estén en estado de mejoramiento continuo.

56 4. Procesos Corporativos

57 4. Procesos Corporativos Estructura de las PA s (KPA s para CMM):

58 4. Procesos Corporativos Common Features: Buscan categorizar prácticas genéricas de la PA a toda la organización Commitment To Perform: Políticas de la PA Ability To Perform: Precondiciones para el éxito de la PA Directing Implementation: Lineamientos prácticos para implementar la PA Verification: Mecanismos para verificar el éxito, estabilidad y trazabilidad de los productos actuales de la PA vs sus definiciones y actividades.

59 4. Procesos Corporativos Tendencias: PeopleCMM: Modelo de madurez para administración (llevar a la madurez, crecimiento integral) de personal. SA CMM: Modelo de madurez para administrar la adquisición de servicios, productos y proyectos de Software.

60 4. Conclusiones del Curso 1. La meta es clara: La ingeniería de software debe convertirse en una ciencia (precisa, formal, detallada, predecible) 2. Las metodologías son herramientas, su éxito depende de cómo las usemos 3. Desafortunadamente cada metodología enfoca solo parte del problema y este debe atacarse de forma integral. 4. El éxito del proyecto no debe depender de factores externos o heroicos sino que debe ser cuidadosamente planeado y controlado.

61 4. Conclusiones del Curso Dada su naturaleza colectiva, el proceso de desarrollo debe enfrentarse de forma integral en los siguientes niveles: Gerencia de Proyectos Metodología de desarrollo Arquitectura del Software Madurez Individual Madurez Corporativa Se busca compartir soluciones exitosas a problemas típicos en el desarrollo de proyectos de software Profundizar en aspectos de la práctica que no son detallados por las metodologías.

62 4. Conclusiones del Curso 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.

63 4. Conclusiones del Curso En la práctica las metodologías facilitan el trabajo Todo modelo de madurez que involucre calidad se basa en el paradigma del mejoramiento continuo (plan-do-check-act).

64 4. Conclusiones del Curso El principal problema que enfrentan las metodologías = resistencia al cambio por: Mitos y malinterpretaciones por falta de información y suficiente experiencia práctica con ellas

65 4. Conclusiones del Curso Tendencias y puntos pendientes en la ingeniería de Software: Formalización de una metodología de análisis y diseño (MDA será la respuesta???) Formalizar una especificación para Business Integration (SOA???) Y después, que nuevos problemas soluciones vendrán????

66 Ahora sí, Finalmente Muchas Gracias por su tiempo!!!