Superintendencia de Industria y Comercio,

RESOLUCIÓN 80935 DE 2015

(Octubre 8)

“Por la cual se modifica la Resolución 64191 del 2015, en particular el contenido en el anexo 6 - Requerimientos del sistema del registro abierto de avaluadores, RAA”.

El Superintendente de Industria y Comercio,

en ejercicio de sus facultades legales, en particular las conferidas en la Ley 1673 de 2013 y el Decreto 4886 de 2011 y en las demás normas reglamentarias, y

CONSIDERANDO:

Que mediante la Ley 1673 de 2013 se reglamentó la actividad del avaluador, la cual tiene por objeto establecer las responsabilidades y obligaciones a cargo de los avaluadores en Colombia, así como prevenir los riesgos sociales de inequidad, injusticia, falta de transparencia y el posible engaño entre compradores, vendedores o al Estado;

Que de conformidad con lo establecido en los artículos 26 “Entidades reconocidas de autorregulación” y 27 “Requisitos”, dispuestos en la Ley 1673 de 2013 y los artículos 2.2.2.17.5.1 “Del reconocimiento de las entidades reconocidas de autorregulación”, 2.2.2.17.5 “Requisitos para el reconocimiento de las entidades reconocidas de autorregulación”, 2.2.2.17.5.3 “Condición de una entidad reconocida de autorregulación para operar”, contenidos en el Decreto 1074 de 2015, “por medio de la cual se expide el Decreto Único Reglamentario del Sector Comercio, Industria y Turismo”, se señalan los requisitos que deben cumplir las entidades reconocidas de autorregulación, ERA;

Que a su turno, la Superintendencia de Industria y Comercio expidió la Resolución 64191 de 2015, “por la cual se deroga el contenido del título IX de la Circular Única de la Superintendencia de Industria y Comercio, en materia de avaluadores y se incorpora lo establecido en la Ley 1673 de 2013 y el capítulo 17 del Decreto 1074 de 2015 y se imparten instrucciones, relativas a la actividad del avaluador”, publicada en el Diario Oficial 49637 de 2015, referente a los requerimientos necesarios para que las entidades reconocidas de autorregulación, ERA, que pretendan solicitar y obtener su reconocimiento y la autorización de la operación ante esta entidad, se ajusten a las instrucciones allí contenidas junto con sus anexos;

Que teniendo en cuenta lo anterior se evidencia que el anexo 6 referente a los requerimientos del sistema registro abierto de avaluadores, RAA, contiene exigencias que hacen más onerosa su implementación a cargo de las agremiaciones sin ánimo de lucro que pretendan constituirse como entidades reconocidas de autorregulación, ERA, en especial, la que opte por la creación e implementación del registro abierto de avaluadores, RAA, de manera que se procederá a adoptar el ajuste correspondiente al anexo en mención, en virtud de los principios que rigen la función administrativa;

Por consiguiente se hace necesario modificar el anexo 6 requerimiento sistema registro abierto de avaluadores, RAA, el cual fue adoptado en la Resolución 64191 de 2015, que a su vez se encuentra incorporado en la Circular Única de la Superintendencia de Industria y Comercio,

RESUELVE:

ART. 1º—Modifíquese el anexo 6 “Requerimiento sistema registro abierto de avaluadores, RAA”.

ART. 2º—La presente resolución rige a partir de la fecha de su publicación en el Diario Oficial.

Publíquese y cúmplase.

Dada en Bogotá, D.C., a 8 de octubre de 2015.

Anexo 6

Requerimientos registro abierto de avaluadores, RAA

Versión 2

1. Descripción del documento
1.1. Propósito
1.2. Generalidades
1.3. Referencias
2. Generalidades del proyecto
2.1. Descripción del problema
2.2. Definiciones
2.3. Stakeholders
3. Requerimientos funcionales
4. Requerimientos no funcionales
4.1. Desempeño
4.2. Seguridad
4.3. Auditabilidad
4.4. Disponibilidad
4.5. Confiabilidad
4.6. Portabilidad
4.7. Escalabilidad
4.8. Usabilidad
4.9. Flexibilidad

1. Descripción del documento.

1.1. Propósito.

Este documento reúne los requerimientos funcionales y no funcionales, que se requieren cumplir con la implementación de un sistema de información para el registro abierto de avaluadores.

1.2. Generalidades.

Los requerimientos funcionales hacen referencia a las funcionalidades mínimas del sistema esenciales para el desarrollo del negocio.

Los requerimientos no funcionales se enmarcan en un ámbito de infraestructura, seguridad y confiabilidad, describiendo las necesidades mínimas para que el sistema sea estable y se salvaguarde la información que allí residirá.

1.3. Referencias.

(1) Ley 1673 de 2013.

(2) Decreto 556 de 2014, compilado en el capítulo 17 del Decreto 1074 de 2015, Decreto Único Reglamentario del Sector Comercio Industria y Turismo.

(3) Decreto 2046 de 2014.

(4) Decreto 458 de 2015.

2. Generalidades del proyecto.

2.1. Descripción del problema.

El Decreto 556 de 2014, por el cual se reglamenta la Ley 1673 de 2013; describe el modo de administración y regulación de los avaluadores en todo el territorio nacional. Establece además la creación de entidades reconocidas de autorregulación y la expedición de certificados para cada avaluador registrado en estas entidades, entre otros aspectos.

Es por esto que para dar cumplimiento a lo establecido en el decreto, se requiere construir un sistema de información que permita la creación, gestión, control y seguimiento al registro abierto de avaluadores.

2.2. Definiciones.

A continuación se citan las definiciones de los conceptos utilizados en el sistema, consignadas en el artículo 3º del capítulo I del Decreto 556 de 2014.

Afiliados o miembros: Son aquellas personas que en el ejercicio del derecho de asociación, son aceptados para que concurran y, de estar habilitados para ello, deliberen y voten en las decisiones del máximo órgano de dirección de una entidad reconocida de autorregulación, de conformidad con los estatutos de la respectiva entidad. Además tendrán los derechos y obligaciones que determinen las normas internas de la entidad. Los avaluadores afiliados o miembros de una entidad reconocida de autorregulación deberán estar inscritos en el registro abierto de avaluadores, a más tardar al finalizar el plazo establecido en los artículos 6º y 23 de la Ley 1673 de 2013.

Entidad gremial: Corresponde a la entidad creada por avaluadores personas naturales para el desarrollo de sus intereses comunes, por gremios de avaluadores o por asociaciones de gremios de avaluadores. Una entidad gremial de las señaladas anteriormente, podrá contar con gremios de usuarios y asociaciones de gremios de usuarios de los servicios de valuación o con personas, gremios o asociaciones de gremios que pertenezcan al sector inmobiliario.

Inscritos: Son las personas naturales que realizan las actividades de valuación y que previo el cumplimiento de los requisitos establecidos en el artículo 6º de la Ley 1673 de 2013, han sido inscritos por la entidad reconocida de autorregulación en el registro abierto de avaluadores. La inscripción conlleva la obligación de autorregulación por parte de la entidad reconocida de autorregulación ante la cual el avaluador se ha inscrito.

Registro abierto de avaluadores, RAA: Es el protocolo único, de acceso abierto a cualquier interesado, a cargo de las entidades reconocidas de autorregulación de avaluadores, en donde se registra, conserva y actualiza la información relativa a la inscripción de avaluadores, a las sanciones disciplinarias a las que haya lugar en desarrollo de la actividad de autorregulación y demás información que de acuerdo con las regulaciones deba o pueda ser registrada en él.

Certificados de aptitud profesional: Los certificados de aptitud profesional de que trata el parágrafo 2º del artículo 6º de la Ley 1673 de 2013 para referirse a las certificaciones que expiden los programas de educación para el trabajo y el desarrollo humano al momento de su culminación, corresponden a los certificados de aptitud ocupacional que expiden las instituciones de educación para el trabajo y el desarrollo humano, legalmente reconocidas por autoridad competente, de conformidad con lo ordenado por el numeral 3.3 del Decreto 4904 de 2009.

2.3. Stakeholders.

A continuación se describen los stakeholders que están involucrados en la consulta, revisión, validación y aprobación del presente documento:

Partes interesadas (stakeholders)Descripción
Usuarios Usuarios finales, gerente del proyecto, conocedores del negocio, organismos de control, y usuarios que realizan procesos de revisión y pruebas de aceptación del documento.
Desarrolladores e ingenieros de prueba Ingenieros de software y de pruebas.
Administradores del sistema Funcionarios encargados de la administración y parametrización del sistema.
Personal de infraestructura Ingenieros de infraestructura y telecomunicaciones, encargados de la definición, administración y operación de los diferentes equipos, computadores, equipos de red y telecomunicaciones.

3. Requerimientos funcionales.

A continuación se describen las reglas de negocio que se deben implementar en el sistema de información.

RequerimientoÁreaNombreDescripción
RF-01 Sistema central RAA Gestión de usuarios Los usuarios se deben poder asociarse a uno de los siguientes perfiles:
• Administrador RAA: Este usuario tiene control total del sistema.
• Administrador ERA: Este usuario tiene acceso a:
○ Opciones asociadas propias para las ERA
○ Administración de usuarios ERA: Estos usuarios tendrán permisos solo a las opciones de las ERA.
• Ente de control: Estos usuarios tienen acceso de consulta al sistema y a la generación de reportes.
• Usuarios ERA: Estos usuarios tienen acceso a las opciones del sistema propias de la ERA.
RF-02 Sistema central RAA Parametrización del sistema Se debe permitir cambiar los valores de los parámetros generales de la aplicación.
RF-03 Sistema central RAA Administración de ERA Se debe permitir crear, editar, consultar, eliminar o inactivar una ERA. El registro de la ERA debe contar como mínimo con los siguientes datos:
• Nombre o razón social de la ERA
• NIT
• Nombre de representante legal
• Tipo y número identificación del representante legal
• Dirección de la ERA
• Teléfono de contacto
• Acto administrativo mediante el cual se reconoció como ERA
• Fechas del acto administrativo
• Fecha de registro al RAA
RF-04 Sistema central RAA Registro de transacciones Se debe llevar un registro de todas las transacciones realizadas en el RAA.
RF-05 Sistema central RAA Administración de categorías de avaluadores Se debe permitir crear, editar, eliminar, consultar o inactivar una categoría.

RequerimientoÁreaNombreDescripción
RF-06 Sistema central RAA Reportes RAA Reportes propios del RAA para su gestión y para reportar a entes de control.
RF-07 Sistema ERA Gestión de usuarios Cada ERA debe tener un usuario administrador, que le permita crear, editar, consultar, eliminar o inactivar usuarios de su ERA.
RF-08 Sistema ERA Registro de avaluadores Se debe almacenar de cada avaluador como mínimo la siguiente información:
• Código único: Este código identificará al avaluador en el sistema para cualquier trámite, se debe tener la opción de elegir entre número de identificación o un código autogenerado y controlado por el sistema con una nomenclatura previamente definida
• Foto
• Tipo y número de identificación
• Nombres y apellidos
• Fecha y lugar de nacimiento
• Número de tarjeta profesional y fecha de expedición (opcional)
• Dirección de domicilio
• Teléfonos de contacto
• Correo electrónico
• Fecha de registro
• Categorías asociadas
• Régimen de inscripción: académicos o practicantes
• Soporte de experiencia: Documentación digitalizada aportada por el avaluador, detallada por tipo de documento y archivo en PDF o imagen. En caso de que el avaluador entregue los documentos físicamente debe permitirse la digitalización de los mismos. El sistema no debe permitir registrar a un avaluador más de una vez. En caso de que el avaluador sea dado de baja en una ERA, se debe conservar el historial en el sistema.
RF-09 Sistema ERA Comité de aprobación de solicitudes El módulo de comités debe permitir ingresar la información de cada reunión del comité de aprobación, relacionando los siguientes datos:
• Número del comité
• Fecha
• Funcionarios
• Solicitudes de avaluadores (suscripción o cancelación) estudiadas
• Decisión para cada solicitud: La decisión para cada para cada solicitud deberá ser registrada de manera individual.
RF-10 Sistema ERA Registro de respuesta a solicitudes Formulario de respuesta a solicitudes de suscripción y cancelación realizadas por el avaluador.
RF-11 Sistema ERA Generación de certificados El módulo debe permitir generar por demanda los certificados solicitados por las ERA para sus afiliados.
El certificado debe contar mínimo con los siguientes datos:
• Datos de la ERA: Nombre, identificación, resolución.
• Datos del avaluador: Nombre, domicilio, correo electrónico, teléfono de contacto, fecha de inscripción, categorías, antecedentes disciplinarios.
• Pin de verificación: Un pin autogenerado que debe ser único y asociado con el certificado para las validaciones en línea.
• Código de barras QR: Código autogenerado que permita verificar la validez de un certificado.
• Fecha de vencimiento.
RF-12 Sistema ERA Traslado de avaluadores Un avaluador solo puede estar activo en una ERA, para realizar el trámite de traslado debe ser dado de baja en la ERA en la que se encuentra activo y dado de alta en otra, para este propósito se debe contar con un formulario de registro de cancelación del avaluador y posteriormente se debe expedir un paz y salvo.

RequerimientoÁreaNombreDescripción
RF-13 Sistema ERA Registro de sanciones disciplinarias Una ERA puede registrar, editar o borrar sanciones disciplinarias al avaluador, el registro debe tener como mínimo la siguiente información:
• Avaluador sancionado
• Fecha de registro
• Tipo de sanción
• Descripción de los hechos
• Fecha de finalización de la sanción
• Documentación de soporte
La sanción registrada debe quedar asociada al avaluador correspondiente, de manera que salga en la certificación o al consultarlo en el sistema.
RF-14 Sistema ERA Visibilidad de la información Una ERA solo puede ver la información de sus afiliados en el RAA.
RF-15 Sistema ERA Reportes ERA Reportes propios de la ERA para su gestión y para reportar a entes de control.
RF-16 Portal entidades de control Sitio para entidades de control Debe existir la funcionalidad que permita, mediante usuario y contraseña, que las entidades de control ingresen al RAA para ejercer sus funciones de vigilancia y control.
RF-17 Portal entidades de control Reportes entidades de control Generación de reportes de entidades de control como la SIC u otras que la ley disponga, estos informes serán retroactivos por lo tanto la información deberá permanecer en el tiempo.

4. Requerimientos no funcionales.

A continuación se describen los requerimientos no funcionales

4.1. Desempeño.

Es un indicador de la capacidad de respuesta de una aplicación para ejecutar una acción dentro de un intervalo de tiempo dado, esta capacidad debe tener como base la infraestructura tecnológica y escenarios específicos a los que el sistema estará expuesto y a los que deberá responder.

RequerimientoNombreDescripción
RNF-01 Tiempo de respuesta en la navegación de la aplicación. El tiempo de respuesta promedio para la navegación entre las páginas, realizar inserciones de datos, ediciones y cambios de estado de registros, debe ser menor o igual a 3 segundos.
Las condiciones y especificaciones de ambiente y ejecución de prueba se definen en el escenario de calidad. Tener en cuenta en el escenario de calidad, la afectación al tiempo de respuesta esperado con respecto al canal de comunicación.

4.2. Seguridad.

Seguridad se define como la forma en que el sistema es protegido para evitar la pérdida o substracción de información de fuentes no autorizadas.

RequerimientoNombreDescripción
RNF-02 Autenticación Todos los actores se autenticarán a través del módulo existente para tal fin en la aplicación. La clave debe ser bloqueada a un número de intento fallido (el número de intentos se define en el archivo de configuración).
Debe existir la opción de recuperación de contraseña para todos los usuarios.
RNF-03 Autorización usuarios Los usuarios del sistema se autorizarán a través de los módulos existentes para tal fin en la aplicación.
Se definen las siguientes funcionalidades específicas:
• Administración de perfiles.
• Asignación de opciones de sistema a perfiles.
• Asignación de perfiles a usuarios.
• Registro de usuarios externos.
• Manejo de contraseña.
RNF-04 Tiempo de inactividad de usuarios El sistema debe controlar los tiempos de inactividad de los usuarios finales y manejar la desconexión.
El tiempo debe ser de 15 minutos y debe ser parametrizable a través de archivo de configuración.
RNF-05 Secuencia entre páginas La aplicación debe mantener la secuencia lógica entre las pantallas, es decir, no debe entrar directamente a una página que no fue solicitada desde otra. Acceso únicamente a través de la secuencia de navegación.

RequerimientoNombreDescripción
RNF-06 Eliminación de cookies Si la aplicación genera cookies en el navegador de Internet, estas deben ser eliminadas al cerrar la sesión.
Así sea por inactividad de usuario o cuando el usuario salga cuando lo desee, es decir, presionando el control de cerrar el navegador de Internet.
RNF-07 Cifrado contraseña usuario La contraseña del usuario debe tener un algoritmo o mecanismo de cifrado al almacenarse en la base de datos.
RNF-08 Múltiples sesiones El sistema debe restringir múltiples sesiones abiertas desde diferentes navegadores o estaciones de trabajo.
RNF-09 Mantener sesión El sistema debe mantener la sesión con el usuario en caso de que uno de los servidores web o de aplicaciones falle.

4.3. Auditabilidad.

Es el proceso de registrar, agrupar, reportar y evaluar evidencias del flujo de los datos y del manejo para mantener la integridad en un sistema de información y así llevar a cabo eficazmente seguimientos y controles que la organización o entidad establezcan.

RequerimientoNombreDescripción
RNF-10 Registro auditoría El sistema requiere un log de registro interno para brindar información oportuna respecto a la trazabilidad de las acciones realizadas por cada uno de los usuarios.
El sistema requiere de un log de errores para brindar información técnica del error presentado en la aplicación. Este log debe quedar en archivo .log y en base de datos.
El archivo .log debe quedar en cada uno de los N servidores de aplicaciones, la partición del archivo debe quedar configurada por tamaño, y este se debe definir en el archivo de configuración.
RNF-11 Consulta información auditoría El sistema requiere de la opción de poder consultar los registros almacenados en el registro interno definido en el requerimiento de registro auditoría para la trazabilidad de las acciones y el log de error de base de datos.

4.4. Disponibilidad.

Disponibilidad se define como la proporción del tiempo que el sistema es funcional y trabaja. Puede ser medido como un porcentaje del tiempo total en que el sistema no estuvo caído en un periodo predefinido. La disponibilidad puede verse afectada por errores del sistema, problemas de infraestructura, ataques o carga del sistema.

Contingencia tecnológica se define como la estrategia que debe tener una aplicación para establecer un servicio continuo y logre operar en caso de falla en uno o varios componentes.

RequerimientoNombreDescripción
RNF-12 Alta disponibilidad El sistema debe estar disponible el 95% del tiempo en el primer año, el 97% en el segundo año, y el 99.5% de ahí en adelante.
El cumplimiento de este escenario de calidad, depende de la infraestructura y de la propuesta de despliegue que se presente.

4.5. Confiabilidad.

Hace referencia al nivel de confianza que el aplicativo ofrece al usuario sobre el hecho de que no fallará en la ejecución de su función.

RequerimientoNombreDescripción
RNF-15 Datos dispuestos a perder La cantidad de datos dispuestos a perder durante la realización de una transacción solicitada por un usuario es igual a 0 (cero) bajo cualquier condición operativa, bien sea en condiciones normales en producción o en condiciones de carga por contingencias extremas o estrés.
Llegado el caso que existan interrupciones de comunicación entre los servidores y el cliente, el sistema no continúa con la solicitud y el cliente debe reanudar la petición. Adicionalmente, cuando se esté recibiendo información y ocurra una interrupción de comunicación, el sistema no continúa con la recepción y el actor debe reiniciar el envío.

RequerimientoNombreDescripción
RNF-16 Manejo de excepciones En el momento que ocurra una excepción debe ser notificada a través de un mensaje al usuario final para que sean entendidos y se pueda tomar una acción con respecto al mensaje.
En relación al mensaje que se le presente al usuario, se clasificarán las excepciones más comunes que se identifiquen en la construcción del sistema; las que no, irán a una excepción por defecto de contactar al administrador del sistema.
El control de excepciones no debe suministrar rutas físicas, arquitecturas de la plataforma, tablas de la base de datos y ninguna información que pueda usarse para vulnerar el sistema.

4.6. Portabilidad.

Se define como la capacidad de la aplicación para poder ejecutarse en diferentes plataformas tecnológicas.

RequerimientoNombreDescripción
RNF-17 Navegador La aplicación deberá ser web y portable entre los siguientes navegadores de Internet:
• Chrome 29.0.1547.76 o superior
• Internet Explorer 8 o superior
• Firefox 23.0.1 o superior

4.7. Escalabilidad.

Escalabilidad es la habilidad del sistema para que cuando se le aumente la carga en número de usuarios o cantidad de procesamiento no requiera crecer en recursos de hardware en igual proporción. Típicamente el sistema será capaz de extenderse en la prestación del servicio al incrementarse la demanda o la carga.

RequerimientoNombreDescripción
RNF-18 Accesos concurrentes Se estima que en concurrencia se pueden tener 50 accesos concurrentes en un instante de tiempo.

4.8. Usabilidad.

La usabilidad se define como la facilidad con que las personas puedan utilizar una aplicación informática, con el fin de cumplir con los requerimientos de los usuarios finales y tener la capacidad de localizar, globalizar y deducir cada una de las acciones contempladas en el sistema.

RequerimientoNombreDescripción
RNF-19 Facilidad de uso La interfaz de usuario del sistema deberá cumplir con el nivel AAA descrito en el manual de usabilidad de gobierno en línea.

4.9. Flexibilidad.

Es la habilidad de un software para adaptarse a situaciones variables y para soportar cambios en políticas y reglas de negocio. Un sistema flexible es uno que es fácil de reconfigurar o que se adapta en respuesta a los diferentes requerimientos de usuarios y del sistema.

RequerimientoNombreDescripción
RNF-20 Configuración recursos Debe existir esquema para el manejo de propiedades de configuraciones específicas de los recursos que use la aplicación. Por ejemplo:
• IP de servidores.
• Puertos.
• Nombre de la base de datos, etc.