Licitación Pública Nº 19/2015- Expediente CM Nº OAyF 158/15-0- Resolución OAyF Nº 253/2015
Buenos Aires, 18 de agosto de 2015
Res. OAyF Nº 253 /2015
VISTO:
El Expediente OAyF Nº 158/15-0 caratulado “D.C.C. s/ Servicios Informáticos Judiciales (SIJ) – Arquitectura Básica” y la Resolución CM Nº 25/2015; y
CONSIDERANDO:
Que a través de la Resolución CM Nº 25/2015 se encomendó a la Dirección General de Informática y Tecnología la realización de todas las acciones necesarias para la implementación del sistema de “Firma Digital”, de acuerdo con lo establecido en la Ley Nacional Nº 25.506, las Leyes Nº 2751 y 4736, los Decretos Nº 322/GCABA/08, 1181/GCABA/08 y 518/GCABA/13, la Resolución Nº 283/GCABA/SECLYT/13, y las normas complementarias y concordantes.
Que en cumplimiento de lo dispuesto por la Resolución CM Nº 25/2015, por Nota Nº 271 (fs. 1/17) la Dirección General de Informática y Tecnología remitió las especificaciones técnicas para proceder a la contratación de los servicios informáticos judiciales (SIJ) -Arquitectura Básica-. Luego, mediante Nota Nº 284 (fs. 22) la mentada Dirección indicó que la contratación propiciada se refería a la “implementación de un sistema de Servicios Informáticos Judiciales de acuerdo a lo establecido en la Resolución CM Nº 25/2015, o sea la Arquitectura Básica, para la contratación de un sistema de integración de los sistemas existentes incluyendo el desarrollo de Firma Digital, aplicando el paradigma de Arquitectura Orientada a Servicios más conocido por sus siglas en inglés SOA (Service Oriented Architecture)” e informó que el presupuesto estimado para la contratación en cuestión asciende a la suma de dos millones quinientos mil pesos ($ 2.500.000,00).
Que entonces, la Dirección de Compras y Contrataciones elaboró los proyectos de Pliego de Condiciones Particulares y de Especificaciones Técnicas y se los remitió a la Dirección General de Informática y Tecnología a fin de que los analizara técnicamente y que indicara -en relación al Punto 15 del Pliego de Condiciones Particulares- si debía incluirse o no la cláusula relacionada con los seguros a requerir a la adjudicataria (v. Memo DCC Nº 273/2015 de fs. 23/39). En respuesta, el área técnica indicó que no tenía observaciones que hacer respecto a los proyectos de pliegos en cuestión y que consideraba necesario incluir el seguro descripto en el Punto 15 del Pliego de Condiciones Particulares (cfr. Nota Nº 346 de fs. 41).
Que en consecuencia, la Dirección de Compras y Contrataciones entendió viable el llamado a Licitación Pública de etapa única, conforme lo dispuesto en los artículos 25, 27, 31, 32, 40 y concordantes de la Ley 2095, su modificatoria la Ley 4764 y su reglamentaria la Resolución CM N° 01/2014 (fs. 43). A su vez, agregó el Anexo III -Pliego de Bases y Condiciones Generales- de la Resolución CM Nº 01/2014 con la modificación introducida por Resolución Pres. N° 554/2014 (fs. 44/51), el proyecto de Pliego de Condiciones Particulares (fs. 52/57), el proyecto de Pliego de Especificaciones Técnicas (fs. 58/67), el modelo de aviso para la publicación del llamado en el Boletín Oficial de la Ciudad Autónoma de Buenos Aires (fs. 68) y el Criterio de Afectación –por personal- (fs. 69).
Que en cumplimiento con lo dispuesto por la Ley 70, la Dirección de Programación y Administración Contable realizó la afectación de las partidas presupuestarias necesarias para afrontar la contratación de marras (v. Constancia de Registración Nº 1295/06-2015 de fs. 70/71).
Que la Dirección General de Informática y Tecnología prestó conformidad al proyecto de Pliego de Condiciones Particulares elaborado por la Dirección de Compras y Contrataciones incorporado a fojas 37/46 (v. Nota Nº 234 de fs. 55).
Que en ese estado, la Dirección General de Asuntos Jurídicos tomó la intervención que le compete y emitió el Dictamen N° 6418/2015. Allí, realizó una breve reseña de lo actuado y el análisis jurídico de la presente Licitación y, en particular, advirtió un error material en el encuadre de la contratación efectuado por la Dirección de Compras y Contrataciones debido a que se contempló el artículo 40º de la Ley de Compras y Contrataciones -referido a Orden de Compra Abierta- siendo el artículo correcto el 44º de dicha normativa -referido a la modalidad llave en mano-. Luego, expuso: “(…) se eleva a fs. 52/57 el proyecto de Pliego de Condiciones Particulares. Con respecto al mismo, esta Dirección General no tiene objeciones jurídicas. Con relación al Pliego de Especificaciones Técnicas (fs. 58/67), el mismo ha sido elaborado por la Dirección General de Informática y Tecnología y esta Dirección General no es competente para su análisis”. Finalmente concluyó: “(…) teniendo en cuenta lo manifestado por la Dirección de Compras y Contrataciones (fs. 72/73), así como la normativa legal vigente aplicable, es opinión de esta Dirección General que no existe obstáculo, desde el punto de vista jurídico, para que se continúe con la tramitación del presente expediente” (fs. 79/80).
Que en este estado, puesto a resolver, en atención a los antecedentes antes relatados, a lo actuado por la Dirección de Compras y Contrataciones, lo expuesto por la Dirección General de Informática y Tecnología en su carácter de área técnica competente y en línea con lo dictaminado por el área de asesoramiento jurídico permanente de este Organismo, corresponderá autorizar el llamado a Licitación Pública N° 19/2015 de etapa única bajo la modalidad de llave en mano que tiene por objeto la contratación del desarrollo del software para la realización del sistema informático denominado Servicios Informáticos Judiciales (SIJ) – Arquitectura Básica, para el Poder Judicial (áreas administrativa y jurisdiccional) de la Ciudad Autónoma de Buenos Aires, en la forma, cantidades y según las características especificadas en el Pliego de Bases y Condiciones Particulares y en el Pliego de Especificaciones Técnicas que serán aprobados como Anexos I y II del presente acto, con un presupuesto oficial de dos millones quinientos mil pesos ($ 2.500.000,00) IVA incluido.
Que de conformidad con lo dispuesto en el inciso g) del artículo 86° del Anexo I de la Resolución CM N° 01/2014 y con el objeto de fomentar una amplia participación de los oferentes en el presente procedimiento de selección, corresponderá establecer que la entrega de los pliegos necesarios para cotizar en la Licitación Pública Nº 19/2015 sea sin cargo.
Que finalmente, se instruirá a la Dirección de Compras y Contrataciones a efectos de que por su intermedio se instrumenten las medidas correspondientes para dar curso al llamado a Licitación Pública N° 19/2015 y para que realice las publicaciones y notificaciones de este acto conforme lo establecido en la Ley N° 2095, su modificatoria Ley N° 4764, su reglamentación y en la Ley de Procedimientos Administrativos -Decreto 1.510/97-.
Por ello, en ejercicio de las atribuciones conferidas por la Ley 31 y sus modificatorias;
EL ADMINISTRADOR GENERAL DEL
PODER JUDICIAL DE LA CIUDAD
RESUELVE:
Artículo 1º: Autorícese el llamado a Licitación Pública Nº 19/2015 de etapa única bajo la modalidad de llave en mano que tiene por objeto la contratación del desarrollo del software para la realización del sistema informático denominado Servicios Informáticos Judiciales (SIJ) – Arquitectura Básica, para el Poder Judicial (áreas administrativa y jurisdiccional) de la Ciudad Autónoma de Buenos Aires, en la forma, cantidades y según las características especificadas en el Pliego de Bases y Condiciones Particulares y en el Pliego de Especificaciones Técnicas que serán aprobados como Anexos I y II del presente acto, con un presupuesto oficial de dos millones quinientos mil pesos ($ 2.500.000,00) IVA incluido.
Artículo 2º: Apruébense el Pliego de Bases y Condiciones Particulares y el Pliego de Especificaciones Técnicas de la Licitación Pública N° 19/2015 que como Anexos I y II integran la presente Resolución.
Artículo 3º: Apruébese el Modelo de Aviso para la publicación del presente llamado en el Boletín Oficial de la Ciudad Autónoma de Buenos Aires que como Anexo III integra la presente Resolución.
Artículo 4º: Establézcase la entrega sin cargo de los pliegos necesarios para ofertar en la Licitación Pública Nº 19/2015 con el objeto de fomentar una amplia participación en este llamado.
Artículo 5º: Establézcase el 07 de setiembre de 2015 a las 12:00 horas como fecha límite para recibir consultas relacionadas con la presente licitación y el 14 de setiembre de 2015 a las 12:00 horas como fecha límite de presentación de ofertas y apertura pública de las ofertas.
Artículo 6º: Instrúyase a la Dirección de Compras y Contrataciones a efectos de que por su intermedio se instrumenten las medidas correspondientes para dar curso al llamado a Licitación Pública N° 19/2015 y para que realice las publicaciones y notificaciones de este acto conforme lo establecido en la Ley N° 2095, su modificatoria Ley N° 4764, su reglamentación y en la Ley de Procedimientos Administrativos -Decreto 1.510/97-.
Artículo 7º: Regístrese, publíquese como se ordenara y comuníquese a la Dirección General de Informática y Tecnología y a la Dirección de Programación y Administración Contable. Pase a la Dirección de Compras y Contrataciones, a sus efectos.
Res. OAyF Nº 253 /2015
ANEXO I
LICITACIÓN PUBLICA N° 19/2015
SERVICIOS INFORMÁTICOS JUDICIALES (SIJ) – ARQUITECTURA BÁSICA
PLIEGO DE BASES Y CONDICIONES PARTICULARES
1. GENERALIDADES
2. OBJETO DE LA CONTRATACIÓN
3. PLIEGO
4. RENGLONES A COTIZAR
5. MODALIDAD DE LA CONTRATACIÓN
6. PLAN DE TRABAJO, ENTREGA Y CAPACITACIÓN
7. ANTECEDENTES DEL OFERENTE
8. PERSONAL DE LA ADJUDICATARIA
9. PROPIEDAD INTELECTUAL
10. FORMA DE COTIZACIÓN
11. PLAZO DE MANTENIMIENTO DE LA PROPUESTA ECONOMICA
12. DICTAMEN DE LA COMISION EVALUADORA. ANUNCIO. IMPUGNACION
13. CRITERIO DE EVALUACION Y SELECCION DE LAS OFERTAS
14. ADJUDICACION
15. SEGUROS
16. GARANTÍA
17. PENALIDADES
18. FORMA DE PAGO. ANTICIPO FINANCIERO
19. PRESENTACIÓN DE LAS OFERTAS
20. APERTURA DE LAS OFERTAS
21. COMUNICACIONES Y CONSULTAS. DENUNCIA DE DIRECCIÓN DE CORREO ELECTRÓNICO
22. PRESUPUESTO OFICIAL
PLIEGO DE BASES Y CONDICIONES PARTICULARES
1. GENERALIDADES
El presente Pliego de Condiciones Particulares tiene por objeto completar, aclarar y perfeccionar las estipulaciones del Pliego de Bases y Condiciones Generales para la Contratación de Bienes y Servicios, para la contratación de referencia aprobado por Resolución CM N°01/2014.
2. OBJETO DE LA CONTRATACIÓN
La Licitación Pública Nº 19/2015 es una licitación de etapa única bajo la modalidad de llave en mano y tiene por objeto la contratación del desarrollo del software para la realización del sistema informático denominado Servicios Informáticos Judiciales (SIJ) – Arquitectura Básica, para el Poder Judicial (áreas administrativa y jurisdiccional) de la Ciudad Autónoma de Buenos Aires.
3. PLIEGO
Sólo se tendrán en cuenta las propuestas presentadas por las firmas que hayan retirado los Pliegos que rigen la presente Licitación Pública, los que serán entregados sin cargo.
Los interesados podrán concurrir de lunes a viernes de 11.00 a 17.00 horas y hasta el día anterior a la apertura de las ofertas a la Dirección de Compras y Contrataciones del Consejo de la Magistratura, sita en Av. Julio A. Roca 530 Piso 8° de esta Ciudad, a los efectos de retirar los respectivos Pliegos.
La Dirección de Compras y Contrataciones emitirá una constancia de retiro de los respectivos Pliegos, la que se deberá acompañar en forma obligatoria junto a la oferta, conforme Art. 102º de la Ley N 2095, y su modificatoria Ley N° 4.764, reglamentada por Resolución CM Nº 01/2014.
4. RENGLON A COTIZAR
Renglón 1: Contratación del desarrollo del software para la implementación de un sistema informático denominado Servicios Informáticos Judiciales (SIJ) – Arquitectura Básica, para el Poder Judicial de la C.A.B.A., de conformidad con las características indicadas en el presente Pliego de Condiciones Particulares y en el Pliego de Especificaciones Técnicas de la Licitación Pública N° 19/2015.
5. MODALIDAD DE LA CONTRATACIÓN
La presente contratación se efectúa bajo la modalidad llave en mano, lo cual implica que se contratará a través de un único proveedor la realización integral del proyecto solicitado, de manera que los oferentes deberán realizar una solución integral que satisfaga las necesidades de este Consejo de la Magistratura.
La propuesta deberá incluir el análisis, diseño e implementación de los siguientes servicios, etapas o tareas, así como también podrá incluir la adquisición de componentes (tecnologías informáticas).
|
Etapas de Implementación de Servicios |
|
Análisis |
|
Diseño |
|
Desarrollo |
|
Implantación |
|
Documentación |
|
Aseguramiento de Calidad de Software |
|
Prueba de Programas |
|
Capacitación |
|
Garantía |
|
Mantenimiento y/o Actualización |
|
Adquisición de Componentes |
|
Herramientas de Desarrollo |
|
Servidor de Aplicaciones |
El servicio solicitado deberá cumplir con la incorporación de todos los servicios y componentes pedidos y con los demás requerimientos técnicos y funcionales que se describan o se soliciten en el presente Pliego de Condiciones Particulares y en el Pliego de Especificaciones Técnicas.
El aplicativo o sistemas de información así como también los componentes tecnológicos objeto de la presente contratación deberán quedar correctamente instalados y funcionando según lo solicitado en el presente Pliego y en el Pliego de Especificaciones Técnicas.
En cada una de las distintas etapas del proyecto, el adjudicatario deberá dar cumplimiento y satisfacción a las funcionalidades, requerimientos y tiempos explicitados en el presente Pliego y en el Pliego de Especificaciones Técnicas.
6. PLAN DE TRABAJO, ENTREGA Y CAPACITACIÓN
6.1 Plan de Trabajo
Junto con su propuesta el oferente deberá adjuntar el Plan de Trabajo, el cual deberá contener mínimamente el detalle de las tareas desde el inicio de los trabajos hasta la culminación del proyecto objeto de la presente contratación bajo la modalidad de llave en mano.
Se deberán indicar como mínimo los lapsos de tiempo y el personal asignado a cada una de las tareas desde el inicio de los trabajos.
6.2 Cronograma de Entrega:
La entrega de cada una de las etapas del servicio de implementación de la presente contratación se realizará conforme con el siguiente cuadro:
|
Etapas de Desarrollo de Servicios |
Componentes |
Semana |
|
Etapa I: Construcción de la Arquitectura Básica de SIJ |
Construcción del SIJ |
1-12 |
|
Adquisición de Componentes |
Semana |
|
Herramientas de Desarrollo |
1-12 |
|
Servidor de Aplicaciones |
6.3 Plazo de Ejecución
La adjudicataria deberá efectuar todas las prestaciones objeto de la presente contratación dentro del plazo máximo de noventa (90) días corridos, contados a partir de la recepción de la correspondiente Orden de Compra.
La percepción del Anticipo Financiero contemplado en el Punto 18 del presente Pliego, en caso de hacer uso de dicha posibilidad, no provocará la suspensión del plazo máximo de ejecución estipulado.
6.4 Plan de Capacitación
Junto con su propuesta el Oferente deberá presentar un plan de capacitación para el correcto uso y mantenimiento.
La capacitación cubrirá todos los aspectos teóricos y prácticos necesarios para alcanzar el desempeño adecuado en cada etapa, por lo tanto se deberá brindar en cada caso un cabal conocimiento de los sistemas y del uso de la documentación pertinente al mismo.
En el Anexo III del Pliego de Especificaciones Técnicas se describen los cursos mínimos solicitados, indicando Nombre del curso, Objetivo, Perfil del Auditorio, Cantidad de Personas, Duración y Material Didáctico.
7. ANTECEDENTES DEL OFERENTE
La oferta deberá contener referencias de instalaciones similares a la que resulta objeto de la presente contratación, ya sea a nivel local o internacional, realizadas y que se encuentren en plena operatividad. En tal sentido, por cada uno de los antecedentes consignados, deberá indicarse:
- Nombre de la empresa.
- Dirección.
- Nombre y Apellido del responsable (contacto).
- Teléfono.
- Desarrollo (nombre y breve descripción).
El oferente deberá acreditar fehacientemente la realización de servicios de desarrollo de similares características técnicas y operativas (cantidad de usuarios 5000 totales y 350 concurrentes como mínimo).
8. PERSONAL DE LA EMPRESA
Para el normal desarrollo del servicio solicitado la empresa adjudicataria deberá disponer, como mínimo, de la cantidad de profesionales que se indica a continuación:
|
Personal |
Cantidad |
|
Project Manager |
1 |
|
Arquitecto SOA |
1 |
|
Analista Funcional SOA |
1 |
|
Líder Técnico SOA |
1 |
|
Desarrollador SR SOA |
1 |
|
Desarrollador SSR SOA |
3 |
|
Especialista Infraestructura |
1 |
|
Desarrollador Web SR |
1 |
|
Desarrollador Web SSR |
1 |
|
QA Web SR |
1 |
El personal de la empresa adjudicataria deberá ser idóneo, certificado en el área correspondiente, estar provisto de identificación adecuada y de los elementos de seguridad establecidos por los organismos que reglamentan la actividad.
La adjudicataria queda obligada a ocupar el personal que resulte necesario con arreglo a las disposiciones laborales vigentes.
El personal utilizado por la adjudicataria para efectuar los trabajos objeto de la presente contratación no tiene ningún tipo o forma de relación de dependencia con el Consejo de la Magistratura.
Junto con su propuesta, el oferente deberá presentar un listado del personal que ejecutará las tareas, adjuntando asimismo, por cada uno de ellos, la siguiente información:
- Currículum Vitae.
- Detalle de las certificaciones aprobadas.
- Detalle de participación en proyectos de la compañía.
- Detalle de cuál sería su actividad en el servicio solicitado.
Queda bajo exclusiva responsabilidad del adjudicatario todo accidente de trabajo que ocurra a su personal o a terceros vinculados o no con la prestación del servicio, como asimismo el cumplimiento de todas las obligaciones determinadas por la legislación laboral, previsional y fiscal.
El adjudicatario asume la responsabilidad por el personal a su cargo, obligándose a reparar cualquier daño y/o perjuicio que se origine en el obrar durante la ejecución de las tareas.
El adjudicatario deberá designar un coordinador que oficiará de interlocutor y que será el responsable del seguimiento y el control de calidad de la prestación del servicio. Por su parte, el Consejo de la Magistratura designará un representante que será el encargado de planificar y controlar la prestación del servicio según lo descripto en el presente Pliego de Condiciones Particulares y en el Pliego de Especificaciones Técnicas.
El consejo de la Magistratura podrá solicitar a la adjudicataria por razones justificadas el cambio del coordinador asignado.
9. PROPIEDAD INTELECTUAL
9.1 Propiedad Intelectual Exclusiva del Software Desarrollado
El Consejo de la Magistratura de la Ciudad Autónoma de Buenos Aires será el propietario exclusivo de todos los derechos de propiedad intelectual, incluyendo todos sus elementos, código fuente, código objeto y documentación pertinente. El derecho de explotación de la aplicación informática en cualquiera de sus formas y de los programas desarrollados al amparo de la presente contratación corresponden únicamente al Estado con exclusividad y a todos sus efectos.
Se considera Propiedad Intelectual del Consejo de la Magistratura de la Ciudad Autónoma de Buenos Aires a todo invento o creación intelectual, conformación, datos del negocio tanto técnicos como comerciales, métodos, normas, procedimientos relevados por la Adjudicataria o con la cual la misma haya tomado contacto durante el desarrollo de las actividades de la presente contratación.
Asimismo, será propiedad del Consejo de la Magistratura de la Ciudad Autónoma de Buenos Aires todo invento y/o creación intelectual que el adjudicatario realice como objeto de la presente contratación y que se derive de procedimientos, métodos, instalaciones, experimentaciones, investigaciones o de la utilización de medios proporcionados por el Consejo de la Magistratura de la C.A.B.A.
Se entiende y define por Invento o Creación Intelectual a:
- Todo plan, regla, método, fórmula, diseño o combinación de los mismos que se desarrolle en forma creativa en ocasión de la relación entre el Consejo de la Magistratura de la Ciudad Autónoma de Buenos Aires y el proveedor.
- La elaboración y desarrollo de programas de ordenadores que sean de utilidad para el Consejo de la Magistratura de la Ciudad Autónoma de Buenos Aires.
- Toda forma creativa publicitaria, materializada en bocetos, storyboards, guiones, frases, desarrollo de marcas, logos, isologos, colores institucionales, etc., destinadas a la presentación de información y/o promoción del Consejo de la Magistratura de la C.A.B.A.
- Quedan incluidas dentro del concepto de invención y/o descubrimiento cualquier tipo de mejora o perfeccionamiento que se logre de métodos/sistemas/procedimientos ya empleados por el Consejo de la Magistratura de la C.A.B.A.
- Se consideran incluidas las invenciones patentables o creaciones intelectuales registrables como también aquellas innovaciones que no lo sean.
Los componentes de tecnologías informáticas incluidos en la presente contratación serán de propiedad del uso del Consejo de la Magistratura de la Ciudad Autónoma de Buenos Aires. Para los casos de software se deberá indicar si las licencias de uso ofrecidas son por tiempo indeterminado o determinado indicando el costo de actualización y mantenimiento.
9.2 Responsabilidad
El Consejo de la Magistratura deslinda toda responsabilidad por ofertas que no estén encuadradas dentro de las normas legales vigentes relativas a la ley de derechos de autor, a la ley de patentes y a las normas aplicables en materia de secretos comerciales o ley de confidencialidad, siendo el oferente y/o adjudicatario responsable por la legalidad de los productos ofrecidos y/o adjudicados, garantizando la total indemnidad o garantía al Consejo de la Magistratura en caso de reclamo de terceros por infracción a sus derechos.
En tal sentido, el oferente/adjudicatario será responsable por las demandas judiciales que pudieran establecerse por el uso ilícito de marcas, patentes y/o derechos de autor pertenecientes a terceros.
9.3 Confidencialidad de la Información:
El adjudicatario queda expresamente obligado a mantener absoluta confidencialidad y reserva sobre cualquier dato que pudiera conocer en ocasión del cumplimiento del contrato, especialmente los de carácter personal, que no podrá copiar o utilizar con fin distinto al que figura en este Pliego, ni tampoco ceder a otros ni siquiera a efectos de conservación.
10. FORMA DE COTIZACIÓN
Las ofertas deberán ser presentadas por duplicados, en pesos, indicando el monto total en números y en letras por la solución propuesta.
10.1 Descripción detallada de la solución propuesta:
Se deberán describir con mayor grado de detalle las características técnicas que tendrá la solución ofrecida en cuanto a arquitectura, diseño, seguridad, resguardo de información, utilización de tecnologías informáticas, documentación, performance (rendimiento), procedimientos de prueba, etc.
10.2 Componentes de tecnologías:
Por cada componente tecnológico se deberán adjuntar folletos técnicos y/o manuales necesarios para una adecuada evaluación de las tecnologías ofrecidas. En caso de presentarse fotocopias de manuales las mismas deberán estar certificadas como copia fiel.
El oferente deberá dejar expresa constancia respecto del grado de cumplimiento de cada uno de los puntos incluidos en los requisitos técnicos mínimos que deben cumplir los componentes. No se admitirá especificar simplemente “según pliego” como identificación del equipamiento ofrecido.
La ausencia de información requerida determinará, a juicio del Consejo de la Magistratura, que considere que la oferta no se ajusta a lo solicitado y sea desestimada.
11. PLAZO DE MANTENIMIENTO DE LA PROPUESTA ECONOMICA
Los oferentes deberán mantener las ofertas por el término de treinta (30) días, contados a partir de la fecha de apertura de las ofertas. Al vencimiento del plazo fijado para el mantenimiento de las ofertas, éste se prorrogará por sucesivos plazos de treinta (30) días, de manera automática, salvo que el oferente se opusiera a una nueva prórroga automática, por escrito, con al menos quince días de anticipación al vencimiento del plazo en el que se encuentra incurso.
Si el oferente no mantuviera el plazo estipulado en el párrafo anterior, será facultad de este Consejo de la Magistratura considerar o no las ofertas así formuladas, según convenga a sus propios intereses.
12. DICTAMEN DE LA COMISION EVALUADORA. ANUNCIO. IMPUGNACION
El Dictamen de Evaluación de las Ofertas (Dictamen de Preadjudicación) se comunicará en forma fehaciente a todos los oferentes, conforme el Art. 106º, Inc. e) del Anexo I de la Resolución CM Nº 1/2014. Asimismo, se publicará en el Boletín Oficial y en la Web del Consejo de la Magistratura www.jusbaires.gov.ar.
Las impugnaciones al Dictamen de Evaluación se harán conforme el Art. 99º del Anexo I de la Resolución CM Nº 1/2014 y al Art. 18º del PCG.
Conforme los Arts. 106º in fine y 109º in fine del Anexo I de la Resolución CM Nº 1/2014 y al Art. 17º del PCG, los interesados podrán formular las impugnaciones dentro del plazo de tres (3) días a contar desde la notificación del acto administrativo que concluye el procedimiento de selección.
La impugnación de los pliegos se realizarán conforme el Art. 17º in fine del PCG, estableciéndose como Garantía de Impugnación al Pliego (Art. 14º, Inc. d) del PCG) un porcentaje del tres por ciento (3%) del presupuesto oficial de la presente Licitación Pública.
13. CRITERIO DE EVALUACION Y SELECCION DE LAS OFERTAS
La adjudicación se realizará a la oferta más conveniente a los intereses del Consejo de la Magistratura. Para ello, una vez apreciado el cumplimiento de los requisitos y exigencias estipulados en la normativa vigente y en los Pliegos de Bases y Condiciones Generales y de Condiciones Particulares y de Especificaciones Técnicas, se considerarán el precio y la calidad de los bienes y/o servicios ofrecidos, conjuntamente con la idoneidad del oferente y demás condiciones de la propuesta.
El Consejo de la Magistratura podrá solicitar demostraciones del grado de cumplimiento de cada uno de los requisitos mínimos especificados, como así también cualquier otra cuestión que considere de interés.
14. ADJUDICACION
La adjudicación de la presente contratación recaerá en un único oferente.
15. SEGUROS
El adjudicatario deberá, previo al inicio de las prestaciones:
15.1. Presentar las pólizas de los seguros obligatorios de vida y por accidentes de trabajo de todo el personal que afecte a esta prestación, acreditándolos con la correspondiente inscripción en la aseguradora correspondiente (ART).
15.2.Contar con un seguro de responsabilidad civil frente daños a terceros y sus pertenencias, por hechos ocurridos como consecuencia de la ejecución de los trabajos contratados no inferior a Pesos trescientos Mil ($ 300.000,00), que permanecerá vigente hasta cumplidos tres (3) meses de la cuarta prestación semestral.
En caso de que el monto de los seguros contratados no alcanzare a cubrir los daños provocados, las diferencias resultantes deberán ser cubiertas exclusivamente por el adjudicatario. De igual manera, en caso de insolvencia o quiebra de la aseguradora, el adjudicatario deberá afrontar por su exclusiva cuenta y cargo todos los daños en cuestión, debiendo dejar liberado al Consejo de la Magistratura de cualquier responsabilidad al respecto. Si el adjudicatario dejase de contratar y mantener en vigor los seguros especificados en el presente Pliego, el Consejo de la Magistratura podrá en tales casos - al margen de cualquier otro derecho o recurso que pudiera ejercer- contratar y mantener en vigor dichos seguros y pagar las primas necesarias que fueran debitadas por el adjudicatario. El Consejo de la Magistratura deducirá las primas así desembolsadas del primer certificado presentado por el adjudicatario.
Dado que estos seguros cubren riesgos o responsabilidades respecto a los cuales el adjudicatario es responsable de acuerdo con estos documentos contractuales, será obligación del mismo notificar a los aseguradores sobre cualquier cuestión o evento que requiera dicha notificación de acuerdo con las cláusulas aplicables de las pólizas correspondientes. El adjudicatario será responsable por todas las pérdidas, reclamos, acciones judiciales, costas, costos y gastos de cualquier índole originados o resultantes de cualquier incumplimiento de dichos requerimientos.
Correrán por cuenta del adjudicatario los intereses y costos por pago fuera de término y las consecuencias económicas y contractuales por la no vigencia de las Pólizas de Seguro.
El Consejo de la Magistratura podrá suspender los trabajos por falta de cobertura, no siendo ello causa de prórroga del programa de trabajo.
Los seguros serán contratados, con una aseguradora a satisfacción del Consejo de la Magistratura, e incluirá a éste como beneficiario de los mismos.
16. GARANTÍA
El servicio de desarrollo de software debe contar con un año de garantía, contado a partir de la fecha de la recepción definitiva del mismo, y cubrirá las tareas descriptas en el Anexo III del Pliego de Especificaciones Técnicas.
17. PENALIDADES
El retraso por parte de la Adjudicataria en el cumplimiento de los tiempos máximos de entrega expresados en el Punto 6.2 del presente Pliego dará lugar a la aplicación de las siguientes penalidades:
- Multa del 0,125 % del monto total de la Etapa cuya entrega se encuentre atrasada, por cada día de retraso, cuando el retraso no supere el mes.
- Multa del 0,25 % del monto total de la Etapa cuya entrega se encuentre atrasada, por cada día de retraso, cuando el retraso supere el mes.
18. FORMA DE PAGO. ANTICIPO FINANCIERO
El pago de la presente contratación se efectuará conforme al Pliego de bases y Condiciones Generales.
El oferente podrá solicitar, incluyéndolo en su propuesta económica, hasta un cuarenta por ciento (40%) del monto adjudicado, en concepto de anticipo financiero. El adjudicatario deberá presentar un seguro de caución por el importe que se le anticipe, que tendrá vigencia hasta la recepción definitiva de los bienes adjudicados.
El importe adelantado se descontará al liquidarse los montos facturados.
19. PRESENTACIÓN DE LAS OFERTAS
Las ofertas deberán ser presentadas de lunes a viernes en el horario de 08:00 a 17:00 horas y hasta las *** horas del día *** de agosto de 2015, en sobre cerrado, en la Mesa de Entrada de este Consejo, sito en Av. Julio A Roca 530, PB de esta Ciudad, debiendo estar dirigidas a la Unidad de Evaluación de Ofertas, e indicando como referencia la leyenda “Licitación Pública Nº 19/2015 - Expediente CM Nº OAyF-158/15-0”.
20. APERTURA DE LAS OFERTAS
La apertura de los sobres será pública y tendrá lugar el día *** de ********* de 2015 a las *** horas, en la sede del Consejo de la Magistratura, Av. Julio A Roca 530, Piso 8°, Ciudad de Buenos Aires, fecha y hora hasta las cuales se recibirán las propuestas económicas, según lo establece el Pliego de Bases y Condiciones Generales.
21. COMUNICACIONES Y CONSULTAS. DENUNCIA DE DIRECCIÓN DE CORREO ELECTRÓNICO
Complementando el Art. 6º del PCG, el oferente además de constituir domicilio legal dentro del ámbito de la Ciudad Autónoma de Buenos Aires, deberá denunciar una dirección de correo electrónico en donde serán válidas todas la comunicaciones efectuadas por el Consejo de la Magistratura, de conformidad con el Art. 4º del PCG.
Las consultas relacionadas con la presente contratación deberán efectuarse conforme lo establece el Art. 8º del PCG, hasta las 12:00 horas del día *** de agosto de 2015.
22. PRESUPUESTO OFICIAL
El presupuesto oficial de la presente contratación asciende a la suma de Pesos Dos Millones Quinientos Mil ($ 2.500.000.-) IVA incluido.
ANEXO II
LICITACIÓN PÚBLICA N° 19/2015
SERVICIOS INFORMÁTICOS JUDICIALES (SIJ) – ARQUITECTURA BÁSICA
PLIEGO DE ESPECIFICACIONES TÉCNICAS
1. GENERALIDADES
2. REQUERIMIENTOS FUNCIONALES
3. ARQUITECTURA DE LA APLICACIÓN
4. DOCUMENTACIÓN
5. RESGUARDO Y RECUPERO DE INFORMACIÓN
6. INTERACCIÓN CON OTROS SISTEMAS DE INFORMACIÓN
7. ESCALABILIDAD Y RENDIMIENTO
8. SEGURIDAD
9. MODULO DE PRUEBA DE PROGRAMAS
10. COMPONENTES
11. PROHIBICIONES
12. TRANSFERENCIA TECNOLÓGICA
ANEXO I – REQUERIMIENTOS FUNCIONALES
ANEXO II – ARQUITECTURA DE LA SOLUCIÓN
ANEXO III – PLAN DE PROYECTO
ANEXO IV – DOCUMENTACIÓN
PLIEGO DE ESPECIFICACIONES TÉCNICAS
1. GENERALIDADES
Las presentes especificaciones técnicas fijan los requerimientos mínimos a los que deberán ajustarse las tareas a realizar en el marco del servicio de implementación de un sistema denominado Servicios Informáticos Judiciales (SIJ) – Arquitectura Básica.
2. REQUERIMIENTOS FUNCIONALES
A efectos de que los posibles oferentes conozcan los límites y alcances del servicio de desarrollo objeto de la presente contratación, como Anexo I al presente Pliego de Especificaciones Técnicas se presenta la lista de requerimientos funcionales que el mismo deberá ser capaz de procesar y elaborar.
3. ARQUITECTURA DE LA APLICACIÓN
La solución a desarrollar deberá cumplir con la arquitectura de aplicación especificada en el Anexo II del presente Pliego de Especificaciones Técnicas, y deberá soportar 350 usuarios concurrentes.
4. DOCUMENTACIÓN
Se deberá presentar toda la documentación de cada etapa del servicio de desarrollo de software según lo solicitado en el Anexo IV del presente Pliego de Especificaciones Técnicas.
5. RESGUARDO Y RECUPERO DE INFORMACIÓN
La solución a desarrollar deberá cumplir con el método de resguardo y recupero de datos especificado en el Anexo III del presente Pliego de Especificaciones Técnicas.
6. INTERACCIÓN CON OTROS SISTEMAS DE INFORMACIÓN
La solución solicitada deberá interrelacionarse con otros sistemas informáticos del organismo tal cual lo que se describe en el Anexo III del presente Pliego de Especificaciones Técnicas.
7. ESCALABILIDAD Y RENDIMIENTO
Los siguientes tiempos máximos deberán estar en un todo de acuerdo con lo estipulado en el Anexo III del Presente Pliego de Especificaciones Técnicas:
- Tiempo máximo estimado de consulta (con independencia del volumen de datos y la cantidad de usuarios).
- Tiempo máximo estimado de Alta, Baja o modificación (con independencia del volumen de datos y la cantidad de usuarios).
- Tiempo máximo estimado para correr procesos batch (con independencia del volumen de datos y la cantidad de usuarios).
El sistema deberá ser capaz de soportar un crecimiento:
- En usuarios concurrentes de 350 usuarios como mínimo.
8. SEGURIDAD
En el Anexo III del presente Pliego de Especificaciones Técnicas se describen las condiciones de seguridad que deberá reunir la aplicación a nivel usuario, grupos de usuarios, registros de auditoria, acceso a datos, etc.
9. MODULO DE PRUEBA DE PROGRAMAS
La tarea de prueba del aplicativo buscará descubrir errores de definición de requerimientos y/o de programación.
Este módulo deberá ser entregado con el sistema por el oferente, incluyendo el código fuente y la documentación del mismo y podrá ser ejecutado por personal del organismo cada vez que se quiera auditar el funcionamiento del software.
La finalidad de contar con el módulo de pruebas permitirá tener una visión clara del estado del software para dicha tarea se deberá testear los siguientes puntos:
- Tiempos de respuesta.
- Sincronización en la ejecución de tareas.
- Ingreso de datos válidos.
- Realización exitosa de procesos.
- Cumplimiento de las condiciones de seguridad.
- Funcionamiento correcto ante la modificación de parámetros del sistema.
- Todo otro requerimiento detallado en el Anexo III del presente Pliego de Especificaciones Técnicas.
10. COMPONENTES
En el Anexo II del presente Pliego de Especificaciones Técnicas se describen todos los componentes informáticos que incluye la presente contratación.
11. PROHIBICIONES
La adjudicataria no podrá transferir parcial ni totalmente el servicio objeto de la presente contratación, teniendo responsabilidad total sobre la ejecución del contrato de servicio y su cumplimiento.
12. TRANSFERENCIA TECNOLÓGICA
Durante la ejecución de los trabajos objeto de la presente contratación, se deberá facilitar al grupo informático del Consejo de la Magistratura designado para el seguimiento y conocimiento del proyecto, la información y documentación que estos soliciten para disponer de un pleno conocimiento de las circunstancias en que se desarrollan los trabajos, así como de los eventuales problemas que puedan plantearse.
Anexo I – Requerimientos Funcionales
Introducción
La Arquitectura Orientada a Servicios (en inglés Service Oriented Architecture), es un paradigma de arquitectura para diseñar y desarrollar sistemas distribuidos. Las soluciones SOA han sido creadas para satisfacer los objetivos de negocio las cuales incluyen facilidad y flexibilidad de integración con sistemas legados, alineación directa a los procesos de negocio reduciendo costos de implementación, innovación de servicios a clientes y una adaptación ágil ante cambios incluyendo reacción temprana ante la competitividad.
Permite la creación de sistemas de información altamente escalables que reflejan el negocio de la organización, a su vez brinda una forma bien definida de exposición e invocación de servicios (comúnmente pero no exclusivamente servicios web), lo cual facilita la interacción entre diferentes sistemas propios o de terceros.
El crecimiento de las organizaciones viene acompañado de la introducción de nuevos sistemas a la actual infraestructura informática. Es por ello que es necesario que dichos sistemas se integren de forma tal que sus funciones específicas puedas ser utilizadas por el resto de los sistemas y vice-versa.
La idea de Servicios Informáticos Judiciales (SIJ) es actuar como integrador del resto de los sistemas legados de la Dirección General de Informática del Consejo de la Magistratura de la Ciudad de Buenos Aires.
SIJ tiene como objetivo prestar servicios básicos de plataforma de integración para los sistemas legados de las diferentes áreas del Consejo de la Magistratura. Sean estos, por mencionar algunos de ellos:
· Sistemas web
· Sistemas de gestión de expedientes judiciales
· Sistemas de gestión de expedientes internos
· Sistemas contables
· Sistemas de presupuestos
· ERP
Los servicios básicos de plataforma de integración serán configurados en el SIJ como módulos independientes de forma tal que los mismos siempre actúen mediante una interface y no directamente con la implementación. De esta forma, dichos servicios podrán ser reemplazados sin tener impacto en el usuario final de las aplicaciones, permitiendo de esta forma lograr una evolución de los sistemas a un bajo costo de implementación y migración.
Arquitectura Lógica
La idea central del SIJ es que actúe, mediante el bus de servicios, como un sistema de redireccionamiento de mensajes. Dichos mensaje, se irán enriqueciendo cada vez que ocurra una transición entre módulo y módulo.
Existirá entonces un flujo predeterminado para todos los mensajes que ingresen al bus a través de los servicios básicos de plataforma. Estos servicios básicos serán proveídos por los siguientes módulos:
· Módulo de Entrada (input) .
·
· Módulo de Seguridad
o Módulo de Autorización.
o Módulo de Autenticación.
· Módulo de Seguridad.
· Módulo de Autorización.
· Módulo de Autenticación.
· Módulo de Firma Digital.
· Módulo de Auditoría.
· Módulo de Workflow.
· Módulo de Output.
· Módulo de Validación.
· Módulo de Service Registry.
· Módulo de Administración.
Más adelante en este documento se explica en detalle la función de cada módulo en la arquitectura antes presentada
Módulos del SIJ
Todos los módulos deben contar con una interfaz común de forma tal que se pueda interactuar con los mismos de manera homogénea. Deben contar con una serie de métodos básicos para poder interactuar con el SIJ. Esto es:
· Info: para saber el ID del módulo y su configuración actual.
· Status: para determinar el estado del mismo.
· Operations: lista de operaciones que puede llevar a cabo este módulo y sus correspondientes parámetros.
· Sample: mensaje de ejemplo para determinar si el módulo está activo y respondiendo.
· Load: nivel de carga del módulo.
· invokeService: invocación de un servicio.
· Etc.
Es decir que debemos poder monitorear el estado completo del bus consultando con los métodos básicos de cada módulo.
Módulo de Entrada (Input)
Este módulo es el responsable de crear un mensaje en formato interno a partir del mensaje externo original. Dicha transformación es realizada para poder direccionarlo internamente.
Los mensajes en formato externo traen, entre otras cosas, los siguientes datos:
· Tipo de mensaje.
· Datos del mensaje.
· Datos del consumidor.
El primero, es el que determina qué operación se llevará a cabo dentro del SIJ. El segundo parámetro lleva los datos necesarios para realizar dicha operación. El tercero y último parámetro son los datos del consumidor del mensaje.
Es válido remarcar que cada módulo realiza su función específica y retorna el mensaje al bus de servicios. Para ello, debemos crear un formato de mensaje que permita transportar datos de direccionamiento y control del mismo.
El formato interno de los mensajes, tiene los siguientes parámetros:
· Identificador del mensaje.
· Módulo origen.
· Módulo destino.
· Estado del mensaje.
· Marca de tiempo.
· Tipo de mensaje.
· Datos del mensaje.
· Datos del consumidor.
· Log interno del mensaje.
Las transiciones de los mensajes a través de los módulos modifican el valor de los campos de control antes mencionados de forma tal que el mensaje quede persistido en todas las transiciones de estado. Cualquiera sea el caso de excepción, se puede reprocesar el mensaje y que el mismo siga su curso original.
Módulo de Seguridad
Este módulo es el responsable de todos los aspectos relacionados con la seguridad del SIJ. Está compuesto por los siguientes submódulos:
· Módulo de autenticación.
· Módulo de autorización.
· Módulo de Firma Digital.
La principal función es autenticar el mensaje entrante. Dado que existen diversas formas de autenticar un mensaje, la que debe ejecutarse está determinada al momento de declaración del servicio. De esta forma, se busca corresponder los parámetros “tipo de mensaje” y forma de autenticación.
Una vez autenticado, el mensaje se envía al Módulo de Autorización donde se determina si el usuario consumidor del servicio posee privilegios para ejecutarlo. Mediante la lista de ACL (Access Control List), esté módulo determina si el perfil de usuario autenticado tiene privilegios de ejecución para este tipo de mensaje.
Por último, la forma de autenticación y autorización de los mensajes es configurada de forma central desde el Módulo de Administración Por último, el Módulo de Firma Digital permite determinar la entidad originadora del mensaje y asegurar que el mismo no ha sido alterado desde que fue firmado por el originador. La firma digital se aplica en aquellos mensajes donde es importante poder verificar la autenticidad y la integridad de ciertos datos, por ejemplo documentos electrónicos o mensaje de aprobación o autorización de operaciones, ya que proporciona una herramienta para detectar la falsificación y la manipulación de contenido.
Módulo de Auditoría
Este módulo tiene como objetivo dejar constancia de las operaciones que se realizan en el SIJ. Debe estar diseñado de forma tal que, no impida ni retrase la ejecución del servicio. Es decir, debe ejecutar sus operaciones en segundo plano. Este módulo es uno de los más sobrecargados de todo el sistema, dado que cada transición de un mensaje tiene su correspondiente mensaje de auditoría para dejar constancia de dicha operación.
Junto con la estructura para auditar las operaciones, este módulo debe contar con una herramienta para visualizar y buscar los mensajes auditados por diferentes parámetros, como por ejemplo:
· Fecha.
· Entidad.
· Tipo de mensaje.
· Entidad originante
Etc.
Módulo de Workflow
Este módulo es el núcleo del SIJ dado que es quiéen establece el flujo que debe tener un mensaje entre los diferentes módulos. Funciona en interacción con el Módulo de Service Registry que tiene la lista de módulos del sistema y sus pares con los que puede interactuar cada uno. Es decir que tiene las transiciones autorizadas para cada módulo.
Este módulo es responsable de establecer la ruta de los mensajes. De esta forma, se puede controlar el flujo y enriquecimiento de los mensajes a través del SIJ. Desde el punto de vista lógico, este módulo necesita dos parámetros fundamentales para determinar la ruta del mensaje. Estos parámetros son:
· Tipo de mensaje.
· Módulo origen.
El módulo de Workflow debe contar con una interfaz de administración (en el Módulo de Administración) para poder gestionar el recorrido de los mensajes. Todos los módulos conectados al SIJ tienen los siguientes flujos:
· Flujo normal.
· Flujo de error.
· Flujo de excepción.
El Flujo Normal, es el camino que debe cumplir un mensaje si el mismo no sufre ninguna alteración. El flujo de error, por el contrario, es el camino alternativo cuando ocurre una situación que no es normal pero si esperada. El flujo de excepción, es el camino a seguir por un mensaje cuando ocurre una situación no contemplada. Este último incluye situaciones interrupciones en el flujo de un mensaje.
Módulo de Output (Salida)
Este módulo es el responsable de responder al consumidor del servicio mediante el canal establecido por este último. Es decir que, debe contar con una tabla para poder responder por el canal establecido para tal fin. Vale remarcar que el consumidor de un servicio puede variar su ubicación y formato de respuesta, requiriendo de esta forma que se modifique el canal. El módulo de output debe estar preparado soportar estas modificaciones.
Entre otras responsabilidades, es el encargado de transformar un mensaje en formato interno a uno en formato externo. Para responder, el módulo de salida busca en los registros del sistema por el identificador de mensaje establecido por el módulo de entrada y así determina a quién y cómo debe responder.
Módulo de Validación
El objetivo de este módulo es validar el correcto formato de los mensajes. Con la existencia de tal módulo se pretende no sobrecargar al SIJ con mensajes cuyo formato sea incorrecto y evitar su ejecución. El formato del mensaje debe ser correcto en estructura y cantidad de parámetros para que la ejecución de la operación será se canalice por el flujo normal.
Módulo de Service Registry
El Service Registry tiene como objetivo actuar un guía de los servicios que se publican en el SIJ. Esta guía de registros debe contar una interfaz web que permita consultar la lista de los servicios y los parámetros y formato requeridos de la siguiente forma:
· Web.
· JSON.
· XML.
· Web Service.
La idea de este módulo es que actúe como centro para la documentación y descubrimiento de los servicios.
Módulo de Administración
Este módulo es el responsable de administrar los sistemas legacy que se conectan el SIJ. Debe ser una consola de administración con una interfaz que permita realizar las siguientes operaciones:
· Alta/Baja/Modificación/Consulta (ABMC) de sistemas
· ABMC de tipos de mensajes asociados a un sistema
· ABMC de workflows asociado a los tipos de mensajes de un sistema
· ABMC de servicios asociados a los módulos de SIJ
· Interfaz de monitoreo de los módulos
Es válido remarcar que, el módulo de administración puede estar integrado a la herramienta que se utilice para la implementación del SIJ.
Módulo de Firma Digital
La plataforma de firma digital se compondrá como mínimo de los elementos que a continuación se indican, que operarán de forma sincronizada entre ellos.
Un sistema que permita la realización de firma digital del lado servidor, proporcionando seguridad y confianza a las aplicaciones que necesiten implementar funciones relacionadas con la misma.
Un sistema que permita la realización de firma digital del lado cliente, que resuelva la operativa de firma electrónica desde una interface web de usuario final, integrada a la aplicación.
Sistema de Firma Corporativa
El sistema de servicios de firma tendrá una arquitectura orientada a servicios (SOA), ofrecerá una interface de acceso a todos los servicios de PKI y sus funcionalidades serán accesibles mediante Web Services. El sistema tendrá las siguientes funcionalidades:
Firma digital. DEBE permitir la verificación y generación de firmas electrónicas, reconociendo diferentes prestadores de certificación. Permitirá la verificación de firmas a lo largo del tiempo, para lo cual habrá de generar y custodiar las evidencias electrónicas necesarias, garantizando el no repudio.
Gestión de claves. DEBE permitir registrar, consultar y verificar las claves de las entidades.
No-repudio digital. DEBE proveer servicios de generación y validación de evidencias digitales, generalmente acompañadas de firma electrónica
Autenticación, autorización y control de acceso. DEBE permitir la autenticación, autorización y control del acceso de las entidades registradas.
Gestión de objetos y entidades. DEBE disponer de funciones de registro, consulta y modificación de la información sobre entidades, en particular, información de identidad del titular de un certificado, nombre de los firmantes de un documento, la fecha/hora contenida en un sello de tiempo, configuración y auditoría
Protección y custodia de datos. DEBE disponer de componentes que permitan la protección de datos, claves, firmas y documentos firmados, y su custodia, a lo largo del tiempo, garantizando el acceso a éstos por las personas autorizadas.
Auditoría y Registro. DEBE disponibilizar de forma centralizada y segura toda la información de traza generada por cualquiera de los componentes de servicio del sistema, así como la información de uso y/o consumo de los servicios. Permitirá generar diversos tipos de informes.
Servicios adicionales. Se DEBE incluir los servicios de sellado de tiempo y de verificación de los certificados digitales, los cuales podrán o no ser incluidos en la solución final.
Se valorará que disponga de un sistema de administración de políticas encargado de suministrar las políticas de decisión, con arreglo a la siguiente funcionalidad:
Políticas de validación de documentos. Se utilizarán para definir cómo se va a llevar a cabo la verificación de documentos: sólo la firma, la firma y la caducidad del certificado, la firma y el estado de revocación del certificado, la firma, la caducidad y estado de revocación del certificado, etc. Se podrán definir niveles de validación global, o por Autoridades de Certificación.
Políticas de sellado / resellado de tiempo. Se aplicarán en el proceso de resellado de tiempo de los documentos en custodia. Indicarán los periodos y las cadencias de este proceso.
Políticas de control de acceso a documentos. Indicarán quién y con qué privilegios puede acceder a una aplicación.
Políticas de control de acceso a servicios. Indicarán los usuarios que van a poder acceder a los servicios de la plataforma y con qué permisos.
Políticas de control de acceso generales, determinarán a qué recurso puede acceder una entidad
El sistema de servicios de firma se entenderá como una plataforma común de gestión de servicios, e incluirá la configuración, monitorización y control de acceso de cada uno de los componentes de servicio. Dicho sistema presentará las siguientes características:
El acceso a los servicios se realizará mediante SOAP según la especificación WSDL de cada servicio en concreto, que será controlado mediante Token de autenticación.
La interacción cliente-servidor se realizará sobre transporte HTTPS de forma que se puede securizar el canal con SSL/TLS con o sin autenticación mutua.
El sistema cumplirá los siguientes estándares:
Estándares de infraestructura: WSDL (Web Service Description Language), SOAP (Simple Object Access Protocol), XML/XSD (Extensible Markup Language / XML Schema Definition)
Estándares de seguridad: SSL (Secure Socket Layer), TLS (Transport Layer Security)
Estándares de firma electrónica y cifrado: PKCS#7/CMS, S/MIME, PDF-Sig, XML-Dsig, XML-Enc, CAdES y XAdES.
Servicios de seguridad: DSS (Digital Signature Service Core Protocols, Elements, and Bindings, OASIS. Draft), valorándose adecuadamente el cumplimiento de alguno de los siguientes estándares de servicios de seguridad: Liberty ID-WSF (Liberty ID-WSF Authentication Service Specification), WSTrust (Web Services Trust Language), WS-Federation (Web Services Federation Language)
Soporte de certificados digitales: X509 (ITU-T Recommendation X509v3)
Soporte de los estándares de sobre digital: PKCS#7 (Public Key Cryptography Standard, IETF RFC 2315), CMS (Cryptographic Message Syntax, IETF RFC 3369), SMIME2 (Secure Multipurpose Internet Mail Extensions Version 2, IETF RFC 2311), SMIME3 (Secure Multipurpose Internet Mail Extensions Version 3, IETF RFC 2633), CAdES (Electronic Signatures and Infrastructures (ESI); Electronic Signature Formats, ETSI TS 101 733), XML-Dsig (XMLSignature Syntax and Processing, W3C Recommendation), XML-Enc (Encryption Syntax and Processing. W3C Recommendation), XAdES (XML Advanced Electronic Signatures. ETSI TS 101 903), PDF (Firma electrónica PKCS#7/CMS en los documentos PDF según las especificaciones de firma digital y cifrado de clave pública para PDF de Adobe y de RFC 3778 de IETF)
Soporte de sellado de tiempo digital: TSP (Time-Stamp Protocol, IETF RFC 3161).
Verificación de estado de certificados digitales: CRL (ITU-T Recommendation X509v3) y OCSP (Online Certificate Status Protocol, IETF RFC 2560)
Directorio: LDAP (Lightweight Directory Access Protocol)
Soporte HSM: PKCS#11 (Cryptographic Token Interface Standard).
Se valorará adecuadamente que la tecnología elegida disponga de algún reconocimiento y/o certificación de seguridad (Common Criteria, FIPS, etc.)
Todo el HW y SW de base (Sistemas Operativos, Bases de datos) serán provistos por el contratante. Se DEBE incluir las necesidades de dimensionamiento necesarias para el correcto funcionamiento de la plataforma.
Todo el HW del módulo de Firma Digital será provisto por el contratante.
Toda la solución deberá contar con Alta Disponibilidad en todos sus componentes.
El sistema será escalable de forma vertical para soportar la carga de trabajo prevista. En cuanto al licenciamiento del software no existirá ninguna limitación en cuanto al número de entidades (usuarios, aplicaciones, web services, etc.) que utilicen el Sistema de Servicios de Firma.
Sistema de firma de cliente
Deberá permitir al usuario realizar tanto la firma electrónica de los documentos generados por el mismo, como la de aquellos documentos generados por otros usuarios o aplicaciones corporativas que requieran de su firma. Este sistema operará de forma totalmente compatible y en conjunción con el sistema de firma electrónica descrito anteriormente. En cuanto al licenciamiento del software no existirá ninguna limitación en cuanto al número de usuarios que utilicen el Sistema.
DEBE permitir la utilización tanto de certificados alojados en un dispositivo criptográfico como en software
DEBE permitir la firma de cualquier tipo de documento de los reconocidos (MS-Office, PDF, DAT, ZIP, BIN, HTML, etc.).
Cuanto al HW, los requerimientos mínimos de cada nodo de la solución a implementar son:
2 vCPU
16 Gb RAM
500 Gb HDD (sistemas)
2 Tb HDD DBMS
Deberá Se implementarse umn nodo por cada componente de la solución
Sistemas Existentes
Al igual que el resto de los módulos el SIJ debe soportar la extensión dinámica de módulos para los sistemas legados del consejo. Todos los módulos deben compartir la misma interface descrita en este documento en el punto de este anexo Módulos del SIJ.
ANEXO II – Flujo de mensajes por la Arquitectura BásicaArquitectura de la aplicación
A continuación se detalla el flujo que deben cumplir los mensajes a través de los módulos descriptos en el Anexo I – “Requerimientos Funcionales” de este documento:
1. Recepción de mensajes externos
La siguiente figura ilustra el formato que deben tener los mensajes que llegan al SIJ (servicios protegidos por autenticación) con pedido de. Dependiendo el tipo de mensaje y su correspondiente configuración, el módulo de autenticación utiliza la forma establecida para autenticar el mensaje. La forma de autenticación se configura desde el módulo de configuración:
2.
Conversión de mensajes al formato interno del SIJ
Una vez autenticado el mensaje, si el proceso es exitoso el mensaje se convierte al formato interno, agregando así los parámetros necesarios para su flujo por los diferentes módulos:
En caso de que la autenticación sea fallida, se debe dejar un registro en el módulo de Auditoría.
La conversión del mensaje al formato interno, agrega los siguientes parámetros:
· Id de mensaje:
· iIdentificador único de mensaje.
· Workflow:
· Es el flujo por los diferentes módulos establecido para este tipo de mensaje:
· SourceModule:
· Es el módulo origen del mensaje:
· TargetModule:
· Es el módulo hacia donde se dirige el mensaje.
· Status:
· eEstado del mensaje.
· TimeStamp:
· mMarca de tiempo.
· MessageType:
· tTipo de mensaje.
· Payload:
· Son los datos que lleva este tipo dedel mensaje.
· SenderInfo:
· Datos de quién envía el mensaje.remitente del mensaje.
· MessageLog:
· sStack trace del mensaje.
3. Validación del formato del mensaje
Una vez que el mensaje ha sido autenticado, el mismo queda autorizado para ingresar dentro del circuito del bus de servicios. Convertido al formato interno por el Módulo de Entrada, el mensaje ya contiene todos los parámetros necesarios para iniciar el su flujo establecido para el mismo. El proceso de validación de mensaje, realiza lo siguiente:
o Chequear la correcta estructura del mensaje.
o Chequear la cantidad parámetros y formato correcto de los mismos.
La siguiente figura, muestra el flujo del mensaje por el Módulo de Validación:
4.
Autorización del mensaje
El proceso de autorización de los mensajes es una de las partes más complejas de la arquitectura, ya que este debe incluir el ACL de cada una de las aplicaciones que estarán conectadas al bus. La configuración de este módulo se realiza desde el Módulo de Configuración del Bus:
Una vez que le mensaje ingresa a este módulo, el tipo de mensaje determina que ACL utilizar para autorizar el mismo. Se verifica la operación que este mensaje pretende autorizar, y:
o Se actualiza el header del mensaje.
o Se registra en el módulo de Auditoría.
o Se actualiza el footer del mensaje.
o El mensaje sigue su curso establecido en el parámetro.
3.
5. Workflow de un mensaje hacia una aplicación
Una vez cumplido el recorrido por todos los módulos básicos de bus de servicio, el módulo de workflow es el encargado de fijar el camino del mensajes por todas las sistemas “legacy” (entiéndase por sistemas legados). La figura a continuación, describe el proceso invocando un servicio del sistema de gestión de expedientes JusCABA CAyT (Contencioso, Administrativo y Tributario):
Una vez ejecutada la operación, el resultado de la misma y los datos resultantes se envían en el cuerpo del mensaje hacia el módulo responsable de responder al consumidor del servicio. Este último, denominado Modulo de Output, cuenta con los datos necesarios para responder el mensaje.
6. Respuesta hacia el consumidor de un mensaje
Una vez ejecutada al función que el tipo de menaje invoca, el sistema envía el mensaje hacia el Módulo de Salida, también llama Modulo de Output. Este último, tiene como función responder al consumidor del mensaje por el canal establecido. Este, actúa de forma inversa al Módulo de Input, ya que transforma el mensaje de formato interno al formato externo y responde al consumidor del mensaje por el canal configurado.
Anexo ANEXO III – Plan de proyecto
El proyecto consta de dos etapas claramente definas. Estas son: A continuación se especifican los detalles para ejecutar la “
Etapa 1: Construcción de aServicios Informáticos Judiciales (SIJ) – Arquitectura Básica. rquitectura básica + Relevamiento Portal de Administración + Firma Digital
· Etapa 2: Integración de sistemas existentes.
sij - Etapa 1: Construcción de arquitectura básica, + Relevamiento Portal de Administración +y Firma Digital
Esta etapa consta de la construcción de la arquitectura básica de SOA, o también denominado SIJ (Servicios Informáticos Judiciales) tal como se especifica en este documento en el Anexo I – Requerimientos Funcionales y l Anexo I – Requerimientos Funcionalesy ANEXO II – Flujo de mensajes por la Arquitectura Básica. El tipo de contratación para esta etapa será de tipo de “llave en mano” y comprende los siguientes desarrollos: ANEXO II – Flujo de mensajes por la Arquitectura Básica. El tipo de contratación para esta etapa será de tipo de “llave en mano” y comprende los siguientes desarrollos:
o
o Construcción de SIJ:
· Arquitectura básica SOA según Anexo I y Anexo II de este documento.
· Prueba de Concepto (POC) del PSJ (Plataforma de Servicios Judiciales):
o Construcción de un prototipo evolutivo con calidad productiva de la Plataforma de Servicios Judiciales (PSJ).
· Nuevo Portal de Sistema Administración con Firma Digital
o Relevamiento Nuevo Portal de administración
o Módulo de Firma Digital (la PoC no incluirá el hardware Criptográfico)
Esta etapa da origen a la Prueba de Concepto (POC (Proof of Concept) por sus siglas en inglés) de la Plataforma Judicial de Servicios (PSJ). El PSJ tiene como objetivo actuar como punto de acceso a todos los sistemas que se integrarán en el SIJ. De esta forma, podemos mejorar las aplicaciones existentes logrando así:
· Incrementar la productividad de los sistemas integrados.
· Mejorar la experiencia del usuario (UX).
· Mayor escalabilidad de los sistemas existentes.
· Mejor interfaz gráfica.
· Integración de servicios.
· Reutilización de los procesos.
· Eficiencia en la utilización de recursos informáticos.
Esta etapa del proyecto entonces, se basa en el diseño de una interfaz gráfica unificada para el sistema de gestión de expedientes judiciales. Particularmente, se basa en reemplazar la interfaz gráfica de los sistemas que hoy en día se utilizan en el Consejo de la Magistratura para la gestión de los expedientes judiciales en ambos fueros, sean estos Contencioso, Administrativo y Tributario (CAyT) y para el fuero Penal, Contravencional y de Faltas (PCyF).
Además, esta etapa incluye el relevamiento la construcción del un Nuevo Portal del Sistemas de Administración y un módulo de Firma Digital.
Equipo de proyecto ETAPA 1
A continuación se detallan los recursos y su correspondiente asignación para la ejecución de esta etapa en 3 (tres meses):
|
Recurso |
% de asignación de recursos |
|
||
|
Mes 1 |
Mes 2 |
Mes 3 |
Mes 4 |
|
|
Project Manager |
|
|
|
|
|
Arquitecto SOA |
100 |
|
|
|
|
Analista Funcional SOA |
100 |
100 |
100 |
100 |
|
Líder Técnico SOA |
- |
100 |
100 |
100 |
|
Desarrollador SOA SR |
100 |
100 |
100 |
100 |
|
Desarrollador SOA SSR |
- |
300 |
200 |
200 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Especialista Infraestructura |
|
|
|
25 |
|
Desarrollador Web SR |
100 |
100 |
100 |
100 |
|
Desarrollador Web SSR |
- |
100 |
100 |
100 |
|
QA Web SR |
- |
100 |
100 |
100 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|||
Entregables y criterios de aceptación
Se detalla a continuación el criterio de aceptación que deben cumplir los entregables de la Etapa 1:
· Construcción del SIJSIJ – Arquitectura Básica:
· Se debe configurar una arquitectura basada en SOA que permita el ruteo dinámico de mensajes y cuyo tiempo de respuestas por los módulos básicos (ver ANEXO II – Flujo de mensajes por la Arquitectura Básica) sea inferior a 1 s (un segundo).ANEXO II – Flujo de mensajes por la Arquitectura Básica) sea inferior a 1 s (un segundo).
·
·
· El módulo de Service Registry del SIJ, debe permitir publicar y posteriormente consultar en formato HTML:
o Índice Guía de mensajes publicados.
o Formato de los mensajes.
o Parámetros requeridos.
o Parámetros opcionales.
o Mensaje de ejemplo.
· Toda la configuración del SIJ debe ser dinámica mediante un Módulo de Administración. El mismo, debe ser accesible mediante la web y debe contar con las interfaces de administración para los siguientes elementos:
o Interface de administración de módulos.
o Interface de administración de tipo de mensajes.
o Interface de administración de flujo de mensajes.
o Interface de administración de parámetros del sistema.
o Interface de administración de usuarios y perfiles.
o Interface de monitoreo del sistema:
§ Reporting de estado de los módulos de arquitectura básica.
§ Reporting de estado de los sistemas conectados.
§ Reporting de mensajes con error.
o Interface de recuperación de mensajes.
· Toda la arquitectura del SIJ debe estar preparada para la concurrencia y recupero de mensajes ante cualquier situación inesperada (cortes del suministro de energía sería un ejemplo de ello).
· Instalación automática y mediante un asistente donde se puedan completar todos los parámetros del sistema. El resultado de la instalación debe ser una arquitectura básica totalmente operativa.
· Debe existir un mensaje de prueba de toda la arquitectura.
· Manuales de usuario y configuración.
1. Relevamiento y plan de proyecto completo de la ETAPA 2
1. POC de PSJ
· Prototipo evolutivo web con calidad productiva basado en HTML 5 que respete los parámetros de usabilidad propuestos por el Consejo de la Magistratura de CABA.
· Interfaz gráfica totalmente responsiva, ágil y dinámica.
· Debe estar basada en el relevamiento inicial realizado por los analistas funcionales y de UX.
· Manual de estándares de diseño.
1. POC Nuevo Sistema de Administración con Firma digital integrada
1. El módulo de Firma digital debe ser de acuerdo con lo establecido en la Ley Nacional Nº 25.506, las Leyes Nº 2751 y 4736, los Decretos Nº 322/GCABA/08, 1181/GCABA/08 y 518/GCABA/13, la Resolución Nº 283/GCABA/SECLYT/13, y las normas complementarias y concordantes.
1. El módulo de Firma Digital debe ser implementado bajo las normativa de diseño establecidas por la arquitectura de SIJ, permitiendo que este forme parte del resto de los módulos de la arquitectura básica
1. El diseño de la interfaz del nuevo sistema de administración debe respetar los lineamientos de diseño de usabilidad establecidas por la nueva arquitectura.
1.
1. Debe ser una Prueba de Concepto (POC) totalmente productiva y funcional que será extendida en la segunda etapa del proyecto.
· Esta primera etapa del Sistema de Administración debe incluir el relevamiento de los procesos completos de Alta, Baja y Modificación y Firma Digital de los siguientes tipos de documentos de administración:
i. Resoluciones Presidenciales
i. Resoluciones Plenario
i. Resoluciones de Comisión de Administración, Gestión y Modernización Judicial (Ex-CAFITIT)
i. Resoluciones de Comisión de Fortalecimiento Institucional y Planificación Estratégica
i. Resoluciones de Oficina de Administración Financiera
· Relevamiento y Plan de proyecto de implementación para la ETAPA 2. Se deben en esta segunda etapa, el relevamiento completo de los siguientes tipos de documentos:
1. Resoluciones Junta Electoral .
1. Resoluciones de Comisión de Selección de Jueces, Juezas e Integrantes del Ministerio Público.
1. Resoluciones de Centro de Formación Judicial.
1. Disposiciones de Dirección de Servicios Generales y Obras Menores.
1. Disposiciones Informática y Tecnología - Caja Chica Especial.
1. Disposiciones SE -– CFJ.
1. Disposiciones de la Secretaría de Innovación.
1. Disposiciones de la Secretaría de Apoyo Administrativo Jurisdiccional.
1. Disposiciones de la Dirección de Compras y Contrataciones.
1. Disposiciones de la Dirección Editorial Jusbaires.
1. Expedientes administrativos.
1. Actuaciones.
1. Pases.
1. Notas Internas.
Etapa 2: Integración de sistemas existentes
Una vez finalizada la Etapa 1, se procederá a integrar los sistemas existentes que ya están en funcionamiento dentro del Consejo de la Magistratura de CABA:
Para realizar esta integración, será necesario entonces la integración de los siguientes sistemas:
· Fuero CAyT
o JusCABA CAyT
§ Sistema de gestión de expedientes judiciales para el fuero Contencioso, Administrativo y Tributario (CAyT)
o IURIX
§ Sistema de gestión de expedientes judiciales para el fuero Contencioso, Administrativo y Tributario (sistema reemplazado por JusCABA CAyT que todavía contiene expedientes)
· Fuero PCyF
o JusCABA PCyF
§ Sistema de gestión de expedientes judiciales para el fuero Penal, Contravencional y de Faltas (PCyF)
· Nuevo Portal de Sistema de Administración con Firma Digital
o Extensión de la funcionalidad de la POC construida en la Etapa 1 de este proyecto
Para integrar los sistemas mencionados anteriormente, se debe llevar a cabo las siguientes tareas:
· Relevamiento/Especificación funcional de Casos de Uso(CU) y Casos de Prueba (CP)
· Priorización de los CU’s
· Construcción de los CU’s
o Construcción de interfaz de servicios con sistemas existentes
o Extensión del PSJ (Plataforma de Servicios Judiciales)
§ Fueros: CAyT y PCyF
· Layout de pantallas actuales
· Consolidación de pantallas/vistas
· Análisis contextual
· Nuevo layout de pantallas
· Asistente de operaciones
· Ayuda contextual.
Equipo de proyecto ETAPA 2
A continuación se detallan los recursos y su correspondiente asignación para la ejecución de esta etapa en 9 (nueve) meses:
|
|
|
||||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|||||||||
Entregables y criterios de aceptación
Se detalla a continuación el criterio de aceptación que se aplicará para los entregables de la Etapa 2:
· Los nuevos sistemas integrados debe funcionar en paralelo con los sistemas existentes.
· Ejecución documentada de los casos de prueba para todos los sistemas integrados.
· Plataforma de Servicios Judiciales (PSJ):
o Sistema totalmente funcional y operativo:
§ Fuero CAyT integrado.
§ Fuero PCyF integrado.
o Test de experiencia de usuario documentada (UX – User eXperience).
o Manuales de usuario PSJ.
o Código fuente documentado y con manuales de procedimiento.
o Capacitación sobre la nueva plataforma.
· Nuevo Portal de Sistema de Administración con Firma Digital: el nuevo sistema debe contar con la capacidad de realizar Alta, Baja, Modificación y Firma digital de los siguientes tipos de documentos de administración:
§ Resoluciones Presidenciales
§ Resoluciones Plenario
§ Resoluciones de Comisión de Administración, Gestión y Modernización Judicial (Ex-CAFITIT)
§ Resoluciones de Comisión de Fortalecimiento Institucional y Planificación Estratégica
§ Resoluciones de Oficina de Administración Financiera
§ Resoluciones Junta Electoral
§ Resoluciones de Comisión de Selección de Jueces, Juezas e Integrantes del Ministerio Público
§ Resoluciones de Centro de Formación Judicial
§ Disposiciones de Dirección de Servicios Generales y Obras Menores
§ Disposiciones Informática y Tecnología - Caja Chica Especial
§ Disposiciones SE - CFJ
§ Disposiciones de la Secretaría de Innovación
§ Disposiciones de la Secretaría de Apoyo Administrativo Jurisdiccional
§ Disposiciones de la Dirección de Compras y Contrataciones
§ Disposiciones de la Dirección Editorial Jusbaires
§ Expedientes administrativos
§ Actuaciones
§ Pases
§ Notas Internas
Capacitación
La implementación de toda la plataforma requiere la capacitación del personal del Consejo de la Magistratura de la Ciudad de Buenos Aires. Estas capacitaciones deben cumplir con las condiciones que se detallan a continuación:
-
Instalación/Configuración del sistema:
-
Capacitación completa sobre la instalación de la plataforma.
- Requerimientos mínimos de software y hardware.
- Configuraciones adicionales.
- Ejecución de script de instalación.
- Prueba mínima de funcionamiento.
- Entregable: Manual de procedimiento de instalación del sistema.
-
Capacitación completa sobre la instalación de la plataforma.
- Administración y configuración de la plataforma:
-
Capacitación completa sobre la administración y configuración de la plataforma.
- Administración de usuarios y perfiles.
- Administración de aplicaciones conectadas.
- Administración de mensajes.
-
Parametrización y configuración general de
el sistemas.
- Entregables: Manual de procedimiento de administración y configuración de la plataforma.
ANEXO IV - Documentación
Deberá entregarse al personal informático del organismo para el correcto seguimiento y atención de aplicativo.
Los correspondientes archivos (.doc, .txt, etc.) objeto de la documentación del sistema. Los mismos tendrán que poder ubicarse y encontrarse en un marco de visualización en HTML a efectos de organizar la documentación y podrán ser consultados mediante cualquier browser de internet. También se tomará como válido que diversas partes de la documentación se encuentren en formato UML (undefine model language).
Toda la documentación deberá ser provista en medio óptico (CD–ROM, DVD, Blu-Ray).
El adjudicatario deberá entregar al menos la siguiente documentación:
· Documentación del relevamiento del sistema.
· Documentación del análisis del sistema.
· Documentación del diseño del sistema.
· Documentación de la tarea de programación y prueba del sistema.
· Documentación de la implantación y prueba del sistema.
· Documentación de la migración.
· Código fuente del sistema.
· Documentación de componentes u objetos desarrollados en el servidor de aplicaciones.
· Documentación del módulo de prueba de la aplicación.
· Manual del sistema (organizado por subsistema):
o Nombre.
o Objetivo.
o Funciones principales.
o Límites y alcances del sistema.
o Altas, bajas y modificaciones al sistema (código fuente).
o Diseño de pantallas.
o Diseño de archivos de datos (detalle de datos, volumen estimado de datos procesados mensualmente).
o Esquema de seguridad del sistema.
o Requisitos de respaldo, contingencia, recuperación de errores.
o Módulo de prueba del sistema (código fuente).
· Manual del programador:
· Nombre del programa (incluyendo procesos, consultas, reportes, etc.)
· Funciones principales del programa.
· Código fuente del programa.
· Prueba del programa.
· Manual del operador:
o Nombre del aplicativo (por cada subsistema).
o Descripción de procesos que realiza cada aplicativo.
o Nombre de los programas que forman parte de cada aplicativo.
o Relación que tiene el aplicativo con otros sistemas.
o Manejo de mensajes de error.
o Instalación del sistema.
· Manual del usuario:
o Ingreso al sistema.
o Utilización del sistema.
o Descripción de formularios.
o Descripción de reportes.
o Glosario de términos.
· Diagrama de secuencia (Moód. Dinámico).
· Diagrama de colaboración (Moód. Dinámico).
· Diagrama de actividad (Moód. Dinámico).
· Diagrama de componente (Moód. Funcionalidad).
· Diagrama de ejecución (Moód. Funcionalidad).
· Diagrama Use-Case.
.
ANEXO V - Planilla de Cotización de Ofertas
Planilla de Cotización de Ofertas
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
.
ANEXO V - Planilla de Cotización de Ofertas
Planilla de Cotización de Ofertas
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
ANEXO III
MODELO DE PUBLICACIÓN
RESOLUCIÓN OAyF N° /2015
CONSEJO DE LA MAGISTRATURA
Dirección de Compras y Contrataciones
Servicios Informáticos Judiciales – Arquitectura Básica
Expediente CM Nº OAyF-158/15 -0
Licitación Pública Nº 19/2015
Objeto: Contratación del desarrollo del software para la realización del sistema informático denominado Servicios Informáticos Judiciales (SIJ)- Arquitectura Básica, para el Poder Judicial (áreas administrativa y jurisdiccional) de la C.A.B.A.
Consultas: Dirección de Compras y Contrataciones, sita en Av. Julio A. Roca 530, Piso 8º Anexo, de esta Ciudad, de lunes a viernes de 11:00 a 17:00 horas; o al teléfono 4008-0358, o en la página web:www.jusbaires.gov.ar.
Pliegos: Los interesados deberán concurrir de lunes a viernes de 11:00 a 17:00 horas y hasta el día anterior a la fecha fijada para la apertura pública de las ofertas a la Dirección de Compras y Contrataciones del Consejo de la Magistratura, sita en Av. Julio A. Roca 530 Piso 8° de esta Ciudad, a los efectos de retirar los respectivos Pliegos, los que serán entregados sin cargo. La Dirección de Compras y Contrataciones emitirá una constancia de retiro de los Pliegos, la que se deberá acompañar en forma obligatoria junto a la oferta, conforme Art. 102 de la ley Nº 2095, reglamentada por Resolución CM Nº 01/2014.
Presentación de las Ofertas: hasta las 12:00 horas del día ** de agosto de 2015, en la Mesa de Entradas del Consejo de la Magistratura, Av. Julio A. Roca 530 PB, de esta Ciudad.
Fecha y Lugar de Apertura: ** de agosto de 2015, a las 12:00 horas, en la sede de este Consejo, Av. Julio A. Roca 530, Piso 8º de esta Ciudad.
Horacio Lértora
Dirección de Compras y Contrataciones