Sistemas De

Información

Cali – Valle Del Cauca

 Historial De Versiones
Versión Fecha Descripción Autor Cargo
Marisol
Veloza
1.0 20/04/2018 Versión inicial.

2
 Tabla de contenido

Historial De Versiones .............................................................................................................................. 2

Tabla de contenido .................................................................................................................................... 3
Objetivo ..................................................................................................................................................... 6
1. Definición Estratégica de los Sistemas de Información - LI.SIS.01 .............................................. 7
1.1 Vista de primer nivel de los sistemas de información de la arquitectura actual. .......................... 11
1.2 Vistas de segundo nivel de los sistemas de información en la arquitectura actual. ...................... 14
1.2.1 Arquitectura cliente / servidor del sistema R/3 ....................................................................... 14
1.2.2 Principios de sistema abierto incluidos en el sistema R/3. ...................................................... 14
1.2.3 Sistema operativos compatibles con el sistema R/3 ................................................................ 15
1.2.4 Bases de datos compatibles con el sistema R/3 ....................................................................... 15
1.2.5 Compatibilidad entre la presentaciones del tipo front-end ...................................................... 15
1.2.6 Modulo PS-Project .................................................................................................................. 16
1.2.7 Modulo SAP ABAP ................................................................................................................ 16
1.2.8 Modulo Aplicaciones .............................................................................................................. 17
1.2.9 Modulo SAP FI ....................................................................................................................... 17
1.2.10 Modulo SAP Logística .......................................................................................................... 18
1.2.11 Modulo SAP Recursos Humanos .......................................................................................... 19
1.3 Inventario de interfaces o servicios en la arquitectura actual. ...................................................... 20
1.4 Diagrama de interoperabilidad con otras entidades para sistemas de información en la
arquitectura actual. .............................................................................................................................. 20
1.5 Portafolio de proyectos de gestión de Sistemas de Información .................................................. 20
2. Catalogo de Sistemas de Información - LI.SIS.02 ....................................................................... 22
2.1 Directorio de Sistemas de Información y Servicios ...................................................................... 22
2.2 Directorio detallado de sistemas de Información y Servicios ....................................................... 23
3. Arquitecturas de Referencia de Sistemas de Información - LI.SIS.03 ........................................ 29
4. Arquitecturas de solución de sistemas de información - LI.SIS.04 ............................................. 31
5. Metodología de referencia para el desarrollo de sistemas de información - LI.SIS.05 ............... 34
5.1 Procesos Primarios ........................................................................................................................ 35
5.1.1 Procesos de adquisición........................................................................................................... 35
5.1.2 Proceso de suministro .............................................................................................................. 35
5.1.3 Proceso de desarrollo............................................................................................................... 36
5.1.4 Proceso de operación ............................................................................................................... 37
5.1.5 Proceso de mantenimiento....................................................................................................... 38
5.2 Procesos de Soporte ...................................................................................................................... 38
5.2.1 Proceso de documentación ...................................................................................................... 39
3
 5.2.2 Proceso de gestión de la configuración ................................................................................... 39
5.2.3 Proceso de control de calidad .................................................................................................. 40
5.2.4 Proceso de verificación ........................................................................................................... 40
5.2.5 Proceso de validación .............................................................................................................. 41
5.2.6 Proceso de revisión conjunta ................................................................................................... 41
5.2.7 Proceso de auditoría ................................................................................................................ 41
5.2.8 Proceso de resolución de problemas ....................................................................................... 42
5.3 Los Procesos de Organización ...................................................................................................... 42
5.3.1 Proceso de gestión ................................................................................................................... 42
5.3.2 Proceso de infraestructura ....................................................................................................... 43
5.3.3 Proceso de progreso................................................................................................................. 43
5.3.4 Proceso de capacitación........................................................................................................... 43
5.4 Aporte de la Norma ISO/IEC 15504 ............................................................................................. 44
6. Derechos Patrimoniales Sobre los Sistemas de Información - LI.SIS.06. ................................... 45
6.1 Políticas .................................................................................................................................... 46
7. Guía de estilo y usabilidad - LI.SIS.07 ........................................................................................ 49
7.1 Directrices ..................................................................................................................................... 49
7.1.1. Directrices de Arquitectura de Información ........................................................................... 50
7.1.2. Directrices de Interfaz de usuario ........................................................................................... 51
7.1.3. Directrices de Diseño de Interacción...................................................................................... 51
7.1.4 Motor de búsqueda y ubicación............................................................................................... 52
7.1.5 Pruebas de Usabilidad ............................................................................................................. 52
8. Apertura de datos - LI.SIS.08 ...................................................................................................... 53
9. Interoperabilidad - LI.SIS.09 ....................................................................................................... 54
10. Implementación de Componentes de información - LI.SIS.10 .................................................... 58
11. Ambientes independientes en el ciclo de vida de los sistemas de información - LI.SIS.11 ........ 61
12. Análisis de requerimientos de los sistemas de información - LI.SIS.12...................................... 63
13. Integración continua durante el ciclo de vida de los sistemas de información - LI.SIS.13 ......... 68
14. Plan de pruebas durante el ciclo de vida de los sistemas de información - LI.SIS.14 ................. 70
15. Plan de capacitación y entrenamiento para los sistemas de información - LI.SIS.15.................. 72
15.1 Objetivo ....................................................................................................................................... 72
15.2 Metas de Aprendizaje.................................................................................................................. 73
15.3 Competencias .............................................................................................................................. 73
15.4 Control de Asistencia .................................................................................................................. 73
16. Manual del usuario, técnico y de operación de los sistemas de información - LI.SIS.16 ........... 74
16.1 Manual de usuario ....................................................................................................................... 74
16.2 Manual técnico ............................................................................................................................ 74
17. Gestión de cambios de los sistemas de información - LI.SIS.17. ................................................ 76
18. Estrategia de mantenimiento de los sistemas de información - LI.SIS.18. .................................. 78
19. Servicios de mantenimiento de sistemas de información con terceras partes - LI.SIS.19 ........... 79
20. Plan de calidad de los sistemas de información - LI.SIS.20 ........................................................ 81
4
 20.1 ISO 25000 ................................................................................................................................... 81
20.1.1 ISO/IEC 2500n – División de Gestión de Calidad ................................................................ 82
20.1.2 ISO/IEC 2501n – División de Modelo de Calidad ................................................................ 82
20.1.3 ISO/IEC 2502n – División de Medición de Calidad ............................................................. 85
20.1.4 ISO/IEC 2503n – División de Requisitos de Calidad ........................................................... 86
20.1.5 ISO/IEC 2504n – División de Evaluación de Calidad .......................................................... 87
21. Criterios no funcionales y de calidad de los sistemas de información - LI.SIS.21 ...................... 88
22. Seguridad y privacidad de los sistemas de información - LI.SIS.22 ........................................... 90
22.1 Creación y movimiento de usuarios ............................................................................................ 91
22.2 Solicitud de Transporte ............................................................................................................... 92
22.3 Desbloqueo o Cambio de Claves ................................................................................................ 93
22.3 Modificación de roles.................................................................................................................. 95
23. Auditoría y trazabilidad de los sistemas de información - LI.SIS.23. ......................................... 97
24. Accesibilidad - LI.SIS.24 ............................................................................................................. 99

5
Objetivo
Consolidar la documentación que permite definir el diseño de los sistemas de
información, de tal manera que se puedan formalizar los esquemas usados para
planear, diseñar la arquitectura, el ciclo de vida, las aplicaciones, los soportes y la gestión
de los sistemas de información que apoyan, y habilitan, el cumplimiento de las funciones
de La Gobernación del Valle del Cauca.

El marco de referencia de arquitectura empresarial con respecto a los sistemas de

información ha contemplado como premisa el poder lograr que los sistemas de
información de la Gobernación del Valle del Cauca, en un futuro cercano puedan estar
conectados, articulados, y cumplan estándares y adopten las mejores prácticas en cuanto
a su desarrollo y al manejo de la información.

Con el propósito de cumplir con el MIPG, pero adicionalmente el plasmar las mejores
practicas, la Secretaria de las Tecnologías de la Información y las comunicaciones
definen mediante el proceso M11-P2 la Gestión de sus sistemas de información.

Código y Nombre del Macroproceso: M11 Gestionar Soluciones TI

Código y Nombre del Proceso: M11P2 Gestionar los sistemas de Información.

Tipo de proceso: Estratégico, Táctico y misional

Los principales objetivos que se plantean son:

El Definir y evolucionar las Arquitecturas de Referencia y de Solución de los Sistemas de

Información, teniendo en cuenta los principios de estandarización, racionalización y
generación de valor y adaptabilidad.

Uno de los propósitos continuos es poder realizar las mejoras evolutivas pertinentes, que
permitan alinear el proceso M11P2 para dar cobertura al ciclo de vida de los Sistemas de
Información.
1. Definición Estratégica de los Sistemas de
Información - LI.SIS.01

La definición estratégica de los sistemas de información se gestan en el año 2007, a partir de un

convenio de cooperación científica y tecnológica con el Ministerio de Hacienda, Crédito Público y
la Gobernación del Valle del Valle del Cauca, cuyo objetivo fue implementar los módulos de
presupuesto , cuentas por pagar tesorería, contabilidad, compras, activos fijos, crédito público e
inversiones.

En Marzo del 2008 y gracias a un trabajo conjunto entre la Secretaria de Hacienda y la Secretaria
de Telemática (predecesora de la Secretaria de Tecnologías de la Información y las
Comunicaciones), se afrontó exitosamente el reto de implementar un sistema de información de
clase mundial para soportar su operación administrativa de manera efectiva, y fue así como se logro
la salida en producción del sistema de información misional SAP.

El Sistema de Información misional SAP tuvo como premisa en su implementación, el poder

gestionar de la mejor manera las finanzas públicas del Departamento. De esta manera se logro la
interacción de todas las dependencias de la gobernación en los procesos y procedimientos
administrativos y financieros, y la automatización de esos procesos.

Posteriormente y de acuerdo con los establecido por el decreto departamental 1597 de 2016, se
estableció que se encuentran dentro de las responsabilidades del Secretario Departamental de las
Tecnologías de la Información y las Comunicaciones:

 Liderar ante las demás dependencias de la administración departamental el diseño y la

puesta en marcha de los sistemas de información, estableciendo los estándares de equipos,
software, hardware e infraestructura en todas las dependencias de la administración
departamental, para garantizar la seguridad informática y la confiabilidad de la información
y las comunicaciones.

Es en razón de lo anterior, una de las responsabilidades que debe asumir la Secretaria de las TIC de
la Gobernación del Valle del Cauca, es trabajar para que los Sistemas de Información
complementarios al sistema de finanzas públicas del Departamento, cumplan con una orientación
estratégica.

Uno de los objetivos de la Secretaria Departamental de las Tecnologías de la Información y las

Comunicaciones es el formalizar una arquitectura tecnológica de los sistemas de información,
acorde con los parámetros dados por el Ministerio de las Tecnologías de Información y las
Comunicaciones, incluyendo estándares de interoperabilidad, de privacidad, de seguridad y de
construcción o parametrización de aplicaciones.

7
La Definición estratégica de los Sistemas de información en la Gobernación del Valle incluye entre
sus etapas:

 Identificar

 Diseñar

 Desarrollar

 Construir

 Instalar

 Administrar

 Configurar

 Parametrizar

 Mantener

 Poner en marcha los sistemas de información y servicios digitales a nivel:

 Estratégico
 Operativo
 Misional

En la Gobernación del Valle del Cauca, esta labor se realiza cumpliendo con los estándares
tecnológicos de calidad (como por ejemplo la ISO 25000) para satisfacer las necesidades de los
usuarios de cada uno de los aplicativos utilizados por las dependencias.

En la Gobernación del Valle del Cauca sus sistemas de información corresponden a las siguientes
categorías:

 Sistemas misionales.

o Sistema de Gestión de Finanzas Publicas SAP

o Sistema de Administración de rentas - SAR
o Sistema de Gestión y Control de Impuestos de Vehículos - AIREPLUS
o Operaciones financieras entidades descentralizadas - SIAFXXI

 Sistemas de apoyo.

o Sistemas de mesas de ayuda Aranda - SAP

o Sistema de Gestión Social Integral - SIGESI que introduce nuevas tecnologías e
8
 innovación para el diseño, implementación, seguimiento y control de las políticas
públicas del departamento en el marco de la ordenanza 330 de 2011.
o Sistemas de Administración documental SADE y ZDOCUM
o Sistema de Administración de personerías jurídicas - PERJURI

 Portales.
o Portal informativo.
o Portales de ciudadanos.
o Pasaportes.
o Sistema web de contacto, peticiones, quejas, reclamos y denuncias (PQRD).
o Sistema VUR - Ventanilla Única de Registro.
o Portales de tramites (implementado parcialmente con el sistema de consulta de
proveedores y contratistas).
o Portal de Funcionarios (implementado parcialmente con el sistema de tabulados de
nomina).

 Sistemas de direccionamiento (en procesos de planeación bajo el sistema MIPG).

Estas labores son apoyadas por actividades como son el soporte técnico de la mesa de ayuda y las
necesidades de la comunidad en general, teniendo como objetivo final el permitir consolidar al
Valle del Cauca como un territorio inteligente e innovador.

Con respecto a las Políticas de Operación de los Sistemas de Información, se definido que:

Toda actividad relacionada con la adquisición, alquiler, renovación, actualización, integración,

mantenimiento, operación, promoción, apropiación, desarrollo o innovación de hardware, software
y todo lo relacionado con las tecnologías de la información y las comunicaciones debe de tener un
acompañamiento técnico y profesional con avales y conceptos técnicos de la secretaria de las
Tecnologías de la Información y las Comunicaciones con el propósito de garantizar la integridad,
de los datos, el soporte y seguridad de la información, como también de la coherencia y
compatibilidad de los aplicativos, software, hardware y contenidos que hoy operan en el
Departamento del Valle del Cauca.

Dentro de la estructura de la Secretaria definida por el decreto 1138 de 2016, se definió un

programa que tiene como responsabilidad la gestión de soluciones de TI en su ámbito interno. Este
programa ha sido estructurada, bajo dos grupos de trabajo así:

 Grupo de servicios tecnológicos

 Grupo de sistemas de información

Corresponde al segundo grupo la tarea de comenzar a fortalecer el cumplimiento de los sistemas de

información con los lineamientos dados en la estrategia nacional de Gobierno Digital.

9
De acuerdo con la estructura de la secretaria según del decreto departamental 1138 de agosto de
2016, mediante el cual se adopta la estructura de la administración central del departamento del
Valle de Cauca, se definen las funciones de sus dependencias y se dictan otras disposiciones ha
quedado establecido:

En el Capítulo II se plantea el modelo de la organización y gestión de la administración publica

departamental.

Dentro del capítulo 156 se establece que corresponde dentro del programa Gestión de Soluciones de
TI, al "Grupo Sistemas de Información, velar por el cumplimiento de los lineamientos previstos en
el presente documento"

Con respecto al equipo de trabajo hay tres grupos de actores principales:

 Grupo de desarrollo

 Mesa de Ayuda

 Consultoría externa

10
1.1 Vista de primer nivel de los sistemas de información de la
arquitectura actual.
La Secretaria de las TIC de la Gobernación del Valle del Cauca, asume como arquitectura de
referencia un diseño de alto nivel, sin detalles tecnológicos o de productos Este diseño de alto nivel
se utiliza como una plantilla para guiar el bosquejo de otras arquitecturas más específicas.

La arquitectura se alinea estrechamente con la arquitectura de su sistema de información misional

soportado en el ambiente SAP R/3

El sistema R/3 de SAP está basado en una arquitectura cliente-servidor, lo que significa que hay
una distribución de las tareas que debe realizar el sistema.

Esta arquitectura que se encuentra dividida en niveles o 3 capas, cada una de estas capas o niveles
tienes unas características determinadas y se encarga de proporcionar ciertos servicios.

Estas capas proporciona servicios a la capa inmediatamente superior (cliente) y solicita servicios a
la capa inferior (servidor).

 Nivel de presentación o capa de presentación. Esta capa proporciona los servicios de

11
 presentación para la implementación de SAP GUI, hace de interfaz entre el usuario y el
sistema. La capa de presentación envía información del usuario al sistema y muestra al
usuario la respuesta del sistema, es el punto de conexión con el usuario a través de un
gadget tecnológico. En esta primera capa o nivel los sistemas y componentes que tienen
como misión garantizar la interacción con el usuario final, por este motivo son procesos que
tienen una interfaz gráfica visual, donde todo debe quedar muy claro para facilitar los
procesos. Las características de esta capa incluyen:
o Agregado de nuevos equipos en cualquiera de sus 3 niveles para acomodarse a los
requerimientos dinámicos del sistema.
o Portabilidad a través de distintos tipos de hardware y sistemas operativos.
o Almacenamiento de todos los datos del sistema en tablas accesibles sin necesidad de
instrucciones complejas de recuperación de datos.

 Nivel de aplicación o capa de aplicación. En esta capa es donde más se interactúa como
desarrollador porque es la capa donde está el código ABAP y funciona como controladora
entre la capa de presentación y la capa de base de datos. Es donde se realiza la gestión de las
aplicaciones, siendo sistemas completos que se han configurado de una manera específica
para rendir a un alto nivel. Se caracteriza por tener un alto volumen de memoria RAM, por
lo tanto dispone de mayor potencia. Esta potencia que dispone está destinada en su mayor
parte a que se ocupe de la gestión y el funcionamiento de las distintas aplicaciones que
funcionan dentro del entorno SAP. Esta capa también se encarga de gestionar el reparto de
trabajo y tareas para que un proyecto pueda llevarse a cabo de manera eficiente. Reparte las
tareas y los encargos de forma adecuada a fin de que el sistema funcione correctamente. El
nivel de aplicación el que se encarga de la interacción con los otros niveles. El nivel de
aplicación es donde se encuentran los componentes técnicos enfocados a la memoria y al
rendimiento del sistema, además sirve de comunicación entre los otros 2 niveles.

 Nivel de base de datos o capa base de datos. En este nivel llamado base de datos es el que se
encuentra vinculado con los discos duros. Proporciona servicios de base de datos para el
almacenamiento y recuperación de los datos. En este nivel se encuentran componentes de
gran tamaño y velocidad que deben actuar con gran precisión para obtener un rendimiento
óptimo del sistema. Es donde se encuentra almacenados todos los datos que sirven de apoyo
a todos los procesos de los que depende SAP. Es donde encontramos todos los datos del
servidor, incluso los programas ABAP.

El usuario final interactúa en la Capa de Presentación a través de un terminal que tiene instalado
SAP GUI. Esta capa captura todos los datos introducidos por el usuario (input) en los campos de
texto o las teclas pulsadas y los trasladados a la Capa de Aplicación para poder ser procesados.

En la Capa de Aplicación se reciben los datos y se ejecutan los módulos y sentencias de código
ABAP que están definidas.

En el caso que necesitemos buscar, insertar o modificar datos en las tablas de la base de datos se
ejecuta la comunicación con la Capa base de datos y obtenemos el output otra vez en la capa de
presentación.

12
Esta combinación de los 3 niveles o capas explicados y su comunicación es lo que hace que SAP
disponga de una arquitectura equilibrada, ajustada y con un rendimiento óptimo.

La visión grafica de la arquitectura utilizada en los sistemas de la Gobernación del Valle Cliente
–Servidor es:

13
1.2 Vistas de segundo nivel de los sistemas de información en la
arquitectura actual.

1.2.1 Arquitectura cliente / servidor del sistema R/3

El sistema R/3 opera utilizando el principio cliente / servidor aplicado a varios niveles. Es altamente
modular y se aplica fundamentalmente por medio del software, de forma que los modos de iteración
entre los diversos clientes y servidores puedan ser controlados.

SAP basa la arquitectura de R/3 en una estructura cliente/servidor de tres niveles:

Nivel de presentación (GUI)

Nivel de aplicación

Nivel de Base de Datos

1.2.2 Principios de sistema abierto incluidos en el sistema R/3.

Normas internacionales para interfaz abierta

Las normas para las comunicaciones externas adoptadas en la gobernación son:

TCP/IP. (Transmission Control Protocol/Internet Protocol). Protocolo de comunicaciones en red que

hace posibles servicios Telnet, FTP, E-mail, y otros.

RPC. Incluido en ABAP/4 como RFC (Remote Function Call) Constituye la interfaz de programación
abierta de R/3, permitiendo que otros sistemas se conecten con las funciones de R/3.

CPI-C. Common Programming Interface-Communication). Utilizado para las comunicaciones

programa-a-programa a través de sistemas múltiples.

SQL. Structured Query Language. Como lenguaje de programación estándar e interactivo para la
obtención de información desde una base de datos y para actualizarla. Las consultas toman la forma de
un lenguaje de comandos que permite seleccionar, insertar, actualizar, averiguar la ubicación de los
datos, y más. También incluye una interfaz de programación.
14
ODBC. Open Data Base Connectivity. Son las normas utilizadas para el acceso abierto de los datos a
los datos comerciales de R/3 en las bases de datos relaciónales.

OLE/DDE. Object Linking and Embedding. Es el estándar principal para integrar las aplicaciones de
las PC´s con el sistema R/3.

X.400/X.500, MAPI. Messaging Application Programming Interface y EDI

(Electronic Data Interchange) También están establecidas interfaces abiertas para proporcionar acceso
a las aplicaciones especializadas como: CAD (Computer-Aided Design), archivos ópticos, subsistemas
técnicos relacionados con la producción.

1.2.3 Sistema operativos compatibles con el sistema R/3

Los sistemas operativos compatibles y usados por la Gobernación del Valle del Cauca incluyen:

 UNIX.
 Open VMS.
 MPE/iX.
 Windows NT

1.2.4 Bases de datos compatibles con el sistema R/3

Las bases de datos soportadas incluyen:

 Informix
 Oracle
 Software AG
 Sybase

En la gobernación del Valle del Cauca su Sistema de Información Misional se soporta sobre la Base de
Datos Oracle.

1.2.5 Compatibilidad entre la presentaciones del tipo front-end

SAP-GUI (Interfaz gráfica de usuario) es capaz de mostrar los resultados en forma de lista o gráfico en
la mayoría de los sistemas de presentación front-end, incluidos los siguientes:

 SAP GUI para el entorno Windows

 SAP GUI para Java (TM) ambiente de trabajo
15
  MotifOS
 2PMMacintosh

1.2.6 Modulo PS-Project

El módulo PS-Project System también es conocido como Sistema de proyectos.

Es un modulo diseñado para la gestión de proyectos de manera intuitiva, de largo alcance y

completamente integrada con el resto de áreas funcionales de un sistema SAP. Este modulo tiene
diversos componentes/elementos así:

 Elemento PEP: Define tareas y asigna recursos a dichas tareas. A cada tarea vienen asociadas
costes y horas de trabajo dedicadas, de aquí el interés y la importancia de que los elementos
PEP estén asociados con los módulos de Controlling, Finanzas y Planificación de la
Producción.

 Centro de trabajo: Define las dependencias o instalaciones – Plantas u Oficinas, por ejemplo –
asociados a los Elementos PEP y las tareas asociadas a estos últimos.

 Trazabilidad de Costes a través de Elementos PEP: Estos costes pueden estar relacionados con
tiempos de trabajo dedicados a una fase del proyecto – es importante destacar que dicha fase se
trataría como un elemento PEP – o con materiales y/o servicios procurados en dicha fase de
proyecto.

 Trazabilidad de Hitos de Proyecto: Se realiza en base a “Fechas Clave” definidas en el

proyecto – estas fechas clave también pueden estar asociadas a una fase de proyecto, que a su
vez, como hemos comentado, serían tratadas como Elementos PEP.

1.2.7 Modulo SAP ABAP

La Gobernación del Valle del Cauca cuenta con el módulo De SAP ABAP en castellano

ABAP Significa (Advanced Business Application Programming ), ABAP también conocido como SAP
ABAP. Este es el lenguaje de programación propiedad del Sistema SAP, que se utiliza para programar
en la mayoría de los productos.

El objetivo de SAP ABAP es crear nuevas transacciones que no existen en el estándar de SAP, pero
también sirve para ampliar transacciones que ya existen en el estándar cuando la funcionalidad que
proveen es insuficiente para la entidad.

Entre las características encontramos:

16
  Lenguaje orientado a eventos bien definidos.

 Interpretado, no compilado.

 Se utiliza tanto en programación de informes como en programación de diálogo para SAP.

 Se encuentra completamente integrado dentro del entorno de desarrollo de SAP.

La importancia de SAP ABAP reside en que todo el sistema SAP está programado en ABAP y todos
los módulos del ERP hacen uso de este lenguaje. A nivel técnico ABAP es un lenguaje que soporta
tanto programación procedimental como orientada a objetos y es posible a través de este modulo el
desarrollo de programas muy diversos.

1.2.8 Modulo Aplicaciones

Las aplicaciones o módulos de SAP R/3 se dividen en tres grandes áreas:

 Finanzas|financiera
 Logística
 Recursos humanos.

Estos tres grupos no son independientes unos de otros. Además de éstos, existen otros componentes,
llamados Cross Aplications, que son válidos para todas las aplicaciones.

Los principales módulos del sistema R/3 incluyen cientos de procesos de negocio para satisfacer las
necesidades de las empresas en sus aplicaciones de gestión e información.

Las aplicaciones del programa funcionan de modo integrado, de forma que existe una conexión
implícita entre los procesos financieros y logísticos, y también con los humanos.

1.2.9 Modulo SAP FI

SAP FI es uno de los módulos más importantes. Está diseñado para atender todos los procesos
financieros y contables de la entidad. Dentro de este módulo, la información financiera está disponible
para cualquier revisión en tiempo real. SAP FI es un módulo complejo dentro del ERP de SAP, que
está formado por un gran número de componentes que se agrupan en sub-módulos:

17
  Cuentas de deudores: responsable de gestionar la contabilización generada como resultado de
las ventas a terceros. Los asientos contables se actualizan automáticamente en el Libro Mayor.
Dentro de este sub-módulo se pueden sacar históricos de deudas y análisis de clientes
específicos. Está integrado con el Libro Mayor (FI-GL), Ventas y Distribución (SD) y Libro de
Caja.

 Cuentas de acreedores: registra los asientos contables generados como resultado de la actividad
de compras a proveedores. Se generan, además, asientos automáticos en el Libro Mayor. La
funcionalidad de este módulo también permite la automatización de pagos a través de diferentes
hitos predefinidos.

 Cuentas de activos: se usa para gestionar los activos fijos de la entidad. SAP permite categorizar
activos y definir valores para el cálculo de depreciaciones en cada clase de activos.

 Cuentas bancarias: gestión de transacciones bancarias en el sistema que incluye gestión de caja.

 Consolidación: combina los resultados (reportes) financieros de múltiples entidades de una

organización. Estos resultados proporcionan un resumen general de la posición financiera de la
Gobernación.

 Gestión de Fondos: proporciona planificación de presupuestos para ingresos y gastos de la

compañía, así como la posibilidad de enlazar estos con las áreas de responsabilidad
correspondiente.

 Libro Mayor/Nuevo Libro Mayor: éstos están totalmente integrados con otros módulos de SAP.
Todos los asientos contables se registran en el Libro Mayor. Los datos de finanzas de otros
módulos también se registran en el Libro Mayor. Estos asientos se registran en tiempo real,
haciendo que la información de las cuentas financieras esté siempre actualizada.

 Libro Especial: define registros orientados a reportes. Los datos pueden ser recogidos tanto de
aplicaciones internas como externas y ser procesados en SAP.

 Gestión de viajes: gestiona todos los aspectos relacionados con viajes incluyendo reservas y
gestión de gastos asociados con el viaje.

1.2.10 Modulo SAP Logística

SAP MM es uno de los módulos funcionales más extensos. Este módulo principalmente se encarga
de procesos de adquisiciones, verificación de facturas y procesos asociados. SAP MM cubre todas
las tareas relacionadas con la cadena de aprovisionamiento. Algunos de los componentes son:

 Planificación en base a Consumos: se encarga de la reposición de stock y utiliza para ello la

18
 funcionalidad de MRP (Planificación de Requerimientos de Materiales).

 Compras: el área de compras de MM proporciona la habilidad de determinar posibles

fuentes de aprovisionamiento de servicios y materiales, la compra en sí de estos materiales o
servicios, el posterior seguimiento de los pedidos desde que salen de los proveedores,
requisas, peticiones de cuotas, precios y condiciones, órdenes de compra y confirmación de
los proveedores entre otras muchas funcionalidades.

 Gestión de Inventario: los componentes de gestión de inventario contiene los registros

maestros de servicios, y controla y rastrea todos los movimientos de bienes, recibos,
incidencias recibos de bienes devueltos, transferencias de stock, reservas, inventario físico,
determinación de stock y gestión de lotes. Además, este sub-módulo contiene la
contabilidad de costes actualizada de los diversos materiales, soporta diversas monedas y
precios actualizados de los materiales, y es capaz de calcular el coste de producción real.

 Verificación de Facturas: da soporte a la verificación y evaluación de material como Last In

First Out (LIFO) y First In First Out (FIFO), análisis de cambio de precios, cambios de
facturas a créditos, impuestos, descuentos en efectivo, comprobación de recibos, definir el
impacto contable de recibos, cancelar recibos, costes de envío, y determinar variaciones de
facturación.

 Gestión de Servicios Externos: este componente da soporte completo al proceso de

aprovisionamiento de servicios externos desde gestión de proveedores, invitaciones a
concursos, órdenes de pedidos, aceptación de servicios. Así mismo, es usado para definir
especificaciones de servicios, registrar los servicios realizados, confirmar dichos servicios y
luego validar la factura del servicio. Los sistemas de información dentro de MM
comprenden evaluaciones de proveedores, sistema de compras e información de inventario.

1.2.11 Modulo SAP Recursos Humanos

El módulo HCM SAP Permite una gestión eficiente de la información y procesos del personal de la
Gobernación, e integra toda esta información y procesos tanto con los demás módulos de SAP
como con posibles aplicaciones externas.

Algunos de los procesos típicos de cualquier departamento de Recursos Humanos, y que están
reflejados en el módulo HCM SAP son:

 Administración de Personal (PA): un sub-módulo que ayuda a los responsables de recursos

humanos y a los empleadores a realizar seguimientos de los datos maestros, funciones,
salario y bonos.

 Desarrollo de Personal (PD): la funcionalidad de este módulo se centra en las cualidades y

19
 tareas de cada empleado, cualificaciones y plan de carrera.

 Evaluación de Tiempos (PT): procesa fichajes, abstinencias, etc. Así como su impacto en el
salario bruto y los cálculos de impuestos relacionados.

 Nómina (PY): pago a empleados y freelances relacionados (contratos comerciales, por

ejemplo).

1.3 Inventario de interfaces o servicios en la arquitectura actual.

En la Gobernación del Valle del cauca, se tiene como premisa que la información digital, no es un
subproducto de las actividades cotidianas de la operación, sino que corresponden a un activo central
que se es vital para generar valor a la organización.

El inventario de interfaces o servicios de la arquitectura actual se encuentra en proceso de

formalización, pero de hecho incluye:

 Archivos planos

 Webservices: Entendidos como forma estandarizada de integrar aplicaciones WEB

mediante el uso de XML, SOAP, WSDL y UDDI sobre los protocolos de la Internet.

 ETLy EAI: Herramientas y procesos que permiten la extracción, transformación y cargue de

información entre aplicativos y la integración de aplicaciones con esquema de “publicación"
y "suscripción”.

1.4 Diagrama de interoperabilidad con otras entidades para sistemas

de información en la arquitectura actual.
En la Gobernación del Valle del cauca, se tiene como premisa que la información digital, no es un
subproducto de las actividades cotidianas de la operación, sino que corresponden a un activo central
que se es vital para generar valor a la organización.

Es bajo esta premisa que se encuentra actualizando sus diagramas de interoperabilidad, definiendo
web services y archivos planos como una primera etapa de interoperabilidad.

1.5 Portafolio de proyectos de gestión de Sistemas de Información

20
El portafolio de proyectos de gestión de Sistemas de información se centra en el fortalecimiento de
los sistemas misionales, con las siguientes acciones prioritarias:

 Migración de los Sistemas de Información a una plataforma tecnológica moderna, que se

encuentre en capacidad de soportar un ambiente virtualizado.

 Actualización del Sistema SAP de la versión 6.0 a la versión 6.07.

 Implementación de una solución informática integrada al Sistema SAP para la liquidación y

gestión del tributo del impuesto vehicular.

 Proyecto de administración de Back-up externo en un centro de datos alterno.

 Consolidación de las características y funcionalidades de los diversos entornos para

desarrollo y pruebas.

 Inventario integral de Sistemas de Información de la Gobernación.

El portafolio de proyectos adicionales incluye:

 Adquisición e implementación de herramientas de BI orientadas al seguimiento, análisis y a

la presentación y publicación de información según sus ciclos de vida y de acuerdo con los
diversos requerimientos de la gobernación.

 Extender el control y la gestión de datos hacia los repositorios en la Nube.

 Integración de los diversos sistemas de información de la entidad.

21
 2. Catalogo de Sistemas de Información -
LI.SIS.02
El siguiente es el directorio de sistemas de información que son gestionados por la Secretaria de la
Tecnologías de Información y las comunicaciones de la Gobernación del valle del Cauca.

2.1 Directorio de Sistemas de Información y Servicios

22
2.2 Directorio detallado de sistemas de Información y Servicios

Directorio de sistemas de información y servicios

Atributo Descripción
Nombre del sistema SAP(Sistemas, aplicaciones y productos para
el proceso de datos)

Descripción del Permite planificar y gestionar los recursos de todas

sistema las operaciones financieras de las áreas de la
Gobernación del Valle del Cauca: desde logística a
contabilidad, finanzas, producción, gestión de
proyectos y administración general.

 Objetivos Del Sistema SAP
SAP ha definido los objetivos de la como los siguientes:
- Satisfacción de la clientela
- Realización de beneficios
- Crecimiento
- Satisfacción de los empleados

 SAP: Características
Las principales características de SAP son:

Información "on-line"
Esta característica significa que la información se
encuentra disponible al momento, sin necesidad de
esperar largos procesos de actualización y
procesamiento habituales en otros sistemas.
 Jerarquía de la información
Esta forma de organizar la información permite
obtener informes desde diferentes vistas.
 Integración
Esta es la característica más destacable de SAP y
significa que la información se comparte entre todos los
módulos de SAP que la necesiten y que pueden tener
acceso a ella. La información se comparte, tanto entre
módulos, como entre todas las áreas.

23
Servicio o  Finanzas
componente  FI --> Gestión financiera.
 TR --> Tesorería
 Logística
 MM --> Gestión de Materiales.0000000
 PS --> Sistema de control de proyectos
 Recursos Humanos
 RH --> Administración de personal.

 Módulos de aplicación
 Gestión financiera (FI)
 Libro mayor, libros auxiliares, ledgers
especiales, etc.
 Controlling (CO)
 Gastos generales, costes de producto, cuenta de
resultados, centros de beneficio, etc.
 Tesorería (TR)
 Control de fondos, gestión presupuestaria, etc
 Sistema de proyectos (PS)
 Grafos, contabilidad de costes de proyecto, etc.
 Gestión de personal (HR)
 Gestión de personal, cálculo de la nómina,
contratación de personal, etc.
 Gestión de material (MM)
 Gestión de stocks, compras, verificación de
facturas, etc.
 Contienen funciones que se pueden aplicar en
todos los módulos

Descripción del MODULO PRESUPUESTO (FM)

servicio
Este módulo sirve para asegurar el manejo de la
Ejecución Presupuestal en la entidad, garantizando
que no se sobrepasen los valores presupuestados.
Además, sirve también para realizar estudios acerca
de la aplicación del Gasto y ver su nivel de
disponibilidad discriminado por fuente de
financiamiento, objeto del gasto y Centro Gestor.
Por otra parte, nos permite visualizar y comparar,
que partidas de ingreso son las que nos aportan los
recursos necesarios para el financiamiento de los
gastos.

MODULO DE TESORERIA(TR)

24
La Tesorería es la directa responsable de la
Administración del Efectivo, proceso que
comprende la gestión de pagos a proveedores y
acreedores de la entidad y el manejo de excedentes
de liquidez.

MODULO DE RECURSOS HUMANOS (HM)

Gestión de personal,
Gestión de tiempo
Calculo de nomina

MODULO DE PPM-PS (PROYECTOS)

Dar a conocer la funcionalidad del módulo PS

donde se gestionan o ejecutan los proyectos de la
Gobernación del Valle, luego de haber sido
aprobados.

MODULO AP

Módulo de Cuentas por Pagar es el componente de

aplicación Contabilidad de acreedores registra y
gestiona los datos de contabilidad de todos los
acreedores. Además, es parte integral de la gestión
de compras.

MODULO AM

se utiliza para gestionar y supervisar los activos fijos

en SAP. La contabilidad de activos fijos abarca toda
la vida de los activos, desde la orden de compra o el
alta inicial hasta su baja.

 Compras
 Ventas
 Depreciación
 Seguimiento

MODULO FI (FINANCIERO)

Forma parte del sector de módulo financieros del

sistema SAP, también integrado por los módulos de
Contabilidad de Costos (CO) y Tesorería (TR).

25
 Hace la gestión de todos los procesos contables y
financieros de una organización.

MODULO PSCD (INGRESOS)

Public Sector Collection and Disbursement:

Recaudación y Desembolso del Sector Público.
Controla y gestiona las operaciones de Liquidación,
Autoliquidación. Se utiliza para administrar
impuestos, cargos y beneficios estatales de / para
socios comerciales, ciudadanos, estudiantes y
contribuyentes.

MODULO MM(MATERIALES)
Es el módulo que hace parte del área de la logística
y se encarga de las funciones de compras e
inventarios de la entidad

Directorio detallado de sistemas de información y servicios

Atributo Descripción
Nombre del sistema SAP

Servicio o MODULO PRESUPUESTO (FM)

componente MODULO DE TESORERIA(TR)
MODULO DE RECURSOS HUMANOS (HM)
MODULO DE PPM-PS (PROYECTOS)
MODULO AP
MODULO AM
MODULO FI (FINANCIERO)
MODULO PSCD (INGRESOS)
MODULO MM(MATERIALES)

Categoría Operativo
Tipo Web con base de datos central
Cliente servidor
BD y scripts
BC Basis Components

Estado Desarrollo
Pruebas
26
 Producción
Número y tipo de Licenciamiento ilimitado.
licenciamiento Licenciamiento para un procesador.
.

Fecha de vencimiento Indique la fecha hasta la cual se tiene el contrato de

del soporte o de mantenimiento o soporte del sistema con el
vencimiento de la proveedor.
licencia

Plataforma de Oracle, Linux, Java 2 Enterprise Edition y ABAP

aplicaciones (el lenguaje de programación de SAP) Advanced
Business Application Programming.
Ubicación servidor
de aplicaciones Desarrollo 192.168.200.65
Calidad 192.168.200.76
Producción 192.168.200.73

Plataforma de base Desarrollo 192.168.200.65

de datos Calidad 192.168.200.76
Producción 192.168.200.73

Ubicación base de Desarrollo 192.168.200.65

datos Calidad 192.168.200.76
Producción 192.168.200.73

Responsable de la LA SECRETARIA DE LAS TECNOLOGIAS DE

base de datos LA INFORMACION Y LAS COMUNICACIONES

Directorio de sistemas de información y servicios

Atributo Descripción
Nombre del sistema Sistema de Información Turística

Descripción del Permite medir la oferta turística del departamento, la

sistema generación de empleo, determinación de donde
están llegando los turistas y las causas por qué nos
están llegando.

Habilita el poder tomar decisiones más asertivas a la

hora de poder ejecutar las estrategias de promoción
27
 turística de la Gobernación.

Servicio o  Estadísticas de caracterización de la industria

componente turística.

Descripción del Plataforma turística digital que ofrece

servicio actualizaciones en tiempo real de número de
visitantes, cupos hoteleros, lugares más visitados y
flujo de divisas como parte del fortalecimiento al
sector turístico de la región.

28
3. Arquitecturas de Referencia de Sistemas de
Información - LI.SIS.03
Los diversos sistemas de información de la Gobernación del Valle del Cauca deben aproximarse en
lo posible a la arquitectura de su sistema misional, en el sentido de que deben estar desarrollados en
arquitecturas multicapas y/o multinivel.

En este caso se deben considerar tres o más capas, y deben mantener como característica que
puedan ser alojados lógicamente en uno o varios servidores, habilitando la posibilidad de
segmentar lógica, y físicamente la distribución de los componentes de la solución,

Entre las característica de este ambiente multicapa se consideran el disminuir los requerimientos de
acoplamiento y la mejora de la cohesión de los componentes para facilitar su mantenimiento.

La Gobernación del Valle de Cauca igualmente ha adoptado la Arquitectura debe ser orientada a
servicios - SOA, como un elemento vital para gestionar la transformación de infraestructura
tecnológica y de negocio para asegurar un camino adecuado hacia la transformación digital. En esta
Arquitectura Orientada a Servicio, se pueden aprovechar diversos beneficios, pero la Secretaria de
las Tecnologías de la información y las comunicaciones han definido como prioritarios el poder
tener:

 Una Visión completa del funcionamiento.

 Una Integración sin fisuras entre los sistemas y la nube.

 Una Vinculación eficiente de los sistemas front office y back office.

 Un eficiente soporte a los requerimientos de software del usuario

 Un esquema estructurado de modelo de procesos

La Gobernación también ha definido dentro de su arquitectura de referencia el involucrar los

estándares abiertos:

 XML - Para representar información estructurada en la web (todos documentos), de modo

que esta información pueda ser almacenada, transmitida, procesada, visualizada e impresa,
por muy diversos tipos de aplicaciones y dispositivos.

 SOAP - Para definir cómo dos objetos en diferentes procesos pueden comunicarse por
medio de intercambio de datos XML.

29
  WSDL - El Web Services Description Language, como formato del Extensible Markup
Language (XML), gramatica que se utiliza para describir servicios web

 REST - Como estilo de arquitectura software para sistemas hipermedia distribuidos como
la World Wide Web.

La arquitectura de referencia usada en la Secretaria de las Tecnologías de informaron y las

comunicaciones de la Gobernación del Valle del Cauca se basa en la articulación de los siguientes
componentes:

• Seguridad

• Auditoría

• Control de acceso

• Canales

• Consultas

• Búsquedas de Contenido

• Visualización

• Frameworks de Desarrollo de aplicaciones

• Flujos de Trabajo

• Lógica de Negocio

• Interoperabilidad

• Base de Datos

• Contenido Documental.

30
4. Arquitecturas de solución de sistemas de
información - LI.SIS.04
La arquitectura de solución adoptada por la Gobernación del Valle del Cauca se basa en el Estándar
Internacional ISO/IEC 25000.

Este estándar establece una arquitectura de alto nivel del ciclo de vida del software. Este comienza
con una idea o una necesidad que puede ser satisfecha en su totalidad o en parte por el software y
termina con el retiro de éste.

La arquitectura se construye con un conjunto de procesos e interrelaciones entre estos. La

derivación de los procesos se basa en dos principios básicos: la modularidad y la responsabilidad.

Los artefactos a ser construidos incluyen:

 La matriz de involucrados e intereses de cada una de las dependencias. Para este trabajo se
ha iniciado con la definición de enlaces para cada una de las dependencias. Se considera que
al tener identificados todos los actores del proyecto, sus intereses, expectativas y
necesidades, se le proporciona congruencia y coherencia al Sistema de Información,
aumentando la probabilidad de recibir apoyos y disminuir la oposición.

 Definición de los atributos de calidad. Para este efecto se consideraran como atributos de
calidad para usuarios así:

o Disponibilidad
o Eficiencia
o Flexibilidad
o Integridad
o Interoperabilidad
o Confiabilidad
o Robustez
o Usabilidad

 y criterios de calidad para desarrolladores así:

o Mantenibilidad
o Portabilidad
o Reusabilidad
o Comprobabilidad
o Gestionabilidad
o Seguridad

31
 Definición de los requerimientos funcionales: Describen cualquier actividad que este deba
realizar el Sistema de Información. Deben incluir funciones desempeñadas por pantallas
específicas, descripciones de los flujos de trabajo a ser desempeñados por el sistema y otros
requerimientos de negocio, cumplimiento, seguridad u otra índole. Entre estos
requerimientos funcionales se incluyen:
o Descripciones de los datos a ser ingresados en el sistema.
o Descripciones de las operaciones a ser realizadas por cada pantalla.
o Descripción de los flujos de trabajo realizados por el sistema.
o Descripción de los reportes del sistema y otras salidas.
o Definición de quien puede ingresar datos en el sistema.
o Definición de como el sistema cumplirá los reglamentos y regulaciones de sector o
generales que le sean aplicables.

 Matriz de drivers de negocio vs atributos de calidad. Los drivers que se han definido para la
Secretaria de las Tecnologías de la Información y las comunicaciones incluyen:
o Reactividad e innovación
o Comportamiento del usuario
o Migración de valor
o Co creación de valor
o Relación con el usuario
o Estrategias disruptivas
o Management competente
o Diferenciación
o Alineamiento e integración
o Procesos eficientes y efectivos
o Experiencias gratificantes
o Gestión de la información
o Redes de valor (gobernación, canal y ciudadanos)

 Matriz de casos de uso vs atributos de calidad. En la Gobernación cada caso de uso se centra
en describir cómo alcanzar una única meta o tarea de negocio. Un caso de uso describe una
característica del sistema. Un caso de uso debe:
o Describir una tarea del negocio que sirva a una meta de negocio
o Tener un nivel apropiado del detalle
o Ser bastante sencillo como que un desarrollador lo elabore en un único lanzamiento

 Con el fin de entender y priorizar las necesidades de negocio a través de sus atributos de
calidad, la Secretaria de las Tecnologías de Información y las comunicaciones ha definido
qué los atributos de calidad son más importantes para la Gobernación y en los cuales se
debe enfocar la arquitectura son:
o Prioridad 1 - Confiabilidad : Mide la probabilidad de que el software se ejecute sin
errores.
o Prioridad 2 - Usabilidad: Se refiere a que tanto el sistema es “amigable” con el
usuario.
o Prioridad 3 - Robustez : Es la medida que dice el grado en el cual el sistema

32
 continua operando con propiedad luego de una entrada inválida, defectos en la
conexión o condiciones inesperadas.
o Prioridad 4 - Integridad: Es el atributo que habla de la seguridad de datos y sistema,
accesos no autorizados, pérdida de información, protección contra virus, privacidad
y seguridad de los datos.
o Prioridad 5 - Mantenibilidad : Indica cuán fácil es corregir un defecto o realizar una
modificación al sistema.
o Prioridad 6 - Flexibilidad: es la medida que dice cuán fácil es agregar nuevas
capacidades al sistema.
o Prioridad 7 - Interoperabilidad: mide cuán fácil el sistema puede intercambiar datos
o servicios con otros sistemas.
o Prioridad 8 - Reusabilidad: Indica el esfuerzo para reutilizar un componente de un
sistema en otro.
o Prioridad 0 - Eficiencia: es el atributo que dice cómo el sistema utiliza el equipo
(procesador, espacio en disco, memoria, ancho de banda, etc). Si un sistema
consume muchos recursos su rendimiento de ve afectado y por ende el usuario.
o Prioridad 10 - Portabilidad : Mide el esfuerzo requerido para migrar una parte del
software de un ambiente operacional a otro
o Prioridad 11 - Comprobabilidad: se refiere al esfuerzo que se hace para buscar
errores
o Prioridad 12 - Disponibilidad: Es el tiempo que el sistema estará disponible para los
usuarios

 Patrones de diseño: Con respecto a los patrones de diseño la Secretaria de las Tecnologías
de Información y las Comunicaciones adopta la definición que indica que un patrón de
diseño es una forma reutilizable de resolver un problema común. En este sentido iniciara la
consolidación de una base de conocimientos, que consistirá de reglas comunes para
solucionar problemas comunes. En este sentido los clasificará como:
o Patrones creacionales: Que facilitan la tarea de creación de nuevos objetos, de tal
forma que el proceso de creación pueda ser desacoplado de la implementación del
resto del sistema.
o Patrones estructurales: Que facilitan la modelización del software especificando la
forma en la que unas clases se relacionan con otras.
o Patrones de comportamiento: Que habilitan el gestionar algoritmos, relaciones y
responsabilidades entre objetos.

33
5. Metodología de referencia para el desarrollo de
sistemas de información - LI.SIS.05
Las metodología de referencia usadas son el Estándar Internacional ISO/IEC 25000.

La estructura de este estándar tienen una característica que se considera muy atractiva y es el poder
ser adaptada a las necesidades de cualquiera que lo use. En este sentido ofrece una metodología de
referencia que aporta eficientemente a la Gobernación del Valle del Cauca.

La Norma ISO/IEC 12207 (antecesora de la ISO/IEC 25000), fue la primera norma internacional
que proporcionó un amplio conjunto de procesos de ciclo de vida del software, el cual forma parte
de un sistema mayor, se realizó su primera publicación el 1 de agosto de 1995, la misma que fue
precedido en noviembre del 2002 por la norma ISO/15288 que trata los procesos del ciclo de vida
de un sistema.

La norma ISO/IEC 15504 ha sido denominada como Determinación de la Capacidad de Mejora del
Proceso de Software o SPICE nos propone un modelo para la evaluación de la capacidad en los
procesos de desarrollo de productos software.

La aplicación de estas normas en general, consiste en seleccionar un conjunto de procesos y

adecuarlos para los Sistemas de Información de la Gobernación del Valle.

Se establece que dadas las características de la Gobernación, no será obligatoriamente necesaria la

inclusión de todos los procesos establecidos en las normas.

El estándar 12207 se basa en dos principios fundamentales:

 Modularidad: Con esta se pretende conseguir procesos con un mínimo acoplamiento y una
máxima cohesión.

 Responsabilidad: Con esta se dan los lineamientos para designar un responsable para cada
proceso.

Estas características facilitan la aplicación del estándar en proyectos en los que pueden existir
distintas personas u organizaciones involucradas.

34
 Los procesos del ciclo de vida se agrupan en tres grandes clases:

 Primarias
 Soporte
 De organización

5.1 Procesos Primarios

5.1.1 Procesos de adquisición

En este proceso se definen las actividades y tareas de la Entidad cuando adquiere un Sistema de
información, un producto de software o un servicio por contrato, que puede ser el servicio completo
o una parte de este.

La entidad presenta las necesidades de los usuarios, este proceso comienza con la definición de esta
necesidad, continua con la preparación y emisión de una solicitud de propuesta, la selección de un
proveedor y la gestión del proceso de adquisición a través de la aceptación del sistema. Todo esto
bajo los lineamientos definidos en la política de compras.

Con respecto a la Norma ISO 25000 se deben monitorear las siguientes actividades:

 Iniciación

 Solicitud de preparación de propuesta

 Elaboración y actualización del contrato

 Monitoreo del proveedor

 Aceptación

 Finalización.

Las 3 primeras se producen antes del acuerdo y las últimas 2 después del acuerdo.

5.1.2 Proceso de suministro

Este proceso contiene las actividades y tareas del proveedor. Se compone de las siguientes
actividades:

35
  Iniciación

 Preparación de la respuesta

 Contrato

 Planificación

 Ejecución y control

 Revisión y evaluación

 Entrega y terminación.

Puede ser iniciado por la decisión de preparar una propuesta para responder a la petición de un
usuario o mediante la firma de un acuerdo con la entidad para proporcionar un servicio.

El servicio puede ser el desarrollo de un Sistema de información - producto de software, la

operación de un sistema con un software o el mantenimiento de un producto. Luego de esto
continua con la identificación de los procedimientos y los recursos necesarios para gestionar y
asegurar el servicio, incluido el desarrollo y ejecución de los planes a través de la entrega al cliente.

5.1.3 Proceso de desarrollo

Este proceso del ciclo de vida contiene las actividades y tareas del desarrollador del Sistema de
Información. El desarrollo a largo plazo denota tanto el desarrollo de nuevo Sistema de
Información y modificación de un Sistema de Información existente.

El proceso de desarrollo está destinado a ser empleado en al menos dos formas:

 Como una metodología para el desarrollo de prototipos o para el estudio de los requisitos y
el diseño de un producto

 Como un proceso para producir productos.

El proceso de desarrollo se compone de las siguientes actividades además de sus tareas específicas:

 Implementación del proceso de análisis de requisitos del sistema

 El diseño del sistema

 Análisis de requerimientos del Sistema de Información

36
  Diseño de la arquitectura del Sistema de Información

 Diseño detallado del Sistema de Información

 Codificación y pruebas del Sistema de Información

 Integración del Sistema de Información

 Pruebas de calificación del Sistema de Información

 Integración de Servicios Tecnológicos

 Pruebas del sistema de calificación

 Instalación de Sistema de Información

 Protocolo de aceptación del Sistema de Información

El orden de estas actividades no implica necesariamente un orden cronológico. Estas actividades

pueden ser iteradas y solapadas. Todas las tareas en una actividad no necesitan ser completadas en
la primera o cualquier iteración dada, pero deberían haberse completado cuando la iteración final
llega a su fin.

Estas actividades y tareas se pueden usar para la construcción de uno o más modelos de desarrollo
(tales como, cascada, incremental, evolutivo, espiral, o de otro tipo, o una combinación de éstos)
para un proyecto o una organización.

El estándar permite asentar las bases para los requisitos, diseño y código en los puntos
predeterminados durante el desarrollo del producto. Lo cual inhibe los cambios prematuros o no
planificados a estos requisitos y promueve el control de cambio efectivo. El estándar también
proporciona los foros (es decir, la revisión conjunta y procesos de auditoría) para las partes
interesadas en participar.

5.1.4 Proceso de operación

Este proceso de ciclo de vida, que forma parte de la operación total del sistema, contiene las
actividades y tareas del operador de un Sistema de Información. El proceso comprende el
funcionamiento del Sistema de Información y de apoyo operativo a los usuarios.

Consta de las siguientes actividades, junto con sus tareas específicas:

 Implementación del proceso

37
  Pruebas de funcionamiento

 Operación del sistema

 Apoyo del usuario.

5.1.5 Proceso de mantenimiento

Contiene las actividades y tareas del encargado de mantener los Sistemas de Información .

Este proceso se activa cuando un Sistema de Información se somete a modificaciones en el código

y la documentación asociada debido a:

 Un error

 Una deficiencia

 Un problema

 La necesidad de una mejora o adaptación.

El objetivo es modificar un sistema existente preservando al mismo tiempo su integridad. Cada vez
que un Sistema de Información necesita modificaciones, el proceso de desarrollo se invoca para
efectuar y completar las modificaciones correctamente.

Este proceso consta de las siguientes actividades además de sus tareas específicas:

 Implementación del proceso de análisis de problemas y modificaciones

 Aplicación de las modificaciones

 Revisión de mantenimiento/ aceptación

 La migración

 Protocolo de baja de un Sistema de Información.

5.2 Procesos de Soporte

Este estándar contiene un conjunto de ocho procesos de apoyo. Un proceso de apoyo es compatible

38
 con cualquier otro proceso como una parte integral con un propósito distinto que contribuye al éxito
y la calidad del proyecto.

Un proceso de apoyo se invoca, según sea necesario, mediante la adquisición, suministro,

desarrollo, operación o proceso de mantenimiento, o en otro proceso de apoyo.

5.2.1 Proceso de documentación

Este es un proceso para registrar la información producida por un proceso de ciclo de vida. El
proceso define las actividades para planificar, diseñar, desarrollar, editar, distribuir y mantener los
documentos necesarios por todos los interesados, tales como gerentes, ingenieros y usuarios del
sistema.

Las cuatro actividades junto con sus tareas son:

 Implementación del proceso

 Diseño

 Desarrollo

 Producción y mantenimiento.

5.2.2 Proceso de gestión de la configuración

Se emplea este proceso para identificar, definir, y alinear la base de los elementos de software en un
sistema, para controlar las modificaciones y versiones de los elementos, para registrar e informar el
estado de los elementos y las peticiones de modificación, para asegurar la integridad y exactitud de
los elementos, y para controlar el almacenamiento, la manipulación y la entrega de los artículos.

Este proceso consiste en:

 La ejecución de procesos

 Identificación de configuración
 Control de configuración

 Estado de la configuración

 Evaluación de configuración
39
  Gestión y administración de liberación.

5.2.3 Proceso de control de calidad

Este proceso proporciona el marco para asegurar la independencia y objetividad de conformidad de

los productos o servicios con sus requisitos contractuales y la adhesión a sus planes establecidos.

Para ser imparcial, el aseguramiento de la calidad debe tener libertad organizacional frente a
aquellas personas directamente responsables de desarrollar el Sistema de Información o ejecutar
los procesos del proyecto.

Este proceso consiste en:

 La implementación de procesos

 Aseguramiento del producto

 Aseguramiento de procesos

 Aseguramiento de sistemas de calidad.

5.2.4 Proceso de verificación

Este proceso proporciona las evaluaciones relacionadas con la verificación de un producto o

servicio de una actividad determinada. La verificación determina si los requisitos para un sistema
son completos y correctos, y que los resultados de una actividad cumplan los requisitos y
condiciones que se les imponen en las actividades anteriores.

Abarca la:

 Verificación del proceso

 Verificación de los requisitos

 Verificación del diseño

 Verificación del código

40
  Verificación de la integración

 Verificación de la documentación.

La verificación no alivia las evaluaciones asignadas a un proceso, al contrario, los complementa.

5.2.5 Proceso de validación

Determina si el sistema final cumple con su uso específico previsto. El alcance de la validación
depende de la criticidad del proyecto. No sustituye a otras evaluaciones, sino que los completa.

La verificación o validación pueden ser realizadas por quien adquiere el producto, el proveedor o
un tercero independiente. (Interventor).

Cuando son ejecutados por una organización independiente del proveedor o desarrollador, se
les llama proceso de verificación y validación independiente.

5.2.6 Proceso de revisión conjunta

El Proceso de Revisión Conjunta es un proceso en el cual se evalúan el estado y productos de una

actividad de un proyecto. Las revisiones conjuntas se hacen tanto a nivel de administración de
proyecto como a nivel técnico y se mantienen a lo largo de la vida del proyecto o contrato del
Sistema de Información.

Este proceso puede ser empleado por cualquiera de las dos partes, donde una (parte revisora) revisa
a otra (parte revisada).

5.2.7 Proceso de auditoría

Este proceso proporciona el marco para las auditorías formales, establecidas en el contrato de los
productos o servicios del proveedor. El auditor evalúa los productos del auditado y actividades con
énfasis en el cumplimiento de los requisitos y planes.

Una auditoría bien puede llevarse a cabo por la misma Gobernación a través del personal de la
Secretaria de las Tecnologías de Información y las Comunicaciones.

41
5.2.8 Proceso de resolución de problemas

Este proceso proporciona el mecanismo para instituir un proceso de circuito cerrado para la
resolución de problemas y tomar acciones de corrección para eliminar los problemas a medida que
se detectan.

Además, el proceso requiere la identificación y análisis de las causas y la reversión de las

tendencias de los problemas reportados. El término "problema" incluye la no-conformidad.

5.3 Los Procesos de Organización

Este estándar contiene un conjunto de cuatro procesos de la organización. Una organización emplea
un proceso organizativo para realizar funciones en él, a nivel corporativo de la organización, por lo
general más allá o en los proyectos.

Un proceso de organización puede apoyar cualquier otro proceso. Estos procesos ayudan a
establecer, controlar y mejorar otros procesos.

5.3.1 Proceso de gestión

Este proceso define las actividades y tareas del gerente de un proceso de ciclo de vida del Sistema
de Información, tales como el proceso de adquisición, proceso de suministro, proceso de operación,
proceso de mantenimiento, o el proceso de apoyo.

Las actividades abarcan:

 Iniciación y definición del alcance

 Planificación

 Ejecución y control

 Revisión y evaluación

 Cierre.

A pesar de que los procesos primarios, en general, tienen actividades de gestión similares, son lo
suficientemente diferentes a nivel de detalle debido a sus diferentes metas, objetivos y métodos de
operación.

42
5.3.2 Proceso de infraestructura

Este proceso define las actividades necesarias para el establecimiento y mantenimiento de una
infraestructura subyacente para un proceso de ciclo de vida.

Este proceso tiene las siguientes actividades:

 Proceso de implementación

 Establecimiento de la infraestructura

 Mantenimiento de la infraestructura.

La infraestructura puede incluir hardware, software, estándares, herramientas, técnicas, y las

instalaciones.

5.3.3 Proceso de progreso

El estándar proporciona las actividades básicas al nivel superior que una organización necesita para
evaluar, medir, controlar y mejorar el proceso de ciclo de vida.

Las actividades comprenden:

 El establecimiento de procesos

 Evaluación de procesos

 Mejora de procesos.

Las experiencias de la aplicación de los procesos del ciclo de vida de los proyectos se utilizan para
mejorar los procesos. Los objetivos son mejorar los procesos en beneficio de la organización en su
conjunto y los proyectos actuales y futuros para el avance de las tecnologías de Sistemas de
Información en toda la Gobernación.

5.3.4 Proceso de capacitación

Este proceso puede ser usado para identificar y hacer el suministro oportuno para adquirir o
desarrollar los recursos y habilidades del personal en los niveles de gestión y técnicos. El proceso
requiere que se elabore un plan de formación, se genere material de capacitación, y se brinde
capacitación al personal en forma oportuna.
43
5.4 Aporte de la Norma ISO/IEC 15504
La creciente complejidad de la producción del software en los últimos tiempos hace necesario la
imposición de los estándares para la certificación de los procesos de desarrollo que acrediten a las
organizaciones de cara a unos usuarios cada vez mas digitales y exigentes.

Dentro del Marco de referencia de Arquitectura Empresaria, el Ministerio de las Tecnologías de la

Información y las Comunicaciones ha recomendado el que se pueda garantizar, que se pueda
adelantar un proceso de evaluación riguroso de la capacidad de procesos TI en cada entidad y para
cada uno de los posibles contratistas, como único medio para una evaluación formal basada en las
evidencias.

La norma ISO/IEC 15504 es una norma de forma internacional para establecer y mejorar la
capacidad y madurez de los procesos de las empresas. La norma ISO/IEC 15504sirve para evaluar
la capacidad o la madurez de los procesos de la empresa. En la definición no se citan las palabras
“procesos software”, porque la norma ISO/IEC 15504 es “framework” para evaluar de forma
cualquier modelo de procesos. De forma genérica y aplicables a muchas áreas diferentes.

44
6. Derechos Patrimoniales Sobre los Sistemas de
Información - LI.SIS.06.

Con respecto a los derechos patrimoniales la Gobernación del Valle del Cauca asume como punto
de partida las obligaciones que le asisten en virtud de lo establecido en la Constitución Política
Colombia, específicamente el artículo 61.

" Artículo 61. El Estado protegerá la propiedad intelectual por el tiempo y mediante las
formalidades que establezca la ley."

En razón de lo anterior es preciso adoptar unas políticas, que permitan generar medidas
preventivas en el ámbito público que conduzcan a la adopción de mejores prácticas administrativas
encaminadas a garantizar el respeto del derecho de autor y los derechos conexos.

La Secretaria de las Tecnologías de información y las comunicaciones, a través de las diferentes

modalidades de contratación:

 Produce Sistemas de Información

 Adquiere Sistemas de Información

 Utilizan bienes con componentes que involucran Sistemas de Información

Todos estos elementos se encuentran protegidos por normas relativas al derecho de autor.

En ese orden de ideas, se han definido como obligaciones de la Gobernación del Valle del Cauca:

 Establecer una política de protección de derechos patrimoniales

 Adelantar actividades de capacitación

 Intercambiar experiencias e información con otras entidades

Y en general propender para que se habilite el generar una cultura de respeto a la propiedad
intelectual, en cada una de las actividades emprendidas por la Gobernación y sus entidades
asociadas.

Lo anterior en consideración a que:

45
  Según lo consagrado en el artículo 91 de la Ley 23 de 1982, los derechos patrimoniales de
autor sobre las obras creadas por empleados o funcionarios públicos, en cumplimiento de las
obligaciones legales y constitucionales de su cargo, son de propiedad de la entidad pública
correspondiente.

 Lo dispuesto por el artículo 183 de la Ley 23 de 1982, todo acto de enajenación de derecho
de autor debe constar en escritura pública o en documento privado reconocido ante notario,
instrumento que para ser oponible ante terceros, deberá ser registrado en la Oficina de
Registro de la Dirección Nacional de Derecho de Autor.

 El artículo 20 del Ley 23 de 1982, especifica que cuando uno o varios autores elaboren,
mediante contrato de prestación de servicios, una obra según plan señalado por persona
natural o jurídica y por cuenta y riesgo de ésta, se entiende que los autores transfieren los
derechos patrimoniales sobre la obra conservando las prerrogativas de tipo moral.

Para contribuir a la construcción de una política con respecto a los derechos patrimoniales de los
sistema de información, la Secretaria de las Tecnologías de Información y las comunicaciones de
la Gobernación del Valle del Cauca, se apoya en que los procedimientos definidos por la Unidad
Especial Administrativa Dirección Nacional de Derecho de Autor.

Esta unidad a través de procesos de difusión y capacitación, y mediante la adopción de los

instrumentos adecuados, permite el diseño y desarrollo de una estrategia para la creación de una
cultura de respeto y protección del derecho de autor y los derechos conexos.

6.1 Políticas
Las políticas incluyen:

1. En la contratación de bienes y servicios de Tecnologías de la Información y las

comunicaciones en la Gobernación del Valle del Cauca debe tenerse en cuenta, en todas las
etapas del proceso contractual, las normas de protección del derecho de autor.
2. Los Sistemas de Información, y en general cualquier componente de software, no pueden
ser copiados, alterados, o distribuidos sin la debida autorización de su titular de derechos
patrimoniales.
3. La Gobernación del Valle del Cauca, conforme a sus necesidades de adquisición de bienes
que involucren componentes TIC, deberá plasmar en los términos de referencia y demás
documentos contractuales el alcance inequívoco de las prestaciones, entre las cuales se
cuenta la relacionada con el ejercicio de los derechos patrimoniales de autor.
4. Cada contrato relativo a bienes que involucren componentes TIC deberá establecer en su
respectivo contrato, de forma precisa cuál de las partes será la titular de estos derechos, o de
ser el caso, las condiciones bajo las cuales la Gobernación del Valle del Cauca podrá

46
 modificar, disponer y en general hacer uso del Sistema de Información o sus componentes.
5. En cada contrato relativo a bienes que involucren componentes TIC, la Gobernación hará un
análisis detallado de las condiciones establecidas para los derechos patrimoniales, con el fin
de evitar o por lo menos minimizar el grado de dependencia tecnológica que eventualmente
pueda llegar a constituir un riesgo en la contratación.
6. La Gobernación verificara si alguna de las bases de datos que utiliza, puede ser considerada
como obra protegida por el derecho de autor, basada en la premisa de que se trate de una
base de datos original.
7. Cuando existan dudas con respecto a Derechos patrimoniales en materia de adquisición,
reposición, actualización, integración, mantenimiento, y sostenimiento de sistemas de
información, equipos de procesamiento de datos y programas informáticos, la Gobernación
del Valle del Cauca, acudirá al Comité Técnico de la Comisión Intersectorial de Políticas y
Gestión del Información para la Administración Pública -COINFO -, creado por el Decreto
3816 de 2003, en su calidad de máximo órgano consultivo.
8. La Gobernación del Valle en salvaguardia del interés público planeara la viabilidad y
sostenibilidad de los proyectos que involucren en su contratación tecnología o la
transferencia de derechos patrimoniales de autor.
9. Cuando se contraten bienes y servicios relacionados con derechos patrimoniales de autor,
incluidos los programas de computador (software), se debe analizar detalladamente los
contratos preestablecidos por el proveedor atendiendo cuidadosamente su contenido.
10. La Gobernación del Valle del Cauca, define como medio de prueba y de publicidad de sus
prerrogativas con respecto a sus Sistemas de Información, que estos se registren ante la
Dirección Nacional de Derecho de Autor, especialmente en las obras cuya titularidad
integral ejerce.
11. Los contratos que impliquen cesión o licencias de uso de programas de computador se
deben incluir las cláusulas que específica y autónomamente regulen el ejercicio de los
derechos patrimoniales de autor, y de ser necesario, se debe buscar el incorporar un anexo
en donde se describa el alcance de lo pactado.
12. Cuando se celebren contratos de licencia se debe verificar que los mismos estén
acompañados de documentos tales como certificados de autenticidad 0 el certificado de
distribuidor autorizado.
13. Cuando la Gobernación del Valle del Cauca adquiera Licencias de uso, se debe analizar y
determinar el alcance de estas. De esta manera, podrá establecer las restricciones y
facultades que en su favor a señalado el titular de la obra.
14. Cuando un tercero elabore un Sistema de Información por encargo a la Gobernación del
Valle del Cauca, debe acreditar de manera expresa y en la fase precedente a la estipulación
del contrato, las autorizaciones sobre aquellos programas de computador que requiera para
desarrollar su objetivo.
15. Cuando la Gobernación del Valle del Cauca, la entidad utilice un Sistema de Información en
virtud de una licencia de uso, será necesario estipular contractualmente las condiciones de
mantenimiento, y de ser posible, acordar con el titular bajo qué condiciones la Gobernación
del Valle del Cauca podría, de manera autónoma, intervenir el respectivo Sistema de
Información.
16. La Gobernación del Valle del Cauca solo renovara licencias relativas a Sistemas de
Información, si estos se van a seguir siendo usadas en un proyecto actual o en proyectos
futuros.
47
17. La Gobernación del Valle del Cauca procurara que en lo posible se logre un tratamiento
económico preferencial por el uso de las licencias del software que vayan a ser
implementadas por la entidad, a tal efecto preferirá negociaciones bajo acuerdos marcos de
precio.
18. La Secretaria de las Tecnologías de la Información las comunicaciones designara un
responsable de la conservación y custodia de las licencias, así como de los Sistemas de
Información sobre los cuales ejerce los derechos patrimoniales.
19. E los casos en que un Sistema de Información será utilizado no solamente por la
Gobernación del Valle del Cauca, sino que debe ser puesto a disposición de terceros, es
necesario que en la negociación previa, dicha facultad se acuerde expresamente al interior
de la licencia que el titular otorgue a la Gobernación.
20. Siempre que la Gobernación del Valle del cauca adquiera la titularidad de los derechos
patrimoniales o negocie los términos de una licencia de uso, es aconsejable que se incluya
en el contrato una cláusula de garantía a través de la cual el cedente de estos derechos o el
titular de la licencia, se haga responsable por las futuras acciones judiciales o extrajudiciales
promovidas por terceros en atención a una pretendida violación a los derechos de autor,
competencia desleal, etc.

48
 7. Guía de estilo y usabilidad - LI.SIS.07
La guía de estilo y usabilidad adoptada por la Gobernación del Valle se encuentra basada en la guía
de Lineamientos y metodologías en Usabilidad para Gobierno en línea.

En razón de los anterior adopta el criterio de la usabilidad, entendida como la cualidad de un

producto interactivo de ser fácil de usar y comprender por quien lo usa.

Una premisa para los aplicativos es que estos sean fáciles de usar, y que tengan la capacidad de
proporcionar la mejor experiencia a los usuarios.

De igual manera se evalúa si la guía aplica a un sistema de información tipo:

 Cliente servidor

 Ambiente WEB

 Dispositivo móvil

Con esta adopción la Secretaria de las Tecnologías de la Información y las comunicaciones busca
obtener como beneficios:

 Disminución de los costos de producción

 Reducción de los costos de soporte y mantenimiento

 Disminución de los costos de uso

 Reducción de los costos de aprendizaje

 Descenso de la cantidad de requerimientos de soporte a usuario final

 Incremento del nivel de satisfacción de los usuarios

 Incremento de visitas a los portales de la Gobernación

7.1 Directrices
Las Directrices que adopta la Gobernación del Valle del Cauca se fundamentan en las guías que ha
definido para este efecto El Ministerio de las Tecnologías de Información y las Comunicaciones, y
su adaptación a los requerimientos específicos de la Gobernación.
49
 Con respecto a las diferentes categorías de directrices la Secretaria de las tecnologías de la
Información y las Comunicaciones adopta:

7.1.1. Directrices de Arquitectura de Información

 La Arquitectura de Información de los Sistemas de Información de la Gobernación del Valle

del Cauca estará argumentada y basada en pruebas con usuarios.

 Cada sistema de información tendrá definido de manera clara e inequívoca las necesidades
que pretende solucionar.

 Para cada sistema de información se evaluara desde un principio el esquema que permitirá
de manera concreta realizar una evaluación del nivel éxito alcanzado.

 Para definir los objetivos de un sistema de información será necesario contar con la
participación de todas aquellas Secretarias de la Gobernación que se vean involucradas.

 Los objetivos, los antecedentes y el proceso de definición de cualquier sistema de

información se deberá encontrar documentado.

 Se adoptara una metodología de análisis basada en la definición de casos de uso. En esta se

plantean casos de uso reales, en los que se define cuál sería el proceso que sigue el usuario
desde que formula su necesidad hasta su interacción con el Sistema de información.

 El equipo de trabajo de La Secretaria de las Tecnologías de la Información y las

Comunicaciones deberá mantener un contacto cercano con el usuario final durante todo el
proceso de construcción de los Sistemas de información.

 Es obligatorio identificar los diversos roles o grupos de usuarios para cada sistema de
información.

 Se considerara que el mejor diseño es aquel que evoluciona constantemente a medida que
los usuarios lo usan, el que aprovecha la información y las estadísticas de uso para aumentar
su calidad.

 Debe existir un documento en el cual quede plasmada la periodicidad y tipo de evaluaciones

a realizar sobre los sistemas de información.

50
7.1.2. Directrices de Interfaz de usuario

 Para La Secretaria de las Tecnologías de la Información y las Comunicaciones se considera

una premisa la calidad del diseño de la interfaz, en consideración a que esta aporta
significativamente a través de la composición, la imagen y el color, a una clara comprensión
de los contenidos.

 El diseño visual es un aporte a la facilidad de uso y como tal será validado con los usuarios.

 Para cada sistema de información se evaluara el comportamiento del usuario, a partir de la

asignación de una tarea concreta sobre el Sistema.

 El texto y las imágenes de texto deberán tener suficiente contraste de brillo y color con el
fondo.

 Se deben usar fuentes tipográficas universales para todos los textos de los Sistemas de
información.

 Enfoque claramente todos los elementos del menú de inicio en las tareas clave de los
usuarios.

 Se debe facilitar que el usuario pueda distinguir claramente los campos obligatorios de los
opcionales. Se debe tener un mecanismos de validación dinámico que evite que el usuario
deje vacío un campo requerido.

7.1.3. Directrices de Diseño de Interacción

 Se de asegurar que todos los campos obligatorios en cada uno de los formularios de los
Sistemas de Información, deben estar etiquetados y deben ser distinguibles de los
opcionales.

 Se deben proporcionar mecanismos de validación dinámicos que eviten que el usuario deje
vacío un campo requerido antes de enviar un formulario.

 Para diseñar etiquetas se deben ubicar las etiquetas de los campos en la parte superior,
reservar un espacio en blanco considerable para separar unos campos de otros, y cuando se
emplee listas de selección no se deben proveer etiquetas, se debe hacer que el valor
predeterminado del campo sea la etiqueta.

 Se debe proporcionar a los campos obligatorios una validación en línea, que despliegue
inmediatamente un mensaje en caso que el usuario no ingrese datos, o los ingrese de manera
incorrecta.
51
7.1.4 Motor de búsqueda y ubicación

 Se debe ofrece un motor de búsqueda interno asociado a los diversos módulos.

 El motor de búsqueda interna debe ser capaz de hacer sugerencias tanto de contenidos
relacionados, como de correcciones en la forma de escribir la consulta.

7.1.5 Pruebas de Usabilidad

Con respecto a las pruebas la Secretaria de las tecnologías de la Información y las comunicaciones
ha definido como premisas la necesidad de:

 Seleccionar adecuadamente los principios aplicables para realizar las pruebas.

 Evaluar el impacto que generan en el usuario los errores de Usabilidad.

 Escoger personal con conocimientos en Usabilidad para llevar a cabo la Evaluación.

 Incluir en el equipo de evaluación más de un perfil (experto, usuario clave, etc.)

 Calificar la frecuencia con que aparecen los errores.

52
8. Apertura de datos - LI.SIS.08
La Secretaria de las Tecnologías de la Información y las comunicaciones ha definido que sus
sistemas de información deben incorporar funcionalidades que facilitan la generación de datos que
cumplen con tener formatos digitales estandarizados y con una estructura de fácil comprensión.

Para priorizar estas funcionalidades se han definido procedimentalmente:

 En la Gobernación del Valle quienes conocen los datos representativos de su sistema de

información son los usuarios funcionales, por eso es necesario establecer un equipo de
trabajo con ellos, apoyado por un grupo técnico que realice las labores de extracción,
transformación y carga (ETL).

 Este Grupo será el encargado de identificar las solicitudes de información más recurrentes.

 La Secretaria de las Tecnologías de Información y las Comunicaciones será la encargada de

identificar, entre la información más recurrente, su nivel de impacto, principalmente en
salud, educación, impuestos, movilidad, seguridad ciudadana, salud pública, atención y
reparación a las víctimas y ordenamiento territorial.

 El Grupo de Sistemas de Información, será el encargado de convertir estos componentes de

información en tablas dinámicas con formato de datos abiertos.

 Para todos estos procesos se realizara la validación del manejo adecuado de la información
confidencial.

De igual manera ha definido la necesidad de automatizar los procesos de extracción de los sistemas
de información fuente, para la generación y publicación de conjuntos de datos abiertos.

La primera actividad son las cargas de pruebas; que deben contribuir a ajustar los scripts y/o
programas de extracción y carga.

53
9. Interoperabilidad - LI.SIS.09
La Secretaria de las Tecnologías de la Información y las Comunicaciones de la Gobernación del
Valle del Cauca considera un componente importante dentro de la estrategia de un Valle del Cauca
Inteligente e Innovador, el lograr establecer esquemas para compartir su información haciendo uso
del Modelo de Interoperabilidad definido por el Estado Colombiano, a través de los lineamientos
del marco de referencia de Arquitectura Empresarial.

Como una de las desarrollar el plan de interoperabilidad se está desarrollando la tarea de consolidar
los catálogos regionales de servicios, sistemas de información y componentes de información. Es
de esta manera que mediante el Comité de Arquitectura Empresarial, El Comité TIC Departamental
y el Comité TIC Gobernación, se está trabajando en apoyar las entidades en esta construcción.
También se está apoyando la identificación de los flujos de información que deben quedar
registrados en el directorio de Componentes de información y a partir de allí detectar las
necesidades de intercambio de información con otras instituciones miembros de los comités en
referencia, y otras de carácter nacional.

Se encuentra en desarrollo el poder habilitar en los sistemas de información de la Gobernación del

Valle del Cauca, las características funcionales y no funcionales, necesarias para interactuar con la
Plataforma de Interoperabilidad del Estado colombiano. Como premisa se tiene que el intercambio
de información simple, eficiente y acorde a las necesidades de la Gobernación.

Esto se adelantara mediante la aplicación de las políticas, recomendaciones y los estándares

consignados en el Marco de Interoperabilidad para el gobierno digital. Para llevar eficientemente a
cabo este proceso la Gobernación del Valle del Cauca debe adaptar y modificar tanto sus procesos e
infraestructura tecnológica, así como la normatividad que la cobija. Uno de los factores críticos a
desarrollar es fortalecer la Seguridad de la Información de la Gobernación.

La interoperabilidad también implica una actuación de sensibilización en uso y apropiación con el

propósito de modificar las preconcepciones y por ende las prevenciones que tienen cada una de las
personas que interactúan con los Sistemas de Información de la Gobernación.

Para su marco de interoperabilidad se están desarrollando adaptaciones en 5 componentes:

Político-legal: Conjunto de políticas y normas que permiten el intercambio de información.

Sociocultural: Generación de competencias en las entidades para poder intercambiar información y

a la habilitación de medios para la colaboración entre entidades.

Organizacional: Modo en que las misiones, políticas, procesos de negocio y mecanismos de

prestación de estos procesos de una entidad interactúan con aquellos de otras entidades, a través del
intercambio de información.
54
 Semántico: Para garantizar que, en el momento de intercambiar datos, el significado de la
información es el mismo para todos los actores involucrados.

Técnico: Condiciones que se deben cumplir para conectar los sistemas de información con el
propósito de intercambiar información.

El nivele de madurez de interoperabilidad de la Gobernación del Valle del cauca es inicial. es decir
se cuenta con los elementos básicos para el diseño y la construcción de los esquemas de
interoperabilidad.

Con respecto al Marco de Interoperabilidad

Dominio Cumplimiento de Pautas

Inicial Básico Avanzado
Organizacional La Gobernación ha La Gobernación se La Gobernación en
designado un encuentra en proceso de encuentra en proceso de
responsable de la adecuar los procesos de desarrollar un modelo
gestión de los servicios negocio para la de mejoramiento
de intercambio de prestación o utilización continuo, que
información. de servicios de contemple la tendencia
intercambio de a aumentar los servicios
La Gobernación ha información. de intercambio de
identificado los información
procesos de negocio disponibles.
involucrados en la
prestación o utilización
de servicios de
intercambio de
información.

Se están desarrollando
los acuerdos de nivel de
asistencia para los
servicios de
intercambio de
información que
ofrecerá.

Político - Legal La Gobernación se Se está en proceso de Se tiene previsto el uso

encuentra en proceso desarrollar los de marcos legales
de afinar los mecanismos legales generales que
mecanismos legales para la prestación y posibilitan el uso y
necesarios para consumo de servicios consumo de servicios
habilitar el uso o de intercambio de de intercambio de

55
 prestación de los información. información.
servicios de
intercambio de
información
identificados.

La Gobernación ha
identificado la
competencia legal que
la habilita para la
prestación de servicios
de intercambio de
información.

Se esta adelantando el
proceso de identificar
la información de
carácter confidencial y
personal, asociada con
los servicios de
intercambio de
información que se
consumirán o prestarán,
y la forma en que será
protegida.
Semántico La Gobernación ha
identificado un grupo
de data-sets particulares
a los procesos de
negocio que hacen
parte de los servicios de
intercambio de
información que
prestará y consumirá.

Se encuentra en
proceso de revisión la
existencia de los
elementos de dato
necesarios en sus
procesos de negocio
dentro del lenguaje
común para el
intercambio de
información.

56
Técnico La Gobernación se
encuentra en proceso
de iniciar la adopción
de las recomendaciones
propuestas para el
diseño y construcción
de los servicios de
intercambio de
información definidos
en el Marco de
Interoperabilidad.
Socio-Cultural Se está estructurando
un plan para divulgar
los servicios de
intercambio de
información, necesarios
dentro de la ejecución
de sus procesos de
negocio.

Se reconoce el proceso
de mantenimiento del
Marco.

57
10. Implementación de Componentes de
información - LI.SIS.10
Durante la implementación de sus Sistemas de Información misional SAP en la Gobernación del
Valle del Cauca se detecto una necesidad común a todos sus módulos, y consistía en poder contar
con los datos necesarios para que el sistema funcionara adecuadamente al momento de salir en
vivo.

Lo anterior considerando que para ese momento la Gobernación contaba con sistemas totalmente
diferentes y con mínimas posibilidades de interacción para cubrir su operación.

Desde ese proceso se adoptaron enseñanzas y se de definió que:

 Sin los componentes de información adecuados ningún sistema puede operar correctamente,
por tanto el no contar con los datos necesarios y en el formato requerido en el momento
oportuno es vital.

 En la Gobernación del Valle del Cauca la responsabilidad de la preparación, revisión y

carga de los componentes de información corresponde al usuario definido por cada
dependencia, ya que es quien conoce realmente su operación.

 Durante la implementación de los Sistemas de Información de la Gobernación del Valle del

Cauca, se debe adelantar un plan de pruebas, en el cual deben participar y ejercer un rol, de
evaluación y generación de recomendaciones, los usuarios funcionales. Estas pruebas son
un requisito previo obligatorio a la salida en vivo. En razón de lo cual es necesario contar
con un conjunto de componentes de información cargados en los sistemas de pruebas.

 Criterios como: integridad, precisión, consistencia, unicidad y oportunidad, son claves para
la aprobación de los datos a ser cargados en el sistema destino. Para lograr esto se deben
definir herramientas de control de cada uno de estos elementos de calidad en los diferentes
momentos de extracción y carga de los datos.

La Gobernación del Valle del Cauca detecto que la metodología Accelerated SAP – ASAP, ofrecía
pautas y aceleradores (plantillas predefinidas) en cada una de las fases de los proyectos de
implementación de componentes de información.

Con respecto a la metodología SAP - ASAP, específicamente en la fase denominada Business

Blueprints se consideran sus tres etapas:

 Definición Blueprint
58
  QAD– B (Questions, Anwers Data base)

 Issue Database

SAP ha definido esta fase con la creación del blueprint. (como blueprint consideramos un artefacto
que permite tener una descripción detallada de cada etapa de la prestación de un servicio, tanto las
partes visibles como no visibles, el blueprint se enfoca más en los procesos y detalles que existen en
la prestación de un servicio).

Este bueprint tiene como propósito de ayudar a extraer información pertinente de la Gobernación,
necesaria para el proceso de implementación de los Sistemas de información y/o nuevos módulos.

Estos Blueprints son diseñados mediante de cuestionarios, y sirven para probar a través de la
información suministrada, la forma en que el negocio funciona. Este ejercicio tiene como beneficio
adicional el servir como la documentación de implementación del proyecto.

Cada documento generado por el blueprint esencialmente subrayará outlines los futuros procesos y
requerimientos de las dependencias de la Gobernación para su implementación. Las preguntas del
cuestionario están diseñadas de acuerdo al tipo de funcionalidad especifico de la dependencia.

El QADB (Questions and Answers Data Base), base de datos de preguntas y respuestas SAP: Es
una herramienta diseñada para facilitar la creación y el mantenimiento del Business Blueprint. Esta
base de datos almacena las preguntas y respuestas, tal como fueron planteadas por cada una de las
dependencias con respecto a su blue print.

Al usuario se le proveerá un input template para colectar la data en cada una de las aplicaciones a
implementar. El formato de las preguntas y respuestas son Standard a través de las diferentes
aplicaciones para facilitar de forma sencilla y más fácil su uso para el equipo de trabajo.

Otra herramienta utilizada para esta fase del Blueprint es el “Issues Databases” (asuntos o temas
relacionados con la base de datos). Esta base de datos almacena cualquier punto a considerar y
puntos pendientes relacionados con la implementación.

Almacenar esta información de manera centralizada ayudará a obtener y manejar asuntos o puntos
para su resolución, así, temas importantes que deberán ser abordados con prontitud y no queden al
margen. Luego se podrá dar un seguimiento por puntos o asuntos almacenados en la base de datos y
asignarlos a los miembros del equipo para su resolución, simultáneamente se actualizara la base de
datos a medida que se tomen las acciones pertinentes.

La Gobernación del valle del Cauca ha definido que desde el modelo de gestión del dato que tendrá
un grupo estandarizado de data sets que cumplirán con los estándares de calidad definidos por el
Ministerio de las Tecnologías de Información y las comunicaciones.

Si bien existen en el mercado diversas herramientas de perfilamiento y limpieza de datos que

59
pueden ser útiles, se considera que es clave poder contar como mínimo con una base de datos
intermedia entre los sistemas fuente y destino. En razón de lo anterior se usaran las herramientas
provistas por Oracle, como base de datos institucional.

60
11. Ambientes independientes en el ciclo de
vida de los sistemas de información - LI.SIS.11
La Secretaria de las Tecnologías de Información y las comunicaciones identifica y mantiene la
independencia de los ambientes requeridos durante el ciclo de vida de los sistemas de información.

Un ambiente refiere a hardware y software donde se ejecuta una aplicación. En la Gobernación del
Valle se han establecido tres ambientes por los cuales va evolucionando un Sistema de información,
desde el inicio de su desarrollo hasta su puesta producción.

Cada ambiente tiene su propia base de datos y su copia de los aplicativos de forma que no haya
interferencias entre los ambientes y entre los diferentes participantes en la construcción los
Sistemas de Información.

La gobernación ha definido que para cualquier proceso se deben mantener sus tres ambientes
independientes:

 Producción: Este entorno corresponde a un Cluster de servidores del Data Center de la

Gobernación, donde trabajan los usuarios finales y se trabaja con los datos reales.

 Pruebas: Pruebas es un entorno lo más idéntico posible al entorno de producción. El

propósito principal del entorno de pruebas es simular al entorno de producción con el fin de
testear las actualizaciones (en un entorno similar al de producción) para asegurar que las
mismas no corrompen la aplicación existente en los servidores en producción. De esta forma
se minimizan las caídas del sistema en producción. Además, este entorno puede funcionar
tanto como demo como para entrenamiento y capacitación de los usuarios.

 Desarrollo: Entorno de trabajo para desarrolladores individuales o pequeños equipos de

desarrolladores. Trabajando de forma aislada con el resto de las capas, los desarrolladores
pueden probar cambios radicales en el código sin afectar de forma adversa al resto del
equipo de desarrollo. Estos entornos están relacionados directamente en las estaciones de
trabajo de cada desarrollador.

Los desarrolladores de software escriben código en su entorno de desarrollo. Cuando los

desarrolladores están conformes con el comportamiento del entorno de integración (ha alcanzado
una cierta estabilidad), este se carga al ambiente de pruebas.

Una vez se ha producido la carga en el ambiente de pruebas, un perfil diferente, denominado tester
adelanta el plan de pruebas pruebas. Este plan se realiza bajo el protocolo de pruebas definido por
la Secretaria de las Tecnologías de Información y las comunicaciones. El grupo de testers está
conformado por otros desarrolladores y usuarios funcionales claves.

61
Los testers presentan sus informes con enfoque en el aseguramiento de calidad, en donde hacen
énfasis en documentar los errores y otros problemas no funcionales como son rendimiento. Este
informe es entregado a los desarrolladores para que realicen las correcciones pertinentes. Esta
interacción se realiza tantas veces como sea requerido.

Una vez se ha cumplido el protocolo de pruebas, y el grupo de tester no ha detectado errores, sobre
este ambiente de pruebas se adelanta el proceso de capacitación. En la Gobernación, este proceso
de capacitación corresponde una posibilidad adicional de verificar el adecuado funcionamiento del
Sistema de información.

El equipo de pruebas y de aseguramiento de la calidad, declara que la versión de prueba está lista
para ser liberada a producción. En la Gobernación, la persona que ejerce el rol de administrador de
entornos (llamado "release manager") aplica la versión de prueba en los servidores en producción.

Los sistemas de información en producción son monitoreados permanentemente, para consolidar

los reportes de errores y pedidos de nuevas características y funcionalidades. estos son remitidos al
grupo de desarrollo, quienes determinan si se requiere escribir nuevo código o ajustar el existente, y
es de esta manera que comienza nuevamente el ciclo para los ambientes desarrollo-prueba-
producción.

La Gobernación ha implementado procedimientos y políticas para evitar que los datos productivos
que son considerados confidenciales, sean utilizados en los demás ambientes. En este sentido se
adoptan componentes de información exclusivos para pruebas.

El trabajo en el entorno de desarrollo es altamente iterativo y se traslada frecuentemente al entorno

de pruebas. El traslado al entorno de testing se considera como una iteración o "sprint" (en
terminología de desarrollo ágil o "scrum").

Para mantener la integridad del repositorio de código fuente en ningún momento un desarrollador
debe realizar cambios directamente en los entornos de prueba o de producción.

62
12. Análisis de requerimientos de los sistemas
de información - LI.SIS.12
El análisis de requerimientos consiste en aplicar una serie de técnicas para desglosar y analizar los
requisitos y sus partes, algunas de estas técnicas son: Modelado de procesos, Modelado de dominio,
casos de uso, inspecciones, listas de chequeo y prototipos.

En la Gobernación del Valle del Cauca se ha definido que para analizar los requerimientos de los
sistemas de información, usara las 8 técnicas más comunes así:

 Descomposición funcional

o La descomposición funcional se refiere al proceso de identificar y resolver las

relaciones funcionales en sus partes constituyentes, de tal forma que la función
global pueda ser reconstruida a partir de sus partes.
o Por lo general, la descomposición funcional se realiza para identificar y entender los
componentes o partes que constituyen un todo (o función global).
o En este proceso, es vital identificar las interacciones entre componentes.
o Aplicado a la Ingeniería de requisitos, consiste en tomar los requerimientos de
software, dividirlos en partes y analizarlos individualmente.
o De ser necesario, los requerimientos de software se pueden descomponer en más
partes hasta lograr un nivel adecuado de detalle.
o El proceso es similar al de la elaboración de una estructura de desglose de trabajo de
un proyecto.
o En Ingeniería de sistemas, la descomposición funcional consiste en definir un
sistema en términos funcionales, para luego definir funciones de más bajo nivel y
establecer las relaciones con estas funciones de alto nivel.
o La intención es dividir un sistema de tal forma que cada componente se pueda
describir sin necesidad de referir a otro componente.
o De esta forma, cada parte del sistema tendrá funciones independientes, que pueden
reusarse y reemplazarse.

 Especificación vía Sentencias Textuales

o Es la forma tradicional de la especificación de requerimientos de los Sistemas de

Información.
o Se usan especificaciones textuales en lenguaje natural, que se documentan en
matrices de trazabilidad de requerimientos o definiciones del alcance.
o El procedimiento consiste en tomar el requerimiento producto del levantamiento de
información, para desarrollar una narrativa más detallada.
o No usa herramientas visuales como los flujo gramas o estructura como los casos de

63
 uso
o Corresponde a una descripción más detallada del requerimiento en lenguaje natural.

 Modelado del proceso

o Comprende la elaboración de diagramas de flujo de procesos (Flujo gramas) a partir

de los requerimientos del software.
o Existen diversas herramientas de modelado de procesos, cada una de las cuales
posee sus propios símbolos y reglas. La Gobernación se encuentra evaluando cual se
puede adoptar como estándar, tarea que debe concertar con los encargados de
adelantar el MIPG.
o Es muy útil para entender el trabajo realizado en múltiples pasos, tareas, roles y
departamentos intervinientes.
o Los procesos son iniciados por eventos y pueden abarcar actividades automatizadas,
manuales o combinación entre ambas.
o Su naturaleza visual ayuda a la comprensión y comunicación a terceros.
o Cuando los procesos son complejos, deben desglosarse en componentes
(subprocesos).
o La relación entre los diagramas de flujo y la gerencia de proyectos es fundamental
para el éxito.

 Modelo de dominio

o En Ingeniería de software, en análisis de dominio consiste en analizar sistemas o

software relacionados en un dominio, con la finalidad de encontrar sus partes
comunes y partes que los diferencian.
o Produce un modelo de contexto de negocio para todo el sistema.
o Un modelo de dominio comprende diagramas conceptuales que incluyen tanto el
comportamiento de un sistema como sus datos.
o Un tipo de modelo de dominio son los diagramas de funcionalidades (Features
Diagrams), que es una representación “compacta” del sistema o aplicación en
términos de sus características.
o El análisis de dominio produce modelos orientados a objetos o modelos relacionales
de datos, que pueden ser usados por los desarrolladores de software como base de
arquitecturas de software y aplicaciones.

 Casos de Uso

o En el ámbito académico y profesional, es una de las técnicas de mayor difusión para

especificar el comportamiento del Sistema.
o Formato simple y estructurado que puede ser compartido entre usuarios y
desarrolladores.
o Además de usarse para analizar los requerimientos de software, también pueden
usarse en el diseño del sistema e inclusive para definir pruebas de caja negra.
o Son útiles en sistemas informáticos orientados a la funcionalidad (transacciones con

64
 el usuario), que se van a implementar orientados a objetos y con UML.
o No son la mejor opción en sistemas sin usuarios, o dominados fundamentalmente
por requerimientos no funcionales.

 Checklists

o La lista de chequeo (Checklist) consiste en una serie de preguntas o revisiones que

se realizan sobre los requerimientos de software, que nos sean presentados de forma
escrita.
o Una lista de chequeo puede realizar preguntas como:
 ¿Se han especificado los requisitos de hardware y software?
 ¿Se han realizado consideraciones de seguridad?
 ¿El nivel de granularidad del requerimiento se ha incluido?
 ¿Se ha incluido el código de referencia en para identificar el requisito en el
desglose de requerimientos?
 ¿Está escrito el requerimiento en un lenguaje claro y conciso?
 ¿El requerimiento es único? (no existe duplicidad con otro requerimiento).
o La lista de chequeo sirve de marco de trabajo y procedimental para revisar el
requerimiento, facilitando su análisis de forma estructurada.
o Los requerimientos se pueden revisar sobre la matriz de trazabilidad de
requerimientos o sobre la definición del alcance.

 Inspección

o Revisión no destructiva de los requerimientos de software. Por ejemplo:

 Examinar un software visualmente para constatar que las pantallas
solicitadas se encuentran incluidas.
 Verificar la inclusión de los campos necesarios para el ingreso de datos.
 Verificar la existencia de los botones necesarios para iniciar la funcionalidad
que ha sido requerida.
 Verificar que el requerimiento se apega a los estándares definidos para la
aplicación. Por ejemplo estándares de navegación entre pantallas y
estándares de interfaz gráfica.
o De forma similar al uso de la lista de chequeo, la inspección consiste en tomar el
requerimiento definido en la matriz de trazabilidad o definición de alcance, leerlo y
producir un resultado para su corrección.

 Prototipos

o Consiste en elaborar representaciones visuales (interfaz gráfica con el usuario) de los

requerimientos de software.
o Es una herramienta muy útil para validar con los usuarios, clientes e interesados de
proyecto que el diseño funcional corresponde con los requerimientos de software
(Que existe entendimiento común entre desarrolladores de software y usuarios).
o Permite a desarrolladores y usuarios entender mejor los requerimientos, determinar

65
 cuáles son indispensables y cuales deseables, e identificar riesgos de forma
temprana.
o Puede enfocarse en toda la solución o sólo en áreas específicas.
o Puede extenderse innecesariamente en el tiempo si las discusiones se realizan en
torno al como en lugar de en torno al que.
o La elaboración de prototipos conlleva iteraciones entre desarrolladores y usuarios,
en los cuales se van elaborando varios prototipos y sometidos a evaluación del
cliente.

El proceso M11-P2 Inicia con la identificación de las necesidades de tecnologías de información y

comunicaciones TIC, en el Departamento del Valle del Cauca, garantizando los recursos mínimos
para mantener la operación existente, en el ámbito interno y externo y termina con el tratamiento a
las acciones correctivas, preventivas y de mejora, resultante de las evaluaciones y seguimiento.

Cuando se realiza un requerimiento y se desea adquirir una solución se debe tramitar el concepto
técnico para adquisición de bienes y servicios tecnológicos FO-M11-P1-01 que es:

Departamento del Código: FO-M11-

Valle del Cauca P1-01
CONCEPTO TECNICO PARA Versión: 01
ADQUISICION DE BIENES Y
SERVICIOS TECNOLOGICOS Fecha de
Aprobación:
24-ENE-2017
Gobernación Página:

Meta de Resultado:
Meta de Producto:
Nombre del proyecto:
Entidad que solicita:

66
 Gobernación Página:

Meta de Resultado:
Meta de Producto:
Nombre del proyecto:
Entidad que solicita:

Cumple con las

Ítem Componente y/o Elemento Cantidad especificaciones Observaciones
SI NO
1

CONCEPTO:

¿Es pertinente el desarrollo del proyecto en lo correspondiente a los aspectos tecnológicos? SI (X) - NO ( )

Concepto Realizado por: Concepto Revisado por:

Nombre: Firma: Nombre: Firma:

Cargo: Cargo:

Fecha: Fecha:

Concepto Aprobado por:

Nombre: Firma:
Cargo:
DD/MM/AAAA
Fecha:

67
13. Integración continua durante el ciclo de
vida de los sistemas de información - LI.SIS.13
La integración continua es una práctica de desarrollo de software mediante la cual los
desarrolladores combinan los cambios en el código en un repositorio central de forma periódica,
tras lo cual se ejecutan versiones y pruebas automáticas. La integración continua se refiere en su
mayoría a la fase de creación o integración del proceso de publicación de software y conlleva un
componente de automatización.

Era común que los desarrolladores de un equipo trabajasen aislados durante un largo periodo de
tiempo y solo intentasen combinar los cambios en la versión maestra una vez que habían
completado el trabajo, esto hacia que se acumularan errores y dificultara la integración. Para
superar esta dificultad y cumplir con este lineamiento, se ha definido que los miembros del equipo
de desarrollo de la Gobernación realicen reuniones para integrar su trabajo con una determinada
frecuencia.

La integración continua e incremental de los nuevos desarrollos, hace que la nueva funcionalidad
de un sistema de información, se pueda integra con el código vigente y esto se realiza en un
ambiente de pruebas.

El desarrollo continuo solo es posible debido a la integración y pruebas continuas. En este sentido
la Integración Continua requiere un Servidor y software de Integración Continua, que tiene como
punto de partida el tener un repositorio de código fuente.

Para esto se usa el ciclo de vida de software (ISO 25000 - ISO 12207), pero se desarrolla un plan
para adoptar las mejores prácticas definidas por el Ministerio de las Tecnologías de la Información
y las comunicaciones así:

 Mantener un único repositorio de código fuente.

 Automatizar la construcción del proyecto.

 Hacer el auto diagnóstico construcción.

 Entregar los cambios a la línea principal todos los días.

 Cada entrega a la línea principal debe ser construida.

 Mantener rápida la construcción del proyecto.

68
 Probar en una réplica del entorno de producción.

 Hacer que todo el mundo pueda obtener el último ejecutable de forma fácil.

 Todo el mundo puede ver los resultados de la compilación más reciente.

 Automatizar el despliegue.

69
14. Plan de pruebas durante el ciclo de vida de
los sistemas de información - LI.SIS.14
La secretaria de las Tecnologías de la Información y las Comunicaciones ha definido un plan de
pruebas que cobija todo el proceso de diseño y hace uso de los resultados para mejorar
constantemente.

Las pruebas se clasifican en dos categorías:

 Funcionales

 No funcionales

En razón de lo anterior, ha determinado que se deben realizar evaluaciones heurísticas previa, antes
de realizar una prueba con usuarios, para detectar los problemas de Usabilidad. Para este efecto se
ha definido como lineamientos los siguientes:

 El evaluador lleve a cabo una calificación del nivel de impacto que causa en el usuario cada
error hallado.

 Se considera fundamental la experiencia y conocimientos del profesional que realiza la

prueba.

 Que la evaluación sea realizada por un profesional garantiza hallar un mayor número de
fallas, y genera una evaluación confiable del impacto de cada error encontrado.

 Se califican la frecuencia con que aparecen los errores.

Una vez realizadas las pruebas heurísticas se realizan pruebas con los usuarios de tal manera que se
mejore la usabilidad. las pruebas con los usuarios consisten básicamente en solicitar a un usuario
que realice una tarea, o intente descifrar un sitio web, y observar su comportamiento.

Los datos recopilados de la observación de varios usuarios permiten medir en varios aspectos el
nivel de usabilidad y la experiencia que tienen los usuarios al interactuar con los aplicativos.

Las pruebas de usuario se realizan constantemente y durante todo el proceso de diseño y desarrollo.
Se tiene como premisa que los beneficios de las pruebas de usuario son mayores en las etapas
tempranas, sobre todo por la posibilidad de reducir costos en implementaciones fallidas.

En cada una de las pruebas se define:

70
  Alcance: Donde se define de manera inequívoca el alcance de la prueba.

 Elementos a ser probados que pueden ser entre otros:

o Módulos
o Casos de uso
o Funcionalidades

 Pruebas Incluidas: Corresponde a la descripción general de las pruebas obligatorias a ser

incluidas dentro del proceso de validación planeado.

 Pruebas no Incluidas: Corresponde a la descripción general de las pruebas no incluidas

dentro del proceso de validación planeado.

 Estrategia de pruebas
o Técnicas y tipos de pruebas
o Criterios de aceptación

 Criterios de entrada: Condiciones que deben estar dadas a nivel del sistema, y a nivel del
proyecto para que inicie el ciclo de pruebas.

 Criterios de salida: Condiciones que se deben presentar para dar por concluido el ciclo de
pruebas.

 Entregables del plan de pruebas.

 Necesidades de ambiente para realizar las pruebas.

 Recursos humanos involucrados, roles y responsabilidades.

 Indicadores de cantidad y severidad de defectos por:

o Estado
o Desarrollador
o Caso de Uso
o Errores reportados vs. solucionados
o Tiempo promedio de solución

La gobernación planea llevar a cabo una grabación de las pruebas, pues estas, facilitan mucho la
labor de análisis y permite al equipo revisar las pruebas una y otra vez para aprovechar los
hallazgos.

71
 15. Plan de capacitación y entrenamiento para
los sistemas de información - LI.SIS.15
La Secretaria de las Tecnologías de Información y las Comunicaciones ha definido los criterios
necesarios para asegurar la capacitación y entrenamiento.

15.1 Objetivo
El objetivo general del plan de capacitación:

Desarrollar habilidades de uso crítico de los Sistemas de Información de la Gobernación del Valle
del Cauca, a partir del manejo correcto de los módulos y recursos de información, como apoyo al
proceso misional inherente a cada dependencia.

Los objetivos específicos incluyen:

 Proporcionar información de calidad al usuario

 Identificar las diversas alternativas para usar los módulos de los Sistemas de Información de
manera efectiva y eficaz

 Resolver necesidades de información especializada a los usuarios de un modulo de un

Sistema de Información.

 Desarrollar en los usuarios habilidades de recuperación de incidentes como malas entradas

o posibles fallas.

 Optimizar el conocimiento respectos a los diferentes recursos operativos que están al

alcance de los usuarios de los Sistemas de Información.

 Difundir los beneficios de apoyo a las labores de las decencias logradas con el uso
apropiado de los Sistemas de Información.

 Utilizar la documentación, como proceso de apoyo al aprendizaje de los Sistemas de

información.

72
15.2 Metas de Aprendizaje
Las Metas de aprendizaje que se pretenda cumplan los usuarios de los Sistemas de Información en
la Gobernación del Valle incluyen:

 Identificación de manera efectiva las diferentes funcionalidades de los Sistemas de

Información que apoyan a la labor administrativa y misional de las dependencias.

 Ampliará los conocimientos de los usuarios en el ámbito de recursos de los Sistemas de

Información para un mayor aprovechamiento de estos.

 Promover la adopción de nuevas herramientas de trabajo para brindar servicios de

información ágiles y efectivos.

15.3 Competencias

Las competencias que se esperan desarrollar en el personal de la Gobernación incluyen:

 Agilidad en la orientación al usuario para la solución de necesidades relacionadas con el uso

de los Sistemas de Información.

 Habilidad en la utilización general de las tecnologías de información y las comunicaciones.

 Capacidad de adquirir recursos relevantes de información desde cualquier sistema de

información, identificando los recursos o fuente de información disponibles en la
Gobernación.

15.4 Control de Asistencia

La gobernación del Valle del Cauca ha adoptado como artefacto para verificar la participación en
las capacitaciones la que se encuentra definida en el Modelo Integrado de Planeación y Gestión, y
que es común a toda la entidad.

Pero adicionalmente la participación se vera motivada dentro de la estrategia integral de uso y

apropiación definida en el respectivo dominio. La Secretaria de las tecnologías de información y las
comunicaciones, implementara estrategias disruptivas, como las definas como "Del Oro Olímpico
al Oro Empresarial".

73
 16. Manual del usuario, técnico y de operación
de los sistemas de información - LI.SIS.16
Para cada Sistema de Información de la Gobernación del Valle del Cauca se ha establecido en su
manual general de políticas, numeral 6, la obligatoriedad de contar con un catalogo de manuales
así:

16.1 Manual de usuario

La Secretaria de las Tecnologías de Información y las Comunicaciones tiene como premisa que el
Manual de usuario se encuentre en línea. Es así, que se tiende a que se encuentre integrado con la
aplicación, de tal manera que los usuarios puedan tener un acceso rápido y eficiente a información
de ayuda en cualquier momento. El manual incluye como mínimo:

 Nombre del sistema

 Objetivo

 Requerimientos de hardware

 Requerimientos de software

 Descripción de menús

 Descripción y explicación de pantallas

 Guía para la solución de problemas

16.2 Manual técnico

La Secretaria de las Tecnologías de Información y las Comunicaciones tiene como premisa que el
Manual integre como mínimo:

 Índice

 Nombre del Sistema

 Pre-requisitos: Pre-requisitos de instalación del sistema: Sistema operativo de los servidores

74
 de aplicaciones y base de datos, marca y versión de la base de datos, marca y versión de los
servidores de aplicaciones, navegador, configuraciones de seguridad, etc

 Diagrama Conceptual

 Relación de Menús

 Frameworks y estándares: Nombres y versiones de los frameworks y estándares bajo los

cuales está construido el sistema.

 Descripción de tablas e índices

 Relación de reportes

 Diagramas de casos de uso del sistema.

 Modelo entidad relación del sistema.

 Diccionario de datos del sistema.

 Scripts de instalación del sistema.

 Diagrama de componentes del sistema.

 Diagrama de servicios expuestos por el sistema.

 Diagrama de despliegue del sistema.

 Diagrama de las clases más relevantes del sistema.

75
 17. Gestión de cambios de los sistemas de
información - LI.SIS.17.
Para solicitar los cambios se ha establecido el formato FO-M11-P2-15, a través del cual se realizan
las respectivas validaciones, y es el punto de partida para disparatar los procesos así:

Departamento del Valle Código: FO-M11-P2-05

del Cauca CREACION Y Versión: 02
MOVIMIENTO DE Fecha de Aprobación:
USUARIOS EN SAP Y 31 de Mayo de 2107
OTROS SISTEMAS DE
INFORMACION
Página: 76 de 1
Gobernación
MARCAR SOLO UNA OPCIÓN
Fecha: Crear:  Retirar:  Activar: 
Datos Personales
Nombre(s) y Apellido(s):
Cargo:
Cédula: Secretaría:
Tipo de vinculación: Desde: Hasta:
Oficina: Piso: Teléfono:
Extensión: Firma Funcionario:

Cuenta de Usuario:
Nombre del Jefe inmediato: Firma:

Nombre Líder Mesa de Servicios: Firma:

Tiene
Sistema de Información y/o aplicativo:
Capacitación? (S/N) :
Rol(es):

76
Transacción(es) y/o
Funcionalidades:

Parametrizador  Desarrollador  Usuario  Consultor Otro

Especifique:
Cliente / Mandante :
VAD VAQ VAP
  
Aprobado Por: Firma:

Aplicado por: Firma:

observaciones:

Una vez registrada la petición e identificado el tipo de mantenimiento y su origen, se

determina de quién es la responsabilidad de atender la petición.

En caso de que la petición sea aprobada, se registra en el catálogo de peticiones de

mantenimiento y continua el proceso. La petición puede ser denegada. En este caso, se
notifica al usuario y acaba el proceso.

Según se trate de un mantenimiento correctivo o evolutivo, se verifica y reproduce el

problema, o se estudia la viabilidad del cambio propuesto por el usuario. En ambos casos
se estudia el alcance de la modificación. Hay que analizar las alternativas de solución
identificando, según el tipo de mantenimiento de que se trate, cuál es la más adecuada.
El plazo y urgencia de la solución a la petición se establece de acuerdo con el estudio
anterior.

L a solución incluye el estudio del impacto de la solución propuesta para la petición en los
sistemas de información afectados. Mediante el análisis de dicho estudio, la persona
encargada del Proceso de Mantenimiento valora el esfuerzo y coste necesario para la
implementación de la modificación.

77
18. Estrategia de mantenimiento de los sistemas
de información - LI.SIS.18.
El punto de partida para determinar la estrategia de mantenimiento de los sistemas de información,
son las peticiones de mantenimiento que los usuarios realizan con motivo de un problema detectado
en el sistema, o por la necesidad de una mejora del mismo.

A partir de las peticiones se generan los datos estadísticos donde se realiza un análisis comparativo
entre;

 Peticiones recibidas Vs. atendidas en un determinado periodo

 Sistemas de Información que se han visto afectados por los cambios

 Nivel de severidad de los cambios en un Sistema de Información

 Tiempo promedio empleado en la resolución de cambios

Atendiendo a los fines, la Secretaria de las Tecnología de Información y las comunicaciones ha

establecido las siguientes categorías de mantenimiento:

 Correctivo: son aquellos cambios precisos para corregir errores de un Sistema de

Información.

 Evolutivo: son las incorporaciones, modificaciones y eliminaciones necesarias en un

Sistema de Información para cubrir la expansión o cambio en las necesidades del usuario.

 Adaptativo: son las modificaciones que afectan a los entornos en los que el Sistema de
Información opera, por ejemplo, cambios de configuración del hardware, software de base,
gestores de base de datos, comunicaciones, etc.

 Perfectivo: son las acciones llevadas a cabo para mejorar la calidad interna de los sistemas
de Información en cualquiera de sus aspectos: reestructuración del código, definición más
clara del sistema y optimización del rendimiento y eficiencia.

78
19. Servicios de mantenimiento de sistemas de
información con terceras partes - LI.SIS.19
La Secretaria de las Tecnologías de la Información y las Comunicaciones de la Gobernación del
Valle del cauca ha establecido los criterios de aceptación y ha definido los Acuerdos de Nivel de
Servicio (ANS) en los proyectos en los que terceros son los encargados del mantenimiento de los
sistemas de información.

En la Gobernación del Valle del Cauca se promueve el establecer un plan periódico de pruebas de
Sistemas de Información que son definidos con terceros. Las pruebas de aceptación son definidas
entre la Secretaria de las Tecnologías de Información y las Comunicaciones y el usuario del sistema
y supervisadas por el equipo de desarrollo. La aprobación final corresponden al usuario del Sistema
de Información.

Estas pruebas van dirigidas a comprobar que el sistema cumple los requisitos de funcionamiento
esperado, que se encuentran definidos como requisitos contractuales y en que se plasman como
criterios de aceptación del sistema de información, y conseguir as la aceptación final del sistema
por parte de la Gobernación.

El responsable de usuarios debe revisar los criterios de aceptación que se especificaron previamente
en el plan de pruebas del sistema y, posteriormente, dirigir las pruebas de aceptación final.

La validación del sistema se consigue mediante la realización de pruebas de caja blanca y negra que
demuestran la conformidad con los requisitos y que se recogen en el plan de pruebas, las cuales
definen las verificaciones a realizar y los casos de prueba asociados.

El plan est diseñado para asegurar que se satisfacen todos los requisitos funcionales especificados
por el usuario teniendo en cuenta también los requisitos no funcionales relacionados con el
rendimiento, seguridad de acceso al sistema, a los datos y procesos, as como a los distintos
recursos del sistema.

La formalidad de estas pruebas depende en mayor o menor medida de cada dependencia , y estará
definida por la criticidad del sistema, el número de usuarios implicados en las mismas y el tiempo
del que se disponga para llevarlas cabo, entre otros.

Entre los artefactos que se encuentran en construcción por parte de la Secretaria de las Tecnología
de la Información y las comunicaciones se incluye:

79
 Documentos con las características de los sistemas cuyo mantenimiento es subcontratado a
terceros. Incluir la interacción del sistema con otros sistemas y su infraestructura TI.

 Descripción de las características del servicio que debe ser ofrecido por los contratistas.
o Equipo y roles del equipo del contratista.
o Recursos requeridos para la prestación del servicio.
o Responsabilidades del contratista.
o Disponibilidad del servicio y horarios de prestación del mismo.
o Indicadores y niveles de calidad del servicio.
o Tiempo y cronograma de prestación del servicio.
o Procedimientos para transferencia de conocimiento a la entidad o a otro contratista.

 Indicadores de desempeño del servicio prestado con la siguiente información por indicador:
o Indicador.
o Descripción del indicador.
o Valor del indicador.
o Nivel de servicio objetivo.

 Reglas para determinar el cumplimiento del ANS pactado con el contratista y fórmulas para
realizar deducciones al contratista.

 Lista de situaciones no atribuibles al contratista, y que lo eximen del cumplimiento de los

indicadores de servicio.

80
 20. Plan de calidad de los sistemas de
información - LI.SIS.20
Calidad de los Sistemas Información, incluye el conjunto de cualidades que lo caracterizan y que
determinan su utilidad y existencia, la cual plantea un adecuado balanceo de eficiencia,
confiabilidad, facilidad de mantenimiento, portabilidad, facilidad de uso, seguridad e integridad.

La Secretaria de las Tecnologías de la Información y las Comunicaciones, asume que la calidad

debe estar presente en todas las etapas del proceso de desarrollo:

 Calidad en el diseño: El control de la calidad en el diseño, se logra mediante la ejecución de

frecuentes inspecciones a las metodologías de trabajo y al uso de las herramientas.

 Calidad en la implementación: Incluye revisiones de prototipos y de las pruebas formales

de los productos finales.

 Calidad en la satisfacción: La calidad en la satisfacción es la perspectiva del usuario desde

un ambiente y contexto específico, esta mide la extensión en la cual los usuarios pueden
conseguir sus metas en un ambiente particular.

20.1 ISO 25000

La Secretaria de las tecnologías de Información y las Comunicaciones adopta la aplicación parcial
de la Norma ISO/IEC 25000, conocida como SQuaRE (System and Software Quality
Requirements and Evaluation), que es una familia de normas que tiene por objetivo la creación de
un marco de trabajo común para evaluar la calidad del producto software.

La familia ISO/IEC 25000 es el resultado de la evolución de otras normas anteriores, especialmente

de las normas ISO/IEC 9126, que describe las particularidades de un modelo de calidad del
producto software, e ISO/IEC 14598, que abordaba el proceso de evaluación de productos software.

81
20.1.1 ISO/IEC 2500n – División de Gestión de Calidad
Las normas que forman este apartado definen todos los modelos, términos y definiciones comunes
referenciados por todas las otras normas de la familia 25000. Actualmente esta división se
encuentra formada por:

 ISO/IEC 25000 - Guide to SQuaRE: contiene el modelo de la arquitectura de SQuaRE, la

terminología de la familia, un resumen de las partes, los usuarios previstos y las partes
asociadas, así como los modelos de referencia.

 ISO/IEC 25001 - Planning and Management: establece los requisitos y orientaciones para
gestionar la evaluación y especificación de los requisitos del producto software.

20.1.2 ISO/IEC 2501n – División de Modelo de Calidad

Las normas de este apartado presentan modelos de calidad detallados incluyendo características
para calidad interna, externa y en uso del producto software.

El modelo de calidad representa el foco central en torno a la cual se establece el sistema para la
evaluación de la calidad del producto. En este modelo se determinan las características de calidad
que se van a tener en cuenta a la hora de evaluar las propiedades de un producto software
determinado.

La calidad del producto software se puede interpretar como el grado en que dicho producto
satisface los requisitos de sus usuarios aportando de esta manera un valor. Son precisamente estos
requisitos (funcionalidad, rendimiento, seguridad, mantenibilidad, etc.) los que se encuentran
representados en el modelo de calidad, el cual categoriza la calidad del producto en características y
sub-características.
82
El modelo de calidad del producto definido por la ISO/IEC 25010 se encuentra compuesto por las
ocho características de calidad así:

 Adecuación Funcional: Representa la capacidad del producto software para proporcionar

funciones que satisfacen las necesidades declaradas e implícitas, cuando el producto se usa
en las condiciones especificadas. Esta característica se subdivide a su vez en las siguientes
sub-características:
o Completitud funcional. Grado en el cual el conjunto de funcionalidades cubre todas
las tareas y los objetivos del usuario especificados.
o Corrección funcional. Capacidad del producto o sistema para proveer resultados
correctos con el nivel de precisión requerido.
o Pertinencia funcional. Capacidad del producto software para proporcionar un
conjunto apropiado de funciones para tareas y objetivos de usuario especificados.

 Eficiencia de desempeño: Esta característica representa el desempeño relativo a la cantidad

de recursos utilizados bajo determinadas condiciones. Esta característica se subdivide a su
vez en las siguientes sub-características:
o Comportamiento temporal. Los tiempos de respuesta y procesamiento y los ratios de
throughput de un sistema cuando lleva a cabo sus funciones bajo condiciones
determinadas en relación con un banco de pruebas (benchmark) establecido.
o Utilización de recursos. Las cantidades y tipos de recursos utilizados cuando el
software lleva a cabo su función bajo condiciones determinadas.
o Capacidad. Grado en que los límites máximos de un parámetro de un producto o
sistema software cumplen con los requisitos.

 Compatibilidad: Capacidad de dos o más sistemas o componentes para intercambiar

información y/o llevar a cabo sus funciones requeridas cuando comparten el mismo entorno
hardware o software. Esta característica se subdivide a su vez en las siguientes sub-
características:
o Coexistencia. Capacidad del producto para coexistir con otro software
independiente, en un entorno común, compartiendo recursos comunes sin
detrimento.
o Interoperabilidad. Capacidad de dos o más sistemas o componentes para
intercambiar información y utilizar la información intercambiada.

 Usabilidad: Capacidad del producto software para ser entendido, aprendido, usado y resultar
atractivo para el usuario, cuando se usa bajo determinadas condiciones. Esta característica
se subdivide a su vez en las siguientes sub-características:
o Capacidad para reconocer su adecuación. Capacidad del producto que permite al
usuario entender si el software es adecuado para sus necesidades.
o Capacidad de aprendizaje. Capacidad del producto que permite al usuario aprender
su aplicación.
o Capacidad para ser usado. Capacidad del producto que permite al usuario operarlo y
controlarlo con facilidad.

83
 o Protección contra errores de usuario. Capacidad del sistema para proteger a los
usuarios de hacer errores.
o Estética de la interfaz de usuario. Capacidad de la interfaz de usuario de agradar y
satisfacer la interacción con el usuario.
o Accesibilidad. Capacidad del producto que permite que sea utilizado por usuarios
con determinadas características y discapacidades.

 Fiabilidad: Capacidad de un sistema o componente para desempeñar las funciones

especificadas, cuando se usa bajo unas condiciones y periodo de tiempo determinados. Esta
característica se subdivide a su vez en las siguientes subcaracterísticas:
o Madurez. Capacidad del sistema para satisfacer las necesidades de fiabilidad en
condiciones normales.
o Disponibilidad. Capacidad del sistema o componente de estar operativo y accesible
para su uso cuando se requiere.
o Tolerancia a fallos. Capacidad del sistema o componente para operar según lo
previsto en presencia de fallos hardware o software.
o Capacidad de recuperación. Capacidad del producto software para recuperar los
datos directamente afectados y restablecer el estado deseado del sistema en caso de
interrupción o fallo.

 Seguridad: Capacidad de protección de la información y los datos de manera que personas o

sistemas no autorizados no puedan leerlos o modificarlos. Esta característica se subdivide a
su vez en las siguientes sub-características:
o Confidencialidad. Capacidad de protección contra el acceso de datos e información
no autorizados, ya sea accidental o deliberadamente.
o Integridad. Capacidad del sistema o componente para prevenir accesos o
modificaciones no autorizados a datos o programas de ordenador.
o No repudio. Capacidad de demostrar las acciones o eventos que han tenido lugar, de
manera que dichas acciones o eventos no puedan ser repudiados posteriormente.
o Responsabilidad. Capacidad de rastrear de forma inequívoca las acciones de una
entidad.
o Autenticidad. Capacidad de demostrar la identidad de un sujeto o un recurso.

 Mantenibilidad: Esta característica representa la capacidad del producto software para ser
modificado efectiva y eficientemente, debido a necesidades evolutivas, correctivas o
perfectivas. Esta característica se subdivide a su vez en las siguientes sub-características:
o Modularidad. Capacidad de un sistema o programa de ordenador (compuesto de
componentes discretos) que permite que un cambio en un componente tenga un
impacto mínimo en los demás.
o Reusabilidad. Capacidad de un activo que permite que sea utilizado en más de un
sistema software o en la construcción de otros activos.
o Analizabilidad. Facilidad con la que se puede evaluar el impacto de un determinado
cambio sobre el resto del software, diagnosticar las deficiencias o causas de fallos en
el software, o identificar las partes a modificar.
o Capacidad para ser modificado. Capacidad del producto que permite que sea

84
 modificado de forma efectiva y eficiente sin introducir defectos o degradar el
desempeño.
o Capacidad para ser probado. Facilidad con la que se pueden establecer criterios de
prueba para un sistema o componente y con la que se pueden llevar a cabo las
pruebas para determinar si se cumplen dichos criterios.

 Portabilidad: Capacidad del producto o componente de ser transferido de forma efectiva y

eficiente de un entorno hardware, software, operacional o de utilización a otro. Esta
característica se subdivide a su vez en las siguientes sub-características:
o Adaptabilidad. Capacidad del producto que le permite ser adaptado de forma
efectiva y eficiente a diferentes entornos determinados de hardware, software,
operacionales o de uso.
o Capacidad para ser instalado. Facilidad con la que el producto se puede instalar y/o
desinstalar de forma exitosa en un determinado entorno.
o Capacidad para ser reemplazado. Capacidad del producto para ser utilizado en lugar
de otro producto software determinado con el mismo propósito y en el mismo
entorno.

Actualmente esta división se encuentra formada por:

 ISO/IEC 25010 - System and software quality models: describe el modelo de calidad para el
producto software y para la calidad en uso. Esta Norma presenta las características y
subcaracterísticas de calidad frente a las cuales evaluar el producto software.

 ISO/IEC 25012 - Data Quality model: define un modelo general para la calidad de los datos,
aplicable a aquellos datos que se encuentran almacenados de manera estructurada y forman
parte de un Sistema de Información.

20.1.3 ISO/IEC 2502n – División de Medición de Calidad

Con el fin de poder tener un plan de calidad en los sistemas de información, se considera necesario
el tener un modelo que habilite la medición en la gestión y el aseguramiento de la calidad del
software. Se establece una línea base para la estimación y a partir de esta de definen las métricas
proporcionan una indicación de cómo se ajusta un Sistema de Información a los requisitos
implícitos y explícitos de los usuarios.

Entre los aspectos a medir incluyen:

 El costo de los diferentes procesos involucrados en la producción de Sistemas de

Información. Para este aspecto se considera como procesos las actividades relacionada con
la producción de Sistemas de Información y que normalmente conllevan el factor tiempo.
Los atributos internos a medir son el tiempo, esfuerzo, número de incidentes de un tipo
específico que se dan durante el proceso.

85
  La productividad de los desarrolladores.

 Los beneficios en términos de productividad y calidad.

 La calidad de la evolución de los sistemas a través de la medición de los procesos. Esto

incluye los cambios hechos durante el diseño, o los errores detectados durante las fases de
prueba.

 Atributos de proceso y producto para certificación. Entre los atributos se consideraran

fiabilidad del código, la entendibilidad de un documento de especificación y la
mantenibilidad del código fuente.

Actualmente esta división se encuentra formada por:

 ISO/IEC 25020 - Measurement reference model and guide: presenta una explicación
introductoria y un modelo de referencia común a los elementos de medición de la calidad.
También proporciona una guía para que los usuarios seleccionen o desarrollen y apliquen
medidas propuestas por normas ISO.

 ISO/IEC 25021 - Quality measure elements: define y especifica un conjunto recomendado

de métricas base y derivadas que puedan ser usadas a lo largo de todo el ciclo de vida del
desarrollo software.

 ISO/IEC 25022 - Measurement of quality in use: define específicamente las métricas para
realizar la medición de la calidad en uso del producto.

 ISO/IEC 25023 - Measurement of system and software product quality: define

específicamente las métricas para realizar la medición de la calidad de productos y sistemas
software.

 ISO/IEC 25024 - Measurement of data quality: define específicamente las métricas para
realizar la medición de la calidad de datos.

20.1.4 ISO/IEC 2503n – División de Requisitos de Calidad

Las normas que forman este apartado ayudan a especificar requisitos de calidad que pueden ser
utilizados en el proceso de transmisión adecuada de requisitos de calidad del producto software a
desarrollar o como entrada del proceso de evaluación. Para ello, este apartado se compone de:

 ISO/IEC 25030 - Quality requirements: provee de un conjunto de recomendaciones para

realizar la especificación de los requisitos de calidad del producto software.

86
20.1.5 ISO/IEC 2504n – División de Evaluación de Calidad
Este apartado incluye normas que proporcionan requisitos, recomendaciones y guías para llevar a
cabo el proceso de evaluación del producto software. Esta división se encuentra formada por:

 ISO/IEC 25040 - Evaluation reference model and guide: propone un modelo de referencia
general para la evaluación, que considera las entradas al proceso de evaluación, las
restricciones y los recursos necesarios para obtener las correspondientes salidas.

 ISO/IEC 25041 - Evaluation guide for developers, acquirers and independent evaluators:
describe los requisitos y recomendaciones para la implementación práctica de la evaluación
del producto software desde el punto de vista de los desarrolladores, de los adquirentes y de
los evaluadores independientes.

 ISO/IEC 25042 - Evaluation modules: define lo que la Norma considera un módulo de

evaluación y la documentación, estructura y contenido que se debe utilizar a la hora de
definir uno de estos módulos.

 ISO/IEC 25045 - Evaluation module for recoverability: define un módulo para la evaluación
de la subcaracterística Recuperabilidad (Recoverability).

La división de extensión de SQuaRE (ISO/IEC 25050 a ISO/IEC 25099) se reserva para normas o
informes técnicos que aborden dominios de aplicación específicos o que puedan ser utilizados para
complementar otras normas de la familia SQuaRE.

87
21. Criterios no funcionales y de calidad de los
sistemas de información - LI.SIS.21
La Secretaria de las Tecnologías de Información y las Comunicaciones tiene en cuenta los
requerimientos de la institución, las restricciones funcionales y técnicas, y los atributos de calidad,
y en ese sentido para criterios no funcionales adopta la Norma ISO 25000.

Con el fin de hacer la adecuada diferenciación consideramos los requerimientos no funcionales

como aquellos que especifican criterios para evaluar la operación de un servicio de tecnología de
información, en contraste con los requerimientos funcionales que especifican los comportamientos
específicos.

La Secretaria de las tecnologías de Información y las comunicaciones ha definido como sus

criterios no funcionales prioritarios los siguientes:

 Comprobabilidad: Grado en que un Sistema de Información permite y facilita que sea

probado en un determinado contexto. Esto incluye la factibilidad de realizar pruebas de
carga y stress, pruebas de caja negra no funcionales y de caja blanca centrados en seguridad.

 Disponibilidad: Corresponde al tiempo total en que un sistema puede ser usado en un

período determinado. También puede definirse el grado en que un sistema está en un estado
operable definido cada vez que se necesite.

 Extensibilidad: Grado en que la implementación del sistema toma en consideración y

facilita su crecimiento en el futuro.

 Escalabilidad: Capacidad de un sistema o servicio de TI de manejar una creciente carga de

trabajo, por ejemplo mayor número de conexiones o usuarios. No debe confundirse con
extensibilidad, que mide la capacidad del sistema de crecer en funcionalidades.

 Mantenibilidad: Mide la facilidad con que puede darse mantenimiento al producto (en este
caso al software o servicio de TI), con la finalidad de: Desarrollar nuevos requerimientos,
Aislar los defectos y sus causas, corregir estos defectos y atender las demandas del entorno
cambiante.

 Seguridad: Grado de protección de los datos, software y plataforma de tecnología de

posibles pérdidas, actividades no permitidas o uso para propósitos no establecidos
previamente, incluye los análisis de vulnerabilidad y pruebas tipo analsisi de penetracion
(Ethical hacking) caja blanca, caja negra y caja gris, tal y como se encuentran definidas en
la Guía MSPI del Ministerio de las Tecnologías de Información y las Comunicaciones.

88
 Usabilidad: Definido como la facilidad de uso y aprendizaje de un Sistema, Software o
Servicio de Tecnología de Información.

89
22. Seguridad y privacidad de los sistemas de
información - LI.SIS.22
Con respecto a la seguridad y privacidad de los sistemas de Información la Secretaria de las
Tecnologías de la Información y las Comunicaciones adopta las normas ISO 27001 e ISO 25000,
considerando como definición aplicable que la la seguridad y privacidad de los Sistemas de
Información corresponde a la capacidad de protección de la información y los datos de manera que
personas o sistemas no autorizados no puedan leerlos o modificarlos.

Se contemplan las características de:

 Confidencialidad. Capacidad de protección contra el acceso de datos e información no

autorizados, ya sea accidental o deliberadamente.

 Integridad. Capacidad del sistema o componente para prevenir accesos o modificaciones no

autorizados a datos o programas de ordenador.

 No repudio. Capacidad de demostrar las acciones o eventos que han tenido lugar, de manera
que dichas acciones o eventos no puedan ser repudiados posteriormente.

 Responsabilidad. Capacidad de rastrear de forma inequívoca las acciones de una entidad.

 Autenticidad. Capacidad de demostrar la identidad de un sujeto o un recurso.

Uno de los aspectos a considerar es la criticidad del maestro en SAP de tal manera que este requiere
ser resguardarlo y monitorearlo en forma continua, tanto en los ambientes de desarrollo como de
producción.

Para esta la Secretaria de las Tecnologías de la Información y las comunicaciones se apoya en

solución SAP-GRC (Governance, risk and compliance) que tiene como propósito el brindar
seguridad lógica al negocio y prevenir ataques desde el interior de la organización.

También se considera la auditoría de código a través de ABAP (Advanced business application

programming) que previene la aparición de ataques desde las etapas de desarrollo.

Se tiene estipulado que si se requiere la creación o movimiento de usuarios en SAP y otros

sistemas de información se debe entregar en los formatos para ellos definidos en el MIPG.

90
 22.1 Creación y movimiento de usuarios

Con el fin de realizar la creación y movimiento de usuarios en los sistemas de información se debe
tramitar el formato FO-M11-P2-05 así:

Departamento del Valle Código: FO-M11-P2-05

del Cauca CREACION Y Versión: 02
MOVIMIENTO DE Fecha de Aprobación:
USUARIOS EN SAP Y 31 de Mayo de 2107
OTROS SISTEMAS DE
INFORMACION
Página: 91 de 1
Gobernación
MARCAR SOLO UNA OPCIÓN
Fecha: Crear:  Retirar:  Activar: 
Datos Personales
Nombre(s) y Apellido(s):
Cargo:
Cédula: Secretaría:
Tipo de vinculación: Desde: Hasta:
Oficina: Piso: Teléfono:
Extensión: Firma Funcionario:

Cuenta de Usuario:
Nombre del Jefe inmediato: Firma:

Nombre Líder Mesa de Servicios: Firma:

Tiene
Sistema de Información y/o aplicativo:
Capacitación? (S/N) :
Rol(es):

Transacción(es) y/o
Funcionalidades:

Parametrizador  Desarrollador  Usuario  Consultor Otro

Especifique:
Cliente / Mandante :
VAD VAQ VAP
  
91
Aprobado Por: Firma:

Aplicado por: Firma:

observaciones:

22.2 Solicitud de Transporte

Con el fin de realizar que por razones de actualización de hardware se requiera actualizar un acceso
a los Sistemas de Información se debe diligenciar el formato FO-M11-P2-09 así:

Departamento del Valle del Código: FO-M11-P2-09

Cauca Versión: 01
Fecha de Aprobación: 24-01-
SOLICITUD DE
2017
TRANSPORTE,
SISTEMA FINANCIERO
– SGFT - SAP Página: 92 de 1

Gobernación

SOLICITANTE: FECHA:

MAQUINA
MAQUINA FUENTE: DESTINO:

# SOLICITUD DE CAMBIO TIPO DE

 PARAMETRIZACION CAMBIO AL
 DESARROLLO CLIENTE

DEPENDIENTE

INDEPENDIENT
E

NOMBRE Y DESCRIPCION:

LIBERADO POR: Firma:

92
 APROBADO POR: Firma:

PARA USO DEL GRUPO IT

FECHA:
IMPORTADO POR:

 0 TRANSPORTE SATISFACTORIO.
CODIGO DE RETORNO  4 MENSAJES DE ALARMA.
DEL LOG DE TRANSPORTE  8 MENSAJES DE ERROR.
 12 ERROR EN EL PROCESO.

COMENTARIOS:

ELABORÓ REVISÓ APROBÓ

Nombre: Gloria Nombre: Frank Comité Coordinador del
Esperanza Osorio L. Alexander Ramírez Sistema Integrado de Gestión –
Ordoñez SIG
Cargo: Subdirectora Cargo: Secretario TIC.
técnica y de apoyo a la Acta No. 1
gestión
Firma: Firma:

Fecha: 24/01/2017 Fecha: 24/01/2017 Fecha: 24/01/2017

22.3 Desbloqueo o Cambio de Claves

Cuando por cualquier motivo un usuario tenga inconvenientes con su clave de acceso a los
Sistemas de Información, y esta daba ser restablecida, se debe diligenciar el formato FO-M11-P2-
12 así:

Departamento del Valle del DESBLOQUEO Y/O Código: FO-M11-P2-12

93
 Cauca INICIALIZACION DE CLAVE Versión: 02
DE USUARIO EN SAP Y Fecha de Aprobación:
OTROS SISTEMAS DE 31 de Mayo de 2107
INFORMACION

Página: 94 de 1
Gobernación

MARCAR OPCIÓN
Fecha: Desbloquear:  Inicializar: 
Datos Personales
Apellido(s):
Nombre(s):
Secretaría: Oficina:
Tipo de vinculación: Desde: Hasta:
Piso: Teléfono: Extensión:
Sistema de información:
Cuenta de Usuario:
Motivo de la Solicitud:

Cliente / Mandante :
VAD VAQ VAP
  
Jefe inmediato: Firma:

Funcionario: Firma:

Aprobado por: Firma:

Aplicado por: Firma:

Observaciones:

94
22.3 Modificación de roles

Cuando se requiere modificar el perfil y/o los privilegios de acceso de un usuario a un sistema de
información, se debe diligenciar el formato FO-M11-P2-13 así:

95
Departamento del Valle Código: FO-M11-P2-13
del Cauca Versión: 02
MODIFICACION DE ROLES A
Fecha de Aprobación: 31/05/2107
USUARIOS EN SAP Y OTROS
SISTEMAS DE INFORMACION
Página: 1 de 1
Gobernación
MARCAR SOLO UNA OPCIÓN
Fecha: Crear:  Modificar:  Retirar: 
Datos Personales
Apellido(s):
Nombre(s):
Cédula: Secretaría:
Tipo de vinculación: Desde: Hasta:
Oficina: Piso: Teléfono:
Extensión: Firma Funcionario:
Cuenta de Usuario:
Nombre del Jefe inmediato: Firma:

Nombre Líder Mesa de Servicios: Firma:

Sistema de Información y/o Tiene

aplicativo: Capacitación? (S/N) :
Rol(es):

Transacción(es) y/o
Funcionalidades:

 Parametrizador   Usuario  Consultor Otro

Desarrollador
Especifique:
Cliente / Mandante :
VAD  VAQ  VAP 
Aprobado Por: Firma:

Aplicado por:
Firma:

Observaciones:

96
23. Auditoría y trazabilidad de los sistemas de
información - LI.SIS.23.
En la Gobernación del Valle del Cauca se han definido cuatro niveles de auditoría y trazabilidad
para sus sistemas de información:

 Auditoria a nivel de base de datos: El usuario que tenga un perfil con privilegio de acceso a
la base de datos configurado en el sistema de información, debe tener un registro de
auditoría en base de datos de las acciones que realice en la misma.

 Auditoria a nivel de sistemas de información: Cada sistema de información debe tener un

registro de los eventos que realicen los usuarios en el sistema.

 Trazabilidad tipo CRUD para cada actividad efectuada en los Sistemas de Información
(CRUD - Create, Read, Update, Delete).

 Log del sistema de información: Cada sistema de información debe registrar los eventos en
nivel de error que se presenten. De esta manera se habilita el poder realizar un seguimiento
a las fallas que afecten la calidad del servicio.

 La Gobernación implementara un sistema de auditoría y trazabilidad, que le facilite su

obtención de la certificación ISO 27001.

En consideración a que el Sistema de información critico trabaja sobre ambiente SAP, La

secretaria de las TIC se apoya en que SAP tiene funciones muy avanzadas para la gestión de
procesos, la trazabilidad entre los mismos y la navegabilidad, y de esta manera se pueden cumplir
cuatro de los cinco niveles de auditoría ya trazabilidad planteados.

La Secretaria mantiene monitoreadas y resguardadas las transacciones que permiten crear,

modificar y eliminar las cuentas de usuario con la restricción y segmentación de sus respectivos
objetos de autorización que permiten ejecutar alguna de estas acciones.

Cuando ocurre una baja de usuarios, se ha definido que no se eliminara la cuenta del usuario que
deja de pertenecer a la entidad, este se debe bloquear al usuario inmediatamente, y se procede a
desvincular inmediatamente la totalidad de los roles, perfiles y autorizaciones de la cuenta de
usuario que deja la Gobernación. Posteriormente se procede a clasificar a estos usuarios en un
grupo especial y representativo, a fin de mantenerlos monitoreados de forma sencilla.

Con respecto a los privilegios de los usuarios, se ha restringido y monitoreado los privilegios para

97
la creación, modificación y eliminación de usuarios en el sistema.

De igual manera se restringe y monitorean los privilegios para la creación de roles, perfiles,
autorizaciones y su asignación a un User Id. Se segregan los privilegios para creación de usuarios,
roles, perfiles y autorizaciones.

Hay un monitoreó continuo del maestro de usuarios. Se usan cuentas de usuario que son
representativas de quien las usa y de esta manea se evita el uso de cuentas genéricas. Lo anterior
especialmente en con respecto a las cuentas de usuarios que ejecutan transacciones de creación,
modificación, actualización o eliminación.

Se ha definido que eventualmente se podría usar cuentas genéricas restringidas con privilegios de
visualización, pero con el debido resguardo de la confidencialidad de la información. Se monitorea
de manera continua la integridad en la creación de datos maestros de usuarios.

98
24. Accesibilidad - LI.SIS.24
La Secretaria de las Tecnologías de Información y las Comunicaciones ha definido como prioridad
que sus sistemas de información deben de ser fáciles de usar y comprender por quien usuarios al
interior de la Gobernación o la ciudadanía.

Es así que se ha definido los sistemas de información que estén disponibles para el acceso a la
ciudadanía o aquellos que de acuerdo a la caracterización de usuarios lo requieran, deben cumplir
con las funcionalidades de accesibilidad que indica la estrategia de Gobierno en Línea,
principalmente se ha hecho énfasis en cumplir con:

 Tener una arquitectura de información que habilite una satisfactoria experiencia de usuario.

 Poseer un diseño de interacción que permita que las interfaces y espacios interactivos
cumplan con las expectativas de los usuarios.

 Tener un adecuado posicionamiento en motores de búsqueda.

 Diseño de la interfaz de usuario enfocada a la experiencia e interacción de los usuarios.

 La gobernación adopta una estrategia de periodismo digital adaptada a las necesidades de

un entorno ágil y dinámico como sus portales.

 Los diseños son centrados en los usuarios.

Con respecto a la interfaz de usuario

 Se ha ubicado el logotipo de la entidad en el mismo lugar en todas las páginas y se

encuentra vinculado con la página de inicio.

 Se ha monitoreado que el diseño de los portales de la Gobernación son consideradas

ordenadas y limpias por parte de los usuarios.

 En los portales de la Gobernación no se incluyen interfaces en movimiento.

 El texto y las imágenes de texto tienen suficiente contraste de brillo y color con el fondo.

 La información transmitida a través de color, está también disponible sin color.

99
  Se evita que se presente la alineación justificada del texto de prosa al margen izquierdo y
derecho a la vez.

 Se utiliza un ancho promedio entre 60 y 80 cpl (caracteres por línea) para el cuerpo de texto.

 Se usan fuentes tipográficas universales desde la hoja de estilo CSS para todos los textos.

 Se utiliza el espacio en blanco para generar relaciones entre los elementos y contenidos de
los portales.

 Se adopta un diseño de página que no genera desplazamiento horizontal.

 Se tiene habilitado un acceso a la página de inicio, mediante hipervínculo en el logotipo y

con un v nculo de texto rotulado como ―Inicio.

 La página de inicio de la Gobernación y de los mini portales se encuentra orientada a las

tareas clave de los usuarios.

 La página de inicio sirve como la puerta de entrada para el resto de contenidos del sitio web
de la Gobernación.

 Los portales de la gobernación son independientemente del navegador.

 Se puede diferenciar claramente los vínculos visitados de los vínculos sin visitar.

 El código HTML y CSS usado para los desarrollos al interior de la gobernación cumple con
los estándares emitidos por la W3C.

Con respecto al diseño de la interacción en los portales y aplicativos de la Gobernación se:

 Distinguen claramente los campos obligatorios de los opcionales.

 Asocian claramente las etiquetas con los campos de los formulario.

 Se proporciona una validación dinámica de datos, antes de que el usuario envíe un

formulario.

 No hay despliegue de ventanas que no son solicitadas por los usuarios.

 La función de botón siempre se encuentra en funcionamiento en las aplicaciones y portales

de la Gobernación.

 Las aplicaciones se encuentran optimizadas de tal manera que el tiempo de carga sea

100
 mínimo.

 Los mensajes y paginas de confirmación son claras e informativas.

101