Test1-RPM - de La Gestion Por Procesos Al BPM

ISSN: 1698-2029
Volumen 5 Nmero 3
OCTUBRE 2008
Revista de
Procesos y Mtricas
de las tecnologas de la informacin
CONTENIDOS
EL BUEN GOBIERNO DE LA SEGURIDAD. Miguel ngel Thomas ...57
GOBERNADOR DE TI: NACE UN NUEVO PUESTO EN EL NIVEL DIRECTIVO
Miguel Garca Menndez .......64
LA GESTIN CUANTITATIVA EN CMMI. RELACIN CON SPC Y SEIS
SIGMA. Anabel Manchn Diez.........67
DE LA GESTIN POR PROCESOS AL B.P.M. Dr. Montgomery Lee, PDF , Ignacio
Fernndez........72
ENTERPRISE AND IT ARCHITECTURE: LAS CLAVES DEL GOBIERNO DE TI
ngel Snchez..........77
PRUEBAS DE SEGURIDAD EN EL MARCO DE UNA FACTORA DE CALIDAD
DE PRODUCTO SOFTWARE. Jess Prez Cristbal........82
Revista de Procesos y
Mtricas de las Tecnologas
de la Informacin
Asociacin Espaola de Mtricas del Software (AEMES)
Volumen 5 Nmero 3
La Asociacin Espaola de Mtricas de Sistemas Informticos (AEMES) es una

asociacin sin nimo de lucro y con plena capacidad de obrar y personalidad jurdica y
patrimonial y con un funcionamiento plenamente democrtico, tal y como exige el
artculo 7.1 g) de la ley orgnica 1/2002 de 22 de marzo.
La Asociacin AEMES tiene por finalidad ltima contribuir a la difusin de los
mtodos y tcnicas relacionados con la gestin cuantitativa de las Tecnologas de la
Informacin y en particular con aquellos aspectos relacionados con la mejora del proceso
de desarrollo del software y su gestin econmica, en las empresas e instituciones que
las desarrollan o utilizan, promoviendo el uso de indicadores, mtricas y cuadro de
mando en las mismas.
Con este fin dirige sus actuaciones a:
a) Promover, coordinar y desarrollar actividades relacionadas con las medidas de
los procesos de las Tecnologas de la Informacin.
b) Favorecer el intercambio de informacin y experiencia entre los profesionales
relacionados con este tema.
c) Relacionarse con otras organizaciones internacionales afines.
d) Difundir informacin al pblico en general sobre la gestin econmica de las
Tecnologas de la Informacin.
e) Crear comits y grupos de trabajo especializados en estos temas.
f) Canalizar la formacin de especialistas en este campo, facilitando el acceso a
titulaciones especficas y en concreto las promovidas por el International
Function Points Users Group.
g) Canalizar las peticiones de certificaciones de puntos funcin y de otras
mtricas del software relativas a aplicaciones solicitadas por empresas.
h) Homologar y mantener un registro de profesionales, material docente y otros
que puedan ser utilizados para los fines de la asociacin.
Revista fundada por la Asociacin

Espaola de Mtricas del Software
(AEMES)
<http://www.aemes.org>
Editores
Dr. D. Jos Carrillo Verdn, Asociacin
Espaola de Mtricas de Sistemas
Informticos
Dr. D. Jos Antonio Gutirrez de Mesa.
UAH
Consejo Editorial
D. Jess Campo Prieto, E-work-LINE
D. Ramiro Carballo, Gesein
D. Jos L. Lucero, IEE
D. Emilio del Moral, ALI
D. Luis Redondo Lpez, MTP
Da. Cecilia Rigoni, Asesora de AEMES
D. Edmundo Tovar Caro, UPM
D. ngel Snchez Daz, EVERIS
Comit Cientfico
Dr. Jos D. Carrillo. UPM
Dr. D. Jos Antonio Gutirrez. UAH
Dr. D. Eladio Domnguez Murillo. UNIZAR
Dr. D. Jos Javier Martnez, UAH
Dr. D. Jos Mara Gutirrez, UAH
Dr. D. Roberto Barchino Plata, UAH
Dr. D. Luis de Marcos Ortega, UAH
Revisores
Dra. Da. Elena Garca. UAH
Dr. D. Jos Ramn Hilera. UAH
Dr. D. Edmundo Tovar Caro. UPM
Dr. D. Jos Antonio Calvo-Manzano. UPM
Dr. D. Toms San Feli. UPM
Dr. D. Oscar Pastor. UPV
Dr. D. Jos Mara Gutirrez. UAH
Las opiniones expresadas por los autores
son responsabilidad exclusiva de los
mismos. Revista de Procesos y
Mtricas de las Tecnologas de la
Informacin permite la reproduccin de
todos los artculos, a menos que lo
impida la modalidad de copyright elegida
por el autor, debindose en todo caso
citar su procedencia.
ISSN: 1698-2029
N Depsito: M23879-2006
Maquetacin
Luis de Marcos
Ana Beln Snchez Daz
Impresin
Imprenta UAH
1. Propsito de la Sociedad
2. Asociados
La asociacin se compone de dos clases de asociados: Miembros de Nmero y Miembros
Honorficos.
Los Miembros de Nmero son las personas fsicas o entidades que participan
regularmente en las actividades de la asociacin. La asociacin est abierta, sin
discriminacin, a todas las personas fsicas o entidades, sean estas organizaciones
pblicas o privadas, que estn interesadas en promover los fines y actividades de la
asociacin.
Los miembros de Nmero ingresan en la asociacin previa solicitud dirigida a la junta
directiva (El formulario se encuentra las pginas finales de esta revista).
3. Beneficios de la Asociacin
Los miembros de Nmero gozan de la plenitud de derecho en orden a participar en los
rganos de Gobierno de la asociacin, tanto en la Asamblea General como en la Junta
Directiva, siempre con sujecin a lo previsto en los estatutos y de acuerdo con las
directrices y normas fijadas por la Junta Directiva.
Los miembros de Nmero tienen derecho a participar en las actividades y actos sociales
en la forma, en que cada caso, disponga la Junta Directiva.
Los miembros de Nmero tienen derecho a recibir sin coste alguno las publicaciones
peridicas realizadas por la asociacin.
4. Publicaciones de la Asociacin
Boletn de la Asociacin Espaola de Mtricas de Sistemas informticos.
Publicacin de periodicidad trimestral cuyo contenido est centrado fundamentalmente
en la actividad interna de la asociacin. Se describen tambin nuevos recursos como
libros o herramientas software de inters para los asociados. Tambin se comentan
aquellos eventos de especial relevancia relacionados con la gestin de los Procesos de
las Tecnologas de la Informacin y las Comunicaciones.
Revista de Procesos y Mtricas de las Tecnologas de la Informacin.
Publicacin de periodicidad cuatrimestral cuyo contenido est formado por artculos
cientficos revisados por pares y enfocados en las reas de inters de la asociacin.
RPM-AEMES, VOL. 5, N 3, Octubre 2008
ISSN: 1698-2029
EL BUEN
GOBIERNO DE LA SEGURIDAD
Miguel ngel Thomas
Resumen:
La seguridad en los sistemas de informacin y la organizacin entorno a la misma es una preocupacin creciente
en las empresas y organizaciones actualmente. El presente artculo explica la evolucin actual del Gobierno de la
Seguridad en las empresas, el ciclo de vida del programa de seguridad as como los principios y reas de gobierno. El enfoque del artculo se basa en nuestra experiencia real en la implantacin del Gobierno de la Seguridad
dentro de grandes organizaciones.
Abstract:
Information Systems security procedures and supporting organization is becoming an increasing concern among
enterprises. This paper deals with the evolution of the IT Security Governance in different organizations, the Security Program Lifecycle and the fundamental application areas and principles. The approach displayed in this
article is based on our experience in several project engagements, deploying Security Governance framework in
big corporations.
Palabras clave:
Gobierno de las Tecnologas de la Informacin, Seguridad Informtica, Gestin de Riesgos Tecnolgicos.
1. SITUACIN ACTUAL
La evolucin actual del Gobierno de la Seguridad en las empresas, generalmente representados por los departamentos de Seguridad, se centra principalmente en el concepto de Seguridad Distribuida. En la
prctica el mbito de la seguridad dentro de
una organizacin abarca normalmente todas
las reas y departamentos:
desde la propia infraestructura

tcnica (hardening, parcheado sistemas, segmentacin de redes, )
pasando por el ciclo de vida del SW
(toma de requerimientos de seguridad
en las primeras fases, desarrollo de
mdulos seguros, buenas prcticas de
codificacin, pruebas de seguridad).
teniendo en cuenta los aspectos legales y regulatorios de aplicacin a toda la organizacin (LOPD, LSSI,
SOX, MIFiD, etc).
llega incluso a tomar de decisiones
estratgicas a nivel comercial (uso de
certificados digitales, implementar la
seguridad como un valor diferencial
por ejemplo en dispositivos mviles,
etc.)
Por lo tanto, es realmente difcil que un nico departamento de Seguridad sea capaz de
ejecutar directamente todas las iniciativas en
cada uno de los mbitos de aplicacin.
En la prctica, las tareas diarias que realizan
los departamentos de Seguridad dependen
directamente del nivel al que reporten y
dnde estn ubicados. Por ejemplo no es lo
mismo un departamento de Seguridad que
est dentro del rea de TI y reporta a la direccin de sistemas que un departamento de
Seguridad que reporta directamente al CEO
y est a la altura de las direcciones de Negocio.
No obstante, generalmente el Gobierno de la
Seguridad en una organizacin suele centrarse en dos tipos de actividades claramente
diferenciadas:
- 57 -
Por un lado, existe una primera etapa

en dnde se define un framework de
Seguridad para toda la organizacin y
se definen una serie de controles que se
deben de cumplir en la mima. Tras esa
etapa, el rea de Seguridad se ocupa de
controlar que el resto de reas y departamentos de la organizacin implementan y cumplen dichos controles. Es
decir, el rea de seguridad coordina,

controla, supervisa y da soporte al resto
de reas para que la seguridad se implemente correctamente.
Adems suelen existir un conjunto de
proyectos que ejecuta directamente (o
subcontrata) y que son nicamente de
su competencia. Ejemplos pueden ser
los Sistemas de Gestin de la Seguridad (ISO27001) o implementaciones
de Sistemas de Gestin de Identidades
o Consolas Centralizadas de logs, etc.
el momento plantearse la certificacin. El

camino contrario es ms costoso y penoso,
no garantizando llegar a gestionar correctamente la seguridad.
El grfico que a continuacin se muestra
indica el proceso de gestin, a alto nivel que
debera realizar el rea de Gobierno de la
Seguridad:
Ciclo de Vida del Programa de Seguridad
Estrategia
Otro dato importante que hay que tener en

cuenta dentro del mbito del Gobierno de la
Seguridad, es que en la actualidad, cada vez
ms se estn creando departamentos de Seguridad con personal especializado. Adems
muchos de estos cuentan con apoyo externo
a la propia organizacin.
Poltica
Cumplimiento
Gobierno de la
Seguridad
Concienciacin
Monitoreo
Implementacin
De
te
Corr
e
2. PROCESOS DE GOBIERNO
Prevenir
ct a
gir
ISSN: 1698-2029
Figura 1. Ciclo de Vida del Programa de Seguridad.
El Gobierno de la Seguridad debe dar cobertura a todos los componentes bsicos de un

programa de seguridad, cubriendo las tareas
bsicas solicitadas por las reas de negocio y
la alta direccin de la organizacin.
Actualmente la norma ms extendida que

indica los diferentes puntos de control sobre
la seguridad en cualquier organizacin, sin
lugar a duda es la ISO27001/ISO27002.
Alrededor de este modelo se debera estructurar el Gobierno de la Seguridad, no obstante debe ser siempre una gua que ayude a la
organizacin y nunca debe llegar a convertirse en un elemento que complique u obstaculice la seguridad. Tambin me gustara
indicar que el hecho de utilizar la ISO27001
como modelo de referencia no tiene porqu
implicar que la organizacin tenga que
certificarse contra esta norma.
Es preferible ir implementando paulatinamente los controles ms necesarios y si llega

- 58 -
Estrategia. A partir de la propia estrategia de negocio de la organizacin se

deben identificar los nuevos objetivos y
estrategias de seguridad. Esta estrategia
debe estar soportada en los estndares
de gestin de la seguridad y debe cumplir con la normativa y regulacin actual, adems de evidentemente dar soporte a los objetivos del negocio.
Poltica. El rea de seguridad debe crear, revisar y mejorar la poltica, normas
y procedimientos de seguridad de la
organizacin en base a estndares y
buenas prcticas reconocidas internacionalmente y a las directivas del negocio.
Concienciacin. Un tema imprescindible que debe promover directamente el
rea de seguridad es la concienciacin,
sensibilizacin y formacin. Debe
promover el conocimiento y utilizacin
ISSN: 1698-2029
de los recursos de seguridad entre los

usuarios de los sistemas de la organizacin diseando y desarrollando planes
de formacin y concienciacin y liderando iniciativas encaminadas a la implantacin de dichas medidas.
Implementacin. Debe realizar tareas
de gestin en la implementacin de los
proyectos asignados al rea de seguridad de la informacin. Realizar tareas
de deteccin de desviaciones, soporte
tcnico y anlisis de seguridad, proponiendo las medidas preventivas y/o correctivas que se estimen oportunas.
Gestionar las actividades encaminadas
a la implantacin de los controles de
Seguridad definidos por la organizacin interactuando con las reas de negocio y tecnologa implicadas.
Monitoreo. Una funcin muy importante que debe realizar el rea de seguridad son las revisiones del funcionamiento de los procesos de seguridad ya
implantados. Es imprescindible disponer de mtricas y cuadros de mando
que permitan conocer en todo momento el estado y la eficacia de los controles implantados.
Cumplimiento. Detectar, proponer e
implantar las acciones necesarias para
cumplir con el marco legal vigente que
afecta al desarrollo del negocio de la
organizacin desde el punto de vista
del rea de seguridad.
4. REAS DE GOBIERNO
Otro modo de enfocar el gobierno de la seguridad, en vez de a nivel de procesos, es
hacerlo segn las competencias que deba de
asumir en la organizacin. Evidentemente, y
tal y como se ha presentado al inicio del presente artculo, estas competencias dependern mucho del nivel de interlocucin que
tenga en la organizacin.
No obstante, y de un modo genrico las
competencias se podran agrupar como sigue:
3. PRINCIPIOS DEL BUEN GOBIERNO

De acuerdo a los requisitos de alto nivel expresados anteriormente, es importante establecer una serie de criterios que deberemos
tener en cuenta en la definicin de la funcin
de seguridad:
por otras funciones dentro de la organizacin.

Principio de resolucin de intereses.
La funcin de seguridad debe estar definida de tal manera que se garantice el
no conflicto de intereses, y en el caso
de que esto se presenten en alguna de
sus funciones, debe proveer los mecanismos necesarios para solventarlo.
Principio de autoridad. La funcin de
seguridad debe disponer de la autoridad
necesaria para ejercer sus funciones
con las garantas correspondientes.
Principio de universalidad. La funcin de seguridad debe tener carcter
global y nico dentro de la organizacin.
Principio de responsabilidad. La funcin de seguridad ser la responsable
de todos los aspectos relacionados con
la seguridad dentro de la organizacin.
Anlisis
Auditoras
Riesgos
Gobierno Seguridad
Soporte
Principio de independencia. La funcin de seguridad no debe estar condicionada en el nivel tctico y operativo
Tcnico
Formacin
Concienciacin
Proy.
Sensibilizacin
Figura 2.
- 59 -
ISSN: 1698-2029
El rea de Gobierno de la Seguridad trabaja

en temas relacionados con los estndares, polticas, procedimientos de Seguridad, incluyendo
la vertiente legal. Aqu se muestran una serie
de tareas que podra realizar:
Definir y mantener la Poltica de Seguridad que ser de aplicacin a toda la

organizacin.
Definir las Normas y Estndares de
Seguridad que aplicarn a todos los
equipos involucrados en la definicin,
implantacin y mantenimiento de la
Seguridad (normas de desarrollo de
SW, normas de securizacin de mquinas, normas de control de accesos, salida de soportes, etc).
Seleccin de Controles ISO27002,
PCI-DSS,
ISO15408,
SOX,
LOPD/RMS, etc. que aplicarn a toda
la organizacin. Validacin de los controles con la Direccin la organizacin
y redaccin del SOA (lista de controles
aplicables).
Revisin y aprobacin de los procedimientos de seguridad asociados a los
diferentes equipos (manuales de instalacin de SW, HW, etc).
El rea de Anlisis de riesgos trabajar con

todos los temas relacionados con el anlisis y
gestin de riesgos de los Sistemas de Informacin, generalmente trabaja con las metodologas como Magerit, CRAMM o ISO 13335-3,
ISO27005. Aqu se muestran una serie de tareas que podra realizar:
Inventario y clasificacin de activos.

Anlisis de vulnerabilidades de los sistemas.
Identificacin de amenazas.
Ejecucin de BIA (Anlisis de Impacto
en el Negocio) para evaluar el impacto.
Seleccin de Salvaguardas.
Evaluacin del Riesgo.
Gestin de Riesgo (implantacin y seguimiento de controles).
El rea Formacin, Concienciacin y Sensibilizacin tiene como uno de los principales

objetivos que todos los proveedores y el propio
personal de la organizacin, conozcan y estn
sensibilizados en materia de confidencialidad,
requerimientos legales y tcnicos de obligado
cumplimiento por la normativa en materia de
proteccin de datos de carcter personal y en
Seguridad en general. Aqu se muestran una
serie de tareas que podra realizar:
El rea de Auditoras se ocupa fundamentalmente de la revisin de la implantacin del

framework definido. Tambin, dentro del
mbito de la legislacin Espaola trabaja en la
auditora de LOPD, auditoras de vulnerabilidades e implantacin de las medidas exigidas
en el Reglamento de Medidas de Seguridad.
Aqu se muestran una serie de tareas que podra realizar:
Realizar auditoras de cumplimiento

normativo de estndares: ISO27001,
ISO 15408 y PCI-DSS.
Realizar pruebas de vulnerabilidades de
las plataformas.
Seguimiento y soporte a las acciones
correctivas.
Crear el programa de Auditora y seguimiento de controles.

Crear la metodologa asociada a las auditoras.
Realizar auditoras de cumplimiento
normativo legal: LOPD y LSSI.
- 60 -
Presentaciones divulgativa de la importancia de la Seguridad y de saber qu

tiene que hacer cada persona en caso de
tratar ficheros con datos personales, detectar incidentes de seguridad y de las
implicaciones de no hacerlo.
Creacin de trpticos auto explicativos.
ISSN: 1698-2029
Creacin de tests para que cada persona

pueda conocer si sabra cmo actuar en
caso de un incidente de seguridad (esta
tarea, aunque sea genrica permite que
el usuario reclame formacin).
Elaborar mensajes estndar de correo
electrnico para que sean divulgados.
Jornadas de formacin sobre las polticas, estndares y procedimientos de
trabajo en materia de proteccin de datos y medidas de seguridad. Estos mensajes sern diferentes en funcin de los
perfiles que se determinen como audiencia objetivo, en principio se plantearan tres tipos de perfiles: perfiles directivos (alta direccin), perfiles gestores y perfiles usuarios/operadores.
El rea de Soporte se ocupa del soporte, tanto

tcnico como a nivel de desarrollo de las aplicaciones, generalmente tiene amplios conocimientos en aspectos relacionados con la instalacin y configuracin de firewalls, antivirus,
sistemas de deteccin de intrusos, desarrollo
seguro, etc. Las principales tareas que realiza
son las siguientes:
establecidos por el rea de Gobierno,

control y seguimiento de los ciclos de
pruebas, etc).
Gestin de los entornos y evoluciones
tecnolgicas de la Seguridad (gestin
de la configuracin de la seguridad, estudios de viabilidad de mejoras de la
aplicacin y evolucin tecnolgica de
los entornos en materia de seguridad,
coordinacin del paso a produccin de
los sistemas de seguridad como antivirus, firewalls, ids, etc...)
Coordinacin de las lneas de trabajo
entre los entornos no productivos y
productivos.
Diseo, configuracin y monitorizacin del sistema de deteccin de intrusiones, consola de logs, instalacin y
configuracin de las herramientas para
el anlisis de vulnerabilidades, etc
5. INTEGRACIN DEL GOBIERNO DE

SEGURIDAD EN EL CICLO DE VIDA
DE LOS PROYECTOS
Por ltimo y a modo de ejemplo, vamos a
mostrar cmo se puede integrar el Gobierno de la Seguridad en el Ciclo de Vida de
los Proyectos. Las competencias que asumir el Gobierno de la Seguridad, en este
caso, estn orientados a cubrir las necesidades de gestin de proyectos de seguridad
y de resolucin de incidencias o dudas dentro del mbito de la seguridad de una organizacin.
Gestin de los requisitos de Seguridad,

su objetivo principal es el estudio de
todos los requisitos de Seguridad: ver
como se empaquetan en las diferentes
implantaciones (planificacin de los
requisitos de seguridad, gestin de alcance para nuevos requisitos de seguridad, gestin de los cambios de alcance
en las releases e implantaciones existentes, evaluar los anlisis funcionales
y diseos tcnicos para identificando el
impacto en la Seguridad)
Realizar el aseguramiento de la Seguridad de los desarrollos implicados en los
diferentes entornos, asegurar el conocimiento y aplicacin de los estndares
de desarrollo definidos (mantenimiento
y aplicacin de estndares y mecanismos de aseguramiento de la seguridad
En este sentido, la gestin de proyectos de

Seguridad se realizar en funcin del estado del ciclo de vida de los proyectos (viabilidad de proyectos, proyectos nuevos y
mantenimientos) y de la interrelacin existente entre los mismos:
- 61 -
ISSN: 1698-2029
Para los controles propuestos se adjuntarn las

estimaciones a alto nivel de coste/beneficio con
el fin de ayudar a los responsables a seleccionar los controles ms adecuados en cada momento para cada nuevo desarrollo.
ci
ina
um
en
tac
i n
n
i
luc cias
o
s n
Re cide
In
Nuevos
desarrollos
trol
Con ad
d
cali
d
or
Co
c
Do
Mantenimiento
operativo y correctivo
Viabilidad
Mantenimiento
preventivo y evolutivo
Mapa Competencias
Figura 3. Mapa de Competencias.
Viabilidad de Proyectos - Anlisis de

proyectos. En este caso el rea de Seguridad realiza tareas de anlisis de
viabilidad de los requisitos de seguridad para los proyectos solicitados por
los responsables del negocio o tcnicos.
Se identifican los requerimientos tcnicos y funcionales de Seguridad necesarios y se propone su viabilidad para la
integracin en la arquitectura de seguridad existente.
Nuevos desarrollo. Los responsables
de la organizacin plantean al rea seguridad los proyectos nuevos que se
desean ejecutar, describiendo los requerimientos tcnicos y funcionales de los
mismos y su propuesta del nivel de seguridad que pretendan dotarles, a alto
nivel.
Mantenimiento preventivo y evolutivo. Para las aplicaciones/sistemas ya

existentes se revisa su nivel actual de
seguridad y los controles que estn implantados. Se analiza su grado de efectividad y el beneficio que aporta. Se
toma como referencia los requerimientos de seguridad planteados internamente por la normativa de seguridad
vigente y se priorizan las iniciativas de
seguridad para cada sistema/aplicativo.
El rea de seguridad se encarga de realizar el

seguimiento de los proyectos en donde est
involucrados los requerimientos de seguridad y
colaborando en las pruebas que sean necesarias.
Adems, el rea de seguridad se encarga de la
supervisin de los pasos a produccin de los
controles, gestionando los recursos necesarios
y proponiendo las fechas ms convenientes
para minimizar el impacto de los mismos y
asegurar su correcto funcionamiento.
Partiendo de esta informacin y del conocimiento que dispone el rea de seguridad de la

arquitectura de aplicaciones de la organizacin,
el rea de seguridad analizar los requerimientos individuales de seguridad y su integracin
en la arquitectura de seguridad ya desplegada
(SAS 70, SOX, LOPD, LDAP, TIM, PKI, comunicaciones, etc.) y propondr los controles
necesarios para conseguir el nivel de seguridad
propuesto.
- 62 -
Mantenimiento operativo y correctivo. El rea de seguridad realiza las tareas de gestin del mantenimiento operativo y correctivo de la misma forma
que el mantenimiento preventivo y
evolutivo pero teniendo en cuenta las
caractersticas de este tipo de proyectos.
Coordinacin de actividades. Realiza
funciones de coordinacin de proyectos
multi-sistema, independientemente de
los equipos y/o proveedores implicados. Estos proyectos tienen como elemento comn la seguridad.
Control de calidad. El rea de seguridad realiza las tareas de revisin de calidad siguiendo los estndares y metodologas proporcionadas por el marco
de seguridad de la organizacin de
forma que se garantiza la calidad de los
proyectos en los que intervenga el rea
de seguridad.
Revisa la calidad de los entregables relacionados con los entornos productivos de forma que
evaluar su validez en funcin de los estndares fijados y su cumplimiento con los requerimientos de seguridad solicitados. Colaborar
definiendo planes de pruebas y ejecutando las
pruebas que sean necesarias para aprobar los
pasos a produccin desde el punto de vista de
seguridad.
ISSN: 1698-2029
zando los formatos estndares de la organizacin. Toda la documentacin generada queda a disposicin de la organizacin en los repositorios que sta
designe.
Escalado y resolucin de incidencias.
El rea de seguridad se encarga de la
gestin de las incidencias dando el soporte necesario a los responsables de la
organizacin, tanto internos como externos, que se puedan ver involucrados
en la resolucin de las mismas.
6. REFERENCIAS.
[1] CISM, Certified Information Security Manager,
Review Manual 2008 ISACA.
[2] JTC 1/SC 27. ISO/IEC 27001:2005, International
Standards for Business, Government and Society.
Documentacin. El rea de seguridad

se encarga de generar la documentacin requerida para realizar el seguimiento de las tareas que realiza utili-
[3] COBIT 4.1, IT Governance Institute

[4] Governing for Enterprise Security Implementation
Guide, CERT
- 63 -
ISSN: 1698-2029
GOBERNADOR DE TI: NACE UN NUEVO PUESTO EN EL NIVEL DIRECTIVO

Miguel Garca Menndez
Atos Consulting
miguel.gmenendez@atosorigin.com
Resumen:
El IT Governance est aqu para quedarse. Como ya ocurriera a principios de esta dcada con la Seguridad, hoy la palabra de moda es, sin duda, Gobernanza. Eso, al menos, parecen indicar todas las alarmas,
a la vista del creciente inters sobre el tema que ha venido observndose, en el ltimo ao y medio, en el
mercado espaol. Bajo esa premisa, el presente artculo propone la creacin de una nueva figura en las
organizaciones: el Gobernador de las TIC, y describe un posible perfil para estos nuevos directivos. A
partir de ah, se plantean una serie de dudas: estn los actuales responsables de Tecnologa preparados
para asumir ese nuevo papel?, constituye, para ellos, una oportunidad nica de ascender al nivel directivo? cabra pensar que el perfil descrito debera ser, tambin, el de los profesionales que asesoran a las
organizaciones en este mbito? Existe algn tipo de iniciativa formativa orientada a ayudar a moldear a
los actuales profesionales en la horma de la nueva figura?
Abstract:
Information Systems security procedures and supporting organization is becoming an increasing concern
among enterprises. This paper deals with the evolution of the IT Security Governance in different organizations, the Security Program Lifecycle and the fundamental application areas and principles. The approach displayed in this article is based on our experience in several project engagements, deploying Security Governance framework in big corporations.
Palabras clave:
Buen gobierno corporativo de las TIC, Gobernador de TI, CGO, CGEIT.
1. INTRODUCCIN
Los Consejos de Administracin y las Direcciones Generales han comprendido, desde
hace tiempo, la necesidad de establecer marcos de buen gobierno corporativo. Esto se
hace particularmente evidente si se tienen en
cuenta las crecientes obligaciones en materia
de conformidad regulatoria.
Ms an, los Sistemas de Informacin, y las
Tecnologas de la Informacin y las Comunicaciones que los sustentan, han adquirido
una gran relevancia en el logro de los objetivos corporativos y en la entrega de beneficios. Ello ha llevado a un importante nmero
de organizaciones a darse cuenta de que la
gobernanza ha de extenderse tambin al
mbito tecnolgico; hasta tal punto, que, hoy
en da, el buen gobierno de las TI es considerado una parte integrante de la gobernanza
corporativa, como medio de apoyar y reforzar las estrategias y objetivos de la organizacin.
Este escenario (con una creciente demanda,

por parte del negocio, de la aportacin que
ofrece la tecnologa; y con una superior concienciacin sobre la importancia de contar
con buenas prcticas y modelos) abre un
claro camino hacia el desarrollo y despliegue
de la Gobernanza de TI.
Como parte de este despliegue, y dado que
la direccin (gobierno) de las TI ya no ha de
verse como una preocupacin exclusiva de la
Direccin de Informtica, sino de la alta direccin en su conjunto, est surgiendo una
nueva figura a nivel directivo: el Gobernador corporativo de TI (Chief [IT] Governance Officer, o CGO, como recogera la
bibliografa anglosajona).
Como ventaja aadida, el establecimiento de
un puesto tal, dentro de la organizacin, supondr una demostracin palpable del compromiso de aquella con la excelencia en las
buenas prcticas de gobernanza de TI.
- 64 -
ISSN: 1698-2029
2. CON LA MIRA PUESTA EN EL NEGOCIO

En el nuevo contexto, la misin del gobernador de TI ser proporcionar el debido apoyo
al Consejo de Administracin y a la Direccin General, maximizando la contribucin
hecha por las Tecnologas de la Informacin
al xito de la organizacin y, al mismo tiempo, gestionando y mitigando los riesgos derivados del uso que se hace de la propia tecnologa.
3. EL PERFIL
Entre las responsabilidades (o, dicho de otro

modo, habilidades) de los profesionales que
desarrollen su actividad entorno a la gobernanza de las TI en sus respectivas entidades,
cabe descatar las siguientes:
debern conocer las actuales tendencias, as como los principales modelos

organizativos y de direccin de TI, y
saber armonizar y canalizar su valor
para la entidad. Esta meta se alcanzar
mediante el establecimiento de procesos de implantacin y despliegue de
dichos marcos de referencia para el
gobierno, la direccin y el control de
las TI a lo largo y ancho de la organizacin;
debern ser capaces de asegurar que las
TI actuan como catalizador para el logro de los objetivos del negocio, mediante la integracin de los planes estratgicos de TI con los planes estratgicos de la organizacin y mediante la
sincronizacin de los servicios prestados desde TI con las operaciones de la
compaa para optimizar los procesos
de negocio. A ello contribuir el desarrollo de una estrategia tecnolgica
de la empresa;
debern, asimismo, encargarse de garantizar que, tanto TI, como las reas
- 65 -
de negocio, cumplen con sus responsabilidades sobre la gestin del valor: esto es, que las nuevas inversiones en actividades apoyadas en tecnologa producen el beneficio esperado y aportan
un valor al negocio, medible, tanto invididual, como colectivamente; que las
capacidades (soluciones y servicios)
son entregados en tiempo y coste; y
que los servicios y otros activos de TI
contribuyen de manera contnua al valor del negocio. Todo ello, mediante el
desarrollo de un proceso de gobierno
del valor;
adicionalmente, los gobernadores de TI
debern asegurar la existencia y puesta
en marcha de marcos apropiados, alineados con las normas y modelos de
referencia, para identificar, evaluar, mitigar, gestionar, comunicar y supervisar
los riesgos del negocio relacionados
con las TI, como una actividad ms del
buen gobierno de la empresa. Todo
ello, mediante el desarrollo, mejora y
mantenimiento de un proceso contnuo y analtico de gestin de los riesgos empresariales;
estos nuevos directivos debern ocuparse de que el rea de TI disponga de
recursos suficientes, competentes y capaces de ejecutar los objetivos estratgicos presentes y futuros, y de responder a las demandas del negocio, a
travs de una optimizacin de la inversin, del uso y de la ubicacin de los
activos tecnolgicos (aplicaciones, informacin, infraestructuras y personal).
Todo ello, mediante la puesta en marcha de un proceso contnuo de planificacin, gestin optimizada y evaluacin de recursos;
igualmente, debern asegurar que se establecen metas e indicadores para las
TI, de apoyo al negocio, en colaboracin con las partes interesadas; y que se
fijen, supervisen y evaluen ciertos obje-
tivos medibles. Todo ello, mediante

procesos contnuos de gestin y evaluacin del rendimiento;
finalmente, debern ser capaces de actuar como impulsores del cambio cultural y organizativo dentro de la entidad;
a lo cual se llegar, a travs de la activacin del oportuno programa de
comunicacin y gestin del cambio
que habr de mantenerse en el tiempo y
en paralelo a la implantacin de las
nuevas prcticas y procesos adoptados
dentro de la organizacin.
Se trata, en definitiva, de habilidades y actividades directamente relacionadas con la definicin, el establecimiento y/o el mantenimiento
de un marco de referencia para la gobernanza de las TI (materializada en liderazgo,
estructuras organizativas y procesos) para: asegurar la sincronizacin con el buen gobierno de
la entidad; controlar el entorno de TI y la informacin de negocio mediante la puesta en
marcha de las mejores prcticas; y garantizar la
conformidad con los requisitos externos.
4. UNA REFLEXIN FINAL
Pero, acaso, el perfil descrito se corresponde
solamente al esperado de un directivo encargado del buen gobierno de las TI, dentro de su
organizacin?; o, de hecho, no se tratar, tambin, de un catlogo de competencias con las
que debera contar toda la comunidad de asesores y consultores que prestan sus servicios en el
mbito de referencia?
Tal vez la respuesta venga dada por la creciente
oferta acadmica de postgrado que, sobre el
Buen Gobierno de las TIC, diversas entidades
pblicas y privadas estn poniendo en marcha
en los ltimos tiempos. La ltima iniciativa en
este sentido, llega, una vez ms, de la mano de
ISACA (www.isaca.org) y su Instituto para el
Buen Gobierno de las TI (www.itgi.org): bajo el
acrnimo CGEIT (Certified in the Governance
ISSN: 1698-2029
of Enterprise IT) (www.isaca.org/cgeit) propone

una nueva certificacin profesional, con la que
tratar de reconocer las competencias y habilidades mnimas, requeridas en aquellos profesionales del sector encargados de asesorar a las
organizaciones en la puesta en marcha y el
mantenimiento de marcos de gobernanza de TI
que permitan a sus equipos directivos atajar las
actuales diferencias existentes entre los objetivos del negocio, los objetivos de la funcin
informtica y sus procesos; y comprender el
modo de enfrentarse a los riesgos de la empresa que se deriven del creciente empleo de la
tecnologa.
5. REFERENCIAS.
[1] ISO/IEC 38500:2008. Corporate Governance of
Information Technology. International Organization
for Standardization, 1-6-2008.
[2] Val IT 2.0. Enterprise Value. Governance of IT
Investments. IT Governance Institute, 2008.
[3] CobiT 4.1. Control Objectives for Information and
related Technology. IT Governance Institute, 2007.
[4] Audit programs currently in alignment with ISACAs
Model
Curriculum.
http://www.isaca.org/Content/NavigationMenu/Students_and_Edu
cators/Model_Curriculum/Programs_in_Alignment/Audit_Programs
_Currently_in_Alignment_with_the_Model_Curriculum.htm
[5] CGEIT, Certified in the Governance of Enterprise

IT.
http://www.isaca.org/Template.cfm?Section=CGEIT_Certific
ation&CONTENTID=43651&TEMPLATE=/ContentManage
ment/ContentDisplay.cfm
[6] CGEIT, Certified in the Governance of Enterprise

IT.
Exam
reference
material.
http://www.isaca.org/Template.cfm?Section=CGEIT_Certification
&Template=/TaggedPage/TaggedPageDisplay.cfm&TPLID=16&
ContentID=36126
[7] Garca Menndez, Miguel. Towards a new C-level

player. IT Strategy and Technology Newsletter.
Atos Consulting. August, 2007.
[8] Garca Menndez, Miguel. Gobernador de TI:
Nuevo garante de la calidad de las TIC dentro de la
organizacin. Calidad. Asociacin Espaola de la
Calidad. Febrero, 2008.
- 66 -
ISSN: 1698-2029
LA GESTIN CUANTITATIVA EN CMMI. RELACIN CON SPC Y

SEIS SIGMA
Anabel Manchn Diez.
Sopra PROFit.
1. INTRODUCCIN
CMMI es uno de los modelos ms conocidos
y empleados a nivel mundial, y cada da ms
y ms empresas lo emplean como estndar
para implementar Mejoras en sus Procesos
Software.
Con el nacimiento de las nuevas constelaciones CMMI, este modelo abarca no slo
las actividades del desarrollo de software

(CMMI for Development), sino tambin la
prestacin de los servicios (CMMI for Services) y la adquisicin del software por terceros (CMMI for Acquisistion), convirtindose
as en un modelo de buenas prcticas con
cobertura total para las empresas de TI.
CMMI mantiene su estructura de niveles de
madurez, as como la denominacin de los
mismos en todas sus constelaciones.
Figura 1.
Aunque los niveles de madurez 2 y 3 son los
ms empleados tanto en el mbito nacional
como internacional, cada da est ms en
auge el empleo de los niveles 4 y 5, conocidos como Niveles de Alta Madurez, donde la
Gestin Cuantitativa, basada en el empleo de
tcnicas estadsticas, es la clave para obtener
los Modelos de Rendimiento y Lneas Base a
seguir por los procesos clave del negocio,

que permitirn mejorarlos y obtener mejores
rendimientos que redunden en la mejora de
los beneficios de la compaa.
Las organizaciones que se encuentran en un
nivel 4, establecen objetivos cuantitativos
para calidad y ejecucin de los procesos y
- 67 -
les usan como criterios en la gestin de procesos y proyectos. Los objetivos se basan en
las necesidades de los clientes, usuarios finales, organizacin e implantadores de los procesos. La calidad y efectividad de los procesos se miden en trminos estadsticos y se
eliminan las causas especiales de variacin
para predecir su rendimiento.
En el nivel 5, la organizacin mejora sus
procesos en base a una comprensin cuantitativa de las causas comunes de variacin
inherentes en los procesos y se enfoca sobre
la mejora continua de la eficacia del proceso,
a travs tanto de la mejora incremental, como de la innovacin tecnolgica.
2. CUNDO APLICAR UNA GESTIN
CUANTITATIVA?
Para poder realizar una Gestin Cuantitativa
de los Procesos y Proyectos de la organizacin, es necesario que se den una serie de
premisas:
Los procesos son estables, se puede

establecer su rendimiento, sus lmites
de control y de especificacin.
Se dispone de un repositorio de
mtricas maduro, que permite establecer modelos de comportamiento y
lneas base de los procesos.
Se conocen las relaciones entre las diferentes variables que influyen en los
procesos, por lo que se pueden evaluar
estas relaciones y conocer aquellas que
son significativas.
Pero quiz la dificultad surge cuando se

cumplen estas premisas, pero no sabemos
qu herramientas emplear, cundo y
cmo. Entre las posibles herramientas que
nos pueden ayudar a realizar una gestin
estadstica de nuestros procesos y proyectos,
destacan dos:
ISSN: 1698-2029
SPC (Statistical Control Process)

Seis Sigma
3. QU ES SPC?
SPC (Statistical Process Control) es un conjunto de tcnicas estadsticas empleadas para
realizar un control sobre los procesos. Entre
estas tcnicas destacan las 7 Magnficas:
Grficos de Control
Histogramas
Hoja de Control
Diagrama de Procesos
Diagrama causa-efecto
Diagrama de Pareto
Diagrama de Dispersin
Muchas de estas herramientas son grandes

conocidas en la mayora de las empresas,
pero muy pocas son utilizadas para la resolucin de problemas o la identificacin de
dependencias y tendencias. Adems de las
7 Magnficas, hay otras herramientas en el
marco de SPC:
Variacin del Sistema de Medida:

R&R (Repetibilidad & Reproducibilidad)
Capacidad de Proceso
Grficas de Evolucin: Run Chart
Boxplot
Ensayos de Hiptesis
Diseos de Experimentos: DOE
Diagramas de Efectos Principales
o Diagramas de Interacciones
o ANOVA
Si no se dominan las tcnicas estadsticas ni la

orientacin ptima de estas herramientas, SPC
puede llegar a asustar a quien se plantea emplearlo: Qu herramienta utilizar?, cundo?,
cmo interpretar los resultados?,
Seis Sigma, a diferencia de SPC, plantea una
secuencia lgica de actividades asociadas al
- 68 -
ISSN: 1698-2029
empleo de herramientas, que ayudan a la organizacin a la utilizacin correcta de las mismas.
Figura 2.
4. SEIS SIGMA COMO INSTRUMENTO

DE MEJORA
minacin de defectos, teniendo como resultado

la mejora del rendimiento econmico de la
organizacin.
Seis Sigma fue ideada por Bill Smith, Jefe de

Calidad de Motorola, comenzando su implementacin en 1987. Es una metodologa orientada a la mejora de los procesos productivos,
cuya filosofa es trabajar mejor llevando a la
reduccin del nmero de fallos en los productos. Su objetivo es aumentar la satisfaccin del cliente mediante la prevencin y eli-
Sigma se refiere a la desviacin tpica, una

medicin de la variacin de los procesos, de su
capacidad, y el estndar Seis Sigma se refiere a
un proceso que tiene 6 desviaciones tpicas, 6,
entre el objetivo y el lmite de especificacin
ms cercano.
- 69 -
ISSN: 1698-2029
Figura 3.
La Sigma del Proceso, su capacidad, est ligada al rendimiento que obtenemos de l, que
est asociado a los defectos o errores que se
detectan, los DPMO (Defectos por Milln de
Oportunidades). As, un proceso de capacidad
6Sigma equivale a un rendimiento del
99,9997% y slo 3,4 defectos por cada milln
de oportunidades, DPMO.
En la tabla adjunta puede verse la relacin entre la capacidad de los procesos (su sigma), el
rendimiento que se obtiene de l y el nmero
de defectos que se espera encontrar por cada
milln de oportunidades (DPMO).
Rendimiento
99,9997%
99.976%
99.4%
93%
65%
50%
DPMO
3,4
6
233
66.807
308.537
500.000
Sigma
6
5
4
3
2
1
Tabla 1.
Un ejemplo puede darnos una idea de las implicaciones:
Supongamos una compaa elctrica, cuyo
proceso de encendido de las luces fuera
4Sigma, esto equivaldra a que las luces estaran apagadas casi 1 hora a la semana debido
a problemas o defectos en el suministro, si la
compaa mejorara la capacidad de este proceso hasta 6Sigma, los cortes de luz debidos a
errores en el suministro, se reduciran a slo 2
segundos por semana.
La metodologa 6Sigma presenta un Ciclo de

Mejora, denominado ciclo DMAIC (Define,
Measure, Analyze, Improve, Control), cada
una de las etapas se centran en:
- 70 -
Define: la Definicin del problema o

situacin que se quiere mejorar
Measure: la Medida de esta situacin
y recopilacin de datos histricos
Analyze: el Anlisis de los datos recopilados
Improve: establecer el Plan de Mejora
de la situacin o problema
ISSN: 1698-2029
Control: garantizar que se mantienen

las mejoras implantadas.
Asociada a cada una de estas etapas del ciclo

DMAIC, 6Sigma propone el empleo de las
herramientas estadsticas (SPC) ms adecuadas
ETAPA
Define
para cubrir el objetivo, con lo que minimizamos podemos dar respuesta a las preguntas que
nos surgan al emplear solamente SPC: Qu
herramienta utilizar? , cundo? , cmo interpretar los resultados?,
HERRAMIENTAS
QFD/Casa de la Calidad
Diagrama de Proceso
Diagrama Causa Efecto/ Ishikawa
Diagrama de Pareto
Measure
Diagrama de Proceso
Evaluacin del Sistema de Medida (R&R)
Capacidad de Proceso
Analyze
Herramientas grficas:
Boxplot
Time Series
Diagramas de Efectos Principales
Diagramas de Interacciones
etc.
Grficos de Control
Ensayos de Hiptesis
Improve
Grficos de Control
Ensayos de Hiptesis
Diseo de Experimentos (DOE)
Control
Grficos de Control
Auditoras
Mtodos conductuales
Mtodos a prueba de error
Tabla 2.
- 71 -
ISSN: 1698-2029
DE LA GESTIN POR PROCESOS AL B.P.M

Dr. Montgomery Lee,
PDF
Ignacio Fernndez,
Gas Natural Informtica
Cuando presentamos en Barcelona mi primer

libro editado en castellano, Ya s quien tiene tu
queso, en una escuela de negocios, EADA,
creo recordar, el presentador hizo mucho nfasis en el subttulo del libro, una frase ingeniosa
a la vez que provocativa: Las cosas se pueden
hacer bien como siempre
En fin, es fcil decir que hacemos las cosas

bien, pero no es tan fcil explicarlo.
No se les ocurra buscar en las enciclopedias el
significado, y mucho menos en Internet. Yo lo
hice, y las conclusiones fueron cuando menos
sorprendentes: Hacer las cosas bien es patrimonio casi exclusivo del ftbol, a excepcin
hecha de la primera referencia de todas, que es
de Hacienda, lo cual no es ninguna sorpresa,
porque es evidente que esta gente s que sabe
hacer las cosas bien...
En definitiva, si pensamos un poco, llegaremos
a la conclusin que hacer las cosas bien significa hacerlas cada vez con menos recursos, sin
que ello implique sacrificar calidad ni prestaciones.
Figura 1.
La discusin sobre la frase deriv al final en
una acalorada discusin acerca de lo que quiere
decir hacer las cosas bien. S, porque pese a
que todo el mundo utiliza esa sentencia, muy
pocos (o ninguno) son capaces de definir con
un mnimo de precisin su significado real.
Porque vamos a ver, cuando decimos que
hacemos las cosas bien, queremos decir que
las hacemos bonitas? baratas? Quiz de
forma ms rpida?..., pero claro, tambin podra ser con una mayor carga de diseo, o
pensndolo mejor... quiz de ms utilidad?...no obstante... no querremos decir
hacerlas ms fiables? ... o ms duraderas?....
Pero... Por qu hacer las cosas bien, si podemos hacerlas como siempre? Para qu complicarnos la vida? Mi insigne colega, el Dr.
Jos Mara Cervell, profesor de derecho, historiador y biblifilo, nos brinda la respuesta:
Hay que hacer las cosas bien por hacerlas bien
y porque es rentable
Toda esta disquisicin, aparte de ser una cua
publicitaria acerca de mi libro, el cual les recomiendo encarecidamente, creo que ilustra
perfectamente el tema de la gestin por procesos, porque esta filosofa no deja de ser un
aproximacin a hacer las cosas bien, de hecho
cada vez mejor, cambiando los viejos modus
operandi con los que hemos venido funcionando toda la vida en nuestros procesos de negocio.
- 72 -
Estos conceptos de gestin, en los procesos

industriales de de fabricacin se aplican de
forma masiva desde finales de la segunda guerra mundial, aunque seguramente tuvieron su
inicio a finales del siglo XIX, a partir de las
teoras de Frederic Taylor, el padre de los
mtodos y tiempos, y difusor de lo que se vino
en llamar el Management Cientfico.
Lo que se buscaba con todo esto era optimizar
los procesos de fabricacin, eliminando aquellas complejidades innecesarias, los cuellos de
botella, las acumulaciones de stocks intermedios, etc., de forma que los flujos de produccin fueran lo ms claros y directos posibles,
optimizando de este modo todos los medios de
produccin empleados, incrementando obviamente el beneficio de fabricacin.
Figura 2.
En definitiva, se tratara de pasar de los procesos de fabricacin artesanales, poco formalizados, basados en las habilidades y conocimientos del trabajador, con una baja capacidad de
produccin y repetibilidad, a las modernas
cadenas de montaje, en las que las piezas se
producen en serie con un alto nivel de fiabilidad, con procesos de montaje automatizados y
en muchos casos robotizados, con la mxima
reduccin de los stocks intermedios, ajustando
al mximo la productividad de todos los recursos, humanos y materiales, implicados en el
proceso de fabricacin.
ISSN: 1698-2029
Estas filosofas de mejora de procesos de fabricacin fueron concebidas en los Estados Unidos, fundamentalmente a partir de los estudios
de Demming y Juran, pero su implantacin de
forma efectiva se realiz en Japn, pas en el
que se aplicaron con xito y se perfeccionaron;
todo ello debido a la necesidad de reconstruir
un pas devastado por la guerra. De hecho, su
mximo impulso se obtuvo en la industria automovilistica nipona, y este hecho dio origen a
muchos modelos de referencia ampliamente
implantados en la actualidad como son el Lean
Manufacturing, Just-in-time y modelos de calidad total, entre otros. De hecho, se formalizaron y aplicaron con xito las filosofas de mejora continua, como el KAIZEN, de igual manera
que se consigui la implicacin de todo el personal en la consecucin de la mejora en la productividad y calidad de los productos fabricados, mediante lo que se vino en llamar los
Crculos de Calidad
En definitiva, todos estos modelos de calidad,
al igual que sus sucesores, como podra ser el
caso de Six Sigma, se basan en la definicin,
medicin y control del proceso productivo,
como base para su optimizacin posterior.
Ahora bien, todo esto que se ha aplicado con
xito demostrado a los procesos de fabricacin...es exportable a aquellos procesos de
negocio que no son de fabricacin, es decir, a
los procesos de soporte a los procesos de
servicio? es posible pasar de la ejecucin
artesana de los procesos administrativos de
desarrollo de sistemas, por ejemplo, a procesos
industrializados de soporte y servicios? Se
puede crear una cadena de montaje en la
tramitacin de un pedido? es posible industrializar el desarrollo y mantenimiento de aplicaciones? Se pueden eliminar los tiempos
muertos en la tramitacin de cualquier solicitud
administrativa interna en una empresa?
Figura 3.
- 73 -
Figura 4.
En definitiva... podemos industrializar todos
aquellos procesos que realizamos en nuestras
empresas que no sean estrictamente de fabricacin?
Y si la respuesta es afirmativa, deberamos
plantearnos cual debera ser el resultado esperado, que no es ms que la realizacin de dichos procesos de forma normalizada, lo cual
permitir facilitar su repetitividad, su medicin
y,a travs de sta, determinar las posibilidades
de optimizacin del proceso en cuestin, ya sea
simplificando los puntos de control, eliminando algunas de las tareas implicadas y, finalmente, evaluando la viabilidad tcnica y
econmica de su automatizacin.
Para todo ello, deberemos proceder de la misma manera que haramos en una cadena de
montaje, definiendo los pasos actividades que
componen el proceso y para cada uno de ellos,
identificar qu es lo que entra sale, quin
interviene, qu o quin en donde se frena el
flujo de trabajo, y, en definitiva, el valor aadido que todos y cada uno de los que intervienen
en el paso aportan al mismo, y si este valor se
puede incrementar. Para ello, convendra que
nos formulramos las siguientes preguntas:
Quin hace qu?

Cul es el coste de nuestros procesos?
Dnde estn los cuellos de botella?
Cul es la lgica de la secuencia de
avance del proceso?
Qu conocimientos se utilizan?
Qu datos se administran?
Qu sistemas de informacin se utilizan y qu procesos respaldan?
ISSN: 1698-2029
Responder a estas preguntas es, ni ms ni menos, la definicin de un proceso, o dicho en

otras palabras, un proceso es cualquier secuencia repetitiva de actividades que una o varias
personas desarrollan para hacer llegar una salida a un destinatario, a partir de unos recursos
que se utilizan o se consumen. Es decir, para
definir un proceso necesitamos conocer la secuencia de actividades que lo conforman, los
recursos implicados, ya sean materiales
humanos, los sistemas y herramientas que se
utilizan, los procedimientos y normas que aplican, y finalmente las mtricas e indicadores
que nos mostrarn el comportamiento del proceso.
Figura 5.
Resumiendo, implantar la gestin por procesos
implica, en primer lugar, identificar todos los
procesos relevantes, describirlos y analizarlos,
eliminar los puntos dbiles, reforzar los cuellos
de botella, eliminar los pasos innecesarios, en
definitiva optimizarlos. Adems se debe crear
una organizacin orientada a procesos, en la
cual cada uno de ellos tenga un propietario que
se responsabilice de su control y optimizacin,
de la misma forma que una cadena de fabricacin tiene siempre su responsable. Adems
debe asegurarse la integracin de los sistemas
de informacin que dan soporte al proceso y
garantizar que la infraestructura que los soporta
proporciona los tiempos de respuesta adecuados para que sta no se constituya en un cuello
de botella, pero sobre todo, es necesario establecer los mecanismos de seguimiento y monitorizacin, imprescindibles para conocer la
- 74 -
estabilidad del proceso y los resultados de las

acciones de optimizacin.
Todo esto en cuanto a la gestin por procesos,
pero quiz es un trmino anticuado. En estos
tiempos que corren nos bombardean con multitud de siglas que empiezan por BP, desde el
BPM(Business Process Management) al BPM
(Business Process Monitoring), pasando por el
BPM (Business Process Modelling), por no
hablar del BPA (Business Process Automation), el BPA (Business Process Analysis) y
sin olvidar el BPR (Business Process Reengineering). Toda esta ensalada de siglas no hace
ms que sembrar la confusin entre el respetable. Porque....qu significa BPM? Es un
cambio de paradigma en la gestin empresarial? Una filosofa de mejora continua? Un
conjunto de herramientas para conseguir lo
anterior? Herramientas sofisticadas para pintar
procesos? quiz una suite de herramientas
de automatizacin de procesos?
En primer lugar, debemos distinguir entre filosofa y tecnologa. BPM como filosofa es lo
que anteriormente hemos llamado gestin por
procesos, es decir, la industrializacin de los
procesos no productivos.
En muchas actividades empresariales, no es
necesario reinventar la rueda, puesto que existen modelos de referencia que proponen una
estandarizacin de los procesos basada en las
mejores prcticas de la industria. Entre ellos
podemos destacar el modelo ISO, que proporciona diferentes modelos de referencia para la
gestin de la calidad.
En el mundo de las tecnologas de la informacin, existen varios modelos de referencia. En
primer lugar, el modelo ITIL (Information
Technology Infrastructure), el cual define un
marco de trabajo de las mejores prcticas destinadas a la entrega de servicios de T.I; recientemente ha aparecido la versin 3 de este modelo.
En segundo lugar, el Modelo CMM (Capacity
Maturity Model), desarrollado por el Software
ISSN: 1698-2029
Engineering Institute de la Carnegie-Mellon

University, proporciona un conjunto de prcticas y procesos clave en el desarrollo de software, estableciendo diferentes estadios de madurez que se alcanzan a travs de la puesta en
prctica de determinados procesos claves en
cada nivel. Se considera el modelo de referencia en calidad de desarrollo de software, hasta
el punto que las mayores empresas de outsourcing de desarrollo estn certificadas en el nivel
5 de CMM, que es el mximo alcanzable.
Finalmente, el modelo COBIT (Control Objectives for Information and Related Technology)
establece un marco de gobierno para las organizaciones de tecnologas de la informacin, y
tiene como objetivo reducir el espacio existente
entre las exigencias de control, las cuestiones
tcnicas y los riesgos del negocio. COBIT
permite la buena prctica para el control de TI
en todas las reas de una organizacin.
En cuanto a la tecnologa, debemos distinguir
fundamentalmente entre las herramientas y los
motores. Entre las herramientas podemos distinguir aquellas que permiten modelizar los
procesos, las que permiten su automatizacin y
las que permiten establecer los mecanismos de
seguimiento, aquellas que presentan los resultados en cuadros de mandos llenos de grficos,
indicadores y relojes, al estilo del tablier de un
coche, por ejemplo. Los motores son las
herramientas que permiten automatizar el flujo
de actividades dentro de los sistemas de informacin, como son los motores de workflow,
que proporcionan la facilidad de automatizacin de la ejecucin de los diferentes pasos de
un proceso en base a las transacciones informticas implicadas en el mismo, los middleware
de Integracin, que permiten la integracin de
los diferentes sistemas informticos a travs del
traspaso de informacin, que puede ser transformada no, en base a reglas del negocio
programables.
Las herramientas de modelizacin, que son la
base para cualquier proyecto de automatizacin
basado en herramientas BPM, permiten dia-
- 75 -
ISSN: 1698-2029
gramar los procesos de negocio, identificando

todos los agentes que intervienen. Dado que
siempre estn soportadas por una base de datos, proporcionan funcionalidades de bsqueda
y anlisis de procesos.
Figura 8.
Figura 6.
En cuanto a las herramientas de simulacin, se
basan en las anteriores, que les proporcionan
los modelos de procesos, a los que agregan
caractersticas de capacidad, velocidad de ejecucin y dems limitaciones, lo que permite
simular el comportamiento de un proceso,
identificar los cuellos de botella y evaluar la
efectividad de los cambios producidos en un
proceso.
Para concluir, creo que es imprescindible distinguir entre la filosofa BPM y la tecnologa
que comparte siglas. Adems, cualquier proyecto de implantacin de herramientas BPM
debera pasar por implantar antes la filosofa de
gestin por procesos, puesto que es de todos
conocidos que no se puede mejorar lo que no
se mide y que automatizar un desastre solamente proporciona un desastre automtico.
Locura es hacer ms de lo mismo y pretender
alcanzar distintos resultados" - Albert Einstein
Si buscas resultados distintos, no hagas siempre lo mismo - Albert Einstein
La mejor estructura no garantizar los resultados ni el rendimiento. Pero la estructura
equivocada es una garanta de fracaso Peter
Drucker (1909-2005) Escritor y consultor estadounidense
El progreso y el desarrollo son imposibles si
uno sigue haciendo las cosas tal como siempre
las ha hecho - Wayne W. Dyer (1940-?) Escritor estadounidense
Figura 7.
Por ltimo, las herramientas de anlisis y monitorizacin proporcionan amplias capacidades
grficas para el anlisis del comportamiento de
un proceso, la evolucin de sus mtricas de
control y la plasmacin grfica, tanto de los
resultados de la simulacin como de las mejoras y optimizaciones propuestas.
El Dr. Montgomery Lee P.D.F. es profesor

universitario, conferenciante y escritor de reconocido prestigio. En Espaa se ha publicado
dos de sus obras, Ya s quien tiene tu queso
(Granica 2006) y El efecto Riverside (Granica,
2007)
Ignacio Fernndez es ingeniero industrial y
actualmente es el responsable de modelos de
referencia en Gas Natural Informtica.
- 76 -
ISSN: 1698-2029
ENTERPRISE AND IT ARCHITECTURE: LAS CLAVES DEL

GOBIERNO DE TI
ngel Snchez
P de la Castellana, 141 planta 9
28046 Madrid
www.everis.com
Resumen:
Una de las principales preocupaciones de las reas de sistemas es el alineamiento con los procesos de negocio,
as como el uso eficiente de sus recursos TI o, de una manera ms general, de sus activos de proceso. Estos dos
objetivos se pueden cumplir simultneamente usando los principios y mtodos de las Enterprise Architectures
(EA), que persiguen la replicacin y uso eficiente de los recursos tecnolgicos y del negocio siguiendo las necesidades de las reas de negocio. Una estrategia de EA empieza con la identificacin de todo aquel elemento candidato a ser replicado a otras localizaciones o reas organizativas o, simplemente, susceptible de ser mejorado en
la bsqueda de la eficiencia. Estos "bloques" se componen de hardware TI, datos, aplicaciones y procesos de negocio. La gestin apropiada de estos elementos, as como su identificacin es una tarea compleja que requiere de
equipos especficos y herramientas adecuadas. Este artculo proporciona una visin general de los principios de
las EA y sus beneficios, todo ello desde un punto de vista prctico a partir de experiencias reales en proyectos.
Abstract:
One of IT Departments main concern is the alignment with business processes and trends as well as the efficient
use of IT resources or, in general, IT processes' assets. These two goals can be simultaneously achieved by using
the principles and methods of the Enterprise Architectures (EA), which aim the replication and efficient use of IT
and business resources following the needs of the business areas. An EA strategy starts with the identification of
any element candidate to be replicate to other locations or organizational units or, merely, improved seeking efficiency. These "building blocks" are composes of IT hardware, data, application and business processes. The appropriate management of such elements, as well as their identification is a difficult task which requires specific
teams and adequate tools. This article provides and overview of EA principles and benefits from a practical point
of view based on actual project experiences.
Palabras clave:
Gobierno de TI, Enterprise Architectures, Organizacin TI.
1. INTRODUCCIN - QU ES UNA
ENTERPRISE ARCHITECTURE?
Llevamos muchos aos hablando sobre el alineamiento entre negocio y sistemas, es como
un mantra que se repite, que omos en todo
tipo de reuniones, mesas redondas y, en general, cualquier foro al que asistimos los profesionales de la Gestin de las Tecnologas de la
Informacin (quienes quiera que seamos y
somos muchos). De tanto orlo nos hacemos
los sordos. Basta una pregunta, Cuntos directores de sistemas (CIOs) forman parte del Consejo de las principales compaas? La respues-
ta: pocos, muy pocos. Sin embargo, hay un

nuevo concepto que se est abriendo paso que
pude ser la solucin, parcial probablemente, a
ese divorcio entre negocio y sistemas. El concepto se denomina Enterprise Architecture
(EA) y se puede entender como el conjunto de
procesos, recursos humanos, materiales y sistemas de informacin que soportan una organizacin.
Una particularidad de las EA son las arquitecturas ms relacionas con las reas de TI, que en
este caso denominaremos Arquitectura TI y
ser en las que nos centremos (para una revisin del tema es recomendable el trabajo de
J.Ross, Enterprise Architecture: Deriving
- 77 -
Business Benefits from IT, MIT Center for

Information Systems Research, abril de 2006).
Ests arquitecturas van ms all del concepto
de modelo de procesos, no se trata de levantar
o pintar, como se dice en el argot, los procesos de un rea y los distintos elementos que lo
soportan, sino de establecer un repositorio que
recoja de forma sencilla, operable y mantenible
dichos procesos y su relacin con las aplicaciones que los soportan, la informacin que
manejan y las personas afectadas. Desde este
punto, pocas son las empresas que han abordado un proyecto de arquitectura y lo que predominan son iniciativas parciales. Por ejemplo, se
abordan proyectos de gestin del servicio y se
implanta ITIL (Information Technology Infrastructure Library), simultneamente alguien
instala herramientas de gestin del portafolio y,
para completar el cuadro, el responsable de
desarrollo decide que todo sea SOA (Service
Oriented Architecture) concepto ubicuo que no
suele faltar en las reas de sistemas. El resultado: confusin y pobre retorno de esas inversiones que en el mejor de los casos acaban convertidas en vistosas presentaciones powerpoint en las mesas de quienes lanzaron estas
iniciativas a bombo y platillo.
Pero como hemos comentado hay una forma
de hacerlo mejor, de ordenar los activos (personas, informacin, procesos y aplicaciones)
que conforman un rea de sistemas: aplicando
los modelos de Arquitectura TI.
ISSN: 1698-2029
2. DE LAS EA Y ARQUITECTURAS TI
AL GOBIERNO DE TI
Segn se ha explicado en la seccin anterior,
las Arquitecturas TI (como concrecin al rea
de sistemas del concepto ms amplio de de
EA) permiten estructurar claramente los activos del rea de sistemas y por lo tanto gestionarlos mejor. No debemos de olvidar que un
marco de Gobierno de TI debe de ayudar a
movilizar los recursos de un departamento de
la forma ms eficiente obedeciendo a necesidades:
1) Normativas, como pueden ser los marcos regulatorios (ahora de nuevo en
primera plana) como Sarbanes-Oxley,
CobIT, CMMi, etc.
2) Operativas, la tan comentada eficiencia.
3) Del negocio. Por ejemplo, planes de
gestin de la demanda.
Evidentemente, para poder hacer los tres puntos anteriores, logrando una operacin de nuestros sistemas de informacin que minimice los
riesgos, generando la confianza que el negocio
(y los clientes) requiere, es necesario conocer
de qu material esta hecho nuestra organizacin, cules son los activos clave, su relacin,
etc. Y lo que es ms, como se relaciones con
los procesos de negocio Este marco de relaciones es lo que hemos denominado Arquitectura TI, entendiendo que es parte de la EA y
que se encuentra ntimamente relacionada con
las actividades del negocio, tal y como se ilustra en la figura 1:
- 78 -
RPM-AE
EMES, VOL. 5,
5 N 3, Octubbre 2008
ISSN
N: 1698-20299
E
Enterprise
Arch
hitecture
Aplicaciones
Interfaces
Sistemas
Arquitectura de TI
Aplicaciones
(Software)
Fraameworks
Plaataformas
Infrraestructura
Tecnologa
(Infraestructura)
Base de datos
Entidades
Flujos
Metas
Visin
Estrategia
Drivers
Principios
Dominios
Soluciones
Implementacciones
Arquittectura de
Ne
egocio
Organizacional
Procesos de
d
Negocio e
Informacin
Datos
(Informacin)
Estrucctura
Productos
Serviccios
Unidades
Locacciones
Posiciiones
Dessempeo
del Negocio
Mtricas
Eficiencia
Riesgos
Proccesos
Conocimiento
Usabilidad
Worrkflows
Estrructuras
Activvidades
Tareeas
Evenntos
F
Figura
1. : Las
L Arquitecturas TI y deel Negocio ccomo elemenntos constituutivos de lass EA.
Por otroo lado, siguiiendo las ideeas de Ross (anteriormeente citado),, una vez que
q la organnizacin disppone de un marco
m
comn para la ejecucin de sus procesoos o servicioos (lo que see de-
nomina en ingls
i
Founndation for Exceution)
E
),
el modelo operativo
o
dee la compaa, su Arquitectura TI y el modeloo de Gobierrno est ntimamente reelacionados:
2 : Modelo operativo, EA
E y modeloo de Gobiernno como blooques constittutivos del rea
de siste-Figura 2.
mas y sooporte de la oorganizacinn.
3.
DE
EMOS UNA
A VISIN DE CONJU
UNTO
Imagineemos que poodemos paraarnos a penssar y

una
ordenar todos los acctivos que componente
c
Arquitecctura TI, sigguiendo una tpica visinn de
abajo a arrriba. En pprimer lugarr nos encontramos con todas las innfraestructuraas tecnolgicas, inmediiatamente poor encima see encuentrann
las funcionees de gestinn del servicio TI, dondee
el modelo ITIL marca lla referenciaa. Llegados a
a
bsieste punto nos encontrramos con activos
camente teccnolgicos, los procesoss que soporrtan el servicio que estaa tecnologa presta y lass
- 79 -
ISSN: 1698-2029
personas entrenadas para ello. A muchos pisos por encima, se encuentran los procesos de
negocio soportados por las aplicaciones desarrolladas a tal efecto. Lo normal es que no se
vaya ms all y que estos dos niveles o agrupaciones de activos se encuentren separados, sin
un mecanismo que permita visualizarlos de
forma integrada. Entonces, cmo debemos
proceder? Vayamos paso a paso:
En primer lugar se modelan los procesos de negocio, es decir, aquellos que

van orientados a satisfacer un resultado
concreto de la actividad de la empresa
y se documentan con una herramienta
de EA (ARIS, System Architect y Provision entre otras), indicando los indicadores y mtricas asociados; as como
los perfiles e integrantes de la organizacin afectados. Concluido este ejercicio podemos dar por finalizada la Arquitectura de Negocio. Este modelado,
favorecido por el uso de herramientas,
se puede llevar a cabo empleando notacin estndar como BPMN (Business
Process Modeling Notation). En este
caso, tal y como describe la figura 3,
nos encontramos dentro del mbito de
la estrategia y el anlisis de procesos de
negocio.
En segundo lugar se modelan los datos
y aplicaciones que soportan los proce-
- 80 -
sos anteriormente descritos y diseados. El uso de BPMN y herramientas

adecuadas permite pasar de la especificacin de un proceso a la de un servicio
IT (p.e., Web Services) mediante un
intrprete denominado BPEL (Busines
Process Excution Language). Es decir,
gracias a los principios de Arquitectura
TI y al uso notacin estndar se pueden
unir de forma elegante el modelado de
negocio con el de sistemas, en otras palabras, sentar las bases del Diseo Detallado.
Finalmente, tras modelar el negocio y
los interfaces de los servicios TI, es necesario integrar los dos mundos: negocio y sistemas. Esta vinculacin es todava ms eficaz en escenarios SOA,
donde previamente las aplicaciones se
han analizado para determinar cuales
son los servicios de aplicacin que poseen y agrupado en servicios de negocio. Dichos servicios se suelen catalogar e inventariar gracias a herramientas
que proporcionan la funcin de repositorios de servicios. Las herramientas
de Arquitectura TI permiten integrar
estos repositorios con los procesos de
negocio y los datos a gestionar, permitiendo tener en una nica ubicacin
lgica todos los activos relacionados
con el modelado de una determinada
actividad.
ISSN: 1698-2029
Entorno de Negocio
Audiencia objetivo:
Propsito:
Modelado
Consultor Estratgico.
Analista de Negocio.
BPMN
Analista de Procesos.
Arquitectos TI.
BPEL
Convergencia
Negocio - TI
Desarrolladores.
Responsables Servicio TI .
Ejecucin
Implementacin Tecnolgica
Figura 3. : Convergencia negocio TI a travs de los mtodos de EA
Es importante destacar que la adopcin del
paradigma SOA tiene ms implicaciones en la
definicin de procesos, es decir, en las reas
negocio que en las tcnicas. En efecto, SOA
supone un cambio radical pues la idea de aplicacin que soporta a uno o varios procesos se
pierde. En su lugar lo que tenemos es un conjunto de servicios, adecuadamente inventariados y expuestos, que bien agrupados con la
ayuda de alguna solucin de integracin darn
soporte a los procesos de negocio. Si el anlisis
y exposicin por parte de las reas de tcnicas
se hace correctamente, son los analistas de
negocio los que deben sacar el mximo partido
a dichos servicios mediante un correcto modelado.
4. CONCLUSIONES
A modo de conclusin, destacara que pese a
su inmadurez actual, los principios, tcnicas
(como el cuadrante Zachman o el modelo TOGAF) y herramientas de Arquitectura TI nos
abren las puertas a un nuevo mundo en el que
analistas de negocio (procesos) y sistemas (arquitectos) se confundan, siendo difcil establecer la distincin entre unos y otros pues ambos
trabajarn sobre los mismos activos de informacin, usando las mismas tcnicas. Esto no es
Ciencia Ficcin, est a la vuelta de la esquina y
las oportunidades para los negocios sern muy
significativas, permitiendo al fin la tan manida
convergencia entre las reas de negocio y sistemas.
Por otro lado, el conocer y ordenar adecuadamente los activos del rea de sistemas permite
desplegar modelos de Gobierno TI, o lo que es
ms, se la base de los mismo, ligando la gestin de los activos con su gobierno.
5. REFERENCIAS.
[1] J.Ross, 2006. Enterprise Architecture: Deriving
Business Benefits from IT, MIT Center for Information Systems Research, abril de 2006.JTC 1/SC
27. ISO/IEC 27001:2005, International Standards
for Business, Government and Society.
[2] N.G. Carr, 2003. IT dosent Matter, Harvard
Business Review.
[3] M. Curley, 2004. "Managing Information Technology for Business Value", INTEL Press
- 81 -
ISSN: 1698-2029
PRUEBAS DE SEGURIDAD EN EL MARCO DE UNA FACTORA

DE CALIDAD DE PRODUCTO SOFTWARE
Jess Prez Cristbal
Consultor Senior de Calidad de SW y Procesos TI
Mtodos y Tecnologa
jesus.perez@mtp.es
http://www.mtp.es
Resumen
El artculo presenta una visin de las pruebas de seguridad dentro del marco de estandarizacin de procesos que representa el modelo de factora de pruebas. Dicha visin es fruto de la experiencia de MTP. Dentro
de este mbito se realiza un anlisis general sobre cuestiones tales como metodologas utilizadas, cuadros de
mando, procesos de calidad, utilizacin de herramientas especializadas o modelos de riesgo.
1. INTRODUCCIN
El paradigma de la factora software est tomando auge gracias a la tendencia actual de
buscar modelos de fabricacin de software que
tiendan a esquemas ms industriales y que se
alejen de las formas artesanales que han dominado por mucho tiempo este sector (y que han
ocasionado no pocos perjuicios). Recordemos
que, como diversos autores han sealado, las
caractersticas esenciales de las factoras software son la estandarizacin de sus procesos,
productos y servicios como camino para mejorar la calidad del software, reducir los tiempos
de desarrollo e incrementar la productividad.
Pero el creciente xito del modelo de factora
software no debe entenderse de forma aislada.
Otras tendencias asentadas en la economa
actual han servido de revulsivo a este modelo.
Algunas de estas tendencias son: la externalizacin de servicios por parte de las empresas
(outsourcing), que dota a las empresas de mayor flexibilidad o la creciente deslocalizacin
como importante factor de reduccin de costes.
Otra tendencia destacable sera la bsqueda por
parte de las empresas de las economas de escala (basado en el fenmeno comprobado de
que a medida que la produccin en una empre-
sa crece, sus costes por unidad producida se

reducen).
Dentro de este contexto favorable estn surgiendo diferentes variedades de factora software. Algunas clasificaciones atienden a criterios como la modalidad de outsourcing (offshore, near-shore, on-shore). Otra clasificacin
es la que distingue las factoras software segn
el mbito concreto del ciclo de vida del software en el que se especializan. Por ejemplo existen factoras que cubren todo el ciclo de vida
del software pero otras se han especializado en
fases concretas como la fase de construccin, la
fase de mantenimiento o la fase de pruebas. Es
esta ltima modalidad de factora la que nos
interesa en este artculo: la factora de calidad
de producto software, comnmente denominada como factora de pruebas o de testing.
El xito del modelo de factora de pruebas se
basa en explotar al mximo los beneficios de la
especializacin de recursos humanos, y en general de una elevada volumetra. Esto puede
suponer importantes beneficios para el cliente:
mejora de la calidad y de la eficiencia en las
pruebas, disminucin de costes fijos por unidad
- 82 -
de produccin, mejora en los clculos de estimacin de costes y tiempo, disminucin del

riesgo en proyectos novedosos, etc.
Una factora de pruebas poseer un catalogo de
servicios que los clientes pueden contratar.
Tpicos servicios sern por ejemplo pruebas
funcionales, pruebas de aceptacin, pruebas de
prestaciones, pruebas de regresin Entre este
tipo de servicios (quizs como un protagonismo menor) tambin se encontrara probablemente las pruebas de seguridad.
El contexto actual desde la perspectiva de la
seguridad es ciertamente preocupante: todava
existe un gran desconocimiento sobre temas de
seguridad en el mbito del desarrollo software
y esto propicia la consiguiente debilidad estructural del sector informtico en este campo. No
es por tanto casualidad que las estadsticas de
incidentes de seguridad muestren un alza continuada en los ltimos aos y que diferentes
encuestas reflejan que uno de los mayores inhibidores a la expansin del comercio electrnico en la red sea el miedo a la inseguridad.
Una solucin eficaz a esta problemtica descrita sera integrar las pruebas de seguridad en el
ciclo de vida del software, y huir de soluciones
reactivas (esto es actuar tras el conocimiento de
incidentes de seguridad). Esto conllevara, entre otras aspectos, unos adecuados requisitos de
seguridad y una eficaces pruebas se seguridad.
2. PRUEBAS DE SEGURIDAD EN UNA

FACTORA SOFTWARE: BASE METODOLGICA
Dada la estandarizacin y formalizacin del
desarrollo software en base a modelos reconocidos por el mercado, es factible especializar y
estandarizar el proceso de pruebas de seguridad. Desde este punto de vista la factora de
pruebas puede ser el marco idneo para la realizacin de este proceso de pruebas.
ISSN: 1698-2029
El punto de partida para que una factora de

pruebas oferte este servicio debera ser el contar con un marco metodolgico slido, preferentemente basado en estndares reconocidos y
respetados internacionalmente. En el contexto
de las pruebas de seguridad de aplicaciones
Web (que representan la mayora de las aplicaciones que se construyen actualmente) una
metodologa muy reputada es la del proyecto
OWASP (Open Web Application Security
Project, en ingls Proyecto de seguridad de
aplicaciones Web abiertas). Este proyecto se
adapta perfectamente a las necesidades que
podra tener una factora software ya que cuenta con requisitos genricos de seguridad, una
metodologa para realizar las pruebas, herramientas para la realizacin de pruebas de seguridad, extensa documentacin sobre el proceso,
una gran comunidad de usuarios, y numerosos
subproyectos dentro del mismo rea de seguridad.
La metodologa OWASP cubre la seguridad en
todo el ciclo de vida del software, aunque se
centra principalmente en las pruebas de intrusin web. El objetivo de tal metodologa es que
las pruebas de seguridad sean consistentes,
reproducibles, y de calidad. Tambin es exhaustiva en el sentido de que busca analizar
todas las vulnerabilidades conocidas. Su enfoque principal es el de una aproximacin de caja
negra donde los tcnicos que realizan las pruebas slo necesitan poseer una mnima informacin sobre la aplicacin que va a ser testeada.
La metodologa OWASP seala dos fases en
las pruebas:
- 83 -
Modo pasivo: los auditores intentan

comprender la lgica de la aplicacin y
recopilar la informacin relevante (la
utilizacin de un proxy http para observar todas las peticiones y respuestas
http puede ser de gran utilidad). Al final de esta fase los auditores deberan
comprender cuales son todos los puntos
ISSN: 1698-2029
de acceso de la aplicacin (por ejemplo

cabeceras HTTP, parmetros, cookies).
Modo activo: en esta fase los auditores
a cargo de la comprobacin empiezan a
realizar las pruebas usando la metodologa especfica para las diferentes categoras de vulnerabilidades (por ejemplo pruebas de autenticacin, de validacin de datos, de gestin de sesiones,
de denegacin de servicio)
3. CALIDAD, COSTE Y PLAZOS ANTICIPADOS

La factora de pruebas debera anticipar al
cliente la calidad, el coste y los plazos en que
va a obtener el servicio. Esto supone que:
Antes de la ejecucin de las pruebas se

debe acordar el alcance de tales pruebas. Dicho alcance lo podemos medir a
travs de la amplitud y la profundidad
de las pruebas. La amplitud corresponde a los diferentes mdulos o partes de
la aplicacin que se quiere testear. La
profundidad corresponde al nivel de
pruebas de seguridad que se quiere ejecutar o a su tipo (revisin de cdigo o
pruebas de penetracin).
Para obtener una estimacin de tiempo y costes de la evaluacin, la factora deber tener en cuenta el alcance de
Figura 1.
- 84 -
las pruebas y los puntos funcin de la

aplicacin a testear. A travs de esta informacin se debe utilizar una metodologa adecuada para hallar tiempo y
costes. Un posible modelo de estimacin podra ser una adaptacin del modelo genrico Cocomo II con el factor
correctivo de los datos histricos que la
factora pudiera poseer. Es importante
sealar que slo a travs de una planificacin adecuada ser posible para la
factora de pruebas cumplir en costes y
tiempo las estimaciones previstas. Y
que esta planificacin deber estar explicitada en el plan de pruebas de seguridad, que detallar el alcance, las fases, las actividades, los recursos, los
tiempos, y las tcnicas a aplicar.
La calidad de la evaluacin se comprueba a travs de la informacin sobre
las mtricas de proceso y los entregables por parte de la factora software.
Las mtricas nos dan valiosa informacin sobre la realizacin de las pruebas
y el resultado de tales pruebas. Tales
mtricas deben mostrar que el nivel de
desempeo est alineado con el Acuerdo de nivel de servicio (SLA). Los entregables adems del informe final
sern productos de trabajo como informes de herramientas, documentos
intermedios, ficheros de logs...
4. CUADROS DE MANDO
Como en el resto de pruebas, las de seguridad
deben formar parte de un proceso definido,
documentado y medido para poder ser gestionado. En el mbito de la medicin dentro de
una factora software son esenciales los cuadros de mando operacionales que permiten la
monitorizacin en vivo de determinadas mtricas seleccionadas por su importancia en el proceso.
Marcos de referencia como Cobit, principalmente, e Itil, nos pueden ayudar a disear cuadros de mandos para los procesos de gestin de
pruebas en general y de gestin de pruebas de
seguridad en particular (conjuntamente con la
metodologa OWASP).
Existirn dos tipos de cuadros de mando: el
interno, diseado para los responsables de la
factora de pruebas, y el cuadro de mando externo, creado para los clientes de la factora y
que forma parte del interfaz externo que la
factora proporciona a estos.
Las mtricas utilizadas en los cuadros de mando de la fase de pruebas de seguridad, junto
con las tcnicas de estimacin adecuadas, nos
deben permitir controlar informacin tal como
la duracin de las pruebas, los recursos dedicados, o el tiempo medio entre vulnerabilidades
encontradas. Adems pueden existir otros indicadores que recojan informacin sobre la calidad del proceso. Ejemplos de tales mtricas
pueden ser: esfuerzo total del proyecto (horas
hombre), esfuerzo total en cada fase, nmero
de vulnerabilidades encontradas en cada fase,
vulnerabilidades crticas halladas
5. AUTOMATIZACIN DE PRUEBAS
La estandarizacin del proceso de pruebas de
seguridad pasa por la utilizacin de herramientas de seguridad que proporcionen automatismo en las tareas a realizar. Por ello la factora
de pruebas debe desarrollar una estrategia de
ISSN: 1698-2029
automatizacin de pruebas. Esta estrategia debe definir qu actividades se pretenden automatizar, qu categoras de herramientas de
pruebas se utilizaran, qu acciones sern necesarias llevar a cabo.
Finalmente se debe definir cules son los costes y beneficios esperados de la estrategia de
automatizacin.
Un subgrupo de estas herramientas son las que
proporcionan automatismo en las bsquedas de
vulnerabilidades. Hay dos tipos de estas:
Herramientas automticas de intrusin: suelen funcionar como proxies intermedios entre el cliente web y el servidor. Retienen la informacin intercambiada y a partir de ah son capaces
de lanzar gran cantidad de pruebas automticas. Estas pruebas pueden ahorrar gran cantidad de tiempo a los
tcnicos que realizan pruebas manuales
de penetracin.
Herramientas automticas de anlisis de cdigo: a partir del cdigo fuente
permiten descubrir posibles vulnerabilidades de seguridad. Puede ser de una
gran ayuda en las revisiones de cdigo
manuales.
Son obvias las ventajas que aporta la automatizacin: rapidez, exhaustividad, permite realizar
pruebas de manera repetitiva, y a largo plazo
reduce los costes. Sin embargo este tipo de
herramientas de anlisis y comprobacin de
seguridad automatizadas tienen grandes limitaciones. En primer lugar estas herramientas son
genricas, por lo que no estn diseadas para
aplicaciones especficas, sino para aplicaciones
en general. Por lo que aunque pueden encontrar
determinadas vulnerabilidades genricas, no
tienen el conocimiento suficiente sobre una
aplicacin especfica como para permitirles
detectar la mayora de los agujeros de seguridad. Adems en una gran parte de los casos las
- 85 -
vulnerabilidades de seguridad ms seras son

aquellas no genricas.
Por tanto podemos decir que las herramientas
que proporcionan automatismo resuelven con
relativo bajo coste la localizacin de las vulnerabilidades ms conocidas. Sin embargo para
conseguir niveles mayores de seguridad es
necesario disear y ejecutar pruebas de seguridad adaptadas a las caractersticas del producto
software a evaluar. Una factora de pruebas,
debido a su especializacin, aporta mayores
ventajas en cuanto a cobertura de vulnerabilidades y en cuanto a los plazos de ejecucin.
6. INFORME DE PRUEBAS DE SEGURIDAD
El producto final de la evaluacin de seguridad
por parte de la factora de pruebas es el informe
de pruebas de seguridad que normalmente estar inserto en el informe global de pruebas
realizadas.
Dicho informe de seguridad deber ser fcilmente comprensible, sealar todos los riesgos
encontrados en la evaluacin de seguridad y
dirigirse tanto al personal tcnico como a los
responsables ejecutivos de la empresa cliente.
Ms concretamente, dicho informe podra contar con un resumen ejecutivo no tcnico que
describa el nivel de riesgo, un resumen destinado a los responsables tcnicos del cliente y
por ltimo un apartado que incluya detalles
tcnicos sobre las vulnerabilidades encontradas, y las consideraciones necesarias para que
estas sean resueltas.
Es importante resear que para que un informe
refleje una percepcin correcta de los riesgos
encontrados la factora de pruebas debe contar
con un modelo de anlisis de riesgos, ya que
descubrir vulnerabilidades en aplicaciones
software es importante, pero igualmente importante es ser capaz de estimar el riesgo asociado
que conllevan tales vulnerabilidades. El mayor
ISSN: 1698-2029
problema que se plantea al establecerse un

modelo de riesgos en una factora software es
que este modelo debe ser lo ms genrico posible al testearse aplicaciones de muy diversos
clientes que pueden pertenecer a diferentes
sectores de la economa.
Tal modelo genrico de anlisis de riesgo puede partir de la conocida valoracin estndar de
riesgo:
Riesgo = Probabilidad de ocurrencia * Impacto
Probabilidad de ocurrencia: medida aproximada de lo probable que es que la vulnerabilidad
sea descubierta y explotada por un atacante.
Impacto: consecuencia de la materializacin de
una amenaza.
Ante las vulnerabilidades halladas por el equipo de la factora software un acertado modelo
de anlisis de riesgos descompondr los factores que intervienen en la probabilidad de ocurrencia y en el impacto para la seguridad de
las aplicaciones, y mostrar como combinarlos
para determinar la severidad global para el
riesgo.
Como resumen de todo el informe de evaluacin de pruebas sera interesante proporcionar
una mtrica global que sintetizar el estado de
la aplicacin desde la perspectiva de la seguridad. La idea bsica consistira en clasificar las
vulnerabilidades descubiertas segn su criticidad y a partir de criterios objetivos (se utilizara
el modelo de riesgo). Podramos definir por
ejemplo vulnerabilidades de criticidad mxima,
alta, media y baja. Por cada vulnerabilidad de
cada tipo la mtrica se incrementara un cierto
valor. Por ltimo existiran unos rangos de
valores de la mtrica que definiran el estado de
la seguridad de la aplicacin. De esta forma
podramos hablar, por ejemplo, de estado crtico, grave, medio, bajo, muy bajo y ptimo.
- 86 -
ISSN: 1698-2029
7. PROCESO DE PRUEBAS DE SEGURIDAD

La estandarizacin del proceso de pruebas de
seguridad supone que es un proceso definido
claramente, documentado en su vertiente interna (subprocesos, actividades, procedimientos y
tareas de trabajo), como en su vertiente externa
(SLAs, cuadros de mando).
Normalmente ser un proceso cclico, donde la

responsabilidad final de aceptar o no los riesgos encontrados en la evaluacin pertenece
siempre al cliente.
En el siguiente diagrama se ha utilizado el
estndar BPMN para formalizar como ejemplo
un proceso simplificado de pruebas de seguridad en el marco de una factora de pruebas.
Figura 2.
8. CONCLUSIONES
Dada la estandarizacin y formalizacin del desarrollo software en la actualidad en base a modelos reconocidos y
atendiendo a los beneficios de la externalizacin de procesos especializados,
es factible estandarizar el proceso de
- 87 -
pruebas de seguridad en el marco de

una factora de software.
La utilizacin de una metodologa reconocida internacionalmente (como por
ejemplo OWASP) puede proporcionar
las bases adecuadas al proceso.
La factora de pruebas debe anticipar al
cliente la calidad, el coste y los plazos
en los que se realizaran las pruebas de
ISSN: 1698-2029
seguridad y esta informacin debe ser

integrada en el plan de pruebas.
La factora de pruebas debe contar con
un modelo de anlisis de riesgo para
que el cliente puede entender en la
lgica de su negocio la informacin en-
contrada en el proceso de pruebas de

seguridad. Puede ser til la utilizacin
de una mtrica sntesis de la evaluacin
de seguridad.
- 88 -
ISSN: 1698-2029
Artculos anteriores publicados en RPM-AEMES

Nombre
Estimacin de variables en proyectos de desarrollo
de software (PDS)
Una propuesta para la verificacin de Requisitos
basada en mtricas
Modelos segmentados de estimacin del esfuerzo de
desarrollo del Software: Un caso de estudio con la
base de datos ISBSG
Proceso y herramientas para la productividad en el
aseguramiento y medicin de calidad en desarrollos
java
Lecciones aprendidas al determinar el estado actual
del rea de proceso de gestin de requisitos utilizando el CMMI
Mejora de la calidad en desarrollos orientados a
objetos utilizando especificaciones UML para la
Obtencin de precedencia de Casos de Prueba
Modelado dinmico y aprendizaje automtico aplicado a la gestin de proyectos software
Un procedimiento de medicin de tamao funcional:
diseo y aplicacin
Estimacin del esfuerzo de implantacin en sistemas
ERP
Un enfoque de modelado y simulacin para la comprensin del proceso de diseo centrado en el usuario
Estimacin del esfuerzo de un proyecto software
utilizando el criterio mdl-em y componentes normales n-dimensionales
Optimizacin de Mtrica Versin 3 en entornos
orientados a objetos
Experiencias de las administraciones pblicas espaolas en los procesos de gestin de requisitos y
gestin de subcontratacin
El factor humano: instrumentos de medida competencial y estimacin software
El Papel de la Organizacin en la Gestin de Riesgos
en Proyectos Software Aeroespaciales
Evaluacin de la exactitud de un nuevo mtodo de
estimacin gil
Utilizacin de QFD en la toma de decisiones para la
estructuracin de una familia de productos
Indicadores Empricos Formales y muy Tempranos
de Complejidad Esencial de Sistemas de Gestin
Intensiva de Datos: Un Modelo Conceptual
Project Management Improvement in Extreme
Programing
Quality Through Test Management in Production
Management Vision on Software Production Lines
MECHDAV: un modelo y su herramienta para la
evaluacin tcnica de la calidad de las herramientas
RAD para ambientes visuales
Applying Software Process Metrics in Business
Process Models
Desarrollo de productos de software seguros en
sintona con los modelos SSE-CMM, COBIT e ITIL
Recomendaciones para el desarrollo del capital
humano desde la perspectiva de la mejora del
Vol
Fecha
J. Aroba, I. Ramos, C. Riquelme
Autor/es
Agosto 2004
B. Bernrdez , A. Durn, M. Toro, M.

Genero
Agosto 2004
J. Cuadrado-Gallego, D. Rodrguez, M.A.

Sicilia
Agosto 2004
L. Fernndez, P. Lara
Agosto 2004
J. Calvo-Manzano, G. Cuevas, T. San Feliu,

A. Serrano, M. Arcilla
Diciembre 2004
L. Fernndez, P. Lara, J. Cuadrado-Gallego
Diciembre 2004
HERACLES
Diciembre 2004
N. Condori-Fernandez, S. Abrao, O. Pastor,

S. Mart
Diciembre 2004
A. Cano, J. Tuya
Marzo 2005
N. Hurtado, M. Ruz, J. Torres
Marzo 2005
Miguel Garre Rubio, Mario Charro Cubero
Marzo 2005
Agosto 2005
Agosto 2005
Agosto 2005
Bernard, P., Salvador, L
Diciembre 2005
Fernando Machado, Luciana Calcagno
Diciembre 2005
Montse Ereo, Rebeca Cortazar
Diciembre 2005
Abril 2006
Abril 2006
Giovani Salvadori
Abril 2006
L.S. Vargas, A. G. Gutirrez, E. M. Felipe
Septiembre 2006
E. Roln, F. Ruiz, F. Garca, M. Piattini
Septiembre 2006
Septiembre 2006
Enero 2007
J. L. Lpez-Cuadrado, . Garca-Crespo, B.
Ruiz-Mezcua, I. Gonzlez-Carrasco
J.A. Calvo-Manzano, G. Cuevas, I. Garca,
T. San Feliu, A. Serrano, F. Arboledas, F.
Ruiz de Ojeda
R. Colomo Palacios, E. Tovar Caro, J. Carrillo Verdn
Pedro Salvetto, Jos Carrillo, Oscar Marbn,

Julio Fernndez, Juan Carlos Nogueira,
Javier Segovia
Houda Zouari Ounaies, Yassine Jamoussi2,
Mohamed Ben Ahmed
Edmundo Tovar C., Jos Carrillo V., Vianca

Vega Z., Gloria Gasca H.
Ricardo Colomo Palacions, Edmundo
Tovar Caro, Juan M. Gmez Berbis,
- 89 -
Nombre
proceso software
Team Software Process (TSP): mejoras en la
estimacin, calidad y productividad de los equipos en la gestin del software
Desde ISO 9001 hacia CMMI, pasos para la
mejora de los procesos y mtricas
Contribucin de los estndares internacionales a
la gestin de procesos software
Asociacion tecnica de cajas de ahorros(ATCA):
un plan de mejora basado en el modelo CMMI
EXHAUSTIF: Una herramienta de inyeccin
de fallos por software para sistemas empotrados
distribuidos heterogneos
Anlisis de Fiabilidad de Sistemas Aplicando
Tcnicas de Crecimiento de Fiabilidad del Software
Definicin de Mtricas de Calidad en el Procesos
de Parametrizacin de Sistemas ERP
Anlisis del Valor de un Proyecto en el Marco
del Mtodo Parker
Benchmarking is an essential control mecanism
for management
Changing from fpa to cosmic a transition framework
Modelo de gobierno de una factora software
Case study of a successful measure-ment program
Cuadro de mando para la gestin integrada
Increase ict project success with concrete scope
management
Capacitacin de recursos testing
Calidad en modelos conceptuales: un anlisis
multidimensional de modelos cuantitativos basados en la iso 9126
Kemis: entorno para la medicin de la calidad
del producto software
Anlisis del valor de un proyecto de TI en el
marco del mtodo Parker
Gobierno de la externalizacin del proceso software
Gestin de los riesgos tecnolgicos
Importancia de la gestin del proceso de la demanda de TI.
Un nuevo marco de convergencia y calidad para
la gestin de la seguridad en el servicio de TI.
Las bases de datos de gestin de la configuracin, el corazn de ITIL.
ISSN: 1698-2029
Autor/es
ngel Garca Crespo
Bayona, S., Calvo Manzano, J., Cuevas,
G., San Feliu, T.
Vol
Enero 2007
Rolando Armas Andrade, Arturo Chamorro Gmez, Maite Montes Beobide, Jos
A. Gutirrez de Mesa
Francisco J. Pino, Flix Garcia, Mario
Piattini
Pablo Serrats Surez, Alberto Villuendas
Hereza, Pilar Meneses Ballestar,
Antonio da Silva, Jos F. Martnez, Lourdes Lpez , Luis Redondo
Enero 2007
Abril 2007
Abril 2007
Abril 2007
Da. Amaya Atencia Ypez, D. Luis

Redondo Lpez
Septiembre 2007
Carmen Pages, Luis de-Marcos, JosJavier Martnez, Jos-Antonio Gutirrez

Helena Garbarino1 Jos Carrillo Verdn
Septiembre 2007
Septiembre 2007
Ton Dekkers
Octubre 2007
H.S. van Heeringen
Octubre 2007
Aurelio Gandarillas Cordero, Mamdouh

El Cuera
Pam Morris
Octubre 2007
Octubre 2007
Douglas Wagner
Carol Dekkers, Pekka Forselius
4
4
4
4
Octubre 2007
Octubre 2007
Miguel ngel Garca Palomo, Mamdouh

Elcuera
Beatriz Marn, Nelly Condori-Fernndez,
Oscar Pastor
Octubre 2007
Octubre 2007
Moiss Rodrguez, Marcela Genero,

Javier Garzs, Mario Piattini
Helena Garbarino, Jos Carrillo Verdn
Octubre 2007
Enero 2008
Enero 2008
Enero 2008
Mayo 2008
Mayo 2008
Mayo 2008
ngel Snchez, Jezreel Meja,Gonzalo

Cuevas
Luis Martn Romeral, lvaro Torres
Gallego
Igos Aguilar Alonso, Jos Carrillo
Verdn, Edmundo Tovar Caro
Mara Teresa Villalba, Luis Fernndez,
Jos Javier Martnez
Manuel Prez Bravo, Daniel Rodrguez
Garca
- 90 -
Fecha
ISSN: 1698-2029
Llamada a la participacin Revista Procesos y Mtricas
Uno de los principales objetivos de esta revista es que aquellas entidades y organizaciones interesadas participen en ella. Y por ello le instamos tanto a usted como a su institucin para que realicen contribuciones,
o enven sus comentarios y sugerencias. Actualmente estamos abiertos a
la recepcin de trabajos para el prximo nmero que cubra los siguientes
tpicos:
Artculos acadmicos.
Casos prcticos o casos de xito (success histories) de aplicacin
de mtricas y procesos de tecnologas de la informacin en organizaciones
Artculos de difusin que traten conceptos tericos, bsicos, novedosos, etc explicados de forma amena, o que traten aspectos relacionados con la difusin y empleo de ciertas tcnicas, mtricas o
procesos.
Informacin sobre noticias, eventos, etc
La revista se edita en formato electrnico y papel (ambas con ISSN propio), y es accesible a travs de su web:
http://www.aemes.fi.upm.es/rpm/rpm.php. Consulte la Gua para Autores publicada en este nmero o visite la web para ms informacin sobre
el formato de las contribuciones.
Esperamos sus contribuciones en: rpm@aemes.org
- 91 -
ISSN: 1698-2029
ASOCIACIN ESPAOLA DE MTRICAS DE SISTEMAS INFORMTICOS AEMES

Facultad de Informtica de la UPM. Campus de Montegancedo. 28660-Boadilla del Monte (Madrid)
Telfono: 91 336 66 08. Fax: 91 336 74 12. E-mail: admon@aemes.org
FORMULARIO DE INSCRIPCIN A AEMES

Informacin Personal
Apellidos:
Telfono:
Direccin Personal:
Empleo:
Nombre:
e-mail:
Inscripcin Institucional o Empresarial

Institucin o Empresa:
C.I.F.:
Direccin:
Datos Bancarios
Nmero de Cuenta:
Titular:
Autorizo a AEMES a cargar a la cuenta arriba indicada la cuota Anual de inscripcin que asciende a 360 + la
cuota de inscripcin que asciende a 150
Fecha y Firma
FORMULARIO DE INSCRIPCIN A RPM (Revista de Procesos y Mtricas)

Informacin Personal
Apellidos:
Telfono:
Direccin Personal:
Empleo:
Nombre:
e-mail:
Inscripcin Institucional o Empresarial

Institucin o Empresa:
C.I.F.:
Direccin:
Datos Bancarios
Nmero de Cuenta:
Titular:
Autorizo a AEMES a cargar a la cuenta arriba indicada la cuota Anual de subscripcin a RPM que
asciende a 60 + Gastos de Envo
Fecha y Firma
- 92 -
Gua para Autores

Se recomienda a los autores enviar los artculos electrnicamente utilizando la direccin
de correo electrnico rpm@aemes.org . Por favor dirigir los artculos al Editor de la
Revista de Procesos y Mtricas de las Tecnologas de la Informacin o a la Asociacin
Espaola de Mtricas de Sistemas Informticos. El artculo debe ser enviado para el
proceso de revisin en formato Microsoft Word o PDF.
En el caso de envos de artculos en papel, se deben enviar tres copias al Editor de la
Revista de Procesos y Mtricas de las Tecnologas de la Informacin o a la Asociacin
Espaola de Mtricas de Sistemas Informticos. Facultad de Informtica - Universidad
Politcnica de Madrid, Campus de Montegancedo, Boadilla del Monte. Madrid - 28660.
Los artculos se debern enviar sin indicar en el documento en el que se describa el
trabajo presentado los autores del mismo. Para cada artculo enviado se deber enviar
en un documento adjunto el nombre y la filiacin completa (incluida direccin, telfono
y correo electrnico) de los autores del artculo, y se indicar cual de ellos se deber
considerar como autor de contacto a efectos de comunicacin.
El envo de un artculo implica que el trabajo descrito no ha sido publicado previamente
(excepto en el caso de una tesis acadmica), que no se encuentra en ningn otro
proceso de revisin, que su publicacin es aceptada por todos los autores y por las
autoridades responsables de la institucin donde se ha llevado a cabo el trabajo y que
en el caso de que el artculo sea aceptado para su publicacin, el artculo no ser
publicado en ninguna otra publicacin en la misma forma, ni en Espaol ni en ningn
otro idioma, sin el consentimiento de la Asociacin Espaola de Mtricas del Software.
Una vez recibido un artculo se enviar al autor de contacto, por correo ordinario, una
carta de recepcin del artculo, tanto si este ha sido enviado por correo electrnico
como si lo ha sido por correo ordinario.
Todos los artculos recibidos para ser considerados para su publicacin sern sometidos
a un proceso de revisin. La revisin ser realizada por tres expertos independientes.
Para asegurar un proceso de revisin lo ms correcto posible los nombres de los
autores y los revisores permanecern confidenciales.
Una vez revisado un artculo se enviar por correo ordinario una carta con los
resultados de la revisin, tanto si este ha sido enviado por correo electrnico como si lo
ha sido por correo ordinario. En el caso de que el artculo haya sido rechazado se
adjuntarn las valoraciones de los revisores.
El proceso de revisin est libre de costes para los autores.
Una vez que un artculo haya sido aceptado, se solicitar a los autores que transfieran
los derechos de autor del artculo a la Asociacin Espaola de Mtricas de Sistemas
Informticos. Recibida la transferencia, se solicitar a los autores el envo de una
versin del artculo lista para publicacin que se deber enviar en formato Microsoft
Word.
La publicacin de un artculo en la revista est libre de costes para los autores.
Gua para la preparacin de manuscritos
El texto deber estar escrito en un correcto castellano (Uso Espaol) o en Ingls (Uso
Britnico). Excepto el abstract que deber estar escrito en un correcto Ingls (Uso
Britnico).
Abstract y Resumen. Se requiere un abstract en ingls con un mximo de 200
palabras. El abstract deber reflejar de una forma concisa el propsito de la
investigacin, los principales y resultados y las conclusiones ms importantes. No debe
contener citaciones. Se debe presentar a continuacin del abstract en ingls una
traduccin del mismo al castellano bajo el epgrafe Resumen.
Palabras clave. Inmediatamente despus del Resumen se proporcionarn un conjunto
de 5 palabras clave evitando trminos en plural y compuestos, tampoco se deben usar
acrnimos o abreviaturas a no ser que sean de un uso ampliamente aceptado en el
campo del artculo. Estas palabras claves sern utilizadas a efectos de indexacin.
Subdivisin del artculo. Despus del Abstract y el Resumen, que no llevarn
numeracin, se debe dividir el artculo en secciones numeradas, comenzando en 1 y
aumentando consecutivamente. Las subsecciones se numerarn 1.1 (1.1.1, 1.1.2, etc.),
1.2, etc. No se deben incluir subdivisiones por debajo del tercer nivel (1.1.1). Cada
seccin o subseccin debe tener un ttulo breve que aparecer en una lnea separada.
Apndices. Si hay ms de un apndice, se deben identificar como A, B, etc. Las
ecuaciones en los apndices tendrn una numeracin separada: (Eq. A.1), (Eq. A.2),
etc.
Agradecimientos. Se deben situar antes de las referencias, en una seccin separada.
Tablas. Se deben numerar las tablas consecutivamente de acuerdo con su orden de
aparicin en el texto. Se deben poner ttulos a las tablas debajo de las mismas.
Figuras. Se deben numerar las figuras consecutivamente de acuerdo con su orden de
aparicin en el texto. Se deben poner ttulos a las figuras debajo de las mismas.
Referencias. Se debe verificar que cada referencia citada en el texto se encuentra
tambin en la lista de referencias y viceversa. Los trabajos no publicados o en proceso
de revisin no pueden ser citados.
-Citaciones en el texto: Un solo autor. El primer apellido del autor, seguido de una coma
y la primera inicial, seguida de un punto, a continuacin, tras una coma, el ao de
publicacin. Todo entre corchetes. Dos o ms autores. Los nombres de los autores,
siguiendo el formato de un solo autor, separados por puntos y comas y el ao de
publicacin. Lista. Las listas debern ser ordenadas, primero de forma alfabtica y
luego, si fuera necesario, de forma cronolgica. Si hay ms de una referencia del mismo
autor en el mismo ao deben ser identificadas por las letras a, b, etc., situadas
despus del ao de su publicacin.
-Referencias. Vase Volumen 1 Nmero 1 de esta publicacin. Apartado 2.8.2.
Formato
-Tamao de la Pgina: Deber ser Carta (21,6 cm de ancho por 27,9 de largo). Las
pginas irn sin numeracin.
-Tipo de Letra: Deber ser Times New Roman
-Tamao y Formato de la letra y el texto: Ttulo: 18 Negrita. Texto Centrado. Ttulo de
Seccin: 14 Negrita. Alineacin Izquierda. Espaciado Anterior y Posterior 12. Ttulo de
Subseccin: 12 Negrita. Alineacin Izquierda. Espaciado Anterior y Posterior 6. Ttulo de
Sub-Subseccin: 12 Normal. Alineacin Izquierda. Espaciado Anterior y Posterior 6.
Texto: 12 Normal. Justificado. Espaciado Anterior y Posterior 0. Sangra en Primera
Lnea 1
-Interlineado: 1 Lnea
-Columnas: 2. Todo el texto excepto el ttulo, datos de los autores, abstract y resumen
debe presentarse a 2 columnas
Socios Institucionales
ALCAMPO S.A.
ALI
AI2
ASOCIACIN TCNICA DE CAJAS DE AHORROS
ATOS ORIGIN
BANCO DE ESPAA
BBVA
CAELUM INFORMATION & QUALITY TECHNOLOGIES
CARE TECHNOLOGIES S.A.
CAST SOFTWARE ESPAA
C.E.C.A.
CENTRO DE CLCULO DE ALAVA, S.A.
COMPUTER ASSOCIATES ESPAA
COMPUWARE, S.A.
CORITEL, S.L.
DELOITTE, S.L.
EL CORTE INGLS
ELITE SISTEMAS DE CONTROL
ENDESA SERVICIOS
EUROPEAN SOFTWARE INSTITUTE
EVERIS
EWORK-LINE TECHNOLOGY SERVICES, S.A.
GAS NATURAL INFORMTICA
GESEIN
IBERDROLA
IBERIA
ICM
IEE
INDRA SISTEMAS S.A.
INDRA SOFTWARE LABS, S.L.
INSA
ITDEUSTO, S.L.
LA CAIXA
LEDA CONSULTING, S.L.
LINEA DIRECTA ASEGURADORA
MAPFRE INTERNET
MTP
NESS PRO SPAIN
ONCE
OPTIMYTH SOFTWARE TECHNOLOGIES
SADIEL
SOFTWARE AG, ESPAA, S.A.
SOGETI ESPAA, S.L.
SOPRA PROFIT, SAU
TECNOLOGA Y CALIDAD DE SOFTWARE, S.A.
TELEFNICA DE ESPAA, S.A.U.
UNIVERSIDAD CARLOS III
UNIVERSIDAD DE ALCAL DE HENARES
UNIVERSIDAD DE DEUSTO
UNIVERSID OBERTA DE CATALUNYA
UNIVERSIDAD POLITCNICA DE MADRID
UNIVERSIDAD POLITCNICA DE VALENCIA
1 y 13
12
3 de noviem
n
mbre de 2008
8
IX Confe
erenc
cia An
nual de la Asocia
A
acin Espa
aola de
Mtricas de
d Sis
stema
as Info
ormtticos.
GESTI
G
N DE
EL SER
RVICIO
O DE T
TI:
G
GOBIE
ERNO,, INDIC
CADORES, MTR
M RICAS Y
FIN
NANZA
AS
PATROC
CINADORES
S PLATA
PATROCINADORES BRONCE

Test1-RPM - de La Gestion Por Procesos Al BPM

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Test1-RPM - de La Gestion Por Procesos Al BPM

Uploaded by

Copyright:

Available Formats

ISSN: 1698-2029

Asociacin Espaola de Mtricas del Software (AEMES)

La Asociacin Espaola de Mtricas de Sistemas Informticos (AEMES) es una

Revista fundada por la Asociacin

RPM-AEMES, VOL. 5, N 3, Octubre 2008

Gobierno de las Tecnologas de la Informacin, Seguridad Informtica, Gestin de Riesgos Tecnolgicos.

desde la propia infraestructura

Por un lado, existe una primera etapa

RPM-AEMES, VOL. 5, N 3, Octubre 2008

decir, el rea de seguridad coordina,

el momento plantearse la certificacin. El

Otro dato importante que hay que tener en

Figura 1. Ciclo de Vida del Programa de Seguridad.

El Gobierno de la Seguridad debe dar cobertura a todos los componentes bsicos de un

Actualmente la norma ms extendida que

Es preferible ir implementando paulatinamente los controles ms necesarios y si llega

Estrategia. A partir de la propia estrategia de negocio de la organizacin se

RPM-AEMES, VOL. 5, N 3, Octubre 2008

de los recursos de seguridad entre los

3. PRINCIPIOS DEL BUEN GOBIERNO

por otras funciones dentro de la organizacin.

RPM-AEMES, VOL. 5, N 3, Octubre 2008

El rea de Gobierno de la Seguridad trabaja

Definir y mantener la Poltica de Seguridad que ser de aplicacin a toda la

El rea de Anlisis de riesgos trabajar con

Inventario y clasificacin de activos.

El rea Formacin, Concienciacin y Sensibilizacin tiene como uno de los principales

El rea de Auditoras se ocupa fundamentalmente de la revisin de la implantacin del

Realizar auditoras de cumplimiento

Crear el programa de Auditora y seguimiento de controles.

Presentaciones divulgativa de la importancia de la Seguridad y de saber qu

RPM-AEMES, VOL. 5, N 3, Octubre 2008

Creacin de tests para que cada persona

El rea de Soporte se ocupa del soporte, tanto

establecidos por el rea de Gobierno,

5. INTEGRACIN DEL GOBIERNO DE

Gestin de los requisitos de Seguridad,

En este sentido, la gestin de proyectos de

RPM-AEMES, VOL. 5, N 3, Octubre 2008

Para los controles propuestos se adjuntarn las

Figura 3. Mapa de Competencias.

Viabilidad de Proyectos - Anlisis de

Mantenimiento preventivo y evolutivo. Para las aplicaciones/sistemas ya

El rea de seguridad se encarga de realizar el

Partiendo de esta informacin y del conocimiento que dispone el rea de seguridad de la

RPM-AEMES, VOL. 5, N 3, Octubre 2008

Documentacin. El rea de seguridad

[3] COBIT 4.1, IT Governance Institute

RPM-AEMES, VOL. 5, N 3, Octubre 2008

GOBERNADOR DE TI: NACE UN NUEVO PUESTO EN EL NIVEL DIRECTIVO

Buen gobierno corporativo de las TIC, Gobernador de TI, CGO, CGEIT.

Este escenario (con una creciente demanda,

RPM-AEMES, VOL. 5, N 3, Octubre 2008

2. CON LA MIRA PUESTA EN EL NEGOCIO

Entre las responsabilidades (o, dicho de otro

debern conocer las actuales tendencias, as como los principales modelos

RPM-AEMES, VOL. 5, N 3, Octubre 2008

tivos medibles. Todo ello, mediante

of Enterprise IT) (www.isaca.org/cgeit) propone

[5] CGEIT, Certified in the Governance of Enterprise

[6] CGEIT, Certified in the Governance of Enterprise

[7] Garca Menndez, Miguel. Towards a new C-level

RPM-AEMES, VOL. 5, N 3, Octubre 2008