ACISDesarrollar proyectos de software y “evitar” el fracaso ?

Por Bernardo Díaz Ariasberdiaz@yahoo.com

Intro

N1: Gerencia de Proyectos - PMI1. Overview de PMI2. Actividades de Inicio

3. Actividades de Planeación Comunicación HR Administración del Alcance

4. Actividades de Monitoreo y Ctrl5. Admin. de Riesgos6. Ctrl. de cambios7. Toma de Decisiones8. Alcance de la Calidad9. Actividades de Cierre

Primer paso: “Aprenda a coordinar un proyecto”

N1: Gerencia de Proyectos - PMI

N1: Gerencia de Proyectos - PMIÁreas de Conocimiento (9) El objetivo de un proyecto es generar un

producto según los requerimientos pactados.

La planeación es la base

La administración de riesgos y el monitoreo brindan estabilidad al proceso.

Los proyectos son de elaboración Progresiva (nadie nace aprendido. El éxito del proyecto no debe “depender” de los expertos sino que estos deben ser herramientas para normalizar el trabajo realizado).

Promueve la autonomía del Project Manager (PM) como figura que integra todos los elementos involucrados

El éxito de un proyecto es equilibrar la triple restricción (Q-$-t)->S

Las causas más comunes de fallo en proyectos de software son:

1. Falta de administración del alcance (S) 2. Comunicación con el cliente (Comm)3. El manejo de los recursos humanos (HR)

N1: Gerencia de Proyectos - PMI1. Actividades de Inicio

Se debe estimar el alcance de los términos contractuales con base en información histórica (a nivel de módulo)

Implicaciones del tipo de contrato del proyecto:

1. Precio Fijo (FP). Es el más riesgoso. Se debe controlar formalizando de antemano restricciones, riesgos del proyecto y precondiciones (requerimientos vs. tiempo, costos y recursos).

2. Subcontratos. Cada etapa del proceso se maneja como un subcontrato, y al final de este se sustenta el alcance del siguiente. Brinda mejores garantías a las partes.

3. Tiempo y Materiales (T&M). Se recomienda que lo “ejecute” una empresa CMMI 4 (o con infraestructura similar) ya que demanda cuantificar y controlar el esfuerzo de desarrollo del proyecto.

No se comprometa con proyectos no viables (Pet Projects)

N1: Gerencia de Proyectos - PMI2. Actividades de Planeación - Comunicación

Asegurese de contar con los siguientes roles: Sponsor Coordinador Funcional - Cliente Usuarios Técnicos Usuarios Funcionales

Formalice mecanismos de comunicación para cada tipo de rol, sin mezclarlos.

Establezca el plan de comunicación con base en reuniones de seguimiento, mecanismos de revisión y mecanismos de aceptación (p.e. actas).

En cualquier caso maneje comunicación formal e informal (envíe el e-mail pero llame para verificar que lo recibieron…). No subestime la retroalimentación 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 días max.

Identifique el tipo de organización del cliente (orientada a proyectos, funcional, matricial <fuerte, débil, balanceada>) así como sus prioridades (Q-S-$-t)

Establezca las reglas del proyecto y del equipo en la reunión de inicio (kickoff)

Asigne responsabilidades a los involucrados en el proyecto para que se integren como parte del mismo.

N1: Gerencia de Proyectos - PMI2. Actividades de Planeación - Manejo de los recursos humanos (HR)

“El proyecto lo implementan los recursos del equipo..”

Proceso de selección:1. Evaluación de Conocimientos (pruebas técnicas)2. Evaluación de Experiencia (años de experiencia específica)3. Evaluación de Actitud (pruebas psicológicas + 2 entrevistas cruzadas (PM, HR) )

Las Pruebas Psicológicas se deben diseñar con base en el perfil y el cargo:

1. Ingeniero de Desarrollo = Concentración + Pensamiento lógico-analítico2. Arquitecto = Pensamiento Abstracto + Capacidad de aprendizaje e investigación.

3. Especificación de requerimientos y pruebas = Organizado, metódico, orientado al detalle.

4. PM = Liderazgo + Comunicación (verbal y escrita), visión global.

* Estadísticamente a 1 y 2 le faltan las características de 3 y 4 y viceversa.

Motivación 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, priorice el inicio del proyecto ya que existen más incertidumbre y riesgos.

N1: Gerencia de Proyectos - PMI2. Actividades de Planeación – Administración del Alcance

Las entradas mínimas para estimar son la especificación funcional y técnica.

La herramienta más usada es Function Points

Una técnica alternativa es el uso de Información Histórica:

o Comience por registrar los tiempos (min-prom-max) de sus equipos progresivamente:1. Pantallas / módulo2. CU / módulo3. Componentes / CU4. Clases / paquete

o Cada elemento tiene complejidad 1-5. o A la información histórica NO se le debe calcular holgura (ya la incluye)o La recolección de información termina al generar las tablas de performance de la

organización

Es más sencillo y flexible planear de forma progresiva – (Plan proyecto + plan detallado por iteración)

Duración recomendada para las iteraciones = 4 – 8 semanas

WBS, base de la planeación?

N1: Gerencia de Proyectos - PMI2. Actividades de Planeación – Administración del Alcance

Plan de Aceptación

Plan de Comunicación

Planeación Iterativa

Tipo de contrato

Juegue con reglas claras: Incluya en sus planes riesgos, restricciones y precondiciones.

Revisiones Periódicas Formales (semanales – fase, técnicas, funcionales y administrativas)

Su compromiso: entregables

Fechas de cierre por fase

Formalice todo

N1: Gerencia de Proyectos - PMI3. Actividades de Monitoreo y Control

Durante la ejecución el equipo se debe concentrar en “desarrollar” el producto.

Durante esta fase las labores del PM se concentran en Monitoreo y Ctrl.

Medición del Progreso. Medición de Esfuerzo + Medición de Costo = (EVA)

Medición de la Calidad. Defectos/KLOC Medición de la Productividad. KLOC/hora

Medición de la Estabilidad del Proceso. Cantidad de cambios registrados al alcance (requerimientos, ajustes al cronograma, controles de cambio, etc..)

Identifique el esfuerzo en entrenamiento. Oriente y cuantifique los resultados hacia sus necesidades (Quiz, paper, prueba de concepto?).

N1: Gerencia de Proyectos - PMI4. Actividades de Administración de Riesgos

Identifique y agrupe los riesgos: De proyecto Técnicos Funcionales

Documento Pendientes. Genere un formato de hoja de cálculo donde cada miembro del equipo registre (día a día) la información pendiente para cumplir su trabajo. Debe incluir tipo, descripción, 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 - PMI5. Control de Cambios

Conviva con ellos, son típicos para proyectos ejecutados en contratos de precio fijo (FP).

Maneje dos tipos, interno al equipo del proyecto o contractuales con el cliente.

Acuerde previamente con el cliente que escenarios “dispararían” 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 sustentado con “hechos y datos”.

N1: Gerencia de Proyectos - PMI6. Toma de Decisiones

Se debe basar en una metodología que evite conflictos de intereses personales como Weighted Scoring

Model:

1. Identifique en consenso los factores que intervienen en la decisión y asigneles un peso o prioridad

2. Asigne un puntaje a cada factor

3. Sume el total de cada alternativa.

4. Se escoge la alternativa con mayor puntaje acumulado

Criterio Peso Keel Mule JBI-SDK Celtix ServiceMi

Tipo Herramienta 0,2 0,2 0,6 1 0,4 1

Release estable 0,2 1 0,6 0 0,6 0,6

Se basa en tecnologías WS

0,2 0 0 1 1 1

Profundidad Documentación

0,1 0,5 0,5 0 0,5 0,5

Enrutamiento e invocación dinámica de servicios web

0,1 0 0,5 0,5 0,5 0,5

Procesamiento Síncrono / asíncrono

0,1 0,5 0,5 0,5 0,25 0,5

Incluye implementaciones de ServiceProviders / Handlers

0,1 0 0,3 0,4 0,4 0,5

TOTAL 1 2,2 3 3,4 3,65 4,6

N1: Gerencia de Proyectos - PMI7. 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 sinónimo 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: Metodología de Desarrollo - RUP1. Disciplinas2. Ejecución Iterativa3. Fases (tiempo)

4. Adaptación del RUP

5. Metodología de Modelamiento6. Normalización Arquitectónica7. QA & QC8. Admin. de la Config.

Segundo paso: “Aprenda a construir software”

N2: Metodología de Desarrollo - RUP1. “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:

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

2. La planeación y control del proyecto se simplifica al dividirlo en Iteraciones cortas (4-8 semanas).

3. El resultado de cada iteración debe ser una versión ejecutable del sistema. El cliente percibe resultados más rápido y puede retroalimentar de forma más efectiva.

N2: Metodología de Desarrollo - RUP

N2: Metodología de Desarrollo - RUP4. En el tiempo el proyecto se divide en fases con objetivos definidos:

Incepción (aprox. 5 – 20% total). Planeación detallada del proyecto. Conocimiento del negocio Especificación funcional y técnica

Elaboración (aprox. 15 – 30% total). Definir la arquitectura de referencia. Implementar Pruebas de Concepto (Verificación Arquitectura) Diseño detallado Definir estrategia de implementación Implementar módulos utilitarios (seguridad, auditoria, pantalla principal)

Construcción (aprox. 30 – 50% total). Desarrollo de los módulos del sistema, distribuidos según prioridad, complejidad y dependencias.

Transición (aprox. 15 - 30% total). Entrega del sistema. Pruebas funcionales Pruebas de aceptación con los usuarios

Pruebas técnicas (carga, estrés, volumen, seguridad, concurrencia, etc.) Pruebas de instalación

Documentación manuales Capacitación Usuarios Entrega a producción (cierre proyecto)

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

N2: Metodología de Desarrollo - RUP6. Todas las actividades de modelamiento del sistema se pueden clasificar en

funcionales o técnicas.

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

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

9. RUP en esencia es un framework genérico que debe ser adaptado a las necesidades y condiciones de cualquier proyecto de software. La metodología como tal NO especifica como adaptarlo. El framework puede resultar muy “pesado” e ineficiente si no se sabe adaptar.

10. La métrica recomendada para adoptar RUP es usar las disciplinas en proyectos cortos hasta institucionalizarla en la compañía.

Un ejemplo sería iniciar usando las disciplinas de administración 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: Metodología de Desarrollo - RUP11. El PM debe conocer en detalle la metodología de desarrollo.

12. El arquitecto debe conocer el grupo de disciplinas principales.

13. El equipo de trabajo debe entender la filosofía de RUP para poder interiorizarla.

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

Especificación D. de CU. Para representar procesos del sistema ***D. de Actividades. Para representar la dinámica interna y relaciones entre procesos

Macro Diseño 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.

Diseño Detallado D. de Paquetes para representar las capas y grupos de componentes D. de Clases. Para representar las clases de implementación (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 código.

N2: Metodología de Desarrollo - RUP

N2: Metodología de Desarrollo - RUP*** Normalización Arquitectónica. Verifica que el diseño detallado sea definido en términos de un modelo de patrones de diseño y capas (propio de la tecnología de implementación). 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 característica opcional y deseable del modelo sino como un requerimiento.

Pensar en grande, hacer en pequeño. La arquitectura debe ser genérica siempre, el desarrollo del sistema debe implementar los requerimientos.

Similar al concepto de normalización relacional en 12 niveles de CODD.

18. Los frameworks simplifican la tarea de normalización por que internamente se basan en patrones y buenas prácticas.

19. Existe la tendencia equivocada de sobre-crear patrones y por principio estos no son patrones.

20. Las evoluciones de OOP son COP, IOC, SOC y las corrientes más prometedoras son AOP, MDA, SOA.

21. Todas las metodologías de modelamiento de software se pueden abstraer en una única metodología (basada en meta-patrones y roles).

22. Cuando se “llegue” a ese nivel de madurez se podrá automatizar la generación de código a partir del modelo requerimientos (ver GeneXus).

N2: Metodología de Desarrollo - RUP

N2: Metodología de Desarrollo - RUP

QA (metodologías y buenas prácticas) y QC (Evaluación del producto, Testing)

Tipos de Pruebas1. *** De código

Unitarias Revisión entre compañeros Code Profiling

2. Funcionales3. Técnicas

De GUI / Usabilidad De instalación De seguridad De concurrencia / transaccionalidad De volumen, carga y stress

Niveles de Prueba1. Unitario2. Integrado (módulo/subsistema)3. Sistema (*Regresión)

Fases de Prueba (ciclos y estados del producto)

1. Alfa (generalmente se alcanza al final de la fase de construcción)

2. Beta (primer ciclo estable de pruebas funcionales de transición)

3. Aceptación (“verificación/checklist” de las pruebas anteriores)

4. Pruebas de Instalación (checklist de entrega a producción)

Artefactos Requeridos

1. Plan de Pruebas2. Plan de Aceptación

3. Casos y escenarios de Prueba

4. Reporte de Defectos5. Resumen Ciclo de Pruebas

N2: Metodología de Desarrollo - RUPConfiguration & Change Management = Administración del

CVS

1. Agrupe todos los documentos de la organización por áreas, súbalos y adminístrelos en el repositorio de CVS.

2. Para cada evento del proyecto (entrega de iteración, control de cambio o estabilización de un ciclo de pruebas) genere un “baseline” que identifique esa versión del sistema.

N3: Individual - PSP

1. Antecedentes

2. Elementos

3. Herramienta para la madurez?

4. Conclusiones

“Que pasaría si la liebre fuera tan organizada, juiciosa y constante como la tortuga?...”

Tercer paso: “Toda organización es fruto

de su gente…”

N3: Individual - PSPAntecedentes

1. Falencias tipificadas Dispersión Estimaciones individuales incorrectas (afectan el plan general =

incumplimiento)

2. Cualquier tipo de actividad puede tener un ciclo Plan-Do-Check-Act

*** 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 compañía.

2. Cronograma Individual. Mide la variación entre la duración real y estimada de las actividades del cronograma

3. Métricas y reportes periódicos.

N3: Individual - PSPConclusiones

Es una herramienta para planear y organizar de forma efectiva la jornada de trabajo (más 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 información y por tanto no puede garantizar

“Competir con calidad y cantidad” Calidad = Interiorizar la cultura del mejoramiento continuoCantidad = Supere el mito del “esclavo”

Saque el mejor partido de sus habilidades e intereses. No todo desarrollador debería “terminar”como PM o arquitecto.

N4: Corporativo - CMMI

1. Antecedentes

2. Generalidades

3. Conclusiones

Cuarto paso: “La organización debe tener un rumbo claro…”

N4: Corporativo - CMMI

N4: Corporativo - CMMI

Antecedentes: “La madurez del proceso es relativa a la madurez de la compañía…”

1. Metodología para lograr la madurez en el proceso de desarrollo de software (CMM-S).

2. Formalizada por el SEI a partir de trabajos previos del DOD, la NASA, IBM y la U. de Carnegie Mellon.

3. Dado su éxito en la práctica, se aplicaron cambios menores y se generalizó para diferentes tipos de procesos e industrias (CMMI).

N4: Corporativo - CMMIGeneralidades:

1. Se basa en 5 Niveles o fases de evolución y estos contienen áreas de procesos (PA).

2. Cada PA contiene políticas de calidad, de mejoramiento, métricas, mecanismos de revisión y control, procesos y actividades. De igual forma que los niveles, cada PA se califica de 1-5.

N0 = Nivel indeterminado o heroico N1 = Se aplican buenas prácticas N2 = Se estandariza la metodología / proyecto N3 = Se “institucionaliza” la metodología a lo largo de la organización

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 evolución donde se priorizan unas PA de diferentes niveles según conveniencia - CMMI).

Conclusiones CMMI:

1. El esfuerzo corporativo debe iniciar a partir de una decisión de la dirección.

2. La implementación del modelo debe iniciar en el staff gerencial.

3. La estructura de una empresa de software debería empezar de forma orientada a proyectos.

4. Cuando la empresa genere un producto comercial se incluyen elementos de organización funcional.

5. A medida que se adopta el modelo CMMI se alcanza una organización de tipo Matriz Balanceada.

6. Se recomienda conformar de forma separada la Oficina de Proyectos de la Gerencia de Tecnología.

(Inicialmente compuestas por comités de gerentes y arquitectos hasta que la evolución de la compañía amerite un encargado por área.)

Conclusiones CMMI:

8. La compañía debe tener un “norte” anual representado en su Plan Estratégico:

1. Mercados, industrias y clientes a “atacar”2. Generación de nuevos productos o estrategias de comercialización de los existentes3. Plan de calidad (mejoramiento continuo)4. Plan de costos5. Plan de Capacitación6. ***Crecimiento proyectado (mejorar vs. crecer)

9. Modelo Propuesto:

1. PSP2. RUP3. PMI4. CMMI5. Six Sigma (corresponde a una metodología integral de optimización de procesos con

una base estadística, alcanza su máxima utilidad al nivel 5 de CMMI)

10. CMMI vs. ISO ???

Siglas y Abreviaturas IPMI = Project Management InstitutPM = Project ManagerQ-$-t = Triple Restricción (calidad-Costo-Tiempo)Proc = Procurement = adquisiciones y comprasHR = Recursos HumanosCOMM = ComunicaciónEVA = Earned Value Analisys

FP = Fixed Price, contratos a precio fijoT&M = Contratos donde el cliente paga al final de cada etapa según el tiempo y materiales invertidos en desarrollar el producto.

KLOC = K = mil, LOC = Líneas de código

RUP = Rational Unified Process (Modelo Unificado de desarrollo propuesto por Rational Corp.)

CU = Caso de Uso

PSP = Personal Software ProcessSEI = Software Engineering InstitutCMMI = Capability Maturity Model – Integration

Siglas y Abreviaturas IIOOP = Object Oriented Programming.

COP = Component Oriented Programming.

SOC = Separation Of Concerns.

IOC = Inversion Of Control.

MDA = Model Driven Architecture.

SOA = Service Oriented Architecture.

AOP = Aspect Oriented Programming.

Finalmente…

Muchas Gracias por su tiempo !!!