ACIS
Desarrollar proyectos de software y
“evitar” el fracaso ?
Intro
Por Bernardo Díaz Arias
[email protected]
N1: Gerencia de Proyectos - PMI
1.
2.
Overview de PMI
Actividades de Inicio
3.
Actividades de Planeación



4.
5.
6.
7.
8.
9.
Primer paso:
“Aprenda a coordinar un
proyecto”
Comunicación
HR
Administración del Alcance
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 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.
2.
3.
Falta de administración del alcance (S)
Comunicación con el cliente (Comm)
El manejo de los recursos humanos (HR)
N1: Gerencia de Proyectos - PMI
1. 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 - PMI
2. 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 - PMI
2. 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.
2.
Ingeniero de Desarrollo = Concentración + Pensamiento lógico-analítico
Arquitecto = Pensamiento Abstracto + Capacidad de aprendizaje e investigación.
3.
Especificación de requerimientos y pruebas = Organizado, metódico, orientado al
detalle.
PM = Liderazgo + Comunicación (verbal y escrita), visión global.
4.
* 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 - PMI
2. 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:
o
o
o
Cada elemento tiene complejidad 1-5.
A la información histórica NO se le debe calcular holgura (ya la incluye)
La recolección de información termina al generar las tablas de performance de la
organización
1.
2.
3.
4.
Pantallas / módulo
CU / módulo
Componentes / CU
Clases / paquete

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 - PMI
2. 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

Su compromiso: entregables

Fechas de cierre por fase

Formalice todo
administrativas)
N1: Gerencia de Proyectos - PMI
3. 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 - PMI
4.
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 - PMI
5. 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 - PMI
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
Documenta
ció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
Incluye
0,1
0
0,3
0,4
0,4
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
0,5
3.
Sume el total de cada
alternativa.
0,5
4.
Se escoge la
alternativa con mayor
puntaje acumulado
implementa
ciones de
ServicePro
viders /
Handlers
TOTAL
1
2,2
3
3,4
3,65
6. Toma de Decisiones
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 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 - RUP
1. Disciplinas
2. Ejecución Iterativa
3. Fases (tiempo)
Segundo paso:
“Aprenda a construir
software”
4. Adaptación del RUP
5.
6.
7.
8.
Metodología de Modelamiento
Normalización Arquitectónica
QA & QC
Admin. de la Config.
N2: Metodología 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:




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 - RUP
4.
5.
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)
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 - RUP
6.
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 - RUP
11.
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 Pruebas
1.
*** De código

Unitarias

Revisión entre compañeros

Code Profiling
2.
Funcionales
3.
Técnicas

De GUI / Usabilidad

De instalación

De seguridad

De concurrencia / transaccionalidad

De volumen, carga y stress
Niveles de Prueba
1.
Unitario
2.
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.
2.
Plan de Pruebas
Plan de Aceptación
3.
Casos y escenarios de Prueba
4.
5.
Reporte de Defectos
Resumen Ciclo de Pruebas
N2: Metodología de Desarrollo - RUP
Configuration & 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
Tercer paso:
“Toda organización es fruto
de su gente…”
2. Elementos
3. Herramienta para la madurez?
4. Conclusiones
“Que pasaría si la liebre fuera tan organizada, juiciosa
y constante como la tortuga?...”
N3: Individual - PSP
Antecedentes
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 - PSP
Conclusiones

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 continuo
Cantidad = 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 - CMMI
Generalidades:
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.
3.




N0
N1
N2
N3
=
=
=
=
Nivel indeterminado o heroico
Se aplican buenas prácticas
Se estandariza la metodología / proyecto
Se “institucionaliza” la metodología a lo largo de la organización


N4 = Cuantificado y administrado
N5 = Optimizado, mejoramiento continuo
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.
2.
3.
4.
5.
6.
9.
Modelo Propuesto:
1.
2.
3.
4.
5.
10.
Mercados, industrias y clientes a “atacar”
Generación de nuevos productos o estrategias de comercialización de los existentes
Plan de calidad (mejoramiento continuo)
Plan de costos
Plan de Capacitación
***Crecimiento proyectado (mejorar vs. crecer)
PSP
RUP
PMI
CMMI
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)
CMMI vs. ISO ???
Siglas y Abreviaturas I
PMI = Project Management Institut
PM
= Project Manager
Q-$-t = Triple Restricción (calidad-Costo-Tiempo)
Proc = Procurement = adquisiciones y compras
HR
= Recursos Humanos
COMM = Comunicación
EVA
= Earned Value Analisys
FP
= Fixed Price, contratos a precio fijo
T&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 Process
SEI
= Software Engineering Institut
CMMI = Capability Maturity Model – Integration
Siglas y Abreviaturas II
OOP
= 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 !!!
Descargar

Sdsadsad sadsadasdasd