ACIS
Desarrollar proyectos de software y
“evitar” el fracaso ?:
Conclusiones
Por Bernardo Díaz Arias
[email protected]
Introducción
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
planeación ligera, la ausencia de monitoreo y
retroalimentación permanente minimizan el éxito
administrativo de los proyectos de software así todas las
demás variables se cumplan”
Solución Propuesta: El PMI es una organización
fundada desde 1969 cuya metodología tiene creciente
aceptación mundial y resume las buenas prácticas en
“Gestión de Proyectos” para cualquier industria.
1. Gerencia de Proyectos
Fortalezas:
 Promueve la gestión
integral (según 9 áreas
de procesos).
 Los procesos de
Planeación aplican a
cualquier industria
Debilidades:
 No detalla en como se
debe ejecutar el proyecto
para generar el producto
o servicio. (propio de
cada industria).
 No incluye Plantillas
 Requiere de experiencia
para aplicar
correctamente los flujos
entre procesos.
1. Gerencia de Proyectos
Oportunidades:
 Utilizarlo en conjunto
con metodologías que
definan el proceso de
construcción del
producto o bien del
proyecto.
Amenazas:
 Durante la planeación
del proyecto tiende a
darse sobrecarga de
trabajo para el PM.
 En nuestro medio no
es frecuente que el PM
se pueda dedicar
tiempo completo a un
proyecto así sea
complejo / grande.
1. Gerencia de Proyectos
•
La gestión de la comunicación es débil,
o peor, inexistente en nuestro medio lo que
directamente afecta el alcance y
entendimiento entre proveedor y cliente.
•
La gestión de la comunicación debe
adaptarse según la cultura organizacional
del cliente.
•
El éxito del proyecto parte de la evaluación
de su viabilidad (administrativa, técnica y
funcional) antes de iniciarlo.
1. Gerencia de Proyectos
•
Es responsabilidad del Gerente Funcional previamente
evaluar la viabilidad del proyecto y proveer toda la
información administrativa, técnica y funcional a los
proveedores.
•
En software la mejor alternativa Gana-Gana para tipos de
contratos es un híbrido entre T&M/FP = Contrato Marco y
Subcontratos (por fases del proyecto).
•
El éxito administrativo en gestionar el alcance se basa en
aspectos como:
•
•
•
•
•
•
Evaluación de la Viabilidad
Plan de comunicación
Plan de Gestión de Cambios
Plan de Aceptación
Administración de riesgos
Precondiciones y restricciones contractuales, etc.
1. Gerencia de Proyectos
•
El éxito funcional en gestionar el alcance se basa en una adecuada
ingeniería de requerimientos.
•
El éxito técnico en gestionar el alcance se basa en tener un conocimiento
detallado de la plataforma tecnológica frente a las necesidades del
producto.
•
En nuestro medio las empresas proveedoras difícilmente realizan gestión
de recursos humanos ya que estos solo se contratan (y rotan) por
proyecto.
•
La administración de riesgos es el tema central de las reuniones entre
cliente y proveedores desde el inicio al final del proyecto.
•
Los riesgos se pueden gestionar y por tanto comunicar según su grupo:
•
•
•
Administrativos
Funcionales
Técnicos
1. Gerencia de Proyectos
•
En la práctica, es un estándar de facto el uso de la herramienta
WBS para identificar progresivamente las actividades necesarias
para realizar los entregables principales y secundarios del
proyecto.
•
En la industria del software se recomienda organizar un WBS
según elementos de RUP:
•
•
•
•
Nivel
Nivel
Nivel
Nivel
1.
2.
3.
4.
Fase
Disciplina RUP
Entregables.
Macro Actividades
•
Del WBS se deduce el cronograma
•
El esfuerzo final de la planeación es el presupuesto pero este se
deduce principalmente del cronograma
(actividades+tiempo+recursos).
•
En nuestro medio no es común que el presupuesto incluya gestión
de costos indirectos, costo del riesgo y de la holgura del proyecto.
1. Gerencia de Proyectos
•
Es recomendable que el Plan del Proyecto se “vea” como
una integración de los subplanes de las 8 áreas de
procesos de PMI.
•
Se recomienda que el plan de gestión de la calidad se
estructure en 2 grupos:
•
•
•
Subplan de Aseguramiento de Calidad (estrategia de
implantación de las buenas prácticas de forma particular al
proyecto)
Subplan de Control de Calidad (Metodología de Pruebas)
Las herramientas y técnicas más usadas son:
•
•
•
WBS
EVA
Weighted Scorecard Model
1. Gerencia de Proyectos
• Finalmente el proyecto lo ejecutan
las personas que lo conforman.
• Por lo anterior nunca será suficiente
en invertir y mejorar las habilidades
de comunicación y administración del
recurso humano.
2. Proceso de Desarrollo
2. Proceso de Desarrollo
Problema: “La gerencia del proyecto debe conocer en
detalle el proceso de construcción de software para
asegurar que nada se deje al azar, para generar la
estratégia de desarrollo adecuada y para la toma de
decisiones”.
“El no conocer el cómo se hacen los productos de software
crea una brecha mutua entre proveedor y cliente y entre
gerente del proyecto y el equipo”.
Solución Propuesta: El Proceso Unificado de Desarrollo,
originalmente un enfoque metodológico integral para
desarrollar cualquier producto de software (1998) y
finalmente un producto de IBM (desde 2002) es la base
de diferentes especializaciones como SUN TONE, EUP,
Métrica 3, IBM BUP, etc.
2. Proceso de Desarrollo
Fortalezas:

Concebido para ser adaptado a cualquier tipo de desarrollo de software

No deja nada al azar (9 disciplinas estructuradas)

Hace énfasis en continuamente administrar y controlar los riesgos del
proyecto

Fuerte base conceptual (UML).

Orientado a generar resultados de calidad y ágiles para el cliente.

Promueve las entregas cortas y ágiles por medio del concepto de
desarrollo iterativo, incremental.

Implícitamente incluye las dos técnicas más exitosas de optimización
de tiempos ( Fasttracking (trabajo progresivo con entregas cortas
sucesivas) y Crashing (trabajo en paralelo) ).
2. Proceso de Desarrollo
Debilidades:


La documentación no especifica reglas
concretas para tomar la decisión de
que plantillas usar en un proyecto
particular.
La documentación tiene ejemplos
generales de cómo adoptarlo en un
proyecto / compañía pero no especifica
reglas claras de cómo hacerlo en la
práctica.

Requiere experiencia y conocimiento
para usarlo correctamente

Sobrecarga y crea dependencia del rol
de Arquitecto.

El trabajo de cada disciplina se centra
en el caso de uso, esta dependencia
minimiza la oportunidad de optimizar
el trabajo en paralelo.

El modelamiento por casos de uso no
es la alternativa recomendable para
proyectos técnicamente complejos y
con baja interacción funcional.

No es fuerte en administración
cuantificada de los procesos.

No presenta una solución directa al
factor humano como origen de los
problemas en proyectos de software.
2. Proceso de Desarrollo
Oportunidades:

Dado que las versiones
recientes adoptaron
conceptos y terminología PMI
se complementan muy bien.

Utilizarlo en conjunto con
metodologías que definan la
administración cuantificada
de procesos de software
(PSP/TSP).

De la experiencia práctica se
pueden identificar soluciones
a cada una de sus debilidades
y amenazas.

Se complementa con las
técnicas de desarrollo ágil.
Amenazas:
 Su dificultad para ser usado y
entendido en la práctica ha
generado muchas
malinterpretaciones
(incluso por “expertos”).

El hecho de que se halla
convertido en producto
comercial minimiza su
difusión e interpretación
metodológica y agrega un
factor de costo a su adopción.
2. Proceso de Desarrollo
• Las entregas cortas (Iteraciones)
facilitan:
• Retroalimentación constante con el
cliente en aspectos funcionales,
administrativos y técnicos del proyecto.
• Controlar, probar y ajustar productos
pequeños (aprox. 4 – 8 semanas) frente
a productos grandes (medidos en meses
y años)
2. Proceso de Desarrollo
• Los Entregables son el producto
percibido por el cliente frente a una
entrega (documentos y piezas de
software).
• Los entregables son la medida ideal
para centrar la estimación, el
monitoreo y control de actividades ya
que son los productos finales de la
iteración.
2. Proceso de Desarrollo
•
Las Fases son etapas de tiempo con objetivos claramente
definidos:
1.
2.
3.
4.
•
Incepción: Análisis del negocio/problema, Planeación del
proyecto y gestión de requerimientos.
Elaboración: Definir y evaluar la arquitectura de referencia,
Madurar y detallar los requerimientos como casos de uso.
Minimizar los riesgos del proyecto (aprox. 70%).
Construcción: Generar una versión completamente funcional
y estable del sistema (alfa).
Transición: Gestiona la adopción del software en la compañía
mediante ciclos de pruebas (beta y aceptación),
documentación y capacitación acerca del producto (técnica,
administrativa y funcional) y finalmente su paso a estado
productivo.
Las fases ayudan a gestionar el alcance ya que implican
que se cierren formalmente etapas en la vida del proyecto.
2. Proceso de Desarrollo
• Cada disciplina RUP consta de:
• Quién?: Workers/Roles
• Cuando y Como ?: Workflows y
Actividades
• Que?: Artefactos/Plantillas/Entregables
2. Proceso de Desarrollo
•
Para simplificar el entendimiento del modelo se
recomienda agrupar los flujos de actividades de las
disciplinas en funcionales, técnicas y administrativas.
•
El RUP se puede interpretar desde la perspectiva
pedagógica de que enseña el “como” desarrollar
productos de software.
•
El RUP se puede interpretar desde la perspectiva
práctica de que cada una de las disciplinas debe
adoptarse/personalizarse ante las necesidades de cada
proyecto.
•
RUP NO obliga a usar toda la carga de artefactos o roles
posibles para cada proyecto.
2. Proceso de Desarrollo
•
Se recomienda para la adopción práctica de RUP que
se identifiquen (por disciplina) los artefactos y roles
obligatorios o mínimos para cualquier proyecto, por
ejemplo:
1.
2.
3.
4.
5.
6.
7.
8.
•
Visión de Negocio
Glosario de Negocio
Plan del Proyecto
Modelo de Requerimientos
Modelo de Casos de Uso
Documento de Arquitectura
Plan de Pruebas
Plan de Administración de la Configuración
Según el tamaño del proyecto variaría el contenido
de los mismos.
2. Proceso de Desarrollo
•
Es un aporte importante de RUP que los
roles sean asociados a grupos de
actividades comunes y específicas ya que
facilitan su adopción práctica: “Estos
pueden ser desde una persona con
diferentes roles en diferentes instantes de
tiempos (proyectos pequeños) hasta
equipos de trabajo que representan un rol
(proyectos grandes)”.
•
En la práctica es crucial la confianza del PM
en el arquitecto para agilizar la toma de
decisiones técnicas.
2. Proceso de Desarrollo
Business Modeling:
• De forma análoga a la terminología
industrial, busca especificar los procesos
de información de la organización.
•
Desde la perspectiva del proveedor, es útil
para entender el problema organizacional
que es causa del proyecto de software.
•
Desde la perspectiva del cliente sirve para
organizar una propuesta de proyecto a
partir de un problema.
2. Proceso de Desarrollo
Requirements:
•
De forma análoga a la terminología industrial, busca
especificar los procesos de información del software a
partir de identificar y normalizar las necesidades y
requerimientos del cliente.
•
Para facilitar su gestión se recomienda agruparlos por
subsistemas y módulos.
•
A nivel de industria de software no existe un proceso
definido, formal y maduro de normalización de
requerimientos.
•
El resultado final de los requerimientos son Casos de
Uso (Procesos del Software).
2. Proceso de Desarrollo
Requirements:
•
Una causa típica de fallos en los proyectos es que se
definen como casos de uso macroprocesos/módulos y
no procesos específicos (atómicos).
•
A nivel de industria existe el error de definir los
Casos de Uso tomando como base el texto, causa
frecuente de malintepretaciones entre usuarios y
proveedor dada su ambigüedad.
•
En la práctica se recomienda que la definición de los
Casos de Uso se base en modelos UML de casos de
uso para macroprocesos hasta procesos atómicos. Y
diagramas de actividades para modelar el workflow
detallado de cada proceso atómico (Caso de Uso).
2. Proceso de Desarrollo
Analisis & Design:
•
Existe dependencia y centralización del Arquitecto.
•
Desafortunadamente el Análisis y Diseño se basa en el
“criterio del experto” (Arquitecto/Diseñador) ya que no se
ha formalizado un proceso que sustente la toma de
decisiones de diseño.
•
En la práctica se han desarrollado productos como
GeneXus que generan código para cualquier plataforma
tecnológica a partir de un modelo de requerimientos.
•
Actualmente se está madurando este concepto en un
estándar del OMG llamado MDA (Model Driven
Architecture).
2. Proceso de Desarrollo
Analisis & Design: MDA
•
MDA se basa en tres principios (paralelos):
1. Modelo de Procesos = Requerimientos
2. Modelo de Integración =
a. Modelo de Subsistemas y Módulos
b. Modelo de Datos (Conceptual o de dominio y
físico)
3. Modelo de la Plataforma tecnológica = Arquitectura
de referencia, combinación de capas y patrones de
diseño estándar para una plataforma.
2. Proceso de Desarrollo
Analisis & Design: MDA
2. Proceso de Desarrollo
Analisis & Design: MDA
• El cruce de los tres principios genera
el diseño detallado del software. (los
procesos son ortogonales a la
arquitectura)
• Finalmente a partir del diseño
detallado se genera el código.
2. Proceso de Desarrollo
Analisis & Design: MDA
•
MDA puede interpretarse desde la
perspectiva comercial para definir un
estándar de productos CASE.
•
MDA puede aprovecharse desde la
perspectiva metodológica para definir un
proceso formal y estándar de Análisis y
Diseño independiente de la plataforma
tecnológica y el criterio experto.
2. Proceso de Desarrollo
Analisis & Design:
La industria del software tiene un
problema crítico asociado a la alta
dependencia del rol de arquitecto frente
a la falta de formalización del proceso
de análisis y diseño:
“Se confunde un arquitecto con un desarrollador senior lo
cuál afecta el grado de correctitud del producto, así a
nivel funcional este cumpla con los requerimientos”
2. Proceso de Desarrollo
Analisis & Design:
•
Los defectos arquitectónicos difícilmente se detectan
durante las pruebas funcionales.
•
Los defectos arquitectónicos se detectan durante etapas
post-productivas a la hora de realizar mantenimientos y
mejoras a la aplicación (cuando queda poco o nada por
hacer !!!).
•
El impacto de los cambios es impredecible. Un cambio
inestabiliza varias partes del código y/o toma mucho
tiempo realizarlo.
•
El conocimiento de un arquitecto es escaso y más aún
para que un proyecto tenga un arquitecto revisor
adicional al que ejecuta el proyecto ($$$).
2. Proceso de Desarrollo
Arquitecto:
Desarrollador Senior:
 Predomina el
pensamiento abstracto
 Predomina el
pensamiento específico
y creativo
y organizado
 Hábil para estructurar
un modelo
 Evalúa la viabilidad de
la solución
 Actúa de forma
independiente de la
plataforma tecnológica
 Hábil para entender
código
 Generalmente es
experto y actúa de
acuerdo con los
lineamientos de una
plataforma tecnológica
2. Proceso de Desarrollo
Arquitecto:
 Evalúa el uso de
frameworks
 Busca la solución más
simple para el
proyecto
 Busca el mejor balance
costo-beneficio al
mediano y largo plazo
para el cliente
 Odia los EJB de
Entidad (J2EE)…
Desarrollador Senior:
 Adopta el uso de
frameworks por
tendencia
 Busca la solución más
simple de programar
 Piensa en lograr los
objetivos puntuales del
proyecto
 No sabe no responde o
le encantan los EJB de
Entidad…
2. Proceso de Desarrollo
Analisis & Design: Business
Integration
La globalización ha traído un problema que en este instante la industria
del software no ha solucionado de manera formal, definitiva y
contundente:
•
Las organizaciones necesitan realizar negocios globales y para ello
requieren información consolidada y en tiempo real.
•
Lo anterior implica que los diferentes sistemas de información que
conforman la organización se encuentren integrados.
•
A nivel técnico existe una tendencia llamada SOA (Arquitecturas
Orientadas a Servicios) que consiste en tipos de productos que
intentan solucionar ese problema a partir de dos enfoques, el
antiguo (mensajería empresarial) y el nuevo (Web Services).
2. Proceso de Desarrollo
Analisis & Design: Business
Integration
•
Otra tendencia frecuentemente malinterpretada es BPM.
•
Tanto la mensajería como los web services y BPM tienen
escenarios bien definidos donde deben o no aplicarse.
•
En el mundo de los web services solo existen 3 estándares
(WSDL, SOAP, WS-Security) si se usan según el WS-I.
•
Por otro lado existen muchas propuestas de estándares que
erróneamente pretenden reinventar el software empresarial pero
programando XML.
•
XML y SOAP deben entenderse como un lenguaje estándar para
comunicar aplicaciones, no una nueva manera de desarrollarlas.
2. Proceso de Desarrollo
Analisis & Design: Business
Integration
•
Finalmente, sea cual sea el desenlace en la
estandarización de productos de Business
Integration, sabremos si la solución es
correcta si al usarla no nos obliga a
depender directamente de web services,
mensajería o BPM sino que integra
transparentemente “servicios”, de
negocio…
2. Proceso de Desarrollo
TESTING:
•
En la industria es marcada la falta de
estandarización en la terminología de pruebas.
•
No son claras las dependencias y tipos de pruebas
y por tanto la estrategia para usarlas mejor…
•
Para proyectos de software, testing es un factor de
costos decisivo para el Project Manager.
•
Usualmente se disminuye el énfasis en estas para
alcanzar los costos del proyecto.
2. Proceso de Desarrollo
TESTING:
2. Proceso de Desarrollo
 QA (metodologías y
buenas prácticas) y
QC (Evaluación del
producto, Testing)
Niveles de Prueba
(Independiente del
tipo de prueba)
 Individual
 Integrado
(módulo/subsistema)
 Sistema
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
4. Pruebas de Instalación
(checklist de entrega a
producción)
2. Proceso de Desarrollo
 Un factor crítico para el éxito es realizar pruebas
unitarias exhaustivas. Por clase y método público
del sistema. “La estabiliad del todo se basa en la
estabilidad de las partes…”
 Es recomendable automatizar y agrupar las pruebas
unitarias por clase, paquete y sistema (Test Cases &
Test Suites).
 Las pruebas unitarias deben ser autónomas e
independientes de los datos, por tanto no deben
existir dependencias en su orden de ejecución.
 Todo lo anterior finalmente concluye en un esquema
automatizado para pruebas de regresión.
2. Proceso de Desarrollo
 Las pruebas de regresión son una
inversión costosa pero a todas luces
sacrificable…
 El no realizarlas es la causa más
común de defectos recurrentes en
entregas a producción después de
haber realizado “supuestamente”
varios ciclos de pruebas.
2. Proceso de Desarrollo

Pese a su aparente falta de rigurosidad, las pruebas
de Guerrilla son la herramienta más ágil de
encontrar defectos.

Se recomienda que se agrupen por tipos:
1.
2.
3.
4.
5.
6.
7.
Pruebas
Pruebas
Pruebas
Pruebas
Pruebas
Pruebas
Pruebas
de
de
de
de
de
de
de
Validación
Control
lógica
lógica inversa
navegación
interacción
consistencia / integralidad
2. Proceso de Desarrollo
 En nuestro medio se menosprecia el valor
de las pruebas de performance pero es
frecuente que la misma funcionalidad
“estable” para un usuario, no lo sea ante
casos de múltiples usuarios, condiciones de
concurrencia y de carga.
 Conociendo lo anterior es un riesgo
asignarlas exclusivamente en fase de
transición (el uso frecuente!!!).
2. Proceso de Desarrollo
 El cliente debe interpretar las pruebas como la última
línea de defensa para implantar o no un software en
producción.
 Generalmente es más costoso para el cliente
implantar un software inestable y que no cumpla con
la funcionalidad requerida que cancelar su instalación
productiva o invertir en pruebas en etapas tempranas
del proyecto.
 En administración de las pruebas es posible que la
empresa de software registre niveles altos de calidad
(0.3 defectos /KLOC) pero en las pruebas de
aceptación y en producción la realidad sea distinta =
No hicimos pruebas lo suficientemente
exhaustivas…!!!
2. Proceso de Desarrollo
 Todos entendemos la importancia de
las pruebas pero no las hacemos
respetar…
 Finalmente, la única gran verdad en
pruebas es que un software nunca se
deja de probar, las pruebas
simplemente se abandonan…
3. Procesos Individuales
Problema: “Un aspecto que origina fracaso en proyectos de
software es la falta de habilidades de planeación,
organización y productividad de los desarrolladores así
como la habilidad de la gerencia para generarlos”
“La productividad y cumplimiento de un equipo depende de la
productividad de las partes”
Solución Propuesta: “Frente a este problema surgío PSP
como una propuesta para mejorar la productividad y
planeación de los ingenieros.
TSP es un set de buenas prácticas especializadas en promover
la productividad y empoderamiento de un equipo para
lograr los objetivos del proyecto”
3. Procesos Individuales
Fortalezas:
 Efectivos para
administrar el
performance de
cada individuo y su
equipo.
 Orientación
netamente práctica
Debilidades:
 No se enfoca en
disciplinas técnicas
importantes dentro de
todo proceso de
desarrollo como análisis
del negocio, ingeniería
de requerimientos,
administración del
ambiente, configuración,
etc.
 Las plantillas de
referencia son
redundantes y en general
poco ágiles.
3. Procesos Individuales
Oportunidades:
 La generación de
estadísticas y
métricas individuales
(PSP) sirven para
estimar directamente
las del proyecto (TSP)
y posteriormente las
de la compañía
(CMM).
 Se complementa muy
bien con un set de
procesos como RUP.
Amenazas:
 La versión más reciente
de PSP (Agosto del
2005) trata los mismos
conceptos de la original
pero es más formal y
rigurosa por lo que se
puede desvirtuar la
practicidad y sencillez del
enfoque inicial.
 TSP NO es un framework
de gerencia de proyectos
sino de administración y
liderazgo de equipos, por
lo mismo no remplaza a
PMI, lo complementa.
3. Procesos Individuales
 PSP/TSP: Como moverse de la teoría a la
práctica (What To How)?
 El mejoramiento requiere cambio y promoverlo
de forma consistente en actores humanos no es
un problema trivial.
 La metodología se implementa desde dos
dimensiones:
 Parte de la coordinación de un proyecto hacia los
miembros del equipo (Reactiva)
 Parte de cada individuo hacia el proyecto (Proactiva)
3. Procesos Individuales
 En las universidades no se enseña normalmente
a como ser productivo
 Cada persona trabaja según sus convicciones y
experiencia en un instante
 Normalmente cada individuo no acepta ser
cuestionado o se autocuestiona
3. Procesos Individuales

PSP/TSP => Rapidez + Calidad

PSP/TSP => Control cuantitativo

PSP/TSP => Cada tipo de actividad debe tener una revisión

PSP/TSP => El tiempo de diseño debe ser al menos igual al de
desarrollo

PSP/TSP => El producto debe entregarse con un 70% de
defectos corregidos

PSP/TSP => Son la alternativa más ágil para iniciar las buenas
prácticas hacia CMMI

No dependen/afectan el uso de otras metodologías o
herramientas.
3. Procesos Individuales (PSP)
3. Procesos Individuales (PSP)

Se concentra en minimizar tiempo y maximizar calidad => ($)

[Deming y Juran (80s)] “La mejor manera de incrementar la
productividad y calidad de cualquier industria era garantizar el
entrenamiento y productividad de las personas”

PSP se considera un subproducto de CMM [Humphrey *** y
Paulk(80s)]

Tiene 2 enfoques de implementación: Reactiva y Proactiva.

Cada individuo debe medir y controlar su propia productividad
3. Procesos Individuales (PSP)
1. Esfuerzo: Total Horas Invertidas
2. Progreso: Variación 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 aceptación
lograr 0.3 defectos/KLOC
“Haber corregido el 70% de los defectos antes de la
entrega al cliente…”
2. Madurez promedio: Después de 4 proyectos.
“Se realizan estimados confiables a partir de info histórica de 3
últimos proyectos…”
3. Procesos Individuales (PSP)
1. Reporte de Actividades (diario)
2. Plan Detallado (Cronograma)
3. Diseño Detallado (Modelos UML clases, secuencias,
Inventario de clases a desarrollar)
4. Reporte de Pruebas (individuales, antes de entregarlo
al PM)
5. Resumen de Resultados (métricas y análisis de toda la
iteración)
3. Procesos Individuales (PSP)
3. Procesos Individuales (TSP)

A diferencia de PSP, es enfático en que el proyecto se cumpla
con los costos establecidos (basado en EVA).

Introduce el concepto de revisiones entre compañeros y
revisiones formales al finalizar una etapa (iteración, fase)

Dada su complejidad los proyectos actuales son
desarrollados por equipos, entre más miembros mayor falta
de control.

Se deben integrar múltiples roles con visiones diferentes.

Se promueve que exista información acerca de la gerencia y
administración en todos los niveles/miembros del equipo.
3. Procesos Individuales (TSP)
Estructura: “Team
Building & Team
Working”




Incepción
Elaboración
Construcción
Transición
3. Procesos Individuales (TSP)

Es recomendable que cada fase se defina entre 2 – 4 meses
aprox.

El Launch está predefinido a 4-5 días (incepción)

Cada Relaunch está predefinido a 2-3 días

El equipo del proyecto es el directamente responsable de la
planeación del proyecto (launch) y cada fase (relaunch)

La gerencia del proyecto revisa cada plan

En cada Launch/relaunch se deben producir planes alternos
para agilizar ante posibles rechazos al plan principal
3. Procesos Individuales (TSP)
Team working: “Manteniendo la productividad adquirida”
1. Liderazgo Activo = Asegurarse que cada individuo pueda
cumplir los compromisos
2. Comunicación constante de parte de la gerencia
3. Compromiso y motivación 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 iteración – 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 revisión.
2. Los participantes no entienden el objetivo de la revisión
3. Los revisores critican el recurso no el producto
4. Las revisiones no se planean y los revisores no están
contextualizados
5. Mezclar reuniones de revisión con reuniones de solución
6. Participación de roles no requeridos (Project Manager)
7. El revisor se concentra en la forma no en el contenido
4. Procesos Corporativos
Problema: “Es común que el fracaso en proyectos de software
empieze antes de empezar el proyecto debido a la manera
artesanal que la empresa proveedora evalúa la viabilidad de
los proyectos en los que va a participar, no es consiente de
trabajar con buenas prácticas para dar mejores y continuos
resultados a sus clientes (sino para cumplir un requisito del
mercado).”
“Un buen Project Manager, arquitecto o desarrollador solamente
avanza hasta donde la empresa para la que trabaja le
permite…”
Solución Propuesta: “El modelo de capacidad y madurez
organizacional del SEI tiene vigencia y creciente aceptación
desde 1987 como un modelo integrado de procesos basados en
buenas prácticas.”
4. Procesos Corporativos
Fortalezas:
 Consolida varias
metodologías y buenas
prácticas

Su adopción es en todo
sentido un proyecto con un
punto de inicio,
presupuesto, riesgos,
entregables y objetivos
claramente delimitados.

El progreso es constante y
cuantitativamente
administrado.

En la práctica se ha
descubierto que aplica para
diferentes tipos de
industrias
Debilidades:

Hereda las debilidades de
las metodologías en las que
se basa.
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 compañía debe adaptar los
lineamientos y buenas prácticas y definir
sus propios procesos. Esto se presta para
definiciones ligeras y poco precisas donde
la toma de decisiones finalmente sigue
quedando a criterio experto (como
generar la estrategia de testing?, en que
pasos realizar el análisis y diseño?, como
identificar los objetivos de planeación en
cada fase del proyecto?, etc.).

Requiere un papel activo de parte del
cliente. En la práctica el mercado impone
restricciones como contratos a precio fijo,
desinformación e inexperiencia de los
clientes.
4. Procesos Corporativos

CMM…

Todas las organizaciones mundiales se administran y operan
con base en sistemas de información

La industria del software particularmente tiene bajo
desempeño en calidad, cumplimiento y funcionalidad de sus
productos. Es artesanal (criterio experto)…

Es un modelo integrado de procesos basados en buenas
prácticas

Busca lograr la madurez de forma planeada, administrada y
medible

Se basa en las lecciones aprendidas en la experiencia
por metodologías predecesoras
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 evolución 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 organización”
4. Administre sus procesos cuantitativamente = Obtenga
calificaciones altas, estables y predecibles en estimaciones y
métricas (como esfuerzo, progreso, productividad, etc.). Ahh!! Y
lógrelo en todos los proyectos de su compañía de forma
consistente en el tiempo.
5. Mejore constantemente: “Plan Estratégico 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, ingeniería de requerimientos,
inicie PSP. Planee e inicie la ejecución del nivel 3
(RUP). Lo difícil acá es la resistencia al cambio.
3. Madure las buenas prácticas de RUP e inicie TSP
cuando los miembros de la compañía sean maduros
en PSP. Planee e inicie la ejecución del nivel 4. Lo
difícil acá es la cantidad de disciplinas o áreas de
procesos que se deben institucionalizar.
4. Procesos Corporativos
 Maturity Levels (1-5):
4. Acá será fácil obtener un base line consistente de los
indicadores y métricas corporativos a partir de los de
cada equipo/proyecto. Planee e inicie la ejecución del
nivel 5. Lo difícil acá no es cuantificar (lo que debió iniciar
desde el nivel 2) sino cuantificar bien y consistentemente
entre proyectos en el tiempo.
5. Logrados los objetivos anteriores, en este nivel se deben
madurar los mecanismos corporativos que
constantemente evalúen y preventivamente apliquen
mejoras a los procesos implantados. Cuando se ha
llegado a este nivel es la mejor oportunidad de
implementar las técnicas de optimización estadística de
SIX Sigma. En niveles previos el costo del esfuerzo no
va a compensar el posible resultado.
4. Procesos Corporativos
 Maturity Levels (1-5):
 La viabilidad de la implantación de CMM depende de la
convicción de la alta gerencia y la capacitación y
experiencia de la gerencia de proyectos.
 El reto del nivel 2 es la resistencia al cambio
 El nivel 3 es el más largo
 El nivel 4 es el más dificil de lograr
 Si lo anterior se realizó bien, el nivel 5 es el más facil de
lograr.
4. Procesos Corporativos
4. Procesos Corporativos
 El modelo continuo es exclusivo de la versión
CMMI. CMM en sus diferentes variantes solo
incluía la representación por niveles (1-5).
 Capability (0-5):
 Los procesos indican el “Que hago?”, la capacidad
indica “Como lo estoy haciendo?”
 El objetivo es que todos los procesos alcancen el
estado de mejoramiento continuo.
4. Procesos Corporativos
4. Procesos Corporativos

La representación continua es más flexible por que parte
del estado particular de la organización (madurez técnica,
costos, cultura).

La representación por niveles es más segura para lograr la
madurez pero requiere un esfuerzo corporativo sincronizado
que se refleja en los costos.

Para una empresa pequeña es más fácil sincronizar
esfuerzos y por lo general más viable adaptar una
representación por niveles.

Para una empresa relativamente madura y con gran
cantidad de personal (aprox. > 200) es recomendable
primero realizar una homologación y valoración para la
toma de decisiones sobre el tipo de representación a seguir.
4. Procesos Corporativos
 Estructura de las PA’s (KPA’s para CMM):
4. Procesos Corporativos
Generis Goals, Common Features: “Buscan
categorizar prácticas genéricas de la PA a toda la
organización”
Commitment To Perform = Políticas de la PA
Ability To Perform = Precondiciones para el éxito de la PA
Directing Implementation = Lineamientos prácticos para
implementar la PA
Verification = Mecanismos para verificar el éxito, estabilidad
y trazabilidad de los productos actuales de la PA vs sus
definiciones y actividades.
4. Procesos Corporativos
Tendencias:
 PeopleCMM: Modelo de madurez para
administración de personal (llevar a la
madurez profesional y crecimiento integral
dentro de la organización).
 SA – CMM: Modelo de madurez para
administrar la adquisición de servicios,
productos y proyectos de Software.
4. Conclusiones Generales
1.
La meta es clara: “La ingeniería de software debe
convertirse en una ciencia (precisa, formal,
detallada) = predecible”
2.
Las metodologías son herramientas, su éxito
depende de cómo las usemos
3.
Desafortunadamente cada metodología enfoca solo
parte del problema y este debe atacarse de forma
integral.
4.
El éxito del proyecto no debe depender de factores
externos o heroicos (criterio experto) sino que
debe ser cuidadosamente planeado y controlado.
4. Conclusiones Generales
 Dada su naturaleza colectiva, el proceso de desarrollo
debe enfrentarse de forma integral en los siguientes
niveles:





Gerencia de Proyectos
Metodología de desarrollo
Arquitectura del Software
Madurez Individual y como equipo
Madurez Corporativa
 Se busca compartir soluciones exitosas a problemas
típicos en el desarrollo de proyectos de software
 Se busca profundizar en aspectos de la práctica que
no son detallados por las metodologías.
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 práctica las metodologías
facilitan el trabajo, en caso contrario
las está usando mal !!!.
 Todo modelo de madurez que
involucre calidad se basa en el
paradigma del mejoramiento continuo
(plan-do-check-act).
4. Conclusiones Generales
 Lo que casi nadie sabe es que las
metodologías expuestas se extrajeron y
formalizaron a partir de la experiencia
práctica. Puede que usted halla hecho PMI
sin saberlo…???
 El principal problema que enfrentan las
metodologías = resistencia al cambio:
“Mitos y malinterpretaciones, por falta de
información y suficiente experiencia
práctica con ellas”
4. Conclusiones Generales
 Tendencias y fallas latentes en la ingeniería
de Software:

Formalización de una metodología de análisis y
diseño (MDA será la respuesta???)

Formalización de una metodología de
normalización de requerimientos
(normalización???)

Formalizar una especificación para productos de
Business Integration (SOA ???)

Y después, que nuevos problemas – soluciones,
retos y paradigmas vendrán ????
Finalmente…
Muchas Gracias por su tiempo !!!
Descargar

Sdsadsad sadsadasdasd