Requisitos.

La oferta deberá cumplir necesariamente con lo siguiente:

- Presentación del documento de garantía de seriedad de la oferta, según lo estipulado en

la Ficha Ejecutiva. Para el caso de boletas electrónicas, éstas deberán ajustarse a lo

dispuesto en la Ley N° 19.799 sobre Documentos Electrónicos, Firma Electrónica y

Servicios de Certificación de dicha firma.

- El equipo mínimo ofertado para brindar los servicios debe ser de 4 personas, de acuerdo

a los perfiles y cantidades indicadas en el numeral 5 del punto III) Bases Técnicas,

denominado “Del equipo ofertado”, equipo de trabajo que debe cumplir con los

imprescindibles mencionados en dicho numeral.

La OFERTA TÉCNICA deberá ser presentada a través del sitio web

www.mercadopublico.cl, en el campo destinado a recibir la oferta técnica, como documento

adjunto, en formato compatible con MS-Office o archivo .pdf con los siguientes documentos:

1.- Anexo N° 1, Declaración Jurada del Proponente (A o B según corresponda a personas

naturales o jurídicas).

2-Anexo N° 2, Antecedentes del Oferente

3.-Anexo N° 4, Certificado de Implementación Exitosa. La información indicada en este

anexo será utilizada para evaluar el siguiente criterio:

o Experiencia en proyectos similares.

4- Anexo N° 5, Currículo de Equipo de Trabajo. La información indicada en este anexo

será utilizada para evaluar los requisitos mínimos solicitados en el 2.2 y para evaluar el

siguiente criterio:

o Cantidad de perfiles con certificación en el Equipo de Trabajo.

5-Anexo N° 6, Carta de compromiso del Scrum Master.

6-Anexo N° 7, Certificaciones del Oferente. La información indicada en este anexo será

utilizada para evaluar el criterio de evaluación certificaciones del oferente.

7- Anexo N° 9, Declaración jurada con/sin saldos insoluto de remuneraciones. (según

corresponda).
La OFERTA ECONÓMICA

deberá ser presentada en Unidades de Fomento, a través del sitio web www.mercadopublico.cl. Además, se debe adjuntar el Anexo
N° 3: Propuesta Económica en el mismo formato, en el campo destinado a recibir la oferta económica. En caso de existir discrepancia
entre la oferta económica presentada en el sitio web www.mercadopublico.cl y la propuesta económica indicada en el Anexo N° 3,
se considerará como válido el valor indicado en el Anexo N° 3. En caso de discrepancia en los valores unitarios
y totales, si procede, se considerarán los valores unitarios.
BASES TÉCNICAS

El SII requiere realizar una serie de mantenciones sobre las aplicaciones que soportan el sistema de Recepción Internet Formulario
de Enajenación de Bienes Raíces (F2890), las que deben ser desarrolladas en la arquitectura referencial del SII (ARSII), cuyas
características se describen en el numeral 4 del punto III) Bases Técnicas. Para lo anterior, se necesita contratar un servicio de
mantención de software, basado en metodologías ágiles, creando una célula que permita implementar mejoras a las aplicaciones de
acuerdo con las actividades que se vayan levantando en cada sprint, según el backlog que se manejará para el sistema.

F2890.

III. TÉCNICAS

1. INTRODUCCIÓN
1.1 Propósito del Proyecto

El SII requiere realizar una serie de mantenciones sobre las aplicaciones que soportan el sistema de
Recepción Internet Formulario de Enajenación de Bienes Raíces (F2890), las que deben ser desarrolladas
en la arquitectura referencial del SII (ARSII), cuyas características se describen en el numeral 4 del punto
III) Bases Técnicas.

Para lo anterior, se necesita contratar un servicio de mantención de software, basado en metodologías

ágiles, creando una célula que permita implementar mejoras a las aplicaciones de acuerdo con las
actividades que se vayan levantando en cada sprint, según el backlog que se manejará para el sistema
F2890.

1.2 Situación Actual

El sistema registra y administra las “Declaraciones sobre Enajenación e Inscripción de Bienes Raíces”
en Notarías, Notarías-Conservadores de Bienes Raíces y Conservadores de Bienes Raíces, como también
movimientos realizados por funcionarios del SII, tanto por la aplicación intranet como internet.

Contempla traspaso de información sobre enajenación en inscripción de bienes raíces mediante

aplicación web de formulario 2890. El proceso considera que los Notarios informen las transacciones de
enajenación realizadas mediante escritura y que los Conservadores informen las inscripciones
practicadas en el Registro de Propiedad de transacciones de transferencias de dominio ejecutadas en
notarías mediante escritura pública y de otras transacciones que no requieren de escritura pública.

Esta aplicación permite actualizar el nombre del propietario en el Catastro de Bienes Raíces tanto de la
línea como el batch; disponer de información necesaria para actualizar el maestro de Multipropietarios
asociados a cada predio con sus porcentajes de propiedad y; disponer para los contribuyentes la
visualización del F2890 en internet entre otros, permitiendo su adecuado procesamiento y uso para
efectos de fiscalización de los impuestos, generación de Ordenes de Trabajo y Notificaciones a
contribuyentes.
1.3 Diagrama Funcional F2890
2. REQUERIMIENTOS

Se requiere implementar mejoras a la aplicación F2890, lo que permitirá resolver problemas detectados
en la carga de información; mejorar la experiencia usuaria de Notarios, Conservadores, Notario-
Conservador, Funcionarios SII y Contribuyentes, optimizando tiempos de respuesta y mejorando los
actuales reportes. Al mismo tiempo, se efectuarán ajustes necesarios para optimizar la captura o
procesamiento de información que se realiza para el cálculo de la sobretasa de bienes raíces y generar
nuevas integraciones.

2.1 Épicas a Implementar

El listado requerimientos se irá levantando durante el transcurso del proyecto, no obstante al momento
de la adjudicación se contará con un conjunto de Historias de Usuario para ser revisadas y comprometidas
en los primeros sprint. Dentro de las épicas que se abordarán:

• Corregir deficiencias en la actual aplicación F2890 que afectan la captura de información proveniente
de Notarias, Conservadores y Notarios Conservadores, así como de funcionarios SII y su adecuado
procesamiento.
• Implementar los cambios requeridos por el proceso de Sobretasa 7 bis1, realizando las adecuaciones
requeridas del sistema F2890 y sistemas con los que se integra, así como el desarrollo de servicios
requeridos por otras aplicaciones.
• Mejorar la experiencia usuaria en términos del tiempo de respuesta del aplicativo, así como de la
reportería con el objetivo de facilitar el cumplimiento tributario de Notarios y Conservadores.
• Mejorar la experiencia usuaria interna considerando que esta información se utiliza actualmente
paraactualizar el catastro en línea e impacta en múltiples procesos internos y es utilizado por el
Banco Central para información estadística.
• Mejorar notificaciones y generar alertas a contribuyentes y funcionarios.

2.2 Requerimientos No Funcionales

• El layout de las soluciones implementadas debe atenerse a los lineamientos institucionales para
aplicaciones Internet/Intranet siguiendo la Guía de Usabilidad Web del SII que será entregada al
proveedor al inicio del proyecto.
• Las soluciones implementadas para este requerimiento deben ser implementadas bajo la
arquitecturareferencial definida por la Subdirección de Informática del SII (ver en el numeral 4 del
punto III) Bases Técnicas).
• La aplicación debe considerar el uso de la autenticación institucional, tanto para la búsqueda web,
como para el acceso directo a los servicios de negocio publicados.
• La aplicación debe incorporar una bitácora de eventos cuya implementación debe realizarse a
travésdel API institucional dispuesta para este propósito.
• Las mejoras solicitadas en los servicios de datos y los servicios de datos construidos para la
interacción con aplicaciones web, deberán responder en un tiempo máximo de 2000 milisegundos.

2.3 Esquema de Trabajo

• El desarrollo se realizará de forma iterativa e incremental. Cada iteración, Sprint, tendrá una duración
preestablecida de 3 semanas.
1
La Ley de Modernización Tributaria incorporó una Sobretasa del Impuesto Territorial, que se aplicará a los
contribuyentes que tengan propiedades cuyos avalúos fiscales, en total, excedan las 670 Unidades Tributarias
Anuales (UTA), es decir, cerca de 400 millones de pesos
 • El equipo, Product Owner, Scrum Master y Development Team en forma conjunta evaluarán el
pesodel backlog y determinarán las Historias de Usuario que se abordarán en cada Sprint.
• El equipo de trabajo multidisciplinario, debe tener los conocimientos (skills) descritos en el
numeral4 y 5 del punto III) Bases Técnicas y experiencia necesaria para llevar a cabo el trabajo.
• El Product Owner será un jefe de proyecto del negocio.
• El primer sprint será para configurar, parametrizar ambientes, conocimiento y toma de control de
laaplicación.
• Las reuniones de la célula se llevarán a cabo en las dependencias del SII, de forma remota o
unhíbrido de ambas.
• El Servicio de Impuestos Internos (SII) apoyará a la célula con un jefe de proyecto que facilitará la
gestión al interior de la Subdirección de Informática (SDI).

3. PRODUCTOS ENTREGABLES
El Servicio de Impuestos Internos (SII) tiene como objetivo el incremento de valor en las aplicaciones
sobre las cuales se realicen ciclos de desarrollo. Estos ciclos comprenden, entre otras, las actividades de
planificación, desarrollo y documentación.

3.1 Documentación y Herramientas

Se detallan a continuación los tipos de documentos y herramientas que se deben considerar durante el
desarrollo del proyecto, a fin de ajustarse a la normativa técnica de la Subdirección de Informática (SDI).
Actualmente se están redefiniendo algunos entregables para proyectos bajo metodología ágil por lo que
el detalle del contenido será entregado al proveedor seleccionado a fin de que los considere como
entregables.

3.1.1 TEMÁTICA REQUISITOS

• Uso herramienta de diseño Enterprise Architect (EA). Análisis y diseño de la solución, especificación
de requisitos funcionales y no funcionales que deberá cumplir la solución. Los entregables
esperados:
o Historias de usuario o casos de uso
o Diagramas de secuencia o actividades
o Casos y plan de pruebas funcionales
o Casos y plan de pruebas para la trazabilidad institucional.

3.1.2 TEMÁTICA MODELO BASE DATOS

• Uso herramienta de diseño Enterprise Architect (EA) para documentar los cambios al Modelo
deDatos y generar los script.
o El entregable esperado de esta etapa es el visto bueno del área de Gobierno de Datos
alModelo de Datos.

3.1.3 TEMÁTICA ARQUITECTURA

• Uso herramienta Enterprise Architect (EA) para actualizar y/o generar la documentación técnica del
sistema, la que considera: diagrama de contexto, diagrama funcional, diagrama de negocio y/o
dominio impactado, diagrama de capas y componentes, diagrama vista dependencias internas y
externas, diagrama de arquitectura, diagrama modelo de datos general.

Esta documentación es requerida para el paso a producción, no obstante, los cambios en el diseño de
la aplicación y/o del modelo de datos deben ser validados por el Comité Técnico y por Gobierno de
Datos antes de iniciar la construcción.

3.1.4 TEMÁTICA SEGURIDAD

• Uso de herramienta Sonar Lint en IDE, codificación.
• Uso de herramientas SonarQube y Appscan, certificación (QA)
3.1.5 TEMÁTICA CALIDAD
• Certificación funcional
 o Plan de Pruebas creado y en formato del estándar de Calidad, planilla Registro
EvidenciaCertificación (REC)
o Pruebas automatizadas con herramientas Selenium y/o Cypress
• Certificación no funcional
o Certificación de la Trazabilidad Institucional
o Pruebas de Carga, Rendimiento y/o Estrés según lo amerite la mantención realizada y o el
móduloafectado.
o Certificación marca DAS (ex DAX)
o Se debe considerar el minificado de la aplicación.
o Documentación en el código.

3.1.6 TEMÁTICA PASO A PRODUCCIÓN

• Especificación Webservices (EWS)
• Pauta de Monitoreo (PMO)
• Solicitud Instalación Aplicaciones JBoss (IJB)
• Evaluación Impacto Instalación JBoss (EIJ)
• Manual de Instalación On Line (MIO)
• Manual de Instalación Batch (MIB)
• Manual de Explotación Batch (MEB)
• Pauta de Proceso (PDP)
• Plan de Actividades Programadas (PAP)
• Manual de Usuario (MUS)

3.1.7 TEMÁTICA PMO

• Carta Gantt. El formato exigido por PMO del SII, será entregado al proveedor adjudicado y se
deberáconsiderar su actualización semanalmente.

3.1.8 TEMÁTICA ADMINISTRATIVA

• Deberes y derechos del proveedor.

3.1.9 TEMÁTICA PRODUCTO DE SOFTWARE

• Cumplimiento de lo solicitado en las presentes Bases Técnicas.
• Todo el Flujo de Trabajo del Equipo se debe realizar en Atlassian Jira y plugins Jira v7.10.1.

3.2 SLA PARA INSTALACIONES

Todo componente desarrollado en ambiente local debe ser instalado en los servidores para realizar
revisiones y certificaciones. El paso o instalación en el servidor de Desarrollo es de responsabilidad de
la célula, a partir del servidor de Estabilización en adelante se deben considerar los SLA de las áreas
encargadas de las instalaciones de los componentes:

Servidor de instalación SLA, cantidad máximo de días hábiles

Desarrollo No aplica
Estabilización 2
Certificación 2
Producción 5 a 10

4. STACK TECNOLÓGICO
A continuación se indica la normativa técnica de la Subdirección de Informática del SII. El detalle del
contenido será entregado al adjudicado seleccionado.
La Arquitectura Referencial del SII, ARSIISOA, es la base referencial de la arquitectura de software que
soporta actualmente el Sistema F2890 y en la cual se debe implementar las mantenciones.
En caso de construir nuevos módulos se deberá evaluar, en conjunto con el Jefe de Proyecto de la SDI,
si se debe construir en ARSIISOA o ARSII2020. En punto 4.2 se detalla Arquitectura Referencial
ARSII2020.

4.1 ARQUITECTURA REFERENCIAL ARSIISOA

En el siguiente diagrama se muestra la estructura y relaciones entre las diferentes tecnologías que
componen la ARSIISOA:

4.1.1 CAPAS, TECNOLOGÍAS Y CONTENEDORES

Arquitectura de Capas: uso de diferentes capas para asignar diferentes responsabilidades a los diferentes
componentes de un producto de software.
Tecnologías: artefactos tecnológicos tales como estándares, frameworks, librerías y otros que facilitan
que los componentes cumplan la responsabilidad asignada.
Contenedores: entornos de ejecución de componentes, les dan todos los servicios base necesarios para
que éstos puedan ejecutarse en conjunto con las tecnologías que los soportan.

4.1.1.1 ESQUEMAS DE CAPAS

Los componentes de la capa IU cliente se preocupan de facilitar la interacción de un ser humano con el
sistema. Estos se deben desarrollar en las tecnologías Angular JS, y controladas bajo el framework Spring
MVC.
Los componentes de la capa IU Servidor se preocupan de intermediar las acciones de un ser humano
contra el sistema, los datos y reglas aplicables a éstas. Se deben desarrollar utilizando SpringMVC,
RestEasy y los utilitarios provistos por Middleware.
Los componentes de la capa de servicios se encargarán de exponer interfaces para acceder a
funcionalidades del dominio de un sistema desde otro sistema. Se utilizará Spring MVC, RestEasy,
Spring y utilitarios para exponer servicios, además los servicios transversales de información y de
integración entre dominios. Los servicios serán expuestos como servicios REST a otros dominios, a
menos que en Comité de Arquitectura se decida lo contrario.
Los componentes de la capa de almacenamiento se encargarán de manejar la persistencia de los datos del
dominio de un sistema.

4.1.1.2 TECNOLOGÍAS
4.1.1.2.1 COMPONENTES DE LA TECNOLOGÍAS

4.1.1.2.2 ARQUITECTURA UI (USER INTERFACE)

La arquitectura de la capa de presentación se presenta con la siguiente estructura:

4.1.1.2.3 ARQUITECTURA DATA SERVICE/DOMAIN
4.1.2 CONTENEDORES

4.1.3 TAXONOMÍA DE SERVICIOS

Descripción / uso:
UI: “User Interface”, corresponde a la capa de presentación de la aplicación.
LOB: Servicios que contienen lógica de negocio particular. Estos servicios se crean en contenedores
JBOSS.
SS: Servicios transversales que proveen de información a todos los sistemas o a una gran cantidad de
ellos.
Los modelos varían de acuerdo a las capas arquitecturales, pero también varían internamente dentro de
una aplicación, nosotros distinguiremos dos tipos de modelos de una aplicación: API y Dominio.
La integración de servicios se realizará en conjunto con el área de Middleware y Arquitectura, donde se
definirá la mejor estrategia mientras se haga una definición formal.

4.1.4 EXPOSICIÓN DE SERVICIOS A APLICACIONES INTERNAS

Los servicios se expondrán usando protocolo REST usando estructura de proyectos generada.
Utilizando la seguridad SdiCommonsAA. Los desarrollos se instalarán en Plataforma JBOSS.
La exposición de servicios internos usa son por defecto del tipo POST. Para el uso de servicios de tipo
GET, se debe convenir con área de Arquitectura y justificar su uso.

4.1.5 EXPOSICIÓN DE SERVICIOS A APLICACIONES EXTERNAS

Los servicios se expondrán usando protocolo SOAP JAX - WS usando estructura de proyectos generada.
Utilizando la seguridad SdiCommonsAA. Los desarrollos se instalarán en Plataforma JBOSS.

4.1.6 ANÁLISIS DE CALIDAD DE APLICACIONES

El área de Pre producción es la encargada de velar por la calidad de las aplicaciones.
Todo nuevo desarrollo debe pasar por el área de calidad, quien emitirá un informe anterior al paso de
producción garantizando la correcta performance de las aplicaciones con el uso de herramientas como
SonarQube y Appscan.

4.1.7 TRAZABILIDAD DE APLICACIONES INSTITUCIONAL

Según el modelo de trazabilidad, el LOG de las aplicaciones debe cumplir con las definiciones existentes
en el manual para la utilización del API de trazabilidad, se considera de uso estricto dentro de las
aplicaciones.

4.1.8 TAG DE MARCA PARA WEB (DAS)

El servicio provee de una utilidad para marcar las visitas a las páginas del sitio. Este TAG, debe ser
incorporado en las aplicaciones web para obtener la información de visitas.

4.1.9 PATRONES DE DESARROLLO

Se espera que los desarrolladores JAVA puedan utilizar patrones adecuados de programación en sus
desarrollos. Para esto existe un pequeño manual descriptivo de patrones más usados y de prácticas de
desarrollo adecuadas para la Subdirección de informática.

4.1.10 HOW TO ARSII

Se ha desarrollado una wiki para mostrar la forma de crear e implementar diferentes aspectos de la
arquitectura referencial ARSIISOA.
4.1.11 DECÁLOGO DBA
Se proporcionará información relevante para mejorar la entrega de modelos de datos, mejorar la
implementación y desarrollo promoviendo buenas prácticas de diseño e implementación de bases de
datos.

4.1.12 CREACIÓN Y MODIFICACIÓN DE MODELOS DE DE DATOS

Se proporcionará pauta para la revisión de solicitudes de creación y/o cambios a modelos de datos Oracle,
procedimiento que se debe tener en cuenta siempre para esta tarea. En conjunto se entregará normas de
uso, construcción y revisión de scripts de bases de datos.

4.1.13 MANEJO DE ERRORES

El manejo de errores y excepciones tanto en la capa de presentación como en la capa de negocios
(dominio y anticorrupción) se manejan en forma diferente a como normalmente se realizan en las
aplicaciones.
El manejo de excepciones en la capa de anticorrupción valida posibles errores que puedan ocurrir, o bien,
captura excepciones de algún tipo para retornarlas a la capa inmediatamente superior como una
DomainException.

Luego en las capas inmediatas se pueden capturar estas excepciones o bien hacer validaciones propias
de datos del dominio que vienen como inputs de la capa de presentación.

Finalmente, la capa angular debe registrar un tipo de evento especial para poder leer los mensajes de
error que puedan llegar junto a la metadata. La diferencia con otros mecanismos es que acá las
excepciones no son propagadas al contenedor web, sino que se hace contención de ellas y se envían
mensajes descriptivos, más el registro del error y el log.

A nivel general, el diagrama de componentes y su interacción se ve así :

 Las

componentes participantes de esta interacción, CommonUtil, CommonData, las cuales proveen de clases
e interfaces que permiten definir un mecanismo de excepción basado en sucesivos mensajes de validación
en la capa de negocios.

4.1.14 COMPONENTES Y VERSIONES

A continuación, tabla con los principales componentes y versiones utilizados en ARSIISOA:
Componente Versión
Java 8
JBoss 6.4.x
Java JEE 6
Java Platform, Enterprise Edition 6 (Java EE 6) JSR 316
Provider Jboss EAP 6.3+
Angular JS 1.7.x
Bootstrap 3.3.x - 4.x
Spring y Spring MVC 3.0.5+, 4.x
Html 5.x
Java Servlet 3.0 JSR 315
Contexts and Dependency Injection for Java (Web
JSR 299
Beans 1.0)
Dependency Injection for Java 1.0 JSR 330
Bean Validation 1.0 JSR 303
Enterprise JavaBeans 3.1 (includes Interceptors 1.1) JSR 318
Java Message Service API 1.1 JSR 914
Java Persistence 2.0 JSR 317
DBMS Oracle 12c y Oracle 19
Java API for RESTful Web Services (JAX-RS) 1.1 JSR 311
RestEasy 2.3.x compatible con versión de EAP 6.4.x
Batch_ARSII 22 o última versión de producción
LOG trazabilidad institucional 1.3 o última versión
 Componente Versión
Tag marca para Web DAS
CommonUtil 1.0.18 o superior
CommonData 1.0.18 o superior
SdiCommonsAA (API interna, no estandarizada) 1.8.x o última versión de producción
SdiSsFramework (API interna, no estandarizada) 2.5.8 o última versión de producción
SdiCommonsSecurity (API interna, no
estandarizada) 1.0 o última versión de producción
ARSII Taxonomía 1.0
Logs Commos-logging 1.1.1, Log4j 1.2.16
Commons-ui-1.0.10 o última versión de
Carga de dependencias Web
producción
CI&CD Bamboo 5.6.2

4.2 ARQUITECTURA REFERENCIAL ARSII2020

Al construir nuevos módulos se deberá evaluar, en conjunto con el SII, si la capa de presentación debe
ser construida en ARSII2020.

4.2.1 AUTOMATIZACIÓN
Este dominio trata de proveer de las herramientas necesarias para automatizar lo que pasa entre que se
modifica el código fuente y que este cambio se refleje para el usuario que lo requiere.
Componente Rol Versión Propósito
Git - GitLab SCM 12 Sistema de control de versiones de código fuente.

Nexus Repository 3.20.x Repositorio para publicar artefactos.

Manager
NPM Build 6.14.4+ Gestor de dependencias y de proyectos
JavaScript.

Maven Build 3.6+ Gestor de dependencias y de proyectos

Java.

Jenkins CI/CD 2.240+ Herramienta para facilitar automatización de

tareas de desarrollo, orientadas a la integración
continua y deployment continuo sobre ambientes
pre productivos.

4.2.2 FRONTEND GUI BROWSER

Este dominio define lo necesario para que el usuario pueda acceder a la funcionalidad aplicativa
utilizando un navegador. En ARSII2020 promueve el desarrollo de sitios web estáticos, cuya dinámica
sea resuelta en el lado cliente utilizando JavaScript.
Componente Rol Versión Propósito
Vuejs Framework 2.6+ Framework para desarrollar aplicaciones con
JavaScript JavaScript
 Componente Rol Versión Propósito
Bootstrap Framework 4.5 Framework CSS para establecer estilo de
Mobile First trabajo, compatibilidad, accesibilidad AA y
posibilidad de ser responsivo

Bootstrap Vue Librería 2.15.0+ Librería de integración entre Vuejs y

JavaScript Bootstrap en base a componentes

Vue Router Librería 3.2.0+ Manejo de rutas (path) dentro de un

JavaScript Aplicativo

Vuex Librería 3.4.0+ Implementación de una máquina de estados en

JavaScript Vuejs para centralizar comunicación entre
componentes

Axios Librería 0.19.2+ Liberia de acceso a servicios Rest

JavaScript

Apache HTTP Servidor 2.4 Proveer entorno productivo para

Server aplicaciones web

4.2.3 FRONTEND API

Este dominio cubre lo necesario para poder exponer APIs hacia fuera, para que sean consumidas por
Frontend GUI propio del SII o aplicaciones de terceros.

Componente Rol Versión Propósito

Taxonomía Definición 1.0 Define un estándar SII para definición deAPI
utilizando path orientados a recursosal estilo
RESTful

Swagger (Open API 3.0.x Framework para documentar APIs con

API) Documentation estándar Open API 3.0

IBM DataPower API Gateway 2018.4.1.9 Permite la integración por medio de

Gateways servicios securitizados

5. DEL EQUIPO DE TRABAJO OFERTADO

El equipo de trabajo destinado a la ejecución de los servicios contratados debe estar conformado por los
siguientes perfiles:

Cantidad de
Perfil
personas
Scrum Master (50%) 1
Development Team (100%)
Desarrollador 1
Arquitecto-Desarrollador 1
Quality Assurance 1

Nota: El Scrum Master debe garantizar una cobertura de un 50% de su tiempo exclusivo para el proyecto.
A continuación, se presentan los requisitos técnicos para cada uno de estos perfiles:

5.1 ROL SCRUM MASTER

Ámbito Requisito Detalle
Ingeniero Civil o Ejecución en Computación e
Informática o carrera técnica o profesional afín al rol
Profesión Imprescindible requerido. Se debe adjuntar copia del certificado de
título profesional, claramente legible, en que se lea la
fecha de obtención del título.
1. Al menos 3 años de experiencia desde la obtención
del título en desempeño de tareas de desarrollo de
sistemas que involucren procesos complejos, de
servicio a clientes y/o transaccionales, con altos
volúmenes de información en distintas
plataformas, tales como los que se presentan en la
Experiencia Imprescindible
industria bancaria, del retail o de similar
envergadura
2. Al menos 3 años de experiencia desempeñando el
rol de Scrum Master.
Debe indicar en su currículum vitae el trabajo
realizado y el periodo de tiempo en el cual lo realizó.
Participación en proyectos de desarrollo y/o
mantención de software con tecnologías Java
Conocimientos Imprescindible
Enterprise Edition sobre JBoss EAP 6 y 7, bases de
datos Oracle 12c, 19c y PosgreSQL.
Certificación como Scrum Master.
Certificaciones Deseable

5.2 ROL DEVELOPMENT TEAM - DESARROLLADOR

Ámbito Requisito Detalle
Ingeniero Civil o Ejecución en Computación e Informática o
carrera técnica o profesional afín al rol requerido. Se debe
Profesión Imprescindible
adjuntar copia del certificado de título profesional, claramente
legible, en que se lea la fecha de obtención del título.

Al menos 3 años de experiencia desde la obtención del título y

desempeño en tareas de desarrollo de sistemas que involucren
Imprescindible
Experiencia procesos complejos, con altos volúmenes de información en
distintas plataformas, tales como los que se presentan en la
industria bancaria, del retail o de similar envergadura.

1. Análisis, diseño e implantación de sistemas en ambiente web

basados en HTML5, servicios REST/JSON, AngularJS,
VueJS y Bootstrap o similar.
2. Diseño y programación orientados a objetos.
3. Tecnologías de desarrollo Java 6 o superior, JEE 5 o superior
Al menos 4 de
Conocimientos (con énfasis en JAX-WS, JAX-RS, JMS).
los 7 ítems
Específicos 4. SQL, de preferencia las versiones incluidas en los motores de
bases de datos Oracle 11g, 12c.
5. Herramientas de testing JUnit, JMeter.
6. Sistema Operativo Unix-Linux.
7. Metodologías ágiles
 5.3 ROL DEVELOPMENT TEAM – ARQUITECTO-DEARROLLADOR
Ámbito Requisito Detalle
Ingeniero Civil o Ejecución en Computación e Informática o
carrera técnica o profesional afín al rol requerido. Se debe
Profesión Imprescindible adjuntar copia del certificado de título profesional,
claramente legible, en que se lea la fecha de obtención del
título.
Al menos 3 años de experiencia desde la obtención del título
desempeñando el rol de arquitecto o líder técnico en sistemas
Experiencia Imprescindible con patrones de diseño, Spring, AngularJS, VueJS, para lo
cual debe presentar su currículum vitae, indicando el trabajo
realizado y el período de tiempo en el cual lo realizó.
1. Java, JEE, Patrones MVC, Persistencia vía JPA,
PL/SQL, Spring, Hibernate, NodeJS, HTML5,
AngularJS y Bootstrap.
2. Arquitectura de sistemas TI.
3. Unix y Lenguajes de programación, tales como: Java,
Conocimientos
Al menos 6 de los HTML, JavaScript, SQL Oracle, PosgreSQL
Específicos
9 ítems 4. Servidores de aplicación JBoss.
5. Servicios Rest.
6. Pruebas de carga, rendimiento, stress.
7. Herramienta Enterprise Arquitect.
8. Uso de control de versiones vía SVN y GIT.
9. Metodologías ágiles

5.4 ROL DEVELOPMENT TEAM- QUALITY ASSURANCE

Ámbito Requisito Detalle
Ingeniero Civil o Ejecución en Computación e Informática o
carrera técnica o profesional afín al rol requerido. Se debe
Profesión Imprescindible
adjuntar copia del certificado de título profesional, claramente
legible, en que se lea la fecha de obtención del título.
Al menos 3 años de experiencia desde la obtención del título y
desempeño en tareas de quality assurance aplicando:
Imprescindible 1. Técnicas de aseguramiento y control de calidad.
(al menos 3 de 2. Técnicas de análisis funcional.
Experiencia
los 5 ítems) 3. Técnicas de generación de plan de prueba.
4. Técnicas de generación de set de datos de prueba.
5. Técnicas de apoyo a las Pruebas de Aceptación de Usuarios
(UAT).
1. Creación de casos de pruebas usando herramientas de
automatización.
2. Uso de Selenium y/o Cypress.
3. Uso Jmeter
Conocimientos (al menos 5 de 4. Conocimiento y generación de diagramas UML.
los 8 items) 5. Conocimiento en SonarQube.
6. Enterprise Architect
7. Uso de suite Atlassian Jira.
8. Metodologías ágiles

IMPORTANTE: Para verificar lo anterior, los oferentes deberán acompañar a sus ofertas los Currículum
vitae de los especialistas, en los cuales se debe indicar expresamente la profesión, experiencia y
conocimientos requeridos, en caso contrario, se considerará que el especialista no cuentacon estos.
Además, debe adjuntar el certificado de título profesional, las
certificaciones/magister/diplomados/cursos en conocimientos imprescindibles o deseables, para
efectos de acreditar el criterio de evaluación “Cantidad de profesionales del equipo de trabajo
propuesto con
alguna certificación vigente, magister, diplomado o curso sobre 40 horas
en los conocimientos imprescindibles o deseables”.