DeGobiernoTIPractica PDF

De Gobierno TI a la Prctica
Ing. Pedro Rozo

CEO - SmartJSP Solutions para Canad & Colombia
http://www.smartjsp.com
Consultor en Integracin, Arquitectura SOA, BPM , Middleware IBM y Open Source
Ing. Sistemas Universidad Distrital
Sun Certified Enterprise Architect for Java Enterprise Edition
MBA Direccin de Empresas Universidad San Pablo - Espaa
Conferencistas
Ing. Pedro Rozo
CEO - SmartJSP Solutions para Canad &

Colombia
http://www.smartjsp.com
Consultor en Integracin, Arquitectura SOA, BPM
, Middleware IBM y Open Source
Ing. Sistemas Universidad Distrital
Sun Certified Enterprise Architect for Java
Enterprise Edition
MBA Direccin de Empresas Universidad San
Pablo Espaa
Agenda
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
Introduccin Gobierno en TI
IT Como un Edificio de Entornos Abiertos
COBIT / ISO 38500 Frameworks para Gobierno de TI
ITIL Gestin del Servicio
PMI Gestin de Proyectos
Arquitectura Empresarial Caso TOGAF
Modelos de Construccin de software: Caso CMMI
Metodologas alternas para Construccin de Software
Arquitecturas de Software de Referencia: Caso SOA
Arquitecturas Tcnicas abiertas: Caso Java Enterprise
Elementos adicionales para Gestin de Infraestructura
Como integrar los componentes ?
Preguntas & Respuestas
Asistentes
Empresas con ms de 100 empleados
Empresas con ms de 1000 empleados
Gobierno de TI y frameworks para control y gestin de

proyectos en TI.
Mejores prcticas para Soluciones robustas en TI
Desarrollo in-house vs. Tercerizacin
Arquitecturas abiertas y escalabilidad de sus reas de TI
Soluciones :
Escalables, facil mantenimiento, extensibles, trazabilidad
de prioridades de Negocio elementos de TI
Enfoque
Una visin ejecutiva de los estndares y mejoras
prcticas en la gestin de TI
Un recorrido integral y gil mostrando fortalezas y
debilidades, que permitan desarrollar criterios,
prioridades y aplicabilidad de estos modelos en el
entorno de TI real.
Un espacio interactivo para discernir que tan real
es su aplicabilidad segn variables como tamao,
presupuesto, equip humano, estrategia, etc.
Antecedentes
20% de las inversiones en TI se pierden, lo que se
traduce en US$ 600 billones anuales a nivel global

(Publicacin Gartner Group, 2002)
Los CIOs reportan que el 40% de las inversiones en
TI no generan retorno para la organizacin

(2004 IBM Survey, Fortune 1000 CIOs)
29% de los proyectos resultan exitosos y el restante
porcentaje son cuestionables o representan fracasos.

(2004 Standish Report)
Introduccin
La necesidad del aseguramiento del valor de TI, la administracin de los riesgos

asociados a TI, as como el incremento de requerimientos para controlar la informacin,
se entienden ahora como elementos clave del Gobierno Corporativo.
El valor, el riesgo y el control constituyen la esencia del gobierno de TI.
Cada organizacin necesita personalizar y adaptar el uso de estndares y mejores

practicas que se adapten a sus requerimientos especficos.
Las empresas estn sacrificando productividad y competitividad cuando no se tienen

estrategias de gobierno para IT.
Los ejecutivos de IT necesitan una forma:

Consistente, ordenada y formal de dirigir su equipo y recursos de IT
De medir el valor que IT provee al negocio
De manejar los riesgos inherentes a las actividades de IT.
Gobierno en TI
El gobierno de TI es responsabilidad de los ejecutivos, del consejo de directores y

consta de liderazgo, estructuras y procesos organizacionales que garantizan que TI en
la empresa sostiene y extiende las estrategias y objetivos organizacionales.
Ms an, el gobierno de TI integra e institucionaliza las buenas prcticas para

garantizar que TI en la empresa soporta los objetivos del negocio. De esta
manera, el gobierno de TI facilita que la empresa aproveche al mximo su
informacin, maximizando as los beneficios, capitalizando las oportunidades y
ganando ventajas competitivas. Brinda un marco de Referencia Integrado para la
administracin de riesgos, as como a marcos compatibles similares.
Las organizaciones deben satisfacer la calidad, los requerimientos fiduciarios y de

seguridad de su informacin, as como de todos sus activos. La direccin tambin
debe optimizar el uso de los recursos disponibles de TI, incluyendo
aplicaciones, informacin, infraestructura y personas. Para descargar estas
responsabilidades, as como para lograr sus objetivos, la direccin debe entender el
estatus de su arquitectura empresarial para TI y decidir qu tipo de gobierno y de
control debe aplicar
Alineacin de Frameworks con Prioridades de IT

Cobit
Gobierno
Estratgico
ISO 38500
Gobierno
TOGAF
PMI
Proyectos
Operativo
CMMI
Software
SOA
Integracin
Conectividad
ISO 27001
Seguridad
Arquitectura
Empresarial
ITIL
Gestin del
Servicio
Tcnico
Infraestructura
Redes : Cisco,
RDBMS Oracle,
etc.
Java
Enterprise
Arquitectura
Tcnica
IT Como un gran Edificio

COBIT 4.1 (IT Governance Institute - ITGI)- frameworks de alto

nivel para Gobierno en TI (que debe ser hecho)

ISO/IEC 38500:2008 Gobierno de TI (que debe ser hecho)
ITIL V3 (Gobierno de Inglaterra) (como debe ser hecho) para la
gestin de servicios.
ISO/IEC 27001:2007 framework para la gestin de seguridad
informtica
PMI -Project management Institute y PRINCE2
Gerencia de Proyectos
CMMI (9001:2000 Quality Management SystemsRequirements, Capability

Maturity Model Integration (CMMI)) (RUP, Agile, XP) Gestin de Software
Arquitectura Empresarial Frameworks (TOGAF)
Arquitecturas Abiertas Tcnicas de Referencia Casos SOA -
Java Enterprise
Infraestructura Abierta
Sistemas Operativos, Bases de Datos, Elementos de Red
Plataformas abiertas para creacin de soluciones de software.
COBIT
Control Objectives for Information and
related Technologies
El Gobierno de TI se define como

El Gobierno de TI es:
Responsabilidad del Board de Directores
y de los directivos
www.itgi.org
www.itgi.org
www.itgi.org
www.itgi.org
RESOURCE
Administracion
MANAGEMENT
De Recursos
Parte integral del Gobierno Corporativo,

que consiste en el liderazgo, estructuras
organizacionales y procesos que
aseguran que el TI de la empresa
soportar y complementar las
estrategias y objetivos de la empresa
La necesidad del Gobierno de TI

Alinearse con el
negocio y
proveer
soluciones
colaborativas
www.itgi.org
www.itgi.org
Ejecutar la
propuesta de
valor a travs
del ciclo de
entrega
Proteger los activos,
recuperarse de los
desastres y cumplir
las leyes,
regulaciones y
contratos
RESOURCE
Administracion
MANAGEMENT
De Recursos
Monitorear los resultados

para aplicar acciones
correctivas
Optimizar el desarrollo
y uso de los recursos
disponibles
Aspectos Prcticos
La implementacin de estas mejores practicas sin un foco en el
negocio, puede resultar costosa e inoperante, por lo cual se

requiere marcar un estrategia clara que defina una carta de
navegacin clara para las reas implicadas.
Las mejores practicas en TI se enfocan en:

Mejor gestin de TI
Mejor gobierno de actividades TI
Efectiva gestin de frameworks de polticas, controles internos y
practicas, para que todos mundo sepa que hacer y como

Beneficios organizacionales como: ganancias en eficiencia,
control interno, menos errores, menor dependencia de expertos,
incremento de confianza con socios de negocio y respeto y
cumplimiento de regulaciones.
Cmo lograr el xito ?

La implementacin real de estas prcticas no suena gran
novedad, de hecho formalizan practicas que ya son parte del da a

da de las organizaciones, pero organizadas de una forma lgica y
alienadas coordinadas con el objetivo del negocio, permiten
mejorar los aspectos ya mencionados anteriormente en la
organizacin de IT.
La utilizacin extensiva y coordinada de estndares abiertos,
mejores prcticas y soluciones probadas;

beneficios ya descritos anteriormente,
navegacin donde se definen criterios de
fcil reutilizacin, reemplazo y gestin
aplicaciones.
brinda adems de los

una clara carta de
flexibilidad tecnolgica,
de roles, recursos y/o
TM
Control Objectives for Information and

related Technologies
TM CoBiT
es propiedad del ITGI (IT Governance Institute)
CobiT sus antecedentes

TM
La comunidad de profesionales relacionados con TI
a travs de ISACA mostr preocupacin por la falta

de una gua estndar sobre control en TI, que
sirviera para diferentes grupos de inters
La ISACF, como rgano que agrupa a profesionales
de distintas reas de actuacin interesadas en el
control de TI se dio a la tarea de desarrollar un
cuerpo comn de conocimientos sobre la materia
ISACF Hoy ITGI
17
COBIT: Un Marco de referencia de Controles para TI
Evolucin del CobiT en el tiempo

Gobierno
COBIT 5
Gestin de
la
Informacin
Evolucin
Administracin /Gerencia
Control
Auditora
COBIT 1
1996
COBIT 2
COBIT 3
1998
2000
COBIT 4
2005
CobiT su misin
TM
Investigar, desarrollar, publicar y promover un

marco de trabajo de control de gobierno de TI
autorizado y actualizado, internacionalmente
aceptado y adoptado para el uso cotidiano de
las empresas, gerentes de negocios,
profesionales de TI y de Aseguramiento.
19
CobiT sus caractersticas

TM
Orientacin al negocio
Alineacin con estndares y regulaciones de
jure y de facto
Basado en una revisin critica de tareas y
actividades en tecnologa de informacin.
Alineamiento con estndares de control y
auditora: COSO, IFAC, IIA, ISACA, AICPA
20
COBIT:
Diagrama de Contenido
Practices
Practicas
Responsibilities
Responsabilidades
Resea Ejecutiva
Ejecutivos & Juntas

Performancedemeasures
desempeo
w Mediciones
Critical success factors
w Benchmarking
Directrices Gerenciales
Maturity models
de Madurez
w Modelos
Gestin
deTechnology
Negocios y Management
Tecnologa
Business
and
Control
QuObjectives
es el Marco
de Gobierno de TI?
Control Framework ?
Audit
Guidelines
Cmo Implementamos
Im
el
Cmo
evaluamos
Guide
El Gobierno de TI?
Gobierno de TI?
Control Framework ?
Profesionales
en and
Gobierno,
auditora,
control y seguridad
Audit, control
security
profesional
Marco COBIT y ValIT
Gua de
Implementacion de IT
Governance
Objetivos de Control
Practicas de
21
Prcticas clave de
Administracion
Control CobiT
Gua de Aseguramiento
De TI
CobiT sus Productos

TM
22
CobiT Online Para todos los usuarios
CobiT Quick Start Pequeas y medianas empresas
CobiT Security Baseline Responsables de la seguridad Informtica

y auditores
Objetivos de Control para Sarbanes-Oxley Responsables del

control Interno, auditores
Objetivos de Control para Basilea II Responsables del control

Interno, auditores, areas de control de entidades financieras
Enterprise Value. Governance of IT Investments Responsables de

TI, control Interno, auditores
Mapeos o cruces con estndares y mejores prcticas
COBIT otros productos
23
CobiT Online Para todos los usuarios
CobiT Quick Start Pequeas y medianas empresas
CobiT Security Baseline Responsables de la seguridad

Informtica y auditores
Objetivos de Control para Sarbanes-Oxley Responsables del

control Interno, auditores
Objetivos de Control para Basilea II Responsables del control

Interno, auditores, areas de control de entidades financieras
Enterprise Value. Governance of IT Investments Responsables

de TI, control Interno, auditores
OBJETIVOS DEL
Interelacion de
Componentes
de CobiT
NEGOCIO
Requerimientos
Informacin
OBJETIVOS TI
PROCESOS TI
OBJETIVOS DE
CLAVES
CONTROL
Para
resultados
ACTIVIDADES
RESPONSABILIDAD
Y RENDICION
DE CUENTAS
PRUEBAS DE
CONTROLES
RESULTANTES
Basado
en
INDICADORES
MEDIDAS
MODELOS
DE DESEMPEO
RESULTANTES
DE MADUREZ
PRUEBAS DE
DISEO DE
CONTROLES
PRACTICAS
DE CONTROL
PROCESOS
DE NEGOCIO
OBJETIVOS DEL
GOBIERNO
Efectividad
INFORMACION
Eficiencia
Confidencialidad
Integridad
Requerimiento
CobiT
del negocio
Disponibilidad
Cumplimiento
confiabilidad
RECURSOS
PARA TI
MONITOREAR Y
EVALUAR
Informacin
sistemas de aplicacin
PLANEAR Y
Infraestructura
ORGANIZAR
personas
ENTREGAR Y
SOPORTAR
ADQUIRIR E
IMPLEMENTAR
COBIT Un framework de Alto Nivel
COBIT Armonizacin de Estndares

Armoniza practicas y
estndares como ITIL, ISO
27001 e ISO 27002 y PMI
(PMBOOK):
Mejora su alineacin con los

objetivos del negocio
Cubriendo el espectro total de
actividades relacionadas con
IT.
27001/2
COBIT y las mejores

Prcticas
COSO
COBIT
ISO 2700X
ISO 9000
ITIL
Qu
Cobertura
Cmo
El Cubo de CobiT
29
ISO/IEC 38500:2008
Corporate Governance for IT
Marco Coherente del Gobierno de TI

ISO/IEC 38500
www.itgi.org
www.itgi.org
Administracion
De Recursos
Control Objectives for Information and related

Technologies
ISO/IEC 38500:2008
Directrices para la orientacin de la Alta Direccin
con el Buen Gobierno Corporativo de TI
Fija estndares de buena gestin de los procesos
empresariales relacionados con los servicios de

TI
Propsitos
ISO/IEC 38500:2008
Asegurar que si la norma se
sigue, las partes involucradas
pueden confiar en el Gobierno
Corporativo de TI
Informar y orientar a los
directivos que controlan el uso
de las TI en la organizacin
Proporcionar una base para la
evaluacin objetiva de la
gestin de TI realizada por la
alta direccin
ISO/IEC 38500:2008
Estndares Principales
Establecimiento de
Responsabilidades
Planeacin
estratgica
Adquisicin adecuada
de soluciones
Adecuado
desempeo
Garanta de
cumplimiento legal
Comportamiento del
factor humano
Establecimiento de Responsabilidades
The Board Briefing on IT Governance and
Unlocking Value: An Executive Primer on the

Critical Role of IT Governance
CoBiT (Monitor and Evaluate)
Val IT frameworks
IT Governance Implementation Guide Using
CoBiT and Val IT
Planeacin Estratgica
The Board Briefing on IT Governance and

Unlocking Value: An Executive Primer on the

Critical Role of IT Governance
Val IT (Investment Management)
CoBiT (Plan and Organize)
Identifying and Aligning Business Goals and IT
Goals
Understanding How Business Goals drive IT
Goals
Adquisicin Adecuada de Soluciones

Val IT
(Investment Management)
Portfolio Management
CoBiT
Plan and Organize
Acquire and Implement
Monitor and Evaluate
Adecuado Desempeo
CoBiT
Plan and Organize
Deliver and Support
Val IT
Business case to benefit realisation
The IT Assurance Guide Using CoBiT
Garanta del Cumplimiento

CoBiT
Plan and Organize
Val IT
Value Governance
Portfolio Management
Investment Management
The IT Assurance Guide Using CoBiT
Comportamiento del Factor Humano

CoBiT
Plan and Organize
Acquire and Implement
Certificaciones
Certified in the Governance of Enterprise IT CGEIT
Certified information Systems Auditor CISA
Certified Information Security Manager CISM
Certified in Risk and Information Systems Control - CRISC
CoBiT Foundations Certificate
ITIL
Information Technology Infrastructure Library
ITIL
ITIL nace como un cdigo de buenas prcticas
dirigidas a alcanzar esas metas mediante:

Un enfoque sistemtico del servicio TI centrado
en los procesos y procedimientos.
El establecimiento de estrategias para la gestin
operativa de la infraestructura TI.
La filosofa ITIL impulsa la adopcin de
procesos, de manera que puedan adaptarse para
encajar tanto en organizaciones grandes como
en pequeas
ITIL
ITIL - Propsitos
ITIL fue desarrollada al reconocer que las organizaciones
dependen cada vez ms de la Informtica para alcanzar sus

objetivos corporativos.
Esta dependencia en aumento ha dado como resultado una
necesidad creciente de servicios informticos de calidad que se
correspondan con los objetivos del negocio, y que satisfagan los
requisitos y las expectativas del cliente.
El nfasis de ITIL pas de estar sobre el desarrollo de las
aplicaciones TI a la gestin de servicios TI.
La aplicacin TI (a veces nombrada como un sistema de
informacin) slo contribuye a realizar los objetivos corporativos
si el sistema est a disposicin de los usuarios y, en caso de
fallos o modificaciones necesarias, es soportado por los
procesos de mantenimiento y operaciones
ITIL
Deliver IT Services
Support IT Services
Managing
Applications
The Business
Perspective
Manage the
infrastructure
ITIL
ITIL
ISO20000/BS15000
CMM
SIX SIGMA
COBIT
ITIL
Governance
Business
Process
Models
ITIL
ITIL
ITIL Principales Elementos

ITIL plantea el anlisis de la administracin de
servicios de TI, con el objetivo de identificar las

necesidades de los clientes y los distintos
usuarios relacionados con los servicios de
Tecnologas de Informacin y telecomunicaciones.
Se han definido cinco elementos que
interactan entre si y se complementan:
Prestacin de servicios de las TI.

Soporte de los servicios de las TI.
Perspectiva de negocios.
Administracin de la infraestructura.
Administracin de Aplicaciones.
ITIL Propsito y Beneficios

El propsito de ITIL es asistir a las organizaciones en el
desarrollo de un framework o marco de referencia para la

Gestin de Servicios de TI, el cual puede ser aplicado para
todo tipo de organizaciones grandes o pequeas, basada en
los pilares de calidad, procesos y orientacin al cliente.
La Gestin de Servicios de TI busca alinear los servicios de
TI con las necesidades actuales y futuras de las empresas,
con el objetivo de:
Reducir costos.
Mejorar los servicios de TI a travs del uso de procesos basados
en mejores prcticas.
Mejorar la satisfaccin del los clientes a travs de un modelo ms
profesional de entrega de servicios.
Mejorar el uso de la experiencia.
Mejorar la entrega de servicios de terceras partes a travs de las
recomendaciones de ITIL o especificaciones del standard BS
15000.
ITIL por que implementar
ITIL - Motivadores
ITIL Implementacin Tpica

Paso 1: Definir el alcance del modelo de referencia, Implica:
* Estructura de operacin del rea el nivel de detalle requerido para los

registros y para los componentes de configuracin asociados con los
servicios.
* Definir el esfuerzo y costo de implementacin.
Paso 2: Definicin de la estructura de Servicios de TI y la CMDB,
Implica:
* Definir el portafolio de servicios y SLAs:

Es necesaria la definicin de la estructura de servicios, dominios de
infraestructura asociados y los acuerdos de nivel de servicio de acuerdo
con la capacidad existente en los recursos (Humanos, experticia e
infraestructura asociada). Este anlisis presenta el impacto que puede
ser alcanzado con los recursos disponibles por la empresa.

Diseo inicial de la CMDB : (Configuration Management
DataBase) es la Base de Datos de Gestin de la Configuracin, un

elemento clave para la correcta implantacin de la estrategia de
Business Service Management (BSM) porque sirve de enlace entre
todos los componentes. La CMDB, tiene que tener una capacidad
de evolucin y ser una columna verteblal para la implantacin de
los siguientes servicios
ITIL Contenido de la CMDB

Inventario completo sobre todos los elementos hardware, software y su
ubicacin, elementos con los que estn conectados.

Todos los manuales de instalacin, configuracin, deploy y
mantenimiento, en Mapeo de cada servicio con los dispositivos del
inventario que lo soportan
Usuarios de cada uno de los servicios con: E-Mail,
* Telfono de
contacto * Nombre * Despacho
Informacin de las incidencias
* Criticidad * Fecha de alta *
Fecha de cierre * Estado (abierta/no abierta) * Tipo
Lista de servicios actualmente cados o con problemas
Toda la informacin necesaria de KEOPS (hora de generacin de la

incidencia, comentarios incluidos por parte de las personas que se han
hecho cargo, el flujo que ha seguido la incidencia, historial de
seguimiento,)
Parmetros de actuacin (en 2 idiomas) para niveles 1 y 2.
Historial de problemas, Historial de incidencias Historial de cambio

Paso 3: Determinar los procesos operativos bsicos:
Es clave la definicin inicial del servicedesk y de los procesos que lo

soportan, as tambin se implantara de las gestiones de incidencias,
problemas, cambios, configuraciones, versiones y niveles de servicio.
Servicio de Service Desk:
Dentro del conjunto de procesos a implantar

ITIL, la instalacin de un Service Desk capaz de resolver con rapidez y
eficacia los posibles problemas que aparezcan, se presenta como uno
de los hitos de mayor relevancia para disponer de un buen servicio.
Gestin de incidencias: La implantacin tiene que constar de tres

partes bien diferenciadas: el rea de recepcin o captacin de
incidencias, el rea de apertura de incidencias y el rea de resolucin
de incidencias. Adems de ello se tendr que definir los niveles que
abarcara dicha gestin.
ITIL Gestin de Incidencias
ITIL Gestin de Problemas

Gestin de problemas: Las incidencias son el resultado de errores o
problemas con el sistema de soporte de las TIC. Un problema puede

provocar mltiples incidencias, y es posible que el problema no se
Diagnostique hasta que se produzcan una serie de incidencias
relacionadas entre ellas.
ITIL Gestin de Cambios

Gestin de cambios: Valorarla necesidad del cambio. - Garantizar la validez de los

cambios. - Minimizar el riesgo del cambio. - Autorizar y disponer recursos para
realizar los cambios. - Garantizar que los cambios son implementados de forma
eficiente. - Controlar los cambios y evaluar el impacto. Monitorizar y reportar la
implementacin. - Revisar y cerrar RFC (peticiones de cambio
ITIL Gestin de Configuraciones

Gestin de Configuraciones: Este proceso en una
empresa tiene que facilitar la integracin de actividades

de configuracin a travs de plataformas y tecnologas.
ITIL Gestin de Versiones

Gestin de Versiones: Este proceso garantiza el correcto despliegue de
versiones, incluyendo la integracin, el anlisis y el almacenamiento de

las mismas. En el momento de la implantacin cumplir con lo siguiente:
ITIL Gestin de Niveles de Servicio (SLA) (OLA)

Gestin de los Niveles de Servicio (SLM): El objetivo al implantar esta gestin es

mantener y mejorar la calidad de los servicios, a travs de los acuerdos establecidos con
el cliente, monitorizando y realizando los informes necesarios de las acciones que
pueden provocar una prdida del servicio.
En la gestin de los niveles de servicio se generan los distintos acuerdos a nivel de

servicio o SLAs (Service LevelAgreement) y acuerdos internos de servicio o OLAs
(OperationalLevelAgreement) ya antes definidos en la implantacin.

Paso 4: Implantar los procesos tcticos
requeridos por la organizacin:

Permiten desde el inicio poner en prctica el nivel
de servicio y garantizar el cumplimiento de los

acuerdos con clientes, establecidos en el paso 3
como SLM; adems se implantaran las gestiones
de disponibilidad, capacidad y continuidad.
ITIL Gestin de la Disponibilidad

El objetivo primordial de la Gestin de la Disponibilidad es asegurar que
los servicios TI estn disponibles y funcionen correctamente siempre

que los clientes y usuarios deseen hacer uso de ellos en el marco de
los SLAs en vigor, la implantacin debe garantizarlo
ITIL Gestin de la Capacidad

El objetivo primordial de la Gestin de la Capacidad es poner a disposicin
de clientes, usuarios y el propio departamento TI los recursos informticos

necesarios para desempear de una manera eficiente sus tareas y todo ello
sin incurrir en costos desproporcionados
ITIL Gestin de la Continuidad

Gestin de la Continuidad de Servicios IT:
Establecer polticas y
procedimientos que eviten, en la medida de lo posible, las perniciosas
consecuencias de un desastre o causa de fuerza mayor
ITIL Implementacin Tpica Paso 5

Paso 5: Construir los procesos alineados con la estrategia del negocio y con
la seguridad de la informacin.
En esta etapa se implantara la gestin financiera y de seguridad.
Gestin Financiera de los Servicios IT
ITIL Gestin de la Seguridad

Gestin de la Seguridad
Disear una poltica de seguridad, en colaboracin con clientes y proveedores
correctamente alineada con las necesidades del negocio.

Asegurar el cumplimiento de los estndares de seguridad acordados.
Minimizar los riesgos de seguridad que amenacen la continuidad del servicio
ITIL Implementacin Tpica Pasos 6-9

Paso 6: Definir mtricas de calidad de servicio y desempeo de los procesos.
Estos indicadores proveen el mecanismo de seguimiento, mejora continua y
planificacin, primordiales tanto hacia dentro del departamento como de cara a los
usuarios
Paso 7: Garantizar la calidad de la informacin en la CMDB:
Mediante la definicin de registros de informacin puntales y que permitan generar
reportes de desempeo, as como formar la base para los procesos de auditora a
la informacin y controles de validacin de datos en el cargue de los mismos
Paso 8: Garantizar y monitorear la gestin de cambios.
Este elemento es la base fundamental para disponer de procesos que generen
auto-aprendizaje y mejoracontinua. Un aspecto clave para iradaptando los nuevos
procedimientos ycapacidades a la cambiante y dinmicarealidad de una empresa
moderna.
Paso 9: Entrenar al personal y hacer participes del proceso al resto de la
organizacin.
El xito de la iniciativa depender en gran manera de la forma en que los nuevos
procedimientos se transformen una costumbre de trabajo, y que la alineacin y
participacin del resto de la empresa en la definicin y toma de decisiones se hayan
hecho presentes
ITIL Implementacin Tpica Paso 10

Paso 10: Seleccionar una herramienta adecuada que permita gestionar

adecuadamente la informacin asociada con los procesos definidos Tiempo de
planificacin para implantar ITIL
ITIL para PYMES ?

Normalmente, las pymes disponen de menos tiempo y menos
recursos para analizar los procesos empresariales e

implementar mejoras de servicio considerando que ITIL es un
marco flexible, y no una doctrina, y que su implementacin
resulta complicada incluso para las grandes organizaciones,
cmo podran las pymes obtener las mayores ventajas de ITIL?
Normalmente, los recursos de las pymes son utilizados ms
plenamente que los de las organizaciones mayores, por eso
podrn aprovechar ITIL para mejorar la productividad.
Por ejemplo, en una pyme las funciones de gerente del centro

de servicios y responsable de cambios suelen estar unificadas
en una misma persona. En las grandes organizaciones, estas
responsabilidades.
ITIL para PYMES
ITIL . Beneficios
ITIL Niveles de Entrenamiento

ITIL tiene tres niveles de certificacin:
a) Foundations o fundamentos:
Provee el nivel de fundamentos de la gestin
de servicios de TI y ayuda a familiarizarse con el
lenguaje y las mejores prcticas de TI.
b) Practitioner o practicante: Provee un nivel de
profundizacin en cada uno de los procesos
de ITIL en todas las actividades. Es un nivel
de especializacin ms profunda por proceso.
c) Service Manager o Gerente de Servicios: Est
destinado a aquellos que tengan la necesidad de
demostrar capacidad de manejo de proyectos de ITIL
.
PMI
Gestin de Proyectos
Qu es el PMI?
Es una organizacin sin nimo de lucro que
agrupa cerca de 260.000 miembros en ms de
170 pases con el fin de certificar a sus miembros
para la gestin y gerencia de proyectos.
Historia del PMI

Fundado en 1.969 por cinco voluntarios en
Atlanta.
Cinco voluntarios fundaron la organizacin.
Su primer simposio se realiz con 83 integrantes.
Su actual sede se ubica en Pennsylvania.
Qu hace el PMI?
Entre sus principales objetivos se encuentran
formular estndares profesionales, generar
conocimiento a travs de la investigacin, y
promover la Gestin de Proyectos como
profesin a travs de sus programas de
certificacin.
El PMI en el mundo
El 70% de los miembros del PMI viven en
Amrica
del
EstadosUnidos.
Norte,
61%
residen
en
Cerca de 40 mil miembrosresiden en Asia.

Los miembros en Europaalcanzan los 30 mil.
En
Latinoamrica
y
el
miembrosalcanzan los 10,700.
Caribe
los
Certificaciones PMI
CAPM: es aquel que ha demostrado una base
comn de conocimientos y trminos en el campo
de la gestin de proyectos. Se requieren 1,500
horas de trabajo en un equipo de proyecto o 23
horas de educacin formal en gestin de
proyectos para conseguir esta certificacin.
Certificaciones PMI
PMP: el profesional ha experimentado una
educacin especfica y requerimientos de
experiencia, ha aceptado ceirse a un cdigo de
conducta profesional y ha pasado un examen
designado para determinar y medir objetivamente
su conocimiento en gestin de proyectos.
Adicionalmente, un PMP debe satisfacer
requerimientos de certificacin continuos, de lo
contrario pierde la certificacin.
Actividades del PMI

Educacin y adquisicin del conocimiento.
Desarrollo profesional y redes.
Perfeccionamiento
de
carrera
profesionales.
Productos y servicios PMI.
estndares
PMI en Colombia
Su sede est ubicada en Santa Fe de Bogot, ante
el se puede gestionar las certificaciones
anteriormente mencionadas, la afiliacin cuesta
U$ 30 y la certificacin U$ 405, su misin es
promover los principios del PMI y apoyar a los
miembros en el proceso de certificacin.
Para ms informacin remtase a:
http://www.pmicolombia.org
PMBOK
El PMBOK es una publicacin desarrollada por el
PMI disponible en once idiomas, consta de 392
pginas y consiste en una coleccin de procesos
y reas de conocimientos, ms conocidas como
mejores prcticas, el libro es reconocido
mundialmente como un estndar (IEEE Std 14902003) que provee los lineamientos para la
gestin de proyectos.
Qu propone el PMBOK?
El PMBOK propone cinco pasos bsicos siendo
aplicables a proyectos, programas y procesos:
1.
2.
3.
4.
5.
Inicio.
Planificacin.
Ejecucin.
Control y monitoreo.
Cierre.
Qu propone el PMBOK?
As mismo se propone nueve reas de conocimiento
mencionadas en el PMBOK, estas son gestin en:
1. Integracin.
2. Alcance.
3. Tiempo.
4. Calidad.
5. Costos.
6. Riesgos.
7. Recursos Humanos.
8. Comunicacin
9. Logstica.
http://www.pmi.org
La gerencia de proyectos es la aplicacin de conocimientos, habilidades,
herramientas y tcnicas a las actividades de un proyecto con el fin de

cumplir con los requerimientos del proyecto.
Gerenciar el proyecto involucra:

Identificar los requerimientos.

Establecer objetivos claros y alcanzables.
Equilibrar las demandas concurrentes de Calidad, Alcance, Tiempo y Costo.
Adaptar los especificaciones, los planes y el enfoque a las distintas
expectativas y preocupaciones de los distintos involucrados (stakeholders).
Calidad
TRIPLE RESTRICCION
Contrato con multas por inclumplimiento.
REQUERIMIENTOS
PROYECTOPRODUCTO
- Seguridad
- Performance
- Impacto Ambiente - Funcionalidad
- Ubicacin
- Operatividad
- etc.
- etc.
Necesidad
Objetivos
Alcance
Relacionado con
el Negocio
Relacionado con
metas del Proyecto
Relacionado con
el Trabajo
Project Charter
Enunciado Preliminar
Linea Base el Alcance

- Enunciado del Alcance.
- WBS
- Diccionario
Limites del
Proyecto
Productos
Entregables del
Proyecto
Sponsor
Patrocinador
Usuarios
Finales
Entradas del
Proyecto
Registros
del
Proyecto.
Firma de
Acta
Constitucin
Activo
de los
Procesos
Entrega
de
Productos
(*) IPECC = Inicio, Planificacion,

Ejecucion, Control, Cierre
- Para el Ciclo de Vida del
Producto. Desde Concepcion,
construccion, uso, hasta dar de
baja.
- Para el Proyecto : IPECC dentro
de la ejecucion del Ciclo de Vida
Gestin de la Integracin del Proyecto

PROBLEMAS Y/O
OPORTUNIDADES
GESTIONAR
- Market Demand EL PROYECTO
- Business Need
- Customer Request
PARA
- Tech. Advance.
- Legal requirement. PRODUCIR
- Social need.
ENTREGABLES
Areas Centrales: Objetivos o Restricciones.

Gestn del
Alcance
Gestn del
Tiempo
Gestn del
Costo
Gestn de
la calidad
Integracin de la Gerencia de Proyectos a travs

del Ciclo de vida del Proyecto para lograr la
Satisfaccin de Stakeholders
Gestn de
RRHH
Gestn de
Comunicacin
Gestn del
Riesgo
Gestn del
Adquisiciones
Areas Facilitadoras :Interactivo y Adaptable
PROYECTO
EXITOSO
- PRODUCTOS
ENTREGABLES
RESULTADO DE
ELABORACION
- ACTIVOS DE
LOS PROCESOS
RESULTADO DE
LA GESTIN
Las percepcin de que un particular proceso no es requerido no significa que no sea

considerado. Se deben considerar todos los procesos y en cada proceso determinar el nivel de
implementacin para un proyecto especfico.

ACTA DE CONSTITUCION
- Autorizacin formal de
la organizacin para uso
de recursos.
- Reconocimiento y
compromiso de la
organizacin.
- Asigna al gerente.
- Autoriza fases.
ALCANCE PRELIMINAR
- Define los objetivos del
proyecto. Trabajo a
realizar y entregables.
- Define caractersticas y
lmites del proyecto y
sus productos.
- Define mtodos de
aceptacin y control del
alcance.
. . . Desea la Empresa . . .
. . Compromiso del Gerente . .
Declaracin del Trabajo (SOW)
Misin
Finalidad / Justificacin
Enunciado de Alcance, Costo, Tiempos

/ Lmites, Hitos
Descripcin del Producto
Entregables producto y proyecto
Restricciones / Asunciones
Restricciones / Asunciones
Riesgos
Sponsor / Jefe Proyecto
Involucrados / Influencias
Equipo del Proyecto. Organizacin.
Mtodo Aceptacin / Control Alcance
Requisitos de Configuracion
Foco: Integrar Planes

Acciones necesarias para definir, integrar y coordinar
todos los planes subsidiarios en el Plan de Gestin Del
Proyecto (Alcance, Costo, Tiempo, Quality, RRHH,
Comunicacion, Riesgo, Adquisiciones).
Define procesos del PMBOX y el nivel de su
implementacion, as como las herramientas a utilizar,
que permitan ejecutar, monitorear, controlar y cerrar
el proyecto.
Define como la gestin de la configuracin ser
desarrollada.
Define estrategias de comunicacin con los
stakeholders.
Foco: Lograr Entregables

Acciones necesarias para ejecutar
el plan de Gestin del proyecto
para cumplir con el trabaja
definido en el enunciando del
alcance del proyecto.
Algunas de las acciones son :
- Seleccionar proveedores:
- Adm. Recursos materiales y
equipos.
- Implementare los estndares y
mtodos propuestos.
- Crear, controlar y verificar
entregables.
- Adm. Acciones relacionadas con
el riesgo.
- Adaptar cambios aprobados.
- Establecer y manejar
comunicacin del proyecto.
- Recolectar y documentar
lecciones aprendidas.
- Implementar acciones aprobadas
preventivas, correctivas y de
reparacin de defectos.
(*) Algunas Definiciones :
- Acciones Correctiva.- Relacin con el proyecto para asegurar
calidad en producto, alcance, costo, tiempo.
-Solicitud de Cambios.- Modificaciones de documentos y acuerdos.
- Reparacin de Defectos.- Modificacin al producto.

Conjunto de actividades, que con
la ayuda del Sistema de Gestin de
la Configuracin y el Sistema de
Control de Cambios, permiten
centralizar la gestin de cambio
del proyecto. Sus principales
actividades son :
- Identifica necesidad de cambio y
realiza la revisin y aprobacin de
cambios solicitados.
- Revisa y aprueba
recomendaciones de acciones
preventivas y correctivas.
- Actualiza Planes de Alcance,
Costo, Tiempo, Calidad y otros
donde impacta el cambio.
- Documenta el impacto del
cambio.
Comparar el Plan con rendimiento
Acciones necesarias para evaluar indicadores y
su impacto en el plan y mejora de los procesos,
tomando las acciones correctivas y/o
preventivas necesarias.
- Compara Plan con Rendimiento (valor ganado).
- Elabora Proyecciones.
- Realiza Comunicaciones
- Monitorea y analiza Riegos.
Quality
Reparacin de Defectos
- Sistema de Control de
Cambios, es parte de la gestin
de configuracin que define
como entregables y documentos
son controlados, cambiados y
aprobados.
Gestin de la Configuracin:
- identifica caractersticas
funcionales y fsicas de los
productos.
- Controla cambios de dichas
caractersticas.
- Registra y reporta cada cambio
y su estado de implementacin.
- Audita productos y
componentes para verificar la
conformidad de los
requerimientos.
Incluye la finalizacin de todas las actividades

realizadas a travs de los otros procesos, y
transfiere el resultado completo o parcial del
proyecto.
Cierre Administrativo :
- Verificacin, Documentacin y entrega del
producto final del proyecto, previa aprobacin
formal del cliente.
- Investiga y Documenta acciones tomadas, y
elabora las lecciones aprendidas.
- Compila y archiva la documentacin del
proyecto.
Cierre de Contrato :
- Actividades para establecer y cerrar todo
acuerdo contractual establecido para el
proyecto.
- Incluye cierre Administrativo y entrega del
producto final
Arquitectura Empresarial
Arquitectura Empresarial
Definicin:
Una descripcin formal de un

sistema, o un plan detallado de un sistema a
nivel
de
componentes
para
guiar
su
implementacin.
La estructura de componentes, sus interrelaciones y los principios y guas que
gobiernan su diseo y evolucin en el tiempo
Prioridades que direcciona:
Control
Eficiencia Operacional
Costo
Framework de Arquitectura
empresarial
Un framework de arquitectura es un conjunto
de herramientas que puede ser utilizado para

desarrollar un amplio espectro de diversas
arquitecturas. Este framework debe:
Describir una metodologa para la definicin de

un sistema de informacin en trminos de un

conjunto de bloques constitutivos (building
blocks, en ingls) que encajen entre s
adecuadamente.
Contener un conjunto de herramientas
Proveer un vocabulario comn
Incluir una lista de estndares recomendados
Incluir una lista de productos que son idneos
para
la
implementacin
de
los
bloques
constitutivos
TOGAF
The Open Group Architecture
Framework
TOGAF The Open Group Architecture FrameworkFramework para Arquitectura Empresarial
Proporciona un enfoque para el diseo, planificacin,
implementacin y gobierno de una arquitectura

empresarial de informacin. Esta arquitectura es
modelada por lo general con cuatro niveles o
dimensiones: Negocios, Tecnologa (TI), Datos y
Aplicaciones. Cuenta con un conjunto de arquitecturas
base que buscan facilitarle al equipo de arquitectos
definir el estado actual y futuro de la arquitectura.
It is a complete package for creating an enterprise
architecture. It is based on a decade of refinements to

the U.S. Department of Defense Technical Architecture
For Information Management (TAFIM). TOGAF, now at
version 8, provides both a method and the structure
for developing an enterprise architecture.
TOGAF - Ventajas
Mejora en el manejo de red, facilidad del sistema e
interoperabilidad
Mejora en la habilidad para direccionar temas
crticos como seguridad
Facilidad
para
actualizar
e
intercambiar
componentes de sistemas.
Incrementar la portabilidad de las aplicaciones
Reducir la complejidad en la infraestructura de IT
Retorno mximo sobre la inversin existente
Flexibilidad para construir, comprar o externalizar
soluciones de IT
Reducir el riesgo total en las nuevas inversiones y
el costo de las
apropiaciones de IT. Bajos costos de desarrollo,
mantenimiento y Soporte de software
TOGAF - Partes
The Architecture Development Method (ADM):
The Enterprise Continuum: The Enterprise
Continuum is a repository of artifacts involved in the

design and implementation of your system, such as
models, patterns, and other architectural work.
TOGAF defines a Technical Reference Model (TRM)
that can form a foundation on which you can build
your repository, as well as a second reference model
and set of solutions and standards with which you can
work.
Additional Resources: TOGAF also provides a
wealth of information to help you build an architecture,
such as business scenarios, case studies, and
various models, views, and guidelines.
TOGAF - ADM
An iterative process that takes you through the eight phases of development,
starting with Architecture Vision and ending with Implementation Governance

and Architecture Change Management. The idea is to build your system in
stages, completing one cycle and embarking on the process again to improve
what you built on the last go-round
TOGAF Fases del ADM

Phase A: Architecture Vision
El objetivo de la primera fase es determinar exactamente el trabajo que se
abordar desde el punto de vista de arquitectura. Se trata de definir

fundamentalmente el alcance del proyecto y las distintas partes involucradas
(consiguiendo su aprobacin). Desde un punto de vista muy genrico, se
documenta el estado actual y el estado futuro.
Phase B: Business Architecture
Se trata de determinar con profundidad los diferentes aspectos de negocio
involucrados en el proyecto. Se abordan los mapas estratgicos, las polticas

corporativas, los objetivos de negocio, se realiza la descomposicin funcional,
los modelos organizativos y se documentan los procesos, tanto los estndares
como los que afectan al core-business de la compaa. No slo se trata de
modelar el estado actual, sino tambin el estado futuro, de ah que los mapas
estratgicos sean un aspecto fundamental, pues determinarn los requisitos
de futuro. Como fruto de este trabajo, se obtiene un Gap Analisys que permite
ver cun de lejos se encuentra el objetivo a conseguir con respecto a lo que
existe en la actualidad.
TOGAF Fases del ADM

Phase C: Information System Architecture
A lo largo de esta fase se analiza tanto la capa de aplicaciones como la de datos. Con
respecto a las aplicaciones, se traza el mapa de las existentes (tanto de las
aplicaciones pertenecientes a terceras partes, como las aplicaciones hechas a medida),
las interfaces existentes entre las ellas y los enlaces (tanto internos como externos a la
compaa). Eso describe el estado actual, pero tambin se proyecta el estado futuro
con una aproximacin a lo que ser el Enterprise Service Bus.
Phase D: Technology Architecture
Es aqu donde se desarrolla la arquitectura tecnolgica que implementa tanto el negocio

como las arquitecturas de informacin que se han elaborado durante las fases B y C. Al
igual que suceda con anteriores fases, se crea un baseline de la tecnologa actual,
analizando el modelo de hardware, modelo de red (LAN y WAN), el software de
infraestructura existente (sistema operativo, servidor de aplicaciones, servidor de datos,
etc.), etc. A partir de ah, se crea el estado futuro y se proyecta la arquitectura
tecnolgica ms ptima. Con todo eso en la mano, se realiza el correspondiente Gap
Analisys que nos permitir ver lo lejos que se encuentra nuestro objetivo de lo que
existe en la actualidad.
TOGAF Fases del ADM

Phase E: Opportunities and Solutions
Nos encontramos ante la fase de anlisis probablemente ms importante de
todo el proceso. Con todas las arquitecturas actuales y futuras definidas en

las anteriores fases, ahora corresponde analizarlas y ver cules son
exactamente los bloques que permitirn construir la nueva arquitectura,
cules se podrn reutilizar, cules ser necesario reemplazar y cules se
tendrn que proporcionar, bien mediante adquisicin de los mismos (en caso
de procesos estndares) y mediante el desarrollo a medida (para procesos
core-business).
Phase F: Migration Planning
A lo largo de la fase E se ha establecido el conjunto de bloques que darn
lugar a la arquitectura a implementar. Lgicamente, no todos se

implementarn al mismo tiempo, pues eso supondra un tremendo caos. Por
tanto, es necesario priorizar y, por tanto, establecer el orden en el que se
realizar la implantacin de todo lo acordado. Por tanto, se establecer el plan
de migracin hacia la nueva arquitectura.
TOGAF Fases del ADM

Phase G: Implementation Governance
Durante esta fase es el momento de crear las directrices que asegurarn que tanto los
desarrollos que se encuentran dentro del mbito de la arquitectura, como aquellos que se
encuentran fuera de ella, se ajustan exactamente a la arquitectura destino que se
pretende crear. Adems de todo el modelo de Governance, se establecen los principios
arquitectnicos, los principios de seguridad, la metodologa que se utilizar en todos
aquellos proyectos que se desarrollen, etc. Al final, se trata de conseguir un contrato de
arquitectura, que sea firmado por todas las partes que vayan a trabajar en los proyectos
de desarrollo.
Phase H: Architecture Change Management
En un entorno tan dinmico como el de un negocio, es prcticamente imposible que una

arquitectura esttica d respuesta a todas las necesidades que se irn generando.
Precisamente gestionar la dinmica de la arquitectura es el objetivo de esta fase. A lo
largo de la fase H se monitorizan las propuestas de cambio y se determinan si se procede
y cmo se procede a incorporarlas. Dependiendo de la naturaleza de los cambios ser
necesario traerlos a esta fase o no. Por ejemplo, una simplificacin de un proceso
normalmente puede ser gestionada mediante una buena poltica de gestin de cambios y
no es necesario traer ese cambio a esta fase. Cambios como la modificacin de
estndares o nuevas tecnologas, pueden requerir una rearquitectura parcial, que se
consigue accediendo a la fase D. Otros cambios ms profundos, como por ejemplo, la
modificacin severa de procesos de negocio, s requieren de volver a comenzar desde la
fase A.
TOGAF
The Open Group Architecture
Framework
http://www.opengroup.org/architecture/togaf9-doc/arch/index.html
TOGAF EC Enterprise Continuum

The second major part of TOGAF is the Enterprise Continuum, which provides a repository
for all the models, patterns, and other artifacts you create while iterating through the ADM.
You will be referencing it throughout the project. More than just a registry, however, the
TOGAF Enterprise Continuum provides a base on which you can build your own enterprise
architecture.
Enterprise Continuum se subdivide a su vez en: Architecture Continuum y Solutions
Continuum. El primero aloja los modelos, patrones, etc. que se producen. El segundo
contiene la forma en la que se han obtenido esos modelos, patrones, etc. Dado lo
pragmtico del modelo, se comienza por lo ms general, pero tambin se aborda lo ms
especfico, de forma que sea claramente de utilidad.
Conceptually, the Enterprise Continuum consists of the Architecture Continuum (models,
patterns, and so on) and the Solutions Continuum (consisting of documentation of how the
models and patterns in the Architecture Continuum are to be achieved). Each of these
continuums runs from the general to the specific. This means the Architecture Continuum
starts with the most general, a foundation architecture. It also includes a common systems
architecture (such as security or network architecture) and an industry architecture (such as
retail's Active Store) or the Petrochemical Open Software Corporation's data model. Finally, it
includes an enterprise architecture, which can be customized for a specific organization. The
Solutions Continuum starts with Products and Services, which are combined into System
Solutions, which are used in Industry Solutions, which can be customized to create an
Enterprise Solution.
Because it's more general than IIIRM and more likely to apply to your situation, let's discuss
the TOGAF Foundation Architecture.
Arquitectura a Diferentes Niveles
TOGAF - Dimensiones
Arquitectura de Negocios (o de Procesos de Negocio), la
cual define la estrategia de negocios, la gobernabilidad,

la estructura y los procesos clave de la organizacin.
Arquitectura de Aplicaciones, la cual provee un plano
(blueprint, en ingls) para cada uno de los sistemas de
aplicacin que se requiere implantar, las interacciones
entre estos sistemas y sus relaciones con los procesos
de negocio centrales de la organizacin.
Arquitectura de Datos, la cual describe la estructura de
los datos fsicos y lgicos de la organizacin , y los
recursos de gestin de estos datos
Arquitectura Tecnolgica, la cual describe la estructura
de hardware, software y redes requerida para dar
soporte a la implantacin de las aplicaciones principales,
de misin crtica, de la organizacin
TOGAF - Dimensiones
Metodologis y Modelos
para Construccin de Software
CMMI
Capability Maturity Model Integration
CMMI - Capability Maturity Model Integration

Modelo para la mejora y evaluacin de procesos para el
desarrollo, mantenimiento y operacin de sistemas de
software. Hay tres constelaciones de la versin 1.2
disponible:
CMMI para el Desarrollo (CMMI-DEV o CMMI for
Development), Versin 1.2 fue liberado en agosto de
2006. En l se tratan procesos de desarrollo de
productos y servicios.
CMMI para la adquisicin (CMMI-ACQ o CMMI for
Acquisition), Versin 1.2 fue liberado en noviembre de
2007. En l se tratan la gestin de la cadena de
suministro, adquisicin y contratacin externa en los
procesos del gobierno y la industria.
CMMI para servicios (CMMI-SVC o CMMI for Services),
est diseado para cubrir todas las actividades que
requieren gestionar, establecer y entregar Servicios.
CMMI - Capability Maturity Model Integration
CMMI Madurez - Inmadurez
CMMI
Modelo para la mejora o evaluacin de los procesos
de desarrollo y mantenimiento de sistemas y

productos de software.
Desarrollado por el Instituto de Ingeniera del
Software de la Universidad Carnegie Mellon (SEI), y
publicado en su primera versin en enero de 2002.
Es empleado para guiar las mejoras de procesos
durante el desarrollo de un proyecto, un
departamento o hasta una organizacin.
Origen CMMI
Durante los aos 90 SEI desarroll modelos
especficos para la mejora y medicin de la

madurez en varias reas:
CMM-SW: CMM for software
P-CMM: People CMM.
SA-CMM: Software Acquisition CMM.
SSE-CMM: Security Systems Engineering CMM.
T-CMM: Trusted CMM
SE-CMM: Systems Engineering CMM.
IPD-CMM: Integrated Product Development CMM.
Origen CMMI
CMMI se desarroll para facilitar y simplificar la
adopcin de varios modelos de forma simultnea.

Su contenido integra y da relevo a la evolucin
de sus predecesores:
CMM-SW (CMM for Software)
SE-CMM (Systems Engineering Capability Maturity
Model)
IPD-CMM (Integrated Product Development)
..sobre CMM
El modelo de Capacidad y Madurez, es un mtodo de definir y y
gestionar los procesos a realizar por una organizacin.

El modelo de calidad CMM aparece con la necesidad de mitigar los
problemas que se presentan continuamente al momento de contratar
empresas desarrolladoras de software, por la progresiva elevacin de
costos y desfase de las fechas de entrega.
Este modelo establece un conjunto de prcticas o procesos clave
agrupados en reas Clave de Proceso (KPA - Key Process Area).
Para cada rea de proceso define un conjunto de buenas prcticas que
habrn de ser:

Definidas en un procedimiento documentado

Provistas (la organizacin) de los medios y formacin necesarios
Ejecutadas de un modo sistemtico, universal y uniforme (institucionalizadas)
Medidas
Verificadas
..sobre CMM
A su vez estas reas de Proceso se agrupan en cinco "niveles de
madurez", de modo que una organizacin que tenga institucionalizadas

todas las prcticas incluidas en un nivel y sus inferiores, se considera
que ha alcanzado ese nivel de madurez.
Los niveles son:
1 - Inicial.
2 - Repetible.
3 - Definido.
4 - Gestionado.
5 - Optimizado.
As es como el modelo CMM establece una medida del progreso
conforme avanza, en niveles de madurez. Cada nivel a su vez cuenta
con un nmero de reas de proceso que deben lograrse. El alcanzar
estas reas se detecta mediante la satisfaccin o insatisfaccin de
varias metas claras y cuantificables.
Estructura CMMI
El modelo para software (CMM-SW)
Establece
5 niveles de madurez para clasificar a las

organizaciones, en funcin de qu reas de procesos
consiguen sus objetivos y se gestionan con principios de
ingeniera.
Es lo que se denomina un modelo escalonado, o centrado en la
madurez de la organizacin.
El modelo para ingeniera de sistemas (SE-CMM)

Establece 6 niveles posibles de capacidad para una de las 18
reas de proceso implicadas en la ingeniera de sistemas.

No agrupa los procesos en 5 tramos para definir el nivel de
madurez de la organizacin, sino que directamente analiza la
capacidad de cada proceso por separado.
Es lo que se denomina un modelo continuo.
En
el equipo de desarrollo de CMMI haba

defensores de ambos tipos de representaciones.
El resultado fue la publicacin del modelo con dos
representaciones: continua y escalonada.
Son equivalentes, y cada organizacin puede optar
por adoptar la que se adapte a sus caractersticas y
prioridades de mejora.
reas de proceso
reas de proceso de CMMI (Capability Maturity Model Integration)
rea de proceso
Categora
Nivel de madurez
Anlisis y resolucin de problemas
Soporte
Gestin de la configuracin
Soporte
Anlisis y resolucin de decisiones
Soporte
Gestin integral de proyecto
Gestin de proyectos
Gestin integral de proveedores
Gestin de proyectos
Gestin de equipos
Gestin de proyectos
Medicin y anlisis
Soporte
Entorno organizativo para integracin
Soporte
Innovacin y desarrollo
Gestin de procesos
Definicin de procesos
Gestin de procesos
Procesos orientados a la organizacin
Gestin de procesos
Rendimiento de los procesos de la org.
Gestin de procesos
Formacin
Gestin de procesos
Ingeniera
Monitorizacin y control de proyecto
Gestin de proyectos
Planificacin de proyecto
Gestin de proyectos
Soporte
Gestin de proyectos
Desarrollo de requisitos
Ingeniera
Gestin de requisitos
Ingeniera
Gestin de riesgos
Gestin de proyectos
Gestin y acuerdo con proveedores
Gestin de proyectos
Solucin tcnica
Ingeniera
Validacin
Ingeniera
Verificacin
Ingeniera
Integracin de producto
Gestin calidad procesos y productos

Gestin cuantitativa de proyectos
CMMI
EVALUACION DE PROCESOS
Mejora Continua del Proceso

(2 reas de Proceso)
Gestin Cuantitativa
(2 reas de Proceso)
Estandarizacin del Proceso

(11 reas de Proceso)
Gestin Bsica de Proyectos

(7 reas de Proceso)
Gestionado
(2)
Inicial
(1)
Optimizante
(5)
Gestionado
Cuantitativamente
(4)
Definido
(3)
- Innovacin y Distribucin Organizacional (OID)

- Anlisis Causal y Resolucin (CAR)
- Rendimiento del Proceso Organizacional (OPP)

- Gestin Cuantitativa de Proyectos (QPM )
- Gestin Cuantitativa del Suministrador (QSM)
- Desarrollo de Requisitos (RD)

- Entorno Organizacional
- Solucin Tcnica (TS)
para la Integracin (OEI)
- Integracin del Producto (PI)
- Equipo Integrado (OIT)
- Verificacin (VER)
- Validacin (VAL)
- Gestin Integrada del
- Enfoque Proceso Organizacional (OPF)
- Definicin del Proceso Organizacional (OPD) Suministrador (ISM)
- Formacin de la Organizacin (OT)
- Gestin Integrada de Proyectos (IPM)
- Gestin de Riesgos (RSKM)
- Anlisis de Decisin y Resolucin (DAR)
- Gestin de Requisitos (REQM)

- Planificacin del Proyecto (PP)
- Seleccin y Monitorizacin
- Monitorizacin y Control del Proyecto (PMC)
del Suministrador (SSM)
- Gestin del Acuerdo con el Suministrador (SAM)
- Medicin y Anlisis (M & A)
- Aseguramiento de la Calidad del Proceso y Producto (PPQA)
- Gestin de la Configuracin (CM)
- Procesos Caticos (Ad Hoc)
CMMI Paso a Paso
Inicial
La organizacin en este nivel no
dispone de un ambiente estable

para el desarrollo y
mantenimiento de productos y
servicios.
Administrado
En
la organizacin que se
encuentra en este nivel algunas
reas
organizacionales
y/o
proyectos han alcanzado las
metas genricas y especficas
establecidas en sus reas de
proceso, es decir planean sus
procesos, los ejecutan, los
miden y los controlan.
Definido
Tienen los procesos caracterizados,
entendidos por los ejecutores,

descritos mediante estndares,
procedimientos, mtodos y
herramientas.
Administrado Cuantitativamente
La organizacin selecciona y
administra las actividades que

contribuyen perceptiblemente
al funcionamiento de proceso
total. Estas actividades
seleccionadas son controladas
con tcnicas estadsticas y
otras tcnicas cuantitativas.
Optimizado
Los procesos de la organizacin
son mejorados continuamente

basados en una comprensin
cuantitativa de las causas
comunes de variacin inherentes
a los procesos. El nivel 5 est
centrado en mejorar
continuamente el desempeo de
los procesos con mejoras
tecnolgicas incrementales e
innovadoras.
CMMI-Componentes
Componentes Requeridos
genrico: Los objetivos genricos
Objetivo asociados a un nivel de capacidad establecen lo que una
organizacin debe alcanzar en ese nivel de capacidad.

Objetivo especfico: Los objetivos especficos se aplican a una nica
rea de proceso y localizan las particularidades que describen que se
debe implementar para satisfacer el propsito del rea de proceso.
Componentes Esperados
Prctica genrica: Una prctica genrica se aplica a cualquier rea de
proceso porque puede mejorar el funcionamiento y el control de

cualquier proceso.
Prctica especfica: Una prctica especfica es una actividad que se
considera importante en la realizacin del objetivo especfico al cual est
asociado.
Las prcticas especficas describen las actividades esperadas para lograr
la meta especfica de un rea de proceso
CMMI - Componentes
Componentes
Componentes Informativos
Propsito
Notas introductorias
Nombres
Tablas de relaciones prctica - objetivo
Prcticas
Productos tpicos
Sub-prcticas: Una sub-prctica es una descripcin detallada que sirve
como gua para la interpretacin de una prctica genrica o especifica.
Ampliaciones de disciplina: Las ampliaciones contienen informacin
relevante de una disciplina particular y relacionada con una prctica
especifica.
Elaboraciones de prcticas genricas: Una elaboracin de una prctica
genrica es una gua de cmo la prctica genrica debe aplicarse al rea de
proceso.

CMMI a Futuro ISO 15504
Procesos y tcnicas para desarrollo de software

Para ampliar informacin
Modelos basados en procesos
Pgina oficial CMMI del Software Engineering Institute. (http://www.sei.cmu.edu/cmmi/cmmi.html)
Pgina para descarga de los modelos CMMI. (http://www.sei.cmu.edu/cmmi/models/models.html)
SWEBOK: reas de conocimiento de la Ingeniera del software (http://www.swebok.org/)
Gestin de proyectos PMI (http://www.pmi.org) IPMA (http://www.ipma.ch) PRINCE 2 (http://www.prince2.com/)
Modelos giles
Manifiesto gil (http://www.agilemanifesto.org/)
Agile Alliance (http://www.agilealliance.org/)

Scrum (http://www.controlchaos.com/)
Exreme Programming (http://www.extremeprogramming.org/)
DSDM (http://www.dsdm.org/)
Microsoft Solutions Framework (http://msdn.microsoft.com/vstudio/teamsystem/msf/)
Rational Unified Process (http://www-306.ibm.com/software/rational/)
(http://www-128.ibm.com/developerworks/rational/library/content/RationalEdge/jan01/WhatIstheRationalUnifiedProcessJan01.pdf)
Agile Modeling (http://www.agilemodeling.com/)
Feature Driven Development (http://www.featuredrivendevelopment.com/)
Internet Speed Development (http://www.sei.cmu.edu/pub/documents/02.reports/pdf/02tr020.pdf)
138

ISO/IEC TR 15504: Dimensin de proceso (alineado 12207)
CUS.1 Adquisicin
Preparacin de la Adquisicin
Seleccin del suministrador
Seguimiento del suministrador
Aceptacin del cliente
CUS.2 Suministro
SUP.1 Documentacin
CUS.4 Operacin
SUP.2 Gestin de la configuracin
Operacin
Soporte a cliente
CUS.3 Obtencin de requisitos
SUP.4 Verificacin
SUP.5 Validacin
ENG.1 Desarrollo
Requisitos del sistema
Anlisis y diseo
Anlisis requ. Software
Diseo del software
SUP.3 Aseguramiento de la calidad
Construccin del software

Integracin del software
Pruebas del software
Pruebas e integ. del sistema
SUP.6 Revisin conjunta

SUP.7 Auditora
ENG.2 Mantenimiento del sistema y del software
SUP.8 Resolucin de problemas
ORG.1 Alineamiento organizacional
MAN.1 Gestin
ORG.2 Mejora
Definicin de procesos
Evaluacin de procesos
Mejora de procesos
ORG.3 Gestin de las personas
MAN.1 Gestin de proyecto
MAN.1 Gestin de la calidad
ORG.4 Infraestructura
ORG.5 Medicin
ORG.6 Reutilizacin
MAN.1 Gestin de riesgos
139

ISO/IEC TR 15504: Dimensin de capacidad
Niveles de capacidad y atributos

Nivel 0: Proceso Incompleto

Nivel 1: Proceso Realizado

PA 1.1 Se produce el resultado
Nivel 2: Proceso Gestionado

PA 2.1 Gestin de la ejecucin

PA 2.2 Gestin de las
caractersticas del producto
Nivel 3: Proceso Establecido

PA 3.1 Definicin del proceso

PA 3.2 Recursos de lproceso
Nivel 4: Proceso Predecible

PA 4.1 Medicin del proceso

PA 4.2 Control del proceso
Nivel 5: Proceso en optimizacin

PA 5.1 Cambio del proceso

PA 5.2 Mejora continua
Medicin de atributos
No alcanzado (0% a 15%).

Escasa o ninguna evidencia de la consecucin
del atributo.
Parcialmente alcanzado (16% a 50%).

Evidencia de un enfoque sistemtico y de la
consecucindel atributo.
Algunos aspectos de la consecucin pueden ser
impredecibles.
Ampliamente alcanzado (51% a 85%).
Evidencia de un enfoque sistemtico y de una
consecucin significativa del atributo.
La realizacin del proceso puede variar en
algunas reas.
Totalmente alcanzado (86% a 100%).

Evidencia de un enfoque completo y sistemtico
y de la consecucin plena del atributo.
140
Metodologis Alternas
para Construccin de Software

Manifiesto gil (2001)
Origen de los mtodos giles
En marzo de 2001, 17 crticos de estos modelos, convocados por Kent Beck, que acababa de definir una nueva
metodologa denominada Extreme Programming, se reunieron en Salt Lake City para discutir sobre los modelos
de desarrollo de software.
En la reunin se acu el trmino Mtodos giles para definir a aquellos que estaban surgiendo como
alternativa a las metodologas formales, (CMM-SW, PMI, SPICE) a las que consideraban excesivamente
pesadas y rgidas por su carcter normativo y fuerte dependencia de planificaciones detalladas, previas al
desarrollo.
Los integrantes de la reunin resumieron en cuatro postulados lo que ha quedado denominado como Manifiesto
gil, que compendia el espritu en el que se basan estos mtodos.
Aunque como se ver ms adelante, en la actualidad hay aproximaciones que combinan lo mejor de ambos
enfoques (formal y gil), hasta 2005, en cada lado sus defensores adoptaron posturas radicales, quiz ms
ocupadas en descalificar a la contraria que en estudiarla y conocerla para mejorar la propia.
142

Manifiesto gil (2001)
Estamos poniendo al descubierto mejores mtodos para desarrollar software, hacindolo y

ayudando a otros a que lo hagan. Con este trabajo hemos llegado a valorar:
A los individuos y su interaccin
por encima
de los procesos y las herramientas
El software que funciona
por encima
de la documentacin exhaustiva
La colaboracin con el cliente
por encima
la negociacin contractual
La respuesta al cambio
por encima
seguimiento de un plan
Aunque hay valor en los elementos de la derecha, valoramos ms los de la izquierda
Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew
Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas
http://agilemanifesto.org/
143

Mtodos giles
Tcnicas y mtodos
giles
Adaptaciones
para softw.
Modelos para software

1997
TickIT
1991
ISO 9000-3
Trillium
1959
1979
1987
MIL-Q 9858
BS 5750
ISO 9000
Modelos especficos
para software.
Modelos y estndares
de calidad
Modelos genricos
Bootstrap
1995
ISO 12207
1995
Proy. SPICE
1993
CMM-SW
TR 15504
2003-05
ISO 15504
Modelos
CMM
2001
CMMI
DSDM
SCRUM
CRYSTAL
XP
ASD
PP
ISD
AM
1995
2000
Manifiesto
gil
144

Mtodos giles
5. Procesos primarios
Recogen tcnicas, buenas prcticas

contrastadas por profesionales
reconocidos.
5. Procesos de soporte
5.1 Adquisicin
6.1 Documentacin
5.2 Suministro
6.2 Gestin de la configuracin
6.3 Control de calidad
Cada una tiene sus caractersticas propias

y cubre un rango de reas de procesos
ms o menos amplia:
Tendencia a combinarlas para dar
mayor cobertura en el ciclo de vida
Han surgido de entornos reales de
desarrollo de software
Responden mejor a la realidad del
software y las diferencias con
produccin industrial.
5.3
Operacin
6.4 Verificacin
6.5 Validacin
5.3
Desarrollo
6.6 Reuniones
5.3
Mantenimiento
6.7 Auditora
6.8 Resolucin de problemas
7. Procesos organizacionales
7.1 Gestin
7.2 Infraestructura
7.3 Mejora
7.4 Formacin
145
eXtreme Programming (XP)

Este es el mtodo que ms popularidad ha alcanzado entre las metodologas giles, y posiblemente sea tambin el
ms transgresor de la ortodoxia basada en procesos.
Su creador, Kent Beck fue el alma mater del Manifiesto gil.
Extreme Programming (XP) se irgue sobre la suposicin de que es posible desarrollar software de gran calidad a
pesar, o incluso como consecuencia del cambio continuo. Su principal asuncin es que con un poco de
planificacin, un poco de codificacin y unas pocas pruebas se puede decidir si se est siguiendo un camino
acertado o equivocado, evitando as tener que echar marcha atrs demasiado tarde.
Valores que inspiran XP

SIMPLICIDAD
FEEDBACK
CORAJE
COMUNICACIN
146

Comunicacin
XP pone en comunicacin directa y continua a clientes y desarrolladores. El cliente se integra en el equipo para
establecer prioridades y resolver dudas. De esta forma ve el avance da a da, y es posible ajustar la agenda y las
funcionalidades de forma consecuente
Feedback rpido y continuo

Una metodologa basada en el desarrollo incremental de pequeas partes, con entregas y pruebas frecuentes y
continuas, proporciona un flujo de retro-informacin valioso para detectar los problemas o desviaciones.
De esta forma fallos se localizan muy pronto.
La planificacin no puede evitar algunos errores, que slo se evidencian al desarrollar el sistema.
La retro-informacin es la herramienta que permite reajustar la agenda y los planes.
147

Simplicidad
La simplicidad consiste en desarrollar slo el sistema que realmente se necesita. Implica resolver en cada momento
slo las necesidades actuales.
Los costes y la complejidad de predecir el futuro son muy elevados, y la mejor forma de acertar es esperar al
futuro.
Con este principio de simplicidad, junto con la comunicacin y el feedback resulta ms fcil conocer las
necesidades reales
Coraje
El coraje implica saber tomar decisiones difciles. Reparar un error cuando se detecta. Mejorar el cdigo siempre
que tras el feedback y las sucesivas iteraciones se manifieste susceptible de mejora.
Tratar rpidamente con el cliente los desajustes de agendas para decidir qu partes y cundo se van a entregar.
148

Las 12 prcticas de XP
XP no es un modelo de procesos ni un marco de trabajo, sino un conjunto de 12 prcticas que se
complementan unas a otras y deben implementarse en un entorno de desarrollo cuya cultura se base en
los cuatro valores citados
PRCTICAS DE CODIFICACIN
1.- Simplicidad de cdigo y de diseo para producir software fcil de modificar.
2.- Reingeniera continua para lograr que el cdigo tenga un diseo ptimo.
3.- Desarrollar estndares de codificacin, para comunicar ideas con claridad a travs del cdigo.
4.- Desarrollar un vocabulario comn, para comunicar las ideas sobre el cdigo con claridad.
PRCTICAS DE DESARROLLO
1.- Adoptar un mtodo de desarrollo basado en las pruebas para asegurar que el cdigo se
comporta segn lo esperado.
2.- Programacin por parejas, para incrementar el conocimiento, la experiencia y las ideas.
3.- Asumir la propiedad colectiva del cdigo, para que todo el equipo sea responsable de l.
4.- Integracin continua, para reducir el impacto de la incorporacin de nuevas funcionalidades.
149

Las 12 prcticas de XP
PRCTICAS DE NEGOCIO
1.- Integracin de un representante del cliente en el equipo, para encauzar las cuestiones de negocio del
sistema de forma directa, sin retrasos o prdidas por intermediacin.
2.- Adoptar el juego de la planificacin para centrar en la agenda el trabajo ms importante.
3.- Entregas regulares y frecuentes para satisfacer la inversin del cliente.
4.- Ritmo de trabajo sostenible, para terminar la jornada cansado pero no agotado.
150
Scrum
No es propiamente un mtodo o metodologa de desarrollo, e implantarlo como tal resulta insuficiente.
Scrum define mtodos de gestin y control para complementar la aplicacin de otros mtodos giles como XP que,
centrados en prcticas de tipo tcnico, carecen de ellas.
Los principios de Scrum son:
Equipos autogestionados.
Una vez dimensionadas las tareas no es posible agregarles trabajo extra.
Reuniones diarias en las que los miembros del equipo se plantean 3 cuestiones:
Qu has hecho desde la ltima revisin?
Qu obstculos te impiden cumplir la meta?
Qu vas a hacer antes de la prxima reunin?
Iteraciones de desarrollo de frecuencia inferior a un mes, al final de las cuales se presenta el
resultado a los externos del equipo de desarrollo, y se realiza una planificacin de la siguiente iteracin,
guiada por cliente.
151
Scrum
152
Otros mtodos giles

Familia de mtodos Crystal
La familia de metodologas Crystal ofrece diferentes mtodos para seleccionar el ms apropiado para cada
proyecto.
Crystal identifica con colores diferentes cada mtodo, y su eleccin debe ser consecuencia del tamao y criticidad
del proyecto, de forma que los de mayor tamao, o aquellos en los que la presencia de errores o desbordamiento
de agendas implique consecuencias graves, deben adoptar metodologas ms pesadas.
Los mtodos Crystal no prescriben prcticas concretas
ASD (Adaptative Software Development)

Mtodo que como alternativa a los procedimientos formales, aborda el desarrollo de grandes sistemas con el uso
de tcnicas propias de las metodologas giles.
No se trata de una metodologa, sino de la implantacin de una cultura en la empresa, basada en la adaptabilidad.
153
Otros mtodos giles

PP (Pragmatic Programming)
Pragmatic Programming es la coleccin de 70 prcticas de programacin, comunes a otros mtodos giles, cuya
aplicacin resulta til para solucionar los problemas cotidianos. Surge del libro The Pragmatic Programmer de
Dave Thomas y Andres Hunt.
AM (Agile Modeling)
Agile Modeling es la presentacin de un nuevo enfoque para realizar el modelado de sistemas,(diseo) y basado en
los principios de los mtodos giles remarca la conveniencia de reducir el volumen de la documentacin. (Amber S.
Agile Modeling: Effective Practices for Extreme Programming and the Unified Process)
ISD Internet Speed Development

Surge de las conclusiones del coloquio celebrado en Octubre de 2001, promovido por SEI que reuni a
especialistas de las universidades Carneige Mellon, Georgia y Copenhagen.
Sienta bases de gestin para abordar el desarrollo de sistemas de software, de tamao pequeo que requieren
tiempos de desarrollo muy rpidos.
FDD (Feature Driven Development)

Prescribe un proceso iterativo de 5 pasos, con iteraciones de dos semanas.
El punto de referencia son las caractersticas que debe reunir el software, y se centra en las fases de diseo e
implementacin del sistema
154
Modelos de propiedad Comercial: MSF

MSF es la metodologa empleada por Microsoft para el desarrollo de software.
Hasta su versin 3 (principios de 2005) MSF se defina como un marco de desarrollo flexible para adaptarse a las
necesidades de cada proyecto, en oposicin a lo que sera una metodologa prescriptiva; porque parte de la base
de que no hay una estructura de procesos ptima para las necesidades de todos los entornos de desarrollo
posibles.
El marco MSF se asienta sobre unos Principios Fundamentales que definen la cultura del entorno de desarrollo:
MSF: PRINCIPIOS FUNDAMENTALES

Fomento de la comunicacin abierta.

Trabajo en torno a una visin compartida.
Apoderar a los integrantes del equipo (empowerment)
Establecimiento de responsabilidades claras y compartidas.
Centrar el objetivo en la entrega de valor para el negocio.
Permanecer giles y esperar e cambio.
Invertir en calidad.
Aprender de la experiencia.
155

Elementos que componen el modelo
Principios fundamentales
Modelos
Disciplinas
Conceptos clave
Prcticas contrastadas
Recomendaciones
Principios bsicos en los que se basa todo el modelo (los 8 de la pg. ant.)
Mapas mentales de organizacin. Hay 2: De equipo y de procesos

reas de trabajo en las que se usan mtodos determinados (Gestin de
proyecto, de riesgos y de la mejora del talento)
Ideas que dan soporte a los principios y disciplinas de MSF y se muestran
a travs de prcticas especficas contrastadas.
Prcticas que han demostrado su efectividad en proyectos en diferentes
condiciones de entornos reales
Prcticas opcionales, sugeridas por el modelo.
156

Relacin entre los componentes del modelo
Este diagrama es un ejemplo para mostrar la interconexin y relacin entre los componentes de Microsoft Solutions
Framework
Principio
Fundamental
Modelo o
Disciplina
Concepto
Clave
Prctica
Contrastada
Recomendac.
Aprender de las
experiencias
Modelo de
procesos
Disposicin al
aprendizaje
Hitos de
revisin
Uso de
facilitadores
externos
Permanecer
gil y esperar el
cambio
Gestin de
riesgos
Evaluacin
continua de
riesgos
Definir y
monitorizar
disparadores
de riesgos
Creacin de
una BD de
riesgos
Est relacionado
En 2005, el desarrollo del nuevo producto de Microsoft Visual Studio 2005 Team System ha ganerado la evolucin
de MSF hacia la nueva versin 4.0 con dos lneas paralelas:
Microsoft Solutions Framework (MSF) for Agile Software Development.
Microsoft Solutions Framework (MSF) for CMMI Process Improvement.
157
Modelos de propiedad Comercial: RUP

Rational Unified Process
Es un proceso de Ingeniera del Software que proporciona una visin disciplinada para la asignacin de tareas y
responsabilidades en las organizaciones de desarrollo de software.
RUP es un modelo-producto desarrollado y mantenido por Racional Software, integrado en su conjunto de
herramientas de desarrollo, y distribuido por IBM.
RUP integra un conjunto de buenas prcticas para el desarrollo de software en un marco de procesos vlido para
un rango amplio de tipos de proyectos y organizaciones.
RUP: Buenas Prcticas
Desarrollo iterativo.
Gestin de requisitos.
Uso de arquitecturas basadas en componentes.
Uso de tcnicas de modelado visual.
Verificacin continua de la calidad.
Gestin y control de cambios.
158

Rational Unified Process: Visin esttica
En su visin esttica, el modelo RUP est compuesto por:
Roles: analista de sistemas, diseador, diseador de pruebas, roles de gestin y roles de administracin.
Actividades: RUP determina el trabajo de cada rol a travs de actividades. Cada actividad del proyecto
debe tener un propsito claro, y se asigna a un rol especfico. Las actividades pueden tener duracin de
horas o de algunos das; y son elementos base de planificacin y progreso.
Artefactos: Son los elementos de entrada y salida de las actividades. Son productos tangibles del
proyecto. Las cosas que el proyecto produce o usa para componer el producto final (modelos,
documentos, cdigo, ejecutables)
Disciplinas: son contenedores empleados para organizar las actividades del proceso. RUP comprende
6 disciplinas tcnicas y 3 de soporte.
Tcnicas: modelado del negocio, requisitos, anlisis y diseo, implementacin, pruebas y desarrollo.
Soprte: gestin de proyecto, gestin de configuracin y cambio, y entorno.
Flujos de trabajo: son el pegamentode los roles, actividades, artefactos y disciplinas, y constituyen la
secuencia de actividades que producen resultados visibles.
159

Rational Unified Process: Visin dinmica
En su visin dinmica, la visin de la estructura del ciclo de vida RUP se basa en un desarrollo iterativo, jalonado
por hitos para revisar el avance y planear la continuidad o los posibles cambios de rumbo.
Cuatro son las fases que dividen el ciclo de vida de un proyecto RUP:
1.- Inicio. Es la fase de la idea, de la visin inicial de producto, su alcance. El esbozo de una arquitectura
posible y las primeras estimaciones. Concluye con el hito de objetivo.
2.- Elaboracin. Comprende la planificacin de las actividades y del equipo necesario. La especificacin
de las necesidades y el diseo de la arquitectura. Termina con el hito de Arquitectura.
3.- Construccin. Desarrollo del producto hasta que se encuentra disponible para su entrega a los
usuarios. Termina con el hito del inicio de la capacidad operativa.
4.- Transicin. Traspaso del producto a los usuarios. Incluye: manufactura, envo, formacin, asistencia y
el mantenimiento hasta lograr la satisfaccin de los usuarios. Termina con el hito de entrega del
producto.
160

FACTORES CLAVE EN LOS PROYECTOS
Factor
Discriminadores giles
Discriminadores formales
Tamao
Dependencia y escalabilidad limitada por el

porcentaje alto de conocimiento tcito.
Apropiado para equipos y productos pequeos.
Escalabilidad y conocimiento explcito.

Apropiado para productos y equipos grandes.
Duro de mantener en pequeos proyectos.
Criticidad
La simplicidad en la documentacin y el diseo

dificulta los planes de pruebas.
No aconsejado para sistemas con niveles de
criticidad altos (IEEE 1012)
Rigor de requisitos y diseo adecuados para

procesos de pruebas, verificacin y validacin.
Duros de gestionar en proyectos de escasa
criticidad
Dinamismo
Re-factorizar desde un diseo bsico hasta el

producto final es un mtodo ideal para entornos
dinmicos e in-novadores, pero muy caro por el
re-trabajo para entornos estables o conocidos
En sistemas estables y conocidos, partir de

requisitos completos y diseos detallados
permite trazar y seguir un plan completo y
hacerlo bien a la primera.
Personal
Los mtodos de trabajo giles requieren una

masa crtica de tcnicos con niveles de
experiencia medios-altos, capaces de
comprender y adaptar los mtodos y las
tcnicas empleadas.
Aunque es aconsejable contar con personas

expertas en las fases de definicin del proyecto,
luego pueden ejecutarse con menor masa
crtica de expertos.
Cultura
Ms apropiado para culturas de empowerment

responsabilidad y horquilla de decisin y
libertad personal.
Ms apropiado en culturas en las que las

personas se sienten seguras con un marco de
tareas y responsabilidades bien definido.
Adaptado de Barry Bohem y Richard Turner
Balancing Agility and Discipline
161

Enfoque formal o gil?
Personal
% Junior
% Senior y Master
40
15
30
20
20
25
10
30
Criticidad
Prdidas posibles
Dinamismo
% Modific. Requisitos / mes
1
5
35
10
30
50
3
10
90
30
70
100
300
Tamao
Nmero de personas
50
30
10
Cultura
% adaptacin a entornos caticos
162
Arquitectura de Software
Proyectos sin Arquitectura, ni Frameworks
IEEE 1471
Arquitectura es la
organizacin fundamental de
un sistema descrita en:
Sus componentes.
Relacin entre ellos y con el
ambiente.
Principios que guan su
diseo y evolucin.
La arquitectura debe
satisfacer los requerimientos

de calidad de servicio.
El nivel conceptual ms alto

de un sistema en su
ambiente.
Evolucin de Arquitecturas
Aplicaciones Monolticas
Interfaces grficas de usuario
(GUI).
Servicios de presentacin,
negocios y persistencia en la
misma mquina.
Arquitectura Cliente-Servidor
+ Clientes pesados, no estndar
+ Conexiones dedicadas a BD
+ Protocolos pesados
+ Ejecucin remota de SQLs
+ Alta administracin
No hay concurrencia de usuarios.
+ Bajo rendimiento
Alto acoplamiento entre tiers.
+ Alto trfico de red

+ Baja accesibilidad
Arquitectura Cliente-Servidor
Arquitectura de 3 niveles
Mejorada
+ Reutilizacin de lgica de negocio para
Lgica de negocios en BD
Clientes pesados, no estndar.
Conexiones dedicadas a la BD.
Mejora en rendimiento
Alta administracin
Baja escalabilidad
Baja flexibilidad
Baja portabilidad
diferentes clientes o sistemas.

+ Mejora la escalabilidad.
+ Mejora la flexibilidad.
+ Independencia de la base de datos.
Arquitectura de N-niveles
100.000+
+ Bajo costo de administracin de clientes.

+ Alta accesibilidad.
+ Alta flexibilidad.
+ Alta disponibilidad y tolerancia a fallos.
+ Alta escalabilidad.
+ Independencia de DB
Visin de Arquitectura Orientada a Servicios (SOA)
+ Requerimientos
Sistema
Batch
Portal de
Servicios Integrados
Arquitectnicos
+ Heterogeneidad
+ Escalabilidad
Base de
Datos
+ Disponibilidad
Servidor de
Procesos
+ Distribucin
(BPM) Aplicaciones
+ Manejabilidad de Procesos
Legadas
+ Administracin y monitoreo de procesos,
servicios e infraestructura
Cluster de
Servidores de
Aplicaciones
Que es un Arquitecto de Software?
Rational Unified Process

Arquitecto es un rol en un proyecto
de desarrollo de software el cual es
responsable de:
Liderar el proceso de
arquitectura.
Producir los artefactos
necesarios: Documento de
descripcin de arquitectura
Modelos y prototipos de
arquitectura.
SUN SL-425:
El arquitecto:
Visualiza el comportamiento
del sistema.
Crea los planos del sistema.
Define la forma en la cual los
elementos del sistema
trabajan en conjunto.
Responsable de integrar los
requerimientos no-funcionales
(NRFs) en el sistema.
Arquitectura Vs. Diseo

+
La arquitectura y el diseo difieren en tres reas:

Arquitectura
Diseo
Nivel de
Abstraccin
Alto nivel
Bajo nivel. Enfoque

especfico en detalles
Entregables
Planear subsistemas, interfaces

con sistemas externos,
servicios horizontales,
frameworks, componentes
reutilizables, prototipo
arquitectnico
Diseo detallado
componentes.
Seleccin de tecnologas,
Requerimientos no funcionales
(QoS),
Manejo de riesgos
Requerimientos
funcionales
reas de
Enfoque
Especificaciones de
codificacin
Arquitectura Vs. Diseo

La arquitectura envuelve un conjunto de
decisiones estratgicas de diseo, lineamientos,

reglas y patrones que restringen el diseo y la
implementacin de un software.
Cdigo
Implementacin
Diseo
Arquitectura
Las decisiones
de arquitectura
causan un alto
impacto en los
proyectos de IT
SOA
Arquitectura Orientada a Servicios
Arquitectura Orientada a Servicios (SOA)
SOA es una arquitectura conceptual.

Organiza funciones de negocio como servicios interoperables.
Permite reutilizacin de servicios para dar cumplimiento a las
necesidades del negocio.

SOA es basado en estndares.
Independencia de fabricantes.
SOA es una estrategia de IT, a nivel empresarial.
Que es un Servicio?
Un servicio es un componente que provee un
conjunto de funciones de negocios.

Los servicios son conceptualmente:
Autnomos
Opacos
Bajamente acoplados.
SOA y Web Services

Los Servicios Web juegan un papel importante en una
arquitectura SOA, ya que brindan mecanismos
independientes de la plataforma para exponer, descubrir
e invocar servicios.
SOA requiere que un servicio:
Sea descubrible e invocable dinmicamente. UDDI,
WSDL, SOAP.
Tenga una definicin del contrato independiente de
plataforma. XML.
Pueda interoperar con otros servicios. HTTP.
Por que SOA?

Permite que el rea de IT
satisfaga ms gilmente las
necesidades del negocio,
cerrando cada vez ms la
brecha entre la evolucin del
negocio y el soporte
tecnolgico.
Crea servicios basados en
estndares, interoperables e
independientes de un
proveedor especfico.
Reutilizacin de servicios para
la creacin de nuevas
aplicaciones o funcionalidades
que apoyan los procesos de
negocio.
Arquitectura de Referencia SOA

Conceptual:
Neutral en
Tecnologa
Dependiente de
Tecnologa.
Reutilizable
entre Proyectos.
Instancia
Arquitectura
de Referencia.
Especfica de
cada Proyecto.
Modelo de Referencia
SOA
Frameworks
Arquitectura de
Referencia SOA
Patrones de Diseo
Arquitectura Concreta
OASIS - Modelo de Referencia SOA
Arquitectura Concreta:
Servicios de Negocio
Presentation
Business
Resources
Session
Facade
Front
Controller
Session
Facade
Session
Facade
Servicios de Negocio: Web Services, EJBs.
EIS
LDAP
Servicios de Negocio y Persistencia
Presentation
Business
Session
Facade
Front
Controller
Session
Facade
Integration
Resources
Composite
Entity
Composite
Entity
Session
Facade
Servicios de Negocio y Persistencia: Web Services, EJBs.
LDAP
Orquestacin y Procesos de Negocio
Presentation
Business
Session
Facade
Front
Controller
Session
Facade
Process Orchestration
Session
Facade
Servicios de Negocio: Web Services, EJBs.
Business Process
Business Logic
Session
Facade
Session
Facade
Integration
Resources
Composite
Entity
Composite
Entity
Process Orchestration
Session
Facade
LDAP
Ruta de Implementacin a SOA

Evaluar grado de madurez SOA y definir grados de madurez que la organizacin
quiere alcanzar en el tiempo.

Implementar un proyecto piloto utilizando SOA con servicios simples que
impacten mas de un rea de negocio.

Para el caso de sistemas legados habilitar funciones de negocio requeridas por
Nivel 6
SOA optimizado
Nivel 5
Adopcin empresarial de SOA
Nivel 4
SOA repetible
Nivel 3
Enfoque SOA definido
Nivel 2
Adopcin Ad Hoc de SOA
Nivel 1
Ninguna adopcin de SOA
Explotacin
Expansin
Exploracin
Evolucin SOA
el proyecto piloto como servicios.
Arquitecturas Tcnicas Abiertas

Caso: Java Enterprise
Lenguaje / Plataforma /Arquitectura

Lenguaje creado a principios de los 90.

Java Enterprise (J2EE JEE) (2001)
Open Source desde Fed /2007.
Sistemas Operativos Soportados: Linux, Solaris, Aix, Unix,
Windows XX
Open source profesional vs. Open source problema.
Firmara usted un contrato para garantizar su proyecto open
source ?
Comunidades dinmicas : fabricantes, ISV, universidades, etc.
Es comn tener mltiples alternativas de solucin para un
requerimiento
Groovy Lenguaje gil para plataforma Java (2004)
Hablemos solo de Open Source ..
Quien est detrs de Java ?

JCP (Java Community Process)
SUN (Oracle)
IBM
SAP
HP
Nokia
Blackberry
Google.
Aplicaciones para Escritorio

Primera Generacin
AWT - Swing (SUN)
SWT (IBM Apache )
Segunda Generacin
Netbeans framework (Drag & Drop environment)
RCP framework (IBM - Apache)
Aplicaciones Mbiles
Java Mobile (J2ME)
Desde Aplicativos Embebidos (Java Card),
electrodomsticos, celulares bsicos, etc.

Hasta PDAs y Smartphones
Fabricantes que implementan JVM y JSRs
Incluyen funcionalidad adicional, emuladores,

Otros Frameworks de alto nivel - J2ME Polish - Iphone
Aplicaciones Web
Primera Generacin
Java Server Pages , Servlets
Segunda Generacin: MVC O.O.
Struts, Tapestry,
Java Server Faces (event oriented)
Tercera Generacin
Web 2.0 - Ajax- RIA Aplicaciones Cinemticas
JSF:

RichFaces, Icefaces, Seam

OpenLaszlo
GWT,
Zk V
aadin
Entornos para Desarrollo (Open)

Eclipse: (IBM Apache Oracle
Adobe)
Escritorio, Mviles (J2ME)
Web, Empresarial (JEE), RIA, Groovy.
Netbeans : (SUN)
Escritorio, Mviles (J2ME), Web, Empresari
(JEE),
SOA, BPM, UML, Groovy, php, ruby and
Rails.
Aplicaciones Empresariales, SOA y BPM

Empresariales
Seguras, transaccional, geogrficamente dispersas, altamente disponibles
EJB, Web Services, Corba, JNDI, JAAS, PKI, Metro
Orientadas a Servicios
Primera Generacin
XML
Web Services : SOAP y REST
Segunda Generacin: Mediacin, Transformacin, orquestacin
(ESB)
SUN Glassfish
Apache Service Mix (ESB)
Orientadas a Procesos (BPM) y Flujos (workflow)

JBPM
Glassfish
OpenSymphony
Java Enterprise - Modular Mxima Reutilizacin

Y adaptabilidad a entornos Existentes
Presentation
Business
Session
Facade
Front
Controller
Session
Facade
Integration
Resources
Composite
Entity
Composite
Entity
Session
Facade
LDAP
Java como Implementacin Natural SOA

SOA optimizado
Nivel 5
Adopcin empresarial de SOA
Nivel 4
SOA repetible
Explotaci
n
Expansin
Nivel 3
Enfoque SOA definido
Nivel 2
Adopcin Ad Hoc de SOA
Nivel 1
Ninguna adopcin de SOA
Exploraci
n
Evolucin SOA
Nivel 6
Frameworks de Ultima Generacin

Pruebas Automatizadas
Junit HttpUnit
Jmeter (Performance)
Integracin
Spring
Reportes y Grficos
Jasper Reports & Birt (Designer & Engine)

Jchart
Apache POI (excel, word, etc)
Itext PDF
Ms frameworks de Ultima Generacin

Persistencia
JPA SQL desde los objetos

IBatis - Mapeo de SQL en Objetos
Model Driven Architecture (desde BD)
OpenXava,
Contenedores :Servidores de Aplicaciones

Compilable a O.S :
Windows: Excelsior Jet /
Linux: GCJ
Web: Apache Tomcat, Jetty, Java Personal

Enterprise: (EJB, web, web services)
IBM WebSphere Application Server Community
edition
Redhat JBoss
SUN Glassfish
Jonas
Porque usar Java

Multiplataforma
Madurez
Distribuido
Seguro: PKI, Certificacin digital..
Abierto: Mltiples O.S, Bases de Datos, directorios de

seguridad, etc.
Mltiples frameworks de solucin para (1) problema
AJAX-RIA - MDA
SOA - Web services Rest & SOAP Rest services
BPM
Fcil Transicin a ambientes soportados por fabricantes.
Porque usar Java ?

Plataforma preferida para la creacin de Open
Source y productos comerciales robusto

OpenJDK,
http://java-source.net/
Quien usa Java en proyectos Open source ?

Google
Yahoo
Nasa
Departamento de Defensa U.S.A.
Quien usa Java en proyectos Open source ?

.
Algunos Proyectos Open Source orientados a Negocio

Ofimatica: Integracin Natural con Open Office
ERP & CRM: Adempiere, Open Bravo
CMS: Alfresco, Jahia
Geospacial: Geoserver, uDig
Portals: Liferay
BPM: JBPM, Intalio.
DataBases: Apache Derby
Business Inteligence & Data
Pentaho
Mercado Laboral y Certificaciones

SCJP Sun Certified Java Programmer
SCJD Sun Certified Java Developer
SCWCD - Sun Certified Web Component
Developer
SCBCD Sun Certified Business component
Developer
SCEA Sun Certified Enterprise Architect for Java
Errores comunes de Percepcin vs. Realidad

Comparar Java con lenguajes de escritorio
Java son solo Applets (en los 90s ?)
Java es complicado
Java es Lento
Es lento desarrollar con Java
Java es costoso
Entrenamiento es Costoso
Es java para todas las soluciones?
Candidato Natural para el seguimiento de
metodologas formales y giles.
Construye sobre arena sobre roca.

Entrenamiento
Certificado por SUN Microsystems a nivel Internacional
Anlisis y Diseo Orientado a Objetos con UML
Java para Desktop y Bases de Datos
Java para Web
Java empresarial
Arquitectura y Patrones.
Diplomado en Fundacin de Egresados

Frameworks de ltima Generacin : JSF, JPA, etc.
Java para Mviles
Groovy & Grails (Orientado a Max. Productividad)

Cobit
Gobierno
Estratgico
ISO 38500
Gobierno
TOGAF
PMI
Proyectos
Operativo
CMMI
Software
SOA
Integracin
Conectividad
ISO 27001
Seguridad
Arquitectura
Empresarial
ITIL
Gestin del
Servicio
Tcnico
Infraestructura
Redes : Cisco,
RDBMS Oracle,
etc.
Java
Enterprise
Arquitectura
Tcnica
Elementos Clave para Gestin de

Infraestructura
Elementos Clave para Gestin

de Infraestructura e Integracin
Infraestructura
Gestin de Red con Cisco
Seguridad
Motores de Bases de datos Diversos.
Sistemas Operativos
Middleware

Cobit
Gobierno
Estratgico
ISO 38500
Gobierno
TOGAF
PMI
Proyectos
Operativo
CMMI
Software
SOA /BPM
Integracin
Conectividad
ISO 27002
Seguridad
Arquitectura
Empresarial
ITIL
Gestin del
Servicio
Tcnico
Infraestructura
Redes : Cisco,
RDBMS Oracle,
etc.
Java
Enterprise
Arquitectura
Tcnica
De Gobierno TI a la Prctica
Preguntas ?
Ing. Pedro Rozo

DeGobiernoTIPractica PDF

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

DeGobiernoTIPractica PDF

Caricato da

Copyright:

Formati disponibili

De Gobierno TI a la Prctica

Ing. Pedro Rozo

traduce en US$ 600 billones anuales a nivel global

TI no generan retorno para la organizacin

porcentaje son cuestionables o representan fracasos.

La necesidad del aseguramiento del valor de TI, la administracin de los riesgos

El valor, el riesgo y el control constituyen la esencia del gobierno de TI.

Cada organizacin necesita personalizar y adaptar el uso de estndares y mejores

Las empresas estn sacrificando productividad y competitividad cuando no se tienen

Los ejecutivos de IT necesitan una forma:

El gobierno de TI es responsabilidad de los ejecutivos, del consejo de directores y

Ms an, el gobierno de TI integra e institucionaliza las buenas prcticas para

Las organizaciones deben satisfacer la calidad, los requerimientos fiduciarios y de

Alineacin de Frameworks con Prioridades de IT

IT Como un gran Edificio

nivel para Gobierno en TI (que debe ser hecho)

CMMI (9001:2000 Quality Management SystemsRequirements, Capability

El Gobierno de TI se define como

Parte integral del Gobierno Corporativo,

La necesidad del Gobierno de TI

Monitorear los resultados

negocio, puede resultar costosa e inoperante, por lo cual se

Las mejores practicas en TI se enfocan en:

practicas, para que todos mundo sepa que hacer y como

Cmo lograr el xito ?

novedad, de hecho formalizan practicas que ya son parte del da a

mejores prcticas y soluciones probadas;

brinda adems de los

Control Objectives for Information and

es propiedad del ITGI (IT Governance Institute)

CobiT sus antecedentes

La comunidad de profesionales relacionados con TI

a travs de ISACA mostr preocupacin por la falta

COBIT: Un Marco de referencia de Controles para TI

Evolucin del CobiT en el tiempo

Investigar, desarrollar, publicar y promover un

CobiT sus caractersticas

Ejecutivos & Juntas

Marco COBIT y ValIT

CobiT sus Productos

CobiT Online Para todos los usuarios

CobiT Quick Start Pequeas y medianas empresas

CobiT Security Baseline Responsables de la seguridad Informtica

Objetivos de Control para Sarbanes-Oxley Responsables del

Objetivos de Control para Basilea II Responsables del control

Enterprise Value. Governance of IT Investments Responsables de

Mapeos o cruces con estndares y mejores prcticas

COBIT otros productos

CobiT Online Para todos los usuarios

CobiT Quick Start Pequeas y medianas empresas

CobiT Security Baseline Responsables de la seguridad

Objetivos de Control para Sarbanes-Oxley Responsables del

Objetivos de Control para Basilea II Responsables del control

Enterprise Value. Governance of IT Investments Responsables

COBIT Un framework de Alto Nivel

COBIT Armonizacin de Estndares

Mejora su alineacin con los

COBIT y las mejores

Marco Coherente del Gobierno de TI

Control Objectives for Information and related

con el Buen Gobierno Corporativo de TI

Fija estndares de buena gestin de los procesos

empresariales relacionados con los servicios de