De Gobierno TI a la Práctica
Ing. Pedro RozoCEO - SmartJSP Solutions para Canadá & Colombia
http://www.smartjsp.com
Consultor en Integración, Arquitectura SOA, BPM , Middleware IBM y Open Source
Ing. Sistemas Universidad Distrital
Sun Certified Enterprise Architect for Java Enterprise Edition
MBA Dirección de Empresas – Universidad San Pablo - España
Conferencistas
Ing. Pedro Rozo
� CEO - SmartJSP Solutions para Canadá & Colombia
� http://www.smartjsp.com� Consultor en Integración, Arquitectura SOA, BPM � Consultor en Integración, Arquitectura SOA, BPM , Middleware IBM y Open Source
� Ing. Sistemas Universidad Distrital� Sun Certified Enterprise Architect for Java Enterprise Edition
� MBA Dirección de Empresas – Universidad San Pablo – España
Agenda1. Introducción – Gobierno en TI2. IT Como un Edificio de Entornos Abiertos3. COBIT / ISO 38500 – Frameworks para Gobierno de TI4. ITIL – Gestión del Servicio5. PMI – Gestión de Proyectos6. Arquitectura Empresarial – Caso TOGAF 7. Modelos de Construcción de software: Caso CMMI8. Metodologías alternas para Construcción de Software9. Arquitecturas de Software de Referencia: Caso SOA 10. Arquitecturas Técnicas abiertas: Caso Java Enterprise 11. Elementos adicionales para Gestión de Infraestructura12. Como integrar los componentes ?13. Preguntas & Respuestas
Asistentes� Empresas con más de 100 empleados� Empresas con más de 1000 empleados� Gobierno de TI y frameworks para control y gestión de
proyectos en TI.Mejores prácticas para Soluciones robustas en TI� Mejores prácticas para Soluciones robustas en TI
� Desarrollo “in-house” vs. Tercerización� Arquitecturas abiertas y escalabilidad de sus áreas de TI� Soluciones :
� Escalables, facil mantenimiento, extensibles, trazabilidadde prioridades de Negocio – elementos de TI
Enfoque
� Una visión ejecutiva de los estándares y mejorasprácticas en la gestión de TI
� Un recorrido integral y ágil mostrando fortalezas ydebilidades, que permitan desarrollar criterios,prioridades y aplicabilidad de estos modelos en elprioridades y aplicabilidad de estos modelos en elentorno de TI real.
� Un espacio interactivo para discernir que tan reales su aplicabilidad según variables como tamaño,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
(Publicación Gartner Group, 2002)
� Los CIOs reportan que el 40% de las inversiones en TI no generan retorno para la organizaciónTI no generan retorno para la organización
(2004 IBM Survey, Fortune 1000 CIOs)
� 29% de los proyectos resultan exitosos y el restante porcentaje son cuestionables o representan fracasos.
(2004 Standish Report)
Introducción� La necesidad del aseguramiento del valor de TI, la administración de los riesgos
asociados a TI, así como el incremento de requerimientos para controlar la información,se entienden ahora como elementos clave del Gobierno Corporativo.
� El valor, el riesgo y el control constituyen la esencia del gobierno de TI.
� Cada organización necesita personalizar y adaptar el uso de estándares y mejorespracticas que se adapten a sus requerimientos específicos.
� Las empresas están sacrificando productividad y competitividad cuando no se tienenestrategias 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 yconsta de liderazgo, estructuras y procesos organizacionales que garantizan que TI enla empresa sostiene y extiende las estrategias y objetivos organizacionales.
� Más aún, el gobierno de TI integra e institucionaliza las buenas prácticas paragarantizar que TI en la empresa soporta los objetivos del neg ocio . De estamanera, el gobierno de TI facilita que la empresa aproveche al máximo suinformación, maximizando así los beneficios, capitalizan do las oportunidades yganando ventajas competitivas . Brinda un marco de Referencia Integrado para laadministración de riesgos, así como a marcos compatibles similares.administración de riesgos, así como a marcos compatibles similares.
� Las organizaciones deben satisfacer la calidad, los requerimientos fiduciarios y deseguridad de su información, así como de todos sus activos. La dirección tambiéndebe optimizar el uso de los recursos disponibles de TI, incluyen doaplicaciones, información, infraestructura y personas . Para descargar estasresponsabilidades, así como para lograr sus objetivos, la dirección debe entender elestatus de su arquitectura empresarial para TI y decidir qué tipo de gobierno y decontrol debe aplicar
Alineación de Frameworks con Prioridades de IT
Estratégico
Operativo
CobitGobierno
PMIProyectos
ISO 38500Gobierno
TOGAFArquitecturaEmpresarial
Operativo
Técnico
ITILGestión del
Servicio
CMMISoftware
SOAIntegración
ConectividadJava
Enterprise Arquitectura
TécnicaInfraestructura
Redes : Cisco, RDBMS – Oracle,
etc.
ISO 27001Seguridad
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 gestión de servicios.
� ISO/IEC 27001:2007 – framework para la gestión de seguridad informática
PMI -Project management Institute – y PRINCE2 –� PMI -Project management Institute – y PRINCE2 –Gerencia de Proyectos
� CMMI – (9001:2000 Quality Management Systems—Requirements, Capability Maturity Model® Integration (CMMI)) (RUP, Agile, XP) Gestión de Software
� Arquitectura Empresarial – Frameworks (TOGAF)� Arquitecturas Abiertas Técnicas de Referencia – Casos SOA -Java Enterprise
� Infraestructura – AbiertaSistemas Operativos, Bases de Datos, Elementos de Red
� Plataformas abiertas para creación de soluciones de software.
COBITControl Objectives for Information and
related Technologies
El Gobierno de TI es:El Gobierno de TI es:
•• Responsabilidad del Board de Directores Responsabilidad del Board de Directores y de los directivos y de los directivos
•• Parte integral del Gobierno Corporativo, Parte integral del Gobierno Corporativo, que consiste en el liderazgo, estructuras que consiste en el liderazgo, estructuras organizacionales y procesos que organizacionales y procesos que aseguran que el TI de la empresa aseguran que el TI de la empresa
El Gobierno de TI se define como El Gobierno de TI se define como
aseguran que el TI de la empresa aseguran que el TI de la empresa soportará y complementará las soportará y complementará las estrategias y objetivos de la empresaestrategias y objetivos de la empresa
RESOURCERESOURCEMANAGEMENTMANAGEMENT
www.itgi.orgwww.itgi.orgwww.itgi.orgwww.itgi.org
AdministracionAdministracionDe RecursosDe Recursos
www.itgi.orgwww.itgi.orgwww.itgi.orgwww.itgi.org
La necesidad del Gobierno de TILa necesidad del Gobierno de TIEjecutar la Ejecutar la
propuesta de propuesta de valor a través valor a través del ciclo de del ciclo de
entregaentrega
Alinearse con el negocio y proveer
soluciones colaborativas Proteger los activos,
recuperarse de los desastres y cumplir
RESOURCERESOURCEMANAGEMENTMANAGEMENT
www.itgi.orgwww.itgi.orgwww.itgi.orgwww.itgi.org
las leyes, regulaciones y
contratos
Optimizar el desarrollo Optimizar el desarrollo y uso de los recursos y uso de los recursos
disponiblesdisponiblesMonitorear los resultados Monitorear los resultados
para aplicar acciones para aplicar acciones correctivascorrectivas
AdministracionAdministracionDe RecursosDe Recursos
www.itgi.orgwww.itgi.org
Aspectos Prácticos
� La implementación de estas mejores practicas sin un foco en elnegocio, puede resultar costosa e inoperante, por lo cual serequiere marcar un estrategia clara que defina una carta denavegación clara para las áreas implicadas.
� Las mejores practicas en TI se enfocan en:
Mejor gestión de TI� Mejor gestión de TI� Mejor gobierno de actividades TI� Efectiva gestión de frameworks de políticas, 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 ycumplimiento de regulaciones.
Cómo lograr el Éxito ?
� La implementación real de estas prácticas no suena grannovedad, de hecho formalizan practicas que ya son parte del día adía de las organizaciones, pero organizadas de una forma lógica yalienadas ó “coordinadas” con el objetivo del negocio, permitenmejorar los aspectos ya mencionados anteriormente en laorganización de IT.
� La utilización extensiva y coordinada de estándares abiertos,mejores prácticas y soluciones probadas; brinda además de losbeneficios ya descritos anteriormente, una clara carta denavegación donde se definen criterios de flexibilidad tecnológica,fácil reutilización, reemplazo y gestión de roles, recursos y/oaplicaciones.
TM
Control Objectives for Information and related Technologies
TM CoBiT es propiedad del ITGI (IT Governance Institute)
CobiTTM … sus antecedentes
� La comunidad de profesionales relacionados con TI a través de ISACA mostró preocupación por la falta de una guía estándar sobre control en TI, que sirviera para diferentes grupos de interés
� La ISACF, como órgano que agrupa a profesionales � La ISACF, como órgano que agrupa a profesionales de distintas áreas de actuación interesadas en el control de TI se dio a la tarea de desarrollar un cuerpo común de conocimientos sobre la materia
ISACF Hoy ITGI
17
Gobierno
Administración /Gerencia
Evo
lució
n
COBIT: Un Marco de referencia de Controles para TI
Evolución del CobiT en el tiempo
COBIT 5 Gestión de la Información
COBIT 4
2005
COBIT 3
2000
COBIT 2
Control
1998
COBIT 1
Auditoría
1996
Evo
lució
n
CobiTTM … su misiónInvestigar, 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,
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, las empresas, gerentes de negocios, profesionales de TI y de Aseguramiento.las empresas, gerentes de negocios, profesionales de TI y de Aseguramiento.
19
CobiTTM … sus características� Orientación al negocio� Alineación con estándares y regulaciones “de
jure” y “de facto” � Basado en una revisión critica de tareas y
actividades en tecnología de información.
� Orientación al negocio� Alineación con estándares y regulaciones “de
jure” y “de facto” � Basado en una revisión critica de tareas y
actividades en tecnología de información.actividades en tecnología de información.� Alineamiento con estándares de control y
auditoría: COSO, IFAC, IIA, ISACA, AICPA
actividades en tecnología de información.� Alineamiento con estándares de control y
auditoría: COSO, IFAC, IIA, ISACA, AICPA
20
COBIT:Diagrama de Contenido
PracticesResponsibilities
wPerformance measures
wCritical success factors
wMaturity models
PracticasResponsabilidades
Ejecutivos & Juntas
wMediciones de desempeño
wBenchmarkingBenchmarking
wModelos de Madurez
Directrices Gerenciales
Reseña Ejecutiva
21
Business and Technology ManagementBusiness and Technology Management
wMaturity models
Audit, control and security profesional
ControlObjectives
AuditGuidelines Guide
Control Framework ?Control Framework ? Control Framework ?Control Framework ?
Gestión de Negocios y Tecnología
wModelos de Madurez
Profesionales en Gobierno, auditoría, control y seguridad
¿Cómo evaluamos ¿Qué es el Marco
de Gobierno de TI?¿Cómo ImImplementamos el
Gobierno de TI?El Gobierno de TI?
Marco COBIT y ValIT
Objetivos de Control
Prácticas clave de
Administracion
Guía de Implementacion de IT Governance
Guía de Aseguramiento
De TIDe TI
Practicas de
Control CobiT
Practicas de
Control CobiT
CobiTTM … sus Productos� CobiT Online � Para todos los usuarios
� CobiT Quick Start � Pequeñas y medianas empresas
� CobiT Security Baseline � Responsables de la seguridad Informática y auditores
� Objetivos de Control para Sarbanes-Oxley � Responsables del control Interno, auditores
22
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 estándares y mejores prácticas
COBIT … otros productos� CobiT Online � Para todos los usuarios
� CobiT Quick Start � Pequeñas y medianas empresas
� CobiT Security Baseline � Responsables de la seguridad Informática y auditores
Objetivos de Control para Sarbanes-Oxley � Responsables del � 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
23
OBJETIVOS DELOBJETIVOS DEL
NEGOCIONEGOCIO
OBJETIVOS TIOBJETIVOS TI
PROCESOS TIPROCESOS TI
InformaciónInformaciónRequerimientosRequerimientosInterelacion de Interelacion de Componentes Componentes
de CobiTde CobiT
ACTIVIDADESACTIVIDADES
CLAVESCLAVESPRUEBAS DE CONTROLES
RESULTANTES
RESPONSABILIDAD Y RENDICION DE CUENTAS
INDICADORES
DE DESEMPEÑO
MEDIDAS
RESULTANTES
MODELOS
DE MADUREZ
Par
a P
ara
resu
ltado
sre
sulta
dos
Basado Basado enen
OBJETIVOS DEOBJETIVOS DE
CONTROLCONTROL
PRACTICAS
DE CONTROL
PRUEBAS DEDISEÑO DE
CONTROLES
PROCESOS PROCESOS
DE NEGOCIODE NEGOCIO
PROCESOS PROCESOS
DE NEGOCIODE NEGOCIO
INFORMACIONINFORMACIONINFORMACIONINFORMACION
Efectividad
Eficiencia
Confidencialidad
Integridad
Disponibilidad
Cumplimiento
confiabilidad
OBJETIVOS DELOBJETIVOS DELGOBIERNOGOBIERNO
OBJETIVOS DELOBJETIVOS DELGOBIERNOGOBIERNO
Requerimiento Requerimiento
del negociodel negocioCobiTCobiT
RECURSOSRECURSOSPARA TIPARA TI
RECURSOSRECURSOSPARA TIPARA TI
Información
sistemas de aplicación
Infraestructura
personas
PLANEAR Y PLANEAR Y
ORGANIZARORGANIZAR
PLANEAR Y PLANEAR Y
ORGANIZARORGANIZAR
ADQUIRIR EADQUIRIR E
IMPLEMENTARIMPLEMENTAR
ADQUIRIR EADQUIRIR E
IMPLEMENTARIMPLEMENTARENTREGAR Y ENTREGAR Y
SOPORTARSOPORTAR
ENTREGAR Y ENTREGAR Y
SOPORTARSOPORTAR
MONITOREAR YMONITOREAR Y
EVALUAREVALUAR
MONITOREAR YMONITOREAR Y
EVALUAREVALUAR
COBIT – Un framework de Alto Nivel
COBIT – Armonización de Estándares
Armoniza practicas y estándares como ITIL, ISO 27001 e ISO 27002 y PMI (PMBOOK):
Mejora su alineación con los
27001/2
Mejora su alineación con los objetivos del negocioCubriendo el espectro total de actividades relacionadas con IT.
CCOBIOBITT
COSOCOSO
COBIT y las mejores COBIT y las mejores Prácticas Prácticas
ISO 9000ISO 9000
ISO 2700XISO 2700X
ITILITILQuéQué CómoCómo
CoberturaCobertura
El Cubo de CobiT
29
Corporate Governance for IT
ISO/IEC 38500:2008
Corporate Governance for IT
Marco Coherente del Gobierno de TI
ISO/IEC 38500
AdministracionAdministracionDe RecursosDe Recursos
www.itgi.orgwww.itgi.orgwww.itgi.orgwww.itgi.org
Control Objectives for Information and related Technologies
ISO/IEC 38500:2008� Directrices para la orientación de la Alta Dirección
con el Buen Gobierno Corporativo de TI
� Fija estándares de buena gestión de los procesos � Fija estándares de buena gestión de los procesos empresariales relacionados con los servicios de TI
ISO/IEC 38500:2008
Pro
pósi
tos Asegurar que si la norma se
sigue, las partes involucradas pueden confiar en el Gobierno
Corporativo de TI
Informar y orientar a los
Pro
pósi
tos
Informar y orientar a los directivos que controlan el uso
de las TI en la organización
Proporcionar una base para la evaluación objetiva de la
gestión de TI realizada por la alta dirección
ISO/IEC 38500:2008
Est
ánda
res
Prin
cipa
les
Establecimiento de Responsabilidades
Planeación estratégica
Adquisición adecuada de soluciones
Est
ánda
res
Prin
cipa
les
Adecuado desempeño
Garantía de cumplimiento legal
Comportamiento del factor humano
Establecimiento de Responsabilidades
� The Board Briefing on IT Governance and Unlocking Value: An Executive Primer on theCritical Role of IT Governance
� CoBiT (Monitor and Evaluate)� Val IT frameworks� IT Governance Implementation Guide Using
CoBiT and Val IT
Planeación Estratégica
� The Board Briefing on IT Governance and Unlocking Value: An Executive Primer on theCritical Role of IT Governance
� Val IT (Investment Management)� CoBiT (Plan and Organize)� CoBiT (Plan and Organize)� Identifying and Aligning Business Goals and IT
Goals� Understanding How Business Goals drive IT
Goals
Adquisición Adecuada de Soluciones
� Val IT� (Investment Management)� Portfolio Management
� CoBiT� CoBiT� Plan and Organize� Acquire and Implement� Monitor and Evaluate
Adecuado Desempeño
� CoBiT � Plan and Organize� Deliver and Support� Monitor and Evaluate
� Val IT� Business case to benefit realisation
� The IT Assurance Guide Using CoBiT
Garantía del Cumplimiento
� CoBiT � Plan and Organize� Monitor and Evaluate
� Val IT� 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� Monitor and Evaluate
� 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
ITILITILInformation Technology Infrastructure Library
ITIL� ITIL nace como un código de buenas prácticas
dirigidas a alcanzar esas metas mediante:� Un enfoque sistemático del servicio TI centrado
en los procesos y procedimientos. � El establecimiento de estrategias para la gestión � El establecimiento de estrategias para la gestión
operativa de la infraestructura TI.� La filosofía ITIL® impulsa la adopción de
procesos, de manera que puedan adaptarse para encajar tanto en organizaciones grandes como en pequeñas
ITIL
ITIL - Propósitos
� ITIL fue desarrollada al reconocer que las organizacionesdependen cada vez más de la Informática para alcanzar susobjetivos corporativos.
� Esta dependencia en aumento ha dado como resultado unanecesidad creciente de servicios informáticos de calidad que secorrespondan con los objetivos del negocio, y que satisfagan losrequisitos y las expectativas del cliente.
� El énfasis de ITIL pasó de estar sobre el desarrollo de las� El énfasis de ITIL pasó de estar sobre el desarrollo de lasaplicaciones TI a la gestión de servicios TI.
� La aplicación TI (a veces nombrada como un sistema deinformación) sólo contribuye a realizar los objetivos corporativossi el sistema está a disposición de los usuarios y, en caso defallos o modificaciones necesarias, es soportado por losprocesos de mantenimiento y operaciones
ITIL
Deliver IT Services Support IT Services
Managing
Manage theinfrastructure
The BusinessPerspective
ManagingApplications
ITIL
ITILISO20000/BS15000
CMM
SIX SIGMA
COBIT
ITIL
BusinessProcess Models
Governance
ITIL
ITIL
ITIL – Principales Elementos
� ITIL plantea el análisis de la administración de servicios de TI, con el objetivo de identificar las necesidades de los clientes y los distintos usuarios relacionados con los servicios de Tecnologías de Información y telecomunicaciones. Se han definido cinco elementos que interactúan entre si y se complementan:interactúan entre si y se complementan:
• Prestación de servicios de las TI.• Soporte de los servicios de las TI.• Perspectiva de negocios.• Administración de la infraestructura.• Administración de Aplicaciones.
ITIL – Propósito y Beneficios � El propósito de ITIL es asistir a las organizaciones en el
desarrollo de un “framework” o marco de referencia para la Gestión de Servicios de TI, el cual puede ser aplicado para todo tipo de organizaciones grandes o pequeñas, basada en los pilares de calidad, procesos y orientación al cliente.
� La Gestión 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.• Reducir costos.• Mejorar los servicios de TI a través del uso de procesos basados
en mejores prácticas.• Mejorar la satisfacción del los clientes a través de un modelo más
profesional de entrega de servicios.• Mejorar el uso de la experiencia.• Mejorar la entrega de servicios de terceras partes a través de las
recomendaciones de ITIL ® o especificaciones del standard BS 15000.
ITIL – por que implementar
ITIL - Motivadores
ITIL – Implementación Típica� Paso 1: Definir el alcance del modelo de referencia , Implica:
* Estructura de operación del área el nivel de detalle requerido para los registros y para los componentes de configuración asociados con los servicios.* Definir el esfuerzo y costo de implementación.
� Paso 2: Definición de la estructura de Servicios de TI y la CMDB, � Paso 2: Definición de la estructura de Servicios de TI y la CMDB, Implica:
* Definir el portafolio de servicios y SLAs:
Es necesaria la definición de la estructura de servicios, dominios deinfraestructura asociados y los acuerdos de nivel de servicio de acuerdocon la capacidad existente en los recursos (Humanos, experticia einfraestructura asociada). Este análisis presenta el impacto que puedeser alcanzado con los recursos disponibles por la empresa.
ITIL – Implementación Típica� Diseño inicial de la CMDB : (Configuration Managemen t
DataBase) es la Base de Datos de Gestión de la Configuración, un elemento clave para la correcta implantación de la estrategia de Business Service Management (BSM) porque sirve de enlace entre todos los componentes. La CMDB, tiene que tener una capacidad de evolución y será una columna verteblal para la implantación de los siguientes servicios
ITIL – Contenido de la CMDB� Inventario completo sobre todos los elementos hardware, software y su
ubicación, elementos con los que están conectados.� Todos los manuales de instalación, configuración, 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, * Teléfono de contacto * Nombre * Despacho
� Información de las incidencias * Criticidad * Fecha de alta * � Información de las incidencias * Criticidad * Fecha de alta * Fecha de cierre * Estado (abierta/no abierta) * Tipo
� Lista de servicios actualmente caídos o con problemas� Toda la información necesaria de KEOPS (hora de generación 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,…)
� Parámetros de actuación (en 2 idiomas) para niveles 1 y 2.� Historial de problemas, • Historial de incidencias • Historial de cambio
ITIL – Implementación Típica� Paso 3: Determinar los procesos operativos básicos:
Es clave la definición inicial del servicedesk y de los procesos que losoportan, así también 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 implantarITIL, la instalación de un Service Desk capaz de resolver con rapidez yeficacia los posibles problemas que aparezcan, se presenta como unoeficacia los posibles problemas que aparezcan, se presenta como unode los hitos de mayor relevancia para disponer de un buen servicio.
� Gestión de incidencias: La implantación tiene que constar de trespartes bien diferenciadas: el área de recepción o captación deincidencias, el área de apertura de incidencias y el área de resoluciónde incidencias. Además de ello se tendrá que definir los niveles queabarcara dicha gestión.
ITIL – Gestión de Incidencias
ITIL – Gestión de Problemas� Gestión de problemas : Las incidencias son el resultado de errores o
problemas con el sistema de soporte de las TIC. Un problema puede provocar múltiples incidencias, y es posible que el problema no se Diagnostique hasta que se produzcan una serie de incidencias relacionadas entre ellas.
ITIL – Gestión de Cambios� Gestión 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 implementación. - Revisar y cerrar RFC (peticiones de cambio
ITIL – Gestión de Configuraciones� Gestión de Configuraciones: Este proceso en una
empresa tiene que facilitar la integración de actividades de configuración a través de plataformas y tecnologías.
ITIL – Gestión de Versiones� Gestión de Versiones: Este proceso garantiza el correcto despliegue de
versiones, incluyendo la integración, el análisis y el almacenamiento de las mismas. En el momento de la implantación cumplirá con lo siguiente:
ITIL – Gestión de Niveles de Servicio (SLA) – (OLA)� Gestión de los Niveles de Servicio (SLM): El objetivo al implantar esta gestión es
mantener y mejorar la calidad de los servicios, a través de los acuerdos establecidos conel cliente, monitorizando y realizando los informes necesarios de las acciones quepueden provocar una pérdida del servicio.
� En la gestión de los niveles de servicio se generan los distintos acuerdos a nivel deservicio o SLAs (Service LevelAgreement) y acuerdos internos de servicio o OLAs(OperationalLevelAgreement) ya antes definidos en la implantación.
ITIL – Implementación Típica� Paso 4: Implantar los procesos tácticos
requeridos por la organización:
� Permiten desde el inicio poner en práctica el nivel de servicio y garantizar el cumplimiento de los de servicio y garantizar el cumplimiento de los acuerdos con clientes, establecidos en el paso 3 como SLM; además se implantaran las gestiones de disponibilidad, capacidad y continuidad.
ITIL – Gestión de la Disponibilidad� El objetivo primordial de la Gestión de la Disponibilidad es asegurar que
los servicios TI estén disponibles y funcionen correctamente siempreque los clientes y usuarios deseen hacer uso de ellos en el marco delos SLAs en vigor, la implantación debe garantizarlo
ITIL – Gestión de la Capacidad� El objetivo primordial de la Gestión de la Capacidad es poner a disposición
de clientes, usuarios y el propio departamento TI los recursos informáticosnecesarios para desempeñar de una manera eficiente sus tareas y todo ellosin incurrir en costos desproporcionados
ITIL – Gestión de la Continuidad� Gestión de la Continuidad de Servicios IT: Establecer políticas y
procedimientos que eviten, en la medida de lo posible, las perniciosasconsecuencias de un desastre o causa de fuerza mayor
ITIL – Implementación Típica – Paso 5� Paso 5: Construir los procesos alineados con la estrategia del negocio y con
la seguridad de la información.
� En esta etapa se implantara la gestión financiera y de seguridad.
� Gestión Financiera de los Servicios IT
ITIL – Gestión de la Seguridad� Gestión de la Seguridad
� Diseñar una política de seguridad, en colaboración con clientes y proveedores correctamente alineada con las necesidades del negocio.
� Asegurar el cumplimiento de los estándares de seguridad acordados.
� Minimizar los riesgos de seguridad que amenacen la continuidad del servicio
ITIL – Implementación Típica Pasos 6-9� Paso 6: Definir métricas de calidad de servicio y desempeño d e los procesos .
Estos indicadores proveen el mecanismo de seguimiento, mejora continua yplanificación, primordiales tanto hacia dentro del departamento como de cara a losusuarios
� Paso 7: Garantizar la calidad de la información en la CMDB:Mediante la definición de registros de información puntales y que permitan generarreportes de desempeño, así como formar la base para los procesos de auditoría ala información y controles de validación de datos en el cargue de los mismos
� Paso 8: Garantizar y monitorear la gestión de cambios.Este elemento es la base fundamental para disponer de procesos que generenauto-aprendizaje y mejoracontinua. Un aspecto clave para iradaptando los nuevosprocedimientos ycapacidades a la cambiante y dinámicarealidad de una empresamoderna.
� Paso 9: Entrenar al personal y hacer participes del proceso a l resto de laorganización.El éxito de la iniciativa dependerá en gran manera de la forma en que los nuevosprocedimientos se transformen una costumbre de trabajo, y que la alineación yparticipación del resto de la empresa en la definición y toma de decisiones se hayanhecho presentes
ITIL – Implementación Típica – Paso 10� Paso 10: Seleccionar una herramienta adecuada que permita gestionar
adecuadamente la información asociada con los procesos definidos Tiempo deplanificación para implantar ITIL
ITIL para PYMES ?� Normalmente, las pymes disponen de menos tiempo y menos
recursos para analizar los procesos empresariales eimplementar mejoras de servicio considerando que ITIL es unmarco flexible, y no una doctrina, y que su implementaciónresulta complicada incluso para las grandes organizaciones,¿cómo podrían las pymes obtener las mayores ventajas de ITIL?Normalmente, los recursos de las pymes son utilizados másNormalmente, los recursos de las pymes son utilizados másplenamente que los de las organizaciones mayores, por esopodrán aprovechar ITIL para mejorar la productividad.
� Por ejemplo, en una pyme las funciones de gerente del centrode servicios y responsable de cambios suelen estar unificadasen una misma persona. En las grandes organizaciones, estasresponsabilidades.
ITIL para PYMES
ITIL . Beneficios
ITIL – Niveles de EntrenamientoITIL tiene tres niveles de certificación:
a) Foundations o fundamentos : Provee el nivel de fundamentos de la gestión de servicios de TI y ayuda a familiarizarse con el lenguaje y las mejores prácticas de TI.
� b) Practitioner o practicante : Provee un nivel de � b) Practitioner o practicante : Provee un nivel de profundización en cada uno de los procesos de ITIL ® en todas las actividades. Es un nivel de especialización más 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 .
PMIGestión de Proyectos
¿Qué es el PMI?
Es una organización sin ánimo de lucro queagrupa cerca de 260.000 miembros en más de170 países con el fin de certificar a sus miembrospara la gestión y gerencia de proyectos.para la gestión y gerencia de proyectos.
Historia del PMI
� Fundado en 1.969 por cinco voluntarios en Atlanta.
� Cinco voluntarios fundaron la organización.� Cinco voluntarios fundaron la organización.
� Su primer simposio se realizó con 83 integrantes.
� Su actual sede se ubica en Pennsylvania.
¿Qué hace el PMI?
Entre sus principales objetivos se encuentranformular estándares profesionales, generarconocimiento a través de la investigación, ypromover la Gestión de Proyectos comopromover la Gestión de Proyectos comoprofesión a través de sus programas decertificación.
El PMI en el mundo
� El 70% de los miembros del PMI viven enAmérica del Norte, 61% residen enEstadosUnidos.
� Cerca de 40 mil miembrosresiden en Asia.
� Los miembros en Europaalcanzan los 30 mil.
� En Latinoamérica y el Caribe losmiembrosalcanzan los 10,700.
Certificaciones PMI
CAPM: es aquel que ha demostrado una basecomún de conocimientos y términos en el campode la gestión de proyectos. Se requieren 1,500de la gestión de proyectos. Se requieren 1,500horas de trabajo en un equipo de proyecto o 23horas de educación formal en gestión deproyectos para conseguir esta certificación.
Certificaciones PMI
PMP: el profesional ha experimentado unaeducación específica y requerimientos deexperiencia, ha aceptado ceñirse a un código deconducta profesional y ha pasado un examenconducta profesional y ha pasado un examendesignado para determinar y medir objetivamentesu conocimiento en gestión de proyectos.Adicionalmente, un PMP debe satisfacerrequerimientos de certificación continuos, de locontrario pierde la certificación.
Actividades del PMI
� Educación y adquisición del conocimiento.
� Desarrollo profesional y redes.
� Perfeccionamiento de carrera y estándaresprofesionales.
� Productos y servicios PMI.
PMI en ColombiaSu sede está ubicada en Santa Fe de Bogotá, ante
el se puede gestionar las certificacionesanteriormente mencionadas, la afiliación cuestaU$ 30 y la certificación U$ 405, su misión espromover los principios del PMI y apoyar a lospromover los principios del PMI y apoyar a losmiembros en el proceso de certificación.
Para más información remítase a:http://www.pmicolombia.org
PMBOK
El PMBOK es una publicación desarrollada por elPMI disponible en once idiomas, consta de 392páginas y consiste en una colección de procesosy áreas de conocimientos, más conocidas comoy áreas de conocimientos, más conocidas comomejores prácticas, el libro es reconocidomundialmente como un estándar (IEEE Std 1490-2003) que provee los lineamientos para lagestión de proyectos.
¿Qué propone el PMBOK?El PMBOK propone cinco pasos básicos siendo
aplicables a proyectos, programas y procesos:
1. Inicio.2. Planificación.2. Planificación.3. Ejecución.4. Control y monitoreo.5. Cierre.
¿Qué propone el PMBOK?Así mismo se propone nueve áreas de conocimiento
mencionadas en el PMBOK, estas son gestión en:1. Integración.2. Alcance.3. Tiempo.4. Calidad.5. Costos.6. Riesgos.7. Recursos Humanos.8. Comunicación9. Logística.
Gerencia de Proyectos
� La gerencia de proyectos es la aplicación de conocimientos,conocimientos, habilidades,habilidades,herramientasherramientas yy técnicastécnicas a las actividadesactividades de un proyecto con el fin decumplircumplir concon loslos requerimientosrequerimientos del proyecto.
®http://www.pmi.org
cumplircumplir concon loslos requerimientosrequerimientos 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).
Gerencia de Proyectos
Calidad
TRIPLE RESTRICCIONContrato con multas por inclumplimiento.
R E Q U E R I M I E N T O SPROYECTOPRODUCTO
- Seguridad - Performance- Impacto Ambiente - Funcionalidad- Ubicación - Operatividad- etc. - etc.
NecesidadRelacionado con
el Negocio
ObjetivosRelacionado con
metas del Proyecto
AlcanceRelacionado con
el Trabajo
Project Charter Enunciado PreliminarLinea Base el Alcance- Enunciado del Alcance.- WBS- Diccionario- Diccionario
Gerencia de Proyectos
Entradas delProyecto
SponsorPatrocinador
ProductosEntregables del
Proyecto
UsuariosFinales
Activode los
Procesos
Registrosdel
Proyecto.
Limites del Proyecto
Firma de Acta
Constitución
Entregade
ProductosConstitución 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
Gerencia de Proyectos
Gestión de la Integración del Proyecto
Gestíón delAlcance
Gestíón delTiempo
Gestíón delCosto
Gestíón dela calidad
Integración de la Gerencia de Proyectos a travésdel Ciclo de vida del Proyecto para lograr la
Satisfacción de Stakeholders
Gestíón de RRHH
Gestíón deComunicación
Gestíón delRiesgo
Gestíón delAdquisiciones
GESTIONAREL PROYECTO
PARA
PRODUCIRENTREGABLES
PROYECTOEXITOSO
- PRODUCTOSENTREGABLESRESULTADO DEELABORACION
- ACTIVOS DELOS PROCESOSRESULTADO DELA GESTIÓN
PROBLEMAS Y/O OPORTUNIDADES
- Market Demand- Business Need- Customer Request- Tech. Advance.- Legal requirement.- Social need.
Areas Centrales: Objetivos o Restricciones.
Areas Facilitadoras :Interactivo y Adaptable
Las percepción 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 implementación para un proyecto específico.
Gestión de la Integración del Proyecto
ACTA DE CONSTITUCION- Autorización formal de la organización para uso de recursos.- Reconocimiento y compromiso de la organización.- Asigna al gerente.- Autoriza fases.
ALCANCE PRELIMINAR- Define los objetivos del proyecto. Trabajo a realizar y entregables.- Define características y límites del proyecto y sus productos.- Define métodos de aceptación y control del alcance.
Declaración del Trabajo (SOW)
Finalidad / Justificación
Descripción del Producto
Restricciones / Asunciones
Sponsor / Jefe Proyecto
Misión
Enunciado de Alcance, Costo, Tiempos/ Límites, Hitos
Equipo del Proyecto. Organización.
Involucrados / Influencias
Entregables producto y proyecto
Restricciones / Asunciones
Riesgos
Método Aceptación / Control Alcance
. . . Desea la Empresa . . . . . Compromiso del Gerente . .
Requisitos de Configuracion
Gestión de la Integración del ProyectoFoco: Lograr EntregablesAcciones necesarias para ejecutar el plan de Gestión del proyecto para cumplir con el trabajadefinido en el enunciando del alcance del proyecto.Algunas de las acciones son :- Seleccionar proveedores:- Adm. Recursos materiales y equipos.- Implementare los estándares y métodos propuestos.- Crear, controlar y verificar entregables.- Adm. Acciones relacionadas con
Foco: Integrar PlanesAcciones necesarias para definir, integrar y coordinar todos los planes subsidiarios en el Plan de Gestión 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 gestión de la configuración será desarrollada.Define estrategias de comunicación con los stakeholders.
- Adm. Acciones relacionadas con el riesgo.- Adaptar cambios aprobados.- Establecer y manejar comunicación del proyecto.- Recolectar y documentar lecciones aprendidas.- Implementar acciones aprobadas preventivas, correctivas y de reparación de defectos.
(*) Algunas Definiciones :- Acciones Correctiva.- Relación con el proyecto para asegurar calidad en producto, alcance, costo, tiempo.
-Solicitud de Cambios.- Modificaciones de documentos y acuerdos.- Reparación de Defectos.- Modificación al producto.
Gestión de la Integración del ProyectoConjunto de actividades, que con la ayuda del Sistema de Gestión de la Configuración y el Sistema de Control de Cambios, permiten centralizar la gestión de cambio del proyecto. Sus principales actividades son :
- Identifica necesidad de cambio y realiza la revisión y aprobación de cambios solicitados.- Revisa y aprueba recomendaciones de acciones preventivas y correctivas.- Actualiza Planes de Alcance, Costo, Tiempo, Calidad y otros
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.
Costo, Tiempo, Calidad y otros donde impacta el cambio.- Documenta el impacto del cambio.
- Sistema de Control de Cambios, es parte de la gestión de configuración que define como entregables y documentos son controlados, cambiados y aprobados.
Gestión de la Configuración:- identifica características funcionales y físicas de los productos.- Controla cambios de dichas características.- Registra y reporta cada cambio y su estado de implementación.- Audita productos y componentes para verificar la conformidad de los requerimientos.
QualityReparación de Defectos
Gestión de la Integración del Proyecto
Incluye la finalización de todas las actividades realizadas a través de los otros procesos, y transfiere el resultado completo o parcial del proyecto.
Cierre Administrativo :- Verificación, Documentación y entrega del producto final del proyecto, previa aprobación formal del cliente.- Investiga y Documenta acciones tomadas, y elabora las lecciones aprendidas.elabora las lecciones aprendidas.- Compila y archiva la documentación 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 EmpresarialArquitectura Empresarial
Arquitectura Empresarial� Definición: Una descripción formal de unsistema, o un plan detallado de un sistema anivel de componentes para guiar suimplementación.
� La estructura de componentes, sus inter-relaciones y los principios y guías querelaciones y los principios y guías quegobiernan su diseño y evolución en el tiempo
� Prioridades que direcciona: � Control� Eficiencia Operacional� Costo
Framework de Arquitectura empresarial� Un framework de arquitectura es un conjuntode herramientas que puede ser utilizado paradesarrollar un amplio espectro de diversasarquitecturas. Este framework debe:� Describir una metodología para la definición deun sistema de información en términos de unconjunto de bloques constitutivos (buildingconjunto de bloques constitutivos (buildingblocks, en inglés) que encajen entre síadecuadamente.
� Contener un conjunto de herramientas� Proveer un vocabulario común� Incluir una lista de estándares recomendados� Incluir una lista de productos que son idóneospara la implementación de los bloquesconstitutivos
TOGAFThe Open Group Architecture
FrameworkFramework
TOGAF –The Open Group Architecture Framework-
Framework para Arquitectura Empresarial
� Proporciona un enfoque para el diseño, planificación,implementación y gobierno de una arquitecturaempresarial de información. Esta arquitectura esmodelada por lo general con cuatro niveles odimensiones: Negocios, Tecnología (TI), Datos yAplicaciones. Cuenta con un conjunto de arquitecturasbase que buscan facilitarle al equipo de arquitectosdefinir el estado actual y futuro de la arquitectura.definir el estado actual y futuro de la arquitectura.
� It is a complete package for creating an enterprisearchitecture. It is based on a decade of refinements tothe U.S. Department of Defense Technical ArchitectureFor Information Management (TAFIM). TOGAF, now atversion 8, provides both a method and the structurefor developing an enterprise architecture.
TOGAF - Ventajas� Mejora en el manejo de red, facilidad del sistema einteroperabilidad
� Mejora en la habilidad para direccionar temascríticos como seguridad
� Facilidad para actualizar e intercambiarcomponentes de sistemas.
� Incrementar la portabilidad de las aplicaciones� Reducir la complejidad en la infraestructura de IT� Reducir la complejidad en la infraestructura de IT� Retorno máximo sobre la inversión existente� Flexibilidad para construir, comprar o externalizarsoluciones de IT
� Reducir el riesgo total en las nuevas inversiones yel costo de lasapropiaciones 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 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 Governanceand Architecture Change Management. The idea is to build your system instages, completing one cycle and embarking on the process again to improvewhat 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 seabordará desde el punto de vista de arquitectura. Se trata de definirfundamentalmente el alcance del proyecto y las distintas partes involucradas(consiguiendo su aprobación). Desde un punto de vista muy genérico, sedocumenta el estado actual y el estado futuro.
� Phase B: Business Architecture
� Se trata de determinar con profundidad los diferentes aspectos de negocioinvolucrados en el proyecto. Se abordan los mapas estratégicos, las políticasinvolucrados en el proyecto. Se abordan los mapas estratégicos, las políticascorporativas, los objetivos de negocio, se realiza la descomposición funcional,los modelos organizativos y se documentan los procesos, tanto los estándarescomo los que afectan al core-business de la compañía. No sólo se trata demodelar el estado actual, sino también el estado futuro, de ahí que los mapasestratégicos sean un aspecto fundamental, pues determinarán los requisitosde futuro. Como fruto de este trabajo, se obtiene un Gap Analisys que permitever cuán de lejos se encuentra el objetivo a conseguir con respecto a lo queexiste 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. Conrespecto a las aplicaciones, se traza el mapa de las existentes (tanto de lasaplicaciones pertenecientes a terceras partes, como las aplicaciones hechas a medida),las interfaces existentes entre las ellas y los enlaces (tanto internos como externos a lacompañía). Eso describe el estado actual, pero también se proyecta el estado futurocon una aproximación a lo que será el Enterprise Service Bus.
� Phase D: Technology Architecture
� Es aquí donde se desarrolla la arquitectura tecnológica que implementa tanto el negociocomo las arquitecturas de información que se han elaborado durante las fases B y C. Alcomo las arquitecturas de información que se han elaborado durante las fases B y C. Aligual que sucedía con anteriores fases, se crea un baseline de la tecnología actual,analizando el modelo de hardware, modelo de red (LAN y WAN), el software deinfraestructura existente (sistema operativo, servidor de aplicaciones, servidor de datos,etc.), etc. A partir de ahí, se crea el estado futuro y se proyecta la arquitecturatecnológica más óptima. Con todo eso en la mano, se realiza el correspondiente GapAnalisys que nos permitirá ver lo lejos que se encuentra nuestro objetivo de lo queexiste en la actualidad.
TOGAF – Fases del ADM
� Phase E: Opportunities and Solutions
� Nos encontramos ante la fase de análisis probablemente más importante detodo el proceso. Con todas las arquitecturas actuales y futuras definidas enlas anteriores fases, ahora corresponde analizarlas y ver cuáles sonexactamente los bloques que permitirán construir la nueva arquitectura,cuáles se podrán reutilizar, cuáles será necesario reemplazar y cuáles setendrán que proporcionar, bien mediante adquisición de los mismos (en casode procesos estándares) y mediante el desarrollo a medida (para procesosde procesos estándares) y mediante el desarrollo a medida (para procesoscore-business).
� Phase F: Migration Planning
� A lo largo de la fase E se ha establecido el conjunto de bloques que daránlugar a la arquitectura a implementar. Lógicamente, no todos seimplementarán al mismo tiempo, pues eso supondría un tremendo caos. Portanto, es necesario priorizar y, por tanto, establecer el orden en el que serealizará la implantación de todo lo acordado. Por tanto, se establecerá el plande migración hacia la nueva arquitectura.
TOGAF – Fases del ADM� Phase G: Implementation Governance
� Durante esta fase es el momento de crear las directrices que asegurarán que tanto losdesarrollos que se encuentran dentro del ámbito de la arquitectura, como aquellos que seencuentran fuera de ella, se ajustan exactamente a la arquitectura destino que sepretende crear. Además de todo el modelo de Governance, se establecen los principiosarquitectónicos, los principios de seguridad, la metodología que se utilizará en todosaquellos proyectos que se desarrollen, etc. Al final, se trata de conseguir un contrato dearquitectura, que sea firmado por todas las partes que vayan a trabajar en los proyectosde desarrollo.
� Phase H: Architecture Change Management
� En un entorno tan dinámico como el de un negocio, es prácticamente imposible que unaarquitectura estática dé respuesta a todas las necesidades que se irán generando.Precisamente gestionar la dinámica de la arquitectura es el objetivo de esta fase. A lolargo de la fase H se monitorizan las propuestas de cambio y se determinan si se procedey cómo se procede a incorporarlas. Dependiendo de la naturaleza de los cambios seránecesario traerlos a esta fase o no. Por ejemplo, una simplificación de un procesonormalmente puede ser gestionada mediante una buena política de gestión de cambios yno es necesario traer ese cambio a esta fase. Cambios como la modificación deestándares o nuevas tecnologías, pueden requerir una rearquitectura parcial, que seconsigue accediendo a la fase D. Otros cambios más profundos, como por ejemplo, lamodificación severa de procesos de negocio, sí requieren de volver a comenzar desde lafase A.
TOGAF The Open Group Architecture
FrameworkFramework
� 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, theTOGAF Enterprise Continuum provides a base on which you can build your own enterprisearchitecture.
� Enterprise Continuum se subdivide a su vez en: Architecture Continuum y SolutionsContinuum. El primero aloja los modelos, patrones, etc. que se producen. El segundocontiene la forma en la que se han obtenido esos modelos, patrones, etc. Dado lopragmático del modelo, se comienza por lo más general, pero también se aborda lo másespecífico, 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 themodels and patterns in the Architecture Continuum are to be achieved). Each of thesecontinuums runs from the general to the specific. This means the Architecture Continuummodels and patterns in the Architecture Continuum are to be achieved). Each of thesecontinuums runs from the general to the specific. This means the Architecture Continuumstarts with the most general, a foundation architecture. It also includes a common systemsarchitecture (such as security or network architecture) and an industry architecture (such asretail's Active Store) or the Petrochemical Open Software Corporation's data model. Finally, itincludes an enterprise architecture, which can be customized for a specific organization. TheSolutions Continuum starts with Products and Services, which are combined into SystemSolutions, which are used in Industry Solutions, which can be customized to create anEnterprise Solution.
� Because it's more general than IIIRM and more likely to apply to your situation, let's discussthe TOGAF Foundation Architecture.
Arquitectura a Diferentes Niveles
TOGAF - Dimensiones
� Arquitectura de Negocios (o de Procesos de Negocio), lacual define la estrategia de negocios, la gobernabilidad,la estructura y los procesos clave de la organización.
� Arquitectura de Aplicaciones, la cual provee un plano(blueprint, en inglés) para cada uno de los sistemas deaplicación que se requiere implantar, las interaccionesentre estos sistemas y sus relaciones con los procesosentre estos sistemas y sus relaciones con los procesosde negocio centrales de la organización.
� Arquitectura de Datos, la cual describe la estructura delos datos físicos y lógicos de la organización , y losrecursos de gestión de estos datos
� Arquitectura Tecnológica, la cual describe la estructurade hardware, software y redes requerida para darsoporte a la implantación de las aplicaciones principales,de misión crítica, de la organización
TOGAF - Dimensiones
Metodologiás y ModelosMetodologiás y Modelospara Construcción de Software
CMMICMMICapability Maturity Model Integration
CMMI - Capability Maturity Model Integration
Modelo para la mejora y evaluación de procesos para el desarrollo, mantenimiento y operación de sistemas de software. Hay tres constelaciones de la versión 1.2 disponible:
� CMMI para el Desarrollo (CMMI-DEV o CMMI for Development), Versión 1.2 fue liberado en agosto de 2006. En él se tratan procesos de desarrollo de productos y servicios.CMMI para la adquisición (CMMI-ACQ o CMMI for � CMMI para la adquisición (CMMI-ACQ o CMMI for Acquisition), Versión 1.2 fue liberado en noviembre de 2007. En él se tratan la gestión de la cadena de suministro, adquisición y contratación externa en los procesos del gobierno y la industria.
� CMMI para servicios (CMMI-SVC o CMMI for Services), está diseñado para cubrir todas las actividades que requieren gestionar, establecer y entregar Servicios.
CMMI - Capability Maturity Model Integration
CMMI Madurez - Inmadurez
� Modelo para la mejora o evaluación de los procesosde desarrollo y mantenimiento de sistemas yproductos de software.
� Desarrollado por el Instituto de Ingeniería delSoftware de la Universidad Carnegie Mellon (SEI), y
CMMI
Software de la Universidad Carnegie Mellon (SEI), ypublicado en su primera versión en enero de 2002.
� Es empleado para guiar las mejoras de procesosdurante el desarrollo de un proyecto, undepartamento o hasta una organización.
Origen CMMI� Durante los años 90 SEI desarrolló modelos
específicos para la mejora y medición de lamadurez en varias áreas:� CMM-SW: CMM for software� P-CMM: People CMM.� 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
adopción de varios modelos de forma simultánea.� Su contenido integra y da relevo a la evolución
de sus predecesores:� CMM-SW (CMM for Software)� 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 método de definir y ygestionar los procesos a realizar por una organización.
� El modelo de calidad CMM aparece con la necesidad de mitigar losproblemas que se presentan continuamente al momento de contratarempresas desarrolladoras de software, por la progresiva elevación decostos y desfase de las fechas de entrega .costos y desfase de las fechas de entrega .
� Este modelo establece un conjunto de prácticas o procesos claveagrupados en Áreas Clave de Proceso (KPA - Key Process Area).
� Para cada área de proceso define un conjunto de buenas prácticas quehabrán de ser:� Definidas en un procedimiento documentado� Provistas (la organización) de los medios y formación necesarios� Ejecutadas de un modo sistemático, universal y uniforme (institucionalizadas)� Medidas� Verificadas
..sobre CMM
� A su vez estas Áreas de Proceso se agrupan en cinco "niveles demadurez", de modo que una organización que tenga institucionalizadastodas las prácticas incluidas en un nivel y sus inferiores, se consideraque ha alcanzado ese nivel de madurez.
� Los niveles son:� 1 - Inicial.� 2 - Repetible.� 2 - Repetible.� 3 - Definido.� 4 - Gestionado.� 5 - Optimizado.
� Así es como el modelo CMM establece una medida del progresoconforme avanza, en niveles de madurez. Cada nivel a su vez cuentacon un número de áreas de proceso que deben lograrse. El alcanzarestas áreas se detecta mediante la satisfacción o insatisfacción devarias metas claras y cuantificables.
Estructura CMMI
� El modelo para software (CMM-SW)� Establece 5 niveles de madurez para clasificar a las
organizaciones, en función de qué áreas de procesosconsiguen sus objetivos y se gestionan con principios deingeniería.
� Es lo que se denomina un modelo escalonado, o centrado en lamadurez de la organización.
� El modelo para ingeniería de sistemas (SE-CMM)� Establece 6 niveles posibles de capacidad para una de las 18
áreas de proceso implicadas en la ingeniería de sistemas.No agrupa los procesos en 5 tramos para definir el nivel de� No agrupa los procesos en 5 tramos para definir el nivel demadurez de la organización, sino que directamente analiza lacapacidad de cada proceso por separado.
� Es lo que se denomina un modelo continuo.
� En el equipo de desarrollo de CMMI habíadefensores de ambos tipos de representaciones.
� El resultado fue la publicación del modelo con dosrepresentaciones: continua y escalonada.
� Son equivalentes, y cada organización puede optarpor adoptar la que se adapte a sus características yprioridades de mejora.
Áreas de procesoÁreas de proceso de CMMI (Capability Maturity Model Integration)
Área de proceso Categoría Nivel de madurez
Análisis y resolución de problemas Soporte 5
Gestión de la configuración Soporte 2
Análisis y resolución de decisiones Soporte 3
Gestión integral de proyecto Gestión de proyectos 3
Gestión integral de proveedores Gestión de proyectos 3
Gestión de equipos Gestión de proyectos 3
Medición y análisis Soporte 2
Entorno organizativo para integración Soporte 3
Innovación y desarrollo Gestión de procesos 5
Definición de procesos Gestión de procesos 3
Procesos orientados a la organización Gestión de procesos 3
Rendimiento de los procesos de la org. Gestión de procesos 4
Formación Gestión de procesos 3
Integración de producto Ingeniería 3
Monitorización y control de proyecto Gestión de proyectos 2
Planificación de proyecto Gestión de proyectos 2
Gestión calidad procesos y productos Soporte 2
Gestión cuantitativa de proyectos Gestión de proyectos 4
Desarrollo de requisitos Ingeniería 3
Gestión de requisitos Ingeniería 2
Gestión de riesgos Gestión de proyectos 3
Gestión y acuerdo con proveedores Gestión de proyectos 2
Solución técnica Ingeniería 3
Validación Ingeniería 3
Verificación Ingeniería 3
EVALUACION DE PROCESOS CMMI
- Innovación y Distribución Organizacional (OID) - Análisis Causal y Resolución (CAR)
Definido
Gestionado Cuantitativamente
(4)
Optimizante (5)
Mejora Continua del Proceso (2 Áreas de Proceso)
Gestión Cuantitativa (2 Áreas de Proceso)
Estandarización del Proceso (11 Áreas de Proceso)
- Rendimiento del Proceso Organizacional (OPP) - Gestión Cuantitativa de Proyectos (QPM )
- Desarrollo de Requisitos (RD) - Solución Técnica (TS) - Integración del Producto (PI) - Verificación (VER)
- Gestión Cuantitativa del Suministrador (QSM)
- Entorno Organizacional para la Integración (OEI) - Equipo Integrado (OIT)
Inicial (1)
Gestionado (2)
Definido (3)
Gestión Básica de Proyectos (7 Áreas de Proceso)
(11 Áreas de Proceso)- Verificación (VER) - Validación (VAL) - Enfoque Proceso Organizacional (OPF) - Definición del Proceso Organizacional (OPD) - Formación de la Organización (OT) - Gestión Integrada de Proyectos (IPM) - Gestión de Riesgos (RSKM) - Análisis de Decisión y Resolución (DAR)
- Gestión de Requisitos (REQM) - Planificación del Proyecto (PP) - Monitorización y Control del Proyecto (PMC) - Gestión del Acuerdo con el Suministrador (SAM) - Medición y Análisis (M & A) - Aseguramiento de la Calidad del Proceso y Producto (PPQA) - Gestión de la Configuración (CM)
- Procesos Caóticos (Ad Hoc)
- Gestión Integrada del Suministrador (ISM)
- Selección y Monitorización del Suministrador (SSM)
CMMI – Paso a Paso
Inicial
� La organización en este nivel no dispone de un ambiente estable para el desarrollo y para el desarrollo y mantenimiento de productos y servicios.
Administrado
� En la organización que seencuentra en este nivel algunasáreas organizacionales y/oproyectos han alcanzado lasmetas genéricas y específicasestablecidas en sus áreas deproceso, es decir planean susprocesos, los ejecutan, losmiden y los controlan.
Definido
� Tienen los procesos caracterizados, entendidos por los ejecutores, descritos mediante estándares, descritos mediante estándares, procedimientos, métodos y herramientas.
Administrado Cuantitativamente � La organización selecciona y
administra las actividades que contribuyen perceptiblemente al funcionamiento de proceso total. Estas actividades seleccionadas son controladas con técnicas estadísticas y otras técnicas cuantitativas.
Optimizado
� Los procesos de la organización son mejorados continuamente basados en una comprensión cuantitativa de las causas comunes de variación inherentes comunes de variación inherentes a los procesos. El nivel 5 está centrado en mejorar continuamente el desempeño de los procesos con mejoras tecnológicas incrementales e innovadoras.
� Componentes Requeridos genérico : Los objetivos genéricos� Objetivo asociados a un nivel de capacidad establecen lo que una
organización debe alcanzar en ese nivel de capacidad.� Objetivo específico : Los objetivos específicos se aplican a una única
área de proceso y localizan las particularidades que describen que sedebe implementar para satisfacer el propósito del área de proceso.
� Componentes Esperados� Práctica genérica : Una práctica genérica se aplica a cualquier área de
proceso porque puede mejorar el funcionamiento y el control decualquier proceso.
CMMI-Componentes
cualquier proceso.� Práctica específica : Una práctica específica es una actividad que se
considera importante en la realización del objetivo específico al cual estáasociado.� Las prácticas específicas describen las actividades esperadas para lograr
la meta específica de un área de proceso
CMMI - Componentes
Componentes� Componentes Informativos
� Propósito� Notas introductorias� Nombres� Tablas de relaciones práctica - objetivo� Prácticas� Productos típicos� Productos típicos� Sub-prácticas : Una sub-práctica es una descripción detallada que sirve
como guía para la interpretación de una práctica genérica o especifica.� Ampliaciones de disciplina : Las ampliaciones contienen información
relevante de una disciplina particular y relacionada con una prácticaespecifica.
� Elaboraciones de prácticas genéricas : Una elaboración de una prácticagenérica es una guía de cómo la práctica genérica debe aplicarse al área deproceso.
CMMI a Futuro – ISO 15504
Para ampliar informaciónPara ampliar información
� Página oficial CMMI del Software Engineering Institute. (http://www.sei.cmu.edu/cmmi/cmmi.html)
� Página para descarga de los modelos CMMI. (http://www.sei.cmu.edu/cmmi/models/models.html)
� SWEBOK: Áreas de conocimiento de la Ingeniería del software (http://www.swebok.org/)
� Gestión de proyectos PMI (http://www.pmi.org) IPMA (http://www.ipma.ch) PRINCE 2 (http://www.prince2.com/)
Modelos basados en procesos
� Manifiesto Ágil
Modelos ágiles
Procesos y técnicas para desarrollo de software
138
� 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)
ISO/IEC TR 15504: Dimensión de proceso (alineado 12 207) ISO/IEC TR 15504: Dimensión de proceso (alineado 12 207)
Preparación de la AdquisiciónSelección del suministradorSeguimiento del suministradorAceptación del cliente
CUS.1 Adquisición
CUS.3 Obtención de requisitos
CUS.2 Suministro
CUS.4 Operación
OperaciónSoporte a cliente
Requisitos del sistema
ENG.1 DesarrolloConstrucción del software
SUP.1 Documentación
SUP.2 Gestión de la configuración
SUP.3 Aseguramiento de la calidad
SUP.4 Verificación
SUP.5 Validación
Procesos y técnicas para desarrollo de software
139
Requisitos del sistemaAnálisis y diseñoAnálisis requ. SoftwareDiseño del software
Construcción del softwareIntegración del softwarePruebas del softwarePruebas e integ. del sistema
ENG.2 Mantenimiento del sistema y del software
SUP.6 Revisión conjunta
SUP.7 Auditoría
SUP.8 Resolución de problemas
MAN.1 Gestión
MAN.1 Gestión de proyecto
MAN.1 Gestión de la calidad
MAN.1 Gestión de riesgos
Definición de procesosEvaluación de procesosMejora de procesos
ORG.2 Mejora
ORG.1 Alineamiento organizacional
ORG.3 Gestión de las personas
ORG.4 Infraestructura
ORG.5 Medición
ORG.6 Reutilización
ISO/IEC TR 15504: Dimensión de capacidadISO/IEC TR 15504: Dimensión de capacidad
Niveles de capacidad y atributosNiveles 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 Gestión de la ejecución� PA 2.2 Gestión de las
características del producto
N
No alcanzado (0% a 15%).Escasa o ninguna evidencia de la consecución del atributo.
Parcialmente alcanzado (16% a 50%).Evidencia de un enfoque sistemático y de la
Medición de atributosMedición de atributos
Procesos y técnicas para desarrollo de software
140
características del producto� Nivel 3: Proceso Establecido
� PA 3.1 Definición del proceso� PA 3.2 Recursos de lproceso
� Nivel 4: Proceso Predecible� PA 4.1 Medición del proceso� PA 4.2 Control del proceso
� Nivel 5: Proceso en optimización� PA 5.1 Cambio del proceso� PA 5.2 Mejora continua
P
Evidencia de un enfoque sistemático y de la consecucióndel atributo.Algunos aspectos de la consecución pueden ser impredecibles.
L
Ampliamente alcanzado (51% a 85%).Evidencia de un enfoque sistemático y de una consecución significativa del atributo.La realización del proceso puede variar en algunas áreas.
F
Totalmente alcanzado (86% a 100%).Evidencia de un enfoque completo y sistemático y de la consecución plena del atributo.
Metodologiás AlternasMetodologiás Alternaspara Construcción de Software
En marzo de 2001, 17 críticos de estos modelos, convocados por Kent Beck, que acababa de definir una nueva metodología denominada Extreme Programming, se reunieron en Salt Lake City para discutir sobre los modelos de desarrollo de software.En la reunión se acuñó el término “Métodos Ágiles ” para definir a aquellos que estaban surgiendo como alternativa a las metodologías formales, (CMM-SW, PMI, SPICE) a las que consideraban excesivamente “pesadas” y rígidas por su carácter normativo y fuerte dependencia de planificaciones detalladas, previas al desarrollo.Los integrantes de la reunión resumieron en cuatro postulados lo que ha quedado denominado como “Manifiesto
Origen de los “métodos ágiles”Origen de los “métodos ágiles”
Manifiesto ágil (2001)Manifiesto ágil (2001)
Procesos y técnicas para desarrollo de software
142
Ágil”, que compendia el espíritu en el que se basan estos métodos.Aunque como se verá más 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á más ocupadas en descalificar a la contraria que en estudiarla y conocerla para mejorar la propia.
Estamos poniendo al descubierto mejores métodos para desarrollar software, haciéndolo y ayudando a otros a que lo hagan. Con este trabajo hemos llegado a valorar:
A los individuos y su interacción de los procesos y las herramientaspor encima
El software que funciona de la documentación exhaustivapor encima
Manifiesto ágil (2001)Manifiesto ágil (2001)
Procesos y técnicas para desarrollo de software
143
La colaboración con el cliente la negociación contractualpor encima
La respuesta al cambio seguimiento de un planpor encima
Aunque hay valor en los elementos de la derecha, valoramos más 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/
Métodos ágilesMétodos ágiles
1997TickIT1991
ISO 9000-3Ada
ptac
ione
spa
ra s
oftw
.
Mod
elos
y e
stán
dare
sde
cal
idad
Modelos genéricos Modelos para software
Procesos y técnicas para desarrollo de software
144
1959MIL-Q 9858
1979BS 5750
1987ISO 9000
ISO 9000-3Ada
ptac
ione
s
1995ISO 12207
1995Proy. SPICE
1993CMM-SW
Mod
elos
esp
ecífi
cos
para
sof
twar
e.
2003-05ISO 15504
2001CMMI
ModelosCMM
TR 15504Mod
elos
y e
stán
dare
sde
cal
idad
TrilliumBootstrap
DSDMSCRUM
CRYSTALXP
ASDPP
AMISD
19952000
ManifiestoÁgil
Téc
nica
s y
mét
odos
ágile
s
Métodos ágilesMétodos ágiles
5. Procesos primarios5. Procesos primarios
5.1 Adquisición
5.2 Suministro
5.3
6.1 Documentación
6.2 Gestión de la configuración
6.3 Control de calidad
6.4 Verificación
5. Procesos de soporte5. Procesos de soporte
� Recogen técnicas, “buenas prácticas” contrastadas por profesionales reconocidos.
� Cada una tiene sus características propias y cubre un rango de áreas de procesos
Procesos y técnicas para desarrollo de software
145
7. Procesos organizacionales7. Procesos organizacionales
5.3 Desarrollo
5.3 Operación
5.3 Mantenimiento
6.4 Verificación
6.5 Validación
6.6 Reuniones
6.7 Auditoría
6.8 Resolución de problemas
7.1 Gestión
7.3 Mejora
7.2 Infraestructura
7.4 Formación
y cubre un rango de áreas de procesos más 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 producción industrial.
eXtreme Programming (XP)eXtreme Programming (XP)
Procesos y técnicas para desarrollo de software
Este es el método que más popularidad ha alcanzado entre las metodologías ágiles, y posiblemente sea también el más 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 suposición de que es posible desarrollar software de gran calidad a pesar, o incluso como consecuencia del cambio continuo. Su principal asunción es que con un poco de planificación, un poco de codificación y unas pocas pruebas se puede decidir si se está siguiendo un camino acertado o equivocado, evitando así tener que echar marcha atrás demasiado tarde.
146
Valores que inspiran XPValores que inspiran XP
FEEDBACK CORAJE COMUNICACIÓNSIMPLICIDAD
eXtreme Programming (XP)eXtreme Programming (XP)
Procesos y técnicas para desarrollo de software
XP pone en comunicación 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 día a día, y es posible ajustar la agenda y las funcionalidades de forma consecuente
ComunicaciónComunicación
Una metodología basada en el desarrollo incremental de pequeñas partes, con entregas y pruebas frecuentes y continuas, proporciona un flujo de retro-información valioso para detectar los problemas o desviaciones.
Feedback rápido y continuoFeedback rápido y continuo
147
continuas, proporciona un flujo de retro-información valioso para detectar los problemas o desviaciones.� De esta forma fallos se localizan muy pronto.� La planificación no puede evitar algunos errores, que sólo se evidencian al desarrollar el sistema.� La retro-información es la herramienta que permite reajustar la agenda y los planes.
eXtreme Programming (XP)eXtreme Programming (XP)
Procesos y técnicas para desarrollo de software
La simplicidad consiste en desarrollar sólo el sistema que realmente se necesita. Implica resolver en cada momento sólo las necesidades actuales.
Con este principio de simplicidad, junto con la comunicación y el feedback resulta más fácil conocer las necesidades reales
SimplicidadSimplicidad
Los costes y la complejidad de predecir el futuro son muy elevados, y la mejor forma de acertar es esperar al futuro.
148
El coraje implica saber tomar decisiones difíciles. Reparar un error cuando se detecta. Mejorar el código siempre que tras el feedback y las sucesivas iteraciones se manifieste susceptible de mejora.Tratar rápidamente con el cliente los desajustes de agendas para decidir qué partes y cuándo se van a entregar.
CorajeCoraje
eXtreme Programming (XP)eXtreme Programming (XP)
Procesos y técnicas para desarrollo de software
XP no es un modelo de procesos ni un marco de traba jo, sino un conjunto de 12 prácticas que se complementan unas a otras y deben implementarse en un entorno de desarrollo cuya cultura se base en los cuatro valores citados
Las 12 prácticas de XPLas 12 prácticas de XP
PRÁCTICAS DE CODIFICACIÓN
1.- Simplicidad de código y de diseño para producir software fácil de modificar.
149
1.- Simplicidad de código y de diseño para producir software fácil de modificar.2.- Reingeniería continua para lograr que el código tenga un diseño óptimo.3.- Desarrollar estándares de codificación, para comunicar ideas con claridad a través del código.4.- Desarrollar un vocabulario común, para comunicar las ideas sobre el código con claridad.
PRÁCTICAS DE DESARROLLO
1.- Adoptar un método de desarrollo basado en las pruebas para asegurar que el código secomporta según lo esperado.
2.- Programación por parejas, para incrementar el conocimiento, la experiencia y las ideas.3.- Asumir la propiedad colectiva del código, para que todo el equipo sea responsable de él.4.- Integración continua, para reducir el impacto de la incorporación de nuevas funcionalidades.
eXtreme Programming (XP)eXtreme Programming (XP)
Procesos y técnicas para desarrollo de software
Las 12 prácticas de XPLas 12 prácticas de XP
PRÁCTICAS DE NEGOCIO
1.- Integración de un representante del cliente en el equipo, para encauzar las cuestiones de negocio del sistema de forma directa, sin retrasos o pérdidas por intermediación.2.- Adoptar el juego de la planificación para centrar en la agenda el trabajo más importante.3.- Entregas regulares y frecuentes para satisfacer la inversión del cliente.4.- Ritmo de trabajo sostenible, para terminar la jornada cansado pero no agotado.
150
4.- Ritmo de trabajo sostenible, para terminar la jornada cansado pero no agotado.
ScrumScrum
Procesos y técnicas para desarrollo de software
No es propiamente un método o metodología de desarrollo, e implantarlo como tal resulta insuficiente.Scrum define métodos de gestión y control para complementar la aplicación de otros métodos ágiles como XP que, centrados en prácticas de tipo técnico, carecen de ellas.Los principios de Scrum son:
� Equipos autogestionados.� Una vez dimensionadas las tareas no es posible agreg arles trabajo extra.� Reuniones diarias en las que los miembros del equip o se plantean 3 cuestiones:
� ¿Qué has hecho desde la última revisión?� ¿Qué obstáculos te impiden cumplir la meta?� ¿Qué vas a hacer antes de la próxima reunión?
151
� ¿Qué vas a hacer antes de la próxima reunión?� 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 planificación de la siguiente iteración, guiada por cliente.
ScrumScrum
Procesos y técnicas para desarrollo de software
152
Procesos y técnicas para desarrollo de software
Otros métodos ágilesOtros métodos ágiles
Familia de métodos CrystalFamilia de métodos Crystal
La familia de metodologías Crystal ofrece diferentes métodos para seleccionar el más apropiado para cada proyecto.Crystal identifica con colores diferentes cada método, y su elección debe ser consecuencia del tamaño y criticidad del proyecto, de forma que los de mayor tamaño, o aquellos en los que la presencia de errores o desbordamiento de agendas implique consecuencias graves, deben adoptar metodologías más pesadas.Los métodos Crystal no prescriben prácticas concretas
153
ASD (Adaptative Software Development)ASD (Adaptative Software Development)
Método que como alternativa a los procedimientos formales, aborda el desarrollo de grandes sistemas con el uso de técnicas propias de las metodologías ágiles.No se trata de una metodología, sino de la implantación de una cultura en la empresa, basada en la adaptabilidad.
Procesos y técnicas para desarrollo de software
Otros métodos ágilesOtros métodos ágiles
PP (Pragmatic Programming)PP (Pragmatic Programming)Pragmatic Programming es la colección de 70 prácticas de programación, comunes a otros métodos ágiles, cuya aplicación resulta útil para solucionar los problemas cotidianos. Surge del libro “The Pragmatic Programmer” de Dave Thomas y Andres Hunt.
AM (Agile Modeling)AM (Agile Modeling)Agile Modeling es la presentación de un nuevo enfoque para realizar el modelado de sistemas,(diseño) y basado en los principios de los métodos ágiles remarca la conveniencia de reducir el volumen de la documentación. (Amber S. “Agile Modeling: Effective Practices for Extreme Programming and the Unified Process”)
154
“Agile Modeling: Effective Practices for Extreme Programming and the Unified Process”)
ISD Internet Speed DevelopmentISD 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 gestión para abordar el desarrollo de sistemas de software, de tamaño pequeño que requieren tiempos de desarrollo muy rápidos.
FDD (Feature Driven Development)FDD (Feature Driven Development)
Prescribe un proceso iterativo de 5 pasos, con iteraciones de dos semanas.El punto de referencia son las características que debe reunir el software, y se centra en las fases de diseño e implementación del sistema
Procesos y técnicas para desarrollo de software
Modelos de propiedad Comercial: MSFModelos de propiedad Comercial: MSF
MSF es la metodología empleada por Microsoft para el desarrollo de software.Hasta su versión 3 (principios de 2005) MSF se definía como un marco de desarrollo flexible para adaptarse a las necesidades de cada proyecto, en oposición a lo que sería una metodología 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
155
� Fomento de la comunicación abierta.� Trabajo en torno a una visión compartida.� Apoderar a los integrantes del equipo (“ empowerment”)� Establecimiento de responsabilidades claras y compa rtidas.� Centrar el objetivo en la entrega de valor para el negocio.� Permanecer ágiles y esperar e cambio.� Invertir en calidad.� Aprender de la experiencia.
MSF: PRINCIPIOS FUNDAMENTALES
Procesos y técnicas para desarrollo de software
Modelos de propiedad Comercial: MSFModelos de propiedad Comercial: MSF
Elementos que componen el modeloElementos que componen el modelo
Principios fundamentales
Modelos
Disciplinas
Principios básicos en los que se basa todo el modelo (los 8 de la pág. ant.)
Mapas mentales de organización. Hay 2: De equipo y de procesos
Áreas de trabajo en las que se usan métodos determinados (Gestión de proyecto, de riesgos y de la mejora del talento)
156
Conceptos clave
Prácticas contrastadas
Recomendaciones
Ideas que dan soporte a los principios y disciplinas de MSF y se muestrana través de prácticas específicas contrastadas.
Prácticas que han demostrado su efectividad en proyectos en diferentes condiciones de entornos reales
Prácticas opcionales, sugeridas por el modelo.
Procesos y técnicas para desarrollo de software
Modelos de propiedad Comercial: MSFModelos de propiedad Comercial: MSF
Relación entre los componentes del modeloRelación entre los componentes del modelo
Este diagrama es un ejemplo para mostrar la interconexión y relación entre los componentes de Microsoft Solutions Framework
Uso de
PrincipioFundamental
Modelo oDisciplina
ConceptoClave
PrácticaContrastada
Recomendac.
157
Aprender de las experiencias
Modelo de procesos
Disposición al aprendizaje
Hitos de revisión
Uso de facilitadores
externos
Permanecer ágil y esperar el
cambio
Gestión de riesgos
Evaluación continua de
riesgos
Definir y monitorizar
disparadores de riesgos
Creación de una BD de
riesgos
˜
˜
˜
˜
˜
˜
˜
˜˜
Está relacionado
En 2005, el desarrollo del nuevo producto de Microsoft “Visual Studio 2005 Team System” ha ganerado la evolución de MSF hacia la nueva versión 4.0 con dos líneas paralelas:
� Microsoft Solutions Framework (MSF) for Agile Software Development.� Microsoft Solutions Framework (MSF) for CMMI Process Improvement.
Procesos y técnicas para desarrollo de software
Modelos de propiedad Comercial: RUPModelos de propiedad Comercial: RUP
Rational Unified ProcessRational Unified Process
Es un proceso de Ingeniería del Software que proporciona una visión disciplinada para la asignación 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 prácticas” para el desarrollo de software en un marco de procesos válido para un rango amplio de tipos de proyectos y organizaciones.
158
�Desarrollo iterativo.�Gestión de requisitos.�Uso de arquitecturas basadas en componentes.�Uso de técnicas de modelado visual.�Verificación continua de la calidad.�Gestión y control de cambios.
RUP: Buenas Prácticas
Procesos y técnicas para desarrollo de software
Modelos de propiedad Comercial: RUPModelos de propiedad Comercial: RUP
Rational Unified Process: Visión estáticaRational Unified Process: Visión estática
En su visión estática, el modelo RUP está compuesto por:� Roles : analista de sistemas, diseñador, diseñador de pruebas, roles de gestión y roles de administración.� Actividades : RUP determina el trabajo de cada rol a través de actividades. Cada actividad del proyecto
debe tener un propósito claro, y se asigna a un rol específico. Las actividades pueden tener duración de horas o de algunos días; y son elementos base de planificación 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, código, ejecutables…)
159
documentos, código, ejecutables…)� Disciplinas : son “contenedores” empleados para organizar las actividades del proceso. RUP comprende
6 disciplinas técnicas y 3 de soporte.Técnicas : modelado del negocio, requisitos, análisis y diseño, implementación, pruebas y desarrollo.Soprte : gestión de proyecto, gestión de configuración y cambio, y entorno.
� Flujos de trabajo : son el “pegamento”de los roles, actividades, artefactos y disciplinas, y constituyen la secuencia de actividades que producen resultados visibles.
Procesos y técnicas para desarrollo de software
Modelos de propiedad Comercial: RUPModelos de propiedad Comercial: RUP
Rational Unified Process: Visión dinámicaRational Unified Process: Visión dinámica
En su visión dinámica, la visión 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 visión inicial de producto, su alcance. El esbozo de una arquitectura posible y las primeras estimaciones. Concluye con el “hito de objetivo”.
� 2.- Elaboración . Comprende la planificación de las actividades y del equipo necesario. La especificación de las necesidades y el diseño de la arquitectura. Termina con el “hito de Arquitectura”.
� 3.- Construcción . Desarrollo del producto hasta que se encuentra disponible para su entrega a los
160
� 3.- Construcción . 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.- Transición . Traspaso del producto a los usuarios. Incluye: manufactura, envío, formación, asistencia y el mantenimiento hasta lograr la satisfacción de los usuarios. Termina con el “hito de entrega del producto”.
FACTORES CLAVE EN LOS PROYECTOSFACTORES CLAVE EN LOS PROYECTOS
Factor Discriminadores ágiles Discriminadores formales
TamañoDependencia y escalabilidad limitada por el porcentaje alto de conocimiento tácito.Apropiado para equipos y productos pequeños.
Escalabilidad y conocimiento explícito.Apropiado para productos y equipos grandes. Duro de mantener en pequeños proyectos.
Criticidad
La simplicidad en la documentación y el diseño dificulta los planes de pruebas.No aconsejado para sistemas con niveles de criticidad altos (IEEE 1012)
Rigor de requisitos y diseño adecuados para procesos de pruebas, verificación y validación.Duros de gestionar en proyectos de escasa criticidad
Procesos y técnicas para desarrollo de software
161
criticidad altos (IEEE 1012) criticidad
Dinamismo
“Re-factorizar” desde un diseño básico hasta el producto final es un método ideal para entornos dinámicos 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 diseños detallados permite trazar y seguir un plan completo y “hacerlo bien a la primera”.
Personal
Los métodos de trabajo ágiles requieren una masa crítica de técnicos con niveles de experiencia medios-altos, capaces de comprender y adaptar los métodos y las técnicas empleadas.
Aunque es aconsejable contar con personas expertas en las fases de definición del proyecto, luego pueden ejecutarse con menor masa crítica de expertos.
CulturaMás apropiado para culturas de “empowerment” responsabilidad y horquilla de decisión y libertad personal.
Más 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 TurnerBalancing Agility and Discipline
¿Enfoque formal o ágil?¿Enfoque formal o ágil?
Personal
Criticidad
Dinamismo
% Junior % Senior y Master
Pérdidas posibles
% Modific. Requisitos / mes
20
30
40
25
20
15
Procesos y técnicas para desarrollo de software
162
TamañoCulturaNúmero de personas
% Modific. Requisitos / mes
% adaptación a entornos caóticos
1
510
3050
10
30
50
70
90
300
100
30
10
3
0
10
35
30
Arquitectura de Software
Proyectos sin Arquitectura, ni Frameworks
Arquitectura de Software
IEEE 1471� Arquitectura es la
organización fundamental de un sistema descrita en: � Sus componentes.� Relación entre ellos y con el
Arquitectura de Software
� Relación entre ellos y con el ambiente.
� Principios que guían su diseño y evolución.
� La arquitectura debe satisfacer los requerimientos de calidad de servicio.
El nivel conceptual más alto de un sistema en su ambiente.
Evolución de Arquitecturas� Aplicaciones Monolíticas
� Interfaces gráficas de usuario (GUI).
� Servicios de presentación, negocios y persistencia en la misma máquina.
Arquitectura Cliente-Servidor
+ Clientes pesados, no estándar+ Conexiones dedicadas a BD+ Protocolos pesados+ Ejecución remota de SQLs
misma máquina.
� No hay concurrencia de usuarios.
� Alto acoplamiento entre tiers.
+ Alta administración+ Bajo rendimiento+ Alto tráfico de red+ Baja accesibilidad
Evolución de Arquitecturas� Arquitectura Cliente-Servidor
Mejorada
� Lógica de negocios en BD
� Clientes pesados, no estándar.
� Conexiones dedicadas a la BD.
Arquitectura de 3 niveles
+ Reutilización de lógica de negocio para diferentes clientes o sistemas.
+ Mejora la escalabilidad.+ Mejora la flexibilidad.
� Conexiones dedicadas a la BD.
� Mejora en rendimiento
� Alta administración
� Baja escalabilidad
� Baja flexibilidad
� Baja portabilidad
+ Independencia de la base de datos.
Evolución de Arquitecturas� Arquitectura de N -niveles
100.000+
+ Bajo costo de administración de clientes.+ Alta accesibilidad.+ Alta flexibilidad.+ Alta disponibilidad y tolerancia a fallos.+ Alta escalabilidad.+ Independencia de DB
Evolución de Arquitecturas� Visión de Arquitectura Orientada a Servicios (SOA)
Cluster deServidores de Aplicaciones
SistemaBatch
Portal deServicios Integrados
+ Requerimientos Arquitectónicos
Aplicaciones
AplicacionesLegadas
Servidor de Procesos(BPM)
Base de Datos
+ Heterogeneidad+ Escalabilidad+ Disponibilidad+ Distribución+ Manejabilidad de Procesos+ Administración y monitoreo de procesos,
servicios e infraestructura
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:
• SUN SL-425:
El arquitecto: – Visualiza el comportamiento
del sistema.– Crea los planos del sistema.
– Liderar el proceso de arquitectura.
– Producir los artefactos necesarios: Documento de descripción de arquitectura
– Modelos y prototipos de arquitectura.
– 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. Diseño+ La arquitectura y el diseño difieren en tres áreas:
Arquitectura Diseño
Nivel de Abstracción
Alto nivel Bajo nivel. Enfoque específico en detalles
Entregables Planear subsistemas, interfaces Diseño detallado con sistemas externos, servicios horizontales, frameworks, componentes reutilizables, prototipo arquitectónico
componentes.
Especificaciones de codificación
Áreas de Enfoque
Selección de tecnologías, Requerimientos no funcionales (QoS), Manejo de riesgos
Requerimientos funcionales
Arquitectura Vs. Diseño� La arquitectura envuelve un conjunto de
decisiones estratégicas de diseño, lineamientos, reglas y patrones que restringen el diseño y la implementación de un software.
Las decisiones de arquitectura de arquitectura causan un alto impacto en los proyectos de IT
Arquitectura
Diseño
Implementación
Código
SOASOAArquitectura Orientada a Servicios
Arquitectura Orientada a Servicios (SOA)
� SOA es una arquitectura conceptual.� Organiza funciones de negocio como servicios interoperables. � Permite reutilización de servicios para dar cumplimiento a las
necesidades del negocio.� SOA es basado en estándares.� 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:
� Autónomos � Opacos
Bajamente acoplados.� Bajamente acoplados.
SOA y Web ServicesLos 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 : SOA requiere que un servicio :
�Sea descubrible e invocable dinámicamente. UDDI, WSDL, SOAP.�Tenga una definición del contrato independiente de plataforma. XML.�Pueda interoperar con otros servicios. HTTP.
Por que SOA?• Permite que el área de IT
satisfaga más ágilmente las necesidades del negocio, cerrando cada vez más la brecha entre la evolución del negocio y el soporte tecnológico.
• Crea servicios basados en estándares, interoperables e independientes de un proveedor específico.
• Reutilización de servicios para la creación de nuevas aplicaciones o funcionalidades que apoyan los procesos de negocio.
Arquitectura de Referencia SOA
Conceptual:Neutral en Tecnología
Dependiente de Tecnología.Reutilizable
Modelo de Referencia SOA
Arquitectura de Referencia SOA
Frameworks
Patrones de Diseño
� OASIS - Modelo de Referencia SOA
Reutilizableentre Proyectos.
Arquitectura Concreta
Patrones de Diseño
Instancia Arquitectura de Referencia.Específica de cada Proyecto.
Arquitectura Concreta:Servicios de Negocio
Session Facade
Presentation Business Resources
FrontController Session
Facade
Session Facade
EIS
LDAP
Servicios de Negocio: Web Services, EJBs.
Arquitectura Concreta:Servicios de Negocio y Persistencia
Session Facade
Presentation Business Resources
Composite Entity
Integration
FrontController Session
Facade
Session Facade
LDAP
Composite Entity
Servicios de Negocio y Persistencia: Web Services, EJBs.
Arquitectura Concreta:Orquestación y Procesos de Negocio
Session Facade
Presentation Business
FrontController Session
Facade
Process Orchestration
Servicios de Negocio: Web Services, EJBs.
Session Facade
Arquitectura Concreta:Servicios de Negocio y Persistencia
Session Facade
Business Process Business Logic Resources
Composite Entity
Integration
Session Facade
Session Facade
LDAP
Composite Entity
Servicios de Negocio y Persistencia: Web Services, EJBs.
Process Orchestration
Ruta de Implementación a SOA
� Evaluar grado de madurez SOA y definir grados de madurez que la organización 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 el proyecto piloto como servicios.
Nivel 6 SOA optimizado
ExplotaciónNivel 5 Adopción empresarial de SOA
Nivel 4 SOA repetible
ExpansiónNivel 3 Enfoque SOA definido
Nivel 2 Adopción Ad Hoc de SOA
ExploraciónNivel 1 Ninguna adopción de SOA Evolución SOA
Arquitecturas Técnicas 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.� Firmaría usted un contrato para garantizar su proyecto open � Firmaría usted un contrato para garantizar su proyecto open
source ?� Comunidades dinámicas : fabricantes, ISV, universidades, etc.� Es común tener múltiples alternativas de solución para un
requerimiento� Groovy – Lenguaje Ágil para plataforma Java (2004)� Hablemos solo de Open Source …..
Quien está detrás de Java ?
� JCP (Java Community Process) � SUN (Oracle)� IBM� SAP� SAP� HP� Nokia � Blackberry� Google.
Aplicaciones para Escritorio
� Primera Generación
� AWT - Swing (SUN)� SWT (IBM – Apache )� SWT (IBM – Apache )
� Segunda Generación
� Netbeans framework (Drag & Drop environment)� RCP framework (IBM - Apache)
Aplicaciones Móbiles� Java Mobile (J2ME)� Desde Aplicativos Embebidos (Java Card),
electrodomésticos, celulares básicos, etc. � Hasta PDA’s y Smartphones� Fabricantes que implementan JVM y JSR’s
Incluyen funcionalidad adicional, emuladores, Otros Frameworks de alto nivel - J2ME Polish - Iphone
Aplicaciones Web� Primera Generación
� Java Server Pages , Servlets
� Segunda Generación: MVC – O.O.� Struts, Tapestry, � Java Server Faces (event oriented)
� Tercera Generación� Tercera Generación� Web 2.0 - Ajax- RIA – Aplicaciones Cinemáticas� JSF: RichFaces, Icefaces, Seam� OpenLaszlo� GWT, � Zk V� aadin
Entornos para Desarrollo (Open)
� Eclipse: (IBM – Apache – Oracle –Adobe)� Escritorio, Móviles (J2ME) � Web, Empresarial (JEE), RIA, Groovy.
� Netbeans : (SUN) � Escritorio, Móviles (J2ME), Web, Empresari
(JEE), � SOA, BPM, UML, Groovy, php, ruby and
Rails.
Aplicaciones Empresariales, SOA y BPM� Empresariales
� Seguras, transaccional, geográficamente dispersas, altamente disponibles� EJB, Web Services, Corba, JNDI, JAAS, PKI, Metro
� Orientadas a Servicios� Primera Generación
� XML� Web Services : SOAP y REST
� Segunda Generación: Mediación, Transformación, orq uestación � Segunda Generación: Mediación, Transformación, orq uestación (ESB)� SUN Glassfish� Apache Service Mix (ESB)
� Orientadas a Procesos (BPM) y Flujos (workflow)� JBPM� Glassfish� OpenSymphony
Java Enterprise - Modular – Máxima ReutilizaciónY adaptabilidad a entornos Existentes
Arquitectura Concreta:Servicios de Negocio y Persistencia
Session Facade
Presentation Business Resources
Composite Entity
Integration
FrontController Session
Facade
Session Facade
LDAP
Composite Entity
Servicios de Negocio y Persistencia: Web Services, EJBs.
Java como Implementación Natural SOA
Nivel 6 SOA optimizado
ExplotaciónNivel 5 Adopción empresarial de SOA
Nivel 4 SOA repetible
Expansión
Evolución SOA
ExpansiónNivel 3 Enfoque SOA definido
Nivel 2 Adopción Ad Hoc de SOA
ExploraciónNivel 1 Ninguna adopción de SOA
Evolución SOA
Frameworks de Ultima Generación
� Pruebas AutomatizadasJunit – HttpUnitJmeter (Performance)
� IntegraciónSpringSpring
� Reportes y GráficosJasper Reports & Birt (Designer & Engine) JchartApache POI (excel, word, etc)Itext – PDF
Más frameworks de Ultima Generación
� PersistenciaJPA – 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, Certificación digital..� Abierto: Múltiples O.S, Bases de Datos, directorios de
seguridad, etc.seguridad, etc.� Múltiples frameworks de solución para (1) problema� AJAX-RIA - MDA� SOA - Web services – Rest & SOAP Rest services � BPM� Fácil Transición a ambientes soportados por fabricantes.
Porque usar Java ?
� Plataforma preferida para la creación de Open Source y productos comerciales robusto
� OpenJDK, � http://java-source.net/� 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: Integración 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 Percepción vs. Realidad
� Comparar Java con lenguajes de escritorio� Java son solo Applets (en los 90’s ?)� Java es complicado� Java es Lento� Es lento desarrollar con Java� Es lento desarrollar con Java� Java es costoso � Entrenamiento es Costoso � Es java para todas las soluciones?� Candidato Natural para el seguimiento de
metodologías formales y ágiles.� Construye sobre arena ó sobre roca.
Entrenamiento
� Certificado por SUN Microsystems a nivel Internacional
� Análisis y Diseño Orientado a Objetos con UML� Java para Desktop y Bases de Datos� Java para Web� Java empresarial� Arquitectura y Patrones.
� Diplomado en Fundación de Egresados
� Frameworks de Última Generación : JSF, JPA, etc.
� Java para Móviles
� Groovy & Grails (Orientado a Max. Productividad)
Alineación de Frameworks con Prioridades de IT
Estratégico
Operativo
CobitGobierno
PMIProyectos
ISO 38500Gobierno
TOGAFArquitecturaEmpresarial
Operativo
Técnico
ITILGestión del
Servicio
CMMISoftware
SOAIntegración
ConectividadJava
Enterprise Arquitectura
TécnicaInfraestructura
Redes : Cisco, RDBMS – Oracle,
etc.
ISO 27001Seguridad
Elementos Clave para Gestión de InfraestructuraInfraestructura
Elementos Clave para Gestión de Infraestructura e Integración
Infraestructura
Gestión de Red con Cisco
SeguridadSeguridad
Motores de Bases de datos Diversos.
Sistemas Operativos
Middleware
Alineación de Frameworks con Prioridades de IT
Estratégico
Operativo
CobitGobierno
PMIProyectos
ISO 38500Gobierno
TOGAFArquitecturaEmpresarial
Operativo
Técnico
ITILGestión del
Servicio
CMMISoftware
SOA /BPM Integración
ConectividadJava
Enterprise Arquitectura
TécnicaInfraestructura
Redes : Cisco, RDBMS – Oracle,
etc.
ISO 27002Seguridad
Preguntas ?
De Gobierno TI a la PrácticaDe Gobierno TI a la Práctica
Ing. Pedro Rozo
Top Related