Requ Fun PDF

CIFI-INFORMATICA – PROCURADURIA GENERAL DE LA NACION
REQUERIMIENTOS DETALLADOS
SISTEMA DE INFORMACIÓN MISIONAL
PARA LA PGN (Funcionales)
Histórico de Revisiones
Fecha Versión Descripción Autor

05-05-05 1.0 Versión Inicial C.García
22-06-05 2.0 Revisión documento de C.Díaz, D.Rubiano,
acuerdo a observaciones H.Velásquez
usuarios PGN.
02-08-05 3.0 Versión final, de acuerdo a C. García
versión 3 de Casos de Uso.
Requerimientos Detallados -Funcionales- (Documento Final) Pág. 2

TABLA DE CONTENIDO
CAPÍTULO 1 - INTRODUCCIÓN....................................................................................................... 5
CAPÍTULO 2 - OBJETIVOS Y ALCANCE ..................................................................................... 7
CAPÍTULO 3 – REQUERIMIENTOS FUNCIONALES................................................................. 10
CAPÍTULO 4 – ESPECIFICACIONES SUPLEMENTARIAS...................................................... 13

TABLA DE ANEXOS
ANEXO 1 - CASOS DE USO SIC..……………………………………………...A1-1

.
ANEXO 2 - CASOS DE USO SIAM ……………………………….…………....A2-1
ANEXO 3 - CASOS DE USO SIMIP ..…………………………………………..A3-1
ANEXO 4 - CASOS DE USO SIREL …………………………………….……..A4-1
ANEXO 5 – DIAGRAMAS DE SECUENCIA…………………………………..A5-1
ANEXO – GLOSARIO…………………………………………………………….A-1

CAPÍTULO 1 -INTRODUCCIÓN
El contrato 066 de 2004 suscrito entre la Procuraduría General de la Nación y la

Universidad de los Andes, incluye la Formulación de la arquitectura de sistemas de
información para las áreas misionales de la entidad y el Detalle de requerimientos del
sistema de información misional.
Este documento de “Requerimientos detallados del Sistema de Información Misional
para la PGN” corresponde al entregable de la Etapa 7 y contiene la descripción de los
requerimientos funcionales y las especificaciones suplementarias de los nuevos
Subsistemas de la Procuraduría General de la Nación para sus áreas misionales:
SIC: Subsistema de Información a la Ciudadanía
SIAM: Subsistema de Apoyo a la Misión
SIMIP: Subsistema de Procesos de la PGN
SIREL: Subsistema de Legislación y Relatoría
En el capítulo 2, se presentan los objetivos y alcance del documento. En el capítulo 3,

se enumeran los requerimientos funcionales y en el 4, se describen de manera general
las especificaciones suplementarias, para los cuatro Susbsistemas mencionados
anteriormente.
En los Anexos 1 a 4 del documento se presentan las especificaciones generales de los

casos de uso de los Subsistemas del Sistema de Información Misional, de acuerdo con
el alcance del contrato suscrito entre la Universidad y la PGN.
Para el Subsistema de Información de Registro de Sanciones e Inhabilidades – SIRI,
existente actualmente en producción en la Procuraduría y el cual continuará operando
de forma integrada con los cuatros Subsistemas de Información Misionales
enunciados anteriormente, se entregará un documento adicional a este documento,

donde se incluirán los casos de uso de este Subsistema. Los nuevos requerimientos de
SIRI serán objeto de una contratación independiente de los Términos de Referencia
del SIM, por parte de la Procuraduría.
Para lograr un mayor entendimiento del documento, la lectura del mismo debe ser
complementada con los documentos “Requerimientos de Alto Nivel de los Sistemas
de Información”, “Mapa del Sistema de Información” y “Arquitectura Seleccionada”
que forman parte de los entregables de las etapas 4, 5 y 6, respectivamente del
contrato Uniandes-PGN.

CAPÍTULO 2- OBJETIVOS Y
ALCANCE
En este capítulo se presentan los objetivos y el alcance de los requerimientos

detallados del Sistema de Información Misional de la PGN, correspondientes a la
Etapa 7, donde se refinan los requerimientos funcionales y las especificaciones
suplementarias de los nuevos desarrollos de la Procuraduría General de la Nación.
En la Etapa 7 se hace el ajuste y refinamiento de los requerimientos identificados en

la etapa 4, bajo la perspectiva de la alternativa seleccionada en la etapa 6.
En la Etapa 4 del proyecto se identificaron los requerimientos de alto nivel

(funcionales y no funcionales) del Sistema de Información Misional que apoyará las
áreas misionales de la Procuraduría. Para esto, los procesos y las necesidades
misionales se expresaron identificando los casos de uso del sistema, con una breve
descripción de cada uno de ellos.
En la Etapa 6 se consolidó la propuesta para la Arquitectura de los Sistemas de
Información para la Procuraduría General de la Nación.
De acuerdo con la metodología utilizada en el proyecto, en el siguiente capítulo
(capítulo 3) se presenta la lista de los casos de uso identificados para cada uno de los
subsistemas del Sistema de Información Misional definido para la PGN, incluyendo
los casos de uso de las interfaces entre los subsistemas y con los otros sistemas no
misionales de la Procuraduría, principalmente con SIAF.
La descripción de cada uno de los casos de uso se encuentra en los Anexos 1 a 4 de
este documento, de la siguiente manera:
ANEXO 1- CASOS DE USO SIC: Subsistema de Información a la

Ciudadanía
ANEXO 2- CASOS DE USO SIAM Subsistema de Apoyo a la Misión
ANEXO 3- CASOS DE USO SIMIP: Subsistema de Procesos de la PGN

ANEXO 4- CASOS DE USO SIREL: Subsistema de Legislación y Relatoría
El contenido de la descripción de los casos de uso que se encuentran en los Anexos 1

a 4, es el siguiente:
1. Descripción Breve
2. Actores Involucrados
3. Entradas
4. Salidas
5. Flujo de Eventos
5.1 Flujo Básico
5.2 Flujos Alternativos
6. Precondiciones
7. Post Condiciones
8. Asuntos Pendientes
Los términos utilizados para la descripción de los casos de uso están explicados en el
anexo de Glosario.
Es importante mencionar, que la lista y los casos de uso presentados en los Anexos 1
a 4 puede aumentar a medida que el proveedor seleccionado por la PGN para la
construcción del SIM detalle más los requerimientos funcionales del sistema. De
igual manera, la especificación de los casos de uso también deberá ser ampliada y
detallada por el proveedor seleccionado.
Adicionalmente, como complemento a los casos de uso, en el Anexo 5 se presentan

dos Diagramas de Secuencia para dos casos de uso de SIMIP:
1) “Asignar Servidor/Equipo de Trabajo a Solicitud/Caso” y
2) “Definir Ruta y Plan de Actividades”
En el capítulo 4 de este documento se encuentra la enumeración de las

especificaciones suplementarias identificadas para el Sistema de Información
Misional de la Procuraduría.

Como producto de la etapa 7 del proyecto también se entregan dos documentos

complementarios a este documento los cuales hacen parte de los Términos de
Referencia y tienen el siguiente contenido:
1) “Requerimientos No Funcionales del Sistema de Información Misional para la

PGN”, los cuales deberán ser refinados por el proveedor que resulte elegido
en la licitación que sigue a este contrato.
2) “Indicadores de Procesos Misionales”, el cual presenta los indicadores de
procesos identificados hasta el momento y que son parte de los requerimientos
funcionales del SIM.

CAPÍTULO 3 –REQUERIMIENTOS
FUNCIONALES
En los cuadros siguientes se relaciona la lista de requerimientos (nombre de los casos

de uso) por subsistema y el anexo en el cual se encuentran los casos de uso
detallados.
3.1 SIC: Subsistema de Información a la Ciudadanía (Anexo 1)
# REQUERIMIENTO SISTEMA
SIC1 Registrar Solicitudes SIC

SIC2 Registrar Peticiones
SIC3 Consultar Información SIC
SIC4 Generar datos estadísticos de demanda y evaluación SIC
de servicio
SIC5 Ingresar Inicio y Actuaciones Proceso Disciplinario SIC
reportados por OCID
SIC6 Evaluación automática del Poder Preferente SIC
SIC_INT_1 SIC_INT_1. Generar archivo de INTERFAZ
solicitudes/peticiones ingresadas por la Web
3.2 SIAM: Subsistema de Apoyo a la Misión (Anexo 2)
SIAM1 Mantener Banco de Plantillas SIAM

SIAM2 Administrar Recursos Físicos SIAM
SIAM3 Administrar Servidor PGN SIAM
SIAM4 Administrar Oficios SIAM
SIAM5 Administrar Políticas y Proyectos SIAM
SIAM6 Administrar Inventario de Entidades SIAM

SIAM7 Administrar Competencias de las Dependencias SIAM

SIAM8 Administrar Etapas, Actividades, Actuaciones e SIAM
Información Relacionada
SIAM_INT_1 Cargar Datos Servidores PGN INTERFAZ
3.3 SIMIP: Subsistema de Procesos de la PGN (Anexo 3)
SIMIP1 Asignar competencia (Dependencia) SIMIP

SIMIP2 Evaluar duplicidad SIMIP
SIMIP3 Acumular solicitud SIMIP
SIMIP4 Reversar acumulación SIMIP
SIMIP5 Abrir un documento de correspondencia en varias SIMIP
solicitudes
SIMIP6 Acumular caso SIMIP
SIMIP7 Fraccionar Caso SIMIP
SIMIP8 Relacionar casos SIMIP
SIMIP9 Complementar Información Solicitud SIMIP
SIMIP10 Asignar Servidor/Equipo de Trabajo a SIMIP
Solicitud/Caso
SIMIP11 Recibir Documentación Física Solicitudes SIMIP
SIMIP12 Contrastar solicitudes recibidas del SIAF contra SIMIP
documentación física.
SIMIP13 Definir Actuación SIMIP
SIMIP14 Asignar Prioridad, Políticas y Proyectos a una SIMIP
Solicitud/Caso
SIMIP15 Abrir Caso SIMIP
SIMIP16 Vincular IÚS con IÚC SIMIP
SIMIP17 Gestionar Actores del caso SIMIP
SIMIP18 Definir Ruta y Plan de Actividades SIMIP
SIMIP19 Registrar Actividades y Actuación/Decisión SIMIP
realizadas
SIMIP20 Alertar Vencimiento Casos SIMIP
SIMIP21 Registrar Conclusiones SIMIP
SIMIP22 Generar oficios, autos SIMIP
SIMIP23 Marcar Cierre Caso SIMIP
SIMIP24 Marcar Archivo Físico Caso SIMIP

SIMIP25 Manejar ubicación del archivo en la dependencia SIMIP

SIMIP26 Administrar préstamo de expedientes SIMIP
SIMIP27 Indicar cumplimiento por caso preventivo SIMIP
SIMIP28 Registra seguimiento SIMIP
SIMIP29 Reabrir Caso SIMIP
SIMIP30 Generar listado de fallos no enviados a SIRI SIMIP
SIMIP31 Administrar Equipos de Trabajo SIMIP
SIAM32 Manejar Agenda Servidores Públicos SIMIP
SIMIP_INT_1 SIMIP_INT_1- Recibir Solicitudes misionales INTERFAZ
SIAF
SIMIP_INT_2 SIMIP_INT_2-Transmitir sanciones SIMIP a SIRI INTERFAZ
(diligenciar formato SIRI)
SIMIP_INT_3 SIMIP_INT_3. Proveer información de INTERFAZ
documentos de salida al SIAF
SIMIP_INT_4 SIMIP_INT_4. Sugerir Caso a SIREL INTERFAZ
SIMIP_INT_5 SIMIP_INT_5 Recibir Solicitudes/Peticiones WEB INTERFAZ
SIC
3.4 SIREL: Subsistema de Legislación y Relatoría (Anexo 4)
SIREL1 AdministrarTemas SIREL

SIREL2 AdministrarServidoresPGNTemas SIREL
SIREL3 ComunicarCambiosServidoresPGN SIREL
SIREL4 Administrar información jurídica SIREL
SIREL5 Administrar links internos SIREL
SIREL6 Administrar links externos SIREL
SIREL7 ConsultarListaLinksInformaciónJurídica SIREL
SIREL8 Buscar información jurídica SIREL
SIREL9 Generar documento SIREL
SIREL_INT_1 SIREL_INT_1. Consultar Temas INTERFAZ
SIREL_INT_2 SIREL_INT_2. Evaluar casos sugeridos INTERFAZ

CAPÍTULO 4 – ESPECIFICACIONES
SUPLEMENTARIAS
Las especificaciones suplementarias corresponden a requerimientos funcionales del

sistema que no se encuentran especificados en los casos de uso descritos en los
Anexos 1 a 4 de este documento, y en la mayoría de ellas aplican de manera general
al sistema, más que a requerimientos particulares del mismo. Estas especificaciones
han sido incluidas con el propósito de tener unas estimaciones de los requerimientos
de consultas, reportes y generación de información del Sistema de Información
Misional de la PGN.
Estos requerimientos funcionales adicionales deberán ser ampliados y detallados

durante las fases de Inicio y Elaboración del Sistema de Información Misional de la
PGN por el proveedor que realizará el análisis, diseño y construcción de este sistema
y que será contratado por la Procuraduría con posterioridad al contrato 066 de 2.004
suscrito con la Universidad de los Andes.
4.1 Tipos de Información que debe generar el SIM
En este capítulo se han dividido las especificaciones suplementarias en:
a) Consultas de Información
b) Reportes y Generación de Información
c) Indicadores de Procesos

4.1.1 Consultas de Información:
9 El sistema deberá ofrecer a todos los usuarios, la posibilidad de consultar

información por diferentes conceptos, de acuerdo con el rol de cada uno
de ellos.
9 La solución debe incluir ayudas en línea para apoyar al usuario en el
diligenciamiento correcto de cada uno de los formularios que deban ser
ingresados al sistema.
4.1.2 Reportes y Generación de Información :
9 El sistema debe permitir generar información y reportes que involucran
información de varios conceptos y en estos casos, aunque la salida del
reporte esté prediseñada, se debe permitir de una manera orientada, que el
usuario defina los criterios de selección de datos para el reporte y el
orden de la salida.
9 Suministrar información que permita a la PGN contar con información de
soporte para el mejoramiento de las políticas, estrategias, reglamentos y
procesos de la PGN.
9 El sistema debe generar información que facilite el desarrollo de las
actividades de planeación, seguimiento, autocontrol, control de gestión,
mejoramiento de procesos y servicios, racionalización de trámites y
procedimientos, diagnósticos y estudios de impacto sobre los procesos
misionales de la PGN.
4.1.3 Indicadores de Procesos
El sistema debe contar con la información y las facilidades para calcular y generar la
información de los indicadores de procesos misionales, definidos con base en los
procesos optimizados elaborados por la Universidad y las variables identificadas por
la PGN. Los indicadores identificados hasta el momento se encuentran en el
documento “Indicadores de Procesos Misionales”, el cual hace parte de los Términos
de Referencia para la contratación del SIM.
4.2 Identificación de Información que debe generar el SIM

A continuación se enuncian algunas consultas, reportes y plantillas identificadas
durante esta consultoría por la Universidad, como ejemplo de los que deberán ser
generados por el SIM, algunos de los cuales se encuentran mencionados en los casos
de uso de los Anexos 1 a 4 de este documento y otros han sido incluidos de manera
general con cantidades estimadas. La mayoría de los ejemplos dados corresponden a
la función disciplinaria.

4.2.1 Consultas
Las consultas aquí identificadas han sido generadas a partir de los casos de uso
especificados en el sistema SIM:
a) Ejemplos de SIAM
- Mantener banco plantilla - Consulta

- Administrar recursos físicos - Consulta recurso
- Administrar recursos físicos - Consulta tipo recurso
- Administrar recursos físicos - Consulta de asignación
- Administrar información Servidor PGN - Consulta
- Administrar Inventario Entidades - Consulta Entidad
- Administrar Políticas y Proyectos - Consulta
- Administrar oficio - Consulta Oficio
- Administrar oficio - Consulta Tipo Oficio
- Administrador de competencias -Consulta Dependencia Organizacional
- Administrador de competencias - Consulta Dependencia Virtual
- Administrar Etapas Actividades, Actuaciones - Consulta
b) Ejemplos de SIC
- Consultar Información WEB - Solicitudes

- Consultar Información WEB – Peticiones
c) Ejemplos de SIMIP:
- Definir ruta y Plan de Actividades - Consulta datos generales

- Definir ruta y Plan de Actividades - Consultar programación una solicitud
- Registrar Conclusiones - Consultar
- Manejar ubicación del archivo en la dependencia - Consulta
- Administrar préstamo de expedientes - Consulta
- Generar lista de fallos no enviados a SIRI
- Manejar Agenda Abogado - Consulta
- Administrar Equipos de trabajo - Consultar
- Programa de migración desde GEDIS - Consulta de datos
d) Ejemplos de SIREL
- Consultar lista Links información Jurídica

- Buscar Información Jurídica
- Generar Documento

- Administrar Temas - Eliminar

- Administrar Sevidores PGN - Temas - Consulta
- Administrar links internos - Consultar
- Administrar links externos - Consultar
- SIREL_INT_2_Evaluar Casos Sugeridos - Consulta
- Programa de migración desde PIREL - Consulta de datos
e) Consultas Adicionales
Adicionalmente se ha estimado que se requieran unas 30 consultas adicionales en el

SIM, principalmente en el SIMIP, las cuales se han clasificado de complejidad alta,
media y baja, de la siguiente manera:
Complejidad de la Consulta Cantidad

Alta 5
Media 15
Baja 10
Total Consultas 30 en total
4.2.2 Reportes
a) De manera general:
Con respecto a los reportes, generación de estadísticas y archivos que la Procuraduría
debe generar con el Sistema de Información Misional – SIM, se han identificado y
estimado por parte de la Universidad, algunos requerimientos adicionales a las
especificaciones dadas en los casos de uso, los cuales deberán ser ampliados y
detallados por el proveedor que contrate la PGN para la construcción del mencionado
sistema. A continuación se enumeran algunos de estos requerimientos:
¾ Para SIC, la generación de datos estadísticos para seguimiento y evaluación
del servicio por parte de la PGN.
¾ 10 Reportes para la generación de Indicadores de proceso (Documento

“Indicadores de Procesos Misionales”), los cuales se han estimado de
complejidad alta.
¾ 50 reportes, clasificados de la siguiente manera:

Complejidad del Reporte Cantidad

Alta 20
Media 20
Baja 10
Total Reportes 50 en total
¾ Convenios para suministrar la información que se genera actualmente con el

sistema SEPREDH en medio magnético a las siguientes entidades: Fiscalía,
Vicepresidencia, Alcaldía de Bogotá y Defensoría del Pueblo, con relación a
Derechos Humanos.
¾ Convenios para suministrar la información que se genera actualmente con el

sistema GEDIS, ejemplo de uno de ellos es el del Ministerio de Defensa -
Oficina de Derechos Humanos, que incluye los procesos activos y fallados
contra miembros de las fuerzas militares y policía por violación en derechos
humanos.
b) Ejemplos de Estadísticas generadas por el GEDIS actualmente:
El siguiente listado de estadísticas son ejemplos de las estadísticas generadas por

Registro y Control con el sistema GEDIS (función disciplinaria), actualmente en
operación en la PGN:
No. Nombre
1. Actuaciones realizadas por las FFMM
2. Actuaciones realizadas por dependencia
3. Actuaciones realizadas por entidad y conducta
4. Actuaciones realizadas por entidad
5. Comisiones enviadas por dependencia
6. Comisiones recibidas por dependencia
7. Decisiones de 1ª. Instancia por dependencia
8. Decisiones de 2ª. Instancia por dependencia
9. Decisiones de 2ª. Instancia respecto a la 1ª
10 Movimiento Final por Etapas
11 Movimiento 2ª. Instancia por dependencia
12 Inventario de procesos por dependencia
13 Quejas recibidas desde/hasta una fecha dada de las FFMM
14 Quejas recibidas desde/hasta una fecha dada por entidad y conducta
15. Quejas recibidas desde/hasta una fecha dada por entidad
16. Relación de Expedientes con Sanciones en las FFMM
17. Relación de Expedientes con Sanciones por dependencia

No. Nombre
18. Relación Salida de Expedientes
19. Relación Expedientes Inventario Final
20. Sanciones 1ª. Instancia FFMM
21. Sanciones 1ª. Instancia por entidad
22. Sanciones 2ª. Instancia FFMM
23. Sanciones 2ª. Instancia por entidad
24. Tipo de Actuaciones
25. Reporte de Quejas Registradas por Asunto
c) Ejemplos de Reportes Informativos y de Control generados por el GEDIS

actualmente:
El siguiente listado de reportes de información y control del seguimiento de los

procesos disciplinarios, son ejemplos de los reportes generados por Registro y
Control y las diferentes dependencias de la PGN con el sistema GEDIS (función
disciplinaria), actualmente en operación en la entidad. Es importante aclarar que
algunos o muchos de estos listados en el nuevo sistema SIM pueden convertirse solo
en consultas, sin requerirse un reporte de los mismos.
Nombre
No.
1. Radicador
2. Implicados
3. Trámite Histórico
4. Quejas Próximas a Prescribir
5. Archivos
6. Expedientes. para primera Instancia
7. Expedientes para segunda Instancia
8. Expedientes para Apelación Pruebas
9. Comisiones
10. Repartos

Nombre
No.
11. Listado de Afectados
12. Expedientes activos con fallo
13. Expedientes Activos a una fecha
14. Repartos Primera Instancia
15. Repartos Segunda Instancia
16. 1a Instancia (periodo)
17. 2a Instancia (periodo)
18. Revocatoria Directa
19. Quejosos
20. Implicados Activos por Dependencias
21. Remisiones Entidades
22. Pliegos de Cargos
23. Implicados según conducta
24. Estado Expedientes por etapas
4.2.3 Plantillas
En este numeral se incluye a manera de ejemplo una lista de las plantillas más
representativas identificadas hasta el momento como requerimientos de la PGN en el
Sistema de Información Misional, particularmente en el Subsistema de Información
de Apoyo a la Misión (SIAM). Esta lista de plantillas deberá ser ampliada y detallada
por el proveedor que contrate la PGN para la construcción del mencionado sistema,
durante el análisis y diseño del mismo, en el contrato que sigue a esta consultoría de
la Universidad.
Esta lista ha sido elaborada con base en la especificación del Caso de Uso “Generar
Oficios y Autos” del Subsistema SIMIP.

No. Nombre Plantilla Función
1. Apertura de caso Prevención
2. Traslado por competencia a otra dependencia Prevención
3. Traslado por competencia otra autoridad Prevención
4. Rechazo Prevención
5. Apertura de caso Intervención
6. Acumulación caso existente Intervención
7. Rechazo Intervención
8. Traslado por competencia a dependencia interna Intervención
9. Auto de Remisión por Competencia a otra Disciplinaria

Entidad
10. Auto de Archivo. Disciplinaria
11. Auto de Apertura Indagación Preliminar Disciplinaria
12. Auto de Apertura Investigación Disciplinaria
13. Auto de Acumulación. Disciplinaria
14. Auto de supervigilancia Disciplinaria
15. Citación a audiencia - procedimiento ante Disciplinaria

Procurador General.
16. Citación a audiencia - procedimiento verbal Disciplinaria

ANEXO 1 – DESCRIPCIÓN DETALLADA

CASOS DE USO SIC
Requerimientos Detallados Módulo SIC (Documento Final) Pág. i

TABLA DE CONTENIDO
SIC1 - Registrar Solicitudes…………………………………………………………………. 1
SIC2 - Registrar Peticiones………………………………………………………………….. 7
SIC3 - Consultar Información………………………………………………………………..13
SIC4 - Generar datos estadísticos de demanda y evaluación de servicio…………………...19
SIC5 - Ingresar Inicio y Actuaciones Proceso Disciplinario reportados por OCID…………24
SIC6 - Evaluación automática del Poder Preferente……………..…………………….…....30
SIC_INT_1. Generar archivo de solicitudes/peticiones ingresadas por la Web………..…...34
Requerimientos Detallados Módulo SIC (Documento Final) Pág. ii

CASO DE USO REGISTRAR

SOLICITUDES
Requerimientos Detallados Módulo SIC (Documento Final) Pág. A1-1

RegistrarSolicitudes.doc
04/05/05 1.0 Versión Inicial Disney Rubiano
21/07/05 3.0 Revisión observaciones PGN C.Díaz
26/07/05 3.0 Revisión observaciones PGN – Se abrió el C.Díaz
caso de uso en Registrar Solicitudes
(quejas) y Registrar Peticiones (derechos de
petición), para dar mayor claridad.

Caso de Uso Registrar Solicitudes

El presente caso de uso tiene como objetivo permitir el ingreso de demandas de servicio.
Dichas demandas de servicio corresponden a solicitudes o quejas nuevas asociadas a alguna
de las áreas misionales de la PGN. Puede ser utilizado por los ciudadanos que vía Web
accedan al sistema o por servidores de la PGN que de forma oficiosa ante el conocimiento
de un hecho ingresan una solicitud a SIMIP.
Vale la pena aclarar que dichas solicitudes corresponden a: Quejas disciplinarias,
Solicitudes de acción preventiva, Solicitudes de Intervención Judicial o Administrativa o
Solicitudes de Ejercicio del Poder Preferente que se registran por primera vez en el sistema.
Las peticiones de los ciudadanos sobre casos ya existentes, para conocer por ejemplo
información detallada del caso, se ingresan al sistema por el caso de uso Registrar
Peticiones.
2. Clasificación del Caso de Uso

2.1 Iteración
0
2.2 Prioridad
Alta
2.3 Complejidad
Alta
Ciudadano o Servidor PGN
4. Entradas
Se debe recolectar como mínimo la siguiente información:
Datos de quien formula la demanda de servicio o solicitud:
Si es el servidor de la PGN que esta registrando una solicitud de manera oficiosa, la
información del servidor quedará registrada automáticamente como persona que formula la
solicitud.
Si es un ciudadano, debe recolectarse información como:

• Tipo de persona: Natural o Jurídica
• Calidad: Particular o Pública
• Nacionalidad: Nacional o Extranjero
• Número de identificación (NIT, Cédula de ciudadanía, Cédula de extranjería, etc.).
• Nombres y apellidos del ciudadano, Nombre de la entidad que formula la queja o

solicitud.
• Dirección de correspondencia, correo electrónico, fax y teléfono del

ciudadano/entidad.
• País, Departamento, Ciudad o Municipio de Procedencia
Datos de la Solicitud:
• Tipo de solicitud: Queja disciplinaria – Solicitud de acción preventiva – Solicitud

de Intervención Judicial o Administrativa – Solicitud de Ejercicio del Poder
Preferente.
• Fecha (automática).
• Detalle de la solicitud: Esta pantalla de detalle debe contener los campos

específicos de acuerdo al tipo de solicitud.
Ejemplos:
• Para el caso disciplinario, se debe recolectar: fecha y lugar de los hechos,

presuntos responsables – autoridad y/o servidores, presunta falta, víctimas
o perjudicados con la conducta, datos del quejoso y descripción de los
hechos (resumen).
• Si se trata de solicitud de ejercicio del poder preferente, se deberá registrar

el número del proceso disciplinario, entidad y estado del proceso (etapa),
agregando las razones por las cuales solicita que la PGN asuma el
conocimiento del proceso y la calidad del solicitante en el proceso
(autoridad de conocimiento, implicado, defensor, víctima, perjudicado,
representante de las víctimas o perjudicados o tercero). Si el proceso se
encuentra en segunda instancia para decidir recurso de apelación, se deberá
indicar la fecha de admisión del recurso.
• Si se trata de solicitud de intervención judicial, como agente ordinario o

especial, deberá indicarse el número de proceso, autoridad de
conocimiento, tipo de proceso, etapa, calidad del solicitante dentro del
proceso (demandante, demandado o investigado, apoderado o defensor,
autoridad de conocimiento o tercero) y exponer las razones por las cuales
solicita la participación del Ministerio Público.

• Archivos anexos: El sistema debe permitir anexar documentos que el ciudadano o

el servidor que este registrando la solicitud desee incorporar al momento de
ingresar la solicitud.
5. Salidas
Registro con información de la demanda de servicio o solicitud, junto con el eventual
archivo o documento adjunto si es del caso.
6. Flujo de Eventos
6.1 Flujo Básico
Acción de los actores Respuesta del sistema
1. Este caso de uso comienza cuando el
ciudadano o el servidor de la PGN, se
dispone a ingresar los datos de una solicitud
a SIMIP.
2. La persona selecciona la opción de
ingreso de datos sobre el sistema (Internet).
3. El sistema despliega una pantalla donde se
podrán ingresar los respectivos datos. Si el
que esta ingresando la informacion es el
ciudadano, el sistema desplegara una sección
para registrar su información (nombre,
dirección, etc). Si es un servidor PGN, el
sistema automáticamente con la
identificación del usuario llenará los campos
relacionados con quien formula la solicitud.
(Ver sección de entradas de este documento).
4. La persona ingresa al sistema los datos de
la demanda de servicio o solicitud, y da la
opción de guardar.
5. Si la información es consistente y
completa, el sistema almacena un registro en
el sistema SIMIP con la correspondiente
información del ciudadano o servidor, la
información detallada de la solicitud y
eventual archivo adjunto.
Luego se activa el caso de uso “Generar datos
estadísticos”. (este caso de uso permite llevar
un registro de información de quienes usan el
sistema, especialmente del contacto
ciudadano).

6. El sistema debe generar un número de

solicitud, notificando al usuario el número y
la fecha de radicación, para que a futuro
pueda obtener información sobre el trámite
que se dio a su solicitud. (Este número viene
del SIAF).
7. El sistema debe hacer un llamado al caso
de uso asignar competencia, con el fin de
asignar la dependencia competente y generar
un mensaje de llegada, como en el correo
electrónico, dejando el asunto como Tarea
Pendiente en la respectiva dependencia.
En los casos en que no sea posible asignar la
dependencia, el sistema asignará a la
División de Registro y Control. (Este puede
ser el caso de solicitudes realizadas por
ciudadanos que no contengan toda la
información requerida para la asignación
automática de dependencia).

Línea 4: Si no ingresa los datos básicos, no se debe permitir el registro de los datos y se
desplegará al usuario un mensaje indicándole de lo sucedido y de los valores que debió
haber diligenciado para hacer el ingreso de la queja o solicitud.
7. Precondiciones
La información correspondiente a la solicitud/demanda de servicio y al ciudadano/servidor
PGN. El archivo adjunto.
8. Post Condiciones
Se crea un registro en el sistema correspondiente a la solicitud en SIMIP.
Se debe revisar cual es la información detallada que va a ser solicitada, especialmente la
diferencia entre la información que puede dar un ciudadano y la que puede suministrar un
servidor. Y la relación de este caso de uso con el de completar información de SIMIP, que
esta relacionado con el ingreso de la información de la solicitud.


PETICIONES

RegistrarPeticionesv3.0.doc
25/07/05 3.0 Revisión observaciones PGN – Se crea este C.Díaz
requerimiento para distinguir el registro de
las solicitudes o quejas, del registro de los
derechos de petición.
Requerimientos Detallados de los Sistemas de Información (Documento Final) Pág. A1-8

Caso de Uso Registrar Peticiones

El presente caso de uso tiene como objetivo permitir el ingreso de peticiones vía Web
(derechos de petición) de los ciudadanos para solicitar información a la PGN sobre
conceptos, o casos ya existentes. Para ello se deberá registrar una petición con la
información mínima necesaria para identificar el caso y/o la solicitud, para luego remitirse a
la dependencia o funcionario a cargo quien se encargará de resolver o contestar dicha
petición.
Las peticiones aquí registradas corresponden a consultas que implican análisis,
fundamentación y posición por parte de la Entidad. Las consultas que pueden sen generadas
por el sistema se encuentran descritas en el caso de uso Consultar Información.
2.1 Iteración
0
2.2 Prioridad
Alta
2.3 Complejidad
Alta
Ciudadano
4. Entradas
Se debe recolectar como mínimo la siguiente información:
Datos de quien formula la Petición:

solicitud.


ciudadano/entidad.
Datos de la Petición:
• Detalle de la petición:
• Si se trata de un derecho de petición relacionado con un caso existente en la

PGN, deberá señalar el número del caso y la dependencia de conocimiento,
a donde deberá direccionarse la solicitud.
• Si se trata de un derecho de petición relacionado con un concepto, se

deberá suministrar la información necesaria para direccionar la petición a la
dependencia competente. Si no es posible establecer la competencia, se
deberá asignar como dependencia la División de Registro y Control.
• Archivos anexos: El sistema debe permitir anexar documentos que el ciudadano

que este registrando la petición desee incorporar al momento del ingreso.
5. Salidas
Registro con información de la petición, junto con el eventual archivo o documento adjunto
si es del caso.
6. Flujo de Eventos
6.1 Flujo Básico
ciudadano se dispone a ingresar los datos de
una petición a la PGN.
podrán ingresar los respectivos datos. Si el
que esta ingresando la informacion es el
ciudadano, el sistema desplegara una sección
para registrar su información (nombre,
dirección, etc).
(Ver sección de entradas de este documento).
4. La persona ingresa al sistema los datos de
la petición, y da la opción de guardar.


información del ciudadano, la información
detallada de la petición y eventual archivo
adjunto.
Luego se activa el caso de uso “Generar datos
estadísticos”. (Este caso de uso permite llevar
un registro de información de quienes usan el
sistema, especialmente del contacto
ciudadano).
la fecha de radicación, para que a futuro
pueda obtener información sobre el trámite
que se dio a su solicitud. (Este número viene
del SIAF).
7. El sistema debe hacer un llamado al caso
de uso asignar competencia, con el fin de
asignar la dependencia competente y generar
un mensaje de llegada, como en el correo
electrónico, dejando el asunto como Tarea
Pendiente en la respectiva dependencia.
En los casos en que no sea posible asignar la
dependencia, el sistema asignará a la
División de Registro y Control. (Este puede
ser el caso de peticiones realizadas por
ciudadanos que no contengan toda la
información requerida para la asignación
automática de dependencia).

haber diligenciado para hacer el ingreso de la queja o solicitud.
7. Precondiciones
La información correspondiente a la petición y al ciudadano. El archivo adjunto.
8. Post Condiciones
Se crea un registro en el sistema correspondiente a la solicitud en SIMIP.

Se debe revisar cual es la información detallada que va a ser solicitada, especialmente para
validar que el sistema pueda con base en dicha información disparar el caso de uso de
asignar competencia para asignar la dependencia encargada de la petición. También debe
revisarse la relación de este caso de uso con el de completar información de SIMIP, que
esta relacionado con el ingreso de la información de la solicitudes.

CASO DE USO CONSULTAR

INFORMACIÓN

ConsultarInformación-v3.0

21/07/05 3.0 Revisión Observaciones PGN C.Díaz
27/07/05 3.0 Revisión Observaciones PGN – Se incluyen C.Díaz
consultas a SIRI o RELATORIA como link
a dichos aplicativos.
Se cambia el nombre de Consultar
Solicitudes a Consultar Información para
hacerlo mas genérico e incluir consultas a
peticiones y otros módulos como SIREL.
Requerimientos Detallados Módulo SIC (Documento Final) Pág. A1- 14

Caso de Uso Consultar Información

El presente caso de uso tiene como objetivo brindar información a los ciudadanos o
autoridades sobre servicios de la PGN en las distintas áreas misionales.
Este caso de uso incluye los siguientes tipos de consultas:
- SIRI (Link al aplicativo): Consultas de antecedentes en línea a través de la funcionalidad
del aplicativo SIRI.
- Relatoria (Link al aplicativo): Consultas de información de relatoría a través de la
funcionalidad de SIREL. (Caso de uso SIREL-Buscar información)
- Consulta Solicitudes y/o Casos: Consultas de información sobre casos registrados en
SIMIP. Dichas consultas deben tener en cuenta las disposiciones legales sobre la reserva de
las investigaciones.
- Consulta peticiones: Consultas sobre derechos de petición registrados en SIMIP.
Vale la pena aclarar que las dos últimas -consultas sobre SIMIP-, son aquellas en las que el
ciudadano puede obtener información directa del sistema, y no requieren de un análisis por
parte de la dependencia. En los casos en los que la consulta se refiera a un aspecto que
implique análisis, fundamentación y posición por parte de la Entidad, se deberá registrar
una petición con la información mínima necesaria para identificar el caso y la solicitud,
para luego remitirse a la dependencia o funcionario a cargo quien dará respuesta a la
solicitud. (Caso de uso Registrar Peticiones).

2.1 Iteración
0.
2.2 Prioridad
Alta.
2.3 Complejidad
Alta.
Ciudadano o Entidad

4. Entradas
Datos del solicitante:

solicitud.

ciudadano/entidad.
Datos de la consulta:
• Si es una consulta relacionada con SIRI o SIREL se debe desplegar la pantalla de

parámetros de la Consulta del sistema correspondiente.
• Si es una consulta relacionada con SIMIP, se deben desplegar los parámetros de

acuerdo a si es sobre un caso/solicitud o si es sobre una petición. Ejemplo: Para
consultas sobre un caso disciplinario casos los parámetros podrían ser datos del
implicado, número de proceso disciplinario, etc.
5. Salidas
Respuesta a la solicitud.
6. Flujo de Eventos
6.1 Flujo Básico

ciudadano o autoridad hace una consulta a
la PGN a través del SIC. (Dicha consulta
puede ser resuelta por el sistema de manera
automática.)
2. El sistema despliega formulario para que el
ciudadano lo diligencie de acuerdo a las 4
opciones de consulta:
- SIRI


- SIREL
- SIMIP – consulta casos/solicitudes
- SIMIP – consulta peticiones
3. El ciudadano o entidad ingresa la
información mínima de la consulta. (Ver
sección de entradas)
En todas las consultas, se deberá registrar
los datos del solicitante (ciudadano o
entidad).
Para las consultas de SIMIP: se debe
registrar información particular del caso o
petición.
4. Busca en el medio de almacenamiento, un
registro con la información asociada a los
parámetros suministrados.
5. Muestra al ciudadano una lista de los
registros que cumplen dicha condición (puede
ser mas de un registro, en el caso por ejemplo,
de que un investigado tenga abierta mas de
una investigación).
6. El ciudadano analiza el contenido de la
lista y selecciona la solicitud o queja que
considere cumple su búsqueda.
7. Despliega la información detallada
correspondiente a la solicitud seleccionada en
la línea 4.
Ejemplo: Para un caso disciplinario en trámite
lo que se puede mostrar es la información
básica del caso, como fecha de inicio,
radicado, dependencia y etapas procesales.
Es importante resaltar que de acuerdo a la
calidad del solicitante (ejemplo, en un
proceso disciplinario, si es el apoderado,
disciplinado, víctima, perjudicado, apoderado
de las víctimas o tercero), la información
suministrada por el sistema puede variar.


Línea 3: Si no existen registros asociados a los parámetros suministrados, despliega un
mensaje que le indica al usuario de la situación.
7. Precondiciones
El usuario debe suministrar los parámetros de búsqueda de registros al sistema.
8. Post Condiciones
Se despliegan los registros almacenados que corresponden a los parámetros de búsqueda
suministrados por el usuario.
Se debe revisar si se requiere una opción adicional de consulta sobre estadísticas generales,
como número total de casos, distribuida por áreas, por dependencias, etc.
También se debe definir en detalle los campos que se van a mostrar como resultado de la
consulta de acuerdo a la calidad del solicitante y a la reserva.

CASO DE USO GENERAR DATOS

ESTADÍSTICOS DE DEMANDA Y
EVALUACIÓN DE SERVICIO

GenerarDatosEstadísticos.doc

25/07/05 3.0 Revisión observaciones PGN – aclaración C.Díaz
estadísticas de demanda de servicio .vs.
estadísticas de respuesta institucional.

Caso de Uso Generar Datos Estadísticos de

Demanda y Evaluación de Servicio
El presente caso de uso tiene como objetivo generar reportes que permitan a la PGN
conocer quienes son los ciudadanos que están usando los servicios de la Entidad para poder
medir la demanda de servicio y la respuesta institucional al requerimiento, y eventualmente,
poder llevar a cabo encuestas para medir la percepción de los mismos.
Se trata entonces de dos cosas, de un lado, llevar un registro de las demandas de servicio y
peticiones a la PGN, generando estadísticas por tipo, área, dependencia, etc… Y de otro
lado, emprender tareas de medición de la respuesta institucional, tales como casos resueltos,
los tiempos de respuesta, el nivel de satisfacción del usuario, etc….
Estadísticas de demandas de servicio: Estas estadísticas se obtienen de la información
suministrada por el ciudadano, autoridad o entidad al momento de registrar una solicitud o
una petición. Como ejemplo tenemos:
- Tipo de solicitudes y peticiones que hacen a la Entidad los ciudadanos o autoridades en
un tiempo determinado
- Datos de los solicitantes/ peticionarios (por ejemplo, personas naturales vs personas
jurídicas, particulares vs autoridades, regiones, edades, etc…)
Estadísticas de respuesta institucional: Estas estadísticas se obtienen de la información
registrada en SIMIP por los servidores de la PGN sobre las diversas actividades y
actuaciones realizadas en cada caso o petición. Ejemplos de ellas son:
- Estadísticas de número de peticiones resueltas
- Estadísticas de número de solicitudes/casos resueltos
- Estadísticas del tiempo de respuesta de acuerdo a los términos establecidos por la ley,
etc.
- Estadísticas por tipo de actuación (decisión). Ejemplo: número de fallos sancionatorios,
número de casos archivados, etc.
Estas estadísticas pueden ser confrontadas con la percepción que los usuarios y autoridades
puedan tener respecto de los servicios que presta la PGN.


2.1 Iteración
0
2.2 Prioridad
Alta.
2.3 Complejidad
Alta.
Sistema
4. Entradas
Opciones que a través del SIC se dejan a disposición de los usuarios de la PGN –
ciudadanos, autoridades o entidades del estado (oficinas de control interno).
5. Salidas
Registra y contabiliza en el sistema lo correspondiente a los datos del usuario, al servicio
solicitado (ejemplo: información de legislación y relatoría, consulta o registro de
solicitudes, registro de inicio de procesos disciplinarios por parte de las oficinas de control
interno disciplinario) y a la información desplegada por el sistema.
6. Flujo de Eventos
6.1 Flujo Básico

1. Este caso de uso comienza cuando el SIC
activa cualquiera de las siguientes acciones:
• Consultas de Información :
Búsqueda de información de
legislación y relatoría.
Búsqueda de los datos de una solicitud.
Búsqueda de los datos de una petición.
Búsqueda de información de SIRI.
• Registro de una solicitud.
• Registro de una petición.

2. Toma los datos referentes al usuario y de la

acción seleccionada y los registra. Por
ejemplo: Almacena en el sistema el nombre y
la identificación del usuario, y el tipo de
acción que ejecutó.
También contabiliza la acción, Por ejemplo:
• Cuenta un registro más de una consulta

de solicitud, y dentro de esta cuenta una
consulta más de una solicitud que es de
competencia preventiva.
• Cuenta las veces que no se encuentra

información asociada a los parámetros de
búsqueda.
• Cuenta las veces que consulta un tema en

particular dentro de SIREL.
El flujo básico descrito anteriormente corresponde a las estadísticas de demanda de

servicio.
Respecto a las estadísticas de respuesta institucional se debe revisar si el sistema satisface
los requerimientos a través de las estadísticas de gestión y la generación automática de
indicadores, que pueden ser para un servidor, una dependencia, un área o a nivel
institucional, lo cual, para este evento, se puede complementar con un informe de gestión e
indicadores por caso, con lo cual, se generaría la información base para determinar la
respuesta institucional ante la demanda de servicio.

No existen.
7. Precondiciones
Se debe contar con valores referentes a los parámetros de búsqueda de información
legal/SIREL, o de una búsqueda o registro de una solicitud o petición.
8. Post Condiciones
Se registran los correspondientes valores del usuario y acción realizada sobre el sistema. Se
hace la correspondiente contabilización de valores.
Relacionar las estadísticas de respuesta institucional con las estadísticas de gestión y la
generación automática de indicadores.

CASO DE USO INGRESAR

INICIO/NOVEDADES PROCESOS
OCID

IngresarInicioNovedadesOCID-v3.0

21/07/05 3.0 Versión Inicial C.Díaz
27/07/05 3.0 Se incluyen además de los inicios de
procesos disciplinarios, las actuaciones
como apertura, cargos, fallos, etc, que serán
registradas en el sistema, para que la PGN
pueda ejercer el poder preferente en
cualquier momento del proceso.

Caso de Uso Ingresar Inicio Proceso Disciplinario

El presente caso de uso tiene como objetivo que las Oficinas de Control Interno
Disciplinario de las entidades del Estado puedan ingresar información del inicio de
procesos disciplinarios por la Web para poner en conocimiento de la Procuraduría la
apertura de investigaciones disciplinarias y de esta manera facilitar a la PGN el ejercicio del
Poder Preferente.
Para reportar inicio de procesos disciplinarios, se debe tener en cuenta el mapa estratégico
de la PGN, de tal forma, que únicamente se reporten aquellos casos que se adscriben a las
prioridades institucionales.
De igual manera podrán reportar las principales decisiones del proceso disciplinario, tales
como: archivo, apertura de investigación, cargos, fallo y suspensión del servidor
investigado de tal manera que la Procuraduría pueda ejercer el poder preferente en etapas
distintas al inicio del proceso disciplinario.

2.1 Iteración
0.
2.2 Prioridad
Alta.
2.3 Complejidad
Media.
Oficinas de Control Interno Disciplinario (OCID)
4. Entradas
Datos de la entidad que comunica el proceso disciplinario:
- Nombre de la Entidad
- Tipo de entidad: Nacional - Descentralizada
- Contacto (persona de la oficina de CI)
- Dirección de correspondencia, correo electrónico, fax y teléfono de la persona contacto.

Datos del Proceso Disciplinario:

- Número del proceso
- Tipo de proceso: Verbal – Ordinario: Indagación Preliminar o Investigación
- Fecha de inicio
- Información del Investigado:
o Nombre
o Identificación
o Cargo
o Dependencia
o Fuerza Pública: Tipo (FFMM – PN) – Rango.
- Información de los hechos y conductas investigadas :
o Fecha y lugar de los hechos
o Presunta Falta: Temática – Conducta – Falta
o Forma de culpabilidad: Dolo – Culpa Gravísima - Culpa
o Víctimas o Perjudicados con la Conducta
o Resumen de los hechos
- Prioridad / Política a la que corresponde
- Tipo de Actuación en el proceso disciplinario: (Esta sección debe invocarse para
registro de novedades, sobre un proceso disciplinario previamente registrado en el
sistema).
o Decisión
o Fecha
5. Fecha Salidas
Registro con información de la comunicación de la oficina de CI.
6. Flujo de Eventos
6.1 Flujo Básico

encargado de una entidad (oficina de
control interno), se dispone a ingresar los


datos de apertura de un proceso
disciplinario en la entidad o las
actuaciones/decisiones de un proceso
disciplinario existente para conocimiento de
la PGN.
podrán ingresar los respectivos datos.(Ver
sección de Entradas en el presente
documento). Si se esta entrando una
actuación (decisión) de un proceso
disciplinario reportado previamente el
sistema debe permitir invocar el proceso
mediante el número de proceso (entidad) o el
número de solicitud (SIMIP).
4. El funcionario de la oficina de CI de la
entidad ingresa al sistema los datos de la
comunicación de inicio de proceso cuando
se esta registrando el proceso por primera
vez, o los datos de actuación/decisión y
fecha cuando se esta reportando una
novedad y da la opción de enviar.
información y eventual archivo adjunto.
Activa el caso de uso “Generar datos
estadísticos”.

la fecha de radicación en el caso de registro
de inicio de proceso.
Cuando se esta registrando una novedad, el
sistema debe desplegar un mensaje del estado
de la transacción sin generar número nuevo
de solicitud.
7. Con base en la información registrada se

llama al caso de uso de asignar competencia
para asignar la dependencia competente y
generar un mensaje de llegada, como en el
correo electrónico, dejando el asunto como


Tarea Pendiente en la correspondiente
dependencia.

haber diligenciado para hacer el ingreso de la comunicación.
7. Precondiciones
La información correspondiente a la comunicación en la oficina de Control Interno de la
Entidad. El archivo adjunto.
8. Post Condiciones
Se crea un registro en el sistema correspondiente a la comunicación.
Se debe revisar cuales son los datos que son obligatorios para el ingreso de una
comunicación de una oficina de CI.
Se debe tener en cuenta que en el evento de ampliación de la apertura de investigación, se
pueden vincular nuevos servidores a la investigación. De igual manera, al reportarse las
actuaciones, se debe tener en cuenta que el OCID puede, por ejemplo, archivar contra XX y
formular cargos contra ZZ, o sancionar a XX y absolver a ZZ.
Esta funcionalidad es similar al caso de uso de SIMIP de Registrar Actividades y
Actuaciones/Decisiones, en cuanto a que algunas Actuaciones dependen de los actores. Sin
embargo el detalle que se pretende llevar sobre las actuaciones de las oficinas de OCID es
menor al detalle que se lleva para casos de la PGN.

CASO DE USO EVALUACIÓN

AUTOMÁTICA DEL PODER
PREFERENTE

EvaluaciónAutomáticaPoderPreferente-v3.0


Caso de Uso Evaluación Automática del Poder

Preferente
El presente caso de uso tiene como objetivo marcar de manera automática el NO ejercicio
del poder preferente de la PGN sobre los inicios y actuaciones de procesos disciplinarios
reportados por las oficinas de control interno disciplinario - OCID, de acuerdo a unas
políticas establecidas por la Entidad.
Una vez la OCID reporta el inicio o la actuación sobre un proceso disciplinario a la PGN, la
dependencia competente tiene 3 días hábiles para manifestar si ejerce o no el poder
preferente.
En caso afirmativo, el proceso disciplinario se debe convertir en un caso en SIMIP.
En caso negativo, existen dos posibilidades:
- Que el servidor de la PGN, manualmente indique que no se ejerce poder preferente y
registre una razón.
- Que el sistema automáticamente después de los 3 días de la notificación por parte de la
OCID, marque que NO se ejerce poder preferente y asigne como razón: acción
automática.

2.1 Iteración
0
2.2 Prioridad
Alta.
2.3 Complejidad
Alta.
Sistema
4. Entradas
Registros de inicio o novedades (actuaciones) de procesos disciplinarios reportados por las
OCID.

5. Salidas
Registro de aplicación negativa del poder preferente para un registro determinado.
6. Flujo de Eventos
6.1 Flujo Básico

1. Este caso de uso se activa como proceso
batch, sobre los inicios o actuaciones de
procesos disciplinarios notificados por OCID.
2. El sistema de manera automática marca el
Flag de poder preferente en NO y razón:
acción automática, para inicios o actuaciones
reportadas por la OCID que no hayan sido
convertidas en casos por parte de los
servidores de la dependencia competente en
el ejercicio del poder preferente una vez
hayan transcurrido 3 días de la notificación.

No existen.
7. Precondiciones
Registro de inicio o actuación de un proceso disciplinario reportado por una OCID.
8. Post Condiciones
Registro proceso disciplinario reportado por una OCID con indicador de NO ejercicio de
poder preferente.
Revisar el criterio por el cual se marca el no ejercicio de poder preferente. En este
momento, el proceso se dispara al cabo de 3 días de ser notificados por la OCID.

CASO DE USO SIC_INT_1.

GENERAR ARCHIVO DE
SOLICITUDES Y PETICIONES
INGRESADAS POR LA WEB

SIC_INT_1GenerarArchivoSolicitudesWEB.doc

C.Díaz

Caso de Uso SIC_INT_1. Generar Archivo de

Solicitudes y Peticiones ingresadas por la Web
Este caso de uso tiene como objetivo generar un archivo con las solicitudes y peticiones que
un ciudadano/entidad haya reportado vía Web, en el sistema SIC. La información del
archivo será cargada en el SIAF (ver el caso de uso “SIAF_INT_1. Cargar solicitudes
ingresadas por la Web”).
2.1 Iteración
0
2.2 Prioridad
Media
2.3 Complejidad
Media
SIC.
4. Entradas
La información recolectada vía SIC en las opciones de registro de solicitud y registro de
petición:
Datos de quien formula la demanda de servicio (Solicitud) o Petición:

solicitud.

ciudadano/entidad.

Datos de la Solicitud/Petición:
• Detalle de la solicitud o petición: Descripción breve de la solicitud o petición.
• Para el caso de solicitudes: Tipo de solicitud: Queja disciplinaria – Solicitud de

acción preventiva – Solicitud de Intervención Judicial o Administrativa – Solicitud
de Ejercicio del Poder Preferente. (Puede equivaler a tipo de clasificación de la
solicitud o asunto en SIAF o a la naturaleza).
Nota: Se debe tener en cuenta la homologación de los campos ingresados en SIMIP con la
información recolectada por SIAF una vez se tenga una versión más detallada de los
requerimientos.
5. Salidas
Un archivo que incorpore los datos que se necesiten de las entradas.
6. Flujo de Eventos
6.1 Flujo Básico
1. Este caso de uso se inicia cuando se activa la

opción de generación de un archivo, con la
información de las solicitudes y peticiones
registradas en SIC.
2. El sistema genera los registros de la interfaz en

un archivo.

Línea 2: En caso de encontrar un error (por ejemplo: sobre el tipo del dato, la longitud del
dato, inexistencia de un dato obligatorio), se debe almacenar en un archivo de log, el error
detectado.
7. Precondiciones
Deben haberse registrado en el SIC datos referentes a las solicitudes (quejas) y peticiones
(derechos de petición), junto con la información del ciudadano o entidad que los formula.
También debe tenerse en cuenta una eventual documentación adjunta.
8. Post Condiciones
Se genera un archivo.

9.1 Periodicidad del cargue
Se debe definir cada cuanto se debe activar la opción de generación del archivo en el
sistema SIC.
9.2 Tipo de cargue
Se debe definir si el cargue es automático (proceso batch).
9.3 Definir donde se debe generar el archivo
Determinar donde debe ser creado el archivo/puestos los registros que se quieren cargar en
el SIAF (servidor, path, base de datos).
9.4 Tipo de archivo
Definir el tipo de archivo que contendrá los datos que se van a cargar en el SIAF. Archivo
plano, vistas de una base de datos?
9.5 Datos que se desean cargar en el SIAF
Se debe identificar cuales son los datos que necesita SIAF y que deben ser incorporados en
el archivo. Además se debe definir las características de los datos (Tipos, longitudes,
obligatorio/no obligatorio).
9.6 Manejo de errores durante el cargue
Definir si durante la generación del archivo se produce un error, se aborta o se continua?
Definir si se hace una generación por lotes y si dicha generación del lote se aborta cuando
se produce un error, pasando a la generación del siguiente lote.
9.7 Identificación del archivo
En caso de manejar archivos planos se debe definir una nomenclatura que permita definir la
fecha y grupo de datos que almacena. Lo propio se debe hacer en la definición de vistas de
una base de datos.


CASOS DE USO SIAM
Requerimientos Detallados Módulo SIAM- (Documento Final) Pág. i

TABLA DE CONTENIDO
SIAM1 - Mantener Banco de Plantillas.…………………………………………………..… 1
SIAM2 - Administrar Recursos Físicos……………………………………………………... 9
SIAM3 - Administrar Servidor PGN……………………………………………………….. 19
SIAM4 - Administrar Oficios………………………………………………………………..24
SIAM5 - Administrar Políticas y Proyectos…………………………………………………31
SIAM6 - Administrar Inventario de Entidades………………………………………………37
SIAM7 - Administrar Competencias de las Dependencias………………………………….44
SIAM8 - Administrar Etapas, Actividades, Actuaciones e Información Relacionada………52
SIAM_INT_1 - Cargar Datos Servidores PGN………………………………………………64
Requerimientos Detallados Módulo SIAM- (Documento Final) Pág. ii

CASO DE USO MANTENER BANCO

PLANTILLAS
Requerimientos Detallados Módulo SIAM (Documento Final) Pág.A2- 1

MantenerBancoPlanillas.doc

14/07/05 2.0 Revisión Observaciones PGN Disney Rubiano

Caso de Uso Mantener Banco Plantillas

Tiene como objetivo la administración, generación y modificación de plantillas que utilice la
Procuraduría para generar comunicaciones, autos, decisiones, resolución de instrumentos, etc.
2.1 Iteración
0.
2.2 Prioridad
Media.
2.3 Complejidad
Media
Administrador SIAM.
4. Entradas
Ingreso de plantilla:
Identificación.
Descripción.
Diseñador.
Fecha de creación.
Versión.

Estado de la plantilla (Un indicador que permite identificar si la plantilla se libera o no para
que los usuarios del sistema la empiecen a usar en la generación de la correspondiente
comunicación, auto, decisión o resolución de instrumentos). Si el valor es “si”, todos los
usuarios con permisos en el sistema para generar documentación, podrían seleccionarla para
generar el correspondiente documento. Si el valor es “no”, pese a que está creada la plantilla,
ningún usuario con permisos para imprimir documentos en el sistema, tendría accedo a la
plantilla.
Un ejemplo de operación de este ítem, es el siguiente: El Administrador puede a través de la
implementación del presente caso de uso, configurar una plantilla y poner el presente ítem
con valor “si”. Con esta situación todos los usuarios con permiso de impresión podrían
acceder a la plantilla creada. Si en algún momento se requiere cambiar campos en la plantilla,
se puede tomar la plantilla original y copiarla en una siguiente versión, en este caso el
administrador puede poner el valor “no” en ese ítem y el valor “si” en la copia, con esto los
usuarios sólo tendrían acceso a la copia (siguiente versión) y no a la plantilla original. Se
debe tener en cuenta que en algunas situaciones puede suceder que por circunstancias de la
administración se requiera mantener el original, así los usuarios con permisos para impresión
no la accedan.
Por cada ítem de la plantilla:
o Texto.
o Tipo de letra del texto.
o Tamaño de la letra del texto.
o Estilo de la letra del texto.
o Ubicación del texto (Coordenadas X,Y)
o Campo para captura/despliegue del valor asociado al ítem. (Opcional: no todos los ítems
deben capturar/ desplegar un valor – Texto o numérico).
o Rango de valores del campo
o Tipo del campo.
o Lugar del medio de almacenamiento de donde toma el valor que despliega. Operación
que lo genera el valor que se despliega.
o Tipo de letra del valor.
o Tamaño de la letra del valor.
o Estilo de la letra del valor.
o Ubicación del valor (Coordenadas X,Y).
Modificación de plantilla:
Identificación.
Descripción.

Diseñador.
Fecha de creación.
Versión.
Estado de la plantilla.
Por cada ítem de la plantilla:
o Texto.
o Tipo de letra del texto.
o Tamaño de la letra del texto.
o Estilo de la letra del texto.
o Ubicación del texto (Coordenadas X,Y)
o Campo para captura/despliegue del valor asociado al ítem. (Opcional: no todos los ítems
deben capturar/ desplegar un valor – Texto o numérico).
o Rango de valores del campo
o Tipo del campo.
o Lugar del medio de almacenamiento de donde toma el valor que despliega. Operación
que lo genera el valor que se despliega.
o Tipo de letra del valor.
o Tamaño de la letra del valor.
o Estilo de la letra del valor.
o Ubicación del valor(Coordenadas X,Y).
Consulta de plantilla:
Identificación.
Eliminación de plantilla:
Identificación.
Copiar plantilla:
Esta funcionalidad se aplica en los casos donde se requiere obtener copias de una plantilla ya
creada (ingresada), bien sea por que se requiere una actualización sobre la misma en una versión
diferente (caso 1) o por que se requiere otra plantilla de naturaleza diferente, cuyo contenido en
buena medida ya fue considerado en la plantilla original (caso 2).

En el caso 1, lo ideal es que la plantilla original quede en el ítem “Estado de la plantilla” con
valor “no” y la copia, en ese mismo ítem con valor “si”. Mientras que en el caso 2, lo ideal es
que las dos plantillas (original y copia) queden con valor “si” en dicho ítem.
Los ítems que se deben tener en cuenta en este caso son:
Identificación del registro original.
Identificación del nuevo registro.
Nueva identificación de versión.
5. Salidas
Ingreso de plantilla:
Se crea y almacena en el sistema un registro de plantilla.
Modificación de plantilla:
Se modifica en el sistema un registro de plantilla ya existente.
Consulta de plantilla:
Se despliega por medio de una pantalla los datos de una plantilla.
Eliminación de plantilla:
Se elimina del medio de almacenamiento un registro de una plantilla.
Copiar plantilla:
Crear en el sistema un nuevo registro de plantilla, con los datos del registro original. Los valores
de los datos del registro de copia son iguales al los del registro original, menos la identificación y
la versión.
6. Flujo de Eventos
6.1 Flujo Básico
1. Este caso de uso comienza cuando el usuario

del sistema SIAM, selecciona una opción de
mantenimiento de plantilla: Ingreso,
Modificación, Consulta, Eliminación y Copia.
2. Si la opción es la de ingreso, despliega una

pantalla para que el administrador suministre los
datos de entrada de la plantilla.
3. Diligencia sobre la pantalla desplegada, los

datos de entrada de la plantilla. Ejecuta la opción
de almacenar.

4. Si el usuario tiene los permisos adecuados, se

almacena el nuevo registro de plantilla.
5. Si la opción es la de consulta, se despliega una

pantalla, para que el usuario ingrese el número de
identificación de la plantilla que quiere consultar.
6. El usuario diligencia sobre la pantalla

desplegada los datos de entrada (Identificación de
la plantilla). Ejecuta la opción de consultar.
7. Si el usuario tiene los permisos adecuados, se

busca un registro cuya identificación corresponde a
la suministrada en la línea 5, se despliega una
pantalla donde se muestran cada uno de los datos de
la plantilla encontrada (Son los datos de entrada
para ingreso de un plantilla).
8. Si la opción es la de modificación, el sistema

ejecuta de la línea 5 a la 7.
9. Sobre los datos desplegados, realiza las

correspondientes modificaciones. Ejecuta la
opción de almacenar cambios.
10. Si el usuario tiene los permisos adecuados, el

sistema almacena los cambios realizados.
11. Si la opción es la de eliminación, el sistema

despliega una pantalla para que usuario diligencie la
identificación de la plantilla que desea eliminar.
12. Diligencia la identificación de la plantilla.

sistema elimina de su medio de almacenamiento el
registro de plantilla asociado a la identificación
suministrada por el usuario.
14. Si la opción es la de copia, el sistema despliega

una pantalla para que usuario diligencie la
identificación de la plantilla que desea copiar y la
versión de la copia.
15. Diligencia los valores para la identificación

de la plantilla original y la versión de la copia.

sistema crea un nuevo registro de plantilla con todos
los valores de los datos del registro de la plantilla
original, exceptuando la identificación y la versión,
que corresponden a los diligenciados en la línea 15.


Línea 4: Si el número de identificación de la plantilla es igual a uno que ya existe, se cancela la
operación y se genera un mensaje que avisa de la situación al usuario del sistema.
Líneas 7: Si no se encuentra ningún registro asociado a la identificación dada, se cancela la
operación y se despliega un mensaje en el que se avisa al usuario de la situación.
7. Precondiciones
Se deben proporcionar todos los datos de entrada obligatorios, de acuerdo al tipo de operación
(Consulta, Ingreso, Actualización, Eliminación y Copia).
8. Post Condiciones
De acuerdo al tipo de operación se ejecuta una acción sobre la parte de almacenamiento del
sistema, con respecto a un registro de plantilla:
• Consulta: Se muestra en una pantalla los datos de una actividad que corresponde a la
identificación dada.
• Ingreso: Se crea y almacena en el sistema un nuevo registro con los datos de una plantilla.
• Actualización: Se modifican los datos de un registro de una plantilla ya almacenada.
• Eliminación: Se elimina del medio de almacenamiento del sistema un registro de una

plantilla.
• Copia: Se crea un nuevo registro en el sistema, de una plantilla ya existente, cambiando los
valores de la identificación y la versión.
9.1 Definición de los datos de la operación de ingreso
Definir cuales son los datos obligatorios que el usuario debe proporcionar, una vez se quiere
hacer los ingresos de los datos de una plantilla.
9.2 Definición de los datos de la operación de actualización

Definir cuales son los datos que el usuario puede modificar, una vez se quiere hacer una
actualización de datos una plantilla.
9.3 Características de los datos que se necesitan para la ejecución del caso de uso
Definir cuáles son datos necesarios para el desarrollo de este caso de uso, sus tipos y longitudes,
además de determinar cuáles son obligatorios, y cuales no.

CASO DE USO ADMINISTRAR

RECURSOS FISICOS/ELEMENTOS

AdministrarRecursosFisicos-Elementos v3.0.doc

14/07/05 2.0 Revisión Observaciones PGN Disney Rubiano

Caso de Uso Administrar Recursos

Físicos/Elementos
Tiene como objetivo permitir la asignación en préstamo de los diferentes recursos físicos.
Además de la creación, consulta, eliminación y actualización de los datos de un recurso.
Un recurso físico puede ser una sala de audiencia, un proyector, o cualquier otro elemento
de apoyo administrativo. También es cualquier elemento de apoyo misional, como bienes y
equipos entregados al servidor para el cumplimiento de sus funciones misionales, además
de los elementos de prueba que integran al proceso disciplinario (manejo de la cadena de
custodia). También se contempla en el presente caso de uso el préstamo de expedientes.
Se debe tener en cuenta que los elementos de prueba deben ser asociado a un caso y
siempre se debe conocer la ubicación física de donde se encuentran.

2.1 Iteración
0.
2.2 Prioridad
Media.
2.3 Complejidad
Media.
Servidor PGN.
4. Entradas
Ingreso de un recurso:

• Tipo de recurso (Por ejemplo: De carácter administrativo o misional).
• Código de caso. (Sólo para los elementos de prueba).
• Nombre del recurso.
• Descripción del recurso.
• Código de inventario (aplica a los recursos administrativos).
• Fecha máxima para devolución.
Eliminación de un recurso:
• Tipo de recurso.
• Código del recurso.
Consulta de un recurso:
Masiva:
Individual:
• Código del caso. (Sólo para elementos de prueba).
• Identificación/nombre de la persona/dependencia que lo solicitó
Modificación de los datos del recurso:
• Tipo de recurso (Por ejemplo: Es un lugar, medio audiovisual, etc).
• Nuevo nombre del recurso.
• Nueva descripción del recurso.
• Código de inventario.

Asignación de recursos:
• Fecha en que se pide prestado el recurso.
• Fecha en que se usará.
• Tiempo por el cual se pide prestado el recurso.
• Persona o dependencia que solicita el recurso.
• Cuando aplique, en caso de que el tipo de recurso no corresponda a un lugar, se debe

indicar en qué lugar se va a utilizar.
• Fecha máxima para devolver el recurso.
Modificación de la asignación de un recurso:
• Nueva fecha en que se pide prestado el recurso.
• Nueva fecha en que se usará.
• Nuevo tiempo por el cual se pide prestado el recurso.
• Nueva persona o dependencia que solicita el recurso.
• En caso que el tipo de recurso no corresponda a un lugar, se debe indicar en que lugar
se va a utilizar.
• Fecha máxima para devolver el recurso.
Quitar la asignación de un recurso:

5. Salidas
Ingreso de un recurso:
Se crea en el sistema, un nuevo registro con los datos de un recurso.
Eliminación de un recurso:
Se elimina del sistema, un registro que corresponde a los datos de un recurso.
Consulta de un recurso:
Masiva:
• Muestra el estado de todos los recursos del tipo dado por el usuario en la entrada
(Descripción y datos de asignación en caso de encontrarse asignado).
Individual:
• Muestra los datos de un recurso (Descripción y datos de asignación en caso de

encontrarse asignado) a partir del Tipo y. Código del recurso por la
Identificación/nombre de la persona/dependencia que lo solicitó
Modificación de los datos del recurso:
Se modifica los datos de un recurso (Tipo, descripción).
Asignación de recursos:
Se crea y almacena un registro en el sistema en cual quedan los datos de asignación de un
recurso.
Modificación de la asignación de un recurso:
Se modifica el registro de los datos de asignación de un recurso.
Quitar la asignación de un recurso:
El recurso queda libre y por tanto queda listo para una nueva asignación.
6. Flujo de Eventos
6.1 Flujo Básico

del sistema SIAM, selecciona una opción:
Ingreso, consulta, actualización ó eliminación
de recursos. Además de las de: (1) Asignación
de recurso, (2) Modificación de de asignación
y la (3) de quitar una asignación.
2. Si el usuario selecciona la opción de ingreso de


datos de un recurso, el sistema despliega una
pantalla para que él pueda diligencia los datos
correspondientes.
3. El usuario digita los datos del recurso. Da la

opción de almacenar los datos en el sistema.
4. Si el usuario tiene permisos para hacer la

operación, el sistema almacena los datos, creando
un nuevo registro.
5. Si el usuario selecciona la opción de consulta

de datos de un recurso, el sistema despliega una
pantalla donde le presenta dos opciones: Consulta
masiva, consulta individual.
6. El usuario selecciona el tipo de consulta.
7. Si el tipo de consulta es masivo, el sistema

despliega una pantalla, donde aparecen todos los
tipos de recursos.
8. El usuario selecciona un tipo de recurso.
9. El sistema despliega los datos de todos los

recursos asociados al tipo seleccionado por el
usuario: Tipo de recurso, Descripción del
recurso, Código de inventario, Código del
recurso, Fecha en que se pide prestado el recurso,
Fecha en que se usará, Tiempo por el cual se pide
prestado el recurso, Persona o dependencia que
solicita el recurso, En caso de que el tipo de
recurso no corresponda a un lugar, se debe
indicar en que lugar se va a utilizar.
10. Si el tipo de consulta es individual, el sistema

despliega una pantalla, donde el usuario deberá
diligenciar los datos de búsqueda del recurso.
11. El usuario ingresa los datos de entrada del

recurso que quiere consultar, en la pantalla.
12. El sistema busca un registro que coincida con

los datos ingresados por el usuario. Una vez
encontrado el registro despliega sus datos en una
pantalla.
13. Si el usuario selecciona la opción de

actualización, el sistema despliega una pantalla
donde el usuario podrá suministrar los datos del
recurso que quiere modificar.

recurso que quiere modificar, en la pantalla.


encontrado el registro despliega sus datos en una
pantalla.
15. Modifica los datos. Da la opción de

almacenamiento de los cambios.
16. Si el usuario tiene permisos para hacer la

operación, El sistema almacena las
actualizaciones del registro.

eliminación, el sistema despliega una pantalla
donde el usuario podrá suministrar los datos del
recurso que quiere eliminar.

recurso que quiere eliminar, en la pantalla.

encontrado el registro, si el usuario tiene
permisos para ejecutar la operación, lo elimina
del medio de almacenamiento.

asignación de recurso, el sistema despliega una
pantalla sobre la cual el usuario podrá diligenciar
los datos de la asignación.
21. El usuario ingresa los datos de entrada de la

asignación.
22. Si el usuario cuenta con los permisos

adecuados, el sistema crea y almacena un nuevo
registro en el sistema en el cual se asocia un
recurso a un funcionario o dependencia. Además
de lo anterior, el registro debe contener los datos
propios de la asignación (Fechas, tiempos,
lugares).

modificación de la asignación de un recurso, el
sistema despliega una pantalla sobre la cual el
usuario podrá diligenciar los datos de la
modificación.
21. El usuario ingresa a la pantalla los datos de

entrada para buscar el recurso asignado que se
quiere cambiar en su asignación (Tipo y código
del recurso).

24. El sistema busca un registro de asignación, en

el cual el código y tipo del recurso coinciden con
los suministrados por el usuario. Una vez
encontrado el registro, despliega sus datos en una
pantalla.
25. El usuario modifica los datos de

asignación. Ejecuta la opción de
almacenamiento de la modificación realizada.
26. El sistema, si el usuario tiene los permisos

apropiados, almacena las modificaciones.
27. Si el usuario selecciona la opción de quitar

una asignación a un recurso, el sistema despliega
una pantalla sobre la cual el usuario podrá
diligenciar los datos de la operación.
28. El usuario ingresa los datos del recurso al

cual le quiere quitar la asignación (Tipo y
código del recurso).
29. El sistema, si el usuario tiene los permisos

apropiados, elimina el registro de asignación.

Líneas 4, 16, 19, 22, 26, 29: Si el usuario no tiene los permisos adecuados, para ejecución
de la operación, el sistema cancela la operación y despliega un mensaje donde se indica la
situación.
Línea 4: Si existe otro recurso con mismo tipo y código, se cancela la operación y se
despliega un mensaje que indica de la situación.
Línea 22: Debe existir previamente en el sistema la información del recurso y del
funcionario o dependencia que lo toma. De no ser así se genera un mensaje de error y se
cancela la operación.
Línea 27: Si no existe un registro de asignación, que corresponda al recurso y a la
identificación del funcionario o entidad a la cual se supone fue asignado, se cancela
operación y se despliega un mensaje que indica de la situación.
7. Precondiciones
Para las operaciones de asignación, eliminación, consulta o modificación de la asignación
de recursos, debe existir previamente en el sistema la información correspondiente al
recurso y al funcionario o dependencia a la cual se le va asignar.

Para las operaciones de modificación, eliminación o consulta de un recurso, debe existir de

forma previa, los datos del recurso en el sistema.
Para las operaciones de ingreso, se deben suministrar todos los datos de las entradas.
8. Post Condiciones
De acuerdo con el tipo de operación, se hace el ingreso, consulta, actualización ó
eliminación de recursos. De acuerdo con el tipo de operación, se hace la asignación de un
recurso a una persona o dependencia, la modificación de la asignación o su eliminación.
Ninguno.


SERVIDOR PGN

AdministrarServidorPGN.doc

12/07/05 2.0 Versión Inicial. Corresponde a la D. Rubiano
incorporación de las observaciones
realizadas por la PGN sobre el caso de uso
“AdministrarFuncionariosEquipos”.

Caso de uso Administrar Servidor PGN

El presente caso de uso tiene como objetivo permitir sobre el sistema SIAM, definir y
modificar la disponibilidad de un servidor PGN, además de la consulta de los datos
tomados del Sistema de Nómina.
La disponibilidad de un servidor PGN, está dada en términos de porcentajes de tiempo
diario. En caso de no ocupar el 100%, se debe indicar el tiempo no disponible en que
actividades lo ocupará.

2.1 Iteración
0.
2.2 Prioridad
Media.
2.3 Complejidad
Baja.
• Administrador SIAM, para todos los casos de entrada que se definen.
• Usuario SIMIP, para el caso de consulta.
4. Entradas
Se debe proporcionar:
Consulta:
Identificación del funcionario.

Modificación de la disponibilidad:
• Porcentaje de tiempo que estará disponible.
• Razones/actividades en las que gastará el tiempo no disponible.
5. Salidas
Consulta:
Se despliega la información básica de la persona, por ejemplo: nombre, número de
identificación, dirección y teléfono, además de cargo, disponibilidad, dependencia,
habilidades y conocimientos.
Modificación de la disponibilidad:
Registro modificado en cuanto al valor de la disponibilidad.
6. Flujo de Eventos
6.1 Flujo Básico

Consulta o modificación de los datos de un
servidor PGN.
2. Si la opción corresponde a consulta, el sistema
desplegará una pantalla para ingreso de datos de
la entrada.
3. El usuario del sistema ingresa la
identificación del servidor PGN.
4. El sistema despliega una pantalla con todos los
datos de salida del servidor PGN.
5. Si la opción corresponde a la modificación de
la disponibilidad del servidor PGN y si el usuario
tiene los permisos apropiados para la ejecución
de la operación, se ejecutan las líneas 2, 3 y 4 del
presente caso de uso, con la opción de que el


valor de la disponibilidad desplegado en la
pantalla pueda ser modificado.
6. El usuario ingresa el nuevo valor de
disponibilidad.
7. El sistema actualiza el registro asociado a la
información del servidor PGN y lo almacena.

Línea 6: Si el usuario ingresa un valor fuera del rango permitido, se un mensaje de error
indicando la situación. La operación no continua hasta tanto el valor suministrado no sea el
apropiado.
7. Precondiciones
Se deben proporcionar todos los datos de entrada.
La información de los servidores se carga previamente del sistema de recursos humanos de
PGN, mediante el caso de uso SIAM_INT_1_Cargar Datos Servidores PGN.
8. Post Condiciones
sistema, con respecto a un registro que está asociado a los datos de un servidor PGN:
• Consulta: Se muestra en una pantalla los datos de un servidor PGN.
• Modificación: Se modifica un registro de un servidor PGN.
• Verificar los datos sugeridos para los registros que definen un servidor PGN.
Definir para estos datos sus tipos, sus longitudes y obligatoriedad.
.


OFICIOS

AdministrarOficios.doc

05/07/05 2.0 Versión Inicial Disney Rubiano – C.Díaz
27/07/05 3.0 Incorporación de las observaciones de la D. Rubiano.
PGN.

Caso de Uso Administrar Oficios

Tiene como objetivo permitir la administración de oficios, estableciendo sobre los mismos
los diferentes estados por los que puede pasar. La implantación de este caso de uso debe
permitir control permanente sobre los diferentes oficios que se generen.

2.1 Iteración
0.
2.2 Prioridad
Media.
2.3 Complejidad
Media.
Servidor PGN.
4. Entradas
Consulta:
La consulta sobre un listado de oficios generados, se puede hacer sobre una combinación de
los siguientes datos (El usuario no necesariamente debe diligenciarlos todos):
• Identificación del servidor PGN.
• Código del oficio.
• Código de la solicitud a la cual se le han generado oficios.

• Código del caso a la cual se le han generado oficios.
• Rango de fechas de la generación del oficio.
• Código del documento respuesta al oficio.
• Estado.
• Indicador de cambio automático a estado “Reiterado” (Si o No?): Cuando se

requiere que los registros consultados pasen a estado “Reiterado” y se creen copias
de los mismos con estado “Pendiente”, el valor asignado debe ser “si”, de lo
contrario deberá mantener el valor de por defecto, que es “No”.
Modificación:
En el caso de una modificación del estado de un oficio, es obligatorio diligenciar los
siguientes datos:
• Identificación del servidor PGN.
• Código del oficio.
• Observación.
• Nuevo estado.
• Código del documento respuesta al oficio1.
• Respuesta (Para ser incorporada en el oficio)
5. Salidas
Consulta:
Se despliegan los datos de un oficio:
Tipo de plantilla, identificador y nombre del servidor PGN que lo generó, solicitud o caso
al cual está asociado, historia de los estados (fecha y nombre del estado), observación,
código del documento respuesta del oficio, fecha de creación.
Adicionalmente se visualiza el oficio con los valores propios, asociados a la solicitud o
caso.
1
Por defecto, cuando se crea un oficio, este toma el estado de “Pendiente”, en señal de que fue generado y no tiene
respuesta.

Modificación:
Se modifica el registro de estados del oficio, con el estado suministrado por el usuario ó
generado de forma automática por el sistema, y si es el caso se incorpora la respuesta. Se
hace un registro histórico de cada estado por el cual atraviesa el oficio.
6. Flujo de Eventos
6.1 Flujo Básico

del sistema SIAM, selecciona una opción de
administración de oficios (Consulta ó
modificación).
2. Si es consulta, el sistema despliega una

pantalla para que el usuario registre los datos de
entrada.
3. El usuario diligencia los datos de entrada

para consulta.
4. A partir de los datos de entrada, el sistema

despliega un listado de oficios, separados por
solicitud, caso y servidor PGN que genera. Por
cada oficio, se visualiza el estado y la fecha de
creación.
5. El usuario selecciona del listado el oficio

que requiere consultar. Si lo requiere, el
usuario también puede imprimir el listado
generado en el momento.
6. El sistema despliega una pantalla con los datos

de salida para el caso de consulta.
7. Si se trata de una modificación de estado y si

el usuario tiene los permisos apropiados para
modificación, se ejecutan las líneas 3, 4, 5 y 6.
8. El usuario ingresa los datos asociados a las

entradas para modificación. Ejecuta la opción
de guardado de la modificación. En caso de
haber recibido una respuesta al oficio, esta es
ingresada por el usuario para ser incorporada al
oficio. El estado que se diligencia en este caso
de respuesta es “Atendido.
9. El sistema altera el registro asociado al oficio

seleccionado, incorporando el nuevo estado y
respuesta (cuando existe respuesta). Cuando se
recibe respuesta, el sistema debe identificar la


situación y pasar de forma automática el registro
asociado al oficio a estado “Atendido”.
10. Si el valor del “indicador de cambio

automático a estado “Reiterado”” es “si”, en la
línea 7 (Ver en la línea 3), no se ejecuta las líneas
4, 5 y 6. Entonces, los registros de los oficios
asociados a las entradas pasan de forma
automática a estado “Reiterado”.Se almacenan
los cambios efectuados sobre los registros
implicados en la operación. Para el caso de
registros en estado “Reiterado”, se crean copias
de los mismos con estado “Pendiente”.

Línea 7: Si el usuario no tiene los permisos apropiados, se genera un mensaje que indica de
la situación y se cancela la situación.
Línea 10: Si se selecciona un estado no apropiado, se genera un mensaje de error y se evita
la ejecución de la operación hasta tanto no se haga la selección correcta de estado. Se debe
tener en cuenta que el estado por defecto de un oficio es “Pendiente”. Cuando se recibe la
respuesta al oficio, el estado debe cambiar a “Atendido”, indicando en la observación la
respuesta dada y en código de documento de respuesta, el código del documento que
soporta la respuesta2. Cuando ha pasado cierto tiempo y aún no se ha recibido respuesta, se
debe cambiar el oficio a estado “Reiterado”, creando otro con estado “Pendiente”. Para
este último caso el sistema debe poder establecer un vínculo entre el nuevo oficio y el
anterior.
7. Precondiciones
Se debe tener en cuenta que los oficios o comunicaciones se elaboran por un usuario en el
curso de un caso. Cuando el usuario desea la generación del oficio, el sistema selecciona de
forma automática la plantilla asociada al mismo y pone allí los datos del caso que
corresponden al formato preestablecido en la plantilla (Estos datos los toma del medio de
almacenamiento y son los que están asociados al caso). El usuario en ese momento puede
ingresar sobre el formato, los datos que no son generados de forma automática. Una vez se
diligencian los datos del formato, se crea un registro y se almacena en el almacenamiento,
el registro por defecto es guardado con estado “Pendiente”.
2
Cuando se recibe un documento de respuesta a un oficio, se sugiere marcar el documento con un código que es generado
de forma automática por el sistema. El código es colocado en el documento y en la observación del sistema se coloca la
referencia, remitente, descripción y resumen del contenido del documento recibido.

8. Post Condiciones
• Para consulta: Se despliega una pantalla con los datos de un oficio.
• Para modificación: Se actualiza un registro de un oficio con los datos de

modificación del estado y si es el caso de respuesta.
9.1 Validar que quien modifica el estado se quien generó el oficio

Se debe garantizar que un usuario sólo modifique los estados de los oficios generados por
él. Una sugerencia a este caso es que se haga por medio de loguin y password la
habilitación de la opción de modificación.
9.2 Estructuras de datos

Verificar los datos sugeridos para los registros que definen los oficios. Sus estructuras,
longitudes y tipos. Identificar las estructuras de datos que permitirán el almacenamiento de
estos registros.


POLÍTICAS Y PROYECTOS

AdministrarPolíticasProyectos.doc

11/07/05 2.0 Se incluye este requerimiento para el C.Díaz
mantenimiento de políticas y proyectos
(que van a ser utilizados en SIMIP)

Caso de Uso Administrar Políticas y Proyectos

El presente caso de uso tiene como objetivo permitir sobre el sistema SIAM, administrar la
información de las políticas y los proyectos de la institución.
Esta administración incluye las opciones de adición, modificación, consulta y eliminación.
Clasificación del Caso de Uso.
• Política es una clasificación por línea de acción, las cuales se encuentran definidas
en el mapa estratégico de la entidad.
• Un Proyecto se crea para el logro de un objetivo específico. Es un conjunto de

actividades estratégicas que se deben cumplir para el logro de las políticas de la
entidad, por tal razón estar adscrito a una política. La asignación de
solicitudes/casos a proyectos puede ayudar a medir avances y logros de proyectos
al interior de la PGN.
1.1 Iteración
0.
1.2 Prioridad
Baja.
1.3 Complejidad
Baja.
Servidor PGN.
3. Entradas
Consulta:
Se debe proporcionar: política y/o proyecto.

Ingreso:
Para ingreso de datos, se necesitaría la información concerniente a: políticas y proyectos.
Actualización:
El código de la política o proyecto para hacer la búsqueda del correspondiente registro
almacenado en el sistema. Una vez se encuentra el registro, se podría hacer actualización de
los datos.
Eliminación:
El código de la política o proyecto.
4. Salidas
Consulta:
Se despliegan los datos de un registro almacenado en el sistema, asociado a la política o
proyecto seleccionado.
Ingreso:
Se crea y almacena un nuevo registro con los datos de la política o proyecto tales como
fecha, descripción, nombre, código (si es del caso), etc.
Actualización:
Se modifican algunos de los datos de un registro de una política o proyecto.
Eliminación:
Esta opción se permite, sólo para el administrador de sistemas, cuando la política no ha sido
relacionada en SIMIP. Si ya se ha utilizado en SIMIP lo que se hace es inactivar el registro
para indicar que no esta vigente.
5. Flujo de Eventos
5.1 Flujo Básico

Ingreso, consulta, actualización o eliminación
de datos.
2. Si la opción corresponde a ingreso, el sistema
desplegará una pantalla para ingreso de datos. La
pantalla sólo se desplegará siempre y cuando el
usuario tenga permisos para ejecutar la opción


seleccionada.
3. El usuario del sistema ingresa los datos de la
política o del proyecto.
4. Crea un registro con los datos suministrados en
la pantalla y lo almacena.
5. Si la opción corresponde a consulta de datos,
el sistema despliega una pantalla en la cual
pedirá el código de la política o proyecto al cual
se le quiere hacer la consulta de los datos.
6. El usuario ingresa el código de la política o
proyecto.
7. El sistema busca el registro asociado a la
política o proyecto y despliega los datos que los
componen y que son requeridos en la consulta. El
sistema identifica los permisos del usuario. Si el
usuario tiene permisos para actualizar, permite la
actualización y entonces se ejecuta lo previsto en
la línea 8.
8. Si la opción a actualización de datos, el
sistema desplegará una pantalla para que el
usuario registre el código de la política o
proyecto.
proyecto para que el sistema despliegue los
datos del mismo.
10. A partir del código de la política o proyecto,
el sistema busca un registro. Una vez encontrado
el registro, despliega los correspondiente datos en
una pantalla.
11. El usuario modifica, elimina o completa los
correspondientes datos.
12. Si la opción es una eliminación, el sistema
desplegará una pantalla para que el usuario
registre el código de la política o proyecto.
proyecto para que el sistema busque el
correspondiente registro y lo elimine.
14. El sistema busca un registro que contenga un
dato, cuyo valor corresponde al código de la
política o proyecto. Una vez encuentra el
registro, lo elimina del medio de
almacenamiento.


Línea 2: Si el código de la política o proyecto ya existe, el sistema deberá desplegar un
mensaje que le indique al usuario la situación. La operación de ingreso es cancelada.
Líneas 7, 10 y 14: Si no se encuentra ningún registro que coincida en el número de
identificación con el suministrado por el usuario, el sistema deberá desplegar un mensaje
que indique de lo sucedido. La operación de ingreso es cancelada.
6. Precondiciones
Se deben proporcionar todos los datos de entrada obligatorios, de acuerdo al tipo de
operación (Consulta, ingreso, Actualización y eliminación).
7. Post Condiciones
sistema, con respecto a un registro que está asociado a los datos de una política/proyecto:
• Consulta: Se muestra en una pantalla los datos de una política o proyecto.
• Ingreso: Se crea y almacena en el sistema un nuevo registro con los datos

suministrados.
• Actualización: Se modifican los datos de un registro ya almacenado en el sistema, que

corresponde a una política o proyecto específico.
• Eliminación: Se elimina del medio de almacenamiento del sistema un registro que

contiene los datos de la política o proyecto si el registro no se ha utilizado en SIMIP.
En análisis y diseño definir:
• Si las políticas y proyectos van a tener un código asociado (para facilitar búsquedas
en el sistema)
• Cuál es la información asociada que se va a recolectar.

Los procedimientos asociados a las acciones sobre políticas y proyectos
(ingreso/modificación/eliminación), para que cuando se afecte una política/proyecto, los
casos que ya han sido creados (cerrados y no cerrados) y que pueden tener relación con
dicha política/proyecto puedan ser afectados en su asociación con la misma. Esto con fines
estadísticos.
Respecto al anterior punto, se debe analizar la viabilidad de poder implementarlo de forma
automática.


INVENTARIO ENTIDADES

AdministrarInventarioEntidades.doc

mantenimiento de las Entidades que tienen
relación con la PGN y que serán
referenciadas en SIMIP.
28/07/05 3.0 Se incluye las observaciones formuladas D. Rubiano
por la PGN, respecto a la generación del
código de de barras.

Caso de Uso Administrar Inventario Entidades

información de las entidades con las que se relaciona la PGN.
Esta administración incluye las opciones de adición, modificación, consulta e inactivación.
Con la implementación del presente caso de uso, el usuario podrá de forma progresiva ir
agregando/modificando/eliminado datos de una entidad.
1.1 Iteración
0.
1.2 Prioridad
Media.
1.3 Complejidad
Baja.
Procurador Delegado.
3. Entradas
Consulta:
Se debe proporcionar el código de la entidad.
Ingreso:

Para ingreso de datos, se necesitaría la información concerniente a entidad, por ejemplo:

Código asociado, nombre de la entidad, razón de la entidad, competencias de las entidad,
tipo de información a intercambiar con dicha entidad, nombre de la persona contacto en esa
entidad, dirección electrónica de la persona contacto, ubicación, dirección, teléfono, fax,
dirección. Para este punto se debe tener en cuenta que existen algunos datos básicos, tales
como el código, el nombre y la dirección electrónica de la persona contacto en la entidad,
los demás datos pueden ser agregados en momentos diferentes al del ingreso.
Actualización:
El código de la entidad para hacer la búsqueda del correspondiente registro almacenado en
el sistema. Una vez se encuentra el registro, se podría hacer actualización de los datos. Los
datos son los que se mencionan en el anterior punto. Se debe tener en cuenta que el usuario
debe contar con un opción de actualización que le permita modificar los datos de las
entidades en momentos diferentes. Una actualización de datos, puede significar el cambio
de valor de un dato por otro valor (por ejemplo: la dirección electrónica de la persona
contacto), el borrado de un valor de un dato (por ejemplo: Dejar en blanco el número de fax
de la entidad), la complementación de un valor de una dato (por ejemplo: agregar un
número de teléfono, agregar información sobre las competencias de la entidad), la
simplificación de un valor de un dato (por ejemplo: si existen dos números de fax, quitar
uno).
Inactivación:
El código de la entidad, fecha de la inactivación, causa, responsable.
4. Salidas
Consulta:
Se despliegan los valores a los datos suministrados en el ingreso.
Ingreso:
Se crea y almacena un nuevo registro con los datos de la entidad.
Actualización:
Se modifican algunos de los datos de un registro de una entidad.
Inactivación:

Se marca el registro asociado a la entidad como inactivado. Se crea un registro donde se

almacenan los datos de la inactivación.
Nota: Es necesario llevar un registro histórico de las acciones que se lleven a cabo en
referencia a las operaciones sobre los datos de las entidades.
5. Flujo de Eventos
5.1 Flujo Básico

Ingreso, consulta, actualización o inactivación
de datos.
seleccionada.
3. El usuario del sistema ingresa los datos de
entrada de la entidad.
la pantalla y lo almacena.
pedirá el código de la entidad a la cual se le
quiere hacer la consulta de los datos. Puede ser
que el sistema despliegue una lista de las
entidades creadas hasta el momento.
6. El usuario ingresa el código de la entidad .
Dado el caso, selecciona la dependencia de la
lista para que el sistema tome el respectivo
código.
7. El sistema busca el registro asociado al código
de entidad suministrado y despliega los datos que
los componen y que son requeridos en la
consulta. El sistema identifica los permisos del
usuario.
8. Si la opción es la de actualización de datos se
ejecutan las líneas 5, 6 y 7. La pantalla se
despliega con opción de modificación sobre los
datos desplegados.


9. El usuario cambia, modifica, elimina o
complementa los correspondientes datos.
Ejecuta la opción de guardar las
modificaciones.
10. El sistema actualiza y almacena los
correspondientes registros.
11. Si la opción es una inactivación, se ejecutan
las líneas 5, 6 y 7
dato, cuyo valor corresponde al número de
identificación de la competencia. Una vez
encuentra el registro, lo marca como inactivo.

Línea 2: Si el código de la entidad ya existe, el sistema deberá desplegar un mensaje que le
indique al usuario la situación. La operación de ingreso es cancelada.
Líneas 7: Si no se encuentra ningún registro que coincida en código suministrado por el
usuario, el sistema deberá desplegar un mensaje que indique de lo sucedido. La operación
de ingreso es cancelada.
6. Precondiciones
operación (Consulta, ingreso, Actualización e inactivación).
7. Post Condiciones
sistema, con respecto a un registro que está asociado a los datos de un funcionario:
• Consulta: Se muestra en una pantalla los datos de una entidad.

suministrados.

corresponde a una entidad.
• Inactivación: Se marca en el medio de almacenamiento, como inactivo un registro de

una dependencia. Se crea un registro con los datos de la inactivación.

Definir cual es la información asociada a la entidad que se va a recolectar. Por cada dato, se
debe identificar su tipo, nombre exacto, longitud y obligatoriedad.


COMPETENCIAS X DEPENDENCIA

AdministrarCompetenciasxDependencia v3.0.doc

mantenimiento de competencias x
dependencias (que van a ser utilizados en
SIMIP para asignar una solicitud a una
dependencia determinada)
26/07/05 3.0 Se incluyeron las observaciones de la PGN D. Rubiano
en torno a las Dependencias virtuales. Y a
la incorporación de los conceptos de
Ubicación, Nivel y de competencias,
teniendo en cuenta que estas últimas están
compuestas por Temas y estos a su vez por
normas.

Caso de Uso Administrar Competencias x

Dependencia
información de las competencias de cada Dependencia. La base para este requerimiento
será la ley (decreto 262).
Esta administración incluye las opciones de adición, modificación, consulta e inactivación
de la información asociada a una Dependencia.
En este punto se debe tener en cuenta que existen las Dependencias Organizacionales y las
Virtuales. Las primeras corresponden a las que tienen un reconocimiento organizacional
formal dentro de la estructura de la PGN (Cuentan con una oficina - una ubicación física) y
las segundas son producto de la conformación de comisiones y comités con servidores PGN
que pertenecen a las Dependencia Organizacionales.
Mientras una Dependencia Virtual es adscrita a una Dependencia Organizacional de la
PGN, una Dependencia Organizacional pertenece a un nivel (Nacional, Regional, Distrital
o Provincial) y en el mismo a una ubicación (Precisa los lugares sobre los cuales tiene
competencia la Dependencia, en algunos casos se debe precisar la sede de la Dependencia).
A una Dependencia (Organizacional/Virtual) se le debe asignar competencias, sabiendo que
una competencia se compone de temas y esta a su vez por normas. Una competencia puede
ser asignada a más de una Dependencia.
Procurador Delegado.
3. Entradas
Consulta:
Se debe proporcionar el código de la dependencia.
Ingreso:
Si es una Dependencia Organizacional: Se debe proporcionar el nivel y la ubicación,
además de los códigos de las competencias y para cada una de estas los temas, y sobre cada
tema las respectivas normas.

Si es una Dependencia Virtual: Se debe proporcionar, el código de la dependencia a la cual

estará adscrita, el nombre de la nueva dependencia, fecha de creación, el objetivo de su
creación, los servidores PGN que la conforman (cada uno con su respectivo rol e
identificación) y los códigos de las competencias asociadas, y para cada una de estas los
temas, y sobre cada tema las respectivas normas.
Actualización:
Dado el código de la dependencia (Sea Organizacional o Virtual), se deben proporcionar las
mismas entradas que para el caso anterior. Se debe tener en cuenta que con respecto a las
competencias, independientemente del tipo de dependencia, estas pueden ser adicionadas,
inactivadas o cambiadas por otras. En referencia a las Dependencias Virtuales, se debe
poder modificar la información relacionada con la dependencia a la cual está adscrita, el
objetivo de su creación y los datos de los servidores PGN que la conforman. Se pueden
adicionar, inactivar o cambiar por otros, los servidores PGN de una Dependencia Virtual.
Inactivación:
En este caso la inactivación aplica directamente sobre una Dependencia Virtual. En este
punto se deben suministrar los siguientes datos: Responsable, fecha y causa de la
inactivación.
4. Salidas
Consulta:
Se despliegan los datos de un registro almacenado en el sistema, asociado a la dependencia
seleccionada.
En el despliegue se pueden observar los siguientes datos:
Dependencia Organizacional: Nombre, código, nivel, ubicación, competencias asociadas.
Por cada Competencia, los temas y por cada uno de estos últimos las normas que lo
componen.
Dependencia Virtual: Código y nombre de la dependencia a la cual está adscrita, nombre y
código de la dependencia consultada, fecha y objeto de su creación, además de los
servidores PGN que la conforman. Por cada servidor PGN, se debe mostrar el nombre, la
identificación, el rol que desempeña en la dependencia, nombre de Dependecia
Organizacional a la cual pertenece y cargo en la PGN. En caso de estar asociado a
Dependencias Virtuales, se debe mostrar el nombre de estas y el rol que allí desempeña.
Ingreso:

Se crea y almacena un nuevo registro con los datos de la dependencia, teniendo en cuenta
que si se trata de una virtual se deben incorporar las asociaciones con servidores PGN que
la conforman y los datos de la dependencia a la cual queda adscrita, además del nombre de
la dependencia y la fecha y objetivo de su creación. En el caso de una Dependencia
Oganizacional, se guardan en el registro las relaciones con las competencia asignadas y los
datos referentes al nivel y ubicación.
Actualización:
Se modifican algunos de los datos de un registro de una dependencia.
Inactivación:
Se marca como inactivo el registro de una Dependencia Virtual.
Nota: Es necesario llevar un registro histórico de las acciones que se lleven a cabo en
referencia a las operaciones sobre los datos de las dependencias.
5. Flujo de Eventos
5.1 Flujo Básico

de datos de una dependencia.
seleccionada.
3. El usuario del sistema ingresa los datos de
entrada de la dependencia (Se tienen en cuenta
las diferencias entre una Dependencia
Organizacional y una Virtual).
4. Si se trata de una Dependencia Virtual, el
sistema desplegará una pantalla adicional con
una lista de servidores PGN. Por cada servidor
PGN, se visualiza, el nombre, la identificación, el
cargo en la PGN y la Dependencia
Organizacional a la cual pertenece. En caso de


pertenecer a Dependencias Virtuales, se debe
mostrar el nombre de estas y el cargo que allí
desempeña.
5. Para la conformación de una Dependencia
Virtual, el usuario señala en la pantalla de la
línea 4 los servidores PGN que quiere que
conformen la nueva Dependencia Virtual. La
señalización sobre los servidores será particular
a la acción de este sobre la Dependencia. Si es
adición, se colocará una señal especial que
indique tal acción, en caso de inactivación, la
señal deberá ser diferente a la anterior.
las pantallas de las líneas 2 y 4 y lo almacena.
pedirá el código de la dependencia al cual se le
quiere hacer la consulta de los datos. Puede ser
que el sistema despliegue una lista de las
dependencias creadas hasta el momento.
8. El usuario ingresa el código de la
dependencia. Dado el caso, selecciona la
dependencia de la lista para que el sistema
tome el respectivo código.
de dependencia suministrado y despliega los
datos que los componen y que son requeridos en
la consulta. El sistema identifica los permisos del
usuario.
10. Si la opción es la de actualización de datos
se ejecutan las líneas 7, 8 y 9. La pantalla se
despliega con opción de modificación sobre los
datos desplegados.
correspondientes datos.
12. De tratarse de una modificación sobre los
datos de los servidores PGN que conforman una
Dependencia Virtual, se desarrollará lo descrito
en las líneas 4 y 5.
13. El usuario ejecuta la acción de
almacenamiento de la actualización.
14. El sistema modifica y almacena los
correspondientes registros.
15. Si la opción es una inactivación, se ejecutan


las líneas 7, 8 y 9.
dato, cuyo valor corresponde al número de
identificación de la dependencia. Una vez
encuentra el registro, lo marca como inactivo.

Línea 2: Si la dependencia ya existe, el sistema deberá desplegar un mensaje que le indique
al usuario la situación. La operación de ingreso es cancelada.
Líneas 9: Si no se encuentra ningún registro que coincida en código suministrado por el
de ingreso es cancelada.
Línea 15: Si el código no es el de una Dependencia Virtual, no se permite la ejecución de la
operación y se muestra un mensaje de error que indique de la situación al usuario.
6. Precondiciones
operación (Consulta, ingreso, Actualización e inactivavión). Los datos concernientes a los
servidores PGN, las competencias, los temas y las normas deben estar ya almacenados.
7. Post Condiciones
sistema, con respecto a un registro que está asociado a los datos de un funcionario:
• Consulta: Se muestra en una pantalla los datos de una dependencia.

suministrados.

corresponde a una dependencia.
• Inactivación: Se marca en el medio de almacenamiento, como inactivo un registro de

una Dependencia Virtual. Se crea un registro con los datos de la inactivación.

Definir los valores que se almacenarán en los medios de almacenamiento referentes a las
competencias, temas y normas.


ETAPAS, ACTIVIDADES,
ACTUACIONES E INFORMACIÓN
ASOCIADA

AdministrarEtapasActividades v2.0.doc

mantenimiento de etapas, actividades,
actuaciones/decisiones y su información
asociada (que van a ser utilizados en SIMIP
en el requerimiento de Registrar
Actividades y Actuaciones/Decisiones)
26/07/05 3.0 Se incorporaron las observaciones D. Rubiano.
formuladas por la PGN.

Caso de Uso Administrar Etapas, Actividades,

Actuaciones e Información Asociada
Tiene como objetivo permitir registrar las etapas, actividades y actuaciones y su
información asociada como documentos, términos y procedimientos, entre otros.
Los datos que se registran en el presente caso de uso, son los que usará el usuario para la
definición de rutas y actividades en la implementación del caso de uso “Definir Ruta y plan
de actividades” del sistema SIMIP.
Los datos que se deben manejar son:
Por cada Áea Misional:

- Áea Misional.
- Código del Área Misional.
- Etapas.
Por cada Etapa:

- Código de Etapa
- Nombre de la Etapa
- Actividades.
- Actuaciones.
- La(s) etapa(s) que le preceden
Por cada Actividad/Actuación

- Código de la Actividad o Actuación (Decisión)
- Nombre de la Actividad o Actuación (Decisión)
- Documentos Asociados
- Términos Asociados (si hay términos se debe registrar en número de días)

- Procedimientos asociados.
- Información para cálculo de indicadores (peso o valor).
- Actores (en caso de que se restrinja el actor a una actividad determinada)
- La(s) actividad(es)/actuación(es) que le preceden.
- Flags.
Por cada Procedimiento:

- Código del procedimiento.
- Nombre del procedimiento.
- Descripción del procedimiento.
Por cada Documento:

- Código del documento.
- Nombre del documento.
- Descripción del documento.
Por cada Flag:

- Código del flan.
- Nombre del flan.
- Descripción del glag.
A continuación se describe brevemente cada uno de los anteriores datos:

Área Misional:
Puede ser Disciplinario, Preventivo, Intervención y Jurídica.
Etapa:
Asociado a fases. Ejemplo: Indagación Preliminar, Investigación Disciplinaria.

Actividades / Actuaciones :
Asociado a tareas particulares. Ejemplos de Actividades son: Para Disciplinario: las
declaraciones de testigos, las declaraciones de las víctimas, las visitas especiales, los
peritazgos, la exposición libre de los disciplinados, etc. Para Intervención: Participación en
la Audiencia de Garantías. Para Preventivo: Las visitas, las entrevistas, etc.
Vale la pena aclarar que hay actividades relacionadas con el caso y otras con los actores del
caso. Si se escucha en exposición libre a la persona esta actividad se encuentra ligada con el
actor o si se hace una notificación, en cambio, si se hace una visita especial, esta actividad
esta ligada con el caso.
Hay actuaciones que implican decisiones, por ejemplo, abrir indagación preliminar, abrir
investigación disciplinaria, suspender al servidor investigado, decretar archivo, formular
cargos y dictar fallo. Al igual que para las actividades, hay algunas decisiones relacionadas
con el actor (ejemplo: sanción, la suspensión y el archivo) y otras relacionadas con el
proceso, como la nulidad.
Documentos Asociados:
Debe incluir la lista de documentos que se pueden generar en dicha actividad, cada
documento debe tener su plantilla correspondiente.
Términos Asociados:
Numero de días en los la actividad prescribe. En realidad el sistema debe manejar tres tipos
de términos: Primero, los términos para decidir el caso, segundo, los términos de las etapas
del caso y, tercero, los términos de ciertas actividades que de acuerdo a la ley se deben
realizar en un plazo determinado, como por ejemplo, presentar alegatos previos al fallo, que
de acuerdo a la ley 734, es de 5 días hábiles contados a partir del tercer día hábil exclusive,
de la notificación del auto que ordena el traslado a los sujetos procesales.
A estos términos se deben agregar las alertas tempranas para evitar la prescripción de los
casos o la preclusión de los términos sin actividad del servidor que tiene a su cargo el caso.
(Esta tarea se realiza en el caso de uso Alertar Vencimiento de Casos).
Flags:
Indican si la actividad afecta o no otra actividad. Estos flags se utilizarán para la realización
automática de ciertas tareas. Ejemplos de valores referentes a los flags son:
- Cambia etapa (SI/NO)

- Cierra caso (SI/NO)

- Tiene valor para cálculo de Indicadores (SI/NO)
- Flag que indique si la actividad o actuación es del proceso o de un actor.
Peso Indicadores:
Indica el peso o valor que se le da a cierta actividad para el cálculo del desempeño de las
actuaciones de los servidores.
Procedimientos:
Listado de pasos o procedimientos a seguir en una actividad o actuación. Ejemplo: Guía
Práctica de Pruebas.

2.1 Iteración
0.
2.2 Prioridad
Alta.
2.3 Complejidad
Baja.
Servidor PGN (administrador sistema).
4. Entradas
Consulta:
Se debe proporcionar el código del Área para conocer las etapas asociadas a la misma.
Respecto a la etapa, se debe proporcionar el código, para conocer las actividades y
actuaciones asociadas. Para conocer el detalle de una actuación/actividad, se debe
proporcionar el código de la misma.

Ingreso/Actualización/Eliminación (Administración):
El ingreso de información puede ser progresivo y no es necesario ingresar todos los datos
de todas las áreas. El ingreso de datos de cada área se puede hacer en tiempos diferentes
alternando con la actualización y la eliminación de datos. Lo mismo sucede para el ingreso
de los datos de las etapas y de las actividades y actuaciones. Esto quiere decir que para un
área se puede ingresar/cambiar por otro/eliminar un subgrupo de etapas y dentro de una
etapa se puede ingresar/cambiar por otro/eliminar un subgrupo de actividades y un
subgrupo de actuaciones. Se debe tener en cuenta que una vez se empieza el ingreso de los
datos de una actuación o actividad, los datos de la misma deben ser ingresados en su
totalidad, teniendo en cuenta que los datos referentes a los términos, procedimientos y
documentos pueden ser modificados y/o eliminados en cualquier momento.
Para ingreso de datos de un área, se necesitaría de los datos de las etapas que la componen,
para el ingreso de cada etapa, se necesita, además del código y el nombre, de los datos de
las actuaciones/actividades que la componen, Adicionalmente la información concerniente
a cada actividad y actuación es la siguiente:
- Código de la Actividad o Actuación (Decisión)
- Nombre de la Actividad o Actuación (Decisión)
- Documentos Asociados
- Términos Asociados (si hay términos se debe registrar en número de días)
- Procedimientos asociados.
- Información para cálculo de indicadores (peso o valor).
- Actores (en caso de que se restrinja el actor a una actividad determinada)
- Flags.
Para los procedimientos, documentos y flags, de becesita de información tal como, el
código, el nombre y la descripción de cada cual.
En cuanto a la actualización, a parte de ingresar/cambiar por otro/eliminar un subgrupo de
etapas a un área, de ingresar/cambiar por otro/eliminar un subgrupo de actividades y/o
actuaciones a una etapa, de ingresar/cambiar por otro/eliminar subgrupos de procedimientos
y documentos a una actividad y/o actuación, se debe poder modificar la información de
elementos, como: nombres, descripciones y datos adicionales como lo es la información
para el cálculo de indicadores y flags.
La eliminación, podrá ser realizada por el administrador del sistema, cuando el registro del
área/etapa/actividad/actuación/documento/procedimiento/ no ha sido utilizado en SIMIP.
En realidad una eliminación no produce un borrado del registro del medio de
almacenamiento sino una inactivación del mismo.

5. Salidas
Consulta:
Se despliegan los datos de los registros almacenados en el sistema, que corresponden a la
información de un área, las etapas que la componen, las actividades y/o actuaciones que
componen cada una de sus etapas, la información propia de cada actuación y/o actividad,
incluyendo la de los flags, documentos y procedimientos.
Ingreso/Actualización/Eliminación:
En el caso de ingreso de datos no existentes en el medio de almacenamiento, se crean y
almacenan nuevos registros. En el caso de actualización de datos tales como nombres y
descripciones, se mantienen los registros creados y almacenan en ellos los cambios
realizados. En al caso de eliminación, se mantiene el registro original, con una marca que
indica que está inactivo. En el caso de ingresar/actualizar/eliminar asociaciones tales como
área – etapa, etapa – actividad, etapa – actuación, actuación/actividad – documento,
actuación/actividad – documento – glag, actuación/actividad – documento,
actuación/actividad – procedimiento, se ingresan y/o eliminan los registros que almacenan
dichas asociaciones.
6. Flujo de Eventos
6.1 Flujo Básico

usuario del sistema SIAM, selecciona una
opción: Consulta, Administración.
2. Si la opción corresponde a una consulta, el
sistema despliega una pantalla, para hacer
selección del área sobre el cual se quiere realizar
dicha acción.
3. El usuario selecciona un área de la pantalla
desplegada.
4. El sistema obtiene el código del área selecciona
y realiza la búsqueda de los registros de datos
asociados a las etapas. La información de los
registros encontrados se despliega en una pantalla
con el ánimo de que el usuario conozca las etapas
asociadas al área seleccionada. Por cada etapa se
muestra a manera de resumen la información de
las actividades/actuaciones que componen cada
etapa.


5. El usuario selecciona una etapa de la
pantalla desplegada.
6. El sistema obtiene el código de la etapa
seleccionada (además del código del área) y
muestra en detalle toda la información de las
actividades/actuaciones asociadas a la misma.
7. Si la opción corresponde a la Administración de
la información
(Ingreso/Actualización/Eliminación), se repite las
líneas 2, 3 y 4. Si el usuario tiene los permisos
apropiados, las pantallas que se despliegan a partir
de este punto se despliegan con opción de
modificación de datos.
8. El usuario puede marcar en la pantalla
desplegada las etapas que desea eliminar. En
caso de querer ingresar etapas, debe
seleccionar la opción de consulta de etapas
creadas.
9. Si existen etapas marcadas como eliminación,
el sistema con el código de estas busca los
registros asociados y los inactiva. Cuando se trata
de un ingreso de etapas, el sistema busca los
registros de las etapas creadas y almacenadas y
los lista en una pantalla.
10. Si el usuario lo requiere, selecciona las
etapas que quiere adicionar al área.
11. El sistema asocia las etapas seleccionadas al
área seleccionada en la línea 3.
12. Si el usuario lo requiere, puede ingresar
nuevas etapas, con toda la información
pertinente (la información concerniente a las
actividades y actuaciones). Se debe tener en
cuenta en esta línea que el usuario puede
ingresar actuaciones/actividades ya creadas
para otras etapas (ver línea 15).
13. En caso de requerir de la modificación de
la información de una etapa, el usuario deberá
seleccionar la etapa y luego la opción de
consulta de datos de una etapa.
14. El sistema ejecuta la línea 6.
15. El usuario puede marcar en la pantalla
desplegada las actividades/actuaciones que
desea eliminar. En caso de querer ingresar
actividades/actuaciones, debe seleccionar la
opción de consulta de actividades/actuaciones


creadas.
16. El sistema asocia las actividades/actuaciones
seleccionadas a la correspondiente etapa del área
seleccionada en la línea 3.
17. Si el usuario lo requiere, selecciona las
actividades/actuaciones que quiere ingresar a
la etapa. En caso de necesitar de etapas no
registradas (nuevas), el usuario podrá crear
nuevas actividades/actuaciones, ingresando
por cada una la información correspondiente a
su nombre, documentos. Procedimienotos y
flags.
18. Si existen actividades/actuaciones marcadas
como eliminación, el sistema con el código de
estas busca los registros asociados y los inactiva.
Cuando se trata de un ingreso, el sistema busca
los registros de las actividades y actuaciones ya
creadas, y los lista en una pantalla, por cada una
indicará la etapa y área en la cual participa. En
caso de tratarse de nuevas
actividades/actuaciones, crea y almacena los
registros y asociaciones correspondientes con la
etapa y el área correspondiente.
19. En caso de requerir de la modificación de
la información de una actividad/actuación, el
usuario deberá seleccionar la
actividad/actuación y luego la opción de
consulta de datos de una actividad/actuación.
17. El sistema obtiene el código de la
actividad/actuación y busca el registro asociado y
despliega la información en una pantalla. La
información se despliega con opción de
modificación.
18. Según sea lo requerido, el usuario puede
modificar los datos de nombre de la
actividad/actuación, adicionar, eliminar
modificar los datos correspondientes a los
documentos, flags y procedimientos de la
actividad/actuación.

Línea 4: Si el código del área seleccionada no existe, el sistema deberá desplegar un
mensaje que le indique al usuario la situación. La operación de consulta es cancelada.

Línea 6: Si el código de la etapa seleccionada no existe, el sistema deberá desplegar un

mensaje que le indique al usuario la situación. La operación de consulta es cancelada.
Línea 11: Si se trata de ingresar etapas que ya existen en el sistema para el área dada, se
genera un mensaje de error que indica la situación y se cancela la operación.
Línea 16: Si se trata de ingresar actividades/actuaciones que ya existen en el sistema para la
etapa-área dadas, se genera un mensaje de error que indica la situación y se cancela la
operación.
En general: en caso de ingresar un nuevo registro al sistema, verificar que el contenido del
mimo no exista ya en el medio de almacenamiento. En caso de proporcionar un código de
algún elemento dato (área/etapa/actividad/actuación, documento/procedimiento/flan), se
debe verificar la existencia previa del registro asociado en el medio de almacenamiento. En
caso de que la verificaciones de existencia no sean exitosas, se debe generar un mensaje de
error indicando la situación y la correspondiente operación se cancela.
7. Precondiciones
Para el caso de la consulta: Para poder realizar las respectivas consultas, se debe poder
contar con el respectivo código de los datos para hacer la búsqueda del registro asociado en
el medio de almacenamiento del sistema. Se debe contar con el código del área para poder
consultar sus datos, en el caso de una etapa, se debe contar con el código de la misma para
poder hacer la consulta, en el caso de una etapa o actividad, se debe contar con el código de
ésta para poder ejecutar la consulta, y sobre esta, se deben conocer los código de los
documentos/procedimientos asociados, para poder consultar los datos de estos. Los
registros deben existir en la base de datos para poder realizar la respectiva consulta. En el
caso de los registros de referencia tales como áreas,
Para el caso de ingreso/actualización/eliminación:
La información de las áreas, tipos de términos debe estar creada y almacenada, y las
etapas, actividades y actuaciones se van creando según se requiera. Se debe tener en cuenta
que una etapa puede ser creada para más de un área y en el momento de establecer la
asociación Área-Etapa, si esta última no existe se crea y almacena. Una actividad y/o
actuación puede estar asociada a más de una etapa y en el momento de establecer la
asociación etapa – actividad/actuación, si esta última no existe, se crea y almacena,
eventualmente respecto a las actividades/actuaciones al estar involucradas en más de una
etapa, lo que cambiaría son los datos referentes a documentación y términos de una etapa a
la otra. Lo mismo sucede con los documentos y los procedimientos, un
documento/procedimiento puede estar asociado a más de una actuación y/o actividad. En el
momento de asociar un documento/procedimiento a una actividad/actuación se debe
verificar su existencia, en caso de no existir, se crea y establece la respectiva asociación.
8. Post Condiciones
sistema, con respecto a un registro que está asociado a los datos de una etapa o actividad.

Revisar los datos definidos para las entradas y si es necesario complementarlos. Definir en
tiempo de diseño los tipos y las longitudes de los mismos, además de cuáles pueden ser o
no obligatorios en el momento de ejecutar una acción de consulta, actualización,
eliminación ingreso.

CASO DE USO CARGAR DATOS

SERVIDORES PGN

SIAM_INT_1CargarDatosServidoresPGN.doc

13/07/05 2.0 Versión Inicial. Corresponde a la Disney Rubiano

Caso de uso Cargar Datos Servidores PGN

El presente caso de uso tiene como objetivo permitir sobre el sistema SIAM, el cargue de
los datos de los servidores PGN inscritos en el sistema de Nómina de la Entidad. La
implementación del presente caso de uso se debe ejecutar en forma periódica, de tal forma
que cada vez que se detecten diferencias sobre los registros de un mismo servidor PGN,
entre SIAM y el sistema de Nómina, los registros del primer sistema sean actualizados
según los datos de los registros del segundo sistema. También se debe generar un archivo
log, en el que se indicarán los servidores PGN que en el momento del cargue de datos están
en SIAM (Si es el caso, indicar los recursos físicos/elementos asignados) y no están en el
sistema de Nómina, los que están en el sistema de Nómina y no están en SIAM, y los que
presentaron datos incompletos, indicando cuáles datos.
La implementación del presente caso de uso debe detectar cambios de dependencia y los
retiros de personal de la PGN, con el fin de que en el caso de uso de nombre
“AsignarServidorEquipo” de SIMIP, el usuario de dicho caso de uso pueda identificar tales
cambios.
Administrador SIAM.
3. Entradas
• Por cada cargue de datos: Fecha, hora, nombre del archivo y encargado del cargue.
• Por cada registro ingresado/modificado/eliminado sobre SIAM, se debe contar con

la información básica de la persona, por ejemplo: nombre, número de
identificación, dirección y teléfono, además de cargo, dependencia, habilidades y
conocimientos.
4. Salidas
• Se producen ingresos, modificaciones y/o eliminaciones sobre los registros de datos

de de los funcionarios PGN en el sistema SIAM, según la información cargada
desde el sistema de nómina. Cada registro de datos de un servidor PGN, debe
corresponder en sus datos, a los que suministran en las entradas.
• Se genera un archivo de log, donde se indica las anomalías de sobre los datos de los
servidores PGN.

• Por cada carga de datos, se crea un registro en el sistema SIAM, donde se indica la
fecha, hora, nombre del archivo y encargado del cargue.
5. Flujo de Eventos
5.1 Flujo Básico

del sistema SIAM, selecciona la opción de
“Cargar Datos Servidores PGN”, sobre el
sistema SIAM.
2. El Sistema SAIM, accede al archivo enviado
desde el sistema de Nómina y toma cada uno de
los registros allí registros. Por cada registro se
determina:
(a) Si su equivalente existe en SIAM (Por
número de identificación), de ser así, realiza las
correspondientes actualizaciones de datos.
(b) Si no tiene equivalente en SIAM, crea un
nuevo registro en el medio de almacenamiento de
este, con los datos del registro leído sobre el
archivo. Se genera un registro en el archivo de
log, donde se indica la situación respecto al
registro.
(c) Si se detecta que existe un registro en SIAM,
que no está en el archivo que se está cargando, se
genera un registro nuevo en el archivo de log,
indicando la situación. Con esta información el
Administrador del sistema deberá decidir
posteriormente si borra o no el registro de SIAM.
(d) Si el registro en SIAM que no está en el
archivo de carga, tiene recursos físicos
asignados, se realiza el correspondiente registro
en el archivo de log.
(e) Si el registro no tiene los datos completos, se
registra el hecho en el archivo de log, indicando
los datos que hacen falta.
Para los puntos (a) y (b): Por cada nuevo registro
de servidor PGN en SIAM, se crea un campo
adicional donde se indica de forma automática
que su disponibilidad en cuanto a la carga de
trabajo es del 100%. Los registros ya existentes,
se dejan con la disponibilidad que tengan en el


momento.
Al final del cargue se crea y almacena un registro
en el sistema SIAM con los datos del cargue.

Línea 2: Si existe un registro de cargue en el sistema con el mismo nombre del archivo que
se procede a cargar, se debe cancelar la operación y generar un mensaje que le indique al
usuario de la situación.
6. Precondiciones
Debe existir un archivo con todos los datos necesarios de cada uno de los servidores PGN,
listo para ser cargado en SIAM. Cada registro de dicho archivo es equivalente a los datos de
un servidor PGN.
7. Post Condiciones
Se ingresaron, modificaron y/o eliminaron registros de datos de servidores PGN en el
sistema SIAM. Se generó un archivo de log con los resultados del cargue y se genero y
almacenó un registro con los datos del cargue.
Definir cuales son los datos obligatorios que se deben proporcionar desde el sistema de
Nómina, una vez el proceso de cargue detecte que se trata de la creación y almacenamiento
de un registro con los datos de un servidor PGN. Tener en cuenta que seguramente existen
dos niveles, entre los que se han considerado los así llamados datos básicos del servidor
PGN.

Definir cuales son los datos que se pueden modificar, una vez el proceso de cargue detecte
que se trata de una modificación de un registro de datos de un servidor PGN en SIAM.
8.3 Características de los datos de entrada y de salida que se necesitan para la ejecución
del caso de uso
Definir cuáles son datos necesarios para el desarrollo de este caso de uso, sus tipos y
longitudes, además de determinar cuáles son obligatorios, y cuales no.

8.4 Definir la interfaz

Definir la manera como técnicamente funcionará la interfaz que permite el cargue de datos
desde el sistema de nómina. Adicionalmente se debe definir el tipo de cargue, por ejemplo
por lotes, y el tipo de cancelación del cargue, por ejemplo: (1) se cancela el cargue en el
momento en que no se puede leer un registro, (2) se cancela el cargue de un lote en el
momento en que no se puede leer un registro, (3) No se cancela el cargue pese a que existe
un registro inconsistente.
Por otro lado se puede pensar que un tipo de interfaz es el acceso directo a la base de datos
de sistema de nómina desde SIAM.


CASOS DE USO SIMIP
Requerimientos Detallados Módulo SIMIP (Documento Final) Pág. i

TABLA DE CONTENIDO
SIMIP1 - Asignar competencia (Dependencia) ……………………………………………3
SIMIP2 - Evaluar duplicidad……………………………………………………………….8
SIMIP3 - Acumular solicitud………………………………………………………………12
SIMIP4 - Reversar acumulación …………………………………………………………..16
SIMIP5 - Abrir un documento de correspondencia en varias solicitudes………………….20
SIMIP6 - Acumular caso……………………………………………………………………24
SIMIP7 - Fraccionar Caso…………………………………………………………………..28
SIMIP8 - Relacionar casos………………………………………………………………….32
SIMIP9 - Complementar Información Solicitud……………………………………………36
SIMIP10 - Asignar Servidor/Equipo de Trabajo a Solicitud/Caso…………………………42
SIMIP11 - Recibir Documentación Física Solicitudes …………………………………….49
SIMIP12 - Contrastar solicitudes recibidas del SIAF contra documentación física. ………54
SIMIP13 - Definir Actuación ………………………………………………………………58
SIMIP14 - Asignar Prioridad, Políticas y Proyectos a una Solicitud/Caso ………………..65
SIMIP15 - Abrir Caso………………………………………………………………………71
SIMIP16 - Vincular IÚS con IÚC…………………………………………………………..76
SIMIP17 - Gestionar Actores del caso………………………………………………………80
SIMIP18 - Definir Ruta y Plan de Actividades …………………………………………….85
SIMIP19 - Registrar Actividades y Actuación/Decisión realizadas……………………….90
SIMIP20 - Alertar Vencimiento Casos……………………………………………………..96
SIMIP21 - Registrar Conclusiones ………………………………………………………...101
SIMIP22 - Generar oficios, autos ………………………………………………………….105
Requerimientos Detallados Módulo SIMIP (Documento Final) Pág. 1

SIMIP23 - Marcar Cierre Caso……………………………………………………………109
SIMIP24 - Marcar Archivo Físico Caso…………………………………………………..114
SIMIP25 - Manejar ubicación del archivo en la dependencia …………………………….118
SIMIP26 - Administrar préstamo de expedientes…………………………………………122
SIMIP27 - Indicar cumplimiento por caso preventivo…………………………………….126
SIMIP28 - Registra seguimiento…………………………………………………………..130
SIMIP29 - Reabrir Caso…………………………………………………………………..134
SIMIP30 - Generar listado de fallos no enviados a SIRI…………………………………138
SIMIP31 - Administrar Equipos de Trabajo…………………………………………… 142
SIMIP32 - Manejar Agenda Servidores Públicos……………………………………… . 149
SIMIP_INT_1- Recibir Solicitudes misionales SIAF……………………………………158
SIMIP_INT_2-Transmitir sanciones SIMIP a SIRI (diligenciar formato SIRI)…………163
SIMIP_INT_3. Proveer información de documentos de salida al SIAF………………….168
SIMIP_INT_4. Sugerir Caso a SIREL……………………………………………………173
SIMIP_INT_5 Recibir Solicitudes/Peticiones WEB SIC…………………………………179
Requerimientos Detallados Módulo SIMIP (Documento Final) Pág. 2

CASO DE USO ASIGNAR

COMPETENCIA
(DEPENDENCIA)
Requerimientos Detallados Módulo SIMIP (Documento Final) Pág.A3- 3

AsignarCompetencia (Dependencia) v2.0.doc

05/07/05 2.0 Versión Inicial C.Díaz – H. Velásquez
27/07/05 3.0 Observaciones Atendidas H. Velásquez
29/07/05 3.0 Revisión final observaciones reunión de C.Díaz
cierre de la etapa.

Caso de Uso Asignar Competencia (Dependencia)

El presente caso de uso tiene como objetivo asignar la dependencia que se hará cargo de la solicitud. El
sistema automáticamente debe asignar la dependencia competente para una solicitud o petición basado en
la información registrada en el sistema en el caso de uso de SIAM – Administrar Competencias de las
Dependencias, en el que se describen los temas y normas que determinan las competencias.
Esta asignación automática se puede realizar cuando los ciudadanos o autoridades diligencien la solicitud o
petición de manera completa, en cuyo caso se cuenta con toda la información. En los casos en los que la
información esta incompleta (ejemplo: algunas solicitudes ingresadas por SIAF), el sustanciador de la
División de Registro y Control complementará la información mediante el caso de uso completar
información solicitud para que posteriormente el sistema pueda hacer la asignación automática de
dependencia.
El sistema debe dar también la posibilidad de asignación manual de dependencia, para que la División de
Registro y Control asigne con base en una lista sugerida de dependencias. (ejemplo: puede ocurrir que de
acuerdo a las competencias haya más de una dependencia competente y sea la División de Registro y
Control la que finalmente asigne).
En caso en que la solicitud se ingrese directamente en la dependencia (ejemplo solicitudes de oficio), el

sistema marcará automáticamente que la solicitud pertenece a la dependencia a la que llegó, una vez el
usuario autorizado ejecute la acción en el sistema.

2.1 Iteración
0
2.2 Prioridad
Alta
2.3 Complejidad
Alta
Servidor PGN
4. Entradas
Solicitud registrada en SIMIP.
5. Salidas
Solicitud asignada a una dependencia.

6. Flujo de Eventos
6.1 Flujo Básico

1. Este caso de uso comienza cuando se lanza el
proceso de asignación de competencia, desde los
casos de uso de registrar solicitud, registrar
petición o completar información.
2. El sistema determina cual es la dependencia
competente para atender la solicitud o petición de
acuerdo a la información de la demanda de servicio
y a las competencias registradas en SIAM en el caso
de uso Administrar Competencias por Dependencia.
Dicha dependencia será asignada al registro de
manera automática.
3. El sistema almacena la dependencia.
4. En el caso de que la asignación sea manual en la
División de Registro y control. El sistema despliega
un listado con las posibles dependencias basado en
la información que tenga de la solicitud o petición.
5. El usuario selecciona la dependencia de
acuerdo a la naturaleza de la solicitud.
7. Si la solicitud llegó directamente a la
dependencia, la competencia fue asignada
automáticamente en el momento del registro de la
solicitud por el usuario autorizado.
Paso 3: Si el sistema no cuenta con información suficiente para sugerir la dependencia, será el sustanciador
quien tome la decisión.
7. Precondiciones
• El IUS entrado corresponde a una solicitud existente en el sistema.
• El listado de dependencias sugeridas existen en el sistema.

8. Post Condiciones
• Se asigna la competencia de una solicitud correctamente en el sistema.
Este caso de uso esta directamente relacionado con el caso de uso en SIAM- Administrar Competencias por
Dependencias. Deberá ajustarse a las definiciones de competencias que allá se determinen.

CASO DE USO EVALUAR

DUPLICIDAD

EvaluarDuplicidad.doc


Caso de Uso Evaluar Duplicidad

El presente caso de uso tiene como objetivo evaluar la duplicidad de solicitudes ingresadas al sistema, y
advertir al servidor para que decida si definitivamente la solicitud debe ser abierta o no. Si la solicitud
llega por la Web y el sistema detecta duplicidad, la advierte al usuario, indicándole en número de
radicación de la solicitud o caso existente. El mecanismo también debe funcionar cuando la solicitud se
inicia de oficio. También debería funcionar si lo que se reporta es el inicio de una investigación
disciplinaria, para el ejercicio del poder preferente.
Este requerimiento es llamado en el momento de ingresar una nueva solicitud para alertar que una solicitud
similar ya se encuentra registrada en el sistema (esto para evitar que se ingresen duplicados al sistema, ya
que muchas veces la misma solicitud llega con copia a varios lugares de la PROCURADURIA). Se deben
definir los datos básicos sobre los cuales se establece la duplicidad.

2.1 Iteración
0
2.2 Prioridad
Alta
2.3 Complejidad
Media
Servidor
4. Entradas
5. Salidas
Advertencia al usuario que una solicitud con la misma información ya se encuentra registrada en el sistema.
6. Flujo de Eventos
6.1 Flujo Básico

1. Este caso de uso comienza cuando se va a
registrar una solicitud nueva al sistema.

2. El sistema evalúa la posible duplicidad en la

solicitud, comparando los campos definidos para tal
fin.
3. El sistema despliega un mensaje al usuario
advirtiendo que ya existe en el sistema una solicitud
similar, desplegando el número de radicación y la
información necesaria de la solicitud existente
(registro inicial) para que el servidor pueda verificar
la verdadera existencia de duplicidad en la solicitud
que se pretende ingresar.
El sistema le da la opción de cancelar o continuar
con el registro de la solicitud.
4. El servidor continúa o cancela con la operación
de registro de la solicitud con base en lo
verificado.
• Ninguno
7. Precondiciones
• Los datos ingresados para la nueva posible solicitud son válidos.
• Existen unos criterios claros, previamente determinados, sobre el ingreso de información en el SIMIP
8. Post Condiciones
• El sistema compara la información entrada con los campos definidos de las solicitudes ingresadas en
SIMIP, y en caso de considerar duplicidad se advierte al servidor.
Falta definir cuales son los campos que sirven de comparación para evaluar duplicidad.

CASO DE USO ACUMULAR

SOLICITUD

AcumularSolicitud.doc

21/07/05 3.0 Observaciones atendidas H. Velásquez

Caso de Uso Acumular Solicitud

El presente caso de uso tiene como objetivo combinar la información de una solicitud con otra ya existente,
vinculando las dos solicitudes indicando cual solicitud depende de la otra e inactivando la solicitud
dependiente.

2.1 Iteración
0
2.2 Prioridad
Media
2.3 Complejidad
Baja
Servidor
4. Entradas
IUS de solicitud registrada en SIMIP a acumular.
IUS de solicitud registrada en SIMIP a la cual se va a acumular.
5. Salidas
Solicitud acumulada indicando la dependencia entre ambas y que solicitud queda inactiva por quedar
acumulada.
Oficio remisorio al funcionario en conocimiento del caso, para notificarlo de la acumulación.
6. Flujo de Eventos
6.1 Flujo Básico

1. Este caso de uso comienza cuando se detecta
que una solicitud está directamente asociada a
otra en el sistema. El servidor le ordena al
sistema vincular la solicitud detectada con la
solicitud a la que se debe acumular, indicando

cual solicitud depende de la otra.

2. El sistema registra vinculación de las dos
solicitudes con la descripción del tipo de
dependencia (relación), e inactiva la solicitud
dependiente.
3. Se llama al caso de uso Generar Oficios Autos
para generar el oficio remisorio al funcionario en
conocimiento de la solicitud.
• Paso 2: Si alguno de los IUS entrados no corresponden a una solicitud válida en el sistema, se
informa el error y se aborta la operación.
7. Precondiciones
• Los IUS entrados corresponden a solicitudes existentes en el sistema.
8. Post Condiciones
• Las solicitudes son correctamente acumuladas en el sistema, indicando cual solicitud depende de
la otra e inactivando la solicitud dependiente.

CASO DE USO REVERSAR

ACUMULACIÓN

ReversarAcumulacion.doc


Caso de Uso Reversar Acumulación

El presente caso de uso tiene como objetivo permitir reversar la acumulación efectuada sobre una solicitud
o un caso.

2.1 Iteración
0
2.2 Prioridad
Media
2.3 Complejidad
Baja
Servidor PGN
4. Entradas
IUC de caso o IUS de solicitud registrada en SIMIP previamente acumulada.
5. Salidas
Caso o solicitud con acumulación reversada.
6. Flujo de Eventos
6.1 Flujo Básico

1. Este caso de uso empieza cuando el servidor
requiere reversar una solicitud o un caso
previamente relacionado mediante el
mecanismo de acumulación.
2. El servidor le dice al sistema si lo que desea
reversar es la acumulación de una solicitud o
de un caso abierto.
3. El servidor entra el IUC o IUS del caso o
solicitud a reversar, dando la justificación de
la operación, y el criterio de reverso
seleccionado. Los criterios se obtienen de una

tabla de donde el servidor debe seleccionar la

que corresponda, aún cuando pueda, en un
campo descripción, hacer las anotaciones
pertinentes.
4. El sistema reversa el caso o la solicitud
desvinculando el IUS o IUC del caso o solicitud
relacionada y registrando la justificación dada.
5. Si se va a reversar un caso, las cargas de los
funcionarios son recalculadas para dejarlas como
estaban al momento de la acumulación.
6. El servidor debe enrutar las solicitudes o casos
reversados según el rumbo que este decida
deben seguir: Al reversar dos solicitudes o
casos, el servidor puede reasignarlos a la
dependencia pertinente, se pueden devolver a
la división de registro y control para que la
reasignación se haga allá o simplemente
continúan su trámite en la dependencia como
dos solicitudes o casos independientes.
7. Si alguno de las solicitudes/casos se convierte en
un asunto nuevo para la dependencia, se llama al
caso de uso Asginar Servidor y/o Equipo de
Trabajo.
8. La operación de reverso queda registrado en la
bitácora histórica del sistema.
• Paso 4: Si se eligió reversar un caso, y el IUC entrado no corresponde a un caso válido en el

sistema, se informa el error y se aborta la operación.
• Paso 4: Si se eligió reversar una solicitud, y el IUS entrado no corresponde a una solicitud válida
en el sistema, se informa el error y se aborta la operación.
7. Precondiciones
• El IUC entrado corresponde a un caso existente en el sistema.
8. Post Condiciones
• La solicitud o caso es correctamente reversado y la información asociada queda igual a como
estaba en el momento antes de efectuar la acumulación.

CASO DE USO ABRIR

DOCUMENTO DE
CORRESPONDENCIA EN
VARIAS SOLICITUDES

AbrirCorrespondenciaVariasSolicitudes.doc


Caso de Uso Abrir documento de Correspondencia en

Varias Solicitudes
El presente caso de uso tiene como objetivo permitir que una solicitud recibida en correspondencia se
convierta en más de una solicitud en el sistema en el momento en que se considere que debe ser atendida
por varias dependencias (ejemplo: tiene un componente de intervención, uno de disciplinario, etc).

2.1 Iteración
0
2.2 Prioridad
Media
2.3 Complejidad
Media
Servidor PGN en división de registro y control
4. Entradas
5. Salidas
6. Flujo de Eventos
6.1 Flujo Básico

1. Este caso de uso comienza cuando se decide
abrir una nueva solicitud a partir de una existente,
o cuando se deduce que la solicitud debe ser
atendida por varias dependencias. El servidor le
ordena al sistema fraccionar la solicitud dando la
justificación correspondiente.
2. Se abre una nueva solicitud asignándole un
nuevo IUS y copiando la información de la solicitud
original en la que se está abriendo en SIMIP.
3. El sistema registra la justificación para fraccionar
la solicitud, escogiendo la razón mas cercana

obtenida de un conjunto predefinido, o ingresándola

en un campo de texto abierto.
• Paso 4: Si el IUS entrado no corresponde a una solicitud válida en el sistema, se informa el error
y se aborta la operación.
7. Precondiciones
8. Post Condiciones
• La solicitud es correctamente fraccionada en el sistema.

CASO DE USO ACUMULAR

CASO

AcumularCaso.doc


Caso de Uso Acumular Caso

El presente caso de uso tiene como objetivo combinar la información de varios casos en uno solo,
vinculando la información, creando una relación de dependencia, de un caso en otro existente e inactivando
el caso dependiente.
Es bueno tener en cuenta que existen dos tipos de acumulación:

- acumulación jurídica (ejemplo, una persona tiene más de un proceso disciplinario y se decide unirlos para
emitir un solo fallo)
- acumulación procesal (cuando dos dependencias al no darse cuenta que era la misma solicitud abren la
misma investigación, decidiéndose la unión de los casos).
Cuando un caso se agrega a otro, el sistema conserva la información de cada caso, no obstante que en el
caso que continúa, se debe reflejar que ese caso tiene agregado el otro, lo mismo en el caso que se inactiva.

2.1 Iteración
0
2.2 Prioridad
Media
2.3 Complejidad
Baja
Servidor
4. Entradas
IUC de caso registrado en SIMIP a acumular.
IUC de caso registrado en SIMIP a la cual se va a acumular.
5. Salidas
Caso acumulado indicando la dependencia entre ambas, indicando relación entre los casos e inactivando el
caso dependiente.

6. Flujo de Eventos
6.1 Flujo Básico

1. Este caso de uso comienza cuando se detecta
que un caso está directamente asociado a otro en
el sistema. El servidor le ordena al sistema
vincular el caso detectado con el caso al que se
debe acumular, indicando cual caso depende del
otro, e indicando las razones para efectuar la
operación, las cuales se tomarán de una tabla de
razones predefinidas, dando la opción al servidor
de ingresar una justificación en un campo de
descripción.
2. El sistema registra vinculación de los dos casos
con su dependencia. El sistema debe recalcular la
carga del servidor del caso que va a ser desactivado,
para liberarlo de carga en el sistema. En el caso
disciplinario, se mantendrá la información de los
funcionarios investigados.
3. El sistema invoca el caso de uso Relacionar
Casos.
4. Una vez el sistema reconoce que caso es el
dependiente, lo inactiva del sistema.
• Paso 2: Si alguno de los IUC entrados no corresponden a un caso válido en el sistema, se informa
el error y se aborta la operación.
7. Precondiciones
• Los IUCs entrados corresponden a casos existentes en el sistema.
8. Post Condiciones
• Los casos quedan correctamente acumulados en el sistema, con las razones para tal y las cargas
de los servidores involucrados son recalculadas.

CASO DE USO FRACCIONAR

CASO

FraccionarCaso.doc


Caso de Uso Fraccionar Caso

El presente caso de uso tiene como propósito abrir un caso de uso existente, en otro nuevo heredando la
información del caso original cuando así se indique. Este aplica cuando un proceso se debe abrir en dos o
mas procesos (hay ruptura de la unidad procesal y se debe abrir un nuevo caso).

2.1 Iteración
0
2.2 Prioridad
Media
2.3 Complejidad
Baja
Servidor PGN
4. Entradas
Caso registrado en SIMIP.
5. Salidas
Nuevo caso, con la información del caso original incorporada y nuevo IUC asignado.
6. Flujo de Eventos
6.1 Flujo Básico

1. Este caso de uso comienza cuando se decide
abrir un nuevo proceso relacionado al original. El
servidor le ordena al sistema fraccionar el caso
dando la justificación correspondiente, indicando
que información desea heredar del caso original.
2. Se abre un nuevo caso asignándole un nuevo
IUC, y el sistema copia la información del caso
original en el que se está abriendo, excepto los
actores del caso para que sean administrados una
vez se llame al caso de uso Gestionar Actores del


Caso.
3. El sistema registra la justificación para fraccionar
el caso.
4. Se invoca el caso de uso Relacionar Casos.
5. Se invoca al caso de uso Gestionar Actores del
Caso para asignar los actores al caso que se
fraccionó, y allí se recalculen las cargas.
• Paso 2: Si el IUC entrado no corresponde a un caso válido en el sistema, se informa el error y se

aborta la operación.
7. Precondiciones
8. Post Condiciones
• El caso es correctamente fraccionado en el sistema.

CASO DE USO RELACIONAR

CASOS

RelacionarCasos.doc


Caso de Uso Relacionar Casos

El presente caso de uso tiene como objetivo relacionar dos o más casos con el fin de hacer seguimiento a
casos relacionados. Este caso de uso es llamado desde los casos de uso de acumular y fraccionar casos, y
consiste en registrar los IUCs de los casos que se relacionaron y que tipo de relación se ejecutó (ej:
acumulación, fracción, etc).
El caso de uso también puede ser llamado directamente para relacionar dos casos con un tipo de relación
genérica que el servidor puede definir, dando la justificación para la relación.

2.1 Iteración
0
2.2 Prioridad
Media
2.3 Complejidad
Baja
Servidor PGN
4. Entradas
UIC de 2 casos registrados en SIMIP que se deben relacionar.
5. Salidas
Registro de relación de los casos ingresada en SIMIP.
6. Flujo de Eventos
6.1 Flujo Básico

1. Este caso de uso comienza cuando se
decide acumular o fraccionar un caso, y se
ejecutó el caso de uso correspondiente, o
cuando el caso de uso es llamado
directamente para ejecutar una relación
genérica.


2. El sistema toma los UICs de los casos a
relacionar entrados del caso de uso
acumular o fraccionar caso según
corresponda. Si es llamado directamente,
el servidor define el tipo de relación e
ingresa la justificación de la misma, así
como los hechos que dieron lugar a la
determinación de relacionarla a otro caso.
3. El sistema registra la relación entre los casos,
diciendo que tipo de relación se efectuó.
• Paso 3 Si alguno de los IUC entrados no corresponden a un caso válido en el sistema, se informa
el error y se aborta la operación.
7. Precondiciones
• Los IUC entrados corresponden a casos existentes en el sistema.
8. Post Condiciones
• Los casos quedan correctamente relacionados en el sistema.

CASO DE USO COMPLEMENTAR

INFORMACIÓN SOLICITUD

ComplementarInformaciónSolicitud v2.0

07/06/05 2.0 Revisión observaciones PGN C.Díaz, F. Martínez
11/07/05 2.0 Revisión Observaciones PGN. C.Díaz
Se cambió el nombre del requerimiento de
Clasificar Solicitud por Característica a
Complementar Información Solicitud.
25/07/05 3.0 Observaciones Atendidas. H. Velásquez

Caso de Uso Complementar Información Solicitud

El presente caso de uso tiene como objetivo complementar la información de la solicitud,
de acuerdo al área misional disciplinaria, de intervención (judicial, administrativa o
jurídica) o de prevención.
Para solicitudes ingresadas por la web, éste requerimiento forma parte de la información
recolectada cuando se hace el ingreso de la solicitud. De igual manera cuando la solicitud es
ingresada por un servidor PGN en una dependencia como solicitud de oficio. Para
solicitudes ingresadas por el sistema SIAF, la información incorporada al SIAF en el
departamento de correspondencia es la información mínima de la solicitud, una vez el
registro ha llegado a SIMIP via interfaz, la información se complementa en SIMIP en la
oficina de registro y control.
2.1 Iteración
0.
2.2 Prioridad
Alta.
2.3 Complejidad
Alta.
Servidor de la PGN como operador del Sistema SIMIP.
4. Entradas
Solicitud Radicada.
Datos de la solicitud.
5. Salidas
Solicitud con información completa
6. Flujo de Eventos
6.1 Flujo Básico


servidor se dispone a ingresar datos
adicionales de una solicitud. (La
información básica es ingresada por SIAF,
en éste punto se ingresa información
adicional – en la oficina de Registro y
Control).
2. El servidor ingresa al sistema el código

de barras asociado a la documentación de la
solicitud o contingencia.

registro de radicación asociado al código de
barras.
4. Muestra al servidor cuatro opciones a

seleccionar respecto a las áreas misionales:
Disciplinaria, Preventiva, Intervención o
Jurídica.
5. El servidor analiza el contenido de la

solicitud y selecciona en el sistema el área
misional relacionada con la solicitud:
Disciplinaria, Preventiva, Intervención o
Jurídica.
6. Despliega la correspondiente sección de

registro de datos:
Si la opción seleccionada es Disciplinaria, se
activará la sección de registro de datos para
solicitudes del área Disciplinaria.
Si la opción seleccionada es Preventiva, se
solicitudes del área Preventiva.
Si la opción seleccionada es Intervención, se
solicitudes del área de Intervención.
Si la opción seleccionada es Jurídica, se
solicitudes del área de jurídica.
7. El usuario ingresa la información


correspondiente.
8. El sistema almacena los datos

suministrados por el Servidor (Sustanciador).
Los datos son asociados al registro
encontrado en la línea 3.
Aclaración: Cuando la solicitud ha sido radicada previamente en el SIAF, debe contener

como mínimo la siguiente información:
• Datos del ciudadano (persona o entidad que formula la queja o solicitud):

Nombres y apellidos del ciudadano (remitente).
Dirección y teléfono del ciudadano (remitente).
País, Departamento, Ciudad de Procedencia.
• Datos de la Queja o Solicitud:

Fecha de la solicitud
Detalle de la queja o solicitud, descripción breve del contenido de la queja o
solicitud.
Naturaleza (el equivalente a naturaleza de documento en SIAF, se refiere si el
documento es un Oficio, Derecho de petición, tutela, etc.) Tipo de clasificación de
la solicitud o asunto.
• Información de los documentos relacionados:

Número externo/interno del oficio.
Fecha de Procedencia del documento.
• Información generada por SIAF:

Número Único de Identificación.
Fecha y hora de registro en SIAF y Dependencia a la que fue asignada la solicitud.
• Sistema Misional (SI/NO)
Una vez ha llegado esta información a SIMIP se procede a complementar los datos de
acuerdo al área misional:
Disciplinaria:
• Información del Quejoso : Nombre, Identificación, Dirección, etc

• Información de los Hechos: Lugar, Fecha, Descripción, etc
• Información del Implicado: Nombre, Identificación, Dirección, etc
• Conducta.
Preventivo:
• Información Entidad Responsable: Nombre.
• Tipo de Derecho Afectado o Temática.

Línea 3: Si no existe en el sistema, un registro previo en referencia a la radicación
genera un mensaje de error y aborta la operación.
7. Precondiciones
Debe existir un registro de radicación con el cual se puedan asociar los datos de la
solicitud.
Se debe tener en cuenta que para solicitudes que se ingresan por la web, o casos de
oficio (originados por la PGN), esta funcionalidad de registrar información de
acuerdo al área misional (clasificar solicitud por característica), hace parte de la
pantalla de registro de la solicitud. Para las solicitudes que ingresan por SIAF la
información ingresada en dicho sistema de correspondencia es mínima, y por tanto
cuando la solicitud llega a la División de Registro y Control, la primera pantalla
que se debe desplegar es esta de clasificar solicitud por característica la cual
permite registrar un mayor detalle y soportar la asignación de competencia.
8. Post Condiciones
Los datos de la solicitud quedan registrados en el sistema, determinados por el tipo
de área misional que lo tratará.

CASO DE USO ASIGNAR

SERVIDOR Y/O EQUIPO DE
TRABAJO A SOLICITUD/ CASO

AsignarServidorEquipo v3.0.doc

04/05/05 1.0 Versión Inicial H. Velásquez
23/06/05 2.0 Revisión observaciones recibidas PGN. C.Díaz
Cambio de nombre del requerimiento de
Repartir y Asignar Solicitudes a Asignar
Servidor y/o Equipo de Trabajo a Solicitud
/ Caso.
Se incluye aquí la asignación de
comisiones.
29/07/05 3.0 Observaciones finales reunión de cierre. C.Díaz

Caso de Uso Asignar Servidor y/o Equipo de

Trabajo a Solicitud/ Caso
El presente caso de uso tiene como objetivo asignar a una solicitud -valorada como de
competencia de la PGN- o a un caso, el servidor o servidores (equipo de trabajo) que se
encargarán del mismo, es decir asignar el titular de la responsabilidad del trámite del caso.
Si se asignan servidores el sistema debe brindar la posibilidad de señalar sus roles, por
ejemplo, para el caso de las comisiones disciplinarias especiales, la presidencia y los
colaboradores.
El sistema debe prever la posibilidad de que un servidor, de la dependencia, también se

encuentre adscrito o se pueda adscribir, a un Comité o Comisión Institucional (dependencia
virtual) creada para atender determinados tipos de casos o problemáticas, en este evento,
también debe permitir asignarle el Caso con cargo a su mapa de carga laboral, en la cual
debe reflejarse, como caso a su cargo si le corresponde su trámite.
Existen dos formas para designar al servidor o servidores, automática y manual. En el

primer evento, es el sistema quien determina a qué servidor le corresponde el conocimiento
del caso (reparto), y en el segundo, es el responsable de la dependencia quien selecciona al
servidor (asignación directa), debiendo en todo caso, señalar el criterio utilizado,
seleccionándolo de una lista de criterios previamente definida en el sistema, por ejemplo, la
complejidad del caso, la connotación que éste pueda tener en la sociedad o en los
organismos internacionales.
En el sistema SIMIP, con base en la información de carga de funcionarios, los cuales

provienen de la suma de los pesos a las solicitudes y casos que tiene un funcionario en el
momento de ejecutar el programa de reparto, el perfil del funcionario y la clasificación de la
solicitud, procede a hacer asignación, que en principio se hace de manera automática, pero
se puede configurar para hacer un reparto manual en caso de requerirse.
El sistema debe contar con opciones de manejo de situaciones administrativas que afectan
la carga laboral y mecanismos de equilibrio, tales como exclusión del reparto, cambio del
valor de carga laboral o reasignación de casos, que se podrán configurar de forma manual
cuando se requiera.
El programa de reparto se podrá hacer mediante mecanismos de asignación o reasignación

directa o aleatoria, según como se haya configurado, y los nuevos pesos asignados a los
funcionarios elegidos serán acumulados en sus respectivas cargas.

Ejemplo de Matriz de carga laboral:
# Casos asignados Vr. C. Lab.(Peso) # Casos evacuados # Casos Activos

Servidores
Pedro 5 5 3 2
Juan 5 6 2 3
José 4 8 2 2
Vale la pena aclarar que este caso de uso se puede llamar en varias oportunidades: cuando
en las dependencias se hace reparto a funcionarios, cuando en la División de Registro y
Control se hacer reparto a sustanciadotes y cuando se hace reparto de casos de segunda
instancia.
Si el caso que llega a segunda instancia proviene de una procuraduría regional o de una
procuraduría provincial, éste se podrá remitir directamente al competente o tramitarse ante
la División de Registro y Control, en los eventos en los que exista más de una delegada
competente para que allí se asigne, con todo, el caso deberá conservar el mismo número.

2.1 Iteración
0
2.2 Prioridad
Alta
2.3 Complejidad
Alta
Procurador Delegado, Regional o Territorial, Jefe o Coordinador de Grupo.
4. Entradas
Solicitudes radicadas y asignadas a la dependencia.
Listado de funcionarios disponibles, con su Información de cargas
5. Salidas
Caso asignado, con especificación de peso.

6. Flujo de Eventos
6.1 Flujo Básico

Procurador Delegado, Regional,
Provincial, Jefe o Coordinador
encuentra que hay una nueva solicitud
ingresada, que no tiene funcionario
asignado, o cuando requiere asignar-
reasignar una solicitud a un funcionario
particular.
2. Si el Procurador Delegado, Regional,

Provincial, Jefe o Coordinador desea
hacer una asignación automática de
servidor, que debe ser la opción por
defecto del sistema. Lo que debe hacer
es configurar el sistema en caso de que
desee excluir algunos funcionarios del
reparto.
3. El sistema recibe los identificadores de

los funcionarios a excluir (si los hay), y
los excluye del reparto. Con ésta
información el sistema sabrá cuales son
los usuarios hábiles para el reparto, de
acuerdo a la carga laboral o alguna
exclusión particular. Por ejemplo, cuando
un servidor sale a vacaciones, así no haya
reparto para hacer, el encargado puede
excluirlo del reparto, y cuando llegue
reparto el sistema ya sabe que él no entra.
4. El Procurador Delegado inicia el

proceso de reparto con los funcionarios
definidos.
5. El programa escoge al funcionario con

menor carga de trabajo, que sale de
sumar los pesos de las solicitudes y casos
que tiene a su cargo, y le asigna dicha
solicitud.
6. El sistema actualiza el nuevo peso en la

carga asignada al funcionario elegido.

7. Si el Procurador Delegado, Regional,

Provincial, Jefe o Coordinador desea
hacer una asignación – o reasignación
manual, de Funcionario ingresa el
identificador del usuario a asignar, así
como la razón de la asignación. El
sistema debe mostrarle una lista de
opciones para que indique cuál es el
criterio de asignación manual que va a
utilizar.
No debe olvidarse que cuando se hace
asignación directa, también se puede variar
el peso que tiene el caso asignado, dándole
por un mayor valor.
8. El sistema asigna la solicitud al

funcionario entrado, y actualiza el nuevo
peso en la carga asignada al funcionario
elegido.
9. Si el Procurador Delegado desea

incorporar un equipo de trabajo
(comisión), selecciona la opción de
comisión.
El encargado puede dárselo a un grupo de
funcionarios de la misma dependencia (equipo
de trabajo), indicando quienes son sus
integrantes y los roles. Igualmente, puede
asignársela a un Comité o Comisión
Institucional ya existente o crearla, indicando
quienes son sus integrantes y sus roles, y en
cada caso, precisar en cabeza de quien queda la
asignación.
10. Para crear las comisiones, el sistema

ejecuta la implementación del caso de
uso de nombre
“AdministrarEquiposTrabajo” del
sistema SIAM.
11. El sistema automáticamente hace el

manejo de cargas para las personas
asignadas a la comisión, de acuerdo a los
roles y % de tiempo definidos.

Nota: Cuando el usuario del sistema ejecute consultas sobre los servidores PGN encargados
de un caso, el sistema le deberá indicar cuales han cambiado de Dependencia1. Cuando un
servidor se retira de la entidad o lo transfieren a otra dependencia, deben ocurrir dos
acciones: 1) Nómina actualiza la desvinculación de la entidad o la vinculación del servidor
a la nueva dependencia, lo cuál permitirá que en la nueva dependencia le puedan asignar
solicitudes o casos. 2) En la dependencia a la cual pertenecía el servidor desvinculado o
transferido, la acción que corresponde es la reasignación de sus casos y además, la
exclusión del servidor en la planta de personal disponible en esa dependencia, para recibir
solicitudes o casos.
• Paso 3: Si alguno de los funcionarios elegidos no existe en el sistema, se informa al usuario

sin abortar la operación, a menos que el usuario lo decida.
• Paso 5: Si al menos algunos de los funcionarios elegidos para el reparto no existe en el

sistema, o no existen funcionarios disponibles, se informa el error y aborta la operación.
• Paso 5: Si el IUS no corresponde a una solicitud válida en el sistema, se informa el error y

se aborta la operación.
• Paso 7: Si el IUS no corresponde a una solicitud válida en el sistema o el funcionario no

existe, se informa el error y se aborta la operación.
7. Precondiciones
• Los funcionarios elegibles para ser asignados a una solicitud, deben existir en el sistema.
• Los pesos de las cargas dependen de las solicitudes, y son números reales positivos.
8. Post Condiciones
• La asignación del funcionario a la solicitud dada queda correctamente registrada en el

sistema, y su peso actualizado como la suma del peso anterior más el peso asignado la caso
asignado.
Ninguno.
1
En SIAM se cuenta con el caso de uso de nombre “cargar Datos Servidores PGN”, que debe identificar el cambio de
dependencia de un servidor PGN.

CASO DE USO
RECIBIR DOCUMENTACIÓN
FÍSICA SOLICITUDES

RecibirDocumentaciónFísicaSolicitudes.doc

02/07/05 2.0 Observaciones atendidas H. Velásquez, F.
Martínez

Caso de Uso Recibir Documentación Física

Solicitudes
El presente caso de uso tiene como objetivo indicar qué documentación física debe haber
sido recibida en una dependencia de la PGN, y asociarla a una solicitud o caso existente en
el sistema.
Esta tarea se podrá realizar con ayuda del código de barras que se le coloca a la
documentación al momento de entrar a la PGN, y que es generada por SIAF. Cuando la
documentación llegue a la dependencia, se leerá el código de barras del documento y de
esta manera quedará registrado en el sistema la dependencia que posee los documentos. Si
la documentación asociada a una solicitud no llega a su receptor después de un tiempo
definido, se generará una alarma a la División de Correspondencia.
Cuando la documentación llegue directamente a la dependencia (i.e. una comunicación
recibida por un procurador judicial), este solicitará el código de barras de SIAF grabando la
información básica, y marcará como recibida la documentación física.
Una vez marcada la documentación como recibida, la dependencia la asociará a un UIC-
IUS existente.
2.1 Iteración
0
2.2 Prioridad
Media
2.3 Complejidad
Media
• Dependencia
4. Entradas
Código de la documentación física a entregar (código de barras).
IUS de la solicitud a la que pertenece.

5. Salidas
Registro de Documentación física recibida por la dependencia.
6. Flujo de Eventos
6.1 Flujo Básico
1. Este caso de uso comienza cuando en la

dependencia se recibe documentación
física asociada a solicitudes.
2. El funcionario en la dependencia ingresa

al sistema el código de barras asociado a la
documentación de la solicitud. Si la
documentación es recibida directamente en
la dependencia, se ingresa la información a
SIAF para obtener código de barras.

registro de radicación asociado al código de
barras.
4. Se marca que la documentación ha sido

recibida físicamente, y le despliega al
usuario la información de la solicitud a la
cual fue asociada previamente.
5. Si la documentación no tiene solicitud o

caso asociado, la dependencia lo debe
asociar a uno existente.
6. El sistema asocia la documentación física

recibida al caso o solicitud dados..
• Línea 6: Si el código de barras de la documentación a entregar no ha sido asociado

a una solicitud de competencia del funcionario que recibe previamente, se informa
del error al usuario.
7. Precondiciones
• El código de barras de la documentación física debe estar asociado a una solicitud

en SIMIP que sea de competencia del usuario al que se le entrega.

8. Post Condiciones
• El recibo de la documentación física queda correctamente registrado en el sistema,

indicando la fecha, hora y el identificador del funcionario que recibió la
documentación en mención.
Incluir en recomendaciones o en la parte de arquitectura la necesidad de lectores de códigos
de barras en las dependencias.

CASO DE USO CONTRASTAR

SOLICITUDES RECIBIDAS DEL
SIAF CONTRA DOCUMENTACIÓN
FÍSICA

ContrastarSolicitudesContraDocumentacion.doc

06/07/05 2.0 Revisión Observaciones PGN C.Díaz, F. Martínez

Caso de Uso Contrastar solicitudes recibidas del

SIAF contra documentación física
El presente caso de uso tiene como objetivo listar las solicitudes asignadas a una
dependencia contra el recibo de la documentación física correspondiente. Esto con el fin de
detectar documentos que no hayan llegado a la dependencia físicamente pero cuya solicitud
ya se encuentra asignada a la dependencia en el sistema.
2.1 Iteración
0.
2.2 Prioridad
Alta.
2.3 Complejidad
Media.
Dependencia
4. Entradas
IUS de una Solicitud existente.
5. Salidas
Relación de solicitudes vs documentación física recibida por la dependencia.
6. Flujo de Eventos
6.1 Flujo Básico

funcionario de una dependencia desea
verificar que la documentación física
asociada a solicitudes de la dependencia ya
se encuentra completa en la dependencia.


2. El sistema le devuelve el listado del
conjunto de solicitudes .vs. documentos
físicos recibidos en un periodo de tiempo
determinado.
3. El usuario contrasta y verifica la
existencia de los documentos físicos que
tiene contra las solicitudes.
4. El usuario indaga con la oficina de
correspondencia por los documentos no
recibidos.

Línea 3: Si el IUS entrado no existe en el sistema, se genera un mensaje de error y
7. Precondiciones
Deben existir solicitudes asignadas a la dependencia en un período determinado.
8. Post condiciones
Ninguna.
Ninguno.

CASO DE USO
DEFINIR ACTUACION

DefinirActuación.doc

06/05/05 2.0 Revisión observaciones PGN C.Díaz, F. Martínez
27/07/05 3.0 Se incluyó en este requerimiento el registro C.Díaz
de la solución que el servidor PGN da a las
peticiones (derecho de petición).
29/07/05 3.0 Se revisaron últimas observaciones reunión C.Díaz
de cierre de etapa.

Caso de Uso Definir Actuación
El presente caso de uso tiene como objetivo registrar la acción que corresponda seguir, una
vez se ha evaluado el asunto. El sistema proporcionará al servidor de la PGN, una lista de
opciones posibles entre las que puede seleccionar la más indicada, por ejemplo: abrir caso,
generar auto u oficio para remitir a otra entidad, etc. Estas acciones corresponden a las
salidas del proceso Evaluar Asunto.
El servidor al que le han asignado el conocimiento de una solicitud o petición, puede:
Para el caso de solicitudes:
a) asumir el caso,
b) redirigirlo enviándolo a otra dependencia,
c) remitirlo a otra autoridad,
d) archivarlo,
e) agregarlo a otro caso que ya exista (acumulación),
Para el caso de peticiones:
a) responder la petición.
b) redirigiéndola enviándola a otra dependencia
Si el servidor asume el caso, tras descartar duplicidad y evaluar la competencia, y decide
tramitarlo, entonces se pasa al caso de uso Abrir caso.
Si el servidor decide redirigir el asunto, cuando la competencia ha sido asignada en forma
errada, debe poder asignar la dependencia que el servidor estime conveniente. Para dichos
casos, el sistema debe tener la posibilidad de reactivar un caso para la nueva dependencia a
quien se le asigno el caso o reactivarlo para el mismo servidor, por la devolución del caso.
No obstante, si son varias las dependencias que tienen competencia para asumir la solicitud
o caso, se deberá remitir a la División de Registro para que allí se asigne la competencia.


2.1 Iteración
0
2.2 Prioridad
Alta
2.3 Complejidad
Alta
• Servidor PGN
4. Entradas
Solicitud radicada.
Tipo de solicitud (disciplinario, preventivo, intervención o jurídica) incluida en la
información de la solicitud.
5. Salidas
Para solicitudes:
• Dependencia o entidad a la que se remite una solicitud
• Identificador(es) único(s) de caso(s) a acumular

Según el análisis que haga el servidor, y el tipo de solicitud puede obtener una de estas
salidas:
Para Disciplinario:
Auto de Remisión por Competencia a otra Entidad.
Auto de Remisión por Competencia a otra Dependencia.
Auto de Archivo.
Auto de Apertura Indagación Preliminar.
Auto de Apertura Investigación.
Auto de Acumulación.
Auto de supervigilancia (como expresión del poder preferente – recuérdese que si
la decisión del poder preferente es ejercer supervigilancia, esto se convierte en caso
de Intervención Administrativa)
Citación a audiencia – procedimiento ante Procurador General.

Citación a audiencia – procedimiento verbal.

Para Preventivo:
Apertura de caso - abrir carpeta.
Traslado por competencia a otra dependencia interna.
Acumulación a caso existente.
Traslado por competencia a otra autoridad.
Para Intervención:
Apertura de caso (se debe tener en cuenta que para jurídica, lo procedente es
contestar la demanda o dar respuesta a la acción que se intenta contra la PGN)
Acumulación a caso existente.
Rechazo.
Traslado por competencia a otra dependencia interna.
Para peticiones:
• Dependencia a la que se remite la petición, o
• Fecha y descripción del detalle de la solución.

6. Flujo de Eventos
6.1 Flujo Básico

servidor efectúa la valoración inicial de los
hechos puestos en conocimiento
(conducta), las pruebas o soportes que
acompañan la queja o solicitud de servicio
y los responsables señalados en la solicitud
(sujetos o autoridades, con el fin de
verificar la competencia de la PGN,
comprobar la existencia de antecedentes
sobre los mismos (acumulación), y
determinar si amerita la apertura de un
caso.
2. El sistema de acuerdo al tipo de solicitud (si
es disciplinario, intervención, prevención o
jurídica), muestra las acciones posibles (ver
Salidas). Lo primero que debería mostrar el
sistema es la lista de posibles actuaciones,
esto es: Abrir Caso, Archivar Solicitud,


Traslado por competencia o Acumulación,
para que el usuario seleccione la que
corresponda y luego si se procede según la
selección.
3. Si es una petición, el sistema debe permitir
registrar del detalle de la solución.
Genera auto, oficio o acto. 4. En caso en que la actuación sea un auto de

remisión, se marca la dependencia o entidad
a la cual debe ser redirigido el caso y se
adjunta el auto.
archivo, se genera el Auto (ver caso de uso:
Generar Oficios, Autos) y se marca el
archivo de la solicitud y se adjunta el auto.
apertura (disciplinario), o una apertura se
procede a Abrir un nuevo caso y se adjunta
el auto o acto. En este evento, si la decisión
es la apertura del caso, se debe pasar los
casos de uso Asignar Identificador único de
caso y Definir Ruta.
acumulación, se vincula a un caso definido
(ver caso de uso Vincular IUS-IUC)
pasándole el (los) identificador(es) único(s)
del caso al que se debe(n) acumular.
8. Se procede a imprimir el auto, acto u oficio,
según caso de uso Generar Oficios, Autos.
• Paso 3: En caso de no existir una dependencia o entidad a la cual remitir el oficio, se

informa del error al usuario Servidor (Abogado) y se aborta la operación.
• Paso 6: Si al menos un caso al cual se debe acumular esta solicitud no existe en el sistema,
se informa del error al usuario Servidor (Abogado) y se aborta la operación.
7. Precondiciones
• Se debe recibir una solicitud correctamente construida.
• Se debe conocer el tipo de solicitud, el cual solo puede ser disciplinario, preventivo,
jurídico o intervención.

• En el evento de generarse oficio de acumulación, el caso a asociar debe existir en el

sistema.
• En el evento de generarse oficio de remisión, la dependencia o entidad deben existir en el

sistema.
8. Post Condiciones
• La información de la actuación realizada debe quedar registrada correctamente en el

sistema, y se debe enlazar al caso de uso que corresponda según el caso.

CASO DE USO ASIGNAR

PRIORIDAD, POLÍTICA Y
PROYECTO A SOLICITUD/CASO

AsignarPrioridadSolicitud.doc

06/07/05 2.0 Revisión observaciones PGN. C.Díaz
Cambio de nombre de Asignar Prioridad
Solicitud a Asignar Prioridad, Política y
Proyecto a Solicitud/Caso.
Se definió prioridad, política y proyecto.
29/07/05 3.0 Revisión últimas observaciones reunión de C.Díaz
cierre.

Caso de Uso Asignar Prioridad, Política y Proyecto

a Solicitud/Caso
El presente caso de uso tiene como objetivo asignar prioridad a una solicitud, así como
adscribir la solicitud/caso a una determinada política institucional y a un proyecto particular
si es del caso.
• Prioridad es el grado de importancia relativa para la PGN, y está determinada por el

grado de connotación de la solicitud o caso (alta, media, baja), para focalizar
esfuerzos. Sirve como criterio de seguimiento para generar alertas. Para la
determinación de la prioridad de un asunto, el sistema debe manejar un listado de
posibilidades – criterios, dentro de los cuales se debe mover el servidor, para
garantizar un adecuado manejo de la opción. (Debe tenerse en cuenta que las
prioridades son dinámicas, así por ejemplo, lo que inicialmente tenía una prioridad
alta, hoy puede bajar de prioridad o viceversa).
Política es una clasificación por línea de acción, las cuales se encuentran definidas
en el mapa estratégico de la entidad. Vale la pena aclarar, que un caso puede
adscribirse a más de una política.
• Un Proyecto se crea para el logro de un objetivo específico. Es un conjunto de

actividades estratégicas que se deben cumplir para el logro de las políticas de la
entidad, por tal razón debe estar adscrito a una política. La asignación de
solicitudes/casos a proyectos puede ayudar a medir avances y logros de proyectos
al interior de la PGN.
2.1 Iteración
0
2.2 Prioridad
Alta
2.3 Complejidad
Media
• Servidor PGN en la Dependencia.

4. Entradas
Solicitud.
5. Salidas
Solicitud priorizada.
6. Flujo de Eventos
6.1 Flujo Básico

servidor se dispone a ingresar los datos
de prioridades, políticas y proyecto de
la solicitud/caso. El servidor entra el
IUS / IUC de la solicitud o caso a
priorizar.
2. Se asigna el nivel de prioridad (puede
hacerse mediante parámetros
establecidos). También puede desplegar
el nivel de prioridad para que sea
seleccionado por el usuario. 1
La prioridad se debe ver como el grado
de importancia, relevancia, seguimiento y
control que se quiere tener sobre el caso.
Esto se traduce en que si bien todos los
casos de competencia de la PGN deben
atenderse de la mejor manera posible,
existen casos que por su trascendencia,
connotación nacional e internacional, su
complejidad, los derechos que se ven
comprometidos, etc…, implican un
mayor esfuerzo comparativamente frente
a los demás.
En este sentido, se debe crear una escala
de prioridades, por ejemplo, baja, media
y alta, en las cuales, se puedan adscribir
todos los casos. Con esto, además de
facilitar el control sobre los casos de
1
Con respecto a la prioridad, lo solicitado por la Procuraduría es que el sistema asigne una prioridad de acuerdo a una
políticas preestablecidas y quede registrada, pero que también exista la posibilidad de que el usuario en esa lista
selecciones una si no está de acuerdo con la asignada por el sistema y que queden las dos registradas en el sistema. La
idea es poder contrastar posteriormente qué pasó entre la prioridad que generó el sistema y lo que asignó el servidor.


mayor relevancia, se previene al servidor
para que le preste mayor atención y
dedicación al asunto.
3. El usuario selecciona la prioridad y la

razón de dicha asignación.
4. La prioridad dada a la solicitud queda

correctamente registrada en el sistema.
(Se registra la generada automáticamente
por el sistema, así como la asignada por
el funcionario si es del caso).
5. El sistema despliega las políticas

institucionales y los proyectos
disponibles en el sistema (SIAM). Este
campo debe ser opcional.
Si el caso se hacer parte de un proyecto, se
selecciona el proyecto y por ende la política,
ya que todos los proyectos deberían estar
adscritos a una política.
Si no hay un proyecto, el usuario puede
seleccionar una política.
6. El usuario selecciona el proyecto y la

política.
7. El proyecto y la política quedan

registrado en el sistema dentro de la
solicitud/caso relacionado.2
2
La información de proyecto es de carácter informativo y para generar consultas posteriores de las solicitudes y/o casos
asociados a los proyectos, principalmente del área preventiva.

• Paso 1: Si el IUS/IUC no corresponde a una solicitud o caso existente en el sistema, se

informa el error y se aborta la operación
7. Precondiciones
• El Identificador único de solicitud o de caso (IUS/IUC) debe existir en el sistema.
• Deben estar almacenadas previamente en el sistema las políticas y proyectos para la

asignación correspondiente a las solicitudes.
8. Post Condiciones
• La solicitud queda correctamente priorizada en el sistema.
Queda pendiente definir la manera como se van a asignar las prioridades automáticamente.

CASO DE USO ABRIR CASO

AbrirCaso v2.0.doc

05/07/05 2.0 Revisión observaciones PGN H. Velásquez
Se cambió el nombre de
AsignarIdentificadorUnicoCaso a Abrir
Caso, para mayor claridad.

Caso de Uso Abrir Caso

El presente caso de uso tiene como objetivo asignar un identificador único de caso (IUC).
Este número servirá para identificar cada caso (preventivo, disciplinario, de intervención o
jurídica) a lo largo de toda la actuación de la PGN, sin importar si el caso cambia de
dependencia en el nivel central, territorial o por traslado de competencia.
Adicionalmente en este punto se incluye información pertinente al caso, que no haya sido
registrada en la solicitud y adicionalmente, el sistema suministra información de la
jurisprudencia relacionada con la materia, la normatividad aplicable, los conceptos y
precedentes que sobre la materia existen en la PGN, con el fin de que el servidor cuente con
información relacionada antes de comenzar a definir la ruta y el plan de acción.
Nota: Si el caso es disciplinario, el número único del caso también debe servir para
identificar el caso en segunda instancia, en éste evento, lo que debe ocurrir es que el sistema
maneje un módulo donde la segunda instancia pueda tomar el caso cuando se recurre alguna
decisión de primera instancia y registrar, tanto la actuación surtida como la decisión. En
esta forma, si alguien consulta el caso, podrá ver si éste ha ido a segunda instancia y en tal
evento, ver cual fue la decisión recurrida, el trámite surtido ante la segunda instancia y la
decisión adoptada. De igual forma, facilita el manejo en segunda instancia, pues si el
proceso va más de una vez a segunda instancia, quien hace la segunda instancia puede ver
en el registro las anteriores actuaciones de segunda instancia y las decisiones. Esta
funcionalidad se hace más eficiente si tanto la decisión de primera instancia como la de
segunda instancia se adjuntan al registro, con lo cual se hace menos necesario consultar el
expediente físico.
procuraduría provincial, éste se podrá remitir directamente al competente o tramitarse ante
la División de Registro y Control, en los eventos en los que exista más de una delegada
En aquellos eventos en los que un caso tiene que ir a segunda instancia y la información de
primera instancia no ha sido registrada en el sistema, antes de remitirse el caso a la
delegada a la regional o a la División de Registro, el responsable del caso deberá ingresar la
información pertinente en el sistema.

2.1 Iteración
0

2.2 Prioridad
Alta
2.3 Complejidad
Baja
• Servidor PGN
• Sistema
4. Entradas
Solicitud valorada.
5. Salidas
Caso con identificador único de caso (IUC) asignado.
6. Flujo de Eventos
6.1 Flujo Básico

1. Este caso de uso comienza cuando la
actuación definida por el servidor de la
PGN corresponde a apertura de caso (ver
caso de uso Definir Actuación).
2. El servidor o funcionario selecciona la
opción de apertura de caso.
3. El sistema despliega al usuario un formulario
de registro con los datos del caso, los valida
y permite guardarlos.
4. El sistema automáticamente asigna un
identificador único de caso para esta
solicitud, y lo registra en el sistema junto
con la información suministrada por el
servidor.
5. Se llama al caso de uso Vincular
Identificador Único de Caso a Identificador
Único de Solicitud. El sistema vincula la
solicitud con el caso abierto, trayendo la
información como histórica.
6. El sistema sugiere automáticamente
normatividad relacionada al caso.

• Paso 3: Si la solicitud no está correctamente armada, se informa el error y se aborta la

operación
7. Precondiciones
• La solicitud de entrada debe estar correctamente armada y registrada en el sistema.
• Se ha descartado la existencia de un asunto o caso en trámite por los mismos hechos.
• Se ha valorado adecuadamente la necesidad de iniciar el caso.
• Se ha descartado la existencia de inhabilidades e incompatibilidades del servidor para

conocer el caso y tramitarlo.
8. Post Condiciones
• Un identificador único de caso es correctamente generado y registrado en el sistema.


CASO DE USO VINCULAR

IDENTIFICADOR UNICO DE
SOLICITUD CON IDENTIFICADOR
UNICO DE CASO

VincularIUS-IUC v2.0.doc

30/06/05 2.0 Observaciones atendidas H. Velásquez, F.
Martínez

Caso de Uso Vincular Identificador Único de

Solicitud con Identificador Único de Caso
El presente caso de uso tiene como objetivo relacionar una solicitud con un caso, mediante
los identificadores correspondientes.
Este caso de uso puede ser utilizado en dos oportunidades: Cuando se abre un caso o
cuando se desea acumular una solicitud nueva a un caso ya existente. Si es en apertura de
caso, el sistema hace la operación automáticamente. Si es por acumulación, el servidor tiene
que suministrar la información de la solicitud y el caso que desea vincular, así como una
justificación de la acción.
2.1 Iteración
0
2.2 Prioridad
Alta
2.3 Complejidad
Baja
Sistema
4. Entradas
Identificador Único de Solicitud
Identificador Único de Caso
5. Salidas
Vinculación IUC-IUS realizada.
6. Flujo de Eventos
6.1 Flujo Básico


1. Este caso de uso se utiliza para vincular
una solicitud a un caso, bien sea por
primera vez cuando se hace la apertura del
caso o por acumulación.
2. Cuando se presenta acumulación, el
servidor selecciona la opción de vincular
solicitud a caso, obteniendo un formulario
para registrar la operación.
3. El sistema despliega formulario para
vincular solicitud con caso.
4. El servidor diligencia el formulario para
vincular la solicitud con el caso y guarda
la información.
5. El sistema vincula el caso a la solicitud
mediante los identificadores entrados.
6. Cuando se presenta vinculación por
apertura de un nuevo caso, el servidor al
utilizar la opción de abrir caso,
automáticamente esta invocando esta
funcionalidad.
7. El sistema vincula el caso a la solicitud
mediante la información del sistema en el
caso de uso abrir caso. Esta acción se haría
de forma automática.
• Si el Identificador único de caso corresponde a un caso inexistente en el sistema, se informa al

usuario y aborta la operación.
• Si el Identificador único de solicitud corresponde a un caso inexistente en el sistema, se informa al

usuario y aborta la operación.
7. Precondiciones
• Tanto el Identificador único de caso como el Identificador único de solicitud deben existir en el
sistema.
8. Post Condiciones
• El sistema registra correctamente la vinculación del IUC al IUS entrados.

CASO DE USO
GESTIONAR ACTORES DEL CASO

GestionarActoresCaso.doc

30/06/05 2.0 Revisión Observaciones PGN. H. Velásquez - C.Díaz
Se aclaro que en este requerimiento se
gestionan los actores distintos a servidores
PGN.
11/0705 2.0 Revisión Observaciones PGN. C.Díaz

Caso de Uso Gestionar Actores del Caso

El presente caso de uso tiene como objetivo registrar en el sistema los actores del caso
(agentes internos o externos) que participan en el proceso pero que no son los titulares de la
responsabilidad del trámite del caso. (Los titulares de la responsabilidad, que pueden ser un
servidor o un equipo de trabajo de la PGN, se asignan en el respectivo caso de uso).
Los actores del caso pueden ser:

- El Disciplinado
Vale la pena aclarar, que éste puede ya formar parte del registro, pues al momento
mismo de registrar la solicitud, si la información se tiene, el encargado de hacer la
radicación debe ingresar los datos del presunto responsable, que para el caso
disciplinario es un servidor público o particular en los casos señalados en la ley,
evento en el que no tiene sentido repetir el registro. De igual forma, al abrir el caso
contra persona determinada, es obligatorio el registro de la persona contra la cual se
dirige la acción disciplinaria.
Para el caso preventivo, se trata de las autoridades que tienen a su cargo la función
que comprende la acción preventiva, por lo cual es probable que desde la misma
radicación se cuente con la información. De igual forma, cuando el asunto se
convierte en caso, es obligatorio registrar la persona o autoridad contra la cual se
dirige la acción preventiva.
En el caso de intervención, los actores pueden ser el Juzgado o Tribunal que conoce
del caso y las partes dentro de éste, razón por la cual desde la misma radicación de
la solicitud puede existir la información.
- Abogado del disciplinado y el suplente si lo tiene.
- El abogado que representa a la víctima o perjudicado, si se ha constituido como
parte dentro del proceso.
- El abogado que representa al quejoso o peticionario.
- ONG nacional o internacional o una organización social, etc.(para el caso del
preventivo)
El sistema debe permitir el registro de los datos básicos de la persona:

- Nombre
- Dirección
- Teléfono, correo, fax
- Rol dentro del proceso (por ejemplo, en disciplinario, defensor de la persona x;
perito para una prueba técnica – el perito puede ser un servidor de la PGN o una
persona externa).

Esta información debe facilitar el envió de oficios o de notificaciones a los actores del
proceso, el sistema podrá tomar datos registrados por cada actor y llevarlos directamente al
oficio. Para las actas de notificación en los disciplinarios, si en el sistema aparecen los datos
de los implicados y sus defensores, al momento de generar el acta de notificación el sistema
debería permitirle al usuario seleccionar de la lista de actores del caso, a la persona que va a
notificar, diligenciar el acta con estos datos y la fecha y permitir al servidor que diligencie
los demás datos y luego imprima el acta para la firma.
El servidor o servidores de la PGN que participan en el caso, serán asignados en el caso de
uso Asignar Servidor/Comisión a Solicitud / Caso, el cual tiene incluido el manejo
respectivo de cargas.
En la lista de actores del caso también se debería contemplar la opción de la Comisión para
la práctica de pruebas en lugar diferente a la sede del funcionario que conoce del asunto,
esto es, que exista la posibilidad de indicar en el sistema a quien (dentro o fuera de la PGN)
se comisiona, el término de la comisión y el objeto, lo cual además permite que el sistema
lleve el control del término de la comisión. De igual forma, una vez se cumpla la comisión,
el servidor que comisionado debe tener la opción de registrar la actuación surtida, con cargo
a su registro de actividades, esto para que sus actividades queden registradas y sumen como
actividad propia para efectos de la evaluación.
También se debería contemplar como opción de registro, es decir, como Actor, a los peritos
que en el curso del proceso disciplinario se designan, pues al igual que la comisión para
pruebas, el peritaje también tiene un término y un objetivo.
2.1 Iteración
0
2.2 Prioridad
Media
2.3 Complejidad
Media
• Servidor PGN
4. Entradas
• UIC del caso al cual se ingresarán los actores.

5. Salidas
• Caso con actores asignados.

6. Flujo de Eventos
6.1 Flujo Básico

servidor encargado del caso requiere
vincular más actores al mismo.
2. El servidor selecciona el tipo de actor
(ejemplo: disciplinado, víctima, quejoso ..)
3. El sistema despliega una pantalla con la
información requerida por cada tipo de actor.
4. El usuario completa la información por
cada actor.
5. El sistema registra correctamente a los
actores del caso.
• Paso 5: Si el IUC corresponde a un caso inexistente, se informa el error y aborta la

operación.
7. Precondiciones
• EL IUC entrado debe corresponder a un caso existente en el sistema.

8. Post Condiciones
• La vinculación de los actores existentes al caso queda registrado correctamente en el

sistema.
Definir que información se requiere por cada tipo de actor.
Definir si se debe validar la existencia de cada actor, ya sea preguntando a la Registraduría
o por cualquier otro tipo de mecanismo.

CASO DE USO DEFINIR RUTA Y

PLAN DE ACTIVIDADES

DefinirRutaPlanActividades v2.0.doc

07/07/05 2.0 Se cambió abogado por servidor F. Martínez
Se dividió el caso de uso administrar ruta y
actividades en dos: Definir ruta y plan de
actividades y Registrar actividades y
actuaciones.

Caso de Uso Definir Ruta y Plan de Actividades

Tiene como objetivo definir la ruta y el plan de acción a seguir en el desarrollo de un caso.
Definir Ruta: El servidor determina el camino a seguir (Marcar ruta), con base en una ruta
sugerida por el sistema siguiendo las consideraciones lógicas y legales correspondientes.
Por ejemplo, si el caso es disciplinario, debe indicar si se va por proceso ordinario o verbal
y en el primero, si se va por indagación preliminar o por investigación. Si es intervención,
debe indicar si es agente especial o agente ordinario. Si es preventivo, la determinación de
la ruta de las acciones que le permitirán comprobar los hechos. La validación de la ruta, en
cuanto validez de las actividades (precedencia, tipo de actividades por área, etc) se hará
teniendo en cuenta las etapas y actividades registradas en el sistema mediante el caso de uso
de SIAM de Administrar etapas, actividades e información asociada.
Definir Plan de Acción: El servidor dice que es lo que va a hacer. El sistema le puede
sugerir algunas actividades, como en derechos humanos, en donde se cuenta para
disciplinario con un manual de pruebas por tipo de violación y para preventivo, con un
instrumento guía. Puede ser un plan general de acción o puede ser detallando una a una las
actividades. El plan también se puede rearmar a medida que transcurre el caso.
El Plan de Acción permitirá al servidor llevar un control ordenado de las actividades a
realizar y su propósito, igualmente, el Plan le permitirá al sistema, controlar los términos,
para el Caso, la etapa o la actividad, según el caso, generando al servidor las alertas
tempranas que se definan.
En este punto el sistema debe aportarle al servidor la siguiente información: Un banco de

plantillas, como herramientas, para que pueda generar los oficios y autos que requiera para
impulsar la actuación, los cuales deberán adjuntarse al registro para facilitar la consulta del
Caso sin tener que recurrir en todo momento al expediente físico.
El sistema sugiere actividades a partir de lo que se registre en el caso de uso de nombre

“AdministrarEtapasActividades v3.0” del sistema SIAM.

2.1 Iteración
0.
2.2 Prioridad
Alta.

2.3 Complejidad
Alta.
• Servidor de la PGN
4. Entradas
• IUC del caso al cual se le va a definir la ruta y el plan de acción.

5. Salidas
• Ruta y plan definido para el caso.

6. Flujo de Eventos
6.1 Flujo Básico

servidor encargado del caso planea la ruta
y el plan de actividades a llevar a cabo en
el caso. El servidor solicita la lista de
etapas válidas para el caso en cuestión para
un IUC dado.
2. El sistema despliega la lista de etapas
predefinidas en SIAM que apliquen al caso
en cuestión, según el área misional asociada
al mismo. Cada etapa puede tener unas
actividades y unos términos sugeridos.
3. El funcionario selecciona la ruta y arma el
plan de actividades.
4. El sistema registra la ruta y el plan de
actividades, y le informa al usuario de la
culminación de la operación. El sistema debe
mostrarle al servidor, la fecha límite para
llevar a cabo las actividades, según los
términos. (Esta fecha se calcula de acuerdo a
los términos previamente registrados en
SIAM para cada actividad).
5. Si el servidor requiere administrar otras
etapas, el sistema le dará la opción de
volver al paso 1, hasta que termine la
operación.

• Paso 1: Si el IUC entrado no corresponde a un caso existente en SIMIP, se informa el error

y aborta la operación.
7. Precondiciones
• El IUC entrado corresponde a un caso existente en SIMIP.
• Las actividades asociadas a las etapas deben estar registradas previamente en el sistema
SIAM.
8. Post Condiciones
• Se registra correctamente los cambios en la ruta de actividades administradas en el sistema

para la información registrada.


ACTIVIDADES Y
ACTUACIONES/DECISIONES

RegistrarActividadesActuaciones v2.0.doc

07/07/05 2.0 Se cambió abogado por servidor F. Martínez
Se dividió el caso de uso administrar ruta y
actividades en dos: Definir ruta y plan de
actividades y Registrar actividades y
actuaciones/decisiones.

Caso de Uso Registrar Actividades y

Actuaciones/Decisiones
Tiene como objetivo registrar las actividades y actuaciones (decisiones) realizadas en el

caso.
Actividades:
Ejemplos de Actividades son: Para Disciplinario: las declaraciones de testigos, las
declaraciones de las víctimas, las visitas especiales, los peritazgos, la exposición
libre de los disciplinados, etc. Para Intervención: Participación en la Audiencia de
Garantías. Para Preventivo: Las visitas, las entrevistas, etc.
Vale la pena aclarar que hay actividades relacionadas con el caso y otras con los
actores del caso. Si se escucha en exposición libre a la persona esta actividad se
encuentra ligada con el actor o si se hace una notificación, en cambio, si se hace
una visita especial, esta actividad esta ligada con el caso.
En el sistema existirá una tabla de posibles actividades (SIAM), para que el usuario
pueda seleccionar la que corresponda, al momento del registro. Estas actividades
tendrán al menos dos indicadores: uno, que señala si la actividad tiene valor para la
evaluación y el otro, la ponderación de la actividad en una escala de valor
previamente definida por la entidad.
Actuaciones / Decisiones:
Hay actuaciones que implican decisiones, por ejemplo, abrir indagación preliminar,
abrir investigación disciplinaria, suspender al servidor investigado, decretar
archivo, formular cargos y dictar fallo.
Al igual que para las actividades, hay algunas decisiones relacionadas con el actor
(ejemplo: sanción, la suspensión y el archivo) y otras relacionadas con el proceso,
como la nulidad.
Al igual que las actividades, las actuaciones forman parte de una lista de posibles
actuaciones, entre las que el usuario puede seleccionar la que corresponda. De la
misma manera, las actuaciones tendrán unos indicadores donde se precise su valor
para efectos de la evaluación. En la lista de actuaciones, se puede además agregar,
un indicador de etapa a la cual aplica la decisión, pues por ejemplo, el fallo solo
aplica si el caso disciplinario ha superado la fase de juzgamiento con traslado a los
sujetos procesales para presentar alegatos previos al fallo.

Debe tenerse en cuenta que si la decisión es por ejemplo, el archivo de la actuación

disciplinaria o el fallo, lo que sigue en la ruta de actividades, es la notificación de la
decisión, y en este evento, el sistema debe tener en cuenta los términos señalados
en la ley para que la decisión cobre ejecutoria.
Esta información de indicadores y términos será manejada en SIAM – Ver caso de uso
Administrar Etapas, Actividades, Actuaciones e Información Asociada. Así mismo, en este
caso de uso el sistema tendrá los documentos y plantillas asociadas por actividad, de
manera que en el momento en que se este registrando la actividad, el sistema pueda sugerir
los documentos y plantillas a utilizar y pueda generar de manera automática dichos
documentos. Ejemplo: El sistema debería operar automáticamente en la ejecutoria, por
ejemplo, cuando el encargado acude a la plantilla “Constancia de Ejecutoria”, el sistema
debería diligenciar automáticamente los datos de la plantilla con la información del caso.
Esto facilitaría el trabajo del servidor y haría más eficiente el registro, pues en muchos
casos las decisiones cobran ejecutoria pero el responsable no registra los datos en el sistema
quedando abierta la decisión o el proceso, cuando se trata del archivo o el fallo.

2.1 Iteración
0
2.2 Prioridad
Alta
2.3 Complejidad
Alta
• Servidor de la PGN
4. Entradas
• UIC del caso a registrar actividad y habilitado para recibir actividades.
• Información de la actividad a registrar, incluida la etapa a la que pertenece.

5. Salidas
• Actividad registrada correctamente en el sistema y asociada al caso entrado.

6. Flujo de Eventos
6.1 Flujo Básico


servidor encargado de un caso, habilitado
dentro de los términos definidos, para
registrar actividades o actuaciones.
2. El sistema despliega el plan de actividades,
el usuario puede seleccionar una de esas
actividades para registrar el detalle de la
actividad realizada. Si es una actividad,
despliega la tabla de actividades posibles, y
si es una actuación, despliega ésta tabla
(tomado de SIAM).
3. El servidor completa la información por
actividad (fecha) y anexa los documentos
relacionados si es del caso, por ejemplo, si
se trata de una declaración o la exposición
libre del implicado, y se cuenta con la
diligencia en medio magnético. Esto
facilita la consulta del caso sin tener que
recurrir permanentemente al expediente
físico. El sistema debería permitir que se
registren anotaciones a las actividades o
decisiones, por ejemplo, el nombre del
declarante.
NOTA IMPORTANTE: si se agregan las
decisiones y las pruebas, se debe tener en
cuenta la reserva del caso. Esto limitaría la
consulta para ciertos usuarios.
4. El servidor puede ingresar actividades que
no hayan sido incluidas en el plan de
acción, evento en el que el sistema debe
identificar (con un flag) que esta tarea no
había sido planeada.
Cuando la actuación que se registre
implique un cambio de etapa, el sistema
debe actualizar el registro indicando el
recorrido histórico del Caso y su etapa
actual.
5. El sistema registra las actividades o la
decisión, y le informa al usuario de la
culminación de la operación.
6. Si el servidor requiere administrar otras
etapas, el sistema le dará la opción de
volver al paso 1, hasta que termine la
operación.

• Paso 1: Si el IUC entrado no corresponde a un caso existente en SIMIP, se informa el

error y aborta la operación.
• Paso 6: Si la información entrada para una actividad es inválida, se informa el error y

7. Precondiciones
• El IUC entrado corresponde a un caso existente en SIMIP.
• Las fechas sugeridas para los términos, deben ser mayores a la fecha de registro de la
actividad.
8. Post Condiciones
• Se registra correctamente los cambios en las actividades y actuaciones de cada caso.

Revisar el tema de argumento – contra-argumento (ejemplos enviados por Jorge Eliécer)
Revisar en diseño detallado los mecanismos de control para permitir la administración de
actividades dentro de un caso dado según los términos definidos.

CASO DE USO ALERTAR

VENCIMIENTO CASO

AlertarVencimientoCaso.doc

06/07/05 2.0 Revisión observaciones PGN H. Velásquez

Caso de Uso Alertar Vencimiento Casos

El presente caso de uso tiene como objetivo generar alertas sobre el próximo vencimiento
de alguno de los casos, términos o decisiones de las etapas o actividades/actuaciones
definidas para un caso. Este será un proceso automático que barre los casos y sus etapas, y
genere unas alertas de los términos que están a punto de vencerse, de acuerdo a unos
parámetros de fechas y requisitos establecidos.
Se debe considerar la generación de varios tipos de alerta. Por ejemplo, unas alertas
tempranas y otras alertas de términos vencidos. Las primeras darán al servidor de la PGN
tiempo suficiente para la ejecución de la tarea, las segundas pueden ser utilizadas para el
monitoreo de actividades.
El manejo de alertas debe estar relacionado con la prioridad de los casos. El manejo de
prioridades se debe ligar a los esquemas de seguimiento y control, brindando mayor
atención a los casos con prioridad alta. En este sentido, el sistema debe manejar alertas y
escalamientos distintos a los que pueda generar para casos que tienen prioridad media o
baja.

2.1 Iteración
0
2.2 Prioridad
Media
2.3 Complejidad
Alta
• SIMIP
4. Entradas
• Fecha del día en que se corre el proceso automático.
• Diferencia de fechas para considerar que un término está a punto de vencerse.
• Conjunto de casos activos en el sistema.

• Definición de los términos del caso y las etapas.
• La justificación o fundamentación de la decisión. Este se aplica al caso de la

generación de alertas para casos preventivos. Un ejemplo de decisión en el caso
preventivo es “archivo”.
5. Salidas
• Listado de términos de un caso particular que están a punto de vencerse.
• Listado de casos que están a punto de vencerse.
• Alertas generadas sobre dicho listado.
6. Flujo de Eventos
6.1 Flujo Básico

1. SIMIP lanzará un proceso automático
según los parámetros (fecha, hora,
periodicidad, etc) definidos en la tarea
programada asociada.
2. Una vez lanzado el proceso, el sistema
barrerá todos los casos activos que tengan
etapas o actividades con términos vigentes.
3. Por cada caso encontrado, se revisarán los
términos vigentes. En caso de haberse
superado la fecha límite, el sistema incluye
el caso en la lista de casos con términos
vencidos. Si el término aún está vigente
pero se encuentra en el rango definido para
disparar alerta según la prioridad definida
para el término, el sistema incluye el caso en
la lista de casos con términos a punto de
vencerse. Incluso se pueden manejar rangos
de alertas tempranas, por ejemplo: casos con
vencimiento en los próximos 30 días – 60
días – 90 días, también se puede manejar
otra categoría en la que se muestren los
casos con términos vencidos, lo cual
también puede hacerse con rangos (estas dos
opciones deben ser parametrizables)
También puede pensarse en esta opción de
alertas para el superior, lo cual facilita el
control de los procesos y la determinación


de las acciones que se deben seguir para
superar la situación.
4. Una vez armada la lista de casos con
términos vencidos o a punto de vencerse, se
genera un correo electrónico de alerta al
servidor a cargo de cada caso encontrado en
esta lista. Adicionalmente, se genera un
reporte de las alertas generadas el cual es
almacenado en un depósito de informes. Las
alertas se pueden manejar de dos formas: a
través del correo o a través de un reporte que
genera el sistema y al cual puede acudir el
usuario cuando requiera ver el estado de sus
procesos, este reporte se irá acrecentando
cada vez que un nuevo caso entre en el
rango definido y también se irá descargando
cada vez que el servidor adopte la decisión
correspondiente. Este reporte debe manejar
íconos descriptivos para que el servidor
entienda mejor cuales son los casos que
están por vencerse (i.e una carpeta amarilla)
y los vencidos (i.e. una carpeta roja).
5. En cualquier momento, el funcionario
encargado de la entidad podrá consultar el
reporte de las alertas generadas.
• Paso 2: Si alguno de los parámetros de entrada (fechas, o diferencias) no están

correctamente armadas en el sistema, se aborta e informa el error.
7. Precondiciones
• La lista de casos con términos por vencer deben ser existentes en el sistema.
• Las fechas de entrada deben ser válidas.

8. Post Condiciones
• Se generan correctamente las alertas de casos con términos a punto de vencerse.

Ninguno.


CONCLUSIONES

RegistrarConclusiones v2.0.doc

Se cambio el nombre del requerimiento,
dejándolo sólo como el registro de
conclusiones (las decisiones se registran en
el caso de uso de registrar actividades y
actuaciones/decisiones realizadas)

Caso de Uso Registrar Conclusiones

El presente caso de uso tiene como objetivo permitir al servidor registrar las conclusiones
en el análisis del caso, una vez se haya emitido la decisión, concepto o informe que pone fin
a la actuación de la PGN Debe constar de una sección donde en forma resumida el servidor
registra las conclusiones del caso y debe tener la posibilidad de adjuntar información
adicional como anexo.
Esta sección de conclusiones puede incluir una plantilla en la que se pueden, por ejemplo,
manejar temas y subtemas, normatividad aplicada para la solución del caso y un breve
resumen de la solución del caso y las razones o fundamentos. Registro que además, puede
facilitar el trabajo de relatoría.
2.1 Iteración
0
2.2 Prioridad
Alta
2.3 Complejidad
Alta
• Servidor PGN.
4. Entradas
Identificador Único de Caso (IUC)
5. Salidas
Campo memo con el resumen (conclusiones del caso).
6. Flujo de Eventos
6.1 Flujo Básico


1. Este caso de uso comienza cuando termina
la actuación de la PGN con solución del
caso y el servidor encargado procede a
registrar las conclusiones de la decisión.
2. El servidor ingresa un campo de resumen
con las conclusiones. Puede anexar un
documento si lo estima conveniente.
3. El sistema registrará correctamente la
información entrada por el usuario según el
flujo de eventos.
• Paso 2: Si el IUC no corresponde a un caso existente en SIMIP, se informa el error y se

7. Precondiciones
• El IUC del caso a concluir, corresponde a un caso existente en SIMIP.
• Las conclusiones a ingresar son un texto válido.
• Los documentos a ingresar contienen información válida.

8. Post Condiciones
• La información de las conclusiones del caso es correctamente ingresada al sistema junto

con los documentos anexos.
Este requerimiento se puede encadenar con el caso de uso “SIMIP_INT_4Sugerir Caso”

CASO DE USO
GENERAR OFICIOS, AUTOS, ETC

GenerarOficios,Autos.doc

23/06/05 2.0 Revisión observaciones PGN C.Díaz, , F. Martínez

Caso de Uso Generar Oficios, Autos, etc

El presente caso de uso tiene como objetivo elaborar los documentos de comunicaciones
(ejemplo: autos, actos, oficios) requeridos en el trámite de una solicitud o caso. Para ello se
cuenta con plantillas preestablecidas en SIAM, que pueden ser importadas como guía del
documento. Una vez el usuario ha completado el documento, el software debe validar que
los campos requeridos han sido diligenciados y adjuntarlo al registro – solicitud o caso.
Vale la pena aclarar, que para algunas plantillas, el sistema podrá automáticamente llenar
los campos con base en la información del caso y una vez revisado por el usuario podrá ser
anexado al caso. El caso de uso de SIAM (Administrar Etapas, Actividades, Actuaciones e
Información Relacionada) describe una tabla básica del sistema que relaciona documentos
(plantillas) con actividades/actuaciones, la cual permitirá al sistema de manera automática
cuando se registra una actividad o actuación en el sistema, desplegar una lista de
documentos asociados. Una vez seleccionado el documento, el sistema traerá
automáticamente la plantilla diligenciada con los datos del registro. Una vez el documento
este completo se anexará al caso.

2.1 Iteración
0
2.2 Prioridad
Media
2.3 Complejidad
Media
Servidor PGN
4. Entradas
• IUC o IUS del oficio, acto o auto a asociar.
• Información del Oficio, acto o auto.

5. Salidas
• Oficio, acto o auto correctamente generado.

6. Flujo de Eventos
6.1 Flujo Básico

servidor encargado del asunto o caso desea
elaborar un oficio, acto o auto, a partir de
un caso de uso (i.e. Definir Actuación,
Registrar Actividades y Actuación/
Decisión realizadas).
2. El sistema despliega una lista de plantillas
predefinidas (SIAM) que servirán como guía
para la elaboración del documento. Esta
lista se obtendrá consultando las plantillas
que apliquen a la actividad para la cual se
está generando el documento.
3. El sistema automáticamente incluye la
información del registro en la plantilla o
formato.
4. El usuario ingresa la información adicional
si es del caso, y confirma que la plantilla
este diligenciada correctamente.
5. El documento generado se asocia al caso
como anexo, y se asocia al caso.
• Si el IUC o IUS al que se debe asociar el auto no existe, se informa el error y aborta la
operación.
• Si la información asociada al documento a generar es inválida, se informa el error y

7. Precondiciones
• El IUS o IUC deben corresponder a solicitud / caso existentes en el sistema
• La información del documento debe ser válida.

8. Post Condiciones
• El documento es generado correctamente y asociado al IUC o IUS correspondiente.


CASO DE USO MARCAR CIERRE

CASO

MarcarCierreCaso.doc


Caso de Uso Marcar Cierre Caso

El presente caso de uso tiene como objetivo cerrar el caso. Consiste en cambiar el estado
del registro en el sistema, indicando que el caso esta cerrado.
En algunos casos el sistema automáticamente puede cerrar el caso, para no tener que
hacerlo en forma manual. Por ejemplo, en disciplinario, si el servidor registra en el sistema
la decisión de archivar la actuación disciplinaria y ésta cobra ejecutoria, sin importar si es
en primera o segunda instancia, el sistema puede cerrar el caso. Lo mismo ocurre cuando
con la decisión de remitir la actuación a otra autoridad, aún cuando en este caso, no opera la
ejecutoria.
En el caso de uso Administrar Etapas, Actividades, Actuaciones e Información Relacionada
de SIAM, se incluirá un flag llamado Cierra Caso, el cual se colocará con valor positivo
para las actividades que impliquen el cierre del caso, de manera que la operación se pueda
llevar a cabo en forma automática.
Cuando se produce el cierre de un caso, el sistema debe reflejar la situación en el mapa de
carga laboral del servidor.
2.1 Iteración
0
2.2 Prioridad
Alta.
2.3 Complejidad
Baja.
• Servidor PGN
4. Entradas
Caso en estado activo.
5. Salidas
Caso en estado inactivo (para decisiones, activo para archivo).

6. Flujo de Eventos
6.1 Flujo Básico

1. Este caso de uso se activa cuando cesa la
actuación de la PGN.
2. El servidor selecciona la opción de cerrar
de caso, y entra el IUC (identificador único
de caso) a cerrar. Salvo aquellos eventos
en los que el sistema puede cerrar en forma
automática el caso.
3. El sistema :
- Registra el cierre del caso en el sistema,
- Se revisa la tabla de retención documental
para calcular el tiempo que debe
permanecer el expediente en la dependencia
antes de pasar a archivo central, y dicha
información se asocia al cierre.
- Se descarga el caso al servidor o servidores
Nota: Debe tenerse en cuenta que la

actuación y las decisiones adoptadas en el
curso del caso, no pueden ser alteradas ni
eliminadas y que tampoco se pueden agregar
nuevas actuaciones, sin embargo, el proceso
queda activo para el responsable del archivo,
quien podrá registrar el lugar de ubicación
del expediente, la fecha del archivo físico,
conformación y estado. (La pantalla del caso
de uso manejar ubicación del expediente en
la dependencia es la única que se puede
modificar una vez el caso este cerrado).
• Paso 3: Si el IUC del caso a cerrar no es un caso existente en SIMIP, se informa el

error y se aborta la operación.
• Paso 3: Si el IUC del caso entrado no corresponde a un caso abierto, se informa el error

7. Precondiciones
• El IUC entrado corresponde a un caso existente y abierto en SIMIP.

8. Post Condiciones
• Se registra correctamente la información asociada al cierre del caso para el IUC entrado,
con la posibilidad de activarlo temporalmente para agregar actuaciones relacionadas a
tutelas y demandas que pueden ocurrir después del cierre del mismo.

CASO DE USO MARCAR ARCHIVO

FÍSICO DEL CASO

MarcarArchivoFisicoCaso.doc

06/07/05 2.0 Revisión observaciones PGN C.Díaz

Caso de Uso Marcar Archivo Físico del Caso

El presente caso de uso tiene como objetivo indicar que la documentación asociada al caso ya
ha sido enviada a Archivo Central. Esta acción se realiza una vez el caso ha pasado a cosa
juzgada (para disciplinario), acción preventiva concluida (para preventivo) o proceso de
intervención concluido (para intervención o jurídico) y se cumpla la fecha estipulada para
establecer dicha acción (ver caso de Uso Marcar Cierre del Caso). Este marcado se realiza
mediante un proceso automático que verifica los casos cerrados que son candidatos a pasar a
Archivo Central, escogiendo los que deben pasar y haciendo la anotación respectiva.
2.1 Iteración
0
2.2 Prioridad
Media
2.3 Complejidad
Media
SIMIP
4. Entradas
UIC de un caso cerrado para enviar a Archivo Central.
5. Salidas
Caso enviado a archivo central satisfactoriamente.
6. Flujo de Eventos
6.1 Flujo Básico

administrador de tareas programadas del
sistema detecta que debe correr el proceso
de cierre físico de casos.


2. El proceso pide el conjunto de casos por
cerrar candidatos a cierre físico.
3. El sistema genera la .información de los
casos candidatos.
4. El proceso obtiene de los casos candidatos,
aquellos cuya fecha es mayor o igual a la
fecha calculada para paso a archivo central
en el momento del cierre (ver caso de uso
Marcar Cierre Caso).
5. Por cada caso encontrado, le pide al
sistema que marque el cierre físico del
caso.
6. El sistema registra el cierre físico del caso
exitosamente.
• Paso 4: Si alguno de los casos a cerrar no es un caso existente en SIMIP, se informa el error
• Paso 4: Si alguno de los casos consultados no corresponde a un caso cerrado y candidato

para pasar a archivo central, se informa el error y se aborta la operación.
7. Precondiciones
• Ninguna
8. Post Condiciones
• Los casos encontrados que cumplan con los criterios definidos para pasar a Archivo
Central, son marcados como cerrados físicamente.
Se podría pensar en invocar el caso de uso Manejar ubicación de la archivo de la dependencia, para ajustar
los datos y reflejar que se encuentra en el archivo central.

CASO DE USO MANEJAR

UBICACIÓN DEL ARCHIVO EN
LA DEPENDENCIA

ManejarUbicacionArchivoDependencia.doc

08/07/05 2.0 Revisión Interna C.García

Caso de Uso Manejar Ubicación del archivo en la

Dependencia
El presente caso de uso tiene como objetivo permitir el registro de la ubicación y seguimiento de los
expedientes en las dependencias hasta que el expediente (documento físico) pase a archivo Central.

2.1 Iteración
0
2.2 Prioridad
Baja
2.3 Complejidad
Baja
Servidor PGN
4. Entradas
Caso registrado en SIMIP y documentos asociados al mismo.
5. Salidas
Información de seguimiento de los documentos de un caso registrados en SIMIP.

6. Flujo de Eventos
6.1 Flujo Básico

1. Este caso de uso inicia cuando un Caso ha
concluido y los documentos físicos deben
pasar al encargado del archivo para su
almacenamiento. En esta instancia, el
servidor de la dependencia responsable de un
caso debe registrar la ubicación de los
documentos físicos que tiene a su cargo, y
están relacionados a un caso.
2. El sistema toma el IUC del caso a cerrar, y lista
los documentos físicos asociados a la solicitud,


que se deben administrar.
3. Por cada documento del listado, el servidor
registra los campos correspondientes a la
ubicación del mismo que son como mínimo:
- dependencia
- fecha de recibo
- numero de cuadernos y folios
- lugar de ubicación
- tipo de documento (medio audiovisual, etc)
- estado de lo que recibió
5. El sistema registra la información de ubicación

de los documentos correctamente en el sistema.
• Paso 3: Si el IUC entrado no corresponde a un caso válido en el sistema, se informa el error y

• Paso 5: Si la información de ubicación no corresponde a información válida, se informa el

7. Precondiciones
• La información de ubicación del documento es válida.
8. Post Condiciones
• La información de ubicación para el documento físico asociado al caso dado es registrada en

el sistema.


PRÉSTAMO EXPEDIENTES

AdministrarPrestamoExpedientes.doc


Caso de Uso Administrar Préstamo Expedientes

El presente caso de uso tiene como objetivo administrar el manejo de préstamo de expedientes al interior de
la PGN. Por cada préstamo que se realice, se debe registrar como mínimo:
- Fecha de préstamo
- Término del préstamo. Si se pasa de este término, se debe generar una alerta.
- Que se presto (folios, tipo de documento, etc)
- Servidor a quien se prestó
- Dependencia

2.1 Iteración
0
2.2 Prioridad
Baja
2.3 Complejidad
Baja
Servidor PGN
4. Entradas
Caso registrado en SIMIP y documentos asociados al mismo.
5. Salidas
6. Flujo de Eventos
6.1 Flujo Básico

1. El caso de uso inicia en el momento en que
un documento se pide prestado, o cuando el
servidor responsable de un caso desea ver los
términos de los documentos que tiene
prestados.
2. El servidor responsable del documento entra
el IUC del caso que contiene el documento a
prestar.

3. El sistema lista los documentos físicos

asociados a la solicitud, dando la posibilidad al
usuario de escoger el documento que se desea
prestar. En este listado el servidor podrá ver
los términos de los documentos que ha
prestado, o si el documento está disponible para
lo cual dará la opción de elegirlo para prestarlo.
4. El servidor ingresa la información del
préstamo del documento (ver descripción
breve).
5. El sistema ingresa la información del préstamo
del documento.
• Paso 3: Si el IUC entrado no corresponde a un caso válido en el sistema, se informa el error y se

• Paso 5: Si la información de préstamo no corresponde a información válida, se informa el error y

7. Precondiciones
• La información del préstamo del documento es válida.
8. Post Condiciones
• La información de préstamo para el documento físico asociado al caso dado es registrada en el

sistema.

CASO DE USO INDICAR

CUMPLIMIENTO EN CASO
PREVENTIVO

IndicarCumplimientoCasoPreventivo.doc

04/05/05 1.0 Versión Inicial Disney Rubiano – H.
Velásquez
07/07/05 2.0 Se cambio abogado por servidor de la PGN. F. Martínez
Se incluyeron recomendaciones PGN.

Caso de Uso Indicar Cumplimiento en Caso

Preventivo
El presente caso de uso tiene como objetivo permitir que sobre el sistema SIMIP, se indique
a un caso que tiene control de advertencia, si la Entidad hizo o dejó de hacer lo que
normativamente le correspondía. Si la indicación tiene connotación positiva, se le debe
deshabilitar el control de advertencia.
Deben quedar previamente registradas las recomendaciones contenidas en el informe final,
ligándolas al seguimiento, para que en este caso de uso se puedan registrar los avances en el
cumplimiento de las recomendaciones u observaciones formuladas por la PGN en el marco
de la acción preventiva. Como la acción preventiva puede recaer simultáneamente sobre
varias entidades, las recomendaciones deberían atarse a la entidad para facilitar el
seguimiento y verificación de cumplimiento, por ejemplo, chequeando en la lista cuales se
van cumplimiento, la forma de cumplimiento, la fecha y la persona responsable
2.1 Iteración
0
2.2 Prioridad
Media
2.3 Complejidad
Baja
Servidor de la PGN.
4. Entradas
UIC de un caso preventivo.
5. Salidas
Información de control de advertencias asociadas al caso si existen.
6. Flujo de Eventos
6.1 Flujo Básico


servidor encargado del caso desea
consultar o registrar el cumplimiento dado
al control de advertencias para el caso en
cuestión. Este entra el UIC del caso
preventivo.
2. El sistema trae la información disponible
para el caso seleccionado, incluyendo la
información de alertas registradas
previamente (ver caso de uso Alertar
Vencimiento Casos).
3. El servidor indica si se dio o no
cumplimento a las recomendaciones y se
indica cual Entidad cumplió.
4. El sistema registra la información e inactiva
el control de advertencia. En caso de
incumplimiento se llama al caso de uso
Generar Oficios Autos para generar los
documentos correspondientes.
• Paso 2: Si el IUC no corresponde a un caso existente en SIMIP, se informa el error y se

• Paso 2: Si el caso no corresponde a un caso preventivo, se informa el error y se aborta la

operación.
7. Precondiciones
• El IUC del caso a concluir, corresponde a un caso preventivo existente en SIMIP.

8. Post Condiciones
• Se registra si la entidad cumplió con las tareas de acuerdo al control de advertencias para
el caso preventivo dado.


SEGUIMIENTO

RegistrarSeguimiento.doc

04/05/05 1.0 Versión Inicial Disney Rubiano – H.
Velásquez
07/07/05 2.0 Se cambió abogado por Servidor de la F. Martínez
PGN.
Se incorporaron las observaciones
formuladas por Jorge Eliécer Gaitán.

Caso de Uso Registrar Seguimiento

El presente caso de uso tiene como objetivo permitir que sobre el sistema SIMIP, se
registren las diferentes actividades que realiza el servidor PGN en torno a las actividades de
seguimiento a la Entidad objeto del caso de prevención, que está bajo seguimiento. Por cada
gestión realizada, el servidor debe indicar las acciones realizadas, la fecha en que se
desarrolló y los resultados obtenidos.
2.1 Iteración
0
2.2 Prioridad
Media
2.3 Complejidad
Media
Servidor de la PGN
4. Entradas
UIC con un caso preventivo que esté bajo control de advertencia.
Información relacionada a las actividades de seguimiento a ingresar a SIMIP.
5. Salidas
Actividades de seguimiento asociadas a un caso registradas en el sistema.
6. Flujo de Eventos
6.1 Flujo Básico

servidor encargado del caso se dispone a
ingresar un conjunto de actividades de
seguimiento a un caso preventivo. Este
entra el UIC del caso preventivo que se


encuentre bajo control de advertencia.
2. El sistema trae la información disponible
para el caso seleccionado, incluyendo la
información de alertas registradas
previamente (ver caso de uso Generar
Alertas Caso Preventivo).
3. El usuario entra la opción de registrar una
actividad de seguimiento. Hecho esto,
ingresa la información relativa a la
actividad.
4. El sistema registra correctamente la
información de la actividad de seguimiento y
la asocia al caso preventivo entrado.
5. El sistema le permitirá al usuario ingresar
otra actividad, en cuyo caso vuelve al paso
3 hasta que no tenga mas actividades de
seguimiento para ingresar.
• Paso 2: Si el UIC no corresponde a un caso existente en SIMIP, se informa el error y se

• Paso 2: Si el caso no corresponde a un caso preventivo bajo control de advertencia, se

informa el error y se aborta la operación.
• Si la información de la actividad de seguimiento a ingresar no es válida, se informa el

7. Precondiciones
• El UIC del caso a concluir, corresponde a un caso preventivo bajo control de

advertencia existente en SIMIP.
• La información relacionada a las actividades de seguimiento a ingresar es válida.

8. Post Condiciones
• La información de las actividades de seguimiento son correctamente registradas en

SIMIP y asociadas al caso preventivo entrado.
Ninguno.

CASO DE USO REABRIR CASO

ReAbrirCaso v3.0.doc


Caso de Uso Reabrir Caso

El presente caso de uso tiene como objetivo permitir la reapertura de un caso. Este caso de
uso debe cambiar el estado del caso que ya estaba cerrado, esta situación se presenta cuando
un caso que ya ha sido fallado debe ser revisado nuevamente por eventos como el de una
tutela.

2.1 Iteración
0
2.2 Prioridad
Alta
2.3 Complejidad
Baja
Servidor PGN
4. Entradas
Caso cerrado.
5. Salidas
Caso reabierto.
6. Flujo de Eventos
6.1 Flujo Básico

1. Este caso de uso comienza cuando la
actuación definida por el servidor de la
PGN corresponde a reapertura de caso.
opción de reapertura de caso y selecciona


un número de caso IUC.
3. El sistema despliega al usuario un formulario
de registro con los datos de la razón por la
cual se esta reabriendo el caso, los valida y
permite guardarlos. Esta razón debe quedar
registrada como una actividad.
4. El sistema automáticamente cambia el
estado del caso, y lo registra en el sistema
junto con la información suministrada por el
servidor.
• Paso 3: Si el caso seleccionado había sido cerrado con información suministrada a SIRI,
se deberá generar una alerta.
7. Precondiciones
• El caso seleccionado esta en estado cerrado.

8. Post Condiciones
• Se cambia el estado del caso.


CASO DE USO GENERAR

LISTADO DE FALLOS NO
ENVIADOS A SIRI

ListadoFallosNoEnviadosaSiri v3.0.doc


Caso de Uso Generar listado de fallos no enviados

a SIRI
El presente caso de uso tiene como objetivo generar un listado de alerta de los fallos que se
han registrado en SIMIP pero que no han sido enviados a SIRI.
El caso de uso Transmitir sanciones SIMIP a SIRI, permite diligenciar el formato SIRI
desde SIMIP para que pueda ser enviado por el usuario al SIRI. Dado que la opción de
envío de dicha información es manual y no automática, existe la posibilidad de que el
usuario no envié a SIRI un fallo determinado. El objetivo de este caso de uso es generar un
listado que permita revisar periódicamente la relación de casos fallados en SIMIP contra
SIRI.

2.1 Iteración
0
2.2 Prioridad
Alta
2.3 Complejidad
Baja
• Servidor PGN
4. Entradas
Listado de casos con fallos sancionatorios en SIMIP en un período determinado.
5. Salidas
Reporte.
6. Flujo de Eventos
6.1 Flujo Básico


1. Este caso de uso comienza cuando un
usuario desea saber los casos con fallo
sancionatorio en SIMIP no reportados al
SIRI.
opción de generación del listado.
3. El sistema genera un listado con los fallos
que no han sido enviados al SIRI (esta
información se puede obtener de un flag que
puede ser actualizado al momento del envío
de las sanciones a SIRI).
• Ninguno.
7. Precondiciones
• Se reciben parámetros del reporte.

8. Post Condiciones
• Se genera un listado.


EQUIPOS DE TRABAJO

AdministrarEquiposTrabajo v3.0.doc

12/07/05 2.0 Versión Inicial. Corresponde a la D. Rubiano
25/07/05 3.0 Se actualizó teniendo en cuenta que las D. Rubiano
comisiones son “dependencias virtuales” y
que las personas que se asignan a un caso
conforman un equipo de trabajo. Se pasó el
caso de uso del sistema SIAM al sistema
SIMIP.

Caso de uso Administrar Equipos de Trabajo

El presente caso de uso tiene como objetivo permitir sobre el sistema SIMIP, para un caso
en particular: Definir, consultar, actualizar e inactivar la información concerniente a los
equipos de trabajo, los roles que los componen y los servidores PGN inscritos en dichos
roles.
Un equipo de trabajo puede ser creado bajo uno de dos tipos: Equipo de trabajo titular –
Responsable del desarrollo de un caso, Equipo de trabajo no titular – De apoyo en el
desarrollo de un caso. Un Equipo de trabajo lo componen roles tales como por ejemplo
“Jefe de equipo” e “Investigador”.
2.1 Iteración
0.
2.2 Prioridad
Media.
2.3 Complejidad
Baja.
Procurador Delegado, Regional o Territorial, Jefe o Coordinador de Grupo.
4. Entradas
Se debe proporcionar:
Consulta:
Código del caso y/o
Código del equipo de trabajo.
Ingreso:

Para ingreso de datos, se necesitaría la información concerniente al equipo: Carga del caso
al cual será asignado el equipo, Código de dicho caso, Tipo de equipo (Por ejemplo: Equipo
titular, Equipo de apoyo), Código del equipo, Nombre, Propósito de la creación del equipo,
Descripción, Identificaciones de los roles que se definan para el equipo, y los servidores-
PGN que se inscriben en cada uno de los roles. En este punto se debe tener en cuenta que
un servidor PGN puede estar asociado a más de un rol y un rol tiene asociado a más de un
servidor PGN1.
Actualización:
Para ingreso de datos, se necesitaría la misma información del punto anterior.
Inactivación:
Se debe suministrar el código del caso y/o del equipo de trabajo.
5. Salidas
Consulta:
Se despliegan los datos de un registro almacenado en el sistema, asociado a un equipo de
trabajo, cuyo código es el mismo suministrado en la entrada (en caso de haberse
diligenciado – seleccionado de forma directa el equipo de trabajo) o en su defecto es un
código de equipo de trabajo asignado al caso, cuyo valor de código es el mismo de la
entrada.
Ingreso:
Se crea y almacena un nuevo registro con los datos de un equipo de trabajo.
Actualización:
Se modifican algunos de los datos de un registro de un equipo de trabajo.
Inactivación:
Se marca el registro del equipo de trabajo como inactivo.
6. Flujo de Eventos
6.1 Flujo Básico
1
El usuario deberá seleccionar de una lista de servidores PGN, aquellos que aún cuentan con disponibilidad y que
corresponde en sus características con el rol que se está ingresando. La lista de servidores PGN, se genera a partir de
una consulta sobre la información cargada desde el Sistema de Recursos Humanos. Como mínimo la lista debe
desplegar por cada servidor PGN, el nombre, el cargo y la dependencia.


del sistema SIMIP, selecciona una opción:
de un equipo de trabajo.
seleccionada. En dicha pantalla se muestra una
lista con todos los nombres, dependencias, cargos
e identificaciones de los servidores de la PGN.
3. El usuario del sistema ingresa los datos del
equipo de trabajo. Por cada rol que establezca,
selecciona de la lista de servidores PGN, los
que ha definido que deben ser ingresados como
parte de dicho rol. Ejecuta la opción de
almacenamiento. En caso de querer identificar
el detalle de la información de un servidor
PGN, puede ejecutar el caso de uso
“AdministrarServidorPGN”, bajo la opción de
consulta.
4. El sistema SIMIP valida que las
disponibilidades de los servidores PGN
seleccionados coincida con la carga del caso al
cual será asignado el equipo de trabajo. El
sistema crea y almacena un registro con los datos
suministrados en la pantalla.
el sistema despliega una de dos pantallas: Una
con la lista de casos, otra con la lista de equipos
de trabajos creados. Esto con el ánimo de que el
usuario seleccione el caso/el equipo de trabajo
sobre el cual desea hacer la consulta.
6. Si se trata de un caso, al seleccionarlo, se
desplegará una lista con todos los equipos de
trabajo asignados a dicho caso, una vez esto
suceda, estando en la lista de equipos, trátese
de cualquiera de las opciones iniciales de
pantalla de la línea 5, el usuario selecciona
sobre la lista de equipos, el que quiere
consultar. Al hacer la selección se obtiene el
código del equipo de trabajo, para hacer la
correspondiente búsqueda del registro
asociado.
y despliega los datos que lo componen
(Equivalentes a los de la entrada para ingreso). El


sistema identifica los permisos del usuario.
ejecutan las líneas 5, 6 y 7. Adicionalmente,
despliega sobre la misma pantalla, los datos de
los servidores PGN que podrían integrarse a los
roles del equipo de trabajo.
correspondientes servidores PGN sobre los
diferentes roles. Puede agregar nuevos roles y
sus correspondiente servidores PGN, también
puede eliminar roles. Puede adicionalmente
cambiar valores como el nombre y tipo del
equipo de trabajo. Se ejecuta por último la
opción de almacenamiento de los cambios
realizados. En caso de querer identificar el
detalle de la información de un servidor PGN,
puede ejecutar el caso de uso
“AdministrarServidorPGN”, bajo la opción de
consulta.
10. El sistema SIMIP valida que las
disponibilidades de los servidores PGN
seleccionados coincida con la carga del caso al
cual será asignado el equipo de trabajo. Se les
restaura la disponibilidad a los servidores PGN
que fueron eliminados de los roles. El sistema
actualiza y almacena el registro asociado a la
operación realizada.
ejecutan las líneas 5, 6 y 7.
dato, cuyo valor corresponde al código del
equipo de trabajo seleccionado. Una vez
encuentra el registro, lo marca como inactivo. Se
almacena la marca en el medio de
almacenamiento. Se restauran las
disponibilidades de los diferentes servidores
PGN involucrados en el equipo de trabajo, según
la carga del caso al cual estaba asociado dicho
equipo.

Línea 2: Si el código del perfil ya existe, el sistema deberá desplegar un mensaje que le
indique al usuario la situación. La operación de ingreso es cancelada.

Línea 7: Si no se encuentra ningún registro que coincida en el código suministrado por el

correspondiente operación es cancelada.
Línea 4 y 10: Si de la validación se obtiene como resultado que las disponibilidades no
coinciden con la carga dispuesta para el caso, se genera un mensaje que indique de la
situación. Ante esta situación, la operación no debe ser cancelada.
7. Precondiciones
Se deben proporcionar todos los datos de entrada.
8. Post Condiciones
sistema, con respecto a un registro que está asociado a los datos de un equipo de trabajo:
• Consulta: Se muestra en una pantalla los datos del equipo de trabajo.

suministrados.

corresponde a un equipo de trabajo.
• Eliminación: Se marca un registro como inactivo.
• Verificar los datos sugeridos para los registros que definen los equipos de trabajo.
Sus estructuras, longitudes y tipos. Identificar las estructuras de datos que
permitirán el almacenamiento de estos registros.
• Definir cuáles serían los roles iniciales con los que se podría operar el sistema.
• Identificar si los roles se pueden establecer de forma automática a partir de los

cargos y experiencia de los servidores PGN. De ser así se sugiere que el sistema
predefina los servidores PGN sobre los roles, de tal forma que el usuario del
presente caso de uso sólo seleccione los servidores PGN que necesite, sin tener que
perder el tiempo revisando el detalle de cada servidor, tratando de identificar si es
el apropiado para el rol que esté definiendo en un momento dado.

CASO DE USO MANEJAR

AGENDA SERVIDORES

ManejarAgendaServidores v3.0.doc

07/07/05 2.0 Cambió el nombre de Manejar Agenda F. Martínez
Abogados por Manejar Agenda Servidores
Públicos
27/07/05 3.0 Se incorporaron las observaciones de la Disney Rubiano
PGN. Por la naturaleza de la especificación,
se pasó el caso de uso de SIAM a SIMIP.

Caso de Uso Manejar Agenda Servidor

Tiene como objetivo permitir el manejo de la agenda de los servidores, entendiéndose como
servidor un funcionario de la PGN. La agenda se maneja respecto a las actividades y tareas
que debe cumplir un servidor en el desarrollo de los casos que se le asignan.
2.1 Iteración
0.
2.2 Prioridad
Baja.
2.3 Complejidad
Baja.
Servidor PGN.
4. Entradas
Para el ingreso de una actividad:
Identificación del servidor público.
Código del caso. (Es el caso sobre el cual se desea programar una actividad).
Fecha de inicio de la actividad.
Fecha de finalización de la actividad.
Hora de inicio de la actividad.
Hora de finalización de la actividad.
Código de la actividad.

Nombre de la actividad.
Descripción de la actividad. (Hace una particularización de la actividad programada).
Participantes en la actividad.
Para la consulta de actividades:

Código del caso.
Para la eliminación de una actividad:

Código del caso.
Para la modificación de una actividades:

Código del caso.
Fecha de inicio para la actividad.
Fecha de finalización para la actividad.
Hora de inicio de la actividad.
Hora de finalización de la actividad.
Descripción de la actividad.
Participantes en la actividad.
5. Salidas
Para el ingreso de una actividad:
Se crea y almacena un nuevo registro para una actividad de un servidor público.

Para la consulta de actividades:

Se muestra por pantalla los datos de las actividades que un servidor público desarrollará
entre la fecha de inicio de la consulta y la fecha de inicialización de la misma.
Para la eliminación de una actividad:

Se elimina del sistema un registro de una actividad de un servidor público.
Para la modificación de una actividades:

Se modifica en el sistema un registro de una actividad de un servidor público.
6. Flujo de Eventos
6.1 Flujo Básico

usuario del sistema SIMIP, selecciona una
opción de manejo de agenda de un servidor
público: Ingreso, Consulta, Eliminación y
Modificación.
2. El usuario provee al sistema su número de

identificación.
3. Dado el número de identificación del usuario, el

sistema busca en el medio de almacenamiento,
todos los registros que corresponde a los casos
que están asociados al usuario. El sistema
despliega en una pantalla una lista con los casos
encontrados (Código del caso, descripción).
4. El usuario selecciona de la pantalla, el caso

sobre el cual quiere hacer manejo de agenda.

seleccionada. Adicionalmente se deberá desplegar
una pantalla con todas las actividades y etapas
registradas para el caso. Las actividades y etapas
del caso, sobre las cuales se hace un manejo de
agenda, son las mismas que se definen en el caso
de uso de nombre “Definir ruta y plan de


actividades”1, del sistema SIMIP.
6. El usuario del sistema deberá seleccionar de

la pantalla de actividades, aquellas sobre las
cuales requiere programar. Por cada actividad
seleccionada deberá registrar los valores a los
datos de entrada, para ingreso de una actividad
(El sistema puede tomar el código del caso, de
la actividad y la identificación del usuario de
forma automática de las líneas 2 y 4).
7. El sistema valida que las fechas registradas si

concuerdan con los términos especificados para la
actividad/actividades seleccionadas en la línea
anterior (Esta configuración se hace en el caso de
uso de nombre “AdministrarEtapasActividades”).
Según el resultado de la validación, crea los
correspondientes registros con los datos de la
entrada y los almacena.
8. Si la opción corresponde a consulta de datos, el

sistema deberá buscar todos los registros de
actividades asociados al número de identificación
y de caso, y con ellos desplegar una pantalla
donde por cada actividad programada para el caso,
mostrará los correspondientes datos (fechas y
demás datos). En este punto, se debe tener en
cuenta que el usuario sólo ejecutó las líneas 1 a 4).
De acuerdo a lo registrado en “Definir ruta y plan
de actividades”2, de SIMIP y en
“AdministrarEtapasActividades” de SIAM, el
sistema deberá señalar en la misma pantalla:
• Actividades no programadas (sin fechas).
• Actividades programadas que están

próximas a desarrollarse.
• Actividades que debieron haber sido

desarrolladas.
Los datos que se desplieguen en pantalla, no

deben permitir la opción de modificación.

apropiados y si la opción es una modificación de
datos, el sistema desplegará una pantalla como la
1
La definición de la ruta y el plan de actividades de un caso, la realiza el usuario con base en lo que se parametrice en el
caso de uso de nombre “AdministrarEtapasActividades” de SIAM.
2
La definición de la ruta y el plan de actividades de un caso, la realiza el usuario con base en lo que se parametrice en el
caso de uso de nombre “AdministrarEtapasActividades” de SIAM.


de la línea 8, con opción de modificación de datos
En este punto, se debe tener en cuenta que el

usuario sólo ejecutó las líneas 1 a 4).
10. El usuario del sistema deberá seleccionar

de la pantalla de actividades, aquellas sobre
las cuales requiere reprogramar. Por cada
actividad seleccionada deberá registrar los
valores a los datos de entrada, para
modificación de una actividad (El sistema
puede tomar el código del caso, de la
actividad y la identificación del usuario de
11. El sistema valida que las fechas registradas si

concuerdan con los términos especificados para la
actividad/actividades seleccionadas en la línea
anterior (Esta configuración se hace en el caso de
uso de nombre “AdministrarEtapasActividades”).
Si el usuario cuenta con los permisos apropiados,
según el resultado de la validación, crea/actualiza
los correspondientes registros con los datos de la
entrada y los almacena.

apropiados y si la opción es una eliminación de
datos, el sistema desplegará una pantalla como la
de la línea 8, con opción de eliminación de datos
En este punto, se debe tener en cuenta que el

usuario sólo ejecutó las líneas 1 a 4).
13. El usuario del sistema deberá seleccionar

de la pantalla de actividades, aquellas requiere
eliminar. Por cada actividad seleccionada
deberá registrar los valores a los datos de
entrada, para eliminación de una actividad (El
sistema puede tomar el código del caso, de la
actividad y la identificación del usuario de

apropiados, el sistema elimina los
correspondientes registros con los datos de la
entrada.
Nota 1: Se debe tener en cuenta que el proceso de manejar agenda es progresivo y que en
momentos diferentes el usuario puede hacer ingreso/modificación/eliminación/consulta de
datos.
Nota 2: El sistema deberá, vía correo electrónico, avisarle con anterioridad al funcionario
del desarrollo de una actividad.


Línea 7 y 11: Si las fechas suministradas para la actividad no coinciden con los términos
legales, especificados inicialmente (ver el caso de uso “AdministrarEtapasActividades”) para
la misma, se genera un mensaje de error indicando la situación. El sistema siempre debe
permitir el registro de una actividad, no importa que este sea por fuera del término legal.
Línea 7 y 11: Si el número de identificación del servidor público ya tiene una actividad
programada, en las fechas y horas suministradas, el sistema deberá desplegar un mensaje
que le indique al usuario la situación. La operación de ingreso es cancelada.
Línea 7: Si no se encuentra ningún registro de actividad que coincida en el número de
identificación de servidor público con el suministrado por el usuario, el sistema deberá
desplegar un mensaje que indique de lo sucedido. La operación de ingreso es cancelada.
Línea 14: Si se modifica la actividad, de tal forma que queda solapada con otra, el sistema
deberá desplegar un mensaje que indica de la situación y cancela la operación.
7. Precondiciones
operación (Consulta, ingreso, Actualización y eliminación).
8. Post Condiciones
sistema, con respecto a un registro que está asociado a los datos de una actividad de un
servidor público:
• Consulta: Se muestra en una pantalla los datos de todas las actividades de un servidor
PGN para un caso.
• Ingreso: Se crea y almacena en el sistema nuevos registro con los datos de actividades
de un caso desarrollado por un servidor PGN.
• Actualización: Se modifican los datos de los registros de actividades ya almacenados en

el sistema para un número de identificación de un servidor PGN y un código de caso.
• Eliminación: Se elimina del medio de almacenamiento del sistema los registros de

actividades de un caso, desarrollado por un servidor PGN.

9.1 Definición del tiempo previo para alertar sobre una actividad a un servidor PGN
En la línea 8, y la nota 2, se debe definir cual es el tiempo que se debe tener en cuenta para
que con anterioridad se le indique al servidor del desarrollo de una actividad.
Definir cuales son los datos obligatorios que el usuario debe proporcionar, una vez se
quiere hacer los ingresos de los datos de una actividad.
Definir cuales son los datos que el usuario puede modificar, una vez se quiere hacer una
actualización de datos una actividad (Por ahora se cuenta con fechas y horas de inicio y de
finalización).
9.4 Características de los datos que se necesitan para la ejecución del caso de uso
Definir cuáles son datos necesarios para el desarrollo de este caso de uso, sus tipos y
longitudes, además de determinar cuáles son obligatorios, y cuales no.

CASO DE USO
SIMIP_INT_1.RECIBIR
SOLICITUDES MISIONALES - SIAF

SIMIP_INT_1RecibirSolicitudesMisionales-SIAF.doc

15/07/05 2.0 Se incorporaron las observaciones sugeridas
por la PGN.
Este caso de uso reune lo sugerido
inicialmente en los casos de uso
“SIAF_INT_2GenerarArchivoSolicitudesMisi
onales” y
“SIMIP_INT_1CargarSolicitudesMisionales”.

Caso de Uso SIMIP_INT_1. Recibir Solicitudes

Misionales - SIAF
Este caso de uso tiene como objetivo registrar en línea, en SIMIP, las solicitudes que se
ingresan en SIAF1 y que se consideran misionales.

2.1 Iteración
0
2.2 Prioridad
Media.
2.3 Complejidad
Media.
SIAF.
4. Entradas
Por cada registro:
Datos del ciudadano (persona o entidad que formula la queja o solicitud):
• Nombres y apellidos del ciudadano (remitente).
• Dirección y teléfono del ciudadano (remitente).
• País, Departamento, Ciudad de Procedencia.
1
SIAF: Sigla usada para referirse al Sistema Administrativo y Financiero de la PGN. Corresponde al software existente
en la PGN en el momento del desarrollo del sistema SIM.

Datos de la Queja o Solicitud:

• Fecha de la solicitud
• Detalle de la queja o solicitud, descripción breve del contenido de la queja o solicitud.
• Naturaleza (el equivalente a naturaleza de documento en SIAF, se refiere si el
documento es un Oficio, Derecho de petición, tutela, etc.) Tipo de clasificación de la
solicitud o asunto.
Información de los documentos relacionados:

• Número externo/interno del oficio.
• Fecha de Procedencia del documento.
Información generada por SIAF:

• Número Único de Identificación.
• Fecha y hora de registro en SIAF.
• Dependencia a la que fue asignada la solicitud.
5. Salidas
Registros de solicitudes en SIMIP.
6. Flujo de Eventos
6.1 Flujo Básico

1. Este caso de uso comienza cuando en SIAF
se registra una solicitud de carácter misional.
2. El sistema SIAF, toma los datos del registro
de solicitud y los incorpora en un mensaje
hacia el sistema SIMIP.
3. SIMIP, una vez recibe el mensaje con los
datos, crea y almacena un registro de solicitud.

dato), se debe generar un mensaje que indique el error detectado. La operación de registro
sobre SIAF es cancelada, hasta tanto no se corrija la situación encontrada.
7. Precondiciones
Se deben suministrar todos los datos de la entrada..
8. Post Condiciones
Se crea un registro en SIMIP de solicitud.
9.1 Definición del mensaje
Se debe determinar la manera como SIAF y SIMIP establecerán comunicación para enviar
y recibir mensajes.
9.2 Definir de donde se debe tomar la información

Determinar de donde deben ser tomados los datos que se requiere sean incorporados en el
mensaje que envía SIAF a SIMIP.
9.3 Datos que se desean cargar en el SIMIP

Se debe identificar cuales son los datos que necesita SIMIP y sus características (Tipos,
longitudes, obligatorio/no obligatorio).

Definir si durante el cargue se produce un error, se aborta o se continua?

CASO DE USO
SIMIP_INT_2.TRANSMITIR
SANCIONES SIMIP A SIRI

SIMIP_INT_2_TransmitirSancionesSIMIP-SIRI-v3.0.doc

28/07/05 3.0 Se incluyeron las observaciones formuladas D. Rubiano.
por la doctora Ferlina en la reunión
celebrada el 27 de julio.

SIMIP_INT_2.Caso de Uso Transmitir Sanciones SIMIP

a SIRI
El presente caso de uso tiene como objetivo la comunicación de un fallo sancionatorio en SIMIP
para el registro de la sanción en el SIRI. Se activa con la decisión sancionatoria en firme y se
cumple con el diligenciamiento del formulario respectivo y el envío a SIRI.
Para el caso de fallos sancionatorios la información básica requerida es la siguiente:

• Identificación del sancionado: Nombre, identificación, lugar de residencia, etc.
• Descripción de las sanciones: Tipo de falta, Culpabilidad, sanción, duración, etc.
• Normas infringidas: Tipo de norma, número, año, artículo, numeral, inciso, etc
• Detalle providencias: Instancia, autoridad.
• Información del proceso: Número de caso, tipo (ordinario, verbal), etc.
• Funcionario responsable de la información: Nombre, identificación, cargo, etc.
En general, se debe proveer desde SIMIP, la información concerniente a los formularios para
reportar sanciones e inhabilidades:
• Formulario para registro de inhabilidades derivadas de las relaciones contractuales con el

estado
• Formulario para registrar novedades de inhabilidades derivadas de las relaciones

contractuales con el estado.
• Formulario de registro de sanciones disciplinarias.
• Formulario de registro novedades de sanciones disciplinarias.
• Formulario para registro de inhabilidades derivadas del proceso por responsabilidad

fiscal.
• Formulario para registro de novedades de inhabilidades derivadas del proceso por

responsabilidad fiscal.
• Formulario para registro de inhabilidades derivadas de la pérdida de investidura.
• Formulario para registro de novedades de inhabilidades derivadas de la pérdida de

investidura.
• Formulario para registro de sanciones penales.
• Formulario para registro de novedades de sanciones penales.


2.1 Iteración
0.
2.2 Prioridad
Media.
2.3 Complejidad
Media.
Servidor PGN.
4. Entradas
UIC.
5. Salidas
Formato SIRI diligenciado.
6. Flujo de Eventos
6.1 Flujo Básico

1. Este caso de uso comienza cuando se emite
un fallo sancionatorio en SIMIP. El
servidor ingresa el IUC de un caso
disciplinario listo para registrar sanción.
2. El sistema despliega por pantalla el formulario con
los campos necesarios para registrar la sanción (ver
Descripción Breve)
3. El servidor llena los campos necesarios
para que estos sean transmitidos a SIRI.
Los datos que se registran en este punto
son los de un formulario.
4. En SIRI, con la información de la línea 3, se crea y
almacena un registro. SIRI establece un estado para
la información del registro: “Completo”, “ceptable”
e “Incompleto”.

Nota: Respecto a las líneas 2, 3 y 4, se debe tener en cuenta que actualmente el SIRI cuenta con
programas que permiten el ingreso de los datos de un formulario, y la ejecución de las opciones
de “Guardar” y “Enviar”, a partir de las cuales se realizan las correspondientes validaciones
sobre la información registrada para un formato de un formulario. Estas validaciones sobre los
formatos de los formularios, actualmente manejan estados de “Completo”, “Aceptable” e
“Incompleto”, de los cuales necesariamente debe enterarse el usuario de SIMIP.
• Línea 2. Si el IUC no corresponde a un caso existente en el sistema, se informa el error y

• Línea 4. Si la información ingresada en el formulario no es válida, se informa el error y
7. Precondiciones
• Los IUC entrado corresponde a un caso existente en el sistema.
• La información entrada en el formulario de la sanción es válida.
8. Post Condiciones
• Se transmite la información de una sanción para un caso particular de SIMIP a SIRI.
9.1 Mecanismo de transmisión de un formulario:

Se debe establecer el mecanismo apropiado que permita la transmisión de los formularios entre
SIMIP y SIRI, de tal forma que se pueda aprovechar los programas de validación,
almacenamiento y de establecimiento de estados de un formulario, desarrollados actualmente en
SIRI.
Adicionalmente, para implementar el presente caso de uso, se debe tener en cuenta que SIRI,
actualmente maneja mecanismos de Token y de perfiles de usuario.

CASO DE USO SIMIP_INT_3.

PROVEER INFORMACIÓN DE
DOCUMENTOS DE SALIDA A SIAF

SIMIP_INT_3ProveerInfoDocumentosSalida-SIAF-v3.0.doc


Caso de Uso SIMIP_INT_3. Proveer información de

documentos de salida a SIAF
Este caso de uso tiene como objetivo generar un archivo con documentos de salida para que se
maneje la correspondencia de salida en SIAF1. Este caso de uso se utiliza para el manejo de
comunicaciones enviadas por la Procuraduría.
SIMIP
3. Entradas
Información básica de los documentos de salida. Número de identificación asociado al caso.
4. Salidas
Archivo con la información de los documentos de salida.
5. Flujo de Eventos
5.1 Flujo Básico
1. Este caso de uso se utiliza cuando se envía

información de correspondencia de salida a
SIAF
2. El sistema genera automáticamente los

registros de la interfaz
La documentación en SIMIP asociada a cada caso debería tener en un identificador

asociado al caso. Como toda la correspondencia de salida tiene que ser manejada por la
oficina de registro y control, SIMIP debe enviar relación de documentos enviados a dicha
división. Una vez recibidos en SIAF se les asigna identificar de salida (para el control de
correspondencia).
La información se vería así:
1
SIAF: Sigla usada para referirse al Sistema Administrativo y Financiero de la PGN. Corresponde al
software existente en la PGN en el momento del desarrollo del sistema SIM.

CASO Documentación SIMIP # SALIDA EN SIAF
10 10-A 4030
10-B 4031
Una tabla de este estilo permitiría asociar el consecutivo del documento en SIMIP con el de
SIAF para hacer seguimiento a la correspondencia de salida de la PGN.
6.2. Flujos Alternativos
dato), se debe almacenar en un archivo de log, el error detectado.
7. Precondiciones
Debe existir previamente la información de documentación de salida proveniente de SIMIP
8. Post Condiciones
Se crea el archivo con la información de la documentación de salida que almacenan los
datos del cargue en el sistema SIAF.
Hay necesidad de definir si esta tabla que relacione los identificadores de documentos en
ambos sistemas está replicada en ambos lados para hacer más efectivas las consultas del
estado de un documento.
9.1 Periodicidad del cargue
Se debe definir cada cuánto se debe hacer activar la operación de cargue en el sistema
SIAF.
9. 2 Tipo de cargue
Se debe definir si el cargue es automático (proceso batch).
9.3 Definir de dónde se debe tomar la información
Determinar de dónde debe ser tomado el archivo que contiene los registros que se quieren
cargar en el SIAF (servidor, path, base de datos).
9.4 Tipo de archivo
Definir el tipo de archivo que contendrá los datos que se van a cargar en el SIAF. Archivo
plano, vistas de una base de datos?

9.5 Datos que se desean cargar en el SIAF

Se debe identificar cuáles son los datos que necesita SIAF y sus características (Tipos,
Definir si durante el cargue se produce un error, se aborta o se continua?. Definir si se hace
cargue por lotes y si dicho cargue del lote se aborta cuando se produce un error, pasando al
siguiente lote.
9.7 Identificación del archivo
En caso de manejar archivos planos se debe definir una nomenclatura que permita definir la
fecha y grupo de datos que almacena. Lo propio se debe hacer en la definición de vistas de
una base

CASO DE USO
SIMIP_INT_4.SUGERIR CASO

SIMIP_INT_4SugerirCaso.doc

05/07/05 2.0 Obedece a una actualización del caso de D. Rubiano
uso “SIMIP_INT_4_ Sugerir Descriptor
Temático”.
22/07/05 3.0 Ajustes producto de las observaciones D. Rubiano.

SIMIP_INT_4.Sugerir Caso
Este caso de uso tiene por objetivo, que un usuario autorizado en SIMIP pueda sugerir al
administrador de SIREL, la inclusión en SIREL de un caso, como representativo, para que
éste pueda ser consultado por los usuarios de SIREL.
La sugerencia del caso implica diligenciar, entre otras variables: Tipo de caso (Preventivo,
Disciplinario, Intervención), Tipo de Origen de la solicitud que dio origen al caso,
Naturaleza de los hechos, Tipo de modalidad (si es verbal, en caso de ser de tipo
disciplinario), Tipo de derecho afectado (en caso de ser preventivo), Tipo de autoridad
judicial (en caso de ser de intervención), Resumen del desarrollo del caso, resultado (por
ejemplo: fallo), Identificación del funcionario que propone el caso, Fecha en la que se
propone el caso y Dirección electrónica del funcionario que sugiere el caso. Además de una
sugerencia de los temas a los cuales puede ser asociado el caso.
Para asociar el caso a los temas, el usuario de SIMIP debe poder consultar los diferentes
temas que existen en SIREL, sabiendo que un tema obedece a un conjunto de descriptores y
restrictotes formulados por el administrador de SIREL.
• Servidor PGN
3. Entradas
• Código del caso.
• Número de Expediente.
• Tipo de caso (Preventivo, Disciplinario, Intervención).
• Dependencia.
• Ubicación geográfica en donde se desarrollan los hechos

(Municipio/Ciudad/Departamento/País).
• Tipo de Origen de la solicitud que dio origen al caso.
• Naturaleza de los hechos.
• Tipo de modalidad (si es verbal, en caso de ser de tipo disciplinario).
• Tipo de derecho afectado (en caso de ser preventivo).
• Tipo de autoridad judicial (en caso de ser de intervención).

• Resumen del desarrollo del caso (Notas del relato).
• Identificación de las informaciones jurídicas sobre las cuales se basó el desarrollo

del caso (por ejemplo: Normas y decretos).
• Información jurídica sugerida: En caso de que en el punto anterior no se encuentre

la información necesaria, el usuario del sistema deberá proponer la nueva
información jurídica que sustenta el desarrollo del caso. Esta información será
evaluada por el administrador de SIREL, y dado el caso incorporada endicho
sistema, teniendo en cuenta la estructura de restrictotes, descriptores, sinónimos,
antónimos y links.
• Concepto acogido.
• Acción.
• Sujetos partes.
• Resultado (por ejemplo: fallo).
• Identificación del funcionario que propone el caso.
• Fecha en la que se propone el caso.
• Fecha de los hechos asociados al caso.
• Dirección electrónica del funcionario que sugiere el caso.
• Sugerencia de los temas a los cuales puede ser asociado el caso.
• Ubicación de la documentación física que soporta el caso.
4. Salidas
Registro almacenado de un caso de caso sugerido desde SIMIP para SIREL.
5. Flujo de Eventos
5.1 Flujo Básico

1. Este caso de uso comienza cuando un
usuario SIMIP selecciona la opción de
sugerencia de caso.
2. El sistema SIMIP, despliega una pantalla, para
que el usuario diligencie los respectivos datos de
entrada. En dicha pantalla, usa el caso de uso
“SIREL_INT_1ConsultarTemas”


3. El usuario registra los datos de la entrada,
entre ellos selecciona los temas a los que
quiere asociar el caso, y activa la opción de
enviar.
4. Al dar la opción de enviar, se genera un
mensaje hacia SIREL, que contiene los datos de la
entrada.
5. SIREL recibe el mensaje con los datos de la
entrada, crea y almacena un registro de caso
sugerido. El registro del caso que es almacenado
en SIREL es guardado con una marca que indica
que no ha sido evaluado en SIREL

Línea 5: Si el caso sugerido ya existe se cancela la operación y se genera un mensaje en el
que se indica de la situación.
6. Precondiciones
Se deben suministrar todos lo datos de entrada, de acuerdo con el tipo de caso (Preventivo,
Disciplinario o de Intervención).
En el caso de los datos básicos, se debe diligenciar los valores de los datos ocasionales
asociados. Por ejemplo: En caso de diligenciar el dato básico Tipo de caso, con el valor
Preventivo, se hace necesario el diligenciamiento del dato ocasional Derecho afectado, pero
no el de Tipo de modalidad (El Tipo de modalidad, solo aplica a los de carácter
disciplinario y se refiere a si es verbal o no).
7. Post Condiciones
Se crea un registro en SIREL de caso sugerido.
Se debe determinar la manera como SIMIP y SIREL establecerán comunicación para enviar
y recibir mensajes.
8.2 Definición de los datos de entrada

Se deben revisar las entradas y de ser necesario ampliarlas, indicando sus longitudes y
tipos, además de cuales son opcionales y cuáles obligatorias. En la entrada de datos se debe

tener en cuenta que existen unos datos básicos y otros ocasionales, y que éstos últimos
dependen en su obligatoriedad de los valores suministrados a los básicos. Por ejemplo: No
se debe solicitar Tipo de modalidad cuando la Tipo de caso es Preventivo.

CASO DE USO SIMIP_INT_5.

RECIBIR SOLICITUDES Y
PETICIONES INGRESADAS
POR LA WEB - SIC

SIMIP_INT_5RecibirSolicitudesWEB-SIC.doc

15/07/05 2.0 Se incorporaron las observaciones sugeridas Disney Rubiano
por la PGN.
Este caso de uso reune lo sugerido inicialmente
en los casos de uso
“SIAF_INT1.CargarSoilcitudesWEB” y
“SIC_INT_1GenerarArchivoSolicitudesWEB”.
Así como se cargan los datos básicos de SIC
en el SIAF, los datos totales de la solicitud,
deben ser cargados en el SIMIP.
27/07/05 3.0 Se incluye el cargue de peticiones (caso de uso C.Díaz
SIC – Registrar Peticiones) y el cargue de
información suministrada por las OCID.

CASO DE USO SIMIP_INT_5. RECIBIR SOLICITUDES Y

PETICIONES INGRESADAS POR LA WEB - SIC
Este caso de uso tiene como objetivo registrar en línea los datos de las solicitudes y peticiones
ingresadas por el SIC, en SIMIP. Incluye lo registrado en los casos de uso de SIC: Registrar
Solicitudes, Registrar Peticiones e Ingresar Inicio y Actuaciones Procesos disciplinarios
reportados por OCID (Oficinas de Control Interno Disciplinario).

2.1 Iteración
0
2.2 Prioridad
Media.
2.3 Complejidad
Media.
SIMIP.
4. Entradas
La información recolectada por cada solicitud o petición, ingresada por Internet vía SIC:
Datos de quien formula la queja o solicitud (persona o entidad que formula la queja o solicitud):
• Número de identificación (NIT, Cédula de ciudadanía, Cédula de extrajería, etc).
• Nombres y apellidos del ciudadano, Nombre de la entidad que formula la queja.
• Dirección y teléfono del ciudadano/entidad.
• e-mail.
• País, Departamento, Ciudad de Procedencia.
• Identificador que determina si se trata de un ciudadano o de un servidor PGN.
Datos de la Solicitud o Petición:

• Detalle de la solicitud o petición, descripción breve del contenido de la solicitud o petición.
5. Salidas
Se almacena en SIMIP un registro por cada una de las quejas o solicitudes ingresadas por SIC.
6. Flujo de Eventos
6.1 Flujo Básico

1. Este caso de uso comienza cuando un usuario
(Servidor PGN ó ciudadano ingresa los datos de
una solicitud o queja por la WEB a través del
sistema SIC.
2. El sistema SIC, toma los datos de entrada de
los casos de uso “RegistrarSolicitudes, Registrar
Petición e Ingresar inicio y actuaciones de
procesos disciplinarios reportados por OCID ” y
los incorpora en un mensaje hacia el sistema
SIMIP.
3. SIMIP, una vez recibe el mensaje con los datos,
crea y almacena un registro de solicitud.
Línea 2: En caso de encontrar un error (por ejemplo: sobre el tipo del dato, la longitud del dato),
se debe generar un mensaje que indique el error detectado. La operación sobre los casos de uso
“RegistrarSolicitudes, Registrar Petición e Ingresar inicio y actuaciones de procesos
disciplinarios reportados por OCID” es cancelada, hasta tanto no se corrija la situación
encontrada.
7. Precondiciones
Se deben suministrar todos los datos de la entrada..
8. Post Condiciones
Se crea un registro en SIMIP de una solicitud.

Se debe determinar la manera como SIC y SIMIP establecerán comunicación para enviar y recibir
mensajes.
9.2 Definir de donde se debe tomar la información

Determinar de donde deben ser tomados los datos que se requiere sean incorporados en el
mensaje que envía SIC a SIMIP.
9.3 Datos que se desean cargar en el SIMIP

Se debe identificar cuales son los datos que necesita SIMIP y sus características (Tipos,

Definir si durante el cargue se produce un error, se aborta o se continua?


CASOS DE USO SIREL
Requerimientos Detallados Módulo SIREL (Documento Final) Pág.A4- i

TABLA DE CONTENIDO
SIREL1 – Administrar Temas ………………………………………………………………1
SIREL2 – Administrar Servidores PGN Temas……………………………………………..8
SIREL3 – Comunicar Cambios Servidores PGN……………………………………………14
SIREL4 - Administrar información jurídica…………………………………………………18
SIREL5 - Administrar links internos …………………………………………………..……25
SIREL6 - Administrar links externos ………………………………………………………..30
SIREL7 – Consultar Lista Links Información Jurídica………………………………………35
SIREL8 - Buscar información jurídica……………………………………………………….41
SIREL9 - Generar documento………………………………………………………………..48
SIREL_INT_1. Consultar Temas…………………………………………………………….53
SIREL_INT_2. Evaluar casos sugeridos……………………………………………………..57
Requerimientos Detallados Módulo SIREL (Documento Final) Pág.A4- ii


TEMAS
Requerimientos Detallados Módulo SIREL (Documento Final) Pág.A4- 1

AdministrarTemas.doc

01/06/02 2.0 Se cambió de nombre, pasando de “Definir Disney Rubiano
descriptores o tesauros” a “Administrar
descriptores”. Se complementó el manejo
de descriptores, llevándolo hacia el
concepto de administración de los mismos.

Caso de Uso Administrar Temas

El presente caso de uso tiene como objetivos consultar, establecer (ingresar-capturar), modificar y borrar
por cada uno de los tipos de información jurídica (Legislación, jurisprudencia o doctrina) del sistema
SIREL, los diferentes temas de clasificación, búsqueda y acceso a los registros de los casos representativos
y de las informaciones jurídicas que se almacenan en dicho sistema1.
Por cada tema, se debe poder establecer, consultar, modificar y borrar subtemas (restrictotes) con el ánimo
de poder realizar de forma avanzada los procesos de clasificación, búsqueda y acceso de información
almacenada en el sistema SIREL. A su vez, por cada subtema, se debe poder consultar, establecer,
modificar y eliminar el conjunto ordenado de términos o palabras (Descriptores) de mayor relevancia,
dentro del concepto manejado por el subtema. A su vez, sobre las palabras definidas se deben poder
establecer relaciones, con tal suerte de que por cada una se puedan identificar sinónimos y antónimos (un
sinónimo y un antónimo son cada uno un descriptor ya almacenado en el sistema).

2.1 Iteración
0.
2.2 Prioridad
Alta.
2.3 Complejidad
Alta.
Administrador de SIREL.
.
4. Entradas
Para modificación2 e ingreso de datos:
• Tipo de información (Legislación, jurisprudencia o doctrina).
1 Se debe tener en cuenta que para hacer la búsqueda de información jurídica para hacer consultas sobre la misma, no sólo se
tiene en cuenta los conceptos de Tema, Restrictor y Descriptor, y que esta búsqueda se puede hacer por otros conceptos tales
como: Tipo de información (Legislación, Jurisprudencia y/o Doctrinas), ponente, dependencia, etc. Este punto puede verse con
más detalle en el caso de uso “SIREL – BuscarInformación”.
2
Una modificación puede significar modificar los datos propios del tema (Como el nombre y la descripción) y/o la modificación,
adición y/o eliminación de descriptores y/o restrictotes. A su vez puede significar hacer cambios sobre los sinónimos y
antónimos de un descriptores, adicionando o eliminando relaciones entre descriptores.

• Código de tema.
• Nombre del tema.
• Descripción del tema.
• Para el tema, los códigos, nombres y descripciones de los restrictores asociados.
• Por cada restrictor, los códigos, nombres y significados de los descriptores asociados.
• Por cada descriptor los códigos de los descriptores que son sinónimos.
• Por cada descriptor los códigos de los descriptores que son antónimos.
• Fecha de creación/actualización del tema.
• Responsable del tema.
Para eliminación y consulta:

• Tipo de información (Legislación, jurisprudencia o doctrina).
5. Salidas
Para Ingreso: Nuevos registros (el del tema, más los registros asociados a descriptores y restrictotes) en el
sistema SIREL que contiene todos los datos suministrados en las entradas.
Modificación: Registros modificados en el sistema SIREL, de acuerdo a los datos suministrados en las
entradas.
Eliminación: Se elimina del sistema SIREL los registros (El del tema más las relaciones establecidas hacia
los descriptores y los restrictores) que corresponde a los datos suministrados en las entradas.
Consulta: Se despliegan en una pantalla todos los datos de un tema, que corresponde a los datos de las
entradas.
6. Flujo de Eventos
6.1 Flujo Básico
administrador SIREL, selecciona la opción
readministrar Temas en el sistema SIREL.
2. Si el usuario tiene los permisos apropiados (El
Administrador de SIREL), SIREL despliega una
pantalla para que el usuario seleccione cualquiera de
4 opciones: Ingreso, consulta, modificación o
eliminación de datos.
3. El usuario selecciona una de las 4 opciones.
4. Si la opción es ingreso, el sistema despliega una
pantalla, para que el usuario ingrese los datos de la

entrada.
5. El usuario diligencia cada uno de las entradas.
Ejecuta la opción de guardar información.
6. El sistema crea un registro para el tema (genera el
código del tema de forma automática) y otros para
las relaciones establecidas con los restrictores y los
descriptores y los almacena.
7. Si es consulta, el sistema despliega una pantalla
para que el usuario registre los datos de entrada de
la información que desea consultar.
8. El usuario ingresa (selecciona) el tipo de
información y el código del descriptor.
9. El sistema busca en su medio de almacenamiento
los registros que coincidan con los datos de entrada
y despliega los respectivos valores en una pantalla.
Despliega valores para cada una de las entradas
especificadas para el ingreso de datos.
10. Si es una modificación, el sistema despliega una
pantalla para que el usuario registre los datos de la
información que desea modificar.
12. El sistema busca en su medio de
almacenamiento los registros que coincidan con los
datos de entrada y despliega los respectivos valores
en una pantalla. Despliega valores para cada una de
las entradas especificadas para el ingreso de datos.
Los valores se despliegan con opción de
modificación.
13. El usuario modifica los valores necesarios
sobre la pantalla desplegada por el sistema, por
ejemplo: (1) Modificar los datos básicos del tema
(Nombre y descripción). (2) Adicionar/Eliminar
descriptores y/o restrictotes.
El usuario ejecuta la opción de guardar las
modificaciones realizadas.
14. El sistema modifica el correspondiente registro
para el tema (genera el código del tema de forma
automática) y los registros de las relaciones
establecidas con los restrictores y los descriptores y
los almacena. Cuando se trate de nuevos
descriptores y/o restrictotes, se crean y almacenan
nuevos registros. Cuando se trate de eliminación de
descriptores y/o restrictotes, se eliminan del medio
de almacenamiento los correspondientes registros.
15. Si es una modificación, el sistema despliega una

información que desea modificar.

17. El sistema busca en su medio de
almacenamiento los registros que coincidan con los
datos de entrada y los elimina. Elimina el registro
que corresponde al tema y los de las asociaciones
con los descriptores y restrictotes. No elimina los
registros que corresponden a la información de los
descriptores y los restrictotes ya creados.

Creación de nuevos descriptores y restrictores:
Líneas 5 y 6: Si hay necesidad de asociar un descriptor no almacenado en el sistema, el usuario deberá

diligenciar los datos del mismo (Generación de código automática, nombre y descripción – significado) y
las relaciones de sinónimos y antónimos, para que el sistema cree y almacene los respectivos registros.
En caso de necesitar nuevos descriptores para las relaciones de sinónimos y antónimos, deberá por cada
uno realizar las acciones del anterior párrafo.
Modificación de información:
Línea 13: Una modificación puede significar la creación/modificación/eliminación de relaciones con

descriptores y/o restrictotes. En caso de que un descriptor o restrictor no exista, se debe tener en cuenta lo
expresado para el título anterior (Creación de nuevos descriptores y restrictotes).
Información inexistente:
Líneas 9, 12 y 17: Si no existen registros que coincidan con los datos suministrados en las entradas (Tipo
de información y código del tema), se genera un mensaje que le indique al usuario la situación y se cancela
la operación.
7. Precondiciones
Se deben suministrar todos los datos de las entradas, según sea el caso. En caso de que se trate de un
ingreso de datos, como mínimo se deben suministrar los siguientes datos.
• Nombre del tema.
• Descripción del tema.
Una modificación se pude realizar sobre cualquiera de los datos de la entrada.

8. Post Condiciones
Según sea el caso identificado en las entradas, se realiza la modificación, ingreso, eliminación o consulta de
los registros que corresponden a la información de un tema.
9.1 Definición de las entradas
Se deben revisar las entradas y de ser necesario ampliarlas, indicando sus longitudes y tipos.
9.2 Definición de temas

Se debe desarrollar una labor de levantamiento de información, con lo cual se pueda especificar de forma
clara el universo necesario de los temas, los descriptores y los restrictores. Para realizar esta tarea de puede
recurrir a sistemas universales de estandarización.


SERVIDORES PGN - TEMAS

AdministrarServidoresPGNTemas.doc

09/06/05 1.0 Se ajustó el caso de uso y se cambió el D. Rubiano.
nombre de “Inscribir Usuarios Temas” a
“Administrar Usuarios temas”.

Caso de Uso Administrar Servidores PGN - Temas

El presente caso de uso tiene como objetivo consultar/ingresar (inscribir)/modificar/eliminar los
servidores PGN según los temas (con conjunto de descriptores y restrictotes asociados) definidos
para la información jurídica y los casos representativos, almacenados en el sistema SIREL. Esto
con el fin de proporcionar información relevante a los servidores PGN cuando estén trabajando
casos particulares en SIMIP, así como permitir la comunicación oportuna producto de la
incorporación y/o modificación de la información sobre el sistema SIREL.

2.1 Iteración
0.
2.2 Prioridad
Alta.
2.3 Complejidad
Alta.
• Administrador SIREL.
4. Entradas
Para ingreso (inscripción) y modificación de datos:
• Tipo de información jurídica (Legislación, jurisprudencia o doctrina).
Por cada tema asociado de la información jurídica:

• Registro de las direcciones electrónicas de los servidores PGN, que desean recibir
comunicaciones que indiquen la incorporación y/o modificación de información jurídica
y de casos representativos asociados con un tema. Por cada dirección electrónica se debe
conocer el nombre y dependencia del servidor a quien corresponde. Un servidor PGN
puede tener más de una dirección electrónica.
Para consulta y eliminación:

El identificador del registro de asociación Tema vs. Direcciones electrónicas de servidores PGN.
5. Salidas
Para Ingreso (inscripción): Nuevo Registro, donde se identifican los temas y la información de los
servidores PGN interesados en el tema. El registro generado tiene un identificador que lo
diferencia de los demás ya creados.
Modificación: Registros modificados en el sistema SIREL, de acuerdo a los datos suministrados
en las entradas.
Eliminación: Se elimina del sistema SIREL el registro seleccionado.
Consulta: Se despliegan en una pantalla todos los datos de un tema, en referencia a los servidores
PGN (Nombre, direcciones electrónicas y dependencia) que tienen interés en el mismo.
6. Flujo de Eventos
6.1 Flujo Básico
administrador SIREL, selecciona la opción de
Administrar usuarios a los temas de interés.
Administrador de SIREL), SIREL despliega una
pantalla para que el usuario seleccione cualquiera de
4 opciones: Ingreso, consulta, modificación o
eliminación de datos.
3. Sobre la pantalla desplegada, el usuario
selecciona una opción.
4. Si la opción es suscripción, el sistema despliega
una pantalla, para que el usuario ingrese los datos de
la entrada.
5. El usuario suministra la información de la
entrada. No necesariamente debe diligenciar toda
la información y en varios tiempos puede ingresar
la información. Por ejemplo: en primera instancia
sólo ingresa los datos para el tipo de información
legislación. El usuario ejecuta la opción guardar
la información suministrada.
6. Por cada tema seleccionado en la entrada, se crea
un registro de asociación tema-direcciones
electrónicas de servidores PGN.
7. Si la opción es consulta, el sistema despliega una
pantalla con los tipos de información de de temas
asociados a estos.
8. El usuario selecciona el tipo y tema sobre el
cual quiere consultar.


9. Con la información anterior, el sistema obtiene el
identificador del correspondiente registro y hace la
correspondiente búsqueda y una vez lo encuentra
despliega la información (las direcciones
electrónicas de los servidores PGN asociados,
además del nombre y la dependencia del servidor
PGN).
10. Si la opción es eliminación, el sistema ejecuta

las acciones de las líneas 7 y 8.
11. Con la información anterior, el sistema obtiene
el identificador del correspondiente registro y hace
la correspondiente búsqueda y una vez lo encuentra
despliega lo elimina.
12. Si la opción es eliminación, el sistema ejecuta

las acciones de las líneas 7, 8 y 9. Los datos se
despliegan con opción de modificación.
13. El usuario hace las modificaciones pertinentes
sobre los datos del servidor PGN (Nombre,
direcciones electrónicas y dependencia). Una
modificación puede significar por ejemplo: Una
corrección sobre una dirección electrónica,
agregar nuevos servidores PGN a un tema o
eliminar servidores PGN de un tema.
13. Con la información anterior, el sistema obtiene
el identificador del correspondiente registro y hace
la correspondiente búsqueda y una vez lo encuentra
almacena las correspondientes modificaciones.

Línea 2. Si el usuario no tiene los permisos adecuados, no se permite la ejecución de la opción.
7. Precondiciones
Debe existir en el sistema de forma previa la información concerniente a los tipos de información
y temas asociados a éstos.
8. Post Condiciones
Se crean, modifican, elimina o consultan registros de asociación entre temas y servidores PGN
que están interesados en los mismos.


Se debe en la etapa de diseño, revisar las entradas, dado el caso complementarlas. Definir las
correspondientes características de las mismas: Nombres, tipos y longitudes. Además se debe
definir de las estructuras de datos que almacenarán los datos que se diligencian según las entradas
del presente caso de uso.

CASO DE USO COMUNICAR

CAMBIOS A SERVIDORES PGN

ComunicarCambiosServidoresPGN.doc

01/06/05 2.0 Se modificó el nombre, pasando de D. Rubiano
“Notificar nuevas normas” a “Comunicar
cambios a usuarios”. Se amplió la
explicación del concepto.

Caso de Uso Comunicar Cambios a Servidores PGN

El presente caso de uso tiene como objetivo comunicar, vía e-mail, a los usuarios sobre la incorporación de
una nueva información jurídica y de la liberación de casos representativos. También comunica las
correcciones y modificaciones sobre la información ya existente (información jurídica y casos
representativos ya liberados), que se hayan registrado en el sistema SIREL.

2.1 Iteración
0.
2.2 Prioridad
Alta.
2.3 Complejidad
Alta.
• Sistema SIREL
4. Entradas
Identificación del registro de asociación Tema-Servidores PGN.
5. Salidas
Se envía un correo electrónico a las direcciones de los servidores PGN que se encuentren en el registro de
asociación Tema-Servidores PGN.
6. Flujo de Eventos
6.1 Flujo Básico
1. Este caso de uso comienza cuando se ejecuta
con éxito sobre SIREL opciones de los casos de
uso “Administrar Información Jurídica”,
“Administrar Historia de Información Jurídica”
ó “SIREL_INT_2EvaluarCasosSugeridos”.


2. El sistema dado el tema de la información
trabajada en cualquiera de los casos de uso
mencionados en la línea 1, obtiene los
identificadores de los correspondientes registros de
asociación Tema-Servidores PGN y hace la
correspondiente búsqueda y una vez lo encuentra
extrae la información correspondiente a las
direcciones electrónicas.
3. Por cada dirección electrónica se envía un correo
donde se comunica la acción realizada en el
respectivo caso de uso de la línea 1, indicando el
tema, y la información jurídica o caso representativo
trabajado.

Línea 2: Si la identificación del perfil aún no ha sido registrada en el sistema, se debe cancelar la operación
y generar un mensaje donde se indique de la situación. Si la norma no ha sido creada o no se le ha hecho
clasificación, también se debe cancelar la operación y generar un mensaje donde se indique lo sucedido.
Línea 3: Si un usuario no tiene dirección electrónica, se debe generar un archivo de tipo log, donde se
indique lo sucedido.
7. Precondiciones
Debe existir en el sistema la definición de perfiles, la asociación de usuarios-perfiles, una norma creada y
clasificada.
8. Post Condiciones
Se envía por mail, la modificación/clasificación de la norma a cada uno de los usuarios asociados al perfil
dado en la entrada.
9.1 Mensaje a usuarios
Se debe definir la manera como sería enviado el mensaje a los usuarios, para indicarles de la modificación
de la norma.


INFORMACIÓN JURÍDICA

AdministrarInformaciónJurídica.doc

03/05/05 1.0 Versión Inicial D.Rubiano
01/06/05 2.0 Cambió de nombre, pasando de “Registrar D.Rubiano
normas” a “Administrar información
jurídica”. Se tuvo en cuenta que la
información jurídica debe obedecer a
conceptos de administración, que implican
su registro y continuo mantenimiento en el
sistema. También toma lo descrito para los
casos de uso de nombres
“ActualizarNormas” y “ClasificarNormas”.

Caso de Uso Administrar Información Jurídica

Este caso de uso tiene por objetivo que el usuario pueda administrar la información jurídica (se
refiere a la normatividad que soporta el desarrollo de los diferentes casos que lleva la PGN – Por
ejemplo: Normas, leyes, decretos, sentencias y doctrinas), teniendo en cuenta que esta debe ser
ingresada (capturada), algunas veces simplemente consultada, y en casos de error, modificada
(corregida) o eliminada. La información jurídica que se administrará obedece a los siguientes
tipos: Legislación, jurisprudencia y doctrina. En referencia a los servidores de la PGN, en general
la información que se administra en la implementación del presente caso de uso, sólo puede ser
consultada y dependiendo del tipo de usuario no se debe admitir ninguna clase de alteración del
documento, salvo que el Administrador necesite hacer correcciones sobre el texto del mismo
(Que por alguna razón se haya incorporado un texto que no coincida con el original del
documento que contiene la información jurídica).

2.1 Iteración
0.
2.2 Prioridad
Alta.
2.3 Complejidad
Alta.
• Para todas las opciones (Consulta, Modificación (corrección), Ingreso (captura) y
Eliminación): Administrador SIREL.
• Para la opción de Consulta: Servidor PGN.
4. Entradas
Para Ingreso y Modificación1:
• Identificador de la información jurídica (Automático).

• Nombre de la información jurídica.
1
Para el caso de la Modificación, se debe señalar si se produce una copia de los registros o se hace modificación sobre el original.
Por ejemplo: Una corrección por error implica una modificación sobre el registro original. Una modificación por cambios en una ley,
significa la creación de nuevos registros.
• Tipo de información jurídica (Legislación, jurisprudencia o doctrina).

• Texto de la información jurídica.
• Identificador de los temas asociados (Cada tema tiene asociados de forma previa los
correspondientes descriptores y restrictores).
• Restrictores asociados a los temas seleccionados (algunos o todos con respecto a los
asociados de forma previa al tema).
• Descriptores asociados a los temas seleccionados (algunos o todos con respecto a los
asociados de forma previa al tema).
• Restrictores extras (fuera de los asociados de forma previa al tema).
• Descriptores extras (fuera de los ya asociados de forma previa al tema).
• Estado de la información jurídica (Por ejemplo: Activa, derogada).
• Autor.
• Fecha de creación.
• Identificación de la entidad responsable de de la información jurídica.
Para Consulta y Eliminación:
• Identificador de la información jurídica (Automático).
Nota: La información que corresponde a los casos que lleva la PGN es ingresada directamente
desde el SIMIP, por medio de una interfaz (Ver el caso de uso de nombre “SIREL -
SIMIP_INT_4SugerirCaso”). El manejo de esta información se hace en SIREL, por medio del
caso de uso de nombre “SIREL_INT_2EvaluarCasosSugeridos”.
5. Salidas
Para Ingreso: Un nuevo registro en el sistema SIREL que contiene todos los datos suministrados
en las entradas.
Modificación: Un registro modificado en el sistema SIREL, de acuerdo a los datos suministrados

en las entradas.
Eliminación: Se elimina del sistema SIREL el registro que corresponde a los datos suministrados
en las entradas.
Consulta: Se despliegan en una pantalla todos los datos de un registro de información jurídica,
que corresponde a los datos de las entradas.
6. Flujo de Eventos
6.1 Flujo Básico


Administración de información jurídica.
2. SIREL despliega una pantalla para que el usuario
seleccione cualquiera de 4 opciones: Ingreso,
consulta, modificación o eliminación de datos.
3. El usuario selecciona una de las 4 opciones.
4. Si la opción es ingreso, el sistema despliega una
pantalla, para que el usuario ingrese los datos de la
entrada.
Administrador de SIREL), diligencia cada uno de
los campos de la entrada (Uno por cada entrada, a
excepción del identificador de información
jurídica que se genera de forma automática).
Ejecuta la opción de guardar información.
6. El sistema crea un registro (genera el
identificador de forma automática) de información
jurídica y lo almacena.
7. Si es consulta, el sistema despliega una pantalla
para que el usuario registre los datos de la
información que desea consultar. Se ejecuta la
implementación del caso de uso
“BuscarInformación” con Tipo de búsqueda: Sólo
información jurídica. “Buscar información”, según
sea el caso, encuentra justamente el registro del caso
cuyo valor de código – registro de la información
jurídica cuyo valor de identificador, coinciden con
el que se suministra en las entradas.
8. Si es modificación, el sistema despliega una
información que desea modificar. Se ejecuta la
Administrador de SIREL) modifica los datos de
entrada que requiera sobre la pantalla desplegada.
Ejecuta la opción de guardar información
modificada
10. El sistema almacena el registro modificado de la
información jurídica. Se debe tener en cuenta el tipo
de modificación, si es por corrección por error, se

modifica sobre el registro original. (Por ejemplo: si
es por modificación sobre una ley, se debe crear un
nuevo registro).
11. Si es eliminación, el sistema despliega una
información que desea eliminar. Se ejecuta la
12. Si el usuario cuenta con los permisos (El
Administrador de SIREL) apropiados, ejecuta la
opción de eliminación del registro seleccionado.
13. El sistema elimina el registro seleccionado de su
medio de almacenamiento.

Línea 6: Si la identificación de la información histórica ya existe en el sistema, se cancela la
operación y se despliega un mensaje al administrador donde se le describe la situación.
Líneas 5 y 9. Si se trata de una entidad responsable que no ha sido registrada en el sistema, se
debe dar la opción de que el usuario la ingrese como una entidad nueva. En el momento de hacer
el almacenamiento del registro ingresado/modificado se almacena la nueva entidad en el sistema.
7. Precondiciones
Se deben diligenciar completamente los datos de entrada para el registro de la norma.
Respecto a las pantallas que se despliegan, tanto para ingreso, como para el caso de uso
“BuscarInformaciónJurídica”, se debe tener en cuenta que los valores concernientes a Tipo de
información, Temas asociado, Descriptores y Restrictores e Identificación de la entidad han sido
ingresados de forma previa al sistema, y que el usuario sólo hace una selección de una lista. En
caso de necesitar hacer cambios sobre las relaciones (asociaciones) entre los temas y sus
restrictotes y descriptores, el administrador deberá recurrir al caso de uso “SIREL –
AdministrarTemas”.
Los descriptores extras sobre los cuales se puede hacer selección en las entradas, deben estar
relacionados con los restrictores seleccionados.
Los registros de información jurídica, como mínimo deben contener los datos de las entradas.
8. Post Condiciones
Para Ingreso: Un nuevo registro en el sistema SIREL que contiene todos los datos suministrados
en las entradas.

Modificación: Un registro modificado en el sistema SIREL, de acuerdo a los datos suministrados

en las entradas.
en las entradas.
Consulta: Se despliegan en una pantalla todos los datos de un registro de información jurídica,
que corresponde a los datos de las entradas.
Se crea un nuevo registro de información jurídica en el sistema SIREL.
En general, cuando la operación realizada es exitosa, se ejecuta la implementación del caso de
uso “ComunicarCambiosUsuarios”.

Se deben revisar las entradas y de ser necesario ampliarlas, indicando sus longitudes y tipos,
además de cuales son opcionales y cuáles obligatorias, por ejemplos los restrictotes y descriptores
extras son opcionales.
9.2 Estado de la información jurídica

En diseño, prestar especial atención a los diferentes estados que puede tener las diferentes
informaciones jurídicas.


LINKS INTERNOS

AdministrarLinksInternos.doc

05/07/05 1.0 Versión Inicial. Forma parte del caso de C.Díaz
uso “Administrar Información Jurídica”.
Requerimientos Detallados Módulo SIREL (Documento Final) Pág .A4- 26

Caso de Uso Administrar Links Internos

El presente caso de uso tiene como objetivo, consultar/establecer (ingresar -
crear)/modificar/borrar dentro de un texto de una información jurídica, un link en referencia a
otro fragmento del mismo texto (Subtexto).

2.1 Iteración
0.
2.2 Prioridad
Alta.
2.3 Complejidad
Alta.
4. Entradas
Para modificación y establecimiento (ingreso - creación):
• Identificador de la información jurídica.

• Identificador del subtexto que referencia.
• Identificador del subtexto que es referenciado.

Identificador del registro de asociación entre subtextos
5. Salidas
Para Ingreso: Un nuevo registro en el sistema SIREL que contiene la información que determina
asociación entre subtextos de una información jurídica.
Modificación: Un registro de asociación entre subtextos modificado en el sistema SIREL, de
acuerdo a los datos suministrados en las entradas.

en las entradas.
Consulta: Al encontrar la referencia a un subtexto dentro de un subtexto que referencia, el sistema

por acción del usuario mostrará el texto referenciado.
6. Flujo de Eventos
6.1 Flujo Básico
selecciona la opción de “Administrar links
internos”.
2. El sistema despliega una pantalla para que el
usuario del sistema pueda seleccionar una de 4
opciones (consultar/establecer/modificar/borrar).
3. El administrador selecciona una de las 4
opciones.
4. Si la opción es de ingreso, el usuario deberá

seleccionar el subtexto que referencia y el
subtexto referenciado.
5. El sistema asigna identificadores a los subtextos y
crea y almacena un registro de asociación. Sobre el
texto de la información jurídica se deberá distinguir
el subtexto que referencia.
6. Si la opción es de consulta, el usuario señalará
7. El sistema identifica el identificador del subtexto
señalado y busca en su medio de almacenamiento el
correspondiente registro de asociación de subtextos
y extrae el identificador de subtexto referenciado.
Una vez es extraído el identificador del subtexto
referenciado, se muestra al usuario el contenido.
8. Si la opción es de modificación, el usuario
señalará subtexto que referencia y el subtexto
referenciado.
9. El sistema identifica el identificador de subtexto
Una vez encontrado el registro, lo elimina.
10. Se ejecutan las acciones de la línea 5.
11. Si la opción es de borrado, el usuario señalará


subtexto que referencia

Ninguno.
7. Precondiciones
El usuario debe tener claro cuales son los subtextos sobre los cuales quiere establecer los links.
8. Post Condiciones
Según sea el caso se crear/ modificar/consultar/borrar registros de asociación de subtextos.
9.1 Definición de perfiles y tipos
Se debe en la etapa de diseño, definir cuál sería el mecanismo que permite la administración de
los links, además de las estructuras de datos que almacenan este tipo de información.


LINKS EXTERNOS

AdministrarLinksExternos.doc

05/07/05 1.0 Versión Inicial. Forma parte del caso de C.Díaz
uso “Administrar Información Jurídica”.

Caso de Uso Administrar Links Externos

El presente caso de uso tiene como objetivo, consultar/establecer (ingresar -
crear)/modificar/borrar dentro de un texto de una información jurídica, un link en referencia a
otra información jurídica.

2.1 Iteración
0.
2.2 Prioridad
Alta.
2.3 Complejidad
Alta.
4. Entradas
Para modificación y establecimiento (ingreso - creación):
• Identificador de la información jurídica desde donde se referencia.

• Identificador del subtexto que referencia.
• Identificador de la información jurídica referenciada.
• Tipo de link (histórico, no histórico): Indica si la información jurídica referenciada hace
parte o no de la historia de la información jurídica que está siendo consultada desde
“Buscar información”.

Identificador del registro de asociación entre un subtexto y una información jurídica
5. Salidas

Para Ingreso: Un nuevo registro en el sistema SIREL que contiene la información que determina
asociación entre un subtexto de una información jurídica y otra información jurídica.
Modificación: Un registro de asociación entre un subtexto de una información jurídica y otra
información jurídica, modificado en el sistema SIREL, de acuerdo a los datos suministrados en
las entradas.
en las entradas.
Consulta: Al encontrar la referencia a un subtexto dentro de un subtexto que referencia, el sistema

por acción del usuario mostrará los datos de la información jurídica referenciada.
6. Flujo de Eventos
6.1 Flujo Básico
selecciona la opción de “Administrar links
externos”.
usuario del sistema pueda seleccionar una de 4
opciones (consultar/establecer/modificar/borrar).
3. El administrador selecciona una de las 4
opciones.
4. Si la opción es de ingreso, el usuario deberá

seleccionar el subtexto que referencia y luego
ejecutar la implementación del caso de uso
“BuscarIformación”, para seleccionar de la lista
resumida de éste, la información jurídica que se
desea referenciar.
5. El sistema asigna un identificador al subtexto y
crea y almacena un registro de asociación en donde
se incluye éste identificador y el de la información
jurídica seleccionada. Sobre el texto de la
información jurídica se deberá distinguir el subtexto
que referencia.
6. Si la opción es de consulta, el usuario señalará
7. El sistema identifica el identificador del subtexto
señalado, busca en su medio de almacenamiento el
correspondiente registro de asociación y extrae el
identificador de la información jurídica
referenciada. Una vez es extraído el identificador de
la información jurídica referenciada, se muestra al


usuario el contenido detallado de la misma.
8. Si la opción es de modificación, el usuario
señalará subtexto que referencia y luego ejecutará
la implementación del caso de uso
“BuscarIformación”, para seleccionar de la lista
resumida de éste, la información jurídica que se
desea referenciar.
9. El sistema identifica el identificador de subtexto
Una vez encontrado el registro, lo elimina.
11. Si la opción es de borrado, el usuario señalará
subtexto que referencia

Ninguno.
7. Precondiciones
El usuario debe tener claro cuales son los subtextos sobre los cuales quiere establecer los links.
8. Post Condiciones
Según sea el caso se crear/ modificar/consultar/borrar registros de asociación entre subtextos e
informaciones jurídicas.
9.1 Definición de perfiles y tipos
Se debe en la etapa de diseño, definir cuál sería el mecanismo que permite la administración de
los links, además de las estructuras de datos que almacenan este tipo de información.

CASO DE USO CONSULTAR

LISTA LINKS INFORMACIÓN
JURÍDICA

ConsultarListaLinksInformaciónJurídica.doc

03/05/05 1.0 Versión Inicial. C.Díaz

Caso de Uso Consultar Lista Links Información

Jurídica
El presente caso de uso tiene como objetivo, dados unos parámetros de búsqueda, mostrar de
forma resumida, una lista donde se pueda distinguir para las diferentes informaciones jurídicas
seleccionadas, los links internos y externos establecidos. En el caso de los links externos se debe
indicar la calidad de los mismos, determinando si son de carácter histórico o no.

2.1 Iteración
0.
2.2 Prioridad
Alta.
2.3 Complejidad
Alta.
4. Entradas
Generación de la lista para una información jurídica específica:
Identificador de la información jurídica.
Parámetros generales de búsqueda:

• Rangos de fechas de creación de las informaciones jurídicas.
• Tipo de información (Legislación, Jurisprudencia y/o Doctrinas).
• Temas.
• Restrictotes.
• Descriptores.
Otros parámetros de búsqueda:

• Sólo links internos.

• Sólo links externos no históricos.
• Sólo links externos históricos.
• Los dos tipos de links.
• Mostrar información jurídica que no tiene links internos.
• Mostrar información jurídica que no tiene links externos históricos.
• Mostrar información jurídica que no tiene links externos no históricos.
• Generación de reporte Si o No?.
5. Salidas
Una lista donde por cada información jurídica seleccionada, se debe mostrar:
• Identificador de la información jurídica.
• Autor de la información jurídica.
Dependiendo de las entradas:

• Links internos (Fragmento de texto que referencia, Fragmento de texto referenciado).
• Links externos históricos: Identificador de la información jurídica, Nombre de la información
jurídica. Estado de la información jurídica.
• Links externos no históricos: Identificador de la información jurídica, Nombre de la
información jurídica.
• Estado de la información jurídica.
6. Flujo de Eventos
6.1 Flujo Básico

1. Este caso de uso comienza cuando el usuario,
selecciona la opción de “Consultar Lista de Links
de Información Jurídica”. También se activa
cuando desde el caso de uso
“BuscarInformación” se ejecuta el presente caso
de uso, para una información específica que está
siendo consultada.
2. El sistema toma la información de las entradas y
hace la búsqueda en su medio de almacenamiento
de los correspondientes registros.


3. El sistema arma la lista y la despliega para la
consulta del usuario. Si la entrada “Generación de
reporte” está activa se hace la respectiva impresión.
4. El usuario puede seleccionar algunos de los
links internos y externos para consultar su detalle.
5. Si se trata de links externos, el sistema despliega
una pantalla con el detalle de la información de la
información jurídica:
• Identificador de la información jurídica
• Tipo de información jurídica (Legislación,
jurisprudencia o doctrina).
• Texto de la información jurídica.
• Identificador de los temas asociados.
• Restrictores asociados a los temas seleccionados
• Descriptores asociados a los temas seleccionados
• Restrictores extras.
• Descriptores extras.
• Estado de la información jurídica (Por ejemplo:
Activa, derogada).
• Autor.
• Identificación de la entidad responsable de de la
6. Si se trata de links internos, el sistema despliega
en una pantalla el respectivo subtexto.
Línea 3: En caso de que no existan links, el sistema debe indicar para cada información jurídica
con qué tipo de links no cuenta.
Líneas 5 y 6: Debe existir una opción que permita al usuario regresar a la línea 4.
7. Precondiciones
Deben existir previamente en el sistema los diferentes links.
8. Post Condiciones
Se crean y almacenan en el sistema registros de asociación entre el perfil y el tema.

9.1 Definición de las entradas.
En diseño se deben revisar las entradas y si es necesario ampliarlas. Para las entradas es necesario
definir los nombres exactos, los tipos y las longitudes.

CASO DE USO BUSCAR

INFORMACIÓN JURÍDICA

SIREL - BuscarInformaciónJurídica v3.0.doc


Caso de Uso Buscar Información Jurídica

El presente caso de uso tiene como objetivo permitir la búsqueda y consulta de información
jurídica o de casos sugeridos, dados algunos criterios de búsqueda. No necesariamente se debe
suministrar valores a todos los criterios y la búsqueda de la información puede obedecer a una
combinación de los mismos.

2.1 Iteración
0.
2.2 Prioridad
Alta.
2.3 Complejidad
Alta.
• Administrador de SIREL y servidor PGN.
4. Entradas
El usuario puede combinar en su búsqueda los siguientes criterios de búsqueda:
• Tipo de información (Legislación, Jurisprudencia y/o Doctrinas).

• Temas.
• Restrictotes extras1.
• Descriptores extras.
• Sinónimos.
• Antónimos.
• Tipo de búsqueda: Sólo información jurídica (por ejemplo: Normas), sólo casos
representativos, los dos anteriores.
1
Los temas ya tienen unos descriptores y resctrictores asociados.

En caso de querer incorporar a la búsqueda registros de información jurídica:
Cualquiera de las siguientes entradas:
• Identificador de información jurídica

• Entidad responsable de la información jurídica.
• Rango de fechas de creación de la información jurídica.
• Autor de la información jurídica.
• Rango de fechas de creación de la información jurídica.
• Identificación de la entidad responsable de de la información jurídica.
En caso de querer incorporar a la búsqueda registros de casos representativos:
Cualquiera de las siguientes entradas:
• Tipo de liberación a servidores PGN (Total, Parcial, No liberación).

• Dependencia.
• Número de Expediente.
• Rango de fechas de liberación total.
• Rango de fechas de liberación parcial.
• Tipo de Origen de la solicitud que dio origen al caso.
• Tipo de modalidad (si es verbal, en caso de ser de tipo disciplinario).
• Tipo de derecho afectado (en caso de ser preventivo).
• Tipo de autoridad judicial (en caso de ser de intervención).
• Identificación del funcionario que propone el caso.
• Rango de fechas en las que se proponen casos.
• Identificador de evaluación en un valor tal que indica que el caso no ha sido evaluado por
el administrador de SIREL.
• Identificador de aceptación o negación del caso.
• Identificador de liberación de la información (Total, parcial, No liberación)2.
2
La “liberación” es el proceso mediante el cual se marca el registro de la información jurídica, como un registro que puede ser
consultado por cualquier servidor de la PGN. Cuando se trata de una liberación parcial, es porque se requiere que sólo unos
cuantos servidores públicos lo puedan consultar. Por defecto los registros son creados en estado no liberado.

• Rango de fechas de liberación total.

• Rango de fechas de liberación parcial.
• Concepto acogido.
• Acción.
• Sujetos partes.
5. Salidas
Según el tipo de búsqueda se despliegan los registros de información jurídica y/o los registros de
casos representativos que corresponde a los valores suministrados en las entradas.
En caso de que el usuario tenga los permisos apropiados, se modifican los valores
correspondientes a los registros de Historia de la información jurídica y/o los links internos y
externos de la información jurídica consultada.
6. Flujo de Eventos
6.1 Flujo Básico

1. Este caso de uso comienza cuando el usuario,
selecciona alguna de las opciones de “Administrar
información jurídica” (Exceptuando la de Ingresar
información jurídica), o cuando el usuario
selecciona la opción de “Evaluar caso sugerido”.
También se le da inicio al caso de uso cuando se
selecciona directamente la opción de “Búsqueda
de de información Jurídica”.
usuario pueda diligenciar los datos de las entradas.
3. El usuario diligencia los datos de las entradas.
4. El sistema busca en su medio de almacenamiento
los registros de información jurídica y/o de casos
representativos que coincidan con los valores
suministrados a las entradas.
5. El sistema despliega un listado resumido con
todos los correspondientes registros. Este listado
muestra los siguientes datos:
Por cada registro de caso representativo:
• Tipo de caso (Preventivo, Disciplinario,
Intervención).
• Tipo de Origen de la solicitud que dio origen al
caso.


• Tipo de modalidad (si es verbal, en caso de ser
de tipo disciplinario).
• Tipo de derecho afectado (en caso de ser
preventivo).
• Tipo de autoridad judicial (en caso de ser de
intervención).
• Identificación del funcionario que propone el
caso.
• Fecha en la que se propone el caso.
• Estado de liberación del caso.
Por cada registro de información jurídica:
• Identificador de la información jurídica
• Tipo de información jurídica (Legislación,
jurisprudencia o doctrina).
• Autor.
• Identificación de la entidad responsable de de la
6. El usuario selecciona del listado la
información que desea consultar en detalle.
7. El sistema despliega una pantalla con el detalle de
la información seleccionada en el listado (Para una
información jurídica despliega los datos de las
entradas, para modificación e ingreso, del caso de
uso “Administrar información jurídica”. Para un
caso relevante, muestra las estradas del caso de uso
“SIREL_INT_2EvaluarCasosSugeridos”). Si se
trata de un registro referente a información jurídica,
desde esta pantalla el usuario debería poder ejecutar
las implementaciones de los siguientes casos de uso:
• “ConsultarListaLinksInformaciónJurídica”,
sólo para la entrada Generación de la lista para
una información jurídica específica (pasando
como parámetro el identificador de la
información jurídica que está siendo consultada
por el presente caso de uso).
• “AdministrarLinksExternos”
• “AdministrarLinksInternos”


Línea 7: Debe existir una opción para regresar al listado, es decir al paso 6.
7. Precondiciones
Deben existir previamente en el sistema la información concerniente a: Temas, Restrictotes,
Descriptores, Sinónimos, Antónimos y/o Entidad responsable de la información jurídica.
Se debe tener en cuenta que cuando se selecciona alguna de las opciones de “Administrar
información jurídica”, se ejecuta en forma exclusiva con tipo de búsqueda para información
jurídica. Que cuando se trata de “Evaluar Caso Sugerido” se ejecuta en forma exclusiva con tipo
de búsqueda para Casos sugeridos. Cuando se trata de la opción “Búsqueda de de información
Jurídica”, se puede ejecutar en los dos o cualquiera de los dos tipos de búsqueda (Información
jurídica y/o casos representativos).
Cuando se origina en una opción diferente a “Búsqueda de de información Jurídica”, los valores
se despliegan (línea 7 del flujo básico) con opción de ser modificados.
Cuando se trata de información de un caso representativo, accedida por un servidor PGN,
diferente al administrador del sistema SIREL, el listado de la línea 5 obedece sólo a los casos que
ya han sido liberados; en referencia a los casos con liberación parcial, además de los casos
liberados totalmente, se adicionaran al listado, aquellos de liberación parcial que hayan sido
liberados para el servidor que está accediendo al sistema.
Nota: Tipo de búsqueda es uno de los parámetros de la entrada.
8. Post Condiciones
Se despliega en una pantalla el detalle de un registro correspondiente a un caso representativo o a
una información jurídica.
Se deben revisar las entradas y de ser necesario ampliarlas, indicando sus longitudes y tipos,
además de cuales son opcionales y cuáles obligatorias. En la entrada de datos se debe tener en
cuenta que existen unos datos básicos y otros ocasionales, y que éstos últimos dependen en su
obligatoriedad de los valores suministrados a los básicos. Por ejemplo: No se debe solicitar Tipo
de modalidad cuando la Tipo de caso es Preventivo.

CASO DE USO GENERAR

DOCUMENTO

GenerarDocumento.doc


Caso de Uso Generar Documento

El presente caso de uso tiene como objetivo permitir la generación automática de documentos con
las informaciones jurídicas y los casos representativos que se encuentren a partir de una búsqueda
de información (Ver el caso de uso “Buscar Información Jurídica”) sobre el medio de
almacenamiento del sistema. Este caso de uso debe permitir en el documento generado, la
incorporación de títulos, subtítulos e índices, además de mantener los links internos y externos a
discreción del usuario.

2.1 Iteración
0.
2.2 Prioridad
Alta.
2.3 Complejidad
Alta.
4. Entradas
Información general:
• La información producida a partir de una búsqueda (Ver el caso de uso

“BuscarInformación”).
• Título general del documento.
• Tipo de letra para textos que no son títulos.
• Tamaño de la letra para textos que no son títulos.
• Color de letra para textos que no son títulos.
• Tipo de letra para títulos.
• Tamaño de letra para títulos.
• Color de letra para títulos.

• Número de niveles en subtítulos.
Por cada nivel de subtítulo:

• Tipo de letra para subtítulos.
• Tamaño de letra para subtítulos.
• Color de letra para subtítulos.
Para los links internos y externos (si existe la necesidad de diferenciarlos):

• Tipo de letra para links.
• Tamaño de letra para links.
• Color de letra para links.
• Tipo de Numeración para títulos y subtítulos (numérica y alfabética).
• Responsable.
5. Salidas
• Registro de creación del documento (Título, fecha y responsable).
• Documento generado.
6. Flujo de Eventos
6.1 Flujo Básico

generar documento.
2. Si el usuario cuenta con los permisos indicados
(se trata del Administrador del sistema), el sistema
despliega una pantalla para que el administrador del
mismo pueda diligenciar los criterios de búsqueda
de los datos que conformarán el documento. Se
ejecuta la implementación del caso de uso
“BuscarInformación”.
3. El sistema toma los registros encontrados en la
búsqueda anterior y los despliega en una lista
resumida.
4. Por cada registro de la lista, el usuario
diligencia los valores que indican si se trata de


información de un subtítulo y de ser así, indica los
valores correspondientes a los niveles de
subtítulos y subtítulos. Además determina cuáles
links internos y externos deben permanecer como
parte del texto del documento que se va a generar.
5. El usuario registra los demás valores de las
entradas.
6. El sistema genera el documento texto
conservando los links internos y externos indicados
en la línea 5.

Ninguno.
7. Precondiciones
Deben existir previamente en el sistema, la información correspondiente a la información jurídica
y casos representativos.
8. Post Condiciones
Se genera el correspondiente documento y el registro con los datos que indica la generación del
documento.
Se debe revisar las entradas con el ánimo de determinar si son suficientes para la generación del
documento. Por cada entrada se debe definir los nombres de los datos, sus longitudes y tipos.
9.2 Herramienta de generación del documento

En diseño se debe hacer una propuesta de herramienta que permita generar automáticamente el
documento a partir de los valores de casos representativos y de informaciones jurídicas
almacenadas en el sistema.

CASO DE USO
SIREL_INT_1.CONSULTAR TEMAS

SIREL_INT_1ConsultarTemas.doc

05/07/05 2.0 Este caso de uso es producto de los ajustes D. Rubiano
sobre el caso de uso
“SIREL_INT_1.Consultar Marco Base”

Caso de uno SIREL_INT_1.Consultar Temas

Este caso de uso tiene como objetivo que un usuario autorizado en SIMIP pueda consultar
automáticamente de SIREL los diferentes temas (grupos de descriptores) allí creados, esto
con el fin de que el usuario pueda asociar un caso a un tema específicoClasificación del
Caso de Uso.
• SIMIP
3. Entradas
Mensaje con la solicitud de consulta de los temas.
4. Salidas
Registros de los diferentes temas creados en SIREL. Por cada tema el identificador del
tema, los descriptores asociados, por cada descriptor los antónimos y sinónimos, además de
los restrictores asociados al tema y una breve descripción del tema.
5. Flujo de Eventos
5.1 Flujo Básico

1. Este caso de uso comienza cuando desde el
sistema SIMIP, se selecciona la opción de
sugerencia de caso. Cuando esto sucede se
genera un mensaje hacia el sistema SIREL
solicitando los temas allí creados y
almacenados.
2. SIREL recibe el mensaje y busca en su medio
de almacenamiento todos los registros de temas,
incluyendo el identificador del tema, los
descriptores asociados, por cada descriptor los
antónimos y sinónimos, además de los
restrictotes y de la descripción del tema.
3. SIREL crea un mensaje que involucra la
información de todos los temas y lo envía hacia
SIMIP.
4. Recibe el mensaje de SIREL y extrae del
mismo la información de los temas para
desplegarla en la correspondiente pantalla con


el ánimo de que el usuario pueda seleccionar
los temas de su interés. La información
desplegada debe permitir identificar por cada
tema el identificador del tema, los descriptores
asociados, por cada descriptor los antónimos y
sinónimos, además de los restrictotes del tema
y de la descripción del tema.

Línea 3: Si no existen registros de temas en SIREL, se envía un mensaje a SIMIP, donde se
indique de la situación.
6. Precondiciones
Los temas deben estar definidos con anterioridad en el sistema SIMIP.
7. Post Condiciones
Se retorna un mensaje de SIREL a SIMIP con todos los registros de los temas creados y
almacenado en el SIREL.
8.1 Definición de mensajes entre los dos sistemas.
En diseño, se debe definir la manera como los dos sistemas intercambiarán mensajes y las
estructura de los mismos.
8.2 Definición de la estructura de datos de los temas
Se deben definir cuáles serían las características de las estructuras que almacenan los temas
en SIREL, nombres, tipos y longitudes, además de obligatoriedad e integridad de datos.

CASO DE USO
SIREL_INT_2.EVALUAR CASOS
SUGERIDOS

SIREL_INT_2EvaluarCasosSugeridos.doc

05/05/05 2.0 Este caso de uso es producto de los ajustes D. Rubiano
sobre el caso de uso
“SIREL_INT_3.Evaluar Descriptor
Sugerido”.

Caso de uso SIREL-INT_2.Evaluar Casos

Sugeridos
Este caso de uso tiene por objetivo tomar los casos sugeridos por usuarios SIMIP, y
presentarlos al administrador de SIREL, para que él haga una evaluación de los mismos y
decida si se deben o no ser tenidos en cuenta en SIREL como casos representativos.
• Para la opción de Modificación: Administrador SIREL.
• Para la opción de Consulta: Servidor PGN.
3. Entradas
Por cada registro de caso sugerido se pueden diligenciar los siguientes valores:
• Identificador de evaluación en un valor tal que indica que el caso ya fue evaluado
por el administrador de SIREL.
• Identificador de liberación de la información (Total, parcial, No liberación)1.
• En caso de ser liberación parcial, se debe registrar las direcciones electrónicas de

los servidores a los que se le es liberada la información.
• Fecha de liberación total.
• Fecha de liberación parcial.
• Lista de informaciones jurídicas sobre las cuales se sustentó el desarrollo del caso,
por ejemplo: Normas que sustentan el desarrollo y las decisiones tomadas por el
servidor PGN en el caso representativo.
1
La “liberación” es el proceso mediante el cual se marca el registro de la información jurídica, como un registro que puede
ser consultado por cualquier servidor de la PGN. Cuando se trata de una liberación parcial, es porque se requiere que
sólo unos cuantos servidores públicos lo puedan consultar. Por defecto los registros son creados en estado no liberado.

4. Salidas
Se actualiza un registro de datos referente a un caso representativo.
5. Flujo de Eventos
5.1 Flujo Básico

administrador de SIREL selecciona la opción
de Evaluación de casos sugeridos de SIMIP.
2. Se ejecuta la implementación del caso de uso
de nombre “BuscarInformación” con Tipo de
búsqueda: “Sólo Casos representativos”. El caso
de uso encuentra justamente el caso
representativo cuyo valor de código es el que se
suministra en las entradas. Despliega en una
pantalla los datos del caso representativo.
apropiados (Se trata del administrador de
SIREL), evalúa (Acepta o niega la
incorporación del caso en SIREL como caso
representativo) la conveniencia del caso
desplegado, y si es necesario corrige la
información relacionada con el tema. En caso
de negar la incorporación del caso, debe
diligenciar el respectivo indicador. En caso de
aceptación, si el usuario lo cree conveniente,
ingresa los datos de liberación del caso.
Para todo caso aceptado, el usuario deberá
establecer/modificar la lista de informaciones
jurídicas que soportaron su desarrollo. Esta
información se establece a partir de la lista de
informaciones jurídicas suministradas por el
usuario SIMIP, en el momento de hacer la
sugerencia del caso (Ver el caso de uso
“SIMIP_INT_4SugerirCaso”).
4. SIREL, dependiendo de la situación
(Aceptación o negación) marca el
correspondiente registro con el valor apropiado.
En caso de negación almacena además la causa
de la misma
Una vez se realiza la afectación del caso por la
evaluación del usuario, el registro debe marcarse
automáticamente como evaluado.
En caso de liberación parcial, de forma


automática se envía un mail a las direcciones de
los servidores PGN interesados, con la
información del caso.
Línea 3: Si el usuario encuentra que no existen las identificaciones de las informaciones

jurídicas (por ejemplo normas), sugeridas por el usuario SIMIP, deberá suspender el
proceso de verificación, para hacer la verificación de la información jurídica sugerida y
dado el caso, hacer su ingreso al sistema (Ejecutar la implementación del caso de uso
“Administrar Información Jurídica”). En caso de encontrar inconsistencias durante la
verificación de la información jurídica sugerida por el usuario SIMIP, deberá ejecutar la
implementación del presente caso de uso, indicando para el caso sugerido la no aceptación
y su causa.
Línea 3: En caso de pretender liberar un caso no aceptado el sistema cancelará la operación
y desplegará un mensaje indicándole al usuario de la situación. El usuario del sistema puede
liberar el caso en una fecha diferente a la de su aceptación.
Línea 3: En caso de haber sufrido alguna evaluación anterior, y se requiera de alguna
corrección, el usuario del sistema podrá pasar de un caso aceptado a uno negado, para esto,
adicionalmente deberá diligenciar la causa de la situación. De cualquier forma el sistema
debe llevar un histórico de las acciones que se realicen sobre los casos, identificando
siempre el usuario que las ejecuta.
Líneas 4: En caso de querer ir de nuevo al listado resumido de los casos, la implementación
del caso de uso debería poder dejar que el usuario vaya de nuevo a la línea 2, a la línea que
corresponde al despliegue del listado resumido de casos representativos (En el caso de uso
“BuscarInformación”).
6. Precondiciones
El registro del caso representativos debe contener valores, según las entradas del caso de
uso de nombre “SIREL - SIMIP_INT_4SugerirCaso“.
7. Post Condiciones
Se modifican los registros de los casos desplegados en la pantalla y que fueron evaluados
por el Administrador. Los registros son modificados en los siguientes campos:
• Identificador de evaluación en un valor tal que indica que el caso ya fue evaluado
por el administrador de SIREL.

• Identificador de evaluación en un valor tal que indica que el caso no ha sido

evaluado por el administrador de SIREL.
• Identificador de liberación de la información (Total, parcial, No liberación).
• En caso de ser liberación parcial, se debe registrar las direcciones electrónicas de

los servidores a los que se le es liberada la información.
• Fecha de liberación total.
• Fecha de liberación parcial.
• Lista de informaciones jurídicas sobre las cuales se sustentó el desarrollo del caso.
En general, cuando la operación realizada es exitosa y es con respecto a un caso

representativo liberado, se ejecuta la implementación del caso de uso
“ComunicarCambiosUsuarios”.
8.1 Definición de las estructuras que permiten el almacenamiento de los casos sugeridos.
Se deben definir cuáles serían las características de las estructuras que almacenan los casos
sugeridos en SIREL, nombres, tipos y longitudes, además de obligatoriedad e integridad de
datos.

ANEXO 5 – DIAGRAMAS DE SECUENCIA
Requerimientos Detallados –Diagramas de Secuencia (Documento Final) Pág.A5-1

TABLA DE CONTENIDO
Tema Pg.
1. DEFINICIÓN .................................................................................................................. 5
2. DIAGRAMA DE SECUENCIAS .................................................................................. 5
2.1 Diagrama de Secuencia del caso de uso: Definir Ruta y Plan de Actividades ............. 5
2.2 Diagrama de Secuencia del caso de uso: Asignar Servidor/Equipo de Trabajo a

Solicitud/Caso .............................................................................................................................. 8
2.3 Diagrama de Secuencia del caso de uso: Marcar Cierre Caso ...................................... 11
2.4 Diagrama de Secuencia del caso de uso: Registrar Conclusiones ............................... 13
2.5 Diagrama de Secuencia del caso de uso: Administrar Préstamos Expedientes.......... 14
2.6 Diagrama de Secuencia del escenario de uso: Ciclo de vida de una solicitud/caso .. 15

CONTROL DE VERSIONES DEL DOCUMENTO
Fecha Versión Revisado por Comentario

Actualización
03/08 /2005 1.0 Hernán Velásquez. Versión inicial
Disney Rubiano

INDICE DE ILUSTRACIONES
ILUSTRACIÓN 1 DIAGRAMA DE SECUENCIA DEL CASO DE USO: Definir Ruta y Plan de

Actividades Componentes de un diagrama de casos de uso.............................................................7
ILUSTRACIÓN 2 DIAGRAMA DE SECUENCIA DEL CASO DE USO: Asignar Servidor/Equipo

de Trabajo a
Solicitud/Caso................................................…………………………………………..…………9
ILUSTRACIÓN 3 DIAGRAMA DE SECUENCIA DEL CASO DE USO: Marcar Cierre

Caso............................................................………………………………………………………12
ILUSTRACIÓN 4 DIAGRAMA DE SECUENCIA DEL CASO DE USO: Registrar

Conclusiones..............................................………………………………………………………13
ILUSTRACIÓN 5 DIAGRAMA DE SECUENCIA DEL CASO DE USO: Administrar Préstamos

Expedientes................................................………………………………………………………14
ILUSTRACIÓN 6 DIAGRAMA DE SECUENCIA DEL ESCENARIO DE USO: Ciclo de Vida de

una solicitud/caso...........................…….............…………………………………………………15

1. Definición
Para entender el contenido del presente anexo, se presenta a continuación una breve
explicación sobre diagramas de secuencias.
Un diagrama de secuencia muestra cómo el control pasa de un objeto a otro a medida que se
ejecuta el caso de uso y a medida que se envían mensajes entre objetos. Un mensaje enviando
por un objeto dispara la toma del control en el objeto receptor y la realización de las
operaciones de su clase.
2. Diagrama de secuencias
Debido a que son los dos casos de uso de SIMIP, donde se hace necesario mostrar la forma
como se pasa el control entre los diferentes objetos, a continuación se muestra los diagramas
de secuencias de:
• Definir Ruta y Plan de Actividades.
• Asignar Servidor/Equipo de Trabajo a Solicitud/Caso
• Marcar caso
• Registrar conclusiones
• Administrar expedientes
Por último, para ilustrar el ciclo de vida de una solicitud/caso en SIMIP, se muestra el
correspondiente diagrama de secuencia sobre el respectivo escenario de uso.
2.1 Diagrama de Secuencia del caso de uso: Definir Ruta y Plan de Actividades
Descripción Breve
Tiene como objetivo definir la ruta y el plan de acción a seguir en el desarrollo de un caso.
Definir Ruta: El servidor determina el camino a seguir (Marcar ruta), con base en una ruta
sugerida por el sistema siguiendo las consideraciones lógicas y legales correspondientes. Por
ejemplo, si el caso es disciplinario, debe indicar si se va por proceso ordinario o verbal y en
el primero, si se va por indagación preliminar o por investigación. Si es intervención, debe
indicar si es agente especial o agente ordinario. Si es preventivo, la determinación de la ruta
de las acciones que le permitirán comprobar los hechos. La validación de la ruta, en cuanto
validez de las actividades (precedencia, tipo de actividades por área, etc.) se hará teniendo en
cuenta las etapas y actividades registradas en el sistema mediante el caso de uso de SIAM de
Administrar etapas, actividades e información asociada.

Definir Plan de Acción: El servidor dice que es lo que va a hacer. El sistema le puede sugerir
algunas actividades, como en derechos humanos, en donde se cuenta para disciplinario con
un manual de pruebas por tipo de violación y para preventivo, con un instrumento guía.
Puede ser un plan general de acción o puede ser detallando una a una las actividades. El plan
también se puede rearmar a medida que transcurre el caso.
El Plan de Acción permitirá al servidor llevar un control ordenado de las actividades a
realizar y su propósito, igualmente, el Plan le permitirá al sistema, controlar los términos,
para el Caso, la etapa o la actividad, según el caso, generando al servidor las alertas
tempranas que se definan.
En este punto el sistema debe aportarle al servidor la siguiente información: Un banco de
plantillas, como herramientas, para que pueda generar los oficios y autos que requiera para
impulsar la actuación, los cuales deberán adjuntarse al registro para facilitar la consulta del
Caso sin tener que recurrir en todo momento al expediente físico.

Diagrama de Secuencia
: Etapa : Actividad
: Caso
/ Definir Ruta y Plan de
Actividades : Servidor
1 : [por cada actividad a definir en la

ruta] crearActividad ( )
2 : \new\
actividad
3 : tomarEtapas ( )
4 : [por cada actividad] \new\
etapas
5 : \selecciona de 'etapas' etapa a
administrar\
6 : [por cada etapa seleccionada]

ingresarEtapaEnRuta ( etapas_
seleccionadas )
Ilustración 1 Diagrama de Secuencia del Caso de Uso: Definir Ruta y Plan de

Actividades

2.2 Diagrama de Secuencia del caso de uso: Asignar Servidor/Equipo de Trabajo a

Solicitud/Caso
Descripción Breve
El presente caso de uso tiene como objetivo asignar a una solicitud -valorada como de
competencia de la PGN- o a un caso, el servidor o servidores (equipo de trabajo) que se
encargarán del mismo, es decir asignar el titular de la responsabilidad del trámite del caso.
Si se asignan servidores el sistema debe brindar la posibilidad de señalar sus roles, por
ejemplo, para el caso de las comisiones disciplinarias especiales, la presidencia y los
colaboradores.
El sistema debe prever la posibilidad de que un servidor, de la dependencia, también se
encuentre adscrito o se pueda adscribir, a un Comité o Comisión Institucional (dependencia
virtual) creada para atender determinados tipos de casos o problemáticas, en este evento,
también debe permitir asignarle el Caso con cargo a su mapa de carga laboral, en la cual debe
reflejarse, como caso a su cargo si le corresponde su trámite.
Existen dos formas para designar al servidor o servidores, automática y manual. En el primer
evento, es el sistema quien determina a qué servidor le corresponde el conocimiento del caso
(reparto), y en el segundo, es el responsable de la dependencia quien selecciona al servidor
(asignación directa), debiendo en todo caso, señalar el criterio utilizado, seleccionándolo de
una lista de criterios previamente definida en el sistema, por ejemplo, la complejidad del
caso, la connotación que éste pueda tener en la sociedad o en los organismos internacionales.
En el sistema SIMIP, con base en la información de carga de funcionarios, los cuales
provienen de la suma de los pesos a las solicitudes y casos que tiene un funcionario en el
momento de ejecutar el programa de reparto, el perfil del funcionario y la clasificación de la
solicitud, procede a hacer asignación, que en principio se hace de manera automática, pero se
puede configurar para hacer un reparto manual en caso de requerirse.
El sistema debe contar con opciones de manejo de situaciones administrativas que afectan la
carga laboral y mecanismos de equilibrio, tales como exclusión del reparto, cambio del valor
de carga laboral o reasignación de casos, que se podrán configurar de forma manual cuando
se requiera.
El programa de reparto se podrá hacer mediante mecanismos de asignación o reasignación
directa o aleatoria, según como se haya configurado, y los nuevos pesos asignados a los
funcionarios elegidos serán acumulados en sus respectivas cargas.

Ejemplo de Matriz de carga laboral:
# Casos asignados Vr. C. Lab.(Peso) # Casos evacuados # Casos Activos

Servidores
Pedro 5 5 3 2
Juan 5 6 2 3
José 4 8 2 2
Vale la pena aclarar que este caso de uso se puede llamar en varias oportunidades: cuando en
las dependencias se hace reparto a funcionarios, cuando en la División de Registro y Control
se hacer reparto a sustanciadotes y cuando se hace reparto de casos de segunda instancia.
procuraduría provincial, éste se podrá remitir directamente al competente o tramitarse ante la
División de Registro y Control, en los eventos en los que exista más de una delegada

/ Asignar Servidor/Equipo a : Caso : ActoresCaso : Usuario

Solicitud/Caso : Servidor
1 : asignarServidorEquipo ( )
2 : \new\
3 : tomarListaActoresCandidatos ( )
actores_candidatos
candidatos
4 : \escoger actores elegidos\
5 : insertarActor ( actoresElegidos )
6 : [por cada actor] \new\
Ilustración 2 Diagrama de Secuencia del Caso de Uso: Asignar Servidor/Equipo de Trabajo a

Solicitud/Caso

2.3 Diagrama de Secuencia del caso de uso: Marcar Cierre Caso
Descripción Breve
Este caso de uso tiene como objetivo cerrar el caso. Consiste en cambiar el estado del registro
en el sistema, indicando que el caso esta cerrado.
En algunos casos el sistema automáticamente puede cerrar el caso, para no tener que hacerlo
en forma manual. Por ejemplo, en disciplinario, si el servidor registra en el sistema la
decisión de archivar la actuación disciplinaria y ésta cobra ejecutoria, sin importar si es en
primera o segunda instancia, el sistema puede cerrar el caso. Lo mismo ocurre cuando con la
decisión de remitir la actuación a otra autoridad, aún cuando en este caso, no opera la
ejecutoria.
En el caso de uso Administrar Etapas, Actividades, Actuaciones e Información Relacionada
de SIAM, se incluirá un flag llamado Cierra Caso, el cual se colocará con valor positivo para
las actividades que impliquen el cierre del caso, de manera que la operación se pueda llevar a
cabo en forma automática.
Cuando se produce el cierre de un caso, el sistema debe reflejar la situación en el mapa de
carga laboral del servidor.

Marcar Cierre Caso : Servidor : Caso : Expediente
1 : marcarCierreCaso ( )
2 : descargarFuncionarios ( )
3 : fijarTiempoEnDependencia ( )
Ilustración 3 Diagrama de Secuencia del Caso de Uso: Marcar Cierre Caso

2.4 Diagrama de Secuencia del caso de uso: Registrar Conclusiones
Descripción Breve
El caso de uso Registrar Conclusiones tiene como objetivo permitir al servidor registrar las
conclusiones en el análisis del caso, una vez se haya emitido la decisión, concepto o informe
que pone fin a la actuación de la PGN Debe constar de una sección donde en forma resumida
el servidor registra las conclusiones del caso y debe tener la posibilidad de adjuntar
información adicional como anexo.
Esta sección de conclusiones puede incluir una plantilla en la que se pueden, por ejemplo,
manejar temas y subtemas, normatividad aplicada para la solución del caso y un breve
resumen de la solución del caso y las razones o fundamentos. Registro que además, puede
facilitar el trabajo de relatoría.
Registrar Conclusiones : Servidor : Caso : Conclusiones
1 : [por cada conclusion a registrar]

registrarConclusiones ( )
2 : \new\
3 : insertarConclusion ( )
Ilustración 4 Diagrama de Secuencia del Caso de Uso: Registrar Conclusiones

2.5 Diagrama de Secuencia del caso de uso: Administrar Préstamos Expedientes
Descripción Breve
Este caso de uso tiene como objetivo administrar el manejo de préstamo de

expedientes al interior de la PGN. Por cada préstamo que se realice, se debe registrar
como mínimo:
• Fecha de préstamo
• Término del préstamo. Si se pasa de este término, se debe generar una alerta.
• Que se presto (folios, tipo de documento, etc).
• Servidor a quien se prestó
• Dependencia
Administrar Prestamo de : Caso : Expediente : PrestamosExpedientes

Expedientes : Servidor
1 : tomarExpediente ( )
2 : ingresarPrestamo ( )
3 : \new\
Ilustración 5 Diagrama de Secuencia del Caso de Uso: Administrar Préstamos Expedientes

2.6 Diagrama de Secuencia del escenario de uso: Ciclo de vida de una solicitud/caso
Escenario de Uso Ciclo de Vida de

: Solicitud : Caso : ActoresCaso : Oficio : Siri
una SOLICITUD/CASO PGN : PGN
1 : \new\
2 : asignarCompetencia ( )
3 : evaluarSolicitud ( )
4 : [existe caso] acumularCaso ( )

5 : [existe solicitud] acumularSolicitud
( )
6 : asignarPrioridadPoliticas ( )
7 : [amerita abrir caso] abrirCaso ( )
8 : vincularASolicitud ( )
9 : gestionarActores ( )
10 : [por cada actor] insertarActor (

actores )
11 : definirRuta ( )
12 : [por cada etapa] ingresarEtapaEn

Ruta ( actividad )
13 : registrarConclusiones ( )
14 : [si hay sanciones a registrar]

ingresarSancion ( )
15 : [por cada oficio a generar]

generarOficios ( )
16 : marcarCierreCaso ( )
17 : [para cada funcionario del caso]

descargarFuncionarios ( )
Ilustración 6 Diagrama de Secuencia del Escenario de Uso: Ciclo de vida de una solicitud/Caso

ANEXO – GLOSARIO
Glosario (Versión Final) Pág. 1


10/05/2005 1.0 Versión Inicial tomado del C.Díaz
documento de Macroprocesos
Existentes y de las
Sugerencias de Jorge Eliécer
10/05/2005 1.0 Inclusión términos de sistemas C.Díaz
15/05/2005 1.0 Revisión con base en las C.Díaz
indicaciones de J.Eliécer
27/05/2005 2.0 Revisión con base en C.Díaz
observaciones de Martha Ligia
15/06/2005 3.0 Revisión términos técnicos C.Díaz
casos de uso
02/08/2005 4.0 Revisión Final C.Díaz
3/08/2005 4.0 Se agregaron los términos F.Martínez
correspondientes al Mapa de
los Sistemas de Información

TABLA DE CONTENIDO
Pág.
1. Términos relacionados con Procesos ................................................................................ 4
2. Términos relacionados con la PGN .................................................................................. 6
3. Términos relacionados con el área técnica en sistemas .................................................. 10
4. Términos relacionados con el Mapa de los Sistemas de Información ............................ 15

GLOSARIO
El glosario incluye y define todos los términos que facilitan la comunicación y entendimiento
de los documentos generados en las diferentes etapas del presente proyecto. Se ha dividido en
varias secciones para facilitar la agrupación de términos.
1. Términos relacionados con Procesos

Homologar: Equiparar, uniformar o poner en relación de igualdad dos cosas.
En este proyecto la homologación está orientada a la optimización de los procesos a partir de
la unificación para facilitar la sistematización. Se llevó a cabo como una de las fases del
trabajo realizadas para proponer mejoras a los macroprocesos existentes en la PGN.
ISO9001: La norma que se ha utilizado como base metodológica en el proyecto para la

descripción de los procesos de la PGN, es la ISO9001. Esta norma especifica los requisitos
para un sistema de gestión de calidad y mejoramiento continuo que puede utilizarse
internamente en la organización.
La norma ISO9001 promueve la adopción de un “enfoque basado en procesos” tendiente a
mejorar la eficacia de un sistema de gestión de calidad. Cabe agregar que la norma ISO fue
pensada inicialmente en términos de “empresa”, pero su utilidad se ha hecho evidente en la
esfera de la gestión pública, donde ha apoyado esfuerzos de modernización hacia la eficiencia
de las entidades públicas.
Proceso: Conjunto de actividades mutuamente interrelacionadas o que interactúan entre sí.

En el contexto del proyecto de la PGN el término “macroproceso” se refiere a un conjunto de
procesos de alto nivel asociados al cumplimiento de las funciones de la Procuraduría. Dichos
macroprocesos se han clasificado de acuerdo a niveles de detalle y sus descripciones más
precisas se describen a continuación:
• Macroproceso (procesos de nivel 1): Tienen que ver con las actividades a nivel
general necesarias para cumplir la misión de la Entidad. (Ejemplo: Gestionar
políticas, Coordinar y Controlar, Ejercer funciones misionales y Ejercer funciones
conexas).
• Proceso (procesos de nivel 2): Hacen relación en un nivel ulterior de detalle, a las
funciones asociadas a la PGN. (Ejemplo: Para el macroproceso de Ejercer Funciones
Misionales, los procesos están asociados a las áreas de intervención, prevención, y

disciplinario).
• Subproceso (procesos de nivel 3): Asociado a las etapas principales dentro de cada
proceso.
• Procedimiento (procesos de nivel 4): Pasos particulares asociados a los sub-

procesos.
En el documento de Procesos Optimizados, se definen los siguientes tipos de procesos:

• Común y obligatorio (COB): Son aquellos macroprocesos que cumplen la doble
condición de que se tienen que adelantar en todas las áreas misionales, pero además
siempre tienen que realizarse; es decir, son imperativos.
• Específico y obligatorio (EOB): Son aquellos macroprocesos que cumplen la doble
condición de que se adelantan exclusivamente en un área misional, pero además,
siempre tienen que realizarse; es decir, son imperativos.
• Común y opcional (COP): Son aquellos macroprocesos que cumplen la doble
condición de que existen en todas las áreas misionales, pero no siempre deben
presentarse y son de tipo condicional.
• Específico y opcional (EOP): Son aquellos macroprocesos que cumplen la doble
condición de que existen exclusivamente en un área misional, pero no siempre tienen
que realizarse; es decir, no son imperativos.
Salida: Dentro de la metodología ISO uno de los componentes de un proceso es la salida,

entendida como el resultado del proceso. Estos resultados o salidas de proceso son los
productos que se entregan a los clientes de acuerdo a ISO.
Vale la pena aclarar que para el caso de la Procuraduría, el término ¨cliente¨ se ha traducido
como ¨actor¨. Y el término producto está asociado con los resultados o actuaciones.
(Ejemplo: fallo disciplinario o el archivo de un expediente disciplinario, la intervención
consignada en un reporte, o el informe de la actuación preventiva).

2. Términos relacionados con la PGN
Abrir Caso: Es el subproceso por medio del cual la delegada, dependencia o funcionario
delegado, avoca el conocimiento de un asunto de su competencia y por tanto debe registrarlo
en el sistema.
Actores PGN: Son las diferentes personas o entidades que interactúan en los procesos
misionales de la PGN, como solicitantes de un servicio, el responsable de una actuación, o la
persona o entidad sobre la cual impacta una decisión. Ejemplo: los ciudadanos que presentan
solicitudes o quejas a la entidad, los servidores y/o dependencias de la PGN, las entidades
que se relacionan con la PGN, los investigados, entre otros.
Agente: Se utiliza para identificar a los servidores de la PGN que atienden solicitudes o
tramitan los casos en las tres áreas misionales de la entidad, en este sentido, puede ser un
procurador delegado, un asesor, un profesional o un procurador judicial, según la materia.
Agente especial: Se utiliza para identificar la asignación, nominación o distinción de un

servidor como Agente “Especial” del Ministerio Público en un determinado proceso judicial
o administrativo, bien sea por decisión propia de la PGN, por solicitud de parte de las
autoridades de conocimiento del proceso, por su importancia social, la naturaleza de los
hechos, la trascendencia nacional o internacional del asunto, su complejidad, o por la
prioridad que reviste el proceso para la PGN.
Área/Función Misional: Los mandatos constitucionales que definen las funciones de la PGN
tienen como fin último garantizar que los funcionarios públicos en el cumplimiento de sus
funciones se ajusten al derecho en sus actuaciones; que los procesos administrativos y
judiciales se desarrollen con el pleno de garantías para las partes; que la vigilancia preventiva
inhiba comportamientos que se aparten de la ley y promueva acciones para la mejor gestión
pública y por último, que las relaciones sociales se basen en el respeto de los derechos
humanos como marco de convivencia. Para el cumplimiento de estas funciones
constitucionales, la PGN ejerce 3 funciones misionales: disciplinaria, de intervención, y
preventiva.

Caso:
• Disciplinario: Comprende el asunto, comportamiento o conjunto de hechos o
conductas de uno o más servidores públicos o particulares sujetos de la acción
disciplinaria, que se investigan en el Proceso Disciplinario;
• Preventivo: Abarca el conjunto de actuaciones, diligencias o acciones preventivas de
la PGN, encaminadas a garantizar el cumplimiento de la norma, a solicitud de parte o
en forma oficiosa, en defensa de los derechos humanos, del orden jurídico, del
patrimonio público o de interés general, ante una o más autoridades;
• Intervención: Se integra por la agencia que ejerce la PGN como Ministerio Público,
en un determinado proceso judicial o administrativo cursante ante las autoridades
competentes y abarca el conjunto de actuaciones, diligencias, recursos o acciones
legales que puede adelantar el agente.
Cerrar caso: Es el subproceso por medio del cual el funcionario o la dependencia

competente, da por terminada toda acción asociada a un caso, el cual se produce cuando cesa
la acción de la PGN.
Decisión del Caso (Resultado / Salida):

• Disciplinario: Providencia que pone fin a la actuación disciplinaria en la PGN,
ordenando el archivo del proceso, remitiéndolo a otra autoridad por competencia, por
acumulación de varios procesos o dictando el fallo respectivo.
• Preventivo: Informe que da cuenta de la actuación preventiva de la PGN, su
diagnóstico de la situación y las acciones o recomendaciones, así como los logros
obtenidos en un determinado caso, asunto o temática.
• Intervención: Concepto, recurso, alegato, solicitud o acción final del Procurador
Judicial o servidor que interviene como Agente del Ministerio Público en un
determinado proceso judicial o administrativo, bien como agente ordinario o especial.
Entrada (de un proceso en la PGN): Está determinada por la solicitud, petición, memorial,
exhortación, notificación, comunicación o queja a través de la cual una persona natural o
jurídica, o una autoridad demanda un servicio o una actuación a la PGN, para que ésta inicie
o asuma una investigación disciplinaria, intervenga en un caso particular, ante determinada
autoridad judicial o administrativa como Ministerio Público, o adelante las acciones
preventivas necesarias, en defensa de los derechos fundamentales, del patrimonio público, el
orden jurídico o el interés general.
Al igual que la acción, diligencia o actuación oficiosa de la PGN en las mismas materias.

Establecer Marco Normativo: Consiste en establecer las normas, doctrina y jurisprudencia

bajo los cuales debe desarrollar sus actividades la PGN en un caso específico.
Evaluar Asunto: Se refiere a la valoración inicial de los hechos o conductas supuestamente

irregulares (conducta) y los responsables o autoridades señaladas en la solicitud (sujetos
responsables) con el fin de verificar la competencia, comprobar la existencia de antecedentes
sobre los mismos y determinar si amerita la apertura de un caso.
Expediente:
• En Disciplinario: Conjunto de actuaciones, pruebas y decisiones que conforman el
Proceso Disciplinario;
• En Preventivo: Conjunto de diligencias, actuaciones, documentos o informes que
conforman la acción preventiva de la PGN;
• En Intervención Judicial o Administrativa: Conjunto de actuaciones, solicitudes,
recursos, acciones, alegatos y conceptos de la PGN cuando actúa como Ministerio
Público en un proceso determinado que cursa ante las autoridades judiciales o
administrativas competentes.
Indicadores: Los indicadores son datos o señales sobre el funcionamiento, desempeño e

impacto de la PGN, estos datos, pueden convertirse, a partir de su análisis, en información,
que permite tomar decisiones.
Instrumento: Conjunto de herramientas que un servidor de la PGN puede aplicar o a las que
puede acudir, durante el manejo de un caso, o un actor dentro de un proceso. (Ejemplos:
acciones de tutela, actuaciones de oficio de la PGN relacionadas con la prórroga o
suspensión del proceso, suspensión del servidor investigado, comisiones, aplicación del poder
preferente/vigilancia superior, resolución de recursos del proceso y causales de inhabilidad o
recusación de las personas y los traslados por competencia.)
Macroproceso Misional: Se trata del conjunto de tareas, acciones, actividades que permiten
a la Procuraduría cumplir con las obligaciones prescritas por la Constitución.
Política: Es la formulación de propósitos, líneas de acción, planes, programas y proyectos,

que determinan la focalización de los recursos y los esfuerzos institucionales, con miras a la
consecución de un objetivo específico.
Radicar Asunto: Actividad que consiste en registrar, inscribir o ingresar al sistema de

información de la PGN, los datos pertinentes de una queja, oficio o comunicación a través de
la cual se demanda el servicio o actuación de la PGN en cualquiera de sus áreas misionales, o

del inicio de la actuación oficiosa emprendida por la PGN o derivada de la notificación ante
una autoridad judicial.
Solicitud: Hace referencia a todas las peticiones, requerimientos o pedidos que llegan a la
PGN respecto a los asuntos manejados por la entidad.
Valorar Solicitud: Este proceso consiste en evaluar la pertinencia para la PGN de tramitar
las solicitudes de servicio o actuación que llegan a la PGN. Estas pueden ser quejas,
solicitudes o peticiones de ciudadanos, memoriales de abogados o comunicaciones de las
autoridades. También pueden ser traslados por competencia, compulsa de copias o
notificaciones.
Verificar Hechos: Consiste en la constatación de los hechos relevantes en un caso por medio
de la observación directa, visitas, cuestionarios o testimonios, documentos, medios técnicos,
para verificar una conducta y/o comprobar el cumplimiento de los mandatos legales. Incluye
la práctica de pruebas de caso, para la afirmación o información de los hechos y la
responsabilidad de los sujetos procesales.

3. Términos relacionados con el área técnica en sistemas
Actor: Es una entidad externa del sistema que de alguna manera participa en la historia del
caso de uso. Por lo regular estimula el sistema con eventos de entrada o recibe algo de él. Los
actores están representados por el papel que desempeñan en el caso.
Administración de la información: conjunto de definiciones, normas, y técnicas para

almacenar, procesar y transmitir información.1
Administración del sistema de información: es el conjunto de herramientas que permiten

mantener un sistema de información en un estado de actualización vigente, en un nivel de uso
controlado, de acuerdo con políticas de actualización, seguridad y confidencialidad definidas
para el sistema.
Ambiente Hardware: Un Ambiente Hardware es una solución de hardware que apoya una ó
varias funciones de una empresa. Un Ambiente Hardware está conformado por equipos y/u
otros Ambientes Hardware.
Ambiente Software: Un Ambiente Software es una solución de software que apoya una ó
varias funciones de una empresa. Un Ambiente software está conformado por paquetes de
software y/o otros Ambientes Software.
Arquitectura: Conjunto de decisiones significativas acerca de la organización de un sistema

software, la selección de los elementos estructurales a partir de los cuales se compone el
sistema y las interfaces entre ellos. La arquitectura de software se interesa no sólo por la
estructura y el comportamiento, sino también por las restricciones y compromisos de uso,
funcionalidad, funcionamiento, flexibilidad al cambio, reutilización, comprensión, economía
y tecnología.
Artefacto UML: En UML un artefacto define cualquier componente que se puede colocar en
un diagrama UML (i.e un diagrama de actividad, una actividad, una transición, etc.).
Literalmente se define como: "Un pedazo de información que es usado o producido por un
proceso de desarrollo de software".
Canal de comunicación: medio para transmitir información entre entes de comunicación
1
Fuente: Diccionario enciclopédico de ciencia y tecnología. Prentice – Hall Hispanoamérica S.A.

separados en el espacio.2
Caso de Uso: Una descripción de un conjunto de secuencias de acciones, incluyendo

variaciones, que un sistema lleva a cabo y que produce un resultado de interés para un actor
determinado. Un caso de uso describe un proceso, un proceso de negocios por ejemplo.
Centro de Información: instalación cuyo propósito es almacenar, procesar y recuperar

información según las necesidades de los usuarios.3
Clase: Una descripción de un conjunto de objetos que comparten los mismos atributos,
operaciones, relaciones y semántica.
Componentes de hardware: es la mínima unidad de hardware que hace parte de un equipo,

hasta cuyo nivel de detalle se desea manejar como infraestructura.
Diagrama: La representación gráfica de un conjunto de elementos, usualmente representado

como un grafo conectado de vértices (elementos) y arcos (relaciones).
Diagramas de Actividad: Diagramas definidos por UML para modelar procesos de negocio
o para refinar casos de uso.
Diagrama de Casos de Uso: Explica gráficamente un conjunto de casos de uso de un

sistema, los actores y la relación entre éstos y los casos de uso. Estos últimos se muestran en
óvalos y los actores con figuras estilizadas. Hay líneas de comunicación entre los casos y los
actores; las flechas indican el flujo de la información o el estímulo. El diagrama tiene por
objeto ofrecer una clase de diagrama contextual que nos permite conocer rápidamente los
actores externos de un sistema y las formas básicas que lo utilizan.
Diagrama de Clases: Un diagrama de clases presenta las clases del sistema con sus
relaciones estructurales y de herencia. La definición de clase incluye definiciones para
atributos y operaciones. El modelo de casos de uso aporta información para establecer las
clases, objetos, atributos y operaciones.
Diagrama de Colaboración: Un diagrama de interacción que enfatiza la organización

estructural de los objetos que envían y reciben mensajes; un diagrama que muestra las
2
3

interacciones organizadas alrededor de instancias y de los enlaces entre ellas. (Utilizan un

formato de grafo o red).
Diagramas de Interacción: Explica gráficamente las interacciones existentes entre las

instancias (y las clases) del modelo de éstas. UML define dos tipos de estos diagramas:
diagramas de colaboración y diagramas de secuencia. Ambos sirven para expresar
interacciones.
Diagramas de Secuencia: Expresa interacciones entre instancias. (Utiliza un formato de

cerca o muro).
Equipo: es una unidad de hardware que hace parte de la infraestructura de información,

como un host, un switch de comunicaciones, un concentrador, un PC, etc. Un equipo puede
estar ó no conformado por otros equipos y puede tener ó no componentes.
Equipo Primario: es un equipo que no hace parte de ningún otro equipo por ejemplo un PC.
Equipo Secundario: es un equipo que hace parte de otro equipo por ejemplo un Controlador
de disco SCSI.
Evento: La especificación de una ocurrencia significativa que tiene una ubicación en el

tiempo y en el espacio; en el contexto de máquinas de estados, un evento es una ocurrencia
de un estímulo que puede disparar una transición de estados.
Flujos de Información: Conjunto de datos que fluyen entre un sistema y otro para garantizar
su operabilidad.
Flujo de Eventos – Flujo Básico: También llamado curso normal de eventos, es la parte
principal del formato de caso de uso expandido. Describe los detalles de la interacción entre
los actores y el sistema. Un aspecto esencial de la sección es que explica la secuencia más
común de los eventos: la historia normal de las actividades y la terminación exitosa de un
proceso.
Flujo de Eventos – Flujos Alternativos: También llamado curso alterno de eventos,

describe importantes opciones o excepciones que pueden presentarse en relación con el curso
normal. Si son muy complejas, se pueden expandir y convertir en nuevos casos de uso.

Formato de Caso de Uso de Alto Nivel: Un caso de uso de alto nivel describe un proceso
muy brevemente. Conviene servirse de este tipo de caso durante el examen inicial de los
requerimientos y del proyecto, a fin de entender rápidamente el grado de complejidad y de
funcionalidad del sistema.
Formato de Caso de Uso Expandido: Un caso de uso expandido describe un proceso más a
fondo que el de alto nivel. La diferencia básica consiste en que tiene una sección destinada al
curso normal de los eventos (flujo normal), que los describe paso a paso.
Función: Es una actividad global que hace parte de la operación de una Empresa, las cuales
se apoyan en infraestructuras de tecnologías de información ó son Funciones potencialmente
sistematizables.
Información: Conjunto de datos con sentido para quien la utiliza.
Informática: Es el tratamiento en forma automática de la información.
Instancia: Una manifestación concreta de una abstracción; una entidad sobre la que pueden
aplicarse un conjunto de operaciones y que tiene un estado que almacena los efectos de las
operaciones, es sinónimo de objeto.
Mapa de los Sistemas de Información: El mapa de sistemas es una representación gráfica

de un sistema de información que permite visualizar los componentes que lo conforman
y los principales flujos entre ellos.
Mensaje: Mecanismo en virtud del cual los objetos se comunican entre sí, generalmente una
respuesta para ejecutar un método.
Método: En el lenguaje UML, implementación o algoritmo específicos de la operación de

una clase. Informalmente, procedimiento de software que puede ejecutarse en respuesta a un
mensaje.
Modelo: Descripción de las características estáticas, dinámicas o ambas de un tema,

presentada en varias vistas (generalmente diagramáticos o textuales).
Objeto: Ver Instancia.

Paquete: Un mecanismo de propósito general para organizar elementos en grupos.
Postcondición: Una restricción que ha de ser cierta al completarse una operación.
Precondición: Una restricción que ha de ser cierta cuando una operación es invocada.
Productos y Servicios: Son las soluciones de tecnologías de información que se han

desarrollado, y que pueden ser usadas para apoyar las diferentes funciones de las Empresas.
Los productos y servicios están formados por componentes de software, hardware y
comunicaciones.
Requerimientos Funcionales: Un requerimiento es la necesidad que tiene un usuario para

resolver problemas o alcanzar un objetivo. Su importancia radica en que son pieza clave y
fundamental en el proceso de desarrollo de software.
Requerimientos no Funcionales: Requisito que especifica propiedades del sistema, como

restricciones del entorno o de implementación, rendimiento, dependencias de plataforma,
mantenibilidad, extensibilidad o fiabilidad.
Restricción: Limitación o condición que se impone a un elemento.
Servicios de TI: Son servicios ofrecidos por proveedores de Tecnologías de Información, los
cuales no involucran elementos tangibles de hardware, software o comunicaciones; se trata de
servicios como asesorías, capacitación, construcción de páginas WEB, entre otros.
Sistema de Información: Un conjunto u ordenación de elementos organizados para llevar a

cabo algún método, procedimiento o control mediante el procesamiento de información.
Soluciones Informáticas: Se refiere a los productos informáticos que ofrece un proveedor de

tecnologías de información, los cuales involucran elementos tangibles de hardware, software
o comunicaciones. Así por ejemplo, un software de nómina es una solución informática.
Tecnologías de información: Las tecnologías de información, como se les llama

comúnmente, se refieren a todo lo relacionado con la captura, transportación, proceso, uso y
presentación de la información (digital, audio y video); es decir, todo lo que involucra

equipos de cómputo (hardware), programas de cómputo de infraestructura y aplicativos

(software) y las telecomunicaciones.4
Términos de Referencia: Documento que contiene las condiciones y requerimientos

necesarios para una contratación.
UML (Unified Modelling Lenguaje): Lenguaje estándar, que mediante el uso de diagramas
definidos permite modelar procesos de negocio, requerimientos, arquitectura y diseño de
sistemas de software.
Usuario: Humano que interactúa con el sistema.
4. Términos relacionados con el Mapa de los Sistemas de

Información
SIAF. Sigla usada para referirse al Sistema Administrativo y Financiero de la PGN.

Corresponde al software existente en la PGN en el momento del desarrollo del sistema SIM.
SIAM. Sigla usada para el subsistema de apoyo cuyo objetivo principal es facilitar la
administración de los recursos disponibles para adelantar la función misional. Los recursos se
refieren a todos los elementos necesarios para la atención de las solicitudes y la ejecución de
los casos en la PGN, tales como recursos humanos, recursos físicos, plantillas de
documentos, etc.
SIC. Sigla usada para el subsistema cuyo propósito es mantener un contacto apropiado con la
ciudadanía a fin de facilitar el registro de solicitudes por parte de los ciudadanos y la
retroalimentación a estos sobre las actuaciones y estado general de los casos en la PGN,
restringiendo los datos al carácter del ciudadano (quejoso, disciplinado, ciudadano del
común, etc.) y al estado de los procesos.
SIMIP. Sigla usada para el subsistema central de la PGN. Este subsistema tiene como
propósitos fundamentales coadyuvar la labor funcional de la entidad, permitiendo: registrar y
controlar las acciones o actuaciones de la PGN en las áreas preventiva, disciplinaria e
intervención judicial o administrativa, velar por el “debido proceso”, minimizar la carga
operativa y facilitar la unificación de criterios en las funciones misionales de la PGN.
SIREL. Sigla usada para el subsistema encargado de apoyar la labor de relatoría de la PGN.
4
Fuente: Tecnologías de la información a la estrategia del negocio. TI Magazin.net. Nelson Roca. Abril del 2000

SIRI. Sigla usada para el sistema de información de registro de sanciones y causas de

inhabilidad, actualmente en uso en la PGN que permite llevar un registro ordenado de
sanciones e inhabilidades, expedir certificado de antecedentes en condiciones de seguridad, y
generar reportes gerenciales en donde se registran los antecedentes disciplinarios y penales.

Requ Fun PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Requ Fun PDF

Cargado por

Copyright:

Formatos disponibles

CIFI-INFORMATICA – PROCURADURIA GENERAL DE LA NACION

Fecha Versión Descripción Autor

Requerimientos Detallados -Funcionales- (Documento Final) Pág. 2

CAPÍTULO 2 - OBJETIVOS Y ALCANCE ..................................................................................... 7

CAPÍTULO 3 – REQUERIMIENTOS FUNCIONALES................................................................. 10

CAPÍTULO 4 – ESPECIFICACIONES SUPLEMENTARIAS...................................................... 13

Requerimientos Detallados -Funcionales- (Documento Final) Pág. 3

ANEXO 1 - CASOS DE USO SIC..……………………………………………...A1-1

ANEXO 3 - CASOS DE USO SIMIP ..…………………………………………..A3-1

ANEXO 4 - CASOS DE USO SIREL …………………………………….……..A4-1

ANEXO 5 – DIAGRAMAS DE SECUENCIA…………………………………..A5-1

Requerimientos Detallados -Funcionales- (Documento Final) Pág. 4

El contrato 066 de 2004 suscrito entre la Procuraduría General de la Nación y la

SIC: Subsistema de Información a la Ciudadanía

SIAM: Subsistema de Apoyo a la Misión

SIMIP: Subsistema de Procesos de la PGN

SIREL: Subsistema de Legislación y Relatoría

En el capítulo 2, se presentan los objetivos y alcance del documento. En el capítulo 3,

En los Anexos 1 a 4 del documento se presentan las especificaciones generales de los

Requerimientos Detallados -Funcionales- (Documento Final) Pág. 5

Requerimientos Detallados -Funcionales- (Documento Final) Pág. 6

En este capítulo se presentan los objetivos y el alcance de los requerimientos

En la Etapa 7 se hace el ajuste y refinamiento de los requerimientos identificados en

En la Etapa 4 del proyecto se identificaron los requerimientos de alto nivel

ANEXO 1- CASOS DE USO SIC: Subsistema de Información a la

ANEXO 2- CASOS DE USO SIAM Subsistema de Apoyo a la Misión

ANEXO 3- CASOS DE USO SIMIP: Subsistema de Procesos de la PGN

Requerimientos Detallados -Funcionales- (Documento Final) Pág. 7

ANEXO 4- CASOS DE USO SIREL: Subsistema de Legislación y Relatoría

El contenido de la descripción de los casos de uso que se encuentran en los Anexos 1

Adicionalmente, como complemento a los casos de uso, en el Anexo 5 se presentan

1) “Asignar Servidor/Equipo de Trabajo a Solicitud/Caso” y

2) “Definir Ruta y Plan de Actividades”

En el capítulo 4 de este documento se encuentra la enumeración de las

Requerimientos Detallados -Funcionales- (Documento Final) Pág. 8

Como producto de la etapa 7 del proyecto también se entregan dos documentos

1) “Requerimientos No Funcionales del Sistema de Información Misional para la

Requerimientos Detallados -Funcionales- (Documento Final) Pág. 9

En los cuadros siguientes se relaciona la lista de requerimientos (nombre de los casos

3.1 SIC: Subsistema de Información a la Ciudadanía (Anexo 1)

SIC1 Registrar Solicitudes SIC

3.2 SIAM: Subsistema de Apoyo a la Misión (Anexo 2)

SIAM1 Mantener Banco de Plantillas SIAM

Requerimientos Detallados -Funcionales- (Documento Final) Pág. 10

SIAM7 Administrar Competencias de las Dependencias SIAM

3.3 SIMIP: Subsistema de Procesos de la PGN (Anexo 3)

SIMIP1 Asignar competencia (Dependencia) SIMIP

Requerimientos Detallados -Funcionales- (Documento Final) Pág. 11

SIMIP25 Manejar ubicación del archivo en la dependencia SIMIP

3.4 SIREL: Subsistema de Legislación y Relatoría (Anexo 4)

SIREL1 AdministrarTemas SIREL

Requerimientos Detallados -Funcionales- (Documento Final) Pág. 12

Las especificaciones suplementarias corresponden a requerimientos funcionales del

Estos requerimientos funcionales adicionales deberán ser ampliados y detallados

4.1 Tipos de Información que debe generar el SIM

En este capítulo se han dividido las especificaciones suplementarias en:

Requerimientos Detallados -Funcionales- (Documento Final) Pág. 13

4.1.1 Consultas de Información:

9 El sistema deberá ofrecer a todos los usuarios, la posibilidad de consultar

4.2 Identificación de Información que debe generar el SIM

Requerimientos Detallados -Funcionales- (Documento Final) Pág. 14

- Mantener banco plantilla - Consulta

- Consultar Información WEB - Solicitudes