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

ACIS Desarrollar proyectos de software y “evitar” el fracaso ?: Conclusiones Por Bernardo Díaz Arias

Introducción Conclusiones Gerencia de Proyectos
Conclusiones Proceso de Desarrollo Conclusiones Procesos Individuales Conclusiones Procesos Corporativos Conclusiones Generales

1. Gerencia de Proyectos

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.

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.

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.

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.

1. Gerencia de Proyectos 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. En software la mejor alternativa Gana-Gana para tipos de contratos es un híbrido entre T&M/FP = Contrato Marco y Subcontratos (por fases del proyecto). 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.

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

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.

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

1. Gerencia de Proyectos Finalmente el proyecto lo ejecutan las personas que lo conforman. Por lo anterior nunca será suficiente en invertir y mejorar las habilidades de comunicación y administración del recurso humano.

2. Proceso de Desarrollo

2. Proceso de Desarrollo Problema: “La gerencia del proyecto debe conocer en detalle 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 y entre gerente del proyecto y el equipo”. 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.

2. Proceso de Desarrollo Fortalezas:
Concebido para ser adaptado a cualquier tipo de desarrollo de software No deja nada al azar (9 disciplinas estructuradas) Hace énfasis en continuamente administrar y controlar los riesgos del proyecto 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) ).

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 en un proyecto / compañía pero no especifica reglas claras de cómo hacerlo en la práctica. Requiere experiencia y conocimiento para usarlo correctamente Sobrecarga y crea dependencia del 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. 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.

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). De la experiencia práctica se pueden identificar soluciones a cada una de sus debilidades y amenazas. Se complementa con las técnicas de desarrollo ágil. 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.

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)

2. Proceso de Desarrollo Los Entregables son el producto percibido por el cliente frente a una entrega (documentos y piezas de software). 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.

2. Proceso de Desarrollo Las Fases son etapas de tiempo con objetivos claramente definidos: Incepción: Análisis del negocio/problema, Planeación del proyecto y gestión de requerimientos. 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%). Construcción: Generar una versión completamente funcional y estable del sistema (alfa). 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.

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

2. Proceso de Desarrollo Para simplificar el entendimiento del modelo se recomienda agrupar los flujos de actividades de las disciplinas en 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.

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: Visión de Negocio Glosario de Negocio Plan del Proyecto Modelo de Requerimientos Modelo de Casos de Uso Documento de Arquitectura Plan de Pruebas Plan de Administración de la Configuración Según el tamaño del proyecto variaría el contenido de los mismos.

2. Proceso de Desarrollo Es un aporte importante de RUP que los roles sean asociados a grupos de actividades comunes y específicas ya que facilitan su adopción práctica: “Estos pueden ser desde una persona con diferentes roles en diferentes instantes de tiempos (proyectos pequeños) hasta equipos de trabajo que representan un rol (proyectos grandes)”. En la práctica es crucial la confianza del PM en el arquitecto para agilizar la toma de decisiones técnicas.

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 sirve para organizar una propuesta de proyecto a partir de un problema.

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).

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).

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).

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

2. Proceso de Desarrollo Analisis & Design: MDA

El 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.

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 y el criterio experto.

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”

Los defectos arquitectónicos difícilmente se detectan durante las pruebas funcionales. Los defectos arquitectónicos se detectan durante etapas post-productivas a la hora de realizar mantenimientos y mejoras a la aplicación (cuando queda poco o nada por hacer !!!). El impacto de los cambios es impredecible. Un cambio inestabiliza varias partes del código y/o toma mucho tiempo realizarlo. El conocimiento de un arquitecto es escaso y más aún para que un proyecto tenga un arquitecto revisor adicional al que ejecuta el proyecto ($$$).

2. Proceso de Desarrollo Desarrollador Senior: Arquitecto:
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 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

2. Proceso de Desarrollo Desarrollador Senior: Arquitecto:
Adopta el uso de frameworks por tendencia Busca la solución más simple de programar Piensa en lograr los objetivos puntuales del proyecto No sabe no responde o le encantan los EJB de Entidad… Arquitecto: Evalúa el uso de frameworks Busca la solución más simple para el proyecto Busca el mejor balance costo-beneficio al mediano y largo plazo para el cliente Odia los EJB de Entidad (J2EE)…

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).

Otra tendencia frecuentemente malinterpretada es BPM. Tanto la mensajería como los web services y BPM tienen escenarios bien definidos donde deben o no aplicarse. En el mundo de los web services solo existen 3 estándares (WSDL, SOAP, WS-Security) si se usan según el WS-I. Por otro lado existen muchas propuestas de estándares que erróneamente pretenden reinventar el software empresarial pero programando XML. XML y SOAP deben entenderse como un lenguaje estándar para comunicar aplicaciones, no una nueva manera de desarrollarlas.

Finalmente, sea cual sea el desenlace en la estandarización de productos de Business Integration, sabremos si la solución es correcta si al usarla no nos obliga a depender directamente de web services, mensajería o BPM sino que integra transparentemente “servicios”, de negocio…

2. Proceso de Desarrollo TESTING:
En la industria es marcada la falta de estandarización en la terminología de pruebas. No son claras las dependencias y tipos de pruebas y por tanto la estrategia para usarlas mejor… Para proyectos de software, testing es un factor de costos decisivo para el Project Manager. Usualmente se disminuye el énfasis en estas para alcanzar los costos del proyecto.

2. Proceso de Desarrollo TESTING:

2. Proceso de Desarrollo 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 Pruebas de Instalación (checklist de entrega a producción) QA (metodologías y buenas prácticas) y QC (Evaluación del producto, Testing) Niveles de Prueba (Independiente del tipo de prueba) Individual Integrado (módulo/subsistema) Sistema

2. Proceso de Desarrollo Un factor crítico para el éxito es realizar pruebas unitarias exhaustivas. Por clase y método público del sistema. “La estabiliad del todo se basa en la estabilidad de las partes…” Es recomendable automatizar y agrupar las pruebas unitarias por clase, paquete y sistema (Test Cases & Test Suites). Las pruebas unitarias deben ser autónomas e independientes de los datos, por tanto no deben existir dependencias en su orden de ejecución. Todo lo anterior finalmente concluye en un esquema automatizado para pruebas de regresión.

2. Proceso de Desarrollo Las pruebas de regresión son una inversión costosa pero a todas luces sacrificable… El no realizarlas es la causa más común de defectos recurrentes en entregas a producción después de haber realizado “supuestamente” varios ciclos de pruebas.

2. Proceso de Desarrollo Pese a su aparente falta de rigurosidad, las pruebas de Guerrilla son la herramienta más ágil de encontrar defectos. Se recomienda que se agrupen por tipos: Pruebas de Validación Pruebas de Control Pruebas de lógica Pruebas de lógica inversa Pruebas de navegación Pruebas de interacción Pruebas de consistencia / integralidad

2. Proceso de Desarrollo En nuestro medio se menosprecia el valor de las pruebas de performance pero es frecuente que la misma funcionalidad “estable” para un usuario, no lo sea ante casos de múltiples usuarios, condiciones de concurrencia y de carga. Conociendo lo anterior es un riesgo asignarlas exclusivamente en fase de transición (el uso frecuente!!!).

2. Proceso de Desarrollo El cliente debe interpretar las pruebas como la última línea de defensa para implantar o no un software en producción. Generalmente es más costoso para el cliente implantar un software inestable y que no cumpla con la funcionalidad requerida que cancelar su instalación productiva o invertir en pruebas en etapas tempranas del proyecto. En administración de las pruebas es posible que la empresa de software registre niveles altos de calidad (0.3 defectos /KLOC) pero en las pruebas de aceptación y en producción la realidad sea distinta = No hicimos pruebas lo suficientemente exhaustivas…!!!

2. Proceso de Desarrollo Todos entendemos la importancia de las pruebas pero no las hacemos respetar… Finalmente, la única gran verdad en pruebas es que un software nunca se deja de probar, las pruebas simplemente se abandonan…

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 la habilidad 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”

Fortalezas: Efectivos para administrar el performance de cada individuo y su equipo. Orientación netamente práctica Debilidades: No se enfoca en disciplinas técnicas importantes dentro de todo proceso de desarrollo como análisis del negocio, ingeniería de requerimientos, administración del ambiente, configuración, etc. Las plantillas de referencia son redundantes y en general poco ágiles.

Amenazas: La versión más reciente de PSP (Agosto del 2005) trata los mismos conceptos de la original pero es más formal y rigurosa por lo que se puede desvirtuar la practicidad y sencillez del enfoque inicial. TSP NO es un framework de gerencia de proyectos sino de administración y liderazgo de equipos, por lo mismo no remplaza a PMI, lo complementa. Oportunidades: La generación de estadísticas y métricas individuales (PSP) sirven para estimar directamente las del proyecto (TSP) y posteriormente las de la compañía (CMM). Se complementa muy bien con un set de procesos como RUP.

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 del equipo (Reactiva) Parte de cada individuo hacia el proyecto (Proactiva)

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 o se autocuestiona

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.

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

Esfuerzo: Total Horas Invertidas Progreso: Variación entre tiempo estimado vs. esfuerzo Productividad: KLOC/hora Calidad: defectos/KLOC Estabilidad: Cantidad de modificaciones al producto

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…” Madurez promedio: Después de 4 proyectos. “Se realizan estimados confiables a partir de info histórica de 3 últimos proyectos…”

Reporte de Actividades (diario) Plan Detallado (Cronograma) Diseño Detallado (Modelos UML clases, secuencias, Inventario de clases a desarrollar) Reporte de Pruebas (individuales, antes de entregarlo al PM) Resumen de Resultados (métricas y análisis de toda la iteración)

3. Procesos Individuales (TSP)
A diferencia de PSP, es enfático en que el proyecto se cumpla con los costos establecidos (basado en EVA). 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 que exista información acerca de la gerencia y administración en todos los niveles/miembros del equipo.

Estructura: “Team Building & Team Working” Incepción Elaboración Construcción Transición

Es recomendable que cada fase se defina entre 2 – 4 meses aprox. El 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 cada fase (relaunch) La gerencia del proyecto revisa cada plan En cada Launch/relaunch se deben producir planes alternos para agilizar ante posibles rechazos al plan principal

Team working: “Manteniendo la productividad adquirida” Liderazgo Activo = Asegurarse que cada individuo pueda cumplir los compromisos Comunicación constante de parte de la gerencia Compromiso y motivación de los individuos. Reporte oportuno de incidentes. Disciplina de los individuos (PSP) Los miembros del equipo se apoyan mutuamente Actualizar y balancear las cargas de trabajo Competitividad: Calidad vs. Cantidad

TSP Inspections: PSP (Personal Reviews: Manual + Automated) Peer Reviews (Cross Checks) Formal Inspections (por iteración – Experto/ disciplina)

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

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 (sino para cumplir un requisito del mercado).” “Un buen Project Manager, arquitecto o desarrollador solamente avanza hasta donde la empresa para la que trabaja le permite…” 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.”

Fortalezas: Consolida varias metodologías y buenas prácticas Su adopción es en todo sentido un proyecto con un punto de inicio, presupuesto, riesgos, entregables y objetivos claramente delimitados. El progreso es constante y cuantitativamente administrado. En la práctica se ha descubierto que aplica para diferentes tipos de industrias Debilidades: Hereda las debilidades de las metodologías en las que se basa.

Amenazas: Ser usada para ganar ventaja competitiva en el mercado antes que para mejorar la efectividad y rentabilidad de los proyectos actuales. Cada compañía debe adaptar los lineamientos y buenas prácticas y definir sus propios procesos. Esto se presta para definiciones ligeras y poco precisas donde la toma de decisiones finalmente sigue quedando a criterio experto (como generar la estrategia de testing?, en que pasos realizar el análisis y diseño?, como identificar los objetivos de planeación en cada fase del proyecto?, etc.). Requiere un papel activo de parte del cliente. En la práctica el mercado impone restricciones como contratos a precio fijo, desinformación e inexperiencia de los clientes. Oportunidades: Se complementa/basa en PMI, RUP, PSP y TSP. De acuerdo con la estructura organizacional puede adoptar grupos de procesos de otros modelos de madurez (como PeopleCMM para recursos humanos, etc.).

CMM… Todas las organizaciones mundiales se administran y operan con base en sistemas de información La industria del software particularmente tiene bajo desempeño en calidad, cumplimiento y funcionalidad de sus productos. Es artesanal (criterio experto)… 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

CMM… Afecta la cultura organizacional La toma de decisiones debe basarse en hechos concretos y medibles (Weighted Scoring Model) Finalmente todos los procesos deben estar valorados en capacidad 5. “El éxito debe ser predecible…”

Maturity Levels (1-5): “Son puntos bien definidos en la evolución de una empresa” “Nivel de éxito impredecible / basado en actos heroicos, reactivo...” “Apague los incendios a nivel de proyectos” “Apagados los incendios defina los procesos para realizar su producto, institucionalizelos en toda la organización” Administre sus procesos cuantitativamente = Obtenga calificaciones altas, estables y predecibles en estimaciones y métricas (como esfuerzo, progreso, productividad, etc.). Ahh!! Y lógrelo en todos los proyectos de su compañía de forma consistente en el tiempo. Mejore constantemente: “Plan Estratégico anual para cada área de procesos, con objetivos, acciones(proyectos) e indicadores.”

Maturity Levels (1-5): Acá estamos… Implemente PMI, ingeniería de requerimientos, inicie PSP. Planee e inicie la ejecución del nivel 3 (RUP). Lo difícil acá es la resistencia al cambio. Madure las buenas prácticas de RUP e inicie TSP cuando los miembros de la compañía sean maduros en PSP. Planee e inicie la ejecución del nivel 4. Lo difícil acá es la cantidad de disciplinas o áreas de procesos que se deben institucionalizar.

Maturity Levels (1-5): Acá será fácil obtener un base line consistente de los indicadores y métricas corporativos a partir de los de cada equipo/proyecto. Planee e inicie la ejecución del nivel 5. Lo difícil acá no es cuantificar (lo que debió iniciar desde el nivel 2) sino cuantificar bien y consistentemente entre proyectos en el tiempo. Logrados los objetivos anteriores, en este nivel se deben madurar los mecanismos corporativos que constantemente evalúen y preventivamente apliquen mejoras a los procesos implantados. Cuando se ha llegado a este nivel es la mejor oportunidad de implementar las técnicas de optimización estadística de SIX Sigma. En niveles previos el costo del esfuerzo no va a compensar el posible resultado.

Maturity Levels (1-5): La viabilidad de la implantación de CMM depende de la convicción de la alta gerencia y la capacitación y experiencia de la gerencia de proyectos. El reto del nivel 2 es la resistencia al cambio El nivel 3 es el más largo El nivel 4 es el más dificil de lograr Si lo anterior se realizó bien, el nivel 5 es el más facil de lograr.

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 alcancen el estado de mejoramiento continuo.

La representación continua es más flexible por que parte del estado particular de la organización (madurez técnica, costos, cultura). La representación por niveles es más segura para lograr la madurez pero requiere un esfuerzo corporativo sincronizado que se refleja en los costos. Para una empresa pequeña es más fácil sincronizar esfuerzos y por lo general más viable adaptar una representación por niveles. Para una empresa relativamente madura y con gran cantidad de personal (aprox. > 200) es recomendable primero realizar una homologación y valoración para la toma de decisiones sobre el tipo de representación a seguir.

Estructura de las PA’s (KPA’s para CMM):

Generis Goals, 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.

Tendencias: PeopleCMM: Modelo de madurez para administración de personal (llevar a la madurez profesional y crecimiento integral dentro de la organización). SA – CMM: Modelo de madurez para administrar la adquisición de servicios, productos y proyectos de Software.

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

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 y como equipo Madurez Corporativa Se busca compartir soluciones exitosas a problemas típicos en el desarrollo de proyectos de software Se busca profundizar en aspectos de la práctica que no son detallados por las metodologías.

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.

En la práctica las metodologías facilitan el trabajo, en caso contrario las está usando mal !!!. Todo modelo de madurez que involucre calidad se basa en el paradigma del mejoramiento continuo (plan-do-check-act).

Lo que casi nadie sabe es que las metodologías expuestas se extrajeron y formalizaron a partir de la experiencia práctica. Puede que usted halla hecho PMI sin saberlo…??? El principal problema que enfrentan las metodologías = resistencia al cambio: “Mitos y malinterpretaciones, por falta de información y suficiente experiencia práctica con ellas”

Tendencias y fallas latentes en la ingeniería de Software: Formalización de una metodología de análisis y diseño (MDA será la respuesta???) Formalización de una metodología de normalización de requerimientos (normalización???) Formalizar una especificación para productos de Business Integration (SOA ???) Y después, que nuevos problemas – soluciones, retos y paradigmas vendrán ????

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

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

Presentaciones similares

Presentación del tema: "ACIS Desarrollar proyectos de software y “evitar” el fracaso ?: Conclusiones Por Bernardo Díaz Arias berdiaz@yahoo.com."— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback

Iniciar la sesión

Autorizarse a través de una red social:

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

Presentaciones similares

Presentación del tema: "ACIS Desarrollar proyectos de software y “evitar” el fracaso ?: Conclusiones Por Bernardo Díaz Arias berdiaz@yahoo.com."— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback