proceso gestionar nuevos desarrollos

PROCESO GESTIONAR NUEVOS DESARROLLOS Archivo: Manual de Proceso Gestionar_Nuevos_Desarrollos Página 1 de 50 Versión : 4 Fecha Versión: 03.07.2017 Estado: Vigente

PROCESO

GESTIONAR NUEVOS DESARROLLOS

REGISTRO DE CAMBIOS

Nro. de versión

Fecha Tipo(1) Descripción del cambio Autor

1.0 25/06/2014 N Creación Documento Orietta Montolivo Aguirre

2.0 11/11/2015 M Se abrió el subproceso Ejecutar Proyecto. Orietta Montolivo Aguirre

3.0 27/04/2017 M Se actualiza Flujo de Gestionar Nuevos Desarrollos

Orietta Montolivo Aguirre

4.0 03/07/2017 M Se actualiza Flujo de Gestionar Nuevos Desarrollos

Orietta Montolivo Aguirre

(1) N: Nuevo – M: Modificar – E: Eliminar


PROCESO

GESTIONAR NUEVOS DESARROLLOS

1. Objetivo Proceso Gestionar Nuevos Desarrollos ........................................................................ 4

2. Propósito del Proceso Gestionar Nuevos Desarrollos .................................................................. 4

3. Alcances Proceso .............................................................................................................. 4

4. Fuera del Alcance .............................................................................................................. 4

5. Responsabilidad y Autoridad................................................................................................. 4

6. Diccionario de Roles ........................................................................................................... 4

7. Referencias Normativas, leyes, políticas asociadas y otras ........................................................... 5

8. Consideraciones Generales .................................................................................................. 6

9. Definiciones ........................................................................................................................ 6

10. Proceso Gestionar Nuevos Desarrollos - Nivel 1 ............................................................................ 7

10.1 Flujo de Actividades Proceso Gestionar Nuevos Desarrollos ........................................................... 7

10.2 Descriptivo de Actividades Proceso Gestionar Nuevos Desarrollos ................................................... 8

11. Subproceso Realizar Levantamiento de Requerimiento Inicial - Nivel 2 ............................................. 15

11.1 Flujo de Actividades Subproceso Realizar Levantamiento de Requerimiento Inicial ............................ 15

11.2 Descriptivo de Actividades Subproceso Realizar Levantamiento de Requerimiento Inicial .................... 15

12. Subproceso Ejecutar Proyecto - Nivel 2 .................................................................................... 19

12.1 Flujo de Actividades Subproceso Ejecutar Proyecto .................................................................... 19

12.2 Descriptivo de Actividades Subproceso Ejecutar Proyecto ............................................................ 19

13. Subproceso Generar Ticket - Nivel 2 ........................................................................................ 22

13.1 Flujo de Actividades Subproceso Generar Ticket ....................................................................... 22

13.2 Descriptivo de Actividades Subproceso Generar Ticket ............................................................... 23

14. Subproceso Generar Casos de Pruebas - Nivel 2 ........................................................................ 27

14.1 Flujo de Actividades Subproceso Generar Casos de Pruebas ....................................................... 27

14.2 Descriptivo de Actividades Subproceso Generar Casos de Pruebas ............................................... 27

15. Subproceso Aplicar Ciclo de Pruebas - Nivel 2 ............................................................................ 30

15.1 Flujo de Actividades Subproceso Aplicar Ciclo de Pruebas ........................................................... 30

15.2 Descriptivo de Actividades Subproceso Aplicar Ciclo de Pruebas ................................................... 30

16. Proceso Gestionar Nuevos Desarrollos Internos .......................................................................... 33


16.1 Flujo de Actividades Proceso Gestionar Nuevos Desarrollos Internos ............................................. 33

16.2 Descriptivo de Actividades Proceso Gestionar Nuevos Desarrollos Internos ..................................... 34

17. Subproceso Realizar Paso a Producción ................................................................................... 39

17.1 Flujo de Actividades Subproceso Realizar Paso a Producción ....................................................... 39

17.2 Descriptivo de Actividades Subproceso Realizar Paso a Producción ............................................... 40

18. Indicadores ........................................................................................................................ 43

19. Anexos ............................................................................................................................. 44


1. Objetivo Proceso Gestionar Nuevos Desarrollos

El proceso de Gestionar Nuevos Desarrollos, tiene como objetivo proveer un ciclo de vida de desarrollo, para todos los nuevos Proyectos y nuevos servicios de la Subsecretaría de Evaluación Social.

2. Propósito del Proceso Gestionar Nuevos Desarrollos

Estandarizar y alinear los principales roles que interactúan con el desarrollo de nuevas funcionalidades de los componentes y/o nuevos servicios de la Subsecretaría de Evaluación Social. Adicionalmente, el propósito del proceso busca lograr una alineación con la contraparte operativa y la posibilidad de gestionar recursos para éstos, dentro de los cuales encontramos:

Cartera de proyectos/servicios. Estandarización de desarrollos. Estandarización de gestión de proyectos (Gantt adecuadas) Alineamiento con la PMO.

3. Alcances Proceso

El proceso abarca desde la solicitud de un requerimiento de tipo informático, por parte de un Jefe de Departamento, Jefe de División o Unidad en particular, hasta el Desarrollo de la solución y puesta en producción. Este proceso incluye sólo a la Subsecretaría de Evaluación Social.

4. Fuera del Alcance

El detalle del proceso de compra, que es responsabilidad de División de Administración y Finanzas, no se detallará en este manual.

5. Responsabilidad y Autoridad Jefe(a) de División de Información Social.

6. Diccionario de Roles

Los roles relevantes para el cumplimiento de este procedimiento y sus funciones principales son los siguientes:

Cargo/Rol Responsabilidad

Contraparte Operativa (Jefe(a) de Departamento, Jefe(a) de División o Unidad en Particular)

Solicitar nuevos Proyectos y/o servicios que tengan relación a sus propios Departamentos y/o solicitudes necesarias.

Financiamiento del proyecto.


Jefe(a) DSIS/DAIS

Según requerimientos ingresados deberá planificar los nuevos Desarrollos según requerimientos ingresados por la Contraparte Operativa.

Evaluar requerimientos según requerimientos ingresados por la Contraparte Operativa.

Recepcionar requerimientos y asignarlos a Coordinador PMO para evaluar presupuesto.

Encargada(o) Gestión Interna (SES)

Analizar presupuesto según requerimiento.

Jefe(a) de Proyectos

Entregar soporte y guía sobre la gestión de los Proyectos en cursos. Evaluar proveedores externos para las soluciones licitadas. Evaluar requerimientos según requerimientos ingresados por la contraparte.

Proveedor Diseñar solución del requerimiento. Generar Casos de Pruebas.

Oficial de Seguridad de la Información

Validar Informe de Vulnerabilidades.

Especialista de Sistemas

Crear Ambientes de Desarrollo, QA y Producción Generar Informe de Vulnerabilidades RFC QA RFC Producción

Especialista QA

Revisar requerimientos entregados por proveedor. Planificar requerimientos. Asignar tareas a analistas QA Gestionar la revisión de Plan de pruebas, casos de pruebas y ejecución de

pruebas Dar Ok de las pruebas en QA

Analista QA

Validar ambientes. Revisar documentación Generar casos de pruebas Ejecutar casos de pruebas Reportar incidencias Realizar informes asociados a las pruebas (avance, evidencias e incidencias)

7. Referencias Normativas, leyes, políticas asociadas y otras

Manual de Proceso PMO – Sub Proceso Nuevos Proyectos. Ley 19.628 sobre Protección de la Vida Privada. Ley N°19223 Tipifica figuras penales relativas a la informática

Ley 20285/2008 Acceso a la información pública.

ISO NCH 27001


8. Consideraciones Generales

El levantamiento realizado incorpora un análisis actual del Proceso Generar Nuevos Desarrollos, dicho levantamiento no considera sub procesos y/o actividades no realizadas actualmente por la División de Información Social.

9. Definiciones AMBIENTE DE DESARROLLO: Ambiente utilizado para el desarrollo de software, cuenta con los elementos necesarios para la ejecución de pruebas, previas a las efectuadas en ambiente de Pruebas. AMBIENTE DE PRUEBAS QA: Ambiente utilizado para la ejecución de pruebas técnicas y funcionales de los sistemas. AMBIENTE DE PRODUCCIÓN: Ambiente computacional en donde se encuentra la información y programas oficiales de la institución. Con relación a los otros ambientes, tiene restricciones de acceso a nivel de red, a nivel de Aplicación, de Base de Datos y de plataforma. PAU: Pruebas de Aceptación de Usuarios, pruebas que realizan los usuarios que realizaron los requerimientos del sistema, estas pruebas son las funcionales.

RFC: (Request For Change) documento que se genera para detallar los tipo de cambios a las plataformas ya sea de Desarrollo, QA y Producción.

CASOS DE PRUEBAS: O también denominado Inventario de casos de pruebas, este documento muestra todos los tipos de casos de pruebas que se quiere validar y verificar del sistema, se indicará la funcionalidad que se probará, el resultado que se espera obtener y las restricciones o dependencias.

PRUEBAS DE REGRESIÓN: Son las pruebas que se realizan después de la corrección de una(as) incidencia (s) o después de la adición de nuevas funcionalidades.


10. Proceso Gestionar Nuevos Desarrollos - Nivel 1 10.1 Flujo de Actividades Proceso Gestionar Nuevos Desarrollos


10.2 Descriptivo de Actividades Proceso Gestionar Nuevos Desarrollos

Act

ivid

ad

Nombre Actividad (¿Qué?)

Cargo (¿Quién?)

Entrada Descripción (¿Cómo?)

Ir a

Tiempo ¿Cuándo? ¿Cuánto?

Aplicación (Sistema)

Salida (Registros)

1 Generar

requerimiento Contraparte Operativa

Solicita nuevos Proyectos y/o servicios que tengan relación a sus propios Departamentos y/o solicitudes necesarias. El memorándum debe indicar CDP, comienzo de la compra y además especificaciones de lo que se quiere desarrollar.

2

Se realiza en el caso de

necesitar un nuevo

requerimiento.

Correo o Minuta reunión

2 Recepcionar

Requerimiento Jefatura

DSIS/DAIS


Recepciona y revisa el requerimiento por parte de algún Jefe de División, Jefe de Departamento o Unidad Particular.

3


solicitar nuevo requerimiento.


3

Evaluar prefactibilidad y disponibilidad de

recursos

Jefatura Dpto.

Sistemas de la Información


Analizar prefactibilidad del requerimiento en cuanto a tiempos. costo y alcance y además ver disponibilidad de recursos. ¿Existe Prefactibilidad y disponibilidad de recursos?

- Sí - No

5 o 4



4 Informar la no prefactibilidad

Jefatura Dpto.


Se debe informar a la contraparte en el caso de considerar la no prefactibilidad del requerimiento.

Fin

Se realiza en el caso de no

existir prefactibilidad

para el requerimiento.

Correo electrónico

Correo o Memorándum

5 Revisar

Presupuesto

Encargada(o) Gestión Interna

Memorándum

Una vez que recepciona el requerimiento por parte de la Jefatura DSIS/DAIS, la Encargada de Gestión Interna revisa el requerimiento y analiza si existe presupuesto para ser asignado el requerimiento al Jefe de Proyectos correspondiente. ¿Existe Presupuesto?

- Sí - No

7 6

Se realiza inmediatamente cuando se

recibe el requerimiento. Esta actividad puede durar

como máximo 3 días hábiles

Correo electrónico

Correo electrónico

con asignación del requerimiento

6 Informar Falta de

Presupuesto

Encargado Gestión Interna

Se le informa a la Contraparte Operativa que no existe presupuesto para ser asignado al requerimiento.

Fin

Se realiza inmediatamente revisado el presupuesto.

Correo electrónico

Correo

7 Asignar

Requerimiento

Jefatura Dpto.


Existiendo presupuesto asigna requerimiento a Jefe de Proyectos.

8


Correo electrónico

Correo

8

Subproceso Realizar

levantamiento de requerimiento

Jefe de Proyectos

Ir al Subproceso Realizar Levantamiento de Requerimiento Inicial.

9 Se indica en Subproceso

Reunión kick off agendada

DIC


Act

ivid

ad


Cargo (¿Quién?)


Ir a



Salida (Registros)

inicial

9

Generar memo de solicitud CDP y

formalización de la compra


Una vez que recibe la documentación genera memo de solicitud de CDP y formalización de la compra.

10

Esta actividad se realiza una

vez que genera el

documento de compra. El tiempo máximo

estimado para realizar esta actividad es

de 3 días hábiles

Memorándum Formulario de

Compra

10 Solicitar CDP y

formalización de la compra

Jefe(a) de División de Información

Social

Una vez que recibe memo de solicitud de CDP lo firma y procede a la solicitud más la formalización de la compra a la DAF.

11


vez que genera el

documento de compra. El tiempo máximo

estimado para realizar esta actividad es

de 3 días hábiles


Compra

11 Subproceso

Gestionar Compra DAF


Compra

Recibida la solicitud a través de Gestión Interna, la División de Administración y Finanzas gestiona la compra.

12


vez que recepciona la

solicitud. El tiempo máximo

estimado para realizar esta actividad se encuentra

establecido en manual de compras

institucional.

12 Ejecutar reunión

Kickoff con proveedor


Presentación de Kick Off

Se realiza reunión de kick off con Proveedor.

13

Se realiza una vez hecho el

levantamiento de

requerimiento. Esta actividad puede durar

como máximo 1 día hábil

Minuta reunión

13 Entregar

Documento de Análisis de

Proveedor Minuta

reunión; kickoff, Oferta

Proveedor analiza y entrega los requerimientos solicitados al Jefe de Proyectos para su validación.

14 Se realiza una vez ejecutada la reunión kick

Documento de requerimientos, matriz de


Act

ivid

ad


Cargo (¿Quién?)


Ir a



Salida (Registros)

Requerimiento Técnica

off. El tiempo dependerá del

tipo de proyecto.

trazabilidad

14

Revisar Documento de

Análisis de Requerimiento


Documento de

requerimientos, Matriz de trazabilidad

El Jefe de Proyectos revisa los requerimientos entregados por el proveedor. ¿Aprueba?

- Sí - No

15 13

Se realiza una vez entregado

el requerimiento. Esta actividad puede durar entre 2 a 10 días hábiles

Acta de aprobación del requerimiento,

Matriz de trazabilidad

15 Revisar

Documento de Requerimiento

Contraparte Operativa

Acta de aprobación

del requerimiento

Recibe el requerimiento y lo revisa para ver si corresponde a su solicitud. ¿Aprueba?

- Sí - No

16 14

Se realiza una vez aprobado el documento por Jefe de Proyectos.

Esta actividad puede durar entre 2 a 10 días hábiles

Acta de

aprobación del requerimiento

16 Subproceso

Ejecutar Proyecto Proveedor

Documento Requerimientos, Matriz de trazabilidad

Si la contraparte operativa aprueba el requerimiento, el proveedor comienza a diseñar la solución.

17

Se realiza una vez aprobado el documento

por la Contraparte Operativa. El tiempo

depende tipo del proyecto.

Modelo de datos,

Prototipos sistema,

Casos de Uso, Matriz de

trazabilidad (dependiendo

tipo de proyecto)

17 Realizar Revisión

de entregables Jefe(a) de Proyectos

Casos de Uso ,

Requerimientos, Matriz de trazabilidad

Especialista QA revisa si los requerimientos están de acuerdo a los casos de uso y valida la matriz de trazabilidad.

18

Se realiza una vez diseñada la solución. El

tiempo depende del

tipo de proyecto

Acta de aprobación del requerimiento


18 Solicitar ambientes Jefe(a) de Proyectos

Acta de aprobación

del requerimiento

Diseñada la solución, el Jefe de Proyectos solicita los ambientes al Especialista de Sistemas.

19

Se realiza una vez revisados

los entregables

por Especialista

QA. Esta actividad

puede durar como máximo

1 día hábil

Aranda Ticket solicitud de ambientes

19 Recepcionar

Solicitud Especialista de Sistemas

Ticket solicitud de ambientes

Recepciona solicitud de ambientes. 20

Esta actividad puede durar


Aranda

20 Crear ambiente QA Especialista de Sistemas

Crea ambiente QA y el Coordinador de Sistemas envía notificación del ambiente ya creado.

21 Se realiza una

vez recepcionada

Correo electrónico

Notificación de ambiente creado.


Act

ivid

ad


Cargo (¿Quién?)


Ir a



Salida (Registros)

la solicitud. Esta actividad puede durar

como máximo 5 días hábiles (en paralelo act 15, 17)

21 Crear ambiente

producción Especialista de Sistemas

Crea ambiente de producción y el Coordinador de Sistemas envía notificación del ambiente ya creado.

22

Se realiza una vez

recepcionada la solicitud.


como máximo 5 días hábiles (en paralelo

15, 16)

Correo electrónico


22

Realizar pruebas de humo en

ambiente desarrollo


Se realizan las pruebas de humo en ambiente de desarrollo. ¿Pruebas ok?

- Sí

- No

23 16

Se realiza una vez creado los

ambientes. Esta actividad puede durar


23 Revisar ambientes Especialista

QA

Notificación de ambiente

creado.

Creado los ambientes, el Especialista QA en conjunto con el Jefe Proyectos revisa y valida los ambientes en función al acceso a aplicativos y Base de Datos. ¿Aprueba?

- Sí - No

24 18




Acta de

aprobación de ambientes.

24 Subproceso

Generar Ticket Jefe(a) de Proyectos

Ir al Subproceso Generar Ticket. 25 Se indica en Subproceso

25 Instalar aplicativo en ambiente QA


El especialista de sistemas realiza el paso de todos los fuentes, componentes tanto de Aplicación como Base de Datos a este nuevo ambiente.

26

Se realiza una vez generado

el RFC. El tiempo

depende del tipo de

proyecto

Correo electrónico

26 Recibir notificación de instalación de

aplicativo


Notificación de instalación de aplicativo

Una vez instalado el aplicativo por parte del Especialista de Sistemas, notifica al Jefe(a) de Proyectos la instalación.

27 Correo

electrónico

27 Realizar pruebas

de humo en ambiente QA MDS


Evidencias de los casos de pruebas en ambiente de

desarrollo

Implementada la solución se realizan las pruebas con funcionalidades más críticas en ambiente QA MDS. .(Esta designación de casos las realiza el Especialista QA del MDS para el proveedor) ¿Pruebas ok?

- Sí - No

28 16

Se realiza una vez instalado el aplicativo.



Informe de Evidencia de los casos de pruebas en

ambiente QA MDS, Informe de resultados de Ciclos de

pruebas


Act

ivid

ad


Cargo (¿Quién?)


Ir a



Salida (Registros)

28 Subproceso

Aplicar ciclo de pruebas

Especialista QA

Ir al Subproceso Aplicar Ciclo de pruebas. ¿Pruebas ok?

- Sí - No

30 29

Se indica en Subproceso

29 Enviar incidencias

a proveedor Especialista

QA

Si las pruebas no están correctas, se deben enviar las incidencias al proveedor para su evaluación. Si es necesario se agenda una reunión para discutir las criticidades de éstas.

16

Se realiza una vez que le

ciclo de pruebas está

correcto.

Correo electrónico

Informe Resultado Incidencias

30 Revisar documento cierre de pruebas

Jefe(a) Proyectos TI

Informe cierre de pruebas

Recepciona informe de cierre de pruebas y revisa para luego ser enviado a la contraparte. ¿OK?

- Sí - No

31 28

Se realiza una vez enviado el

documento.

Correo electrónico


31 Revisar casos de

pruebas de Negocio


Informe cierre de pruebas Casos de

pruebas de negocio

Recepcionado el Documento cierre de pruebas y los casos de pruebas, la contraparte realiza una revisión.

32

Se realiza una vez que losl documentos

están correctos.


como máximo 7 días hábiles,

periódico

Correo electrónico

Casos de pruebas de

negocio

32 Ejecutar Casos de

Pruebas Contraparte Operativa

Casos de pruebas de

negocio

La Contraparte ejecuta los casos de pruebas. ¿OK?

- Sí - No

36 33

Se realiza una vez revisados los casos de

pruebas. Esta actividad


14 días hábiles

Dependiendo del tipo

de requerimien

to

Casos de pruebas de

negocio

33 Informar Incidentes

a JP Contraparte Operativa

Si al ejecutar los casos de pruebas se encuentra algún tipo de incidente, este se debe informar al Jefe de Proyectos TI.

34


que los casos de pruebas no se ejecutaron correctamente

.

Correo electrónico

34 Enviar incidencias

a proveedor Jefe(a)

Proyectos Planilla de incidencias

Una vez que el Jefe de Proyectos sea informado de los incidentes este a su vez debe informar al proveedor.

35


que los casos de pruebas no se ejecutaron correctamente

Correo electrónico

Planilla de incidencias

35 Resolver

incidencias Proveedor

El proveedor resuelve las incidencias notificadas.

31

36 Enviar Correo a JP Contraparte Operativa

Informe final de aceptación

de pruebas

Si el documento está correcto, se envía por correo al Jefe de Proyectos.

37

Se realiza una vez creado el documento

final de

Correo electrónico

Informe final de aceptación

de pruebas


Act

ivid

ad


Cargo (¿Quién?)


Ir a



Salida (Registros)

pruebas.

37 Firmar Actas de Validación PAU


Documento Casos de pruebas

Si las pruebas de aceptación de usuarios están correctas, la contraparte debe certificar las pruebas de usuario mediante un Acta de Validación PAU.

38 Depende del

tipo del proyecto

Correo electrónico

Acta de validación de

PAU.

38 Solicitar evaluación de vulnerabilidades


Datos de los aplicativos

Solicita evaluación de vulnerabilidades a través de ticket a Especialista de Sistemas.

39

Se realiza una vez hecha las

pruebas funcionales.



Aranda

Ticket de solicitud de

ejecución de vulnerabilidad

es

39 Ejecutar

vulnerabilidades

Especialista de

Infraestructura

Ticket de solicitud de

ejecución de vulnerabilidad

es Datos de los aplicativos

Si las pruebas en ambiente QA están correctas, el Especialista evalúa las vulnerabilidades.

40

Se realiza una vez solicitada la ejecución.



Qualys

40 Generar Informe Especialista

de Infraestructura

Genera informe de vulnerabilidades y lo envía al Jefe de Proyecto.

41

Se realiza una vez ejecutada

las vulnerabilidad

es. Esta actividad


1 día hábil

Qualys Informe de

vulnerabilidades

41 Evaluar Informe con proveedor


Informe de vulnerabilidad

es

Recepcionado el informe de vulnerabilidades, junto con el proveedor evalúa los resultados del informe. ¿OK?

- Sí - No

43 42


el informe. Esta actividad puede durar


Minuta de Reunión

(vulnerabilidades a resolver)

42 Resolver

vulnerabilidades 3,4 y5

Proveedor

Minuta de Reunión

(vulnerabilidades a

resolver)

Se le solicita al proveedor que resuelva las vulnerabilidades indicadas en el informe.

43

Se realiza una vez evaluado

el informe. Depende el

tipo de cambio e

impacto en el sistema.

Entregable de

la solución.

43 Enviar Informe de Vulnerabilidad a

Seguridad



Si las pruebas están correctas, se envía el informe de vulnerabilidad al Oficial de Seguridad de la Información para que valide.

44

Se realiza una vez evaluado

el informe. Esta actividad puede durar


Informe de

vulnerabilidad


Act

ivid

ad


Cargo (¿Quién?)


Ir a



Salida (Registros)

44 Recepcionar

Informe

Oficial de Seguridad de la Información


Recepciona Informe de Vulnerabilidad para su revisión.

45 Correo

electrónico Informe de

vulnerabilidad

45 Evaluar Informe Oficial de

Seguridad de la Información


Revisa y valida informe de vulnerabilidad. ¿Aprueba?

- Sí - No

46 41

Se realiza una vez

recepcionado el informe.



Correo electrónico

Notificación de validación

46 Recepcionar




Si el Oficial de Seguridad aprueba el proyecto, el Jefe de Proyectos recepciona notificación de aceptación.

47 Correo

electrónico

47 Subproceso

Realizar paso a producción


RFC, Manuales de instalación, operación,

explotación.

Si las pruebas están correctas ir al Proceso Realizar Paso a Producción.

Fin Se indica en Subproceso

Sistema en producción.


11. Subproceso Realizar Levantamiento de Requerimiento Inicial - Nivel 2 11.1 Flujo de Actividades Subproceso Realizar Levantamiento de Requerimiento Inicial

11.2 Descriptivo de Actividades Subproceso Realizar Levantamiento de Requerimiento Inicial

Act

ivid

ad


Cargo (¿Quién?)


Ir a



Salida (Registros)

1 Realizar

Levantamiento Jefe(a) de Proyectos

Memo Requerimiento de parte de

Área Funcional

Levantar requerimientos de Proyecto, considerando aspectos tales como: • Req. Funcionales

• Operativos • Flujos • Reportes • Perfiles • funcionales

• Req. Sistemas • licencias, SO, BD

• Req. Infraestructura • Espacio Disco Servidores

Web, • Servidores de Aplicación y BD

• Req. ambientes: QA y PRD

2

Se realiza una vez

asignado el requerimien

to. El tiempo

depende de disponibilid

ad de involucrado

s significativo

s.

Documento de Requerimiento

s Preliminar


Act

ivid

ad


Cargo (¿Quién?)


Ir a



Salida (Registros)

• Req. Desarrollo • Lenguaje, Patrones y Modelos • Documentación • Doc. Levantamiento

• Doc. Diseño Funcional (dirigido a Negocio)

• Doc. Diseño Técnico de Solución

• Doc. Diseño de Arquitectura (dirigido a Infraestructura)

• Manuales: usuario, administrador, explotación e instalación

• Capacitaciones • Usuario • Usuario Administrador • TI (Infra + Sistemas) • Pruebas • Período Ajustes

(horas/período) • Req. Seguridad

2 Generar propuesta

de desarrollo Jefe(a) de Proyectos

Documento de

Requerimientos Preliminar

Genera la propuesta de desarrollo considerando una solución tentativa preliminar.

3

Se realiza una vez

realizado el levantamien

to. Esta actividad

puede durar como

máximo 5 días hábiles

Preliminar DIC

3 Realizar Reunión Involucrados Significativos

Preliminar DIC

Reunión con los Involucrados Significativos del proceso (Jefe de Sistemas, Jefe de Infraestructura, Oficial de Seguridad, Coordinador de Desarrollo, Jefe de TI y Procesos, Jefe de Proyecto, Arquitecto TI). Esta reunión se puede realizar más de una vez hasta que no encontrar observaciones. ¿Hay observaciones?

- Sí - No

4 5

Se realiza una vez

generada la propuesta

de desarrollo.

Esta actividad

puede durar como

máximo 2 reuniones,

3 días

Minuta Reunión

Preliminar DIC validado

4 Informar a la contraparte


Preliminar DIC

En el caso de haber observaciones en la propuesta, se debe informar a contraparte.

Fin

Se realiza una vez

encontrado observacion

es en el requerimien

to.

5 Elaborar propuesta Jefe(a) de Proyectos

Preliminar DIC

Si no hay observaciones, el Jefe de Proyectos TI elabora propuesta.

6

Se realiza una vez

realizada la reunión con

los

Preliminar DIC


Act

ivid

ad


Cargo (¿Quién?)


Ir a



Salida (Registros)

involucrados

significativos del

proceso. Esta

actividad puede durar

como máximo 2

días hábiles

6 Revisar Propuesta Contraparte Operativa

Preliminar DIC

Revisar para su validación. ¿Valida?

- Sí - No

7 2

Se realiza una vez

elaborada la

propuesta .Esta


como máximo 3

días hábiles

Preliminar DIC

validado

7 Generar

Documentos para PMO


Preliminar DIC validado

Si la propuesta es validada por la contraparte, genera documentos para PMO.

8

Se realiza una vez

validada la propuesta .

Esta actividad

puede durar como

máximo 2 días

Acta de

Constitución, DIC

8 Revisar

Documentación Encargado(a)

PMO

Acta de Constitución,

DIC

Validar documentación entregada y solicitar CDP. ¿Valida?

- Sí - No

9 6

Se realiza una vez

generado los

documentos. Esta


como máximo 8

días hábiles

CDP, Acta de Constitución validada, DIC

validado

9

Revisar DIC Coordinador(a

) de Desarrollos

DIC

Revisa documento para su validación antes de ser entregado a la contraparte. ¿Aprueba?

- Sí - No

11 8

Se realiza una vez

validada la documentación Esta actividad

puede durar como


DIC aprobado

por Coordinador

10 Revisar DIC Contraparte Operativa

DIC validado coordinador

Una vez que es validado por el Coordinador de Desarrollo, este le envía a la contraparte para su

Se realiza una vez

revisado y

DIC aprobado por

Contraparte


Act

ivid

ad


Cargo (¿Quién?)


Ir a



Salida (Registros)

validación. ¿Aprueba?

- Sí - No

11 7

validado por el

Coordinador de

Desarrollo. Esta


como máximo 3

días hábiles

11 Gestionar Compras

DIC Si el DIC es validado por la Contraparte ir al Proceso de Gestionar Compras.

Fin Se indica

en Subproceso

Documento con ofertas

CDP


12. Subproceso Ejecutar Proyecto - Nivel 2 12.1 Flujo de Actividades Subproceso Ejecutar Proyecto

12.2 Descriptivo de Actividades Subproceso Ejecutar Proyecto

Act

ivid

ad


Cargo (¿Quién?)


Ir a


Aplicación

(Sistema)

Salida (Registros)

1 Revisar

Documentos Proveedor

DIC, Documento de Requerimientos

Revisa todos los documentos (DIC y Documento de Requerimientos) para posteriormente reunirse con la contraparte.

2

Se realiza una vez validado el documento de

análisis de requerimientos

por la Contraparte.



DIC, Documento de Requerimiento

s

2 Realizar reunión con Contraparte

Proveedor DIC,

Documento de Se realiza reunión con la contraparte junto con el Jefe de

3 Se realiza una

vez revisado los

Minuta Documento de


Act

ivid

ad


Cargo (¿Quién?)


Ir a


Aplicación

(Sistema)

Salida (Registros)

Requerimientos Proyectos para incorporar o sancionar la versión final del documento de requerimientos.

requerimientos solicitados por la

contraparte. Esta actividad puede durar


Requerimientos V2

3 Generar

Documentos de Análisis

Proveedor Documento de Requerimientos

V2

Una vez realizada la reunión con la contraparte se generan los documentos de análisis.

4

Se realiza una vez realizada reunión con la Contraparte.


como máximo 10 días hábiles.


4 Revisar




Generados los documentos de análisis la contraparte operativa revisa y valida si está de acuerdo.

5 o 3

Se realiza una vez generados los documentos de análisis. Esta actividad puede

durar como máximo 3 día

hábil


5 Firmar Documento Contraparte Operativa


Si valida los documentos procede a firmar la contraparte.

6

Se realiza una vez validado los

documentos. Esta actividad puede durar



firmado

6 Completar Matriz de trazabilidad

Proveedor Documentos de

Análisis firmado

Una vez que la contraparte firma el documento, el proveedor comienza a completar la matriz de trazabilidad.

7

Se realiza una vez firmado el

documento. Esta actividad puede


hábil

Matriz de

trazabilidad

7 Generar Diseño Proveedor


Documento de Requerimientos

V2

Se genera el diseño para el requerimiento solicitado.

8

Se realiza una vez que se completa la matriz de

trazabilidad. Esta actividad puede durar


Documento de

Diseño

8 Revisar Diseño Jefatura

DSIS/DAIS Documento de

Diseño Generado el diseño se revisa y valida en el caso de estar correcto.

9

Se realiza una vez generado el

diseño. Esta actividad puede


hábil

Documento de

Diseño

9 Firmar Documento

de Diseño Jefatura

DSIS/DAIS Documento de

Diseño Si valida los documentos procede a firmar documento de diseño.

10 Se realiza una

vez validado los documentos.

Documento de

Diseño validado


Act

ivid

ad


Cargo (¿Quién?)


Ir a


Aplicación

(Sistema)

Salida (Registros)



10

Solicitar ambiente de desarrollo



Diseñada la solución, el Jefe de Proyectos solicita ambiente de desarrollo al Especialista de Sistemas.

11

Se realiza una vez firmado el documento de diseño. Esta

actividad puede durar como

máximo 1 día hábil

Aranda Ticket solicitud de ambientes

11 Recepcionar


Ticket solicitud de ambientes

Recepciona solicitud de ambiente de desarrollo.

12



Aranda

12 Crear Ambiente de

Desarrollo Especialista de Sistemas

Crea ambiente de desarrollo y el Coordinador de Sistemas envía notificación del ambiente ya creado.

13

Se realiza una vez

recepcionada la solicitud.


como máximo 5 días hábiles.

Correo electrónic

o


13 Revisar ambientes Jefe(a) de Proyectos


Creado los ambientes, el Jefe de Proyectos revisa y valida los ambientes en función al acceso a aplicativos y Base de Datos. ¿Aprueba?

- Sí - No

14,15 o 12

Se realiza una vez creado el

ambiente. Esta actividad puede

durar como máximo 2 días

hábiles

Acta de


14

Implementar solución en ambiente de

desarrollo

Proveedor

Modelo de datos, Prototipos

sistema, Doc. Requerimientos, CU (depende del

proyecto)

Se implementa la solución en ambiente de desarrollo.

16

Se realiza una vez validados los ambientes.

El tiempo depende del

proyecto

Solución

implementada

15 Subproceso

Generar Casos de Prueba

Acta de


Ir al Subproceso Generar Casos de Pruebas.


16

Ejecutar Casos de Pruebas en ambiente Desarrollo

Proveedor Documento Casos de Pruebas

Se ejecuta documento de casos de pruebas documentado. ¿Pruebas ok?

- Sí - No

17 16

Se realiza una vez

implementada la solución. El

tiempo depende del tipo de proyecto


desarrollo

17 Implementar

Diseño Proveedor

Documento de Diseño validado

Validado el documento de diseño se comienza la implementación del diseño. Este puede ser con metodología ágil ir a (1) o cascada (fin).

1 o Fin

Se realiza una vez firmado el documento de diseño. Esta

actividad dependerá del

tipo del proyecto.


13. Subproceso Generar Ticket - Nivel 2 13.1 Flujo de Actividades Subproceso Generar Ticket


13.2 Descriptivo de Actividades Subproceso Generar Ticket

Act

ivid

ad


Cargo (¿Quién?)


Ir a


Aplicación

(Sistema)

Salida (Registros)

1 Completar documento


Requerimientos

Completa el documento RFC para su posterior aprobación.

2

Se realiza una vez ejecutado los casos de

pruebas. Esta actividad puede


hábiles

RFC

preliminar

2 Gestionar firmas de autorización


RFC preliminar

Una vez completado el documento, gestionar la autorización de firmas con los involucrados significativos.

3

Se realiza una vez completado el documento. Esta actividad puede durar

como máximo 2 días hábiles(se

realizan en paralelo a las actividades.

3,4,5,6,7,8,9,10,11,12,13,14,15)

RFC

preliminar

3 Firmar documento Jefe(a) de Proyectos

RFC preliminar

Firma el RFC.

4




3,4,5,6,7,8,9,10,11,12,13,14,15)

RFC

preliminar

4 Evaluar documento Contraparte Operativa

RFC preliminar

Evalúa el RFC y valida si está bien. ¿Aprueba?

- Sí - No

5 1

Se realiza una vez que es firmado el

documento por el Jefe de

Proyectos. Esta actividad puede


hábiles(se realizan en

paralelo a las actividades.

3,4,5,6,7,8,9,10,11,12,13,14,15)

RFC

preliminar

5 Firmar documento Contraparte Operativa

RFC preliminar

Firma el RFC. 6




3,4,5,6,7,8,9,10,11,12,13,14,15)

RFC validado

por Contraparte


Act

ivid

ad


Cargo (¿Quién?)


Ir a


Aplicación

(Sistema)

Salida (Registros)

6 Evaluar documento Especialista

QA

RFC validado por

Contraparte


- Sí - No

7 1


documento por la Contraparte Operativa. Esta actividad puede


hábiles(se realizan en

paralelo a las actividades.

3,4,5,6,7,8,9,10,11,12,13,14,15)

RFC validado

por Contraparte

7 Firmar documento Especialista

QA

RFC validado por

Contraparte Firma el RFC. 8




3,4,5,6,7,8,9,10,11,12,13,14,15)

RFC validado por

Coordinador de Desarrollo

8 Evaluar documento Oficial de


RFC validado por



- Sí - No

9 1


documento por el Coordinador de Desarrollo. Esta actividad puede durar



3,4,5,6,7,8,9,10,11,12,13,14,15)

RFC validado por


9 Firmar documento Oficial de


RFC validado por


Firma el RFC. 10




3,4,5,6,7,8,9,10,11,12,13,14,15)

RFC validado por

Coordinador de

Infraestructura

10

Evaluar documento Coordinador(a

) de Desarrollo

RFC validado por

Coordinador de

Infraestructura


- Sí - No

11 1


documento por el Coordinador

de Infraestructura. Esta actividad

RFC validado por

Coordinador de

Infraestructura


Act

ivid

ad


Cargo (¿Quién?)


Ir a


Aplicación

(Sistema)

Salida (Registros)

puede durar como máximo 2 días hábiles(se


3,4,5,6,7,8,9,10,11,12,13,141,15)

11 Firmar documento Coordinador(a

) de Desarrollo

RFC validado por

Coordinador de

Infraestructura

Firma el RFC. Fin




3,4,5,6,7,8,9,10,11,12,13,14,15)

RFC validado por

Coordinador de Sistemas

12 Evaluar documento Coordinador(a

) de Infraestructura

RFC validado por

Coordinador de Sistemas


- Sí - No

13 1



de Infraestructura. Esta actividad puede durar



3,4,5,6,7,8,9,10,11,12,13,14,15)

RFC validado por

Especialista QA

13 Firmar documento Coordinador(a

) de Infraestructura

RFC validado por

Especialista QA

Firma el RFC. 14




3,4,5,6,7,8,9,10,11,12,13,14,15)

RFC validado por

Especialista QA

14 Evaluar documento Coordinador(a) de Sistemas

RFC validado por

Especialista QA


- Sí - No

15 1



de Infraestructura. Esta actividad puede durar



RFC validado por Oficial de Seguridad de la Información


Act

ivid

ad


Cargo (¿Quién?)


Ir a


Aplicación

(Sistema)

Salida (Registros)

3,4,5,6,7,8,9,10,11,12,13,14,15)

15 Firmar documento Coordinador(a) de Sistemas

Firma el RFC. Fin




3,4,5,6,7,8,9,10,11,12,13,14,15)

RFC validado por Oficial de Seguridad de la Información


14. Subproceso Generar Casos de Pruebas - Nivel 2 14.1 Flujo de Actividades Subproceso Generar Casos de Pruebas

14.2 Descriptivo de Actividades Subproceso Generar Casos de Pruebas

Act

ivid

ad


Cargo (¿Quién?)


Ir a


Aplicación

(Sistema)

Salida (Registros)

1 Generar Casos de

Pruebas Proveedor

Documento casos de uso,

Prototipos, Requerimientos

Una vez que el Especialista QA valida los ambientes, el proveedor comienza a generar los casos de pruebas.

2

Se realiza una vez revisado los ambientes

creados. El tiempo depende del tamaño del proyecto

Dependiendo de

los requerimi

entos

Inventario casos de pruebas

2 Generar Plan de

Pruebas Proveedor


Prototipos, Requerimientos

Se genera la estrategia de las pruebas, los requisitos básicos y los requerimientos asociados a las pruebas.

3

Se realiza una vez generados los

casos de pruebas. Esta actividad

puede durar como máximo 10 días

hábiles (se r ealiza de forma paralela a

la actividad n°1)

Plan de Pruebas

inicial


Act

ivid

ad


Cargo (¿Quién?)


Ir a


Aplicación

(Sistema)

Salida (Registros)

3 Enviar

Documentación Proveedor


Plan de Pruebas inicial

Generados los casos y el plan de pruebas el proveedor envía la documentación al Jefe de Proyectos TI.

4

Se realiza una vez generado el plan de pruebas. Esta actividad puede

durar como máximo 1 día hábil

Correo electrónic

o

Inventario casos de pruebas Plan de Pruebas

inicial

4 Recepcionar

documentacion y enviar a QA


TI


Plan de Pruebas inicial

Recepciona la documentación enviada por el proveedor y luego envía a Especialista QA.

5 Esta actividad

puede durar como máximo 1 día hábil

Correo electrónic

o

Inventario casos de pruebas Plan de Pruebas

inicial

5 Recepcionar

documentación de proyectos

Especialista QA


Prototipos, Requerimientos, Inventario casos

de pruebas Plan de Pruebas

inicial

Recepciona la documentación de los proyectos y revisa si la documentación está completa. ¿Documentación ok?

- Sí - No

6 3

Esta actividad puede durar como


Correo electrónic

o

6 Planificar Proyectos

Especialista QA




inicial

Una vez que tiene toda la documentación comienza con la planificación de los proyectos. Para posteriormente asignar al analista.

7

Se realiza una vez que la

documentación es la correcta.. Esta actividad puede


hábiles

Project

7 Asignar tareas a

Analistas Especialista

QA




inicial

Realizada la planificación de proyectos, asigna las tareas a los analistas correspondientes.

8

Se realiza una vez que se planifican

los proyectos. Esta actividad puede


hábiles

Correo electrónic

o

Documento casos de

uso, Prototipos, Requerimie

ntos, Inventario casos de pruebas Plan de Pruebas

inicial

8 Recepcionar

documentación Analista QA

(Externo)




inicial

Recepciona la documentación de las tareas asignadas.

9



Correo electrónic

o

Correo de aceptación o rechazo

9 Generar Casos de

Pruebas Analista QA

(Externo)




inicial

Con la documentación comienza a generar los casos de pruebas asociados al requerimiento.

10

Se realiza una vez recepcionada la

información. Esta actividad puede


hábiles (dependerá del tipo de

Testlink


modificados


Act

ivid

ad


Cargo (¿Quién?)


Ir a


Aplicación

(Sistema)

Salida (Registros)

proyecto si es grande o pequeño)

10 Enviar a JP

inventario de casos pruebas

Analista QA (Externo)

Inventario casos de pruebas modificados

Una vez que genera los casos de pruebas, envía al Jefe de Proyectos TI para que los apruebe.

11

Se realiza una vez generado los

casos de prueba por parte del

Analista QA. Esta actividad puede

durar como máximo 1 día hábil

Correo electrónic

o

Correo de aceptación o rechazo

11 Revisar casos de

pruebas con proveedor


Inventario casos de pruebas con observaciones

Recepciona los casos de pruebas y revisa con el proveedor si es necesario para ver si hay observaciones. ¿Hay observaciones?

- Sí - No

12 13

Se realiza una vez que el Analista QA envía el inventario.


máximo 7 días hábiles (que puede

variar según el tamaño del proyecto)

Correo electrónic

o

Correo a Especialista

QA y Analista QA

12 Corregir casos de

pruebas Analista QA

(Externo)


En el caso de haber observaciones en los casos de pruebas, el Analista QA deberá corregir los casos de pruebas y enviar nuevamente.

9

Se realiza en el caso de existir observaciones. Esta actividad

puede durar como máximo 10 días

hábiles (que puede variar según el

tamaño del proyecto)

Testlink


modificados

13 Enviar correo de aceptación a QA


TI


Si los casos de pruebas están correctos, envía correo de aceptación a Especialista QA.

Fin

Se realiza en el caso de no haber observaciones. Esta actividad

puede durar como máximo 1 día hábil

Correo electrónic

o

14

Priorizar Casos de Prueba con Contraparte Operativa


TI




inicial

Si la documentación no está conforme, el Jefe de Proyectos debe priorizar los casos de prueba con contraparte operativa para que vuelva a enviar la documentación.

3

Se realiza en el caso de existir

observaciones de la documentación.


máximo 7 días hábiles (que puede

variar según el tamaño del proyecto)

Correo electrónic

o


15. Subproceso Aplicar Ciclo de Pruebas - Nivel 2 15.1 Flujo de Actividades Subproceso Aplicar Ciclo de Pruebas

15.2 Descriptivo de Actividades Subproceso Aplicar Ciclo de Pruebas

Act

ivid

ad


Cargo (¿Quién?)


Ir a



Salida (Registros)

1 Revisar

Planificación Especialista

QA Datos de Usuarios

Una vez que recibe correo de aceptación de los casos de prueba, revisa planificación para luego asignar las tareas a los Analistas QA.

2

Se realiza una vez validado informe de

vulnerabilidades. Esta actividad


1 día hábil, periódico

Project Datos de Usuarios


Act

ivid

ad


Cargo (¿Quién?)


Ir a



Salida (Registros)

2 Asignar tareas a

Analistas Especialista

QA Datos de Usuarios

Una vez que se planifican los proyectos que se revisarán por QA, se valida si el proyecto no es una regresión de casos (por efectos de incidencias) y si es un proyecto nuevo se le asigna el proyecto al analista. ¿Es primer ciclo?

- Sí - No

3 10

Se realiza una vez revisada

la planificación. Esta actividad puede durar

como máximo 1 día hábil, periódico

Correo electrónico

-Documento de Requerimientos -Documento de

Diseño -Casos de Uso

-Casos de Prueba

-Prototipo -Datos de Usuarios

3 Revisar

Documentación solicitada

Analista QA (externo)

-Documento de

Requerimientos

-Documento de Diseño -Casos de

Uso -Casos de

Prueba -Prototipo -Datos de Usuarios

Al ser un proyecto nuevo o primer ciclo, se revisa la documentación del proyecto y se tienen las reuniones de contexto con los involucrados. Si la documentación está OK se procede a ejecutar las pruebas, si no está Ok la documentación, se envía correo al JP. ¿OK?

- Sí - No

4 15

Se realiza una vez asignadas

las tareas. Esta actividad puede durar

como máximo 3 a 5 días hábiles,

periódico

Correo electrónico

Correo de aceptación o

rechazo

4 Ejecutar la pruebas Analista QA

(externo) Datos de usuarios

En el caso que la documentación esté correcta, el Analista QA ejecutará un ciclo de pruebas funcionales. Si al terminar el ciclo de pruebas éste presenta incidencia y por lo tanto no son satisfactorias se analiza la severidad de los defectos. ¿Pruebas satisfactorias?

- Sí - No

5 10

Se realiza una vez revisada

la documentación solicitada.



(proyecto pequeño) 20 días hábiles

(proyecto grande) Para proyectos que

tienen un desarrollo de

un año se debe evaluar el tiempo de

pruebas.

Dependiendo del tipo

de requerimien

to

-Informe de Avance

-Documento de evidencia de

pruebas

5 Crear documento

cierre pruebas Analista QA

(externo)

-Informe de Avance

-Documento de evidencia de pruebas

Si las pruebas ejecutadas son satisfactorias, se crea el documento cierre de pruebas.

6

Se realiza una vez

ejecutadas las pruebas. Esta


como máximo 2 días hábiles,

periódico

Informe cierre de

pruebas


Act

ivid

ad


Cargo (¿Quién?)


Ir a



Salida (Registros)

6

Enviar Documento de Cierre de Pruebas a

Especialista QA



Creado el documento se envía por correo a Especialista QA.

7

Se realiza una vez creado el documento de

cierre de pruebas.

Correo electrónico


7

Enviar Documento de Cierre de Pruebas a

Especialista JP

Especialista QA


Recepcionado el documento se envía por correo a Jefe de Proyectos TI.

8

Se realiza una vez creado el documento de

cierre de pruebas

Correo electrónico


8

Evaluar respuesta de desarrollo

según severidad de Defectos



En el caso de no ser primer ciclo se realiza revisión de los defectos encontrados (ciclos de pruebas anteriores)

9

Se realiza en el caso de no ser de primer

ciclo. Esta actividad

puede durar como máximo 5 días hábiles

Mantis Planilla de Incidencias corregidas.

9 Ejecutar pruebas

de Regresión Analista QA

(externo) Planilla de incidencias

Se ejecutan las pruebas de regresión. ¿Pruebas ok?

- Sí - No

5 10

Se realiza una vez evaluada la respuesta

de desarrollo. Esta actividad puede durar


(dependiendo del tamaño

del proyecto)

Mantis Planilla de incidencias

cerrada

10 Analizar severidad

defectos encontrados



Si las pruebas de regresión y las de primer ciclo no han sido satisfactorias, se analiza la severidad de defectos encontrados.

11 Lo que dura la ejecución de las pruebas

Mantis Planilla de incidencias

11 Realizar control de

Incidencias Analista QA

(externo) Planilla de incidencias

Realiza ingreso de incidentes y cambios de estados en la herramienta Mantis.

12

Se realiza una vez analizada la severidad de defectos

encontrados. Esta actividad puede durar


Mantis Planilla

Asignación de Incidencias

12 Enviar a Proveedor Analista QA

(externo)

Planilla Asignación de

Incidencias

Realizado el control de incidencias, se envían al proveedor.

13

Se realiza una vez realizado el control de incidencias.

Correo electrónico

Correo con Planilla


13 Informar

Incidencias a Especialista QA


Correo con Planilla


Una vez que informa al proveedor las incidencias, envía correo electrónico informando a Especialista QA.

14


control de incidencias al

proveedor.

Correo electrónico

Correo con Planilla


14 Informar

Incidencias a Jefe de Proyectos

Especialista QA

Correo con Planilla


Una vez que informa al proveedor las incidencias, envía correo electrónico informando a Jefe de Proyectos

Fin


control de incidencias al

Correo electrónico

Correo con Planilla



Act

ivid

ad


Cargo (¿Quién?)


Ir a



Salida (Registros)

proveedor.

15 Informar por correo a Especialista QA


Si la documentación solicitada para el primer ciclo no está bien se debe informar al Especialista QA.

16

Se realiza una vez que es revisada la

documentación cuando es

de primer ciclo y esta no es correcta.

Correo electrónico

16 Informar por correo

a Jefe de Proyectos

Especialista QA

Si la documentación solicitada para el primer ciclo no está bien se debe informar al Jefe de Proyectos.

Fin

Se realiza una vez que es revisada la

documentación cuando es

de primer ciclo y esta no es correcta.

Correo electrónico

16. Proceso Gestionar Nuevos Desarrollos Internos 16.1 Flujo de Actividades Proceso Gestionar Nuevos Desarrollos Internos


16.2 Descriptivo de Actividades Proceso Gestionar Nuevos Desarrollos Internos

Act

ivid

ad


Cargo (¿Quién?)


Ir a



Salida (Registros)

1 Generar

requerimiento Contraparte Operativa

Solicita nuevos Proyectos y/o servicios que tengan relación a sus propios Departamentos y/o solicitudes necesarias.

2


necesitar un nuevo

requerimiento.

Memorándum

2 Recepcionar


DSIS/DAIS Memorándum

Recepciona el requerimiento por parte de algún Jefe de División, Jefe de Departamento o Unidad Particular.

3



Memorándum

3 Evaluar

requerimiento Jefatura

DSIS/DAIS Memorándum

Una vez que recepciona el requerimiento, revisa el requerimiento y analiza si existen recursos para asignar el requerimiento al Jefe de Proyectos correspondiente. ¿Existen Recursos?

- Sí No

4 o 6




Correo electrónico

Correo electrónico con asignación del requerimiento

4 Revisar

Presupuesto


Una vez que recepciona el requerimiento por parte del la Jefatura Dpto. Sistemas de la revisa el requerimiento y analiza si existe presupuesto para asignar el requerimiento al Jefe de Proyectos correspondiente. ¿Existe Presupuesto?

- Si - No

5 o 6




Correo electrónico

Correo electrónico con asignación del requerimiento

5 Informar Falta

de Presupuesto


Se le informa a la Contraparte Operativa que no existe presupuesto para ser asignado al requerimiento.

Fin


Correo electrónico

Correo

6 Asignar


DSIS/DAIS

Existiendo presupuesto asigna requerimiento a Jefe de Proyectos.

7


Correo electrónico

Correo

7

Realizar levantamiento

de requerimiento inicial


Ir al Subproceso Realizar Levantamiento de Requerimiento Inicial.

8

Se realiza inmediatamente asignado el requerimiento. Se indica en Subproceso

Reunión kick off

agendada

8

Entregar Documento de



Minuta reunión;

kickoff, Oferta Técnica

Proveedor analiza y entrega los requerimientos solicitados al Jefe de Proyectos para su validación.

9

Se realiza inmediatamente realizado el levantamiento

del requerimiento. Depende del

tipo de

Documento de requerimientos,

matriz de trazabilidad


Act

ivid

ad


Cargo (¿Quién?)


Ir a



Salida (Registros)

proyecto

9

Revisar Documento de


(9)


Acta de aprobación

del requerimiento

El Jefe de Proyectos revisa los requerimientos entregados por el proveedor. ¿Aprueba?

- Sí - No

8 o 10

Se realiza una vez entregado el documento de Análisis de Requerimient

o. Esta actividad


2 a 10 días hábiles

Acta de

aprobación del requerimiento

10 Diseñar solución Jefe(a) de Proyectos

Documento Requerimientos, Matriz de trazabilidad

Si la contraparte operativa aprueba el requerimiento, el proveedor comienza a diseñar la solución. En el caso de ser un Requerimiento de Sistemas

11

Se realiza inmediatamente aprobado el requerimiento

por la Contraparte. Depende tipo del proyecto.

Modelo de datos, Prototipos

sistema, Casos de Uso, Matriz de trazabilidad (dependiendo

tipo de proyecto)

11 Realizar

Revisión de entregables

Especialista QA

Casos de Uso ,

Requerimientos, Matriz de trazabilidad

Especialista QA revisa si los requerimientos están de acuerdo a los casos de uso y valida la matriz de trazabilidad.

12

Se realiza una vez diseñada la solución. El

tiempo depende del

tipo del proyecto



12 Solicitar

ambientes Jefe(a) de Proyectos

Diseñada la solución, el Jefe de Proyectos solicita los ambientes al Especialista de Sistemas.

13

Se realiza una vez realizada la revisión de ambientes.



Aranda ticket

13 Recepcionar


Recepciona solicitud de ambientes 14,15,16,17



Aranda

14 Crear ambiente de desarrollo (


Crea ambiente de desarrollo y el envía notificación del ambiente ya creado.

18

Se realiza una vez

recepcionada la solicitud de



act 14, 15, 16)

Correo electrónico


15 Crear ambiente

QA Especialista de Sistemas

Crea ambiente QA y envía notificación del ambiente ya creado.

18

Se realiza una vez


Correo electrónico



Act

ivid

ad


Cargo (¿Quién?)


Ir a



Salida (Registros)


como máximo 5 días hábiles (en paralelo actividades 14, 15, 16)

16 Crear ambiente

producción Especialista de Sistemas

Crea ambiente de producción y envía notificación del ambiente ya creado.

18

Se realiza una vez




actividades14, 15, 16)

Correo electrónico


17 Crear SVN Especialista de Sistemas

Crea ambiente SVN y envía notificación del ambiente ya creado.

18

Se realiza una vez

recepcionada la solicitud de ambientes. Se

realiza una vez


ambientes.

18 Validar

ambientes Especialista

QA

Notificación de ambiente

creado.

Creado los ambientes, el Especialista QA en conjunto con el Jefe Proyectos valida los ambientes en función al acceso a aplicativos y BD ¿Aprueba?

- Sí - No

19 o 14,15,16,17




Acta de


19

Implementar solución en ambiente de desarrollo


Modelo de datos,

Prototipos sistema, Doc. Requerimient

os, CU (depende del

proyecto)

Se implementa la solución en ambiente de desarrollo.

20 o 21


El tiempo dependerá del

tipo de proyecto.

Solución

implementada

20 Generar Casos

de Prueba Jefe(a) de Proyectos

Acta de aprobación de

ambientes.

Ir al Subproceso Generar Casos de Pruebas.

24


El tiempo dependerá del

tipo de proyecto.

21

Ejecutar Casos de Pruebas en

ambiente Desarrollo


Documento Casos de Pruebas

Se ejecuta documento de casos de pruebas documentado. ¿Pruebas ok?

- Sí

21 o 22

Se realiza una vez

implementado el ambiente



Act

ivid

ad


Cargo (¿Quién?)


Ir a



Salida (Registros)

- No de desarrollo. El tiempo

dependerá del tipo de

proyecto.

desarrollo

22 Instalar

aplicativo en ambiente QA


El especialista de sistemas realiza el paso de todos los fuentes, componentes tanto de Aplicación como Base de Datos a este nuevo ambiente.

23


el RFC. El tiempo

dependerá del tipo de

proyecto

Correo electrónico

23

Realizar pruebas funcionales en ambiente QA

MDS



desarrollo

Implementada la solución se realizan las pruebas con funcionalidades más críticas en ambiente QA MDS. .(Esta designación de casos las realiza el Especialista QA del MDS para el proveedor) ¿Pruebas ok?

- Sí - No

23 o 24

Se realiza una vez instalado el aplicativo en Ambiente

QA. Esta actividad

puede durar como máximo 2 días hábiles

Informe de Evidencia de los

casos de pruebas en

ambiente QA MDS, Informe de

resultados de Ciclos de pruebas

24 Solicitar

evaluación de vulnerabilidades



Solicita evaluación de vulnerabilidades a través de ticket a Especialista de Sistemas. ¿Es intranet?

- Sí - No

25 o 33

Se realiza una vez que las

pruebas funcionales

están correctas.



Aranda Ticket de solicitud

25 Ejecutar

vulnerabilidades

Especialista de

Infraestructura


Si las pruebas en ambiente QA están correctas, el Especialista evalúa las vulnerabilidades.

26

Se realiza en el caso que

sea por intranet. Esta



26 Generar Informe

de vulnerabilidades

Especialista de

Infraestructura

Genera informe de vulnerabilidades y lo envía al Jefe de Proyecto.

27

Se realiza una vez

ejecutadas las vulnerabilidad

es. Esta actividad


1 día hábil

Informe de

vulnerabilidades

27 Evaluar Informe Jefe(a) de Proyectos


es

Recepcionado el informe de vulnerabilidades, junto con el proveedor evalúa los resultados del informe. ¿OK?

- Sí - No

28 o 29

Se realiza una vez generado el informe de vulnerabilidad

es. Esta actividad


Minuta de Reunión

(vulnerabilidades a resolver)


Act

ivid

ad


Cargo (¿Quién?)


Ir a



Salida (Registros)

3 días hábiles

28 Resolver

vulnerabilidades 3,4 y5


Minuta de Reunión

(vulnerabilidades a

resolver)

Se le solicita al proveedor que resuelva las vulnerabilidades indicadas en el informe.

23

Se realiza una vez que se

hayan encontrado

vulnerabilidades. Depende

el tipo de cambio e

impacto en el sistema.

Entregable de la

solución.

29

Enviar Informe de

Vulnerabilidad a Seguridad (30)



Si las pruebas están correctas, se envía el informe de vulnerabilidad al Oficial de Seguridad de la Información para que valide.

30



Informe de

vulnerabilidad

30 Recepcionar

Informe

Oficial Seguridad de la Información


Recepciona Informe de Vulnerabilidad para su revisión.

31 Correo

electrónico Informe de

vulnerabilidad

31 Evaluar Informe Oficial



Revisa y valida informe de vulnerabilidad. ¿Aprueba?

- Sí - No

27 o 32

Se realiza una vez

recepcionado el informe.



Correo electrónico


32 Recepcionar




Si el Oficial de Seguridad aprueba el proyecto, el Jefe de Proyectos recepciona notificación de aceptación.

33 Correo

electrónico

33 Subproceso

Aplicar ciclo de pruebas

Especialista QA

Ir al Subproceso Aplicar Ciclo de pruebas. ¿Pruebas ok?

- Sí - No

34 o 35

Se indica en Subproceso

34 Enviar

incidencias a JP Especialista

QA

Si las pruebas no están correctas, se deben enviar las incidencias al proveedor para su evaluación. Si es necesario se agenda una reunión para discutir las criticidades de éstas.

23

Se realiza una vez que le

ciclo de pruebas está

correcto.

Correo electrónico

Informe Resultado Incidencias

35 Firmar Actas de Validación PAU


Documento Casos de pruebas

Si las pruebas de aceptación de usuarios están correctas, la contraparte debe certificar las pruebas de usuario mediante un Acta de Validación PAU

36 Depende del

tipo del proyecto

Correo electrónico

Acta de validación de

PAU.

36 Subproceso

Realizar Paso a Producción


RFC, Manuales de instalación, operación,

explotación.

Si las pruebas están correctas ir al Proceso Realizar Paso a Producción.


Sistema en producción


17. Subproceso Realizar Paso a Producción 17.1 Flujo de Actividades Subproceso Realizar Paso a Producción


17.2 Descriptivo de Actividades Subproceso Realizar Paso a Producción

Act

ivid

ad


Cargo (¿Quién?)


Ir a



Salida (Registros)

1

Solicitar RFC de

Paso a Producción


Solicita RFC a proveedor para realizar el paso a producción. ¿Existe proveedor?

- Sí - No

5 o 1

Se realiza una vez firmadas las actas de aceptación

por el usuario. Esta actividad puede durar


Correo

electrónico

2 Generar RFC Proveedor Correo

electrónico El proveedor genera el documento RFC.

3

Se realiza una vez


RFC. Los tiempos se indica en

Subproceso

RFC

3 Revisar RFC Jefe(a) de Proyectos

RFC

Una vez generado el RFC por parte del proveedor, el Jefe de Proyectos debe revisar la ejecución del documento. ¿RFC ok?

- Sí - No

4 o 2

Se realiza una vez generado el RFC. Esta



RFC impreso

4 Generar RFC Jefe(a) de Proyectos

El Jefe de Proyectos genera el documento RFC.

5 RFC

5 Gestionar Firmas Jefe(a) de Proyectos

RFC impreso Una vez que valida el RFC se debe gestionar las firmas con los involucrados necesarios.

6

Se realiza una vez validado el RFC. Esta



RFC firmado

6 Ejecutar Mesa de

Cambio

Coordinador(a) de

Sistemas RFC firmado

El Coordinador de Sistemas debe convocar a una reunión a todos los Jefes de proyectos para revisar en conjunto toda la documentación necesaria para los nuevos desarrollos a ejecutar y los cambios que impliquen estos.

7

Se realiza una vez validado el RFC. Esta



7 Generar Ticket

para Paso a Producción


RFC firmado

Gestionadas las firmas se debe generar el ticket para paso a producción al Encargado de Sistemas y además asigna el número de ticket al documento RFC.

8

Se realiza una vez firmado el

RFC. Esta actividad


1 día hábil

Aranda Ticket

8 Revisar Ticket Coordinado

r(a) de Sistemas

Ticket Revisa ticket con solicitud de Paso a producción. ¿Valida?

9 o 1


el ticket. Aranda Ticket


Act

ivid

ad


Cargo (¿Quién?)


Ir a



Salida (Registros)

- Sí - No



9 Agendar Paso a

Producción

Coordinador(a) de

Sistemas

Ticket validado

Si valida ticket agenda el paso a producción.

10

Se realiza una vez validado el ticket. Esta



10 Ejecutar RFC Especialista

de Sistemas

RFC

Se ejecuta el RFC. ¿Resultado exitoso?

- Sí - No

11 o 14

Se realiza una vez agendado

el paso a producción.



RFC

11 Revisar

requerimiento Contraparte RFC

Ejecutado el RFC, la contraparte debe revisarlo. ¿Valida?

- Sí - No

18 o 12

Se realiza una vez ejecutado el RFC. Esta



RFC validado o rechazado por Contraparte

12 Informar rechazo Contraparte RFC

rechazado por Contraparte

Si la Contraparte no valida la ejecución del RFC debe informar rechazo al Coordinador de Sistemas.

13

Se realiza una vez que ha

sido rechazado el

RFC. Esta actividad


1 día hábil

Correo electrónico

Correo electrónico

13 Evaluar rechazo Coordinado

r(a) de Sistemas

Correo electrónico

Evalúa el rechazo informado por la Contraparte y ve si es necesario ejecutar nuevamente el RFC. ¿Ejecutar nuevamente RFC?

- Sí - No

8 o 1


sido informado el

rechazo. Esta actividad


1 día hábil

Correo electrónico

Correo electrónico

14

Analizar vuelta atrás con

contraparte

Especialista de

Sistemas

Correo electrónico

Se analiza con la contraparte si se realiza la vuelta atrás. ¿Acepta vuelta atrás ?

- Sí - No

10 o 1


sido rechazada la ejecución del

RFC. Esta actividad


1 día hábil


Act

ivid

ad


Cargo (¿Quién?)


Ir a



Salida (Registros)

15 Realizar vuelta

atrás

Especialista de

Sistemas

Correo electrónico

Si la contraparte acepta, se realiza la vuelta atrás.

16

Se realiza una vez que la contraparte

acepta realizar la

vuelta atrás. Esta actividad puede durar


Correo

electrónico

16 Validar con Contraparte

Contraparte Correo

electrónico

Valida con la contraparte la vuelta atrás. ¿Valida?

- Sí - No

17 o 15

Se realiza una vez realizada

la vuelta atrás. Esta actividad


1 día hábil

Correo

electrónico

17 Finalizar Ejecución Paso a producción

Especialista de

Sistemas

Finaliza la ejecución del Paso a Producción.

18

Se realiza una vez validado

por la contraparte.



Aranda Cambiar estado

en Aranda

18 Cerrar Paso a

Producción Jefe(a) de Proyectos

Es responsabilidad del jefe de Proyectos realizar el cierre de Paso a Producción.

Fin

Se realiza una vez finalizado la ejecución del Paso a

Producción. Esta actividad puede durar



18. Indicadores Los siguientes indicadores corresponden a mediciones de desempeño del proyecto.

N° Actividad Objetivo Indicador Fórmula de

Cálculo

Frecuencia de

Medición Responsable Meta Nota

Producto No

Conforme

1 Aplica a todo el

proceso

Detectar si el presupuesto otorgado para un proyecto se utilizó en su totalidad

% de presupuesto gastado por

proyecto

0 % - 100 %

Presupuesto gastado

versus Presupuesto asignado

Anual

Contraparte Operativa/Dep

to TI y Procesos

Por definir

Dependerá de donde se asigna el presupuesto.

Falta de presupuest

o para terminar el proyecto.

El

presupuesto otorgado

no se utilizó en

su totalidad.

2 Aplica a todo el

proceso

Realizar el Proceso Gestionar Nuevos

Desarrollos en el tiempo establecido en carta

Gantt.

% cumplimiento

de tiempo definido en carta Gantt.

Duración en días

Anual Depto. TI y Procesos

Por definir

Dependerá del tipo de requerimiento y el Control de Cambios.

3 Aplica a todo el

proceso

Obtener el número total de requerimientos

resueltos versus los solicitados.

Porcentaje de requerimiento

s resueltos

0 % - 100 % Cantidad de

de requerimientos, versus la cantidad

total de requerimien

tos resueltos

en el periodo


Por definir

Dependerá del tipo de requerimiento y del presupuesto.

4

Actividades involucradas; 11, 19, 20 ,21, 22 y

26.

El objetivo es medir el nivel de satisfacción de los Jefes de Proyectos

que solicitan un requerimiento al

proveedor.

% nivel satisfacción proveedor

Cálculo SFi: Sumatoria

de las respuestas

“muy bueno” y

“Bueno”/Total de

respuestas (“muy

bueno”, “bueno”, “regular”, “malo”)


Por definir

Nota: No se considera la respuesta “no aplica”

Que el porcentaje de satisfacción de las personas que contestaron bueno o muy bueno sea menos al 70%


N° Actividad Objetivo Indicador Fórmula de

Cálculo

Frecuencia de

Medición Responsable Meta Nota

Producto No

Conforme

5 Aplica a todo el

proceso

Capacitar a la contraparte operativa e

involucrados significativos del proceso

Capacitación y difusión a la contraparte operativa e

involucrados significativos

Entero >=0 Anual

Depto. TI y Procesos

Por definir

19. Anexos Anexo 1: Formulario de paso a producción.

HOJA RESUMEN RFC PRD

BREVE DESCRIPCIÓN DE RFC

AUTORIZADORES TRASPASO

Rol Nombre Fecha Firma


Jefe de Proyecto SIS

Encargado de QA

Oficial Seguridad de la Información

Coordinador Depto. Desarrollo


Coordinador Unidad Infraestructura

Coordinador Unidad Sistemas

DOCUMENTO RFC

Sistema

Proyecto PMO

Documentos Adicionales

Versión Actual Aplicación Nueva Versión

Plataforma Origen

Servidor Web (nombre)

Servidor Aplicaciones (nombre)

Servidor BD (nombre)

Esquema Base de Datos

Framework(s)

Otros componentes SW

Plataforma Destino





Framework(s)


Marque con un “X”

Categoría de Cambio1

Normal Urgente Estándar

Tipo de Cambio Instalación Actualización Parche de Seguridad

1 Todos los Pasos a Producción son de lunes a jueves, excepto vísperas de feriado


Justificar Urgencia

Nombre Completo y Firma Jefe División Contraparte Operativa (Solo Cambios Urgentes)

INSTRUCTIVO RFC 1.- PLAN DE VUELTA ATRÁS (Tareas y/o actividades – incluye respaldos previos requeridos) 2.- PLAN DE EJECUCIÓN (detalle de instrucciones técnicas a realizar paso a paso)

3.- VALIDACIÓN DE EJECUCIÓN (validación mínima de traspaso)

4.- ESPECIALISTA DE EJECUCIÓN (a completar por especialistas responsables)

Rol Nombre Fecha

Inicio

Fecha

Término

Firma


HOJA RESUMEN RFC QA

BREVE DESCRIPCIÓN DE RFC

AUTORIZADORES TRASPASO

Rol Nombre Fecha Firma

Jefe de

Proyecto SIS


DOCUMENTO RFC

Sistema

Proyecto PMO

Documentos Adicionales

Versión Actual Aplicación Nueva Versión

Plataforma Destino





Framework(s)


Marque con un “X”

Categoría de Cambio2

Normal Urgente Estándar

Tipo de Cambio Instalación Actualización Parche de Seguridad

Justificar Urgencia

Nombre Completo y Firma Jefe División Contraparte Operativa (Solo Cambios Urgentes)

2 Los traspasos a Ambiente QA son de lunes a viernes


INSTRUCTIVO RFC 1.- PLAN DE VUELTA ATRÁS (Tareas y/o actividades – incluye respaldos previos requeridos) 2.- PLAN DE EJECUCIÓN (detalle de instrucciones técnicas a realizar paso a paso)

3.- VALIDACIÓN DE EJECUCIÓN (validación mínima de traspaso)

4.- ESPECIALISTA DE EJECUCIÓN (a completar por especialistas responsables)

Rol Nombre Fecha

Inicio

Fecha

Término

Firma


Anexo 2: Memorándum.

Santiago,

MAT: Solicita compra XXX y Gestión de CDP.

REF: No tiene.

ADJ.: No tiene.

A: CRISTIAN CORTÉS CORREA

JEFE DIVISIÓN INFORMACIÓN SOCIAL

DE: XXX

JEFE DIVISIÓN XXX

Junto con saludar, por medio del presente, tengo a bien solicitar a usted pueda gestionar la compra del

Proyecto XXX.

Para este proyecto se dispone de un presupuesto de XXX U.F, cuyo costo debe ser imputado al código

XXX, estructura presupuestaria del Subtítulo 22.

Por otro lado y bajo el contexto del Proyecto citado en el presente Memorándum, solicitamos además,

gestionar CDP por un monto de XXXU.F.

Centro de costo: XXX

Ítem presupuestario: XXX

Subtítulo XXX

Sin otro particular, agradeciendo de antemano vuestra gestión, se despide atentamente,

NOMBRE JEFE DIVISIÓN

C.C.

División de XXX

Departamento de Sistemas de Información Social.

Departamento de TI y Procesos.

Unidad XXX.

Anexo 3: Ruta de Documentaciones. K:\Proyectos_2014\00-PMO\03-Plantillas\03-Entregables adicionales TI y P Desarrollo\3.2 CM-EN100-

1000-MANTENCIÓN, CASCADA O RUP\03-Ejecución\Plantillas TIP Desarrollo Proyecto Mantención

Memorándum N°

proceso gestionar nuevos desarrollos

Documents