Línea N° Documento

TR 110 Procedimiento de Análisis y Diseño

1. Introducción
El siguiente documento presenta el diseño lógico del Procedimiento de Análisis y diseño, el
diagrama del proceso, los roles y responsabilidades de la organización, basados en las
mejores prácticas sugeridas.

2. Objetivo
Asegurar una base estable de información para las etapas de Diseño y Desarrollo, analizar
y diseñar técnicamente en forma detallada los requerimientos del proyecto, cumpliendo
con las normativas internas de desarrollo de requerimientos y comprendiendo siempre las
necesidades de los Stakeholders.

3. Alcance
Todos los Proyectos bajo la supervisión de la Gerencia de Tecnología de SURA-Chile.

Procedimiento Nº 110 Análisis y Diseño

Responsable: Subgerencia de Desarrollo y Proyectos
Subgerencia: Desarrollo y Proyectos
Actualizado al 02/07/2014 (versión 1.2) 1
4. Procedimiento (narrativa)
Los proveedores de este proceso corresponden a los Líderes de Proyecto, Analistas de
Proyecto, el Área de Arquitectura, el Proveedor de Desarrollo y otros Stakeholders del
proceso.

Las entradas de este proceso corresponden a PMO-097-01 Carta Gantt Proyecto, PMO-
141-04 Especificación de Requerimiento ERU, PMO-097-01-Arquitectura, documento
Operational Security Guideline (OSG) para aplicaciones ya existentes.

Las actividades se centran en describir el flujo del proceso de Análisis y Diseño, definir roles
y responsabilidades de los involucrados en éste.

Las salidas son identificadas como documento PMO-097-01-Arquitectura, PMO-110-01-

Documento de Análisis y Diseño, PMO-110-02 Casos de Uso, PMO-110-03-Casos de
Prueba, PMO-110-04 Matriz de Acceso (Si aplica), Prototipo de Interfaz Usuaria (Si aplica),
PMO-110-05-OSG (Si aplica) y actualización de PMO-097-01 Carta Gantt Proyecto.

Los clientes del proceso son los Líderes de Proyecto, Proveedor de Desarrollo, Área de
Arquitectura, Área de Testing, Grupo de Administración de Acceso, el responsable de la
PMO y Área Usuaria.

4.1. El líder generará ticket de Solicitud de Documento de Arquitectura, adjuntando el

ERU, Guía de Clasificación de Activos y las especificaciones técnicas
(especificaciones no funcionales: funcionalidad, facilidad de uso, confiabilidad,
rendimiento, entre otras) de la aplicación, según las necesidades del negocio
revisadas con el usuario.

4.2. El Área de Arquitectura en base al correo con las especificaciones técnicas, el ERU
aprobado y el documento Guía de Clasificación de Activos enviados anteriormente
vía correo electrónico por el Líder de Proyecto, actualizará o generará el PMO-097-
01-Documento de Arquitectura y enviará vía correo electrónico la aprobación de
este documento al Líder del proyecto (* Email 1) o la evidencia del documento
firmado. [RT004, RT005, RT008, RT011] [CD1]

4.3. El líder enviará el documento de arquitectura al proveedor para que este elabore
alternativas de solución técnica.

4.4. El Proveedor de Desarrollo elaborará diferentes soluciones de implementación

técnica a nivel de detalle que satisfagan los requerimientos y cumplan con las
limitaciones establecidas para implementar la solución técnica más adecuada,
según el marco definido en el documento de arquitectura.

4.5. Posteriormente, el Área de Arquitectura revisará las alternativas de solución

propuesta, gestionará reuniones con el líder de proyecto y el Proveedor de
Desarrollo, con el objeto de acordar la solución técnica definitiva a implementar. El

Procedimiento Nº 110 Análisis y Diseño

Responsable: Subgerencia de Desarrollo y Proyectos
Subgerencia: Desarrollo y Proyectos
Actualizado al 02/07/2014 (versión 1.2) 2
 Líder de Proyecto generará una minuta de reunión, la enviará vía correo electrónico
a los involucrados a la reunión, quienes adjuntaran su V°B° o comentarios.

Este hito significa para el Proveedor el inicio del análisis de alternativas de solución
de desarrollo.

4.6. El proveedor realizará el análisis y diseño de la aplicación.

Para desarrollo de las aplicaciones se utilizarán las siguientes consideraciones:

 Identificar las clases conceptuales, sus atributos y las relaciones entre estas.

 Identificar los conceptos de negocio que están dentro del ámbito del problema
a analizar.

 Diseñar el Modelo de Datos (si aplica), de acuerdo a:

o Reglas técnicas universales de modelamiento de datos
o Normativas internas de almacenamiento de datos
o Requerimientos de negocio

 Validar si la aplicación a desarrollar requiere de la creación de un archivo log

para transacciones auditables.

 En base a los puntos anteriores, generar el documento PMO-110-01-

Documento de Análisis y Diseño y enviar vía correo electrónico al Líder de
Proyecto Sura-Chile. [RT008, RT010, RT012] [CD2]

 En base a documento ERU, elaborar el documento PMO-110-02-Casos de Uso

que detallen todos los flujos alternativos de la aplicación a construir en una
versión preliminar, la cual deberá ser validada por el usuario.

 Concretar el prototipo de interfaz usuaria en un diseño definitivo y sin lógica de

sistema (Si aplica).

Para paquetes o software cerrados dependiendo de los GAPs funcionales

(Funcionalidades no cubiertas por la versión estándar del aplicativo) que se deban
implementar sobre la línea base adquirida se deben efectuar las mismas
consideraciones que son utilizadas para desarrollo de aplicaciones.

4.7. El líder gestiona a través de ticket la validación del documento de análisis y diseño
por parte de arquitectura. Quienes generarán una reunión de trabajo con el
proveedor, en caso de existir diferencias y necesidad de corrección. Finalmente el
arquitecto del proyecto envía la aprobación del documento vía correo electrónico
(*Email 2) o la evidencia del documento firmado.

Procedimiento Nº 110 Análisis y Diseño

Responsable: Subgerencia de Desarrollo y Proyectos
Subgerencia: Desarrollo y Proyectos
Actualizado al 02/07/2014 (versión 1.2) 3
4.8. En caso aplique, el Líder de proyecto en conjunto con el Área Usuaria definen y
generan la Matriz de Acceso (PMO-110-04-Matriz de Acceso), que es publicada en
el sitio del proyecto y es enviada al Grupo de Administración de Acceso para su
posterior implementación.

4.9. En caso que aplique, evidenciado en el PO10-08 – Art-01 Checklist de Adherencia

Metodológica del proyecto, para cada especificación funcional se requiere generar
el documento de PMO-110-02-Casos de Uso o equivalente, en el cual se definan los
flujos alternativos (Inválidos). El documento de casos de uso será elaborado por el
proveedor en una versión inicial, el cual deberá ser revisado y aprobado por el
usuario de negocio, a través de correo electrónico al líder del proyecto o evidencia
del documento firmado. El Líder de Proyecto gestionará con el usuario la revisión y
la aprobación del documento PMO-110-02-Casos de Uso generado por el
proveedor, mediante un correo electrónico (*Email 3). [RT005, RT010] [CD3]

4.10. Dependiendo de la definición inicial del proyecto en acuerdo con el usuario, el

proveedor desarrollará un prototipo del aplicativo dejándolo disponible en un
ambiente de desarrollo Sura, e informando al líder de proyecto vía correo
electrónico la disponibilidad de éste.
Posteriormente el Líder de Proyecto informa al Área Usuaria que el prototipo se
encuentra disponible para su revisión y aprobación formal vía correo electrónico,
en caso de que existan observaciones al prototipo entregado se iterará hasta lograr
la aprobación.

4.11. En caso que aplique, evidenciado en la PO10-08 – Art-01 Checklist de Adherencia

Metodológica del proyecto, el líder de Proyecto solicita al Área Usuaria generar los
casos de pruebas en el documento PMO-0110-03 Casos de Prueba que certifiquen
la completitud de todas las funcionalidades del aplicativo a construir, guiado por los
casos de uso aprobados. El área usuaria envía por correo electrónico el documento
de casos de pruebas aprobado al líder del proyecto (*Email 4). [RT005, RT010,
RT011, RT012, RT017, RT018] [CD4]

4.12. En caso que aplique, evidenciado en el PO10-08 – Art-01 Checklist de Adherencia

Metodológica del proyecto, el Líder de Proyecto gestiona con el Área de Testing la
complementación del documento PMO-110-03-Casos de Prueba, a partir de los
casos de uso y del documento ERU, para ser utilizado en el proceso de pruebas.
Como resultado de este proceso, el Área de Testing entrega vía correo electrónico
al Líder de Proyecto la nueva versión del documento de Casos de Prueba (*Email
5).

4.13. El Líder de proyecto debe verificar y gestionar con las Áreas de Plataforma
(Arquitectura e Ingeniería de Sistemas) la disponibilidad del ambiente de pruebas y
configuraciones, tal que permitan al Área Usuaria realizar las pruebas
posteriormente en la etapa de certificación. El canal de comunicación de esta
actividad es a través de correo electrónico.

4.14. El Líder de proyecto generará el documento OSG (PMO-110-05- Documento OSG)

en caso de que se trate de una nueva aplicación. En caso de ser una aplicación

Procedimiento Nº 110 Análisis y Diseño

Responsable: Subgerencia de Desarrollo y Proyectos
Subgerencia: Desarrollo y Proyectos
Actualizado al 02/07/2014 (versión 1.2) 4
 existente, revisará si es necesario actualizar la OSG existente. La OSG se publicará
en el sitio del proyecto.

4.15. El Líder proyecto deberá actualizar la Carta Gantt del proyecto con todas las
actividades del proceso.

Procedimiento Nº 110 Análisis y Diseño

Responsable: Subgerencia de Desarrollo y Proyectos
Subgerencia: Desarrollo y Proyectos
Actualizado al 02/07/2014 (versión 1.2) 5
Plantillas de Correo para Evidencias de Controles
(*Email 1)

(*Email 2)

Procedimiento Nº 110 Análisis y Diseño

Responsable: Subgerencia de Desarrollo y Proyectos
Subgerencia: Desarrollo y Proyectos
Actualizado al 02/07/2014 (versión 1.2) 6
(*Email 3)

Procedimiento Nº 110 Análisis y Diseño

Responsable: Subgerencia de Desarrollo y Proyectos
Subgerencia: Desarrollo y Proyectos
Actualizado al 02/07/2014 (versión 1.2) 7
5. APLICACIONES TECNOLÓGICAS
Sistemas Financieros Claves : Este procedimiento no utiliza sistemas financieros claves.
Otros Sistemas : Sharepoint, Paquetería de Oficina

6. SEGREGACION DE FUNCIONES DEL PROCESO

Responsable 
Jefatura : Jefatura de Desarrollo Wealth Management
: Jefatura de Desarrollo Arquitectura
: Jefatura de Pensiones y Mantención
: Jefatura de Desarrollo Canales
: Jefatura de Desarrollo Sistemas Compartidos
: Jefatura de Desarrollo Proyectos I+D
Subgerencia : Subgerencia de Desarrollo y Proyectos
Gerencia : Gerencia de Tecnología
VP : Servicios Compartidos

Usuarios : Colaboradores de la subgerencia de Desarrollo y Proyectos, y

responsables de las distintas áreas de negocio de Sura-Chile.

Tipos de proceso:
Proceso (Manual / Automático) : Dependiente de Sistema
Aplicación/respaldo : Sharepoint, Paquetería de Oficina

Procedimiento Nº 110 Análisis y Diseño

Responsable: Subgerencia de Desarrollo y Proyectos
Subgerencia: Desarrollo y Proyectos
Actualizado al 02/07/2014 (versión 1.2) 8
7. SEGREGACIÓN DE FUNCIONES Y NIVELES DE AUTORIZACIÓN

Empresa: Sura Chile

Fecha: 19/08/13
Análisis realizado por: Jorge Avendaño, Verónica Emhart, Maria Isabel Gajardo, Raimundo Diaz,
Patricio Sotomayor, Eduardo Vasquez
Análisis aprobado por: Ricardo Yañez A.

Proceso de Análisis y Diseño

Actividad de Control Solicitud Autorización/ Ejecución
Validación
CD1: El Arquitecto asignado al Líder de Proyecto Líder de Proyecto Arquitecto
proyecto, elabora el Documento asignado
de Arquitectura que aborda las
especificaciones técnicas
conforme a los criterios del
documento Guía de Clasificación
de Activos. El Documento de
Arquitectura será enviado al
Líder de Proyecto vía correo
electrónico o evidencia del
documento firmado por el
arquitecto.
CD2: Por cada proyecto, el líder Líder de Proyecto Arquitecto Proveedor de
del proyecto solicita al asignado Desarrollo
proveedor o a los
desarrolladores internos la
generación del documento
"Análisis y Diseño". Este
documento es validado por el
Área de Arquitectura, quienes
envían por correo electrónico al
líder de proyecto su aprobación.
CD3: En caso que aplique, Líder de Proyecto Usuario del Proveedor de
evidenciado en el PO10-08 – Art- Negocio Desarrollo
01 Checklist de Adherencia
Metodológica del proyecto, para
cada especificación funcional se
requiere generar el documento
de PMO-110-02-Casos de Uso o
equivalente, en el cual se
definan los flujos alternativos
(Inválidos). El documento de
casos de uso será elaborado por
el proveedor en una versión
inicial, el cual deberá ser
revisado y aprobado por el

Procedimiento Nº 110 Análisis y Diseño

Responsable: Subgerencia de Desarrollo y Proyectos
Subgerencia: Desarrollo y Proyectos
Actualizado al 02/07/2014 (versión 1.2) 9
 Actividad de Control Solicitud Autorización/ Ejecución
Validación
usuario de negocio, a través de
correo electrónico al líder del
proyecto o evidencia del
documento firmado. El Líder de
Proyecto gestionará con el
usuario la revisión y la
aprobación del documento
PMO-110-02-Casos de Uso
generado por el proveedor,
mediante un correo electrónico.
CD4: En caso que aplique, Líder de Proyecto Testing / Usuario Testing /
evidenciado en la PO10-08 – Art- Usuario
01 Checklist de Adherencia
Metodológica del proyecto, el
líder de Proyecto solicita al Área
Usuaria generar los casos de
pruebas en el documento PMO-
0110-03 Casos de Prueba que
certifiquen la completitud de
todas las funcionalidades del
aplicativo a construir, guiado por
los casos de uso aprobados. El
área usuaria envía por correo
electrónico el documento de
casos de pruebas aprobado al
líder del proyecto.

Conclusión
¿Se ha identificado algún riesgo potencial de conflicto de funciones? SI NO
Si, se ha identificado algún riesgo potencial de conflicto de funciones, indicar en el
cuadro de abajo, la incompatibilidad y riesgo potencial.

Procedimiento Nº 110 Análisis y Diseño

Responsable: Subgerencia de Desarrollo y Proyectos
Subgerencia: Desarrollo y Proyectos
Actualizado al 02/07/2014 (versión 1.2) 10
8. CONCILIACIÓN DE LA INFORMACIÓN CON LA CONTABILIDAD,
CUENTAS CONTABLES ASOCIADAS Y/O OTROS
DEPARTAMENTOS INVOLUCRADOS
Este apartado no aplica ya que en el proceso no se realizan afectaciones a las cuentas
contables.

Procedimiento Nº 110 Análisis y Diseño

Responsable: Subgerencia de Desarrollo y Proyectos
Subgerencia: Desarrollo y Proyectos
Actualizado al 02/07/2014 (versión 1.2) 11
9. Flujograma del Proceso

Procedimiento Nº 110 Análisis y Diseño

Responsable: Subgerencia de Desarrollo y Proyectos
Subgerencia: Desarrollo y Proyectos
Actualizado al 02/07/2014 (versión 1.2) 12
Procedimiento Nº 110 Análisis y Diseño
Responsable: Subgerencia de Desarrollo y Proyectos
Subgerencia: Desarrollo y Proyectos
Actualizado al 02/07/2014 (versión 1.2) 13
10. Identificación de Riesgos y Controles
Los riesgos y controles, identificados e implementados en el proceso se encuentran
documentados en el archivo: “Matriz de riesgos tecnológicos SUAM SOX.xlsx”

Procedimiento Nº 110 Análisis y Diseño

Responsable: Subgerencia de Desarrollo y Proyectos
Subgerencia: Desarrollo y Proyectos
Actualizado al 02/07/2014 (versión 1.2) 14
11. FICHA DE APROBACIÓN PROCESO/ PROCEDIMIENTO/
MATRIZ DE RIESGO PARA CERTIFICACIÓN

IDENTIFICACIÓN DEL PROCESO

Nombre del proceso Análisis y Diseño
Gerencia a la que pertenece Gerencia de Tecnología
Responsable de primera línea Ricardo Yañez (Dueño del Proceso)
Fecha de Aprobación 19/08/2013
Próxima Actualización
DECLARACIÓN

Como Dueño del proceso identificado anteriormente, declaro por medio de este documento que
la información contenida en el procedimiento Análisis y Diseño, y su matriz de riesgo asociada,
representan la operativa vigente del proceso, los controles definidos mitigan los riesgos y se
encuentran operando, existiendo evidencia de ello.

Entendiendo que es responsabilidad de la línea que el procedimiento documentado se cumpla, en

caso que el proceso, procedimiento, riesgos y/o controles sufran cambios en la práctica y la
documentación asociada requiera modificaciones, estas deben ser reflejadas en el documento.

APROBACIONES FORMALES

GERENTE
Nombre: Cristian Barros Firma:
Cargo: Gerente de Tecnología

SUBGERENTE
Nombre: Ricardo Yañez Firma:
Cargo: Subgerente de Desarrollo y Proyectos

DUEÑO DE PROCESO
Nombre: Ricardo Yañez Firma:
Cargo: Subgerente de Desarrollo y Proyectos

RESPONSABLE DEL LEVANTAMIENTO

Nombre: Jorge Avendaño, Maria Isabel Gajardo, Firma:
Veronica Emhart, Eduardo Vasquez, Raimundo Diaz,
Patricio Sotomayor.
Cargo: Jefe Arquitectura, Jefe de Desarrollo Wealth
Management, Jefe de Desarrollo Canales, Jefe de
Desarrollo Sistemas Compartidos, Jefe de Desarrollo
Pensiones y Mantención, Jefe de Desarrollo Proyectos
I+D

Procedimiento Nº 110 Análisis y Diseño

Responsable: Subgerencia de Desarrollo y Proyectos
Subgerencia: Desarrollo y Proyectos
Actualizado al 02/07/2014 (versión 1.2) 15
 12. REVISION DEL DOCUMENTO
El procedimiento será sujeto a una revisión mínima anual que será plasmada dentro del
presente documento, independientemente de que necesite ser actualizado o no por algún
cambio funcional en el proceso.

El registro de actualizaciones quedará reflejado en la siguiente tabla de control de cambios:

HOJA DE MODIFICACIÓN
Revisado y
Modificaciones Fecha Realizado por (Área / Nombre
Versión aprobado
efectuadas aaaa/mm/dd colaborador
(Nombre Cargo)
Desarrollo Wealth Management/
Jorge Avendaño,
Desarrollo Canales y BI/ Verónica
2013/08/19 Emhart, Ricardo Yañez A. /
Actualización del Desarrollo Sistemas Compartidos / Subgerente de
1.0
documento. Rodrigo Vial Desarrollo y
Desarrollo Pensiones y Mantención / Proyectos
Raimundo Diaz
Desarrollo Proyectos I+D / Patricio
Sotomayor
Desarrollo Wealth Management/
Jorge Avendaño,
Desarrollo Canales y BI/ Verónica
Emhart, Ricardo Yañez A. /
Actualización del
Desarrollo Sistemas Compartidos / Subgerente de
1.1 documento, cambios 2013/11/14
Rodrigo Vial Desarrollo y
de forma.
Desarrollo Pensiones y Mantención / Proyectos
Raimundo Diaz
Desarrollo Proyectos I+D / Patricio
Sotomayor
Actualización de
narrativa de Ricardo Yañez A. /
controles. Subgerente de
1.2 2014/07/02 Desarrollo Canales / Verónica Emhart
Cambio en los Desarrollo y
responsables de Proyectos
levantamiento.

Estándar para el uso del número de control de versión:

• Utilizar un digito, seguido de un punto (separador), y otro dígito. Ej: 1.1, 2.0, 9.3.

Procedimiento Nº 110 Análisis y Diseño

Responsable: Subgerencia de Desarrollo y Proyectos
Subgerencia: Desarrollo y Proyectos
Actualizado al 02/07/2014 (versión 1.2) 16
 • El primer dígito se utilizará representar para cambios mayores en el documento, relacionados principalmente a cambios en la ejecución del proceso.
• El segundo dígito se utilizará para representar cambios menores en el documento, relacionados a cambios de forma. Incluye la revisión mínima
realizadas al procedimiento.

Procedimiento Nº 110 Análisis y Diseño

Responsable: Subgerencia de Desarrollo y Proyectos
Subgerencia: Desarrollo y Proyectos
Actualizado al 02/07/2014 (versión 1.2) 17