ACIS

Desarrollar proyectos de software y evitar el fracaso ?: Conclusiones

Por Bernardo Daz Arias berdiaz@yahoo.com

Introduccin
1. Conclusiones Gerencia de Proyectos 2. Conclusiones Proceso de Desarrollo

3. Conclusiones Procesos Individuales

4. Conclusiones Procesos Corporativos 5. Conclusiones Generales

1. Gerencia de Proyectos

1. Gerencia de Proyectos
Problema: El no evaluar la viabilidad de un proyecto, la planeacin ligera, la ausencia de monitoreo y retroalimentacin permanente minimizan el xito administrativo de los proyectos de software as todas las dems variables se cumplan Solucin Propuesta: El PMI es una organizacin fundada desde 1969 cuya metodologa tiene creciente aceptacin mundial y resume las buenas prcticas en Gestin de Proyectos para cualquier industria.

1. Gerencia de Proyectos
Fortalezas: Promueve la gestin integral (segn 9 reas de procesos). Los procesos de Planeacin 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 metodologas que definan el proceso de construccin del producto o bien del proyecto. Amenazas: Durante la planeacin 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 gestin de la comunicacin es dbil, o peor, inexistente en nuestro medio lo que directamente afecta el alcance y entendimiento entre proveedor y cliente. La gestin de la comunicacin debe adaptarse segn la cultura organizacional del cliente. El xito del proyecto parte de la evaluacin de su viabilidad (administrativa, tcnica y funcional) antes de iniciarlo.

1. Gerencia de Proyectos
Es responsabilidad del Gerente Funcional previamente evaluar la viabilidad del proyecto y proveer toda la informacin administrativa, tcnica y funcional a los proveedores. En software la mejor alternativa Gana-Gana para tipos de contratos es un hbrido entre T&M/FP = Contrato Marco y Subcontratos (por fases del proyecto). El xito administrativo en gestionar el alcance se basa en aspectos como:
Evaluacin de la Viabilidad Plan de comunicacin Plan de Gestin de Cambios Plan de Aceptacin Administracin de riesgos Precondiciones y restricciones contractuales, etc.

1. Gerencia de Proyectos
El xito funcional en gestionar el alcance se basa en una adecuada ingeniera de requerimientos. El xito tcnico en gestionar el alcance se basa en tener un conocimiento detallado de la plataforma tecnolgica frente a las necesidades del producto. En nuestro medio las empresas proveedoras difcilmente realizan gestin de recursos humanos ya que estos solo se contratan (y rotan) por proyecto. La administracin 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 segn su grupo:
Administrativos Funcionales Tcnicos

1. Gerencia de Proyectos
En la prctica, es un estndar 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 segn elementos de RUP:
Nivel Nivel Nivel Nivel 1. 2. 3. 4. Fase Disciplina RUP Entregables. Macro Actividades

Del WBS se deduce el cronograma El esfuerzo final de la planeacin es el presupuesto pero este se deduce principalmente del cronograma (actividades+tiempo+recursos). En nuestro medio no es comn que el presupuesto incluya gestin 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 integracin de los subplanes de las 8 reas de procesos de PMI. Se recomienda que el plan de gestin de la calidad se estructure en 2 grupos:
Subplan de Aseguramiento de Calidad (estrategia de implantacin de las buenas prcticas de forma particular al proyecto) Subplan de Control de Calidad (Metodologa de Pruebas)

Las herramientas y tcnicas ms 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 comunicacin y administracin del recurso humano.

2. Proceso de Desarrollo

2. Proceso de Desarrollo
Problema: La gerencia del proyecto debe conocer en detalle el proceso de construccin de software para asegurar que nada se deje al azar, para generar la estratgia de desarrollo adecuada y para la toma de decisiones. El no conocer el cmo se hacen los productos de software crea una brecha mutua entre proveedor y cliente y entre gerente del proyecto y el equipo. Solucin Propuesta: El Proceso Unificado de Desarrollo, originalmente un enfoque metodolgico 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, Mtrica 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.
Implcitamente incluye las dos tcnicas ms exitosas de optimizacin de tiempos ( Fasttracking (trabajo progresivo con entregas cortas sucesivas) y Crashing (trabajo en paralelo) ).

2. Proceso de Desarrollo
Debilidades: La documentacin no especifica reglas concretas para tomar la decisin de que plantillas usar en un proyecto particular. La documentacin tiene ejemplos generales de cmo adoptarlo en un proyecto / compaa pero no especifica reglas claras de cmo hacerlo en la prctica. 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 tcnicamente complejos y con baja interaccin funcional. No es fuerte en administracin cuantificada de los procesos. No presenta una solucin 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 terminologa PMI se complementan muy bien. Utilizarlo en conjunto con metodologas que definan la administracin cuantificada de procesos de software (PSP/TSP). De la experiencia prctica se pueden identificar soluciones a cada una de sus debilidades y amenazas. Se complementa con las tcnicas de desarrollo gil. Amenazas: Su dificultad para ser usado y entendido en la prctica ha generado muchas malinterpretaciones (incluso por expertos). El hecho de que se halla convertido en producto comercial minimiza su difusin e interpretacin metodolgica y agrega un factor de costo a su adopcin.

2. Proceso de Desarrollo
Las entregas cortas (Iteraciones) facilitan:
Retroalimentacin constante con el cliente en aspectos funcionales, administrativos y tcnicos del proyecto. Controlar, probar y ajustar productos pequeos (aprox. 4 8 semanas) frente a productos grandes (medidos en meses y aos)

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 estimacin, el monitoreo y control de actividades ya que son los productos finales de la iteracin.

2. Proceso de Desarrollo
Las Fases son etapas de tiempo con objetivos claramente definidos:
1. 2. 3. 4. Incepcin: Anlisis del negocio/problema, Planeacin del proyecto y gestin de requerimientos. Elaboracin: Definir y evaluar la arquitectura de referencia, Madurar y detallar los requerimientos como casos de uso. Minimizar los riesgos del proyecto (aprox. 70%). Construccin: Generar una versin completamente funcional y estable del sistema (alfa). Transicin: Gestiona la adopcin del software en la compaa mediante ciclos de pruebas (beta y aceptacin), documentacin y capacitacin acerca del producto (tcnica, 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:
Quin?: 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, tcnicas y administrativas. El RUP se puede interpretar desde la perspectiva pedaggica de que ensea el como desarrollar productos de software. El RUP se puede interpretar desde la perspectiva prctica 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 adopcin prctica de RUP que se identifiquen (por disciplina) los artefactos y roles obligatorios o mnimos para cualquier proyecto, por ejemplo:
1. 2. 3. 4. 5. 6. 7. 8. Visin de Negocio Glosario de Negocio Plan del Proyecto Modelo de Requerimientos Modelo de Casos de Uso Documento de Arquitectura Plan de Pruebas Plan de Administracin de la Configuracin

Segn el tamao del proyecto variara 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 especficas ya que facilitan su adopcin prctica: Estos pueden ser desde una persona con diferentes roles en diferentes instantes de tiempos (proyectos pequeos) hasta equipos de trabajo que representan un rol (proyectos grandes).
En la prctica es crucial la confianza del PM en el arquitecto para agilizar la toma de decisiones tcnicas.

2. Proceso de Desarrollo
Business Modeling: De forma anloga a la terminologa industrial, busca especificar los procesos de informacin de la organizacin.
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 anloga a la terminologa industrial, busca especificar los procesos de informacin del software a partir de identificar y normalizar las necesidades y requerimientos del cliente. Para facilitar su gestin se recomienda agruparlos por subsistemas y mdulos. A nivel de industria de software no existe un proceso definido, formal y maduro de normalizacin de requerimientos. El resultado final de los requerimientos son Casos de Uso (Procesos del Software).

2. Proceso de Desarrollo
Requirements: Una causa tpica de fallos en los proyectos es que se definen como casos de uso macroprocesos/mdulos y no procesos especficos (atmicos). 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 ambigedad. En la prctica se recomienda que la definicin de los Casos de Uso se base en modelos UML de casos de uso para macroprocesos hasta procesos atmicos. Y diagramas de actividades para modelar el workflow detallado de cada proceso atmico (Caso de Uso).

2. Proceso de Desarrollo
Analisis & Design: Existe dependencia y centralizacin del Arquitecto. Desafortunadamente el Anlisis y Diseo se basa en el criterio del experto (Arquitecto/Diseador) ya que no se ha formalizado un proceso que sustente la toma de decisiones de diseo. En la prctica se han desarrollado productos como GeneXus que generan cdigo para cualquier plataforma tecnolgica a partir de un modelo de requerimientos. Actualmente se est madurando este concepto en un estndar del OMG llamado MDA (Model Driven Architecture).

2. Proceso de Desarrollo
Analisis & Design: MDA MDA se basa en tres principios (paralelos):
1. Modelo de Procesos = Requerimientos 2. Modelo de Integracin = a. Modelo de Subsistemas y Mdulos b. Modelo de Datos (Conceptual o de dominio y fsico) 3. Modelo de la Plataforma tecnolgica = Arquitectura de referencia, combinacin de capas y patrones de diseo estndar para una plataforma.

2. Proceso de Desarrollo
Analisis & Design: MDA

2. Proceso de Desarrollo
Analisis & Design: MDA El cruce de los tres principios genera el diseo detallado del software. (los procesos son ortogonales a la arquitectura) Finalmente a partir del diseo detallado se genera el cdigo.

2. Proceso de Desarrollo
Analisis & Design: MDA
MDA puede interpretarse desde la perspectiva comercial para definir un estndar de productos CASE. MDA puede aprovecharse desde la perspectiva metodolgica para definir un proceso formal y estndar de Anlisis y Diseo independiente de la plataforma tecnolgica y el criterio experto.

2. Proceso de Desarrollo
Analisis & Design: La industria del software tiene un problema crtico asociado a la alta dependencia del rol de arquitecto frente a la falta de formalizacin del proceso de anlisis y diseo: Se confunde un arquitecto con un desarrollador senior lo cul afecta el grado de correctitud del producto, as a nivel funcional este cumpla con los requerimientos

2. Proceso de Desarrollo
Analisis & Design: Los defectos arquitectnicos difcilmente se detectan durante las pruebas funcionales. Los defectos arquitectnicos se detectan durante etapas post-productivas a la hora de realizar mantenimientos y mejoras a la aplicacin (cuando queda poco o nada por hacer !!!). El impacto de los cambios es impredecible. Un cambio inestabiliza varias partes del cdigo y/o toma mucho tiempo realizarlo. El conocimiento de un arquitecto es escaso y ms an para que un proyecto tenga un arquitecto revisor adicional al que ejecuta el proyecto ($$$).

2. Proceso de Desarrollo
Arquitecto:
Predomina el pensamiento abstracto

Desarrollador Senior:

y organizado Hbil para estructurar un modelo

Predomina el pensamiento especfico y creativo

Hbil para entender cdigo Generalmente es experto y acta de acuerdo con los lineamientos de una plataforma tecnolgica

Evala la viabilidad de la solucin Acta de forma independiente de la plataforma tecnolgica

2. Proceso de Desarrollo
Arquitecto: Evala el uso de frameworks Desarrollador Senior: Adopta el uso de frameworks por tendencia Busca la solucin ms simple de programar Piensa en lograr los objetivos puntuales del proyecto No sabe no responde o le encantan los EJB de Entidad

Busca la solucin ms 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 globalizacin ha trado 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 informacin consolidada y en tiempo real. Lo anterior implica que los diferentes sistemas de informacin que conforman la organizacin se encuentren integrados. A nivel tcnico 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 (mensajera empresarial) y el nuevo (Web Services).

2. Proceso de Desarrollo
Analisis & Design: Business Integration Otra tendencia frecuentemente malinterpretada es BPM. Tanto la mensajera 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 estndares (WSDL, SOAP, WS-Security) si se usan segn el WS-I. Por otro lado existen muchas propuestas de estndares que errneamente pretenden reinventar el software empresarial pero programando XML. XML y SOAP deben entenderse como un lenguaje estndar para comunicar aplicaciones, no una nueva manera de desarrollarlas.

2. Proceso de Desarrollo
Analisis & Design: Business Integration
Finalmente, sea cual sea el desenlace en la estandarizacin de productos de Business Integration, sabremos si la solucin es correcta si al usarla no nos obliga a depender directamente de web services, mensajera o BPM sino que integra transparentemente servicios, de negocio

2. Proceso de Desarrollo
TESTING: En la industria es marcada la falta de estandarizacin en la terminologa 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
QA (metodologas y buenas prcticas) y QC (Evaluacin del producto, Testing) Niveles de Prueba (Independiente del tipo de prueba) Individual Integrado (mdulo/subsistema) Sistema
Fases de Prueba (ciclos y estados del producto)
1. Alfa (generalmente se alcanza al final de la fase de construccin) 2. Beta (primer ciclo estable de pruebas funcionales de transicin) 3. Aceptacin 4. Pruebas de Instalacin (checklist de entrega a produccin)

2. Proceso de Desarrollo
Un factor crtico para el xito es realizar pruebas unitarias exhaustivas. Por clase y mtodo pblico 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 autnomas e independientes de los datos, por tanto no deben existir dependencias en su orden de ejecucin. Todo lo anterior finalmente concluye en un esquema automatizado para pruebas de regresin.

2. Proceso de Desarrollo
Las pruebas de regresin son una inversin costosa pero a todas luces sacrificable El no realizarlas es la causa ms comn de defectos recurrentes en entregas a produccin despus 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 ms gil de encontrar defectos. Se recomienda que se agrupen por tipos:
1. 2. 3. 4. 5. 6. 7. Pruebas Pruebas Pruebas Pruebas Pruebas Pruebas Pruebas de de de de de de de Validacin Control lgica lgica inversa navegacin interaccin 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 mltiples usuarios, condiciones de concurrencia y de carga. Conociendo lo anterior es un riesgo asignarlas exclusivamente en fase de transicin (el uso frecuente!!!).

2. Proceso de Desarrollo
El cliente debe interpretar las pruebas como la ltima lnea de defensa para implantar o no un software en produccin. Generalmente es ms costoso para el cliente implantar un software inestable y que no cumpla con la funcionalidad requerida que cancelar su instalacin productiva o invertir en pruebas en etapas tempranas del proyecto. En administracin de las pruebas es posible que la empresa de software registre niveles altos de calidad (0.3 defectos /KLOC) pero en las pruebas de aceptacin y en produccin 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 planeacin, organizacin 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 Solucin Propuesta: Frente a este problema surgo PSP como una propuesta para mejorar la productividad y planeacin de los ingenieros.

TSP es un set de buenas prcticas especializadas en promover la productividad y empoderamiento de un equipo para lograr los objetivos del proyecto

3. Procesos Individuales
Fortalezas:

Efectivos para administrar el performance de cada individuo y su equipo.

Orientacin netamente prctica

Debilidades: No se enfoca en disciplinas tcnicas importantes dentro de todo proceso de desarrollo como anlisis del negocio, ingeniera de requerimientos, administracin del ambiente, configuracin, etc. Las plantillas de referencia son redundantes y en general poco giles.

3. Procesos Individuales
Oportunidades:

La generacin de estadsticas y mtricas individuales (PSP) sirven para estimar directamente las del proyecto (TSP) y posteriormente las de la compaa (CMM). Se complementa muy bien con un set de procesos como RUP.

Amenazas: La versin ms reciente de PSP (Agosto del 2005) trata los mismos conceptos de la original pero es ms 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 administracin y liderazgo de equipos, por lo mismo no remplaza a PMI, lo complementa.

3. Procesos Individuales
PSP/TSP: Como moverse de la teora a la prctica (What To How)? El mejoramiento requiere cambio y promoverlo de forma consistente en actores humanos no es un problema trivial.
La metodologa se implementa desde dos dimensiones:
Parte de la coordinacin de un proyecto hacia los miembros del equipo (Reactiva) Parte de cada individuo hacia el proyecto (Proactiva)

3. Procesos Individuales
En las universidades no se ensea normalmente a como ser productivo Cada persona trabaja segn sus convicciones y experiencia en un instante
Normalmente cada individuo no acepta ser cuestionado o se autocuestiona

3. Procesos Individuales

PSP/TSP => Rapidez + Calidad

PSP/TSP => Control cuantitativo PSP/TSP => Cada tipo de actividad debe tener una revisin PSP/TSP => El tiempo de diseo 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 ms gil para iniciar las buenas prcticas hacia CMMI No dependen/afectan el uso de otras metodologas o herramientas.

3. Procesos Individuales (PSP)

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 implementacin: Reactiva y Proactiva.

Cada individuo debe medir y controlar su propia productividad

3. Procesos Individuales (PSP)

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. Procesos Individuales (PSP)

1. Objetivo Final [Yield]: En pruebas de aceptacin lograr 0.3 defectos/KLOC
Haber corregido el 70% de los defectos antes de la entrega al cliente

2. Madurez promedio: Despus de 4 proyectos.

Se realizan estimados confiables a partir de info histrica de 3 ltimos proyectos

3. Procesos Individuales (PSP)

1. Reporte de Actividades (diario) 2. Plan Detallado (Cronograma) 3. Diseo Detallado (Modelos UML clases, secuencias, Inventario de clases a desarrollar)

4. Reporte de Pruebas (individuales, antes de entregarlo al PM)

5. Resumen de Resultados (mtricas y anlisis de toda la iteracin)

3. Procesos Individuales (PSP)

3. Procesos Individuales (TSP)

A diferencia de PSP, es enftico en que el proyecto se cumpla con los costos establecidos (basado en EVA).
Introduce el concepto de revisiones entre compaeros y revisiones formales al finalizar una etapa (iteracin, fase) Dada su complejidad los proyectos actuales son desarrollados por equipos, entre ms miembros mayor falta de control. Se deben integrar mltiples roles con visiones diferentes. Se promueve que exista informacin acerca de la gerencia y administracin en todos los niveles/miembros del equipo.

3. Procesos Individuales (TSP)

Estructura: Team Building & Team Working Incepcin Elaboracin Construccin Transicin

3. Procesos Individuales (TSP)

Es recomendable que cada fase se defina entre 2 4 meses aprox.
El Launch est predefinido a 4-5 das (incepcin) Cada Relaunch est predefinido a 2-3 das El equipo del proyecto es el directamente responsable de la planeacin 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

3. Procesos Individuales (TSP)

Team working: Manteniendo la productividad adquirida
1. Liderazgo Activo = Asegurarse que cada individuo pueda cumplir los compromisos

2. Comunicacin constante de parte de la gerencia

3. Compromiso y motivacin 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

3. Procesos Individuales (TSP)

TSP Inspections:
1. PSP (Personal Reviews: Manual + Automated) 2. Peer Reviews (Cross Checks) 3. Formal Inspections (por iteracin Experto/ disciplina)

3. Procesos Individuales (TSP)

TSP Inspections: Los 7 pecados capitales...
1. Nunca coloque a revisar a alguien que no pueda producir el objeto de revisin. 2. Los participantes no entienden el objetivo de la revisin 3. Los revisores critican el recurso no el producto 4. Las revisiones no se planean y los revisores no estn contextualizados 5. Mezclar reuniones de revisin con reuniones de solucin 6. Participacin de roles no requeridos (Project Manager) 7. El revisor se concentra en la forma no en el contenido

4. Procesos Corporativos
Problema: Es comn que el fracaso en proyectos de software empieze antes de empezar el proyecto debido a la manera artesanal que la empresa proveedora evala la viabilidad de los proyectos en los que va a participar, no es consiente de trabajar con buenas prcticas 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

Solucin Propuesta: El modelo de capacidad y madurez organizacional del SEI tiene vigencia y creciente aceptacin desde 1987 como un modelo integrado de procesos basados en buenas prcticas.

4. Procesos Corporativos
Fortalezas: Consolida varias metodologas y buenas prcticas Su adopcin 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 prctica se ha descubierto que aplica para diferentes tipos de industrias Debilidades: Hereda las debilidades de las metodologas en las que se basa.

4. Procesos Corporativos
Amenazas: Oportunidades: Ser usada para ganar ventaja competitiva en el mercado antes que para mejorar la efectividad y rentabilidad de los proyectos Se complementa/basa en PMI, RUP, actuales. 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.). Cada compaa debe adaptar los lineamientos y buenas prcticas 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 anlisis y diseo?, como identificar los objetivos de planeacin en cada fase del proyecto?, etc.). Requiere un papel activo de parte del cliente. En la prctica el mercado impone restricciones como contratos a precio fijo, desinformacin e inexperiencia de los clientes.

4. Procesos Corporativos

CMM
Todas las organizaciones mundiales se administran y operan con base en sistemas de informacin

La industria del software particularmente tiene bajo desempeo en calidad, cumplimiento y funcionalidad de sus productos. Es artesanal (criterio experto)
Es un modelo integrado de procesos basados en buenas prcticas Busca lograr la madurez de forma planeada, administrada y medible

Se basa en las lecciones aprendidas en la experiencia por metodologas predecesoras

4. Procesos Corporativos
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

4. Procesos Corporativos

4. Procesos Corporativos
Maturity Levels (1-5): Son puntos bien definidos

en la evolucin de una empresa

1. Nivel de xito impredecible / basado en actos heroicos, reactivo...

2. Apague los incendios a nivel de proyectos

3. Apagados los incendios defina los procesos para realizar su producto, institucionalizelos en toda la organizacin

4. Administre sus procesos cuantitativamente = Obtenga calificaciones altas, estables y predecibles en estimaciones y mtricas (como esfuerzo, progreso, productividad, etc.). Ahh!! Y lgrelo en todos los proyectos de su compaa de forma consistente en el tiempo. 5. Mejore constantemente: Plan Estratgico anual para cada rea de procesos, con objetivos, acciones(proyectos) e indicadores.

4. Procesos Corporativos
Maturity Levels (1-5):
1. Ac estamos

2. Implemente PMI, ingeniera de requerimientos, inicie PSP. Planee e inicie la ejecucin del nivel 3 (RUP). Lo difcil ac es la resistencia al cambio.
3. Madure las buenas prcticas de RUP e inicie TSP cuando los miembros de la compaa sean maduros en PSP. Planee e inicie la ejecucin del nivel 4. Lo difcil ac es la cantidad de disciplinas o reas de procesos que se deben institucionalizar.

4. Procesos Corporativos
Maturity Levels (1-5):
4. Ac ser fcil obtener un base line consistente de los indicadores y mtricas corporativos a partir de los de cada equipo/proyecto. Planee e inicie la ejecucin del nivel 5. Lo difcil ac no es cuantificar (lo que debi iniciar desde el nivel 2) sino cuantificar bien y consistentemente entre proyectos en el tiempo. 5. Logrados los objetivos anteriores, en este nivel se deben madurar los mecanismos corporativos que constantemente evalen y preventivamente apliquen mejoras a los procesos implantados. Cuando se ha llegado a este nivel es la mejor oportunidad de implementar las tcnicas de optimizacin estadstica de SIX Sigma. En niveles previos el costo del esfuerzo no va a compensar el posible resultado.

4. Procesos Corporativos
Maturity Levels (1-5):
La viabilidad de la implantacin de CMM depende de la conviccin de la alta gerencia y la capacitacin y experiencia de la gerencia de proyectos.
El reto del nivel 2 es la resistencia al cambio El nivel 3 es el ms largo El nivel 4 es el ms dificil de lograr Si lo anterior se realiz bien, el nivel 5 es el ms facil de lograr.

4. Procesos Corporativos

4. Procesos Corporativos
El modelo continuo es exclusivo de la versin CMMI. CMM en sus diferentes variantes solo inclua la representacin 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.

4. Procesos Corporativos

4. Procesos Corporativos
La representacin continua es ms flexible por que parte del estado particular de la organizacin (madurez tcnica, costos, cultura). La representacin por niveles es ms segura para lograr la madurez pero requiere un esfuerzo corporativo sincronizado que se refleja en los costos. Para una empresa pequea es ms fcil sincronizar esfuerzos y por lo general ms viable adaptar una representacin por niveles.

Para una empresa relativamente madura y con gran cantidad de personal (aprox. > 200) es recomendable primero realizar una homologacin y valoracin para la toma de decisiones sobre el tipo de representacin a seguir.

4. Procesos Corporativos
Estructura de las PAs (KPAs para CMM):

4. Procesos Corporativos
Generis Goals, Common Features: Buscan
categorizar prcticas genricas de la PA a toda la organizacin
Commitment To Perform = Polticas de la PA

Ability To Perform = Precondiciones para el xito de la PA

Directing Implementation = Lineamientos prcticos 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.

4. Procesos Corporativos
Tendencias:
PeopleCMM: Modelo de madurez para administracin de personal (llevar a la madurez profesional y crecimiento integral dentro de la organizacin). SA CMM: Modelo de madurez para administrar la adquisicin de servicios, productos y proyectos de Software.

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. El xito del proyecto no debe depender de factores externos o heroicos (criterio experto) sino que debe ser cuidadosamente planeado y controlado.

2.

3.

4.

4. Conclusiones Generales
Dada su naturaleza colectiva, el proceso de desarrollo debe enfrentarse de forma integral en los siguientes niveles:
Gerencia de Proyectos Metodologa de desarrollo Arquitectura del Software Madurez Individual y como equipo Madurez Corporativa

Se busca compartir soluciones exitosas a problemas tpicos en el desarrollo de proyectos de software Se busca profundizar en aspectos de la prctica que no son detallados por las metodologas.

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
En la prctica las metodologas 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).

4. Conclusiones Generales
Lo que casi nadie sabe es que las metodologas expuestas se extrajeron y formalizaron a partir de la experiencia prctica. Puede que usted halla hecho PMI sin saberlo??? El principal problema que enfrentan las metodologas = resistencia al cambio: Mitos y malinterpretaciones, por falta de informacin y suficiente experiencia prctica con ellas

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

Muchas Gracias por su tiempo !!!