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 del Curso

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. Es responsabilidad del Gerente Funcional previamente evaluar la viabilidad del proyecto y proveer toda la informacin administrativa, tcnica y funcional a los proveedores. 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

2. Proceso de Desarrollo

2. Proceso de Desarrollo
Problema: La gerencia del proyecto debe conocer 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. 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) 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 (proyecto, compaa) pero no especifica reglas claras de cmo hacerlo en la prctica. 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. 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). Actualmente la trayectoria prctica permite identificar soluciones a cada una de sus debilidades y amenazas. 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
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)

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 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. 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 todos los flujos de actividades de las disciplinas Principales (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 tipos de actividades especficas ya que facilitan su adopcin prctica por que estos pueden ser desde una persona con diferentes roles en diferentes instantes de tiempos (proyectos pequeos) hasta equipos de trabajo por rol (proyectos grandes).

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 le 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:
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 resultado o 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.

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
Arquitecto:
Predomina el pensamiento abstracto

Desarrollador Senior: Predomina el pensamiento especfico y creativo Hbil para entender cdigo Generalmente es experto y acta de acuerdo con los lineamientos de una plataforma tecnolgica Adopta el uso de frameworks por tendencia

y organizado Hbil para estructurar un modelo Evala la viabilidad de la solucin Acta de forma independiente de la plataforma tecnolgica Evala el uso de frameworks

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

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 el conocimiento 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
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 Parte de cada miembro hacia el proyecto

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 ni 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. Calidad: defectos/KLOC 4. Productividad: KLOC/hora 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 (Inventario de clases a desarrollar, Modelos UML clases, secuencias) 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. 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 la conciencia de la gerencia y administracin a todos los niveles del equipo.

3. Procesos Individuales (TSP)

Estructura: Team Building & Team Working Incepcin Elaboracin Construccin Transicin

3. Procesos Individuales (TSP)

Cada fase debe visualizarse entre 2 4 meses Cada 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 la fase (relaunch) La gerencia del proyecto revisa cada plan En cada Launch/relaunch se deben producir planes alternos

3. Procesos Individuales (TSP)

Teamworking: 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.

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
CMM Busca Todas las organizaciones mundiales se administran y operan basadas en sistemas de informacin La industria del software particularmente tiene bajo desempeo en calidad, cumplimiento y funcionalidad de sus productos. Es artesanal 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 Afecta la cultura organizacional Finalmente todos sus procesos estn valorados en capacidad 5. El xito debe ser predecible

4. Procesos Corporativos

4. Procesos Corporativos
Maturity Level(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 e institucionalizelos en toda la organizacin 4. Administre sus procesos cuantitativamente 5. Mejore constantemente: Plan Estratgico anual para cada rea de procesos, con objetivos, acciones e indicadores.

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 estn en estado de mejoramiento continuo.

4. Procesos Corporativos

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

4. Procesos Corporativos
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 (llevar a la madurez, crecimiento integral) de personal. SA CMM: Modelo de madurez para administrar la adquisicin de servicios, productos y proyectos de Software.

4. Conclusiones del Curso

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 sino que debe ser cuidadosamente planeado y controlado.

2.

3.

4.

4. Conclusiones del Curso

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 Madurez Corporativa

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

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.

4. Conclusiones del Curso

En la prctica las metodologas facilitan el trabajo Todo modelo de madurez que involucre calidad se basa en el paradigma del mejoramiento continuo (plan-do-check-act).

4. Conclusiones del Curso

El principal problema que enfrentan las metodologas = resistencia al cambio por: Mitos y malinterpretaciones por falta de informacin y suficiente experiencia prctica con ellas

4. Conclusiones del Curso

Tendencias y puntos pendientes en la ingeniera de Software:
Formalizacin de una metodologa de anlisis y diseo (MDA ser la respuesta???) Formalizar una especificacin para Business Integration (SOA ???) Y despus, que nuevos problemas soluciones vendrn ????

Ahora s, Finalmente

Muchas Gracias por su tiempo !!!