ProcesosIngenieriaSoftwareCMMI PDF

CONTEXTO ACTUAL DE MEJORA A LOS PROCESOS DE
INGENIERÍA DE SOFTWARE SEGÚN EL MODELO CMMi v 1.3

Mario Javier Monsalve Hazbón
Gerente de Proyectos & Consultor en CMMi, Arquitectura Empresarial, SOA, BPM, ITIL, COBIT & ISO 27001
Bogotá, Junio 2 de 2011

Recursos más Relevantes
Bibliografía
 Modelo CMMi del Instituto de Ingeniería de Software
 SWEBOK
 PMBOK
 Ingeniería de Software de Roger S Pressman
 Ingeniería de Software de Ian Somerville
Sitios Web
 www.sei.cmu.edu
 www.pmi.org
 www.construx.com
MEJORA A LOS PROCESOS DE INGENIERÍA DE SOFTWARE SEGÚN EL MODELO CMMi v 1.3

Presentación Preparada por: Mario Javier Monsalve Hazbón ( mario.monsalve@raginwald.com) Diapositiva 8
Contexto e
Introducción

Contexto de la Ingeniería de
Software a nivel mundial y de
Colombia
Ciencia o Arte ?
Moda o Requerimiento ?
Herramienta ?
Negocio ? Industria ?
Solución o Problema ?
Definición de Ingeniería de Software
Ingeniería de software es la disciplina o área
de la Ingeniería que ofrece métodos y
técnicas para desarrollar y mantener
software.
La creación del software es un proceso
intrínsecamente creativo y la Ingeniería del
Software trata de sistematizar este proceso
con el fin de acotar el riesgo del fracaso en la
consecución del objetivo creativo por medio
de diversas técnicas que se han demostrado
adecuadas en base a la experiencia previa.

Ingeniería de Software
 Esta ingeniería trata con áreas muy diversas de la
informática y de las ciencias de la computación, tales
como:
 Construcción de compiladores, sistemas operativos,
o desarrollos Intranet/Internet
 Abordando todas las fases del ciclo de vida del
desarrollo de cualquier tipo de sistemas de
información y aplicables a infinidad de áreas:
• Negocios
• Investigación científica
• Medicina
• Producción
• Logística
• Banca & Finanzas
• Control de tráfico
• Meteorología
• Derecho
• Internet, Intranet, etc.

CAPAS DE LA INGENIERIA DE SOFTWARE
La Ing.Software es una tecnología multicapa

 Enfoque de Calidad
 Proceso
 Métodos
 Herramientas
MARCO DE CALIDAD
 Contexto de Negocios
 Satisfacción de Necesidades de los Stakeholders
 Organización, Orden, Transparencia, Controles
 Estándares Internacionales de mejores prácticas

CAPAS DE LA INGENIERIA DE SOFTWARE
PROCESOS
 Fases del Ciclo de Vida del Software
 Asegurando un Producto Excelente
METODOLOGÍAS
 Orientaciones sobre como manejar el desarrollo a
traves del ciclo de vida del software
HERRAMIENTAS
 Uso de tecnologías para asistir el desarrollo del
software y asegurar el cumplimiento de los objetivos
del software
 Enfoque automático / semiautomático

Características diferenciadoras del
Software
El software desempeña un papel cada vez más
importante en la sociedad actual.
Sin embargo los productos de software se
diferencian de los otros productos.
 Cada vez más Complejo
 Debe cumplir Conformidades (Normas y Estándares)
 Variabilidad (Debe poder personalizarse)
 Invisible
Tendencia de no ser Producto sino un Servicio

EL PRODUCTO DE LA INGENIERÍA DEL SOFTWARE
Características que debe tener el

software
 Económico
 Confiable
 Flexible
 Portable
 Mantenible

REQUERIMIENTOS DE CALIDAD QUE DEBE SATISFACER EL
SOFTWARE

ATRIBUTOS DE CALIDAD DEL SOFTWARE
Cumplir con los siguientes atributos:
 Seguro, Fiable, Tolerante a fallas Functionality
 Comprensible, Fácil de usar Cost Compatibility
 De complejidad baja, Capacity Security

 Fácil de aprender a manejar
 Mantenibilidad Availability Fault tolerance
 Fácil de probar
 Auditable Performance ROI
 Extensibilidad Life Time
 Homogeneidad, Adaptable, Modular, Reutilizable
 Eficaz, Preciso, Exacto
 Compatible, Portable y Acorde al contexto Tecnológico vigente
 Viable financieramente (Costos de Adquisición y Mantenimiento Vs Beneficios
en generación de Valor)

Software Quality Assurance
Aseguramiento de la Calidad del Software
SQA Definición de Revisiones Técnicas

Procesos & Formales
Estandraes
Análisis
& Planeación
Reportes de las
Pruebas e
Mediciones Inspecciones

PARA QUÉ SE HIZO
EL SOFTWARE ?

CUAL ES LA NECESIDAD QUE EL SOFTWARE DEBE
SATISFACER ?
 Ser el medio (herramienta) que permita contribuir a

“poner en orden la organización”
 Que problema puede resolver:
 Mejor gobernabilidad de los procesos de negocio
 Mejorar el ambiente colaborativo y los Niveles de
Satisfacción de sus Stakeholders
• Clientes
• Accionistas
• Empleados
• Aliados de Negocios
• Proveedores
 Métricas (Indicadores de Desempeño)
 Posición Competitiva

PROPOSITO DEL SOFTWARE
MEJORAR LA PRODUCTIVIDAD DE LAS

ORANIZACIONES Y LOS NEGOCIOS
MEJORAR LA CALIDAD DEL VIDA DEL
SER HUMANO (CONTRARRESTAR LO
TEDIOSO, RIESGOSO, INCOMODO, ETC)

ADMINISTRAR LA COMPLEJIDAD DE LAS ORGANIZACIONES
CON HERRAMIENTAS IDONEAS
Listado fallas de equipos nuevos
Contrat. minutos pdos de trabajo

Fiscalización
C uad. O P C H “B ”
Fiscal
O P R iohacha Firma Centro Gas
B anco & Promigas
Informa ción
O fic. Producción
Rde dia
s
zo
Po
Promedios
de Proyectos
Datos
D atos de calibr. as s 1/d Banco de la Republica

eb
P ru Fis cal
ia Fa lla
ea &
O bl
Decadas de Producción
Lineasde conección
A lteraciones, Puntos de
Fa ct
P ru
O P C H “A ” eb Presión, Inhibidores de
Facturas de
as
ur as
D at de Presión, Pruebas de
Repportes
os pr po
od uc lo s valvula subsuelo
P&T
de G
c. Pe
Pr om dido
ed io s M at
s D pto. Ing
Gas
eria Gastos
as
le s B anco
de
Técnicos 1/se Co Petróleos
tr ol
m. n tr
R ep
ra l.
M anto.
C on
ol
Reco
G en
de
etir
di a
Ev alu
O ficina G eneral
.y
A re
P /6
en
Reporte s
om
del
me nd
P ru
na
na
R ec
.es tud
A re
. Instrc c. cierre
or te
eb a
ó apertu
ac ión
y report e diario ra pozos Servicio de fallo
R ep
ios
O P B allena Trabajos realiz.
Orde n de
Trab ajo
es
to C ompañía
Pro ces
pu
diario s . su
esp eci
P
de Tarea s Repo
rtes Jefe de Producción P re C omtratista
Co nta
T Jefe de
o pru eba
Co ntr
ale s.
M antenim iento H ouston
bilida
producción y pruebas 1/D
Fiscalización progreso de
Orden de trabojo, aprob.
ato s
ed
s
rm to .
d - No
fo
s
In M an es
d.
to
Aprobación
tra
de pro
Ingenierosde 1 /m
Sim
ad
on
s. Ecopetrol
rm as
rid
C
id
ul ac
Producción tiv
o
B odega Soldador
d o si se g u
Pedidos Trab
ic
gu nt.
ac
cn
ro s
r.
fo an al
RQ S
Té
fic.
as
Contaduria se m
y pre
In
de Se
fa ll
Pr
io y
r te
od al
me nsu diar
po
uc
y q sió n ,
izac ión
gu ri
me nt.
c. or te
ic o
Fis cal
So
En Rq R ep 00
ajo
tre ,0
u im
rro
Facturas
da d
g. s > 20
Superintendente
ne s
ajo s co
. co
yR id os
Jefe de P ed
pc io
ec
D istriro
o rt
R
ib D
US
17
os
Legal
R ep
Tr ab
Ex ce
M
a ts M ateriales B ogotá Jefe
. de
ió n
ob ac pra
Proveedores A pr C om Facturas
Prod .
pozo x pozo
M ateriales ITD
Rep orte
ales
e intern acion
ras nacio nale
Req. comp
s
r me
fo Pedidos de servicios
In H SE Ac tas
Prom igas & de ca
lib R ecursos
ra ció
C entrogas M arina y co n
R ep rre H um anos
In
. C or cc io M inisterio de
G obierno
s tr
ro sió ne s
Pro gra mas
uc
ny M inas & Energía

Recom endac.
G uajira
.y
Segu
rid ad
pr
oc
Producc. Pedidos
ed
Com pañía M ateriales

.
M antenim iento
Com tratista
Gobierno, Autoridad C ontratista del
C ia. C orrosión y M arina B arco
y Q uim icos N orm as A uditorías
H SE
- Inform e Escrito Inspec. y Recom

endacio nes
- Inform e V erbal
- Instrucción Escrita
- Instrucción V erbal Facturas

REFLEXION !
EL SOFTWARE Y LA
INGENIERIA DE
SOFTWARE ESTAN
CUMPLIENDO EL
PROPOSITO ?

LA CRISIS DEL SOFTWARE !
Bajos niveles de
productividad
Demasiados reprocesos
Sobrecostos
Tiempos de entrega
inoportunos
Complejidad en el proceso
de mejora continua

EL ESTADO DEL DESARROLLO DE SOFTWARE
La mayoría de los proyectos de desarrollo

de software fallan
Qué significa fallar?
 No cumplir los cronogramas
 No cumplir el presupuesto
 No satisfacer la funcionalidad requerida
 Demasiados defectos una vez en producción
 Demasiado frágil a los cambios
 ...

¿Qué tipo de Problemas Surgen?
 Retrasos en los proyectos.

 Falta de calidad.
 Incumplimiento con la funcionalidad
acordada.
 Desarrolladores que improvisan
permanentemente
 Exceso de requerimientos y
funcionalidad.
 Falta de una planificación responsable
 Motivación débil, Falta de participación.
 No existe gestión de riesgos.
ALLSOFT, S.A.. de C.V., Presentación
2002 Preparada por: Mario Javier Monsalve Hazbón ( mario.monsalve@raginwald.com) Diapositiva 27
DESEMPEÑO DE LOS PROYECTOS DE INGENIERIA DE SOFTWARE
Exitosos
29%
Cuestionables
53%
Fallidos
18%
Fuente: Standish Group International

Miles de Millones USD de Desperdicio

EL ESTADO DEL DESARROLLO DE SOFTWARE
Proyectos
cancelados
antes de
terminarse
31.1%
Proyectos
terminados
68.9%
Standish Group International Report, “Chaos” Open Computing

EL ESTADO DEL DESARROLLO DEL SOFTWARE
Proyectos
dentro de los
tiempos y
costos
previstos
16%
84%
Standish Group International Report, “Chaos”, Open Computing

El estado del desarrollo del software
43%
Cuestan
190% más
que el valor
estimado
57%

EL ESTADO DEL DESARROLLO DEL SOFTWARE
Proyectos
que
satisfacieron
totalmente
los
requerimeint
os
58% 42%

LA GESTION TRADICIONAL EN LA INGENIERIA DE
SOFTWARE

LA GESTION EN LA INGENIERIA DE SOFTWARE

EL DESBALANCE ENTRE LA OFERTA & DEMANA DE
SOFTWARE
 CADA VEZ LAS ORGANIZACIONES DEMANDAN MAS APOYO

TECNOLOGICO
 LA ERA POST-INDUSTRIAL o DIGITAL
 NEW ECONOMY
 LOS RECURSOS TECNOLOGICOS NO SOLO REQUIEREN DINERO,
SINO CAPACIDAD DE GESTION
 DISPONIBILIDAD DE EXCELENTES TECNOLOGIAS DE BASE
 INFRAESTRUCTURA CRECIENTE
 TENDENCIA GLOBALIZADA (INTERNET,WEB 2.0 & e-BUSINESS)

REVISION DEL MARCO GENERAL DE LA INGENIERIA DE
SOFTWARE
"La calidad de un
producto es
ampliamente gobernada
por la calidad del
proceso usado para
construirlo“
Mark C. Paulk
REFLEXION

REFLEXIÓN
QUÉ AJUSTES LE DEBEMOS

PRACTICAR A NUESTROS
PROCESOS DE DESARROLLO
DE SOFTWARE PARA QUE
ESTÉN ALINEADAS A LOS
RETOS Y DESAFÍOS DE
NEGOCIO y CAPITALICE EL
POTENCIAL DE LAS TIC´s ?
EL DINAMISMO DE LAS ORGANIZACIONES
DIMENSIONANDO EL CAMBIO DE ESCENARIOS Y
EL CAMINO DE TRANSICION
SITUACION
DESEABLE Y
VIABLE
SITUACION
ACTUAL

PONER LA CASA EN ORDEN

EL SOFTWARE DEBE
ASEGURAR LA
OBTENCIÓN DE LOS
BENEFICIOS DE NEGOCIO
A UNOS COSTOS
RAZONABLES
CALIDAD
 Es un conjunto de propiedades asociadas a un objeto

que le confieren capacidad para satisfacer necesidades
implícitas o explícitas.
 La calidad de un producto o servicio es la percepción
que el cliente tiene del mismo, es una fijación mental
del consumidor que asume conformidad con dicho
producto o servicio y la capacidad del mismo para
satisfacer sus necesidades.
 La calidad significa aportar valor al cliente, esto es,
ofrecer unas condiciones de uso del producto o servicio
superiores a las que el cliente espera recibir y a un
precio accesible

ASEGURAMIENTO
Son las medidas preventivas
que se toman paso a paso
durante un proceso para evitar
que el resultado final no sea
defectuoso
Diferente de Control de
Calidad
 No es solo la Revisión al final del
proceso
 No es solo enfocado al cliente
PANORAMA DE
LA INDUSTRIA
DE SOFTWARE
EN COLOMBIA

ACTIVIDADES DE LA INDUSTRIA

INVERSION DE LOS SECTORES ECONOMICOS EN T.I.

MACRO TENDENCIAS DE CRECIMIENTO

PANORAMA DE LA INDUSTRIA DE SOFTWARE EN COLOMBIA

NO ALCANZAMOS A FIGURAR EN
POSICIONAMIENTO DEL MERCADO DE SW

Cambio esperado en la participación del mercado
mundial de software

PANORAMA DE LA INDUSTRIA DE SOFTWARE EN COLOMBIA

Panorama mundial de la Ing. Software
“La Muralla China del Software”

El Modelo de Software & Servicios de la India

El Modelo de Software & Servicios de la India

 Costo de $(1 ingeniero USA) = $(2.5 ingenieros Colombianos) =
$(5 ingenieros de India) = $(8 ingenieros de China)
 Si nuestra industria de software no se fortalece aplicando
modelos y mejores practicas que internacionalmente sean
reconocidos (Cmmi, ISO´s, IEEE, etc) y se capitalicen las
tecnologías disponibles ;los grandes negocios (> 500mUsd) se
los llevaran las potencias del Software
 El Pez Grande se come al pez Chico !

REFLEXION
“Tuvimos que pelear dos batallas para triunfar.

La primera fue en nuestra mente !”

Modelos de
Procesos de
Ing. Software
EL PROCESO DE SOFTWARE
 OBJETIVOS
 Satisfacer una necesidad de negocio mediante una solución asistida por
Computador.
 Producir el mantenimiento del software hasta el fin de su vida útil.
 BENEFICIOS
 Definir una estructura de proyectos manejable.
 Definir un esquema para planificar, organizar, asignar personal,
coordinar, presupuestar, y dirigir las actividades de la construcción de
software.
 Encadenar las tares y actividades del proceso software de una
determinada forma.
 Determinar la entrega y producción de la documentación guía para el
usuario.
 Determinar que herramientas, técnicas y metodologías de Ingeniería de
Software serán más apropiadas.

LOS MODELOS CONTRARRESTAN LOS MITOS
 Mitos de Gestión
 Resistencia al cambio en la gestión de proyectos
 Con un libro de estándares es suficiente
 Computadores modernos = Buen entorno de desarrollo
 Mitos de Gestión
 Experiencia para saltarse las metodologías
 Incapacidad de los usuarios para comunicar sus necesidades
 Mitos del Cliente
 Ideas genéricas al principio, detalles al final
 Requisitos en continua evolución
 Mitos del Desarrollador
 El trabajo acaba cuando se ha escrito el programa y funciona
 Hasta que no se ejecuta el programa no puede comprobarse su calidad
 Sólo se entrega un programa funcionando
 Lo que uno crea sólo debe entenderlo él

LA ESTRATEGIA DE SALVAMENTO DE LA INGENIERIA DE
SOFTWARE EN LAS ORGANIZACIONES
PERSONAL
NUEVOS NUEVAS COMPETENTE CON LA ORGANIZACIÓN
PROCESOS + TECNOLOGIAS + ACTITUD ADECUADA Y = MAS EFECTIVA
ALINEADA A LAS
METAS DEL NEGOCIO
Asegurables

EL ÉXITO EN DESARROLLO DE SOFTWARE

LA CORRECTA APLICACIÓN DE LA TECNOLOGIA EN UN e-BUSINESS
NUEVOS
PROCESOS

UN ANTI-EJEMPLO DE UTILIZACION DE LAS
TECNOLOGIAS

UN ANTI-EJEMPLO DE UTILIZACION DE LAS TECNOLOGIAS…
CONTINUACION

UN ANTI-EJEMPLO DE UTILIZACION DE LAS TECNOLOGIAS…
CONTINUACION

DOS ENFOQUES DE GESTION EN LOS PROCESOS
Orquestado
 Bien Diseñado
 Monitoreado
Improvisado
 Fruto de la
Inspiración
 Centrado en Héroes

EL PROPOSITO DE LOS MODELOS ES EL DE
CONTRARRESTAR LAS MALAS PRACTICAS
Todo empieza con optimismo y

entusiasmo !

CONTRARRESTANDO LAS MALAS PRACTICAS
Pero muchas de las iniciativas de gestion

de la calidad fracasan !

 Los problemas empiezan en las practicas gerenciales del

proceso tecnológico (algunas veces el exceso de confianza)

 No se le da la importancia sino a la ultima capa del software,

ignorando sus fundamentos

EN EL DESARROLLO DE SOFTWARE
El éxito no es cuestión de suerte, es

cuestión de actitud profesional.

NO IGNORAR LAS MEJORES PRACTICAS
LO MEJOR
EN SU CLASE.
“CLASE MUNDIAL”
LAS MEJORES PRACTICAS
MEJORA DE LAS PRACTICAS ACTUALES
IGUAL O INFERIOR A LAS PRACTICAS CORRIENTES
Esquema Universal de Mejores Practicas

Las Mejores Prácticas: Estándares de IT

MAPA DE MODELOS QUE ORIENTAN LA GESTION T.I.

CAPITALIZANDO LAS NUEVAS TECNOLOGIAS EN LA INGENIERIA
DE SOFTWARE
NUEVAS
TECNOLOGIAS

Contexto de tendencias
en Ingeniería de
Software

PANORAMA DE LAS GENERACIONES DE T.I.

PANORAMA DE LAS GENERACIONES DE T.I.

INGENIERIA DE SOFWARE ASISTIDA POR HERRAMIENTAS
 Herramientas de Modelamiento & Arquitectura
 EA-TOOLS: Troux, Rational Systema Architect, Enterprise Architect, Power Designer, Visio
 Herramientas para gestión de requerimientos
 Requisite Pro, Doors, Gforge, RedMine
 Herramientas para Gestión de la Configuración
 SubVersion, CVs, Clearcase
 Herramientas para Especificación de Casos de prueba
 TestLink
 Herramientas para gestión de defectos
 Mantis, Elementtool
 Herramientas para Planeación y Control de Proyectos
 Project, EPM, RPM, Gforge, Web2Project, Project.net, Primavera, PlanView
 Automatización de Pruebas
 Rational SQA Test, Robot, WinRunner, Remedy
 Herramientas para gestión de contenido
 Life Ray
 Herramientas para generación de código
 Genexus, RationalRose
 Herramientas de Gestión de Flujos de Trabajo (WF) e Incidentes (Service Desk)

Algunos Estándares de Calidad

¿ Qué se busca al implantar un estándar de
Calidad de Software ?
Nivel X Control de calidad

# Errores / KLOCS
Proceso de
mejoramiento Nivel Y
Tiempo
Sistema de Calidad de Software
 Estándares
 Revisiones
 Pruebas
 Análisis de defectos
 Administración de la configuración
 Seguridad
 Educación
 Administración de contrataciones
Las personas responsables por los proyectos del software son sólo quienes pueden
ser responsable por calidad. El papel de SQA es supervisar la manera en que estos
grupos ejecutan sus responsabilidades. Humphrey

LAPSO NORMAL ENTRE ORIGEN Y
APARICION DE DEFECTOS
Requerim. Diseño Program. Document. Testing Mantenimiento

Origen
Aparición
Zona de Caos

LAPSO ENTRE ORIGEN Y APARICION DE
DEFECTOS EN UN PROCESO CONTROLADO

Origen
Aparición

GOBERNANDO EL CICLO DE VIDA DE UNA SOLUCION DE
SOFTWARE
4. CONSECUCION DE RECURSOS
1. DIMENSIONAMIENTO
ESTRATEGICO (FORMULAR Y 5. ADQUISICION & ALISTAMIENTODE
VIABILIZAR EL PROYECTO) LA INFRAESTRUCTURA TECNOLOGICA
As-Is & To-Be (Alto Nivel)
6. DESARROLLO/PERSONALIZACION DEL
SOFTWARE Y PRUEBAS TECNICAS
3. DISEÑO -
2. ANALISIS DETALLADO ARQUITECTURA DEL
DE LA SITUACION ESCENACIO DESEABLE 7. ALISTAMIENTO DE LOS 12. PRUEBAS PILOTO
SISTEMAS DE INFORMACION 13.ADAPTACIONE
ACTUAL (As-IS) Y VIABLE & SATELITES Y LOS SERVICIOS DE / SIMULACROS
S FINALES
PLANEACION DEL NEGOCIO
(Ingeniería de PROYECTO
Requerimientos)
14. CHEQUEO DE
To-Be 8. ORGANIZACIÓN DE LA
INFORMACION A MIGRAR CONDICIONES
PREVIAS A LA PUESTA
9. CONFIGURAR & PARAMETRIZAR
APLICACION
EN MARCHA
10. PREPARACION 15. PUESTA EN

DOCUMENTACION MARCHA
11. PREPARACION DEL PERSONAL

(COMPETENCIAS) 16. ESTABILIZACION &
SOPORTE
19. MEJORAMIENTO 18. SEGUIMIENTO AL 17. GESTION
CONTINUO DESEMPEÑO INCIDENTES

El proceso de Software: Modelo IDEAL

Presentación Preparada por: Mario Javier Monsalve Hazbón ( mario.monsalve@raginwald.com)
[McFeeley 96]
Diapositiva 86
CMM: Marco de Trabajo
Capability Maturity Model - SEI
Optimizado
Dirigido 5 Niveles de Madurez

18 Áreas Clave en el CVS
Definido
Marco de trabajo del proceso común en la Organización
Repetible Actividades del Marco de Trabajo
Inicial Conjunto de Tareas

Tareas
Hitos, entregas
Puntos SQA
Actividades de Protección

Las estadísticas muestran que ….
El 70% o mas de los problemas en

Ingeniería de Software están
relacionados con el proceso.
El 30% relacionados con otros

aspectos

CAPABILITY
Presentación Preparada por: Mario Javier Monsalve Hazbón ( mario.monsalve@raginwald.com) MATURITY
Diapositiva 88 MODEL (CMM)
Categorías de los procesos en CMMi

CATEGORIAS & AGRUPACIÓN x NIVELES

ACRONIMOS DE LOS PROCESOS CMMi

PROYECTO SPICE, ISO/IEC TR 15504
Software Process Improvement and Capability dEtermination
Identifica Mejora
Cambios a del
Conduce a
Proceso
Sujeto a Puede
Valoración
Conducir a
Proceso del
Proceso
Determinar
Conduce a Nivel de
Está Madurez
sometido a

TEMA 4: EL MODELO
INTEGRADO DE MADUREZ DE LA
CAPACIDAD DEL SOFTWARE
CMMi

MARCO DE MODELOS PARA MEJORAR CALIDAD DEL
SOFTWARE

Implementación y Valoración de CMMI
CMMi – Capability Maturity Model Integration
NIVELES DE MADUREZ
5 Enfoque mejoramiento procesos Optimizado
4 Proceso medido y controlado

Administrado
cuantitativamente
3 Proceso caracterizado por la

organización y pro actividad Definido
2
Proceso caracterizado por
proyectos y son usualmente reactivos Gestionado
1
Proceso impredecible,
Inicio
pobremente controlado y reactivo

Categorías de los procesos en CMMi

ACRONIMOS DE LOS PROCESOS CMMi

COMPAÑIAS VALORADAS EN NIVELES CMMi

ESTADISTICAS DE CMMi (2010)

Empresas con evaluación CMMi

Nivel 2 - Repetible
EL RETO:
DISCIPLINAR EL
PROCESO DE
SOFTWARE
AREAS CLAVES DE PROCESO CMMi
Nivel 2:
1. PP- Planeación de Proyectos de Software
2. PMC- Control y Seguimiento de Proyectos de
Software
3. REQM- Administración de Requerimientos
4. CM- Administración de la Configuración de los
Componentes del Software
5. SAM- Gestión de Terceros en el Proceso de
Desarrollo de Software
6. PPQA- Aseguramiento de estándares de calidad en
el software (Producto & Proceso)
7. MA- Definición de Métricas y Análisis del
Desempeño de los Procesos de Software
LOS CINCO NIVELES DE LA MADUREZ DEL PROCESO DE SOFTWARE
(Nivel 2: REPETIBLE)
Proceso
Consistente
y Estándar
Repetición de
Experiencias Exitosas
REPETICIÓN DE EXPERIENCIAS EXITOSAS
 El objetivo son los proyectos

 Repetir los éxitos logrados con proyectos similares
 Control gerencial básico y disciplina en el proceso
 Se establecen políticas y procesos básicos de Administración de
proyectos
 Se fija y controla la obtención de los requerimientos de software
 Se definen y se siguen estándares para los proyectos de desarrollo de
software
 El proceso es disciplinado
 Proyectos exitosos son frecuentes

Nivel 3 - Definido
Apagados los incendios,

defina procesos y opere a
nivel de organización

NIVEL 3 DE CMMi
 Nivel 3:
 RD- Desarrollo de los Requerimientos
 TS- Soluciones Técnicas
 VAL- Validación (Pruebas)
 VER- Verificación (Proceso)
 OPF- Enfocar a la Organización a Operar x Procesos
 OT- Programa de adiestramiento
 IPM- Integración Gerencia Proyecto e Ingeniería de S/W
 PI- Ingeniería de productos de S/W
 RSKM- Gestión de Riesgos
 DAR- Análisis de Decisiones y Resolución

LOS CINCO NIVELES DE LA MADUREZ DEL
PROCESO DE SOFTWARE
Proceso
Predecible
Definición del
Proceso Estándar
DEFINICIÓN DEL PROCESO ESTANDAR

 El objetivo es la organización
 Los aspectos claves del proceso son conocidos y
utilizados en toda la organización
 El proceso de desarrollo y mantenimiento de software es
estandarizado
 El proceso estándar es una integración de las actividades
administrativas y de ingeniería de software
 Todos los proyectos usan y ajustan a sus necesidades, el
estándar aprobado para mantener o desarrollar el
software.

Nivel 4 - Administrado
Conozca sus procesos

cuantitativamente

LOS CINCO NIVELES DE LA MADUREZ DEL
PROCESO DE SOFTWARE
Proceso
Mejorándose
Contínuamente
GESTIÓN EFECTIVA
Gestión
 Se recolectan medidas detalladas de la calidad, Efectiva
tanto del proceso de desarrollo mismo como del
software
 El proceso de desarrollo y los productos
obtenidos son comprendidos y controlados
cuantitativamente
 La productividad de los procesos también es
medida y controlada
 El proceso de desarrollo es predecible
ÁREAS CLAVES
 Gestión de la calidad del software
 Gestión cuantitativa del proceso

Nivel 5 - Optimización
Mejore constante y
permanentemente

Organización Madura
“Una organización madura, en contraste,
posee“habilidad a través de toda la
compañía para desarrollar y mantener
software. Posee habilidad para transmitir
tanto a los nuevos como a los empleados
actuales el proceso de software y lleva a
cabo las actividades de acuerdo con los
planes. Los procesos están documentados,
se utilizan y son consistentes con la forma
real de trabajo. ”
Organización Madura
“Las definiciones de procesos se actualizan
cuando“ es necesario y las mejoras se
desarrollan a través de pruebas piloto y
análisis de costo - beneficio. Los roles y
responsabilidades son claros en los procesos
y a través de toda la organización... En
general, las organizaciones maduras siguen
un proceso disciplinado consistentemente
porque todos los participantes entienden el
valor de hacerlo así ”.
GENERALIDADES
DE CADA UNA DE
5 LAS AREAS DE
PROCESOS DE
CMMi
AREA DE PROCESOS DE PROYECTOS

AREA DE PROCESOS DE INGENIERIA

AREA DE PROCESOS DE SOPORTE

AREA DE PROCESOS DE GESTION X PROCESOS

METAS DE CADA AREA DE PROCESO

AREAS AVANZADAS DE PROYECTOS

AREAS AVANZADAS DE SOPORTE

AREAS AVANZADAS DE GESTION X PROCESOS

RD- Desarrollo de los Requerimientos
 El propósito del Desarrollo de requerimientos (RD) es producir y analizar
los requerimientos de cliente, de producto y de componente del producto.
 Identifica las necesidades del cliente y traduce dichas necesidades en
requerimientos del producto. El conjunto de requerimientos del producto
se analiza para producir una solución conceptual de alto nivel. Este
conjunto de requerimientos se asigna entonces para establecer un
conjunto inicial de requerimientos de componentes del producto.
 Otros requerimientos que ayudan a definir el producto se derivan y asignan
a componentes del producto. Este conjunto de requerimientos del
producto y de componentes del producto describe de manera clara la
ejecución del producto, las características del diseño, los requerimientos
de verificación, etcétera, de tal modo que el desarrollador pueda
comprender y usar.
 Este proceso va desde la identificación de los requerimientos de software
hasta dejarlos generados y aprobados por los involucrados para que el
proceso de administración (REQM) los custodie y controle los cambios que
surjan.
RD-DESARROLLO DE LOS REQUERIMIENTOS
IEEE Std 830-1998

RD-DESARROLLO DE REQUERIMIENTOS
Metas específicas para Desarrollo de

Requerimientos (SG-RD)
 SG 1 Establecer los requisitos del cliente
• Las Necesidades de los interesados, expectativas, limitaciones, y
las interfaces son recogidos y traducidos a los requerimientos del
cliente.
 SG 2: Desarrollar los requisitos del producto
• Los requerimientos del cliente son refinados y elaborados para
desarrollar los requisitos del producto y el producto de los
componentes.
 SG 3 Analizar y validar los requisitos
• Los requisitos son analizados y validados, y una definición de la
funcionalidad requerida desarrollados.

TS- Soluciones Técnicas
 El propósito de la Solución técnica (TS) es diseñar, desarrollar e implementar
soluciones para los requerimientos. Las soluciones, los diseños y las
implementaciones engloban productos, componentes de producto y procesos
del ciclo de vida asociados al producto, individualmente o en combinación,
según sea apropiado.
 El área de proceso se enfoca en:
 Evaluar y seleccionar soluciones (referidas a veces como “planteamiento
de diseño”, “conceptos de diseño” o “diseños preliminares”) que
potencialmente satisfacen un conjunto apropiado de requerimientos
asignados.
 Desarrollar diseños detallados para las soluciones seleccionadas
(detallados en el contexto de contener toda la información necesaria para
fabricar, codificar o, de otra manera, implementar el diseño como un
producto o componente de producto).
 Implementar los diseños como un producto o componente de producto.

TS- Soluciones Técnicas
 Resumen de metas y prácticas específicas
 SG 1 Seleccionar las soluciones de componentes de producto.
 SP 1.1 Desarrollar las soluciones alternativas y los criterios de selección.
 SP 1.2 Seleccionar las soluciones de componentes de producto.
 SG 2 Desarrollar el diseño.
 SP 2.1 Diseñar el producto o el componente de producto.
 SP 2.2 Establecer un paquete de datos técnicos.
 SP 2.3 Diseñar las interfaces usando criterios.
 SP 2.4 Realizar los análisis sobre si hacer, comprar o reutilizar.
 SG 3 Implementar el diseño de producto.
 SP 3.1 Implementar el diseño.
 SP 3.2 Desarrollar la documentación de soporte de producto.

PP- Planeación de Proyectos de Software
 El proceso PP tiene como propósito el Desarrollar y mantener los

planes del proyecto, los compromisos adquiridos por parte de los
participantes del proyecto y gestiona las partes interesadas del
proyecto
 El proceso de PP se desagrega en los siguientes subprocesos:
 Planificación del Alcance (G. Alcance).
 Definición del Alcance (G. Alcance).
 Creación de EDT(WBS) (G. Alcance).
 Definición de Actividades (G. Tiempo).
 Establecimiento de Secuencia de Actividades (G. Tiempo).
 Estimación de Recursos (G. Tiempo).
 Estimación de la Duración de las Actividades (G. Tiempo).
 Desarrollo del Cronograma (G. Tiempo).

PP-PLANEACION DE PROYECTOS
 Practicas específicas para Planeación de proyectos (SP-PP)
 SG 1. Establecer estimaciones
• SP 1.1 Establecer el alcance del proyecto
• SP 1.2 Establecer y mantener estimaciones para los atributos de trabajo y los
atributos de las tareas
• SP 1.3 Definir el ciclo de vida del proyecto
• SP 1.4 Determinar estimaciones de esfuerzo de trabajo y costo
 SG 2. Desarrollar un plan de proyecto
• SP 2.1 Establecer un presupuesto y un cronograma
• SP 2.2 Identificar los riesgos de proyecto
• SP 2.3 Planear la administración de los datos
• SP 2.4 Planear los recursos para llevar a cabo el proyecto
• SP 2.5 Planear para las necesidades de conocimiento y habilidades
• SP 2.6 Planear la participación de los interesados en el proyecto
• SP 2.7 Establecer el plan del proyecto
 SG 3. Obtener compromisos hacia el plan
• SP 3.1 Revisar los planes que afecten el desarrollo del proyecto
• SP 3.2 Conciliar el trabajo y el nivel de recursos
• SP 3.3 Obtener un plan de compromisos

PMC- Control y Seguimiento de Proyectos de Software
 El proceso de monitoreo y control de proyectos (PMC)

tiene como propósito el proveer un entendimiento del
avance del proyecto a fin de que las acciones
correctivas sean tomadas en el momento en el que el
proyecto se desvié significativamente del plan
 Es muy importante tener en cuenta, para el monitoreo
y el control del proyecto, la documentación del
proyecto y la estructura de desglose de trabajo (EDT)
como medida de control del proyecto para tomar las
acciones correctivas necesarias en caso de que el
proyecto se desvié significativamente del plan.

PMC
 Gestión de Integración
 Supervisión y control del trabajo del proyecto
 Control integrado de cambios
 Gestión de Alcance
 Verificación de alcance
 Control de alcance
 Gestión de Tiempo
 Control del cronograma
 Gestión de Costos/Presupuesto
 Control de Costos/Presupuesto
 Gestión de la Calidad
 Control de la calidad
 Gestión de Recurso Humano
 Gestión del equipo del proyecto
 Gestión de las Comunicaciones
 Informe de rendimiento
 Gestión a los interesados
 Gestión de los Riesgos
 Seguimiento y control de riesgos

PMC
 Practicas específicas para Monitoreo y control de proyectos (SP-PMC)
 SG 1. Monitoreo del proyecto contra el plan
 SP 1.1 Monitoreo de los parámetros del plan del proyecto
 SP 1.2 Monitoreo de compromisos
 SP 1.3 Monitoreo de los riesgos del proyecto
 SP 1.4 Monitoreo de la gestión de la información
 SP 1.5 Monitoreo del involucramiento del Stakeholder
 SP 1.6 Revisar periódicamente el progreso del proyecto, el rendimiento y los problemas
 SP 1.7 Revisión de los logros y resultados en los hitos del proyecto seleccionado
 SG 2. Administración de las acciones correctivas al cierre
 SP 2.1 Análisis de los inconvenientes
 SP 2.2 Toma de acciones correctivas
 SP 2.3 Administración de las acciones correctivas

REQM- Administración de Requerimientos
 Mantiene los requerimientos de software que fueron generados por

el proceso de Desarrollo de Requerimientos (RD).
 Describe las actividades para obtener y controlar los cambios a los
requerimientos, y asegurar que otros planes y datos relevantes se
mantengan actualizados. Proporciona la trazabilidad de los
requerimientos desde el cliente al producto y de éste a sus
componentes.
 La Gestión de requerimientos asegura que los cambios a los
requerimientos se reflejan en los planes, actividades y productos
de trabajo del proyecto. Este ciclo de cambios puede afectar a
todas las otras áreas de proceso de Ingeniería; así, la Gestión de
requerimientos es una secuencia de eventos dinámica y a menudo
recursiva. El área de proceso de Gestión de requerimientos es
fundamental para un proceso de diseño de ingeniería controlado y
disciplinado.

 Este proceso de administración de los
requerimientos de software cubre la recepción
de los requerimientos generados por el proceso
de Desarrollo de Requerimientos (RD) y
controla la gestión de cambios de los mismos
 Se Desagrega en:
 Administrar el sistema de información de los
requerimientos
 Obtener una comprensión de los requerimientos
 Obtener el compromiso sobre los requerimientos
 Gestionar los cambios de los requerimientos
 Mantener la trazabilidad bidireccional de los
requerimientos

 ADMINISTRAR EL SISTEMA DE INFORMACIÓN DE LOS REQUERIMIENTOS
 Recepción de requerimientos aprobados
 Registrar los estados del requerimiento
 Registrar Fecha y Hora de la modificación
 Registrar responsables
 Registrar la descripción de los cambios
 OBTENER UNA COMPRENSION DE LOS REQUERIMIENTOS
 Establecer los criterios para distinguir a los proveedores apropiados de requerimientos.
 Establecer los criterios objetivos para la evaluación y la aceptación de los
requerimientos.
 Analizar los requerimientos para asegurar que se cumplen los criterios establecidos.
 Alcanzar una comprensión de los requerimientos con el proveedor de requerimientos
para que los participantes del proyecto puedan comprometerse con ellos.
 OBTENER EL COMPROMISO SOBRE LOS REQUERIMIENTOS
 Evaluar el impacto de los requerimientos sobre los compromisos existentes
 Negociar y registrar los compromisos

REQM
 GESTIONAR LOS CAMBIOS DE LOS REQUERIMIENTOS
 Documentar todos los requerimientos y los cambios a los requerimientos que
son dados o generados por el proyecto.
 Mantener la historia de cambios de requerimientos con la razón del cambio.
 Poner los requerimientos y los datos de los cambios disponibles para el
proyecto.
 MANTENER LA TRAZABILIDAD BIDIRECCIONAL DE LOS REQUERIMIENTOS
 Mantener la trazabilidad de los requerimientos.
 Mantener la trazabilidad de los requerimientos desde un requerimiento a sus
requerimientos derivados
 Generar la matriz de trazabilidad de los requerimientos.
 Revisar los planes, las actividades y los productos de trabajo del proyecto en cuanto a la
consistencia con los requerimientos y los cambios realizados a ellos.
 Identificar la fuente de la inconsistencia y la razón.
 Identificar los cambios que necesitan realizarse a los planes y a los productos de trabajo
resultantes de los cambios a la línea base de los requerimientos.
 Iniciar las acciones correctivas

CM- Administración de la Configuración de los
 El propósito de la Gestión de configuración (CM) es establecer y
mantener la integridad de los productos de trabajo utilizando la
identificación de configuración, el control de configuración, el
registro del estado de configuración y las auditorías de
configuración.
 El área de proceso de Gestión de configuración implica:
 Identificar la configuración de los productos de trabajo
seleccionados que componen las líneas base en puntos
determinados en el tiempo.
 Controlar los cambios a los elementos de configuración.
 Construir o proporcionar especificaciones para construir los
productos de trabajo a partir del sistema de gestión de
configuración.
 Mantener la integridad de las líneas base.
 Proporcionar a los desarrolladores, usuarios finales y clientes
datos del estado exacto y de la configuración actual.

Es un área Transversal a los demás

procesos
Es común en RUP, ITIL, COBIT

 Algunos ejemplos de productos de trabajo que pueden

ponerse bajo gestión de configuración son:
 Planes.
 Descripciones de proceso.
 Requerimientos.
 Datos de diseño.
 Dibujos.
 Especificaciones de producto.
 Código.
 Compiladores.
 Ficheros de datos de producto.
 Publicaciones técnicas de producto.

CM Administración de la Configuración de los
Administración de la
configuración
SG1/ Establecer SG2/ Seguimiento y SG3/ Establecer la

Líneas base control de cambios integridad
SP1.1/ Identificar SP2.1/ Seguimiento SP3.1/ Establecer

artículos de la a las solicitudes de registro de
configuración cambios administración de
la configuración
SP1.2/ Establecer SP2.2/ Controlar
SCM los artículos de la
configuración SP3.2/ realizar
auditorias
SP1.3/ Crear o
liberar líneas base

SAM- Gestión de Terceros/Contratistas en el Proceso de
 El propósito de la SAM (Administración de Acuerdo con

Proveedores) es administrar la adquisición de productos
de proveedores.
 El área de proceso SAM involucra:
 Determinar el tipo de adquisición que será usado para los
productos a ser adquiridos
 Seleccionar el tipo de proveedores.
 Seleccionar y mantener • acuerdos con proveedores.
 Ejecutar el acuerdo de proveedores.
 Monitorear el proceso de proveedores seleccionados.
 Evaluar el trabajo de los productos del proveedor seleccionado.
 Aceptar la entrega de productos adquiridos.
 Trasladar productos adquiridos al proyecto

SAM- Gestión de Terceros/Contratistas en el Proceso de
SG1 Establecer acuerdos con los proveedores
 SP 1.1 Determinar el tipo de adquisición
 SP 1.2 Seleccionar proveedores
 SP 1.3 Establecer acuerdos con los proveedores
SG2 Satisfacer acuerdos con los proveedores
 SP 2.1 Ejecutar el acuerdo con el proveedor
 SP 2.2 Monitorear los procesos del proveedor seleccionado
 SP 2.3 Evaluar el trabajo del producto del proveedor
seleccionado
 SP 2.4 Aceptar el producto adquirido
 SP 2.5 Transición de productos

PPQA- Aseguramiento de estándares de calidad en el
software (Producto & Proceso)
 El objetivo del proceso PPQA es proveer a los miembros

de la organización una información objetiva obtenida
de evaluaciones en las que se revisan las actividades
sobre los procesos y los productos de trabajo.
 El área de proceso PPQA Involucra:
 Evaluación objetiva de procesos realizados, productos de
trabajo y servicios, frente a los descripciones de trabajo,
estándares y procedimientos.
 Identificación y documentación de no-conformidades.
 Proporcionar retroalimentación al equipo (Staff) de proyectos
sobre los resultados de actividades de garantía y de calidad.
 Aseguramiento del re-direccionamiento de las no-
conformidades.

PPQA
 Puntos Clave de PPQA:

 Garantizar la adherencia a los Procesos de CMMi en la
organización
 Despliegue consistente
 Retroalimentación Objetiva
 Proveer una Mejora Continua en los procesos de la Organización

PPQA
PPQA/Plantillas
 Reporte de no conformidad.doc
 Plan de evaluacion.doc
 Instructivo de evaluacion.doc
 Informes de evaluacion.doc
 Informe Final de evaluacion.doc
 Informe de Tendencias de calidad.doc
 Informe de no conformidades.doc
 Informe de acciones correctivas.doc
 Matriz de control de no conformidades.xls

MA- Definición de Métricas y Análisis de los Procesos de
Software
 El propósito de la Medición y análisis (MA) es desarrollar y sustentar una

capacidad de medición que se utiliza para poder dar soporte a las
necesidades de información de la gerencia.
 El área de proceso de Medición y análisis involucra:
 Especificar los objetivos de medición y análisis de modo que estos estén
alineados con las necesidades de información y los objetivos identificados.
 Especificar las medidas, las técnicas de análisis y los mecanismos para la
recogida de datos, almacenamiento de datos, informes y realimentación.
 Implementar la recogida, almacenamiento, análisis e informes de los datos.
 Proporcionar resultados objetivos que puedan utilizarse en la toma de
decisiones informadas y en la toma de acciones correctivas apropiadas.
 La integración de las actividades de medición y análisis en los procesos del
proyecto da soporte a:
 La planificación y estimación objetivas.
 El seguimiento del rendimiento real frente a los planes y objetivos
establecidos.
 La identificación y resolución de problemas relativos al proceso.
 El suministro de una base para incorporar la medición en procesos adicionales
en el futuro.
MA- Definición de Métricas y Análisis de los Procesos de
Software
 Resumen de Metas y prácticas específicas

 SG 1 Alinear las actividades de medición y análisis.
 SP 1.1 Establecer los objetivos de medición.
 SP 1.2 Especificar las medidas.
 SP 1.3 Especificar los procedimientos de recogida y de
almacenamiento de datos.
 SP 1.4 Especificar los procedimientos de análisis.
 SG 2 Proporcionar los resultados de la medición.
 SP 2.1 Recoger los datos de la medición.
 SP 2.2 Analizar los datos de la medición.
 SP 2.3 Almacenar los datos y los resultados.
 SP 2.4 Comunicar los resultados.

PI- Integración de producto de S/W
 El propósito de Integración de producto (PI) es ensamblar el producto a
partir de sus componentes, asegurar que el producto, una vez integrado,
funciona correctamente, y entregar el producto.
 Esta área de proceso trata la integración de los componentes de producto
dentro de componentes de producto más complejos o de productos
completos.
 El alcance de esta área de proceso es lograr la integración del producto
completo a través de un ensamblaje progresivo de los componentes, en
una etapa o en etapas incrementales, de acuerdo a una secuencia y
procedimientos de integración definidos. En todas las áreas de proceso-,
donde usamos los términos de producto y componente de producto, su
significado previsto engloba también a los servicios y a sus componentes.
 Un aspecto crítico de la integración de producto es la gestión de
interfaces internas y externas de los productos y de los componentes de
producto, para asegurar la compatibilidad entre las interfaces. Se debe
poner atención a la gestión de la interfaz a lo largo de todo el proyecto.
 La integración de producto es más que un ensamblaje de una vez de
componentes de producto a la finalización del diseño y la fabricación.
PI- Integración de producto de S/W
Resumen de Metas y prácticas específicas
 SG 1 Preparar para la integración de producto.
 SP 1.1 Determinar la secuencia de integración.
 SP 1.2 Establecer el entorno de integración de producto.
 SP 1.3 Establecer los procedimientos y los criterios de integración de producto.
 SG 2 Asegurar la compatibilidad de la interfaz
 SP 2.1 Revisar la completitud de las descripciones de la interfaz.
 SP 2.2 Gestionar las interfaces.
 SG 3 Ensamblar los componentes de producto y entregar el producto.
 SP 3.1 Confirmar la disponibilidad de los componentes de producto para su
integración.
 SP 3.2 Ensamblar los componentes de producto.
 SP 3.3 Evaluar los componentes de producto ensamblados.
 SP 3.4 Empaquetar y entregar el producto o el componente de producto.

VAL- Validación (Pruebas)
 El objetivo del proceso VAL es demostrar que un

producto o componentes del producto cumplen su uso
planeado cuando es ubicado en su planeado ambiente.

VAL- Validación (Pruebas)
 La validación asegura que “se construye la cosa

correcta”.
 La verificación asegura que “se construye correctamente”.
 El área de proceso VAL Involucra:
 Seleccionar los productos a validar.
 Establecer el entorno de validación.
 Establecer los procedimientos y los criterios de validación.
 Preparar la Validación
 Seleccionar los productos a validar
 Validar el producto o los componentes del producto
 Realizar la validación.
 Analizar los resultados de la validación.

VAL- VALIDACION

VAL – VALIDACION
 SELECCIONAR LOS PRODUCTOS O COMPONENTES A VALIDAR
 Se Listan los productos o entregables del proyecto desglosados en sus componentes, estableciendo prioridad y su nivel de impacto según las
necesidades del usuario.
 Se evalúa los datos de la lista y se seleccionan los de mayor ponderado.
 Establecer el alcance de la validación.
 Seleccionar los métodos de validación.
 ESTABLECER EL ENTORNO DE VALIDACION
 Se identifican los requerimientos de entorno de validación
 Se identifican los productos suministrados por el cliente
 Se identifican los elementos de reutilización.
 Se identifican el equipamiento y las herramientas de prueba.
 Se identifican los recursos de validación que están disponibles para reutilización y modificación.
 Se planifica en detalle la disponibilidad de los recursos.
 ESTABLECER LOS PROCEDIMIENTOS Y LOS CRITERIOS DE VALIDACIÓN
 Se revisan los requerimientos del producto y se resuelven los problemas que afectan la validación.
 Se documenta el entorno, escenario operacional, procedimientos, entradas, salidas y criterios para la validación
 Se evalúa el diseño a medida que madura el entorno de validación, para identificar problemas de validación.
 REALIZAR LA VALIDACION
 Asigna Grupo Tester
 Capacita Grupo Tester
 Realiza la Validación
 Documenta los resultados
 Revisa y registra los informes de Validación.
 ANALIZAR LOS RESULTADOS DE LA VALIDACION
 Se comparan los resultados reales con los resultados esperados.
 Identificar los productos/componentes que no funcionan adecuadamente en sus entornos operacionales previstos.
 Analizar los datos de la validación en cuanto a defectos.
 Registrar los resultados de análisis e identificar los problemas.
 Usar los resultados de la validación para comparar las mediciones y el rendimiento reales para el uso previsto

VER- Verificación
 El propósito de la Verificación (VER) es asegurar que los

productos de trabajo seleccionados cumplen sus
requerimientos especificados.
 VER involucra la verificación del producto o servicios y
artefactos intermedios con respecto a los
requerimientos seleccionados, incluyendo
requerimientos del cliente, del producto o servicio y
componentes del producto o servicio.
 VER es un proceso incremental porque se aplica al
desarrollo del producto y artefactos, comenzando con
la verificación de los requerimientos, pasando por la
verificación de artefactos y terminando con la
verificación del producto completo.
VER- Verificación
 El área de proceso de Verificación implica: preparación

de la verificación, realización de la verificación e
identificación de acciones correctivas.
 La verificación incluye la verificación del producto y de
los productos de trabajo intermedios frente a todos los
requerimientos seleccionados, incluyendo
requerimientos del cliente, del producto y del
componente de producto. En todas las áreas de
proceso, donde se usan los términos producto y
componente de producto, su significado previsto
engloba también a los servicios y a sus componentes.

VER- Verificación (Proceso)

 SG 1 Preparar la verificación.
 SP 1.1 Seleccionar los productos de trabajo a verificar.
 SP 1.2 Establecer el entorno de verificación.
 SP 1.3 Establecer los procedimientos y los criterios de verificación.
 SG 2 Realizar revisiones entre pares.
 SP 2.1 Preparar las revisiones entre pares.
 SP 2.2 Llevar a cabo las revisiones entre pares.
 SP 2.3 Analizar los datos de la revisión entre pares.
 SG 3 Verificar los productos de trabajo seleccionados.
 SP 3.1 Realizar la verificación.
 SP 3.2 Analizar los resultados de la verificación.

OT- Programa de adiestramiento
 El propósito de Formación organizativa (OT) es desarrollar las

habilidades y el conocimiento de las personas para que puedan
realizar sus roles eficaz y eficientemente.
 Formación organizativa incluye la formación para dar soporte a los
objetivos del negocio de la organización y para cumplir las necesidades
tácticas de formación comunes a los proyectos y grupos de soporte.
 Las necesidades específicas de formación identificadas por proyectos y
grupos de soporte individuales se tratan a nivel de proyecto y de grupo de
soporte, y están fuera del alcance de Formación organizativa. Los
proyectos y grupos de soporte son responsables de identificar y de tratar
sus necesidades específicas de formación.
 Un programa de formación organizativa implica:
 Identificar las necesidades de formación de la organización.
 Obtener y proporcionar formación para tratar esas necesidades.
 Establecer y mantener la capacidad de formación.
 Establecer y mantener los registros de formación.
 Evaluar la eficacia de la formación.

OT- Programa de adiestramiento

SG 1 Establecer una capacidad de formación
organizativa.
 SP 1.1 Establecer las necesidades de formación estratégicas.
 SP 1.2 Determinar qué necesidades de formación son
responsabilidad de la organización.
 SP 1.3 Establecer un plan táctico de formación organizativa.
 SP 1.4 Establecer la capacidad de formación.
SG 2 Proporcionar la formación necesaria.
 SP 2.1 Impartir la formación.
 SP 2.2 Establecer los registros de formación.
 SP 2.3 Evaluar la eficacia de la formación.

IPM- Gestión integrada de proyecto
 El propósito de la Gestión integrada de proyecto (IPM) es establecer y
gestionar el proyecto y la involucración de las partes interesadas
relevantes de acuerdo a un proceso integrado y definido que se adapta
a partir del conjunto de procesos estándar de la organización.
 Para IPPD, la Gestión integrada de proyecto + IPPD también cubre el
establecimiento de una visión compartida para el proyecto y el
establecimiento de equipos integrados que llevarán a cabo los objetivos
del proyecto.
 La Gestión integrada de proyecto implica:
 Establecer el proceso definido del proyecto al inicio del mismo, mediante la adaptación del conjunto de procesos
estándar de la organización.
 Gestionar el proyecto utilizando el proceso definido del proyecto.
 Establecer el entorno de trabajo para el proyecto, basándose en los estándares del entorno de trabajo de la
organización.
 Utilizar y contribuir a los activos de proceso de la organización.
 Permitir que las inquietudes de las partes interesadas relevantes sean identificadas, consideradas, y, cuando sea
apropiado, tratadas durante el desarrollo del producto.
 Asegurar que las partes interesadas relevantes realizan sus tareas de una forma coordinada y oportuna (1) para tratar
los requerimientos del producto y de los componentes del producto, los planes, los objetivos, los problemas y los
riesgos; (2) para satisfacer sus compromisos; y (3) para identificar, seguir y resolver los problemas de coordinación .

IPM- Gestión integrada de proyecto
 SG1 Utilizar el proceso definido del proyecto.
 SP 1.1 Establecer el proceso definido del proyecto.
 SP 1.2 Utilizar los activos de proceso de la organización para planificar las actividades del proyecto.
 SP 1.3 Establecer el entorno de trabajo del proyecto.
 SP 1.4 Integrar los planes.
 SP 1.5 Gestionar el proyecto utilizando los planes integrados.
 SP 1.6 Contribuir a los activos de proceso de la organización.
 SG 2 Coordinar y colaborar con las partes interesadas relevantes.

 SP 2.1 Gestionar la involucración de las partes interesadas.
 SP 2.2 Gestionar las dependencias.
 SP 2.3 Resolver los problemas de coordinación.
 SG 3 Aplicar los principios de IPPD.

 SP 3.1 Establecer la visión compartida del proyecto.
 SP 3.2 Establecer la estructura del equipo integrado.
 SP 3.3 Asignar los requerimientos a los equipos integrados.
 SP 3.4 Establecer los equipos integrados.
 SP 3.5 Asegurar la colaboración entre los equipos interconectados.

RSKM- Gestión de Riesgos
 El propósito de la Gestión de riesgos (RSKM) es identificar los problemas
potenciales antes de que ocurran para que las actividades de tratamiento de
riesgos puedan planificarse e invocarse según sea necesario a lo largo de la vida
del producto o del proyecto para mitigar los impactos adversos para alcanzar los
objetivos.
 La gestión de riesgos es un proceso continuo, orientado a evaluar el futuro, y una parte
importante de la gestión. La gestión de riesgos debería tratar los aspectos que podrían poner en
peligro el logro de los objetivos críticos. Una aproximación de gestión de riesgos continua se
aplica para anticipar y mitigar eficazmente los riesgos que puedan tener un impacto crítico
sobre el proyecto.
 La gestión de riesgos eficaz incluye la identificación temprana y agresiva de cada riesgo a
través de la colaboración y la involucración de las partes interesadas relevantes, tal y como se
describió en el plan para la involucración de las partes interesadas tratado en el área de
proceso de Planificación de proyecto. Es necesario un fuerte liderazgo entre las partes
interesadas relevantes para establecer un entorno para la libre y abierta divulgación y discusión
de los riesgos.
 La gestión de riesgos debe considerar fuentes tanto internas como externas para riesgos de
coste, de calendario y de rendimiento, así como de otros tipos. La detección temprana y
agresiva del riesgo es importante porque normalmente es más fácil, menos costoso y menos
perjudicial hacer los cambios y corregir los esfuerzos de trabajo durante las fases más
tempranas del proyecto, en lugar de en fases posteriores.
 La gestión de riesgos puede dividirse en tres partes: definir una estrategia de gestión de
riesgos, identificar y analizar los riesgos, y manejar los riesgos identificados, incluyendo la
MEJORA A de
implementación LOSlos
PROCESOS
planes DEmitigación
de INGENIERÍAde DEriesgo,
SOFTWARE cuandoSEGÚN
sea EL MODELO CMMi v 1.3
necesario.
RSKM- Gestión de Riesgos

 SG 1 Preparar la gestión de riesgos.
 SP 1.1 Determinar las fuentes y las categorías de los riesgos.
 SP 1.2 Definir los parámetros de los riesgos.
 SP 1.3 Establecer una estrategia de gestión de riesgos.
 SG 2 Identificar y analizar los riesgos.
 SP 2.1 Identificar riesgos.
 SP 2.2 Evaluar, categorizar y priorizar los riesgos.
 SG 3 Mitigar los riesgos.
 SP 3.1 Desarrollar los planes de mitigación de riesgo.
 SP 3.2 Implementar los planes de mitigación de riesgo.

QPM- Gerencia cuantitativa de proyectos
 El propósito de la Gestión cuantitativa de proyecto (QPM) es gestionar
cuantitativamente el proceso definido del proyecto para alcanzar los
objetivos establecidos de calidad y de rendimiento del proceso del
proyecto.
 El área de proceso de Gestión cuantitativa de proyecto implica:
 Establecer y mantener los objetivos de calidad y de rendimiento del proceso en el proyecto.
 Identificar los subprocesos adecuados que constituyen el proceso definido del proyecto en base a los
datos históricos de estabilidad y de capacidad encontrados en las líneas base o los modelos del
rendimiento del proceso.
 Seleccionar los subprocesos del proceso definido del proyecto a ser gestionados estadísticamente.
 Monitorizar el proyecto para determinar si los objetivos de calidad y de rendimiento del proceso en el
proyecto están siendo satisfechos, e identificar la acción correctiva apropiada.
 Seleccionar las medidas y las técnicas analíticas a usarse en la gestión estadística de los subprocesos
seleccionados.
 Establecer y mantener una comprensión de la variación de los subprocesos seleccionados usando las
medidas y las técnicas analíticas seleccionadas.
 Monitorizar el rendimiento de los subprocesos seleccionados para determinar si son capaces de
satisfacer sus objetivos de calidad y de rendimiento del proceso, e identificar la acción correctiva.
 Registrar los datos de gestión estadística y de calidad en el repositorio de medición de la
organización.

QPM- Gerencia cuantitativa de proyectos
 SG 1 Gestionar cuantitativamente el proyecto.
 SP 1.1 Establecer los objetivos del proyecto.
 SP 1.2 Componer el proceso definido.
 SP 1.3 Seleccionar los subprocesos que serán gestionados
estadísticamente.
 SP 1.4 Gestionar el rendimiento del proyecto.
 SG 2 Gestionar estadísticamente el rendimiento del
subproceso.
 SP 2.1 Seleccionar las medidas y las técnicas analíticas.
 SP 2.2 Aplicar los métodos estadísticos para comprender la variación.
 SP 2.3 Monitorizar el rendimiento de los subprocesos seleccionados.
 SP 2.4 Registrar los datos de gestión estadística.

OPP- Gestión del desempeño de los procesos de la
organización
 El propósito del Rendimiento de procesos de la organización (OPP) es establecer y mantener
una comprensión cuantitativa del rendimiento del conjunto de procesos estándar de la
organización en apoyo de los objetivos de calidad y de rendimiento de procesos, y
proporcionar datos, líneas base y modelos de rendimiento de los procesos para gestionar
cuantitativamente los proyectos de la organización.
 El rendimiento de los procesos es una medida de los resultados reales logrados mediante el
seguimiento de un proceso. El rendimiento de los procesos se caracteriza mediante medidas
del proceso (p. ej., esfuerzo, tiempo de ciclo y eficacia de la eliminación de defectos) y
medidas del producto (p. ej., fiabilidad, densidad de defectos, capacidad, tiempo de
respuesta y costes).
 Cuando la organización tiene medidas, datos y técnicas analíticas relacionadas a las
características críticas del proceso, del producto y del servicio, es capaz de hacer lo
siguiente:
 Determinar si los procesos se comportan consistentemente o tienen tendencias estables (es decir, son
predecibles).
 Identificar los procesos donde el rendimiento está dentro de los límites naturales que son consistentes en
todos los equipos que están implementando el proceso.
 Establecer los criterios para identificar si un proceso o subproceso debería gestionarse estadísticamente, y
determinar las medidas y las técnicas analíticas pertinentes que deben utilizarse en dicha gestión.
 Identificar los procesos que muestran un comportamiento inusual (p. ej., esporádico o impredecible).
 Identificar cualquier aspecto de los procesos que pueda mejorarse en el conjunto de procesos estándar de la
organización.
 Identificar la implementación
MEJORA de unDEproceso
A LOS PROCESOS que seDEejecuta
INGENIERÍA de laSEGÚN
SOFTWARE mejor manera
EL MODELO CMMi v 1.3
OPP- Gestión del desempeño de los procesos de la
organización
Resumen de Metas y prácticas específicas

SG 1. Establecer las líneas base y los modelos de
rendimiento.
 SP 1.1 Seleccionar los procesos.
 SP 1.2 Establecer las medidas de rendimientos del
proceso.
 SP 1.3 Establecer los objetivos de calidad y de
rendimiento de procesos.
 SP 1.4 Establecer las líneas base de rendimiento del
proceso.
 SP 1.5 Establecer los modelos de rendimiento de
procesos.
EL PROCESO DE VALORACION CMMi
La Acreditación de cumplimiento con las

prácticas del modelo se efectúa a través
de una guía llamada SCAMPI (Standard
CMMI Appraisal Method for Process
Improvement)
Las Valoraciones (Assessment / Appraisal)
 Para cada área de proceso tiene una guía de
auditoría que persigue evaluar el
cumplimiento de las exigencias del modelo

DEFINICIÓN DE ASSESSMENT
 El acto de juzgar o evaluar

(valorar) una persona,
situación o evento.
 Es un instrumento de alta
especificidad técnica para la
evaluación de potencial de
las personas.
 Permite obtener información

objetiva acerca de cómo se
actuaría en diferentes
circunstancias y tareas.
ASSESSMENT - CMM
En el contexto que
abarca el estándar de
Capability Maturity
Model (CMM), se
entiende por
assessment como una
medida coordinada y
objetiva de las
fortalezas y debilidades
encontradas en el
programa de mejora de
procesos de software.

VARIANTES DE SCAMPI
SCAMPI ofrece
una gran
flexibilidad de uso
a través de sus
tres variantes:
clases A, B y C.

CMMI DEV v1.3
 PRIMERA VERSIÓN 93 CMM 2002 CMMi 2006 1.2 2010 1.3
 CAMBIOS LIGEROS DE CMMi DEV 1.3
 PROYECCIÓN DE CAMBIOS AL MÉTODO DE EVALUACIÓN SCAMPI
 CAMBIOS DE ENFOQUE Y ESPECIALIZACIÓN EN CONSTELACIÓN
(DESARROLLO, ADQUISICIÓN, SERVICIOS)
 HOMOGENEIZAR Y MEJORAR CONTEXTO DE PRACTICAS Y
TERMINOLOGÍAS
 LOS PRINCIPALES CAMBIOS ESTÁN EN LOS NIVELES 4 y 5, LAS MAS
CUESTIONADAS POR EL SEI
 ALTA MADUREZ QUE INCORPOREN SIX SIGMA Y OTRAS PRACTICAS
PARA NIVELES 4 Y 5, CONTROL ESTADÍSTICO
 REDUCIR GENERALIDADES DE LAS PRACTICAS GENÉRICAS (MAS
LIBERTAD Y MAS AMBIGÜEDAD)
 MEJORAR EFICIENCIA EVALUACIONES SCAMPI, MAS VALOR Y
CONSISTENCIA
CMMi v1.3
 DAR COBERTURA A TEMAS DE SEGURIDAD

 REDUCIR EL TAMAÑO DEL LIBRO
 NO AFECTAR LOS PROYECTOS EN MARCHA
 INNOVACIÓN & DESPLIEGUE ORGANIZACIÓN PASA A
MEJORA DE DESEMPEÑO
 CORTA DE RAÍZ NIVELES DE CAPACIDAD EN 4 Y 5
 LOS TRES MODELOS COMPARTEN 16 ÁREAS Y ESTOS SE
CONSERVAN (NÚCLEO)
 ALGUNAS COINCIDENCIAS CON METODOLOGÍAS AGILES
(CM, PI, RD, RSK, TS, VER)
 VARIOS EQUIPOS: ARQUITECTURA, DESARROLLO,
VALIDACIÓN
UN CAMINO DE
ADOPCIÓN DEL
MODELO DE CMMi
1.3
HABRA ALGUN PROCESO DE LA ING. SOFTWARE QUE
MEJORAR?
INFORMATICA & SISTEMAS
 EL ENFOQUE DE LAS APLICACIONES ES ESTRATEGICO PARA LA EMPRESA
 ESTA LA TECNOLOGIA INFORMATICA AUTOMATIZANDO EL ESFUERZO Y EL CONOCIMIENTO DE LOS PROCESOS
DE LA EMPRESA.
 POSEEMOS INFORMACION UTIL PARA TOMAR DECISIONES ACERTADAS O SOLO DATOS CON LOS CUALES
EXPERIMENTAR
 TENEMOS USUARIOS DE T.I. O CLIENTES DE T.I (NIVEL DE SATISFACCION)
 QUE TAN MADURA ESTA NUESTRA ORGANIZACION EN TECNOLOGIA INFORMATICA
 COMO ESTAN LOS TIEMPOS DE RESPUESTA DE SOLUCIONES INFORMATICAS A LAS NECESIDADES CAMBIANTES
DEL NEGOCIO
 TENEMOS UNA TRAYECTORIA EXITOSA DE PROYECTOS DE SOFTWARE
 ESTAMOS CAPITALIZANDO EL POTENCIAL DE LA TERCERIZACION (SaaS, IaaS, PaaS, Cloud, Offshore)
 ESTAMOS APROVECHANDO LA POTENCIALIDAD DE LA ARQUITECTURA WEB 2.0 (INTERNET/INTRANET/J2EE,
REDES SOCIALES, COLABORACION, SOA, BPM, BI, LDAP/SSO)
 PROGRAMAMOS APLICACIONES O DISEÑAMOS E IMPLEMENTAMOS SOLUCIONES
 LA TECNOLOGIA INFORMATICA ES UNA VENTAJA COMPETITIVA PARA EL NEGOCIO O ES PARTE DE LA BASE
OPERATIVA
 CUAL HA SIDO EL RETORNO DE LA INVERSION EN TECNOLOGIA INFORMATICA Y CUAL SU TIEMPO DE VIDA
UTIL/RECUPERACION

GENERALIDADES DE LOS PROYECTOS
DE MEJORA INSTITUCIONAL
DIMENSIONANDO EL CAMBIO DE
ESCENARIOS Y EL CAMINO DE
TRANSICION
SITUACION
DESEABLE Y
VIABLE
SITUACION
ACTUAL

QUE DEBE CONTENER COMO MINIMO UNA ESTRATEGIA DE
ASEGURAMIENTO DE LA CALIDAD DEL SOFTWARE
 Una Determinación Corporativa
 Crear un área que lidere y coordine el proceso de aseguramiento de la calidad del
software
 Una Preparación del Personal que pertenece a los procesos de desarrollo de
software en el contexto del aseguramiento de la calidad del software para que
adquiera “el sentido de urgencia” del cambio.
 Una puesta en común de la necesidad de Enfocar los esfuerzos en asegurar la
calidad del software CON UN PROPÓSITO organizacional
 Enfocarse en procesos (Identificarlos y bosquejarlos)
 Contemplar la alternativa de “Valorar/Certificar los Procesos” por un ente avalado
internacionalmente.
 Tener un marco de referencia para cada proceso (Mejor Practica)
 Efectuar un diagnostico de las debilidades, fortalezas y el impacto que esta
teniendo en la organización cada uno de los actuales procesos según la óptica del
Modelo de Referencia seleccionado
 Priorizar los procesos que se van a mejorar y definir metas de logro

QUE DEBE CONTENER COMO MINIMO UNA ESTRATEGIA DE
ASEGURAMIENTO DE LA CALIDAD DEL SOFTWARE
 Identificar las herramientas de apoyo tecnológico que “disciplinen” los

procesos (Requerimientos, Control Cambios, Automatización de Pruebas,
Documentación, Gestion de Proyectos, Estimación de Esfuerzos)
 Ajustar las agendas del personal para que simultáneamente con su
actividad diaria avance en el mejoramiento de los procesos
 Establecer un plan integrado de mejora
 Iniciar la ejecución del plan y asignar los recursos que ello demanda
 Efectuar el seguimiento al plan hasta garantizar el logro de los planeado
 Evaluar objetivamente los logros y retroalimentar el plan
 Efectuar una auditoria externa que certifique los logros
 Formular la siguiente Iteración del proceso de mejora

PLAN DE IMPLEMENTACION
VALORACIÓN & REDISEÑO DE DESPLIEGUE &

PREPARATIVOS &
ANALISIS DE PROCESOS & GESTIÓN DEL
SENSIBILIZACIÓN
BRECHAS ROLES CAMBIO
IMPLEMENTACIÓN MONITOREO Y
NUEVOS EVALUACIÓN DE VALORACIÓN MEJORA
PROCESOS CUMPLIMIENTO CONTINUA
Procesos
Tecnologías
Competencias

COMENTARIOS E INQUIETUDES ?
OBJETIVO DE LA CONFERENCIA
Mostrar un modelo de gobernabilidad

para la Arquitectura Empresarial
(Enterprise Architecture Governance
Model) que garantice que la AE se afiance
en una organización y logre cumplir su
propósito de construir solidez, desarrollo
sostenible, competitividad, control y
productividad

 La ingeniería de software se ejerce por medio de procesos que se
desarrollan a través de todo el ciclo de vida del software, desde
que se concibe la iniciativa o proyecto hasta que el
producto/solución se estabiliza en el ambiente de producción.

 En Colombia y en el mundo aún se sigue desarrollando
el software de una manera casi artesanal que no le da
la importancia a los modelos de procesos que
desarrollan el ciclo de vida del software y por ello
vemos que el gran potencial de las tecnologías de
información no se ha podido canalizar en beneficios de
productividad y competitividad que tanto demandan las
organizaciones del mundo de los negocios. Las prácticas
tradicionales de ingeniería de software manejan altos
niveles de desperdicio, representados en reprocesos
que además de generar sobrecostos deterioran las
condiciones de los proyectos de software generando
insatisfacción y pérdida de credibilidad en las partes
interesadas en los proyectos que habilita el software.
 Varias instituciones (SEI, ISO, IEEE y otras) han venido
aportando desde hace más de 20 años modelos que
orientan los procesos de la ingeniería de software y
cuando nos damos a la tarea de conocer esos modelos
encontramos que el problema del desperdicio en la
ingeniería de software no es por falta de definiciones,
estándares, conocimiento o fuentes de información
pues en estos modelos hay muchas recomendaciones
sobre cómo abordar con éxito el ciclo de vida de
software, el problema está en la indisciplina que reina
en las prácticas de desarrollo de soluciones de
ingeniería de software.

Es responsabilidad de nuestra asociación
enfatizar en la importancia de madurar
nuestras prácticas/procesos de ingeniería
de software para que como gremio nos
posicionemos mejor nacional e
internacionalmente en un mercado donde
los profesionales y firmas de servicios de
Ingeniería de software de otras naciones
ya lo han hecho exitosamente (India,
China, USA).
 El modelo CMMi propuesto por el Instituto de Ingeniería de
software (SEI) es uno de los más completos para dar un marco de
referencial sobre el deber ser de los procesos de software. Y en
Noviembre de 2010 publicó la versión 1.3 del modelo para
desarrollo de software en el cual de una manera muy consistente
presenta como manejar las principales fases del ciclo de vida de la
ingeniería, los proyectos de software, las actividades de soporte y
como preparar a la organización de software para desarrollar los
procesos de negocio.


ProcesosIngenieriaSoftwareCMMI PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

ProcesosIngenieriaSoftwareCMMI PDF

Cargado por

Copyright:

Formatos disponibles

CONTEXTO ACTUAL DE MEJORA A LOS PROCESOS DE

INGENIERÍA DE SOFTWARE SEGÚN EL MODELO CMMi v 1.3

Bogotá, Junio 2 de 2011

MEJORA A LOS PROCESOS DE INGENIERÍA DE SOFTWARE SEGÚN EL MODELO CMMi v 1.3

MEJORA A LOS PROCESOS DE INGENIERÍA DE SOFTWARE SEGÚN EL MODELO CMMi v 1.3

MEJORA A LOS PROCESOS DE INGENIERÍA DE SOFTWARE SEGÚN EL MODELO CMMi v 1.3

MEJORA A LOS PROCESOS DE INGENIERÍA DE SOFTWARE SEGÚN EL MODELO CMMi v 1.3

La Ing.Software es una tecnología multicapa

MEJORA A LOS PROCESOS DE INGENIERÍA DE SOFTWARE SEGÚN EL MODELO CMMi v 1.3

MEJORA A LOS PROCESOS DE INGENIERÍA DE SOFTWARE SEGÚN EL MODELO CMMi v 1.3

MEJORA A LOS PROCESOS DE INGENIERÍA DE SOFTWARE SEGÚN EL MODELO CMMi v 1.3

Características que debe tener el

MEJORA A LOS PROCESOS DE INGENIERÍA DE SOFTWARE SEGÚN EL MODELO CMMi v 1.3

MEJORA A LOS PROCESOS DE INGENIERÍA DE SOFTWARE SEGÚN EL MODELO CMMi v 1.3

 De complejidad baja, Capacity Security

MEJORA A LOS PROCESOS DE INGENIERÍA DE SOFTWARE SEGÚN EL MODELO CMMi v 1.3

SQA Definición de Revisiones Técnicas

MEJORA A LOS PROCESOS DE INGENIERÍA DE SOFTWARE SEGÚN EL MODELO CMMi v 1.3

MEJORA A LOS PROCESOS DE INGENIERÍA DE SOFTWARE SEGÚN EL MODELO CMMi v 1.3

 Ser el medio (herramienta) que permita contribuir a

MEJORA A LOS PROCESOS DE INGENIERÍA DE SOFTWARE SEGÚN EL MODELO CMMi v 1.3

MEJORAR LA PRODUCTIVIDAD DE LAS

MEJORA A LOS PROCESOS DE INGENIERÍA DE SOFTWARE SEGÚN EL MODELO CMMi v 1.3

Contrat. minutos pdos de trabajo

D atos de calibr. as s 1/d Banco de la Republica

Orden de trabojo, aprob.

ny M inas & Energía

Com pañía M ateriales

- Inform e Escrito Inspec. y Recom

MEJORA A LOS PROCESOS DE INGENIERÍA DE SOFTWARE SEGÚN EL MODELO CMMi v 1.3

MEJORA A LOS PROCESOS DE INGENIERÍA DE SOFTWARE SEGÚN EL MODELO CMMi v 1.3

MEJORA A LOS PROCESOS DE INGENIERÍA DE SOFTWARE SEGÚN EL MODELO CMMi v 1.3

La mayoría de los proyectos de desarrollo

MEJORA A LOS PROCESOS DE INGENIERÍA DE SOFTWARE SEGÚN EL MODELO CMMi v 1.3

 Retrasos en los proyectos.

Fuente: Standish Group International

MEJORA A LOS PROCESOS DE INGENIERÍA DE SOFTWARE SEGÚN EL MODELO CMMi v 1.3

Standish Group International Report, “Chaos” Open Computing

MEJORA A LOS PROCESOS DE INGENIERÍA DE SOFTWARE SEGÚN EL MODELO CMMi v 1.3

Standish Group International Report, “Chaos”, Open Computing

MEJORA A LOS PROCESOS DE INGENIERÍA DE SOFTWARE SEGÚN EL MODELO CMMi v 1.3

Standish Group International Report, “Chaos” Open Computing

MEJORA A LOS PROCESOS DE INGENIERÍA DE SOFTWARE SEGÚN EL MODELO CMMi v 1.3

Standish Group International Report, “Chaos” Open Computing

MEJORA A LOS PROCESOS DE INGENIERÍA DE SOFTWARE SEGÚN EL MODELO CMMi v 1.3

MEJORA A LOS PROCESOS DE INGENIERÍA DE SOFTWARE SEGÚN EL MODELO CMMi v 1.3

MEJORA A LOS PROCESOS DE INGENIERÍA DE SOFTWARE SEGÚN EL MODELO CMMi v 1.3

 CADA VEZ LAS ORGANIZACIONES DEMANDAN MAS APOYO

MEJORA A LOS PROCESOS DE INGENIERÍA DE SOFTWARE SEGÚN EL MODELO CMMi v 1.3

MEJORA A LOS PROCESOS DE INGENIERÍA DE SOFTWARE SEGÚN EL MODELO CMMi v 1.3

QUÉ AJUSTES LE DEBEMOS

MEJORA A LOS PROCESOS DE INGENIERÍA DE SOFTWARE SEGÚN EL MODELO CMMi v 1.3

MEJORA A LOS PROCESOS DE INGENIERÍA DE SOFTWARE SEGÚN EL MODELO CMMi v 1.3

 Es un conjunto de propiedades asociadas a un objeto

MEJORA A LOS PROCESOS DE INGENIERÍA DE SOFTWARE SEGÚN EL MODELO CMMi v 1.3

MEJORA A LOS PROCESOS DE INGENIERÍA DE SOFTWARE SEGÚN EL MODELO CMMi v 1.3

MEJORA A LOS PROCESOS DE INGENIERÍA DE SOFTWARE SEGÚN EL MODELO CMMi v 1.3

MEJORA A LOS PROCESOS DE INGENIERÍA DE SOFTWARE SEGÚN EL MODELO CMMi v 1.3

MEJORA A LOS PROCESOS DE INGENIERÍA DE SOFTWARE SEGÚN EL MODELO CMMi v 1.3

MEJORA A LOS PROCESOS DE INGENIERÍA DE SOFTWARE SEGÚN EL MODELO CMMi v 1.3

MEJORA A LOS PROCESOS DE INGENIERÍA DE SOFTWARE SEGÚN EL MODELO CMMi v 1.3

MEJORA A LOS PROCESOS DE INGENIERÍA DE SOFTWARE SEGÚN EL MODELO CMMi v 1.3

MEJORA A LOS PROCESOS DE INGENIERÍA DE SOFTWARE SEGÚN EL MODELO CMMi v 1.3