ACIS

Desarrollar proyectos de software y evitar el fracaso?

Por Bernardo Daz Arias berdiaz@yahoo.com

Introduccin
Antecedentes
1. 2. Estadsticas globales de fracaso en proyectos de software Errores cometidos y observados

Objetivos
1. 2. Compartir soluciones prcticas a problemas tpicos Proponer un modelo progresivo de buenas prcticas en 4 niveles (cada uno respaldado por una metodologa madura). Profundizar en cada nivel en los aspectos crticos donde se presentan fallas o la metodologa no detalla.

3.

Introduccin
Premisas Principales
1. La Ingeniera de Software (SE) como ciencia precisa, basada en hechos y datos (cuantificable).

2.
3.

Las metodologas como herramientas para simplificar y organizar

Mejoramiento continuo (plan-do-check-act)

4.

Dada su naturaleza colectiva, el proceso de desarrollo debe enfrentarse de forma integral:

N1: N2: N3: N4: Gerencia de Proyectos = PMI Metodologa de desarrollo = RUP Individual = PSP Corporativo = CMMI

Introduccin
Premisas Secundarias 1. Administracin y control del Alcance 2. Ayudarse con la metodologa de desarrollo 3. Normalizacin Arquitectnica 4. Sacar ventaja de las pruebas 5. PSP como base de un proceso maduro 6. Papel de la organizacin en los proyectos

Siglas y Abreviaturas
PMI = Project Management Institut PM = Project Manager Q-S-$-t = Triple Restriccin (calidad-Alcance-Costo-Tiempo) Proc = Procurement = adquisiciones y compras HR = Recursos Humanos COMM = Comunicacin EVA = Earned Value Analisys FP = Fixed Price, contratos a precio fijo T&M = Contratos donde el cliente paga al final de cada etapa segn el tiempo y materiales invertidos en desarrollar el producto. KLOC = K = mil, LOC = Lneas de cdigo RUP = Rational Unified Process (Modelo Unificado de desarrollo propuesto por Rational Corp.) CU = Caso de Uso

PSP = Personal Software Process SEI = Software Engineering Institut CMMI = Capability Maturity Model Integrated

N1: Gerencia de Proyectos - PMI

1. 2. 3. Overview de PMI Actividades de Inicio Actividades de Planeacin
Comunicacin HR Estimacin del Alcance

4. 5. 6. 7. 8. 9.

Actividades de Monitoreo y Ctrl Admin. de Riesgos Ctrl. de cambios Toma de Decisiones Alcance de la Calidad Actividades de Cierre

N1: Gerencia de Proyectos - PMI

N1: Gerencia de Proyectos - PMI

reas de Conocimiento (9)
El objetivo de un proyecto es generar un producto segn los requerimientos pactados (NUNCA los exceda). La planeacin es la base La administracin de riesgos y el monitoreo brindan estabilidad al proceso. Los proyectos son de elaboracin Progresiva (nadie nace aprendido, no se depende de expertos de negocio o tcnicos) Promueve la autonoma del Project Manager (PM) como figura que integra todos los elementos involucrados El xito de un proyecto es equilibrar la triple restriccin (Q-$-t-S)

Las causas ms comunes de fallo en proyectos de software son la falta de administracin del alcance, la comunicacin con el cliente y el manejo de los recursos humanos (S-Comm-HR).

N1: Gerencia de Proyectos - PMI

1. Actividades de Inicio
Se debe estimar el alcance de los trminos contractuales con base en informacin histrica (a nivel de mdulo) Implicaciones del tipo de contrato del proyecto: 1. Precio Fijo (FP). Es el ms riesgoso. Se debe controlar formalizando de antemano restricciones, riesgos del proyecto y precondiciones (requerimientos vs. tiempo, costos y recursos). Subcontratos. Cada etapa del proceso se maneja como un subcontrato, y al final de este se sustenta el alcance del siguiente. Brinda mejores garantas a las partes.

2.

3.

Tiempo y Materiales (T&M). Se recomienda que lo ejecute una empresa CMMI 4 ya que requiere una infrainstructura para cuantificar y controlar el esfuerzo de desarrollo del proyecto.

No se comprometa con proyectos no viables (Pet Projects)

N1: Gerencia de Proyectos - PMI

2. Actividades de Planeacin - Comunicacin
Asegurese de contar con los siguientes roles: Sponsor Coordinador Funcional - Cliente Usuarios Tcnicos Usuarios Funcionales Formalice mecanismos de comunicacin para cada tipo de rol, sin mezclarlos. Establezca el plan de comunicacin con base en reuniones de seguimiento, mecanismos de revisin y mecanismos de aceptacin (p.e. actas). En cualquier caso maneje comunicacin formal e informal (enve el e-mail pero llame para verificar que lo recibieron). No subestime la retroalimentacin informal con los diferentes participantes del proyecto (no deje de ltimo a los miembros de su equipo). Todos los eventos relevantes deben formalizarse por escrito. Con un margen de 1-3 das max. Identifique el tipo de organizacin del cliente (orientada a proyectos, funcional, matricial <fuerte, dbil, balanceada>) as como sus prioridades (Q-S-$-t) Establezca las reglas del proyecto y del equipo en la reunin de inicio ( kickoff) Asigne responsabilidades a los involucrados en el proyecto para que se integren como parte del mismo.

N1: Gerencia de Proyectos - PMI

2. Actividades de Planeacin - Manejo de los recursos humanos (HR)

El proyecto lo implementan los recursos del equipo.. Proceso de seleccin: 1. Evaluacin de Conocimientos (pruebas tcnicas) 2. Evaluacin de Experiencia (aos de experiencia especfica) 3. Evaluacin de Actitud (pruebas psicolgicas + 2 entrevistas cruzadas (PM, HR) ) Las pruebas psicolgicas se deben disear con base en el perfil y el cargo: 1. Ingeniero de Desarrollo = Concentracin + Pensamiento lgico-analtico 2. Arquitecto = Pensamiento Abstracto + Capacidad de aprendizaje e investigacin. 3. 4. Especificacin de requerimientos y pruebas = Organizado, metdico, orientado al detalle. PM = Liderazgo + Comunicacin (verbal y escrita), visin global.

Estadsticamente a 1 y 2 le faltan las caractersticas de 3 y 4 y viceversa.

** Motivacin es el arte y la ciencia de identificar y potenciar lo mejor de cada persona de su equipo, independiente de su cargo, preferencias y relaciones personales. Mantenga un ritmo de trabajo alto y constante en lugar de un ritmo espasmdico ante entregas o pruebas. Los fines de semana dependen de que cada individuo cumpla los objetivos de la semana.

N1: Gerencia de Proyectos - PMI

2. Actividades de Planeacin Administracin del Alcance
Las entradas mnimas para estimar son la especificacin funcional y tcnica. La herramienta ms usada es Function Points Una tcnica alternativa es el uso de Informacin Histrica: o Comience por registrar los tiempos de sus equipos (min-prom-max):

o o o

Cada elemento tiene complejidad 1-5. A la informacin histrica NO se le debe calcular holgura (ya la incluye) La recoleccin de informacin termina al generar las tablas de performance de la organizacin

o o o o

Pantallas / mdulo CU / mdulo Componentes / CU Clases / paquete

Es ms sencillo y flexible planear de forma progresiva (Plan proyecto + plan detallado por iteracin) Duracin recomendada para las iteraciones = 4 8 semanas WBS

N1: Gerencia de Proyectos - PMI

2. Actividades de Planeacin Administracin del Alcance

Plan de Aceptacin
Plan de Comunicacin Planeacin Iterativa Tipo de contrato Juegue con reglas claras: Incluya en sus planes riesgos, restricciones y precondiciones. Revisiones Peridicas Formales (semanales fase, tcnicas, funcionales y
administrativas)

Su compromiso: entregables Fechas de cierre por fase Formalice todo

N1: Gerencia de Proyectos - PMI

3. Actividades de Monitoreo y Control Durante la ejecucin el equipo se debe concentrar en desarrollar el producto. Durante esta fase las labores del PM se concentran en Monitoreo y Ctrl. Medicin del Progreso. Medicin de Esfuerzo + Medicin de Costo = (EVA) Medicin de la Calidad. Defectos/KLOC Medicin de la Productividad. KLOC/hora

Medicin de la Estabilidad del Proceso. Cantidad de cambios registrados al alcance (requerimientos, ajustes al cronograma, controles de cambio, etc..)
Identifique el esfuerzo en entrenamiento y cuantifique los resultados (Quiz?).

N1: Gerencia de Proyectos - PMI

4.

Actividades de Administracin de Riesgos Identifique y agrupe los riesgos: De proyecto Tcnicos Funcionales Documento Pendientes. Genere un formato de hoja de clculo donde cada miembro del equipo registre (da a da) la informacin pendiente para cumplir su trabajo. Debe incluir tipo, descripcin, fecha ingreso, estado, responsable, respuesta. El manejo de riesgos es netamente preventivo y como tal se debe informar e involucrar activamente al cliente.

N1: Gerencia de Proyectos - PMI

5. Control de Cambios Conviva con ellos, son tpicos para proyectos ejecutados en contratos de precio fijo (FP). Maneje dos tipos, interno al equipo del proyecto o contractuales con el cliente.

Acuerde con el cliente que escenarios dispararan un control de cambio contractual.

Si un evento genera un control de cambio que afecte el alcance del proyecto, alguien debe asumir el costo. Si no es su culpa, no la asuma, recuerde que todo debe estar formalizado con hechos y datos.

N1: Gerencia de Proyectos - PMI

Criterio Peso Keel Mule JBI-SDK Celtix ServiceMi

6. Toma de Decisiones Se debe basar en una metodologa que evite conflictos de intereses personales como Weighted Score Model: 1. Identifique los factores que intervienen en la decisin y asigneles un peso o prioridad Asigne un puntaje a cada factor Sume el total de cada alternativa. Se escoge la alternativa con mayor puntaje acumulado

Tipo Herramienta Release estable Se basa en tecnologas WS Profundidad Documenta cin Enrutamiento e invocacin dinmica de servicios web Procesamiento Sncrono / asncrono Incluye implementa ciones de ServicePro viders / Handlers TOTAL

0,2 0,2 0,2

0,2 1 0

0,6 0,6 0

1 0 1

0,4 0,6 1

1 0,6 1

0,1

0,5

0,5

0,5

0,5

0,1

0,5

0,5

0,5

0,5

2.
0,1 0,5 0,5 0,5 0,25 0,5

3. 4.

0,1

0,3

0,4

0,4

0,5

2,2

3,4

3,65

4,6

N1: Gerencia de Proyectos - PMI

7. Calidad (Q)

El costo de la calidad TOTAL es muy alto (no se puede identificar que es peor, la cura o la enfermedad).
En proyectos de software, calidad es sinnimo de estabilidad no de mejoras o adiciones a los requerimientos acordados (Gold Plating).

8. Actividades de Cierre PMI recomienda que en cada ciclo terminado de un proyecto se registren las lecciones aprendidas (embarradas cometidas).

N2: Metodologa de Desarrollo - RUP

1. Disciplinas 2. Ejecucin Iterativa 3. Fases (tiempo) 4. Adaptacin del Modelo 5. 6. 7. 8. Metodologa de Modelamiento Normalizacin Arquitectnica QA & QC Admin. de la Config.

N2: Metodologa de Desarrollo - RUP

1. No dejar nada al azar. Obliga a desarrollar software considerando todos los elementos necesarios o Disciplinas principales:

Business Modeling Requirements Analisis & Design Implementation Testing

Y las disciplinas complementarias:

2. 3. Project Management (*** PMI se puede integrar ac) Config & Change Mgmt Environment Mgmt Deployment

La planeacin y control del proyecto se simplifica al dividirlo en Iteraciones cortas (4-8 semanas). El resultado de cada iteracin debe ser una versin ejecutable del sistema. El cliente percibe resultados ms rpido y puede retroalimentar de forma ms efectiva.

N2: Metodologa de Desarrollo - RUP

N2: Metodologa de Desarrollo - RUP

4. En el tiempo el proyecto se divide en fases con objetivos definidos: Incepcin (aprox. 5 20% total). Planeacin detallada del proyecto. Conocimiento del negocio Especificacin funcional y tcnica Elaboracin (aprox. 15 30% total). Definir la arquitectura de referencia. Implementar Pruebas de Concepto (Verificacin Arquitectura) Diseo detallado Definir estrategia de implementacin Implementar mdulos utilitarios (seguridad, auditoria, pantalla principal) Construccin (aprox. 30 50% total). Desarrollo de los mdulos del sistema, distribuidos segn prioridad, complejidad y dependencias. Transicin (aprox. 15 - 30% total). Entrega del sistema. Pruebas funcionales Pruebas de aceptacin con los usuarios 5. Pruebas tcnicas (carga, estrs, volumen, seguridad, concurrencia, etc.) Pruebas de instalacin Documentacin manuales Capacitacin Usuarios Entrega a produccin (cierre proyecto)

Cada fase consta de iteraciones de su mismo tipo (p.e. IC1, IC2, IC3, corresponden a iteraciones de la fase de construccin).

N2: Metodologa de Desarrollo - RUP

6. Todas las actividades de modelamiento del sistema se pueden clasificar en funcionales o tcnicas.

7.
8.

De forma complementaria RUP define Roles, Actividades y Artefactos-Entregables.

RUP incluye un set de plantillas de artefactos para cada disciplina y flujos generales de las actividades pero no define un flujo detallado para el proceso de desarrollo. RUP en esencia es un framework genrico que debe ser adaptado a las necesidades y condiciones de cualquier proyecto de software. La metodologa como tal NO especifica como adaptarlo. El framework puede resultar muy pesado e ineficiente si no se sabe adaptar.

9.

10. La mtrica recomendada para adoptar RUP es usar las disciplinas en proyectos cortos hasta institucionalizarla en la compaa.
Un ejemplo sera iniciar usando las disciplinas de administracin en un primer proyecto. En un segundo proyecto incluir el grupo de business Modeling y Requirements. En un tercer proyecto adicionar Analisis & Design En un cuarto proyecto adicionar Implementation & Testing En un quinto proyecto usar todas las disciplinas.

N2: Metodologa de Desarrollo - RUP

11. 12. 13. 14. El PM debe conocer en detalle la metodologa de desarrollo. El arquitecto debe conocer el grupo de disciplinas principales. El equipo de trabajo debe entender la filosofa de RUP para poder interiorizarla. Como tal, RUP no es prescriptivo con el uso de una herramienta de modelamiento (aunque las plantillas de ejemplo se basan en UML). Los usos recomendados para UML son: Especificacin D. de CU. Para representar procesos del sistema ***D. de Actividades. Para representar la dinmica interna y relaciones entre procesos Macro Diseo D. de Deployment. Para representar los subsistemas y sus dependencias D. de Clases para representar el modelo de Entidades y relaciones del sistema (MER) D. de Componentes. Para representar las capas y componentes del sistema (arquitectura) y sus dependencias. Diseo Detallado D. de Paquetes para representar las capas y grupos de componentes D. de Clases. Para representar las clases de implementacin (clases de control, de entidad, de interfase y utilitarias). ***D. de Secuencias. Para representar el paso de mensajes entre clases al ejecutar un proceso del sistema. *** Permiten anticipar requerimientos y reglas de negocio complejas antes de escribir cdigo.

N2: Metodologa de Desarrollo - RUP

N2: Metodologa de Desarrollo - RUP

15. *** Normalizacin Arquitectnica. Verifica que el diseo detallado sea definido en trminos de un modelo de patrones de diseo y capas (propio de la tecnologa de implementacin). Los procesos del sistema se implementan a lo largo de este modelo (p.e. desde la capa cliente hasta la capa de persistencia para J2EE). El desacoplamiento entre clases y componentes no debe interpretarse como una caracterstica opcional y deseable del modelo sino como un requerimiento.

16.

17.
18. 19. 20. 21. 22.

Pensar en grande, hacer en pequeo. La arquitectura debe ser genrica siempre, el desarrollo del sistema debe implementar los requerimientos.
Los frameworks simplifican la tarea de normalizacin por que internamente se basan en patrones y buenas prcticas. De las metodologas de diseo resaltan COP, IOC, SOC originadas a partir de los proyectos open source de Apache. Las corrientes ms prometedoras son AOP, MDA, SOA. Existe la tendencia equivocada de sobre-crear patrones y por principio estos no son patrones. Todas las metodologas de modelamiento de software se pueden abstraer en una nica metodologa (basada en meta-patrones y roles). Cuando se llegue a ese nivel de madurez se podr automatizar la generacin de cdigo a partir del modelo requerimientos (ver GeneXus).

N2: Metodologa de Desarrollo - RUP

N2: Metodologa de Desarrollo - RUP

QA (metodologas y buenas prcticas) y QC (Evaluacin del producto, Testing) Tipos de Pruebas 1. *** De cdigo Unitarias Revisin entre compaeros Code Profiling 2. Funcionales 3. Tcnicas De GUI / Usabilidad De instalacin De seguridad De concurrencia / transaccionalidad De volumen, carga y stress Niveles de Prueba 1. Unitario 2. Integrado (mdulo/subsistema) 3. Sistema (*Regresin)
Fases de Prueba (ciclos y estados del producto) 1. 2. Beta (generalmente se alcanza al final de la fase de construccin) Alfa (primer ciclo estable de pruebas funcionales de transicin)

3.
4.

Aceptacin (verificacin/checklist de las pruebas anteriores)

Pruebas de Entrega (checklist de entrega a produccin)

Artefactos Requeridos 1. 2. 3. 4. 5. Plan de Pruebas Plan de Aceptacin Casos y escenarios de Prueba Reporte de Defectos Resumen Ciclo de Pruebas

N2: Metodologa de Desarrollo - RUP

Configuration & Change Management = Administracin del CVS
1. Agrupe todos los documentos de la organizacin por reas, sbalos y adminstrelos en el repositorio de CVS. Para cada evento del proyecto (entrega de iteracin, control de cambio o estabilizacin de un ciclo de pruebas) genere un baseline que identifique esa versin del sistema.

2.

N3: Individual - PSP

1. Antecedentes 2. Elementos 3. Herramienta para la madurez? 4. Conclusiones

N3: Individual - PSP

Antecedentes 1. Falencias tipificadas Dispersin Estimaciones individuales incorrectas (afectan el plan general = incumplimiento) Todas las actividades tienen un ciclo Plan-Do-Check-Act

2.

*** El PSP es el pilar de un modelo de madurez en una empresa de software.

1. Reporte de Esfuerzo. Mide el esfuerzo individual y permite estimar el del proyecto y la compaa.

2.
3.

Cronograma Individual. Mide la variacin entre la duracin real y estimada de las actividades del cronograma
Mtricas de Productividad.

N3: Individual - PSP

Conclusiones Es una herramienta para planear y organizar de forma efectiva la jornada de trabajo (ms de 9X5 ???). Empresa organizada vs. Empresa dream-team ? La estabilidad de las partes aportan a la estabilidad del todo

No se comprometa a realizar algo sobre lo cual no posee informacin

Competir con calidad y cantidad

Calidad = Interiorizar la cultura del mejoramiento continuo Cantidad = Superar el mito del esclavo Saque el mejor partido de sus habilidades e intereses. No todo desarrollador debera terminarcomo PM o arquitecto.

N4: Corporativo - CMMI

1. Antecedentes 2. Generalidades 3. Conclusiones

N4: Corporativo - CMMI

N4: Corporativo - CMMI

Antecedentes: La madurez del proceso va hasta la madurez de la compaa 1. Metodologa para lograr la madurez en el proceso de desarrollo de software (CMM-S). Formalizada por el SEI a partir de trabajos previos del DOD, la NASA, IBM y la U. de Carnegie Mellon. Dado su xito en la prctica, se aplicaron cambios menores y se generaliz para diferentes tipos de procesos e industrias (CMMI).

2.

3.

N4: Corporativo - CMMI

Generalidades:
1. 2. Se basa en 5 Niveles o fases de evolucin y estos contienen reas de procesos (PA). Cada PA contiene polticas de calidad, de mejoramiento, mtricas, mecanismos de revisin y control, procesos y actividades. De igual forma que los niveles, cada PA se califica de 1-5. N0 N1 N2 N3 = = = = Nivel indeterminado o heroico Se aplican buenas prcticas Se estandariza la metodologa / proyecto Se institucionaliza la metodologa a lo largo de la organizacin

N4 = Cuantificado y administrado N5 = Optimizado, mejoramiento continuo

3.

Se pueden escoger 2 rutas de mejoramiento para llegar a N5. Evolucionar por nivel (todas las PA del nivel deben ser nivel 5 - CMM). Evolucionar por PA (se define un plan de evolucin donde se priorizan unas PA de diferentes niveles segn conveniencia - CMMI).

Conclusiones CMMI:
1. La estructura de una empresa de software debera empezar de forma orientada a procesos. Cuando la empresa produzca un producto comercial se incluyen elementos de organizacin funcional. A medida que se adopta el modelo CMMI se alcanza una organizacin de tipo Matriz Balanceada. En la parte tcnica se recomienda separar una Oficina de Proyectos de la Gerencia de Tecnologa. Inicialmente compuestas por comits de gerentes y arquitectos hasta que la evolucin de la compaa amerite un encargado por rea. La compaa debe tener un norte anual representado en su Plan Estratgico. En este se estipula:
1. 2. 3. 4. 5. 6. Mercados, industrias y clientes a atacar Generacin de nuevos productos o estrategias de comercializacin de los existentes Plan de calidad (mejoramiento continuo) Plan de costos Plan de Capacitacin ***Crecimiento proyectado (mejorar vs. crecer)

2.

3.

4.

Modelo Integrado:
1. 2. 3. 4. 5. PSP RUP PMI CMMI Six Sigma (corresponde a una metodologa integral de optimizacin de procesos con una base estadstica, se integra al nivel 5 de CMMI)

5.

CMMI vs. ISO ???

Finalmente

Muchas Gracias por su tiempo !!!