“25688 Desarrollo de Sistema de Plan de

Mejoramiento Educativo – PME 2017”

Propuesta Técnica.

Cliente: Ministerio de Educación.

Versión: 1.0
Fecha: 20/12/2015
SEIDOR establece que los contenidos de este documento son CONFIDENCIALES y podrían causar daño a la empresa
si es dada a conocer a sus competidores. Los datos presentados contienen secretos técnicos, comerciales y/o
información financiera privilegiada y confidencial. Tales datos se usarán únicamente para propósitos de evaluación de
la propuesta por parte del cliente, esto incluye estructura, ideas, consejos y sugerencias de la solución propuesta.
Queda entonces prohibida su reproducción, transmisión, trascripción, grabado en algún otro sistema recuperable, o
traducción a otro idioma, ya sea en forma total o parcial, sin el consentimiento escrito de SEIDOR.

Oficinas y Contactos:

Seidor Technologies Chile

Holanda 099, Oficina 303
7510006, Santiago - Chile
Tel. (+56 2) 2 233 5498

Seidor – Propuesta Técnica. 2

APROBACIONES.

Cliente. Ministerio de Educación.

Proyecto. 25688 Desarrollo de Sistema de Plan de Mejoramiento Educativo – PME 2017.

Autor. Simón E. Doering U.

Fecha Elaboración. 20/12/2015.

Versión. 1.0.

Apellido y Nombres. Rol. Aprobación. Fecha.

Simón E. Doering U. Gerente de Otros Servicios.
Sergio Tapia L. Project Manager.

REVISIONES.

Autor. Claudio Mecoli.

Fecha de Modificación.
Versión. 1.0.

Descripción de la Modificación.

Seidor – Propuesta Técnica. 3

Tabla de Contenidos.

1.- RESUMEN EJECUTIVO. ...........................................................................................................6

2.- QUIENES SOMOS. .................................................................................................................7

3.- VALOR AGREGADO. ...............................................................................................................7

3.1.-ASPECTOS NO TÉCNICOS. ....................................................................................................7

3.2.-ASPECTOS TÉCNICOS. .........................................................................................................8

4.- VISIÓN DE LA SOLUCIÓN. ........................................................................................................8

4.1.- ENTENDIMIENTO DEL PROBLEMA. ..........................................................................................8

4.2.- PROPUESTA DE VALOR........................................................................................................9

4.3.- VISIÓN DE LA IMPLEMENTACIÓN DE LA SOLUCIÓN. ..................................................................11

4.4.- ARQUITECTURA DE LA SOLUCIÓN. .......................................................................................11

5.- ALCANCES. ........................................................................................................................12

5.1.- ALCANCES DE LA PROPUESTA. ...........................................................................................12

5.2.- ALCANCES DEL SERVICIO. .................................................................................................12

5.3.- LIMITES DEL ALCANCE. ......................................................................................................13

5.4.- ENTREGABLES .................................................................................................................13

5.5.- CONDICIONES DE ACEPTACIÓN. ..........................................................................................13

6.- RIESGOS Y SUPUESTOS. ......................................................................................................14

6.1.- RIESGOS. .......................................................................................................................14

6.2.- SUPUESTOS ....................................................................................................................15

6.2.1.- SUPUESTOS DE LA SOLUCIÓN. .........................................................................................15

6.2.2.- SUPUESTOS SOBRES EL SERVICIO. ...................................................................................16

6.2.3.- INFRAESTRUCTURA DEL PROYECTO. .................................................................................17

6.2.4.- SUPUESTOS SOBRE LA DOCUMENTACIÓN. .........................................................................17

6.2.5.- RELACIONADOS CON LA PUESTA EN PRODUCCIÓN. .............................................................17

7.- PLANIFICACIÓN Y EQUIPO DE TRABAJO. ..................................................................................17

7.1.- PLAN DE TRABAJO ............................................................................................................17

7.2.- DURACIÓN ESTIMADA. .......................................................................................................19

7.3.- EQUIPO DE TRABAJO PROPUESTO ......................................................................................19

8.- METODOLOGÍA. ..................................................................................................................20

Seidor – Propuesta Técnica. 4

 8.1.- VISIÓN AGILISTA. ..............................................................................................................20

8.2.- OBJETIVOS – RESULTADOS. ...............................................................................................21

8.3.- VISTA GRÁFICA DEL PROCESO ............................................................................................22

8.4.- DESCRIPCIÓN DEL PROCESO ..............................................................................................22

8.4.1.- VISIÓN .........................................................................................................................22

8.4.2.- DESARROLLO DEL PRODUCT BACKLOG ..............................................................................22

8.4.3.- SPRINT PLANNING MEETING. ...........................................................................................23

8.4.4.- DAILY MEETING. ............................................................................................................25

8.4.5.- SPRINT REVIEW. ...........................................................................................................25

8.4.6.- SPRINT RETROSPECTIVE. ...............................................................................................26

8.5.- ARTEFACTOS. ..................................................................................................................27

8.5.1.- VISIÓN. ........................................................................................................................27

8.5.2.- PRODUCT BACKLOG. ......................................................................................................27

8.5.3.- SPRINT BACKLOG. .........................................................................................................27

8.6.- ROLES............................................................................................................................27

8.6.1.- PRODUCT OWNER. ........................................................................................................27

8.6.1.- SCRUMMASTER.............................................................................................................28

8.6.2.- EL EQUIPO. ..................................................................................................................28

Seidor – Propuesta Técnica. 5

 1.- RESUMEN EJECUTIVO.

La Coordinación Nacional de Tecnología, en adelante CNT y la División de Educación General, en adelante DEG, requieren
la Contratación por “Proyecto”, para el desarrollo, capacitación e instalación de una Plataforma de Gestión de Información,
para el Sistema de “Plan De Mejoramiento Educativo – PME 2017.

El “Plan De Mejoramiento Educativo – PME 2017” debe permitir el registro, la implementación y la evaluación de un proceso
de mejora continua en los establecimientos tendiente a mejorar los procesos de enseñanza y aprendizaje.

Para ello esta plataforma deberá contar con los siguientes módulos:

Módulo 1: “Planificación Estratégica”, el cual se busca en identificar la realidad del establecimiento, definir los
objetivos de este y la estrategia para alcanzarlos dentro del periodo de cuatro años de PME.
Módulo 2: “Planificación Anual”, El cual debe realizar la definición de actividades a realizar durante un ciclo anual
de PME definiendo acciones y presupuestos asociados.
Módulo 3: “Implementación”, el cual debe permitir implementar el seguimiento de la ejecución de lo planificado.
Módulo 4: “Evaluación”, en el cual se deben identificar brechas de cumplimiento, e identificar el grado de
cumplimiento de los objetivos estratégicos de acuerdo a las actividades realizadas.
Requerimientos No Funcionales.

El proyecto será abordado con un enfoque iterativo y ágil generando entregables en cada una de sus iteraciones.

Un factor clave para el éxito de cualquier proyecto es la gestión del mismo, por eso nosotros ponemos énfasis en la gestión
siguiendo los lineamientos del PMI para llevar a cabo una gestión acorde a las necesidades de cada servicio. Nuestra oficina
de PMO, da el apoyo necesario a nuestros jefes de proyectos para aplicar las buenas prácticas de gestión y lograr el control
y éxito de los proyectos.

Seidor – Propuesta Técnica. 6

 2.- QUIENES SOMOS.

Seidor es una Consultora Tecnológica líder dedicada a ofrecer soluciones integrales en el ámbito de la consultoría de software
y servicios informáticos, estrategia IT, desarrollo (soluciones móviles, BPM, SOA, Content Management), operaciones,
infraestructura, mantenimiento de aplicaciones, soluciones Cloud y Outsourcing, entre otras.

Con más de 30 años de trayectoria en el mercado, conocimiento tecnológico de vanguardia, especialización sectorial, cercanía
y equipo de expertos certificados por los principales fabricantes, Seidor es una compañía sólida, estable y en expansión,
focalizada en simplificar a sus clientes el acceso a tecnologías emergentes y gestionar sus negocios de una forma más rápida,
sencilla y asequible.

La alianza estratégica de Seidor con los principales y más importantes desarrolladores y fabricantes de tecnología
internacionales (Oracle, IBM, SAP, Microsoft, Dell, Quest Software, Red Hat, etc) es su principal garantía para ofrecer la
solución que mejor se ajusta a la necesidad específica de cada cliente.

Refiérase a documento “01 – Quienes somos.pdf”

3.- VALOR AGREGADO.

3.1.-ASPECTOS NO TÉCNICOS.

Nosotros como empresa estamos convencidos que los pilares para una buena relación de largo plazo y éxito en un proyecto
son:
Transparencia.
Confianza.
Compromiso.
Seriedad.
Comunicación.
Empatía.
Visión de negocio.
Transferencia de conocimiento.

Nuestra permanencia en el mercado Chileno y en Latinoamérica en general durante todos estos años se debe, más allá de
nuestra capacidad técnica, al reconocimiento por todos los valores antes señalados.
La empatía con las necesidades y desafíos de nuestros clientes, el compromiso por cumplir los objetivos y las metas más allá
de las dificultades que puedan existir, ser transparente y asumir sin temor las responsabilidades que nos quepan y asumir el
compromiso de solucionar los problemas que puedan existir, ganando la confianza del cliente para seguir trabajando con
nosotros.

Seidor – Propuesta Técnica. 7

Entregamos el conocimiento, trasmitiendo y apoyando a que el cliente sea capaz de seguir adelante con los desafíos técnicos,
no nos consideramos indispensables ni es nuestra política, agregamos valor, no queremos un cliente cautivo.

3.2.-ASPECTOS TÉCNICOS.

Amplia experiencia en proyectos de desarrollo & consultoría, contemplando soluciones de negocio.

Acompañamos al cliente en el proceso de adopción del cambio.
Tenemos experiencia en integración y migración de plataformas utilizando diferentes tecnologías.
Aplicamos estándares y metodologías ágiles para todo el proceso de desarrollo de software, además de contar con
procesos definidos para la gestión de proyectos, gestión de requerimientos de cambio, entre otros.
Contamos con un área de control de proyectos PMO y aplicación de estándares. para garantizar el éxito en la
gestión.
Ejecutamos técnicas de aseguramiento de la calidad, condición necesaria para la puesta en producción de cualquier
producto de software.
Contamos con el reconocimiento por el esmero en la calidad de los trabajos realizados, la utilización de tecnología
de última generación y las capacidades de pre-venta y venta consultiva, que nos han transformado en el primer
referente en clientes y partners estratégicos.

4.- VISIÓN DE LA SOLUCIÓN.

4.1.- ENTENDIMIENTO DEL PROBLEMA.

El Ministerio de Educación de Chile, también conocido por su acrónimo MINEDUC, busca contribuir a elevar los estándares
de educación en la población, desarrollando sistemas de mejoramiento, centrados en las personas, fortalecer el control de los
factores que puedan afectar la educación y reforzar la gestión del plan nacional de educación.

Objetivos del Negocio

Realizar un sistema que se ajuste al nuevo modelo de mejoramiento continuo del MINEDUC y remplace al actual
sistema de Plan de Mejoramiento Educativo.
Flexibilizar la gestión de los componentes del proceso de mejoramiento educativo, en casos de excepción.
Crear herramientas de comunicación entre los diversos actores del sistema que interactúan en la creación PME.
Mejorar la capacidad de análisis de resultados, obtenidos durante los procesos de mejoramiento.
Mantener en constante actualización la información proveniente desde entidades externas al MINEDUC (Agencia
de Calidad, Superintendencia de Educación, DEMRE).
Reportar sobre el proceso a todos los actores involucrados en los temas de gestión y mejora educativa
(Sostenedores, MINEDUC, Agencia de Calidad y Superintendencia de Educación)
Contar con una herramienta que apoye los cambios de práctica en los procesos de registro y gestión de los procesos
de mejora en la escuela.

Seidor – Propuesta Técnica. 8

Objetivos del proyecto

Implementar una solución tecnológica con la capacidad de cumplir con todos los requerimientos planteados por el
MINEDUC.
Trabajar bajo los parámetros de construcción y arquitecturas establecidas por el MINEDUC.
Respetar y resguardar la confidencialidad de la información que pueda ser recibida desde el MINEDUC o
participantes externos, y que sea útil para el desarrollo del sistema.

Objetivos del Sistema

Simplicidad del sistema, con interfaces de fácil uso para minimizar errores.
Utilizar los mecanismos de seguridad definidos por el MINEDUC para proteger la información y datos de acceso no
autorizado.
Construir una aplicación robusta, modular y mantenible, que sea escalable, segura, capaz de centralizar errores y
de manejar alta concurrencia.
Proveer altos estándares de seguridad acorde a las definiciones hechas por el Ministerio de Educación.

4.2.- PROPUESTA DE VALOR.

Se proporcionará la construcción de una plataforma web para todos los actores que participan en las operaciones del Plan de
Mejoramiento Educativo a nivel nacional. Aproximadamente 12.000 establecimientos, 3.000 sostenedores, 700 supervisores
42 encargados provinciales MINEDUC, 15 seremis, 200 funcionarios MINEDUC, agencia de calidad y superintendencia.

El sistema estará dividido en 2 fases Macro: Fase Estratégica (etapa 1) y Plan Anual (etapa 2), siendo 4 años la duración del
nuevo plan, ambos independientes entre sí en el aspecto de la finalización de las fases. Estas fases estarán estructuradas
de la siguiente forma:

Módulo de Mantenimiento de Usuarios y sistema de autentificación de credenciales:

Mantenedor de Usuarios
Mantenedor de Roles/Perfil
Modulo Inicio Sesión usuarios Internos y Externos

Fase Estratégica

Análisis Estratégico
 Definición de Sellos Educativos
 Fortalezas y Debilidades

Planificación Estratégica
 Definición de Objetivos y Metas

Seidor – Propuesta Técnica. 9

  Definición de Estrategias
 Definición de Metas

Fase Plan Anual

Sub Fase Planificación

 Definición indicadores y actividades
Sub Fase Implementación
 Seguimiento y Monitoreo de Actividades
Sub Fase Evaluación

Adicional a esto existen requerimientos transversales a todo el sistema:

Registro de Actividades

Plataforma de comunicaciones

Proceso de Apertura
 Sistema que permita la modificación de datos de periodos anteriores en algún punto del flujo con el objetivo
de ajustar las estrategias según la actualización de la información.

Sistema de Reportes

Carga de datos inicial y actualización automática

Interacción con otros sistemas

 Comunidad Escolar
 SIGE
 LDAP
 AME
 Plataformas PME anteriores
 Plataformas de la Agencia de Calidad

Seidor – Propuesta Técnica. 10

 4.3.- VISIÓN DE LA IMPLEMENTACIÓN DE LA SOLUCIÓN.

4.4.- ARQUITECTURA DE LA SOLUCIÓN.

En el diagrama presentado se identifican claramente las capas y sus componentes, que en ambiente de producción se
recomienda un desplegué de la siguiente forma.

Se utilizará la arquitectura indicada y propuesta por Mineduc respectando los estándares establecidos, detallados a
continuación.

4.4.1.- CAPA PRESENTACIÓN.

Capa que contendrá páginas dinámicas y formularios. A esta capa se le propagará las credenciales de autenticación.. Esta
capa tiene el objetivo de contar con un diseño acorde a lo esperado, cumpliendo con las características básicas de las
aplicaciones Web que deben ser intuitiva para el usuario y definida por Mineduc.

4.4.2.- APP SERVER

Frente a la opción de utilizar 2 tipos de servidores para realizar los desarrollos escogemos la utilización de Apache con Java
1.6 rigiéndonos según de lo que de la especificación de arquitectura se desprende:

“La aplicaciones serán montadas sobre OS Centos versión 6.2, la versión de Java es Java. 1.6 (puede sufrir modificaciones)
y la versión de tomcat es 6 (puede sufrir modificaciones), adicionalmente se está utilizando la versión de apache 2.2.15 (puede
sufrir modificaciones).”
4.4.3.- FRAMEWORK.

El Framework a utilizar es el provisto por Mineduc basado en Spring 3.1.1, siendo característica del desarrollo realizado con
Patrón de diseño MVC.

Seidor – Propuesta Técnica. 11

Tecnologías propuestas a utilizar y siguiendo con la operación de Mineduc están:

 Uso de Maven para Gestión de Ciclo de Vida del Proyecto.

 Ibatis para el Mapeo Objeto-Relación.
 Junit para la ejecución de Test Unitarios.
 Jenkins como Herramienta de Integración.

Como política del Mineduc se debe cumplir con un 97% de cumplimiento de Reglas definidas por Mineduc donde se utiliza
SonarQube para generar informes de cumplimento de las reglas definidas.

5.- ALCANCES.

5.1.- ALCANCES DE LA PROPUESTA.

El alcance de la propuesta se rige según el documento de especificaciones Funcionales y No funcionales sobre las cuales
estamos de acuerdo y se adjuntan a continuación:

Levantamiento de
Requerimientos.docx

Respetando los siguientes lineamientos propuestos por MINEDUC:

1. Requerimientos Ares de Seguridad y QA Mineduc:

Guia Estandares QA
v3.2.docx

2. Requerimientos Área de desarrollo:

Arquitectura Estándar Base de Templates Web para SVN Mineduc

Aplicaciones Mineduc V1 Datos
0.docx- Wiki Mineduc.doc Norma de Uso.pdf
Apps Internas - Wiki Mineduc.doc

5.2.- ALCANCES DEL SERVICIO.

El alcance de las actividades del proyecto, está delimitado por las fases del mismo. De acuerdo a los requerimientos del
negocio, la naturaleza y características de los componentes existentes y los requerimientos señalados anteriormente, se
plantea lo siguiente:

Seidor – Propuesta Técnica. 12

 Levantamiento inicial y delimitación del alcance del proyecto.
Diseño de la solución.
Implementación del alcance funcional propuesto.
Testing en ambiente de desarrollo.
Apoyo paso a ambiente QA.

5.3.- LIMITES DEL ALCANCE.

Están fuera del alcance de este proyecto:

Elaboración documentación que no sea la especificada como entregables de responsabilidad de SEIDOR

TECHNOLOGIES.
Desarrollo de funcionalidades que no sean los especificados en esta propuesta.
Todos los programas o interfaces necesarias para integrar esta aplicación con otros sistemas no mencionados como
parte del alcance de esta propuesta es de entera responsabilidad del cliente.
Solucionar errores de sistemas no desarrollados por SEIDOR TECHNOLOGIES.
Instalación y configuración de otras plataformas o componentes tecnológicos que no sean las descritas en esta
propuesta.
Dar soporte más allá de lo especificado en esta propuesta.
Generación de todos los datos necesarios para las pruebas en ambiente de desarrollo y calidad.
La puesta en producción de la solución.
La generación del plan de pruebas y los casos de pruebas para todos los requerimientos funcionales.
La instalación y configuración del Hardware requerido.

5.4.- ENTREGABLES

La siguiente es la lista de entregables del servicio:

Documentación de diseño de la solución propuesta.

Generación de la carta Gantt (planificación del proyecto).
Documento de Despliegue.
Casos de Prueba Ejecutados.
Código fuente

5.5.- CONDICIONES DE ACEPTACIÓN.

En esta sección deben definirse de forma clara, completa y explícita cuáles serán las condiciones de aceptación de los
servicios de SEIDOR TECHNOLOGIES. Estas condiciones deben definirse en conjunto con el cliente y no deben contemplar
ambigüedades, no deben estar sujetas a diferencias de opinión ni subjetividades y deben ser concretas, simples y medibles.
Se proponen inicialmente las siguientes condiciones de aceptación:

Seidor – Propuesta Técnica. 13

 Condición o caso de prueba Resultado esperado Resultado Esperado

Documento de Especificación Técnica. La aceptación del cliente en 48 hrs.

Módulos entregados con las evidencias del plan de

Módulos según planificación entregados en ambiente de desarrollo.
pruebas ejecutado en ambiente de desarrollo.

Informe de Avance de Proyecto. La aceptación del cliente en 48 hrs.

6.- RIESGOS Y SUPUESTOS.

6.1.- RIESGOS.

Se reconocen como riesgos aquellas situaciones que de producirse afectarán negativamente de manera directa o indirecta la
ejecución del proyecto.

El objetivo de este apartado es construir con el cliente una visión común de los posibles problemas que deberán enfrentarse
en la implementación de la solución propuesta, en términos de probabilidad de ocurrencia, impacto del problema en el
proyecto, y diferentes formas de evitar el riesgo o al menos reducir su impacto.

Descripción. Impacto. Estrategia de mitigación y/o contingencia.

Dado que el proyecto requiere participación y
compromiso parte de personal del cliente,
puede ser que esta participación no se cumpla
si no se planifican los recursos con tiempo.
En relación con el alcance funcional y no
funcional del proyecto, dado que no se tiene
total claridad de la información y su
complejidad. En caso de manifestarse este
riesgo bajo la aparición de requerimientos
ambiguos o no identificados en un comienzo, el
esfuerzo y la duración del proyecto pueden
verse afectados.
Demora en las aprobaciones de
documentación por parte del cliente impactan
en los hitos de pago.
El cliente debe arbitrar los medios para que el personal propio
involucrado en el proyecto tenga la dedicación necesaria.
Alto.
Se plantea una fase de inicial para el proyecto. Durante la
misma se obtendrá una línea base de la funcionalidad de los
procesos a implementar.
En caso de aparecer divergencias entre la estimación
cotizada y la línea base, se analizarán con el cliente las
Alto.
acciones a seguir, siendo las posibilidades:
- Reducción de la funcionalidad (conservando el costo)
- Generación de una extensión del proyecto (previa
cotización)
- Generación de una release adicional (previa cotización)
la Asignar los recursos el tiempo necesario para poder realizar
Alto. la revisión de los documentos dentro de los plazos
establecidos.

Seidor – Propuesta Técnica. 14

 Demora en la entrega de la documentación y/o
componentes necesarios en las etapas
estipuladas del proyecto.
La indisponibilidad de los recursos de
infraestructura en los tiempos estipulados por la
planificación de proyecto.
No se definen alcance no funcionales
.
6.2.- SUPUESTOS
Asignar los recursos el tiempo necesario para realizar la
Alto. entrega de la documentación y/o componentes necesarios,
dentro de los plazos establecidos.
Una estrategia de mitigación es la revisión temprana de la
Alto. actividad para informar al personal asignado al proyecto sobre
tal situación en caso de suceder.
Dado que no hay alcances no funcionales definidos, la
aparición de los mismos implica revisar el alcance, esfuerzo y
Alto.
los costos iniciales de la propuesta, según sea necesario para
incluir dichos requerimientos.

La siguiente es la lista de los supuestos del proyecto. Todo lo expuesto en la propuesta ha sido desarrollado asumiendo que
estos supuestos son verdaderos. El hecho de que algún supuesto no se cumpla, puede llegar a tener impacto en el plan de
proyecto y deberá ser analizado en cada caso.

6.2.1.- SUPUESTOS DE LA SOLUCIÓN.

La implementación de la solución queda sujeta a las características, capacidades y performance por default de la
herramienta/arquitectura con la cual se implementa la solución.
La estimación presentada es tentativa de acuerdo a lo especificado por el cliente y considerado como alcance
funcional.
Cualquier información no incluida explícitamente en estos documentos no formará parte del alcance del proyecto.
Todo nuevo requerimiento o modificación al alcance inicial detectado en la fase de análisis será considerado un
control de cambio y debe ser estimado, cotizado y aprobado por el cliente para su implementación, caso contrario
no será incluido en el proyecto.
El cliente deberá proveer documentación y los artefactos de software que sean requeridos de las aplicaciones
existentes.
Todos los procedimientos almacenados o servicios web necesarios para implementar los procesos deben ser
provistos por el cliente al inicio del proyecto.
Todas las interfaces de ingreso deben estar definidas y el cliente debe entregar:
o Todos sus campos especificados.
o Todos los formatos de datos de cada campo.
o Todas las reglas de negocio que aplican a cada campo.
o La relación o reglas de negocio entre los campos de una misma pantalla o entre campos de diferentes páginas.
Cualquier integración en esta propuesta que se requiera realizar con los sistemas actuales del cliente, será
responsabilidad del cliente desarrollar dicha integración y disponerla para su uso.
El cliente debe proveer todos los datos necesarios para la fase de desarrollo y pruebas del sistema al inicio del
proyecto.

Seidor – Propuesta Técnica. 15

 El cliente debe definir todas las interfaces de salida al inicio del proyecto y disponibilizarlas (informes, reportes, etc)
a considerar entro del alcance funcional definido.
Todos los casos de uso y casos de prueba deben estar definidos y provistos por el cliente al inicio del proyecto.

6.2.2.- SUPUESTOS SOBRES EL SERVICIO.

El cronograma de implementación será definido por el equipo implementador de acuerdo al plan general de proyecto
de común acuerdo.
Para aquellos trabajos que sean necesarios realizar en el cliente, este facilitará todos los recursos humanos y
tecnológicos (servidores, puestos de trabajo, conexión a internet, VPN, etc) necesarios para poder llevar a cabo las
tareas en forma exitosa.
Deberán respetarse las fechas fijadas para la celebración de reuniones, y se deberá documentar el resultado de
cada reunión, lo que se transformará en documentación del proyecto en lo que respecta a decisiones que se tomen
en dichas reuniones.
Por cada reunión existirá una minuta de reunión con las decisiones tomadas.
El cliente asume el compromiso de colaborar con SEIDOR TECHNOLOGIES para que éste pueda prestar los
servicios objeto del presente Contrato, incluyendo asuntos tales como facilitar la información y documentación que
sean necesarias para realizar el proyecto en los plazos establecidos en la Carta Gantt, dar las aprobaciones que
SEIDOR TECHNOLOGIES precise en los plazos establecidos en la carta Gantt, revisar informes y realizar aportes
en relación con los mismos en el momento que sea necesario acorde a los plazos establecidos en la carta Gantt en
cada etapa del proyecto.
El cliente se obliga a responder y aclarar todas las dudas o interpretaciones de toda la información entregada por el
mismo para este proyecto, como así también se hace responsable de especificar todo aquello que no estando
especificado debidamente al inicio del proyecto se considere parte de las especificación de los alcances de este
proyecto y que no signifique un cambio de alcance. Todo lo anterior debe ser realizado dentro de los plazos
acordados en la planificación.
Una vez efectuado un requerimiento por parte de SEIDOR TECHNOLOGIES, el cliente deberá dar respuesta dentro
de los plazos establecidos en la carta Gantt. En caso de que el cliente no pudiere dar respuesta a dicho
requerimiento dentro del plazo antes señalado, se encontrará obligado a dar por aprobados los artefactos
entregados (documento, producto de software u otro) y aceptada la interpretación o entendimiento del problema por
parte de SEIDOR TECHNOLOGIES, relacionado con el requerimiento solicitado.
El cliente procurará que SEIDOR TECHNOLOGIES tenga acceso en el menor plazo posible, no superior a los plazos
establecidos en la planificación, al personal relacionado con este proyecto.
Se asume que en las reuniones que se traten temas que requieran de decisiones inmediatas participarán los
funcionarios que puedan decidir durante la reunión los temas en cuestión para evitar cualquier atraso en el plan de
proyecto.
SEIDOR TECHNOLOGIES se reserva el derecho de cambiar los miembros del equipo de proyecto en caso de ser
necesario.
El cliente debe asignar como mínimo el siguiente equipo al proyecto, según la planificación que se defina:
o Jefe de Proyecto: 25%.
o Responsable de tecnología o plataformas: 50%.
o Responsable de negocio: 50%.
Seidor – Propuesta Técnica. 16
 6.2.3.- INFRAESTRUCTURA DEL PROYECTO.

EL HW para todos los ambientes debe ser provisto por el cliente dimensionado de acuerdo a los requerimientos
mínimos recomendado por las plataformas a utilizar como solución.
El pasaje entre ambientes (desarrollo, QA, producción) es de responsabilidad del cliente, pero SEIDOR
TECHNOLOGIES brindará todo el apoyo que sea necesario en el proyecto.

6.2.4.- SUPUESTOS SOBRE LA DOCUMENTACIÓN.

Existirá un tiempo límite (2 días) para la revisión por parte del cliente de la documentación entregada por SEIDOR
TECHNOLOGIES, pasado ese tiempo, la documentación será considerada como aceptada.

El tiempo límite para presentar objeciones o correcciones sobre la documentación entregada por SEIDOR
TECHNOLOGIES se considera de 2 (dos) días hábiles, aunque podrán existir excepciones que serán acordadas
entre SEIDOR TECHNOLOGIES y el cliente en el caso de documentación muy extensa.
SEIDOR TECHNOLOGIES utilizará los templates propios para la confección de los documentos solicitados por el
cliente. En caso de que el cliente quiere trabajar con sus propios templates, estos deben ser acordados al inicio del
proyecto.

6.2.5.- RELACIONADOS CON LA PUESTA EN PRODUCCIÓN.

Se supone que existirán los equipos necesarios para desplegar la aplicación.

La puesta en producción será realizada por el cliente en horario a definir.

7.- PLANIFICACIÓN Y EQUIPO DE TRABAJO.

7.1.- PLAN DE TRABAJO

El plan de proyecto detallado y acordado con el cliente es parte del proceso inicial de la metodología de trabajo propuesta. El
plan de proyecto se divide en distintas fases iterativas e incrementales desde la definición o revisión de los requerimientos
(en este caso la revisión de los requerimientos) hasta la liberación parcial de cada una de sus funcionalidades.

La división del proyecto en fases o etapas claramente marcadas, con resultados visibles y concretos permitirá facilitar la
administración y gestión del proyecto.

El siguiente gráfico ejemplifica el modelo ágil e iterativo a trabajar para la implementación de los requerimientos:

Seidor – Propuesta Técnica. 17

Por cada requerimiento funcional que se detalla, planifica y trabaja, se liberan diferentes productos en cada reléase (entrega).

El plan general del proyecto involucra las grandes fases que se requieren, como se indica en el siguiente gráfico:
Lo siguiente es un ejemplo de las tareas que se deben considerar en el primer sprint de trabajo y en un sprint cualquiera del
proceso de desarrollo.

Spike Sprint.
Kickoff inicial y Spring Planning meeting.
Análisis detallado de los requerimientos y situación actual.
Relevamiento Arquitectura actual y Sistemas.
identificación, organización y documentación de los requerimientos.
Definición de supuestos y riesgos iniciales.
Elaboración de los casos de uso y los casos de prueba iniciales.
Diseño de la solución.
Elaboración Documentación técnica y requisitos para la fase de desarrollo.
Sprint Review.
Elaboración del ProductBacklog y Sprint Baklog.

Sprint n.
Sprint Planning meeting.
Revisión del Sprint Backlog, priorización alcance y re-estimación.
Ajuste de casos de usos y casos de pruebas.
Desarrollo funcionalidades priorizadas.
Testing unitario y Rework.
Teesting Integral y Rework.
Certificación y Rework.
Aprobación Sprint.
Sprint Review.

Seidor – Propuesta Técnica. 18

 7.2.- DURACIÓN ESTIMADA.

La cantidad total de tiempo estimado para el proyecto, asciende a 7 Meses.

7.3.- EQUIPO DE TRABAJO PROPUESTO

Jefe Proyecto

Arquitecto Analista
Funcional

Desarrolladores Analista QA

Roles del proyecto. Tareas. Empresa.

Realizar la Planificación detallada del proyecto.
Ejecutar el proyecto.
Realizar el seguimiento del proyecto.
Anticipar incidencias que afecten a la planificación realizada.
Alertar los desvíos en Tiempo, Esfuerzo y Costo.
Asegurar el cumplimiento de los hitos establecidos. SEIDOR
Jefe de Proyecto.
Asegurar el no desvío de los objetivos planteados. TECHNOLOGIES.
Coordinar el TEAM de proyecto.
Realizar la asignación de tareas al TEAM, en el Corto y largo plazo.
Actualizar la lista de riesgo y garantizar estrategias de mitigación con
acuerdo del cliente.
Mantener el contacto permanente con el Cliente.

Desarrollo y pruebas unitarias de los componentes y servicios requeridos SEIDOR

Desarrolladores.
como parte de la solución. TECHNOLOGIES.

Ejecución de los casos de test. (pruebas unitarias) SEIDOR

Analista QA.
Documentación de las pruebas. TECHNOLOGIES.
Diseño de la solución.
Definir la arquitectura y buenas prácticas de programación. SEIDOR
Arquitecto.
Elaborar pruebas de conceptos. TECHNOLOGIES.
Apoyo al equipo de Programación.

Seidor – Propuesta Técnica. 19

 Relevamiento de requerimientos.
Armado de casos de uso. SEIDOR
Analista Funcional.
Entendimiento del negocio. TECHNOLOGIES.
Documentación.

Los profesionales de SEIDOR TECHNOLOGIES poseen una amplia experiencia en proyectos de desarrollo y son capacitados
en forma continua.

8.- METODOLOGÍA.

Los procesos de desarrollo son fundamentales para trabajar eficientemente y poder evitar incidentes que llevan a que un gran
porcentaje de proyectos se terminen sin éxito. El objetivo de un proceso de desarrollo es aumentar la calidad del software (en
todas las fases por las que pasa) y que sea repetible, a través de una mayor transparencia y control sobre todo el proceso.
Hay que producir lo esperado en el tiempo esperado y con el costo esperado, es labor entonces, del proceso de desarrollo
hacer que éstas medidas sean reproducibles en cada desarrollo y garantizar su cumplimiento.

No todos los proyectos y las necesidades son iguales, por esto, Seidor trabaja con RUP como proceso de desarrollo formal
para proyectos de gran envergadura y SCRUM incorporando prácticas de XP y perfeccionado para trabajo en contextos
distribuidos, como proceso Ágil de desarrollo de software. Cada uno personalizado para el cliente y tipo de proyecto, es parte
de nuestro valor agregado decidir cuál es el proceso que mejor se adapta a la situación concreta a la que se enfrenta un
proyecto, para minimizar la inversión requerida, obtener los resultados esperados y garantizar al cliente alcanzar la meta
propuesta.

8.1.- VISIÓN AGILISTA.

Basándose en gestión adaptiva y en las lecciones aprendidas de los fracasos de la crisis del software, la industria desarrolla
durante los 90 y consolida en 2011 un conjunto de prácticas y recomendaciones que a la fecha se conocen como el “Manifiesto
Ágil”. En este documento se plasman las mejores ideas y conceptos probados en proyectos altamente exitosos.
Las prácticas comunes de cualquier metodología ágil son:

Gestión iterativa: el proyecto se desglosa o subdivide en mini-proyectos conocidos como iteraciones de duración
estrictamente fija no mayor a 30 días, siendo 15 días lo más común. Se hacen tantas de estas iteraciones como

1
Historia del manifiesto ágil - http://agilemanifesto.org/history.html.
Seidor – Propuesta Técnica. 20
 sean necesarias para tener software que de valor al negocio, pero el empresario es quien finalmente decide cuando
terminar las iteraciones. Cada una de las iteraciones se concluye con software funcionando y potencialmente listo
para ser usado. Es decir, al final de cada iteración se tiene software que se puede ver y usar.
Equipos pequeños y multi-disciplinarios: El trabajo es realizado por equipos no más grandes que 8 personas
incluyendo los expertos del negocio, formando parte integral del equipo. Todos hacen de todo y lo hacen todo el
tiempo.
Inspección frecuente: El esfuerzo del proyecto se inspecciona diariamente por el equipo y demás interesados.
Gestión de productividad y calidad: Se aplican prácticas enfocadas a la productividad y la calidad. Es casi automático
duplicar la productividad y no es difícil multiplicarla 3 o 4 veces. La calidad del producto es controlada y mantenida
mediante un proceso continuo de pruebas automatizadas a lo largo del proyecto. No se hacen las pruebas al final,
se prueba todos los días muchas veces por día de forma casi automática.
Mejora continua: A lo largo de todo el proyecto se inspecciona el proceso para encontrar oportunidades de mejorar
productividad, calidad y satisfacción del cliente.

8.2.- OBJETIVOS – RESULTADOS.

Fiel al primer principio del Manifiesto Ágil:

“Nuestra más alta prioridad es satisfacer al cliente mediante la entrega

temprana y frecuente de software valioso”.

Con la aplicación de agilidad al desarrollo de software se obtienen los siguientes resultados para la empresa:

Entrega temprana y frecuente de software (entre 2 a 4 semanas).

Control permanente del costo mediante la gestión de iteraciones de duración fija. El negocio decide cuando dejar
de pagar iteraciones.
Duplicar, triplicar o incluso cuadriplicar la productividad de los programadores.
Alta visibilidad y control directo del esfuerzo. Los hombres de negocio deciden que desarrollar y cuando, no los
programadores.
Minimizar al máximo los riesgos de implementación.
Alto retorno de inversión (ROI).
Claves
Las claves son la velocidad y la simplicidad.
Concentración en obtener lo antes posible una pieza útil que implemente (sólo lo que sea más urgente)
La prioridad es satisfacer al cliente mediante entregas tempranas y continuas de software que le aporte un valor
En este momento se espera el feedback del cliente y se dan la bienvenida a los cambios solicitados, interpretándolos
como un avance en la comprensión y luego satisfacción del cliente.

Seidor – Propuesta Técnica. 21

 8.3.- VISTA GRÁFICA DEL PROCESO

8.4.- DESCRIPCIÓN DEL PROCESO

8.4.1.- VISIÓN

Esta es la primera actividad del proceso, donde los máximos responsables establecen dónde quieren estar a futuro, qué se
quiere lograr, a fin de transmitir al equipo, y poder enfocar las acciones en esa dirección.

PERSONAS AFECTADAS.
Product Owner.
Stakeholders.

TAREAS.
Identifica todas las metas y objetivos del proyecto.
Plasma la estrategia de la organización para cumplir metas y dar mayor valor al negocio.
Anticipa el ROI, releases e hitos.

8.4.2.- DESARROLLO DEL PRODUCT BACKLOG

El product backlog es el corazón del proceso, básicamente es una lista priorizada de requerimientos, features, store users,
etc. Cosas que el cliente quiere, descritas utilizando la terminología del cliente.

PERSONAS AFECTADAS
Product Owner.
Stakeholders.

Seidor – Propuesta Técnica. 22

TAREAS
El Product Owner (junto con los stakeholders), planean y definen el conjunto de requerimientos.
El Product Owner realiza las definiciones de los requerimientos.
El Product Owner identifica los ítems del Product Backlog (User Storys, por ejemplo).
Define las condiciones de aceptación y asigna un Business Value a cada User Story.
Development Team estima el Product Backlog.
El Product Owner prioriza el Product Backlog.
CHECKLIST
Listar / actualizar todos los requerimientos.
Validar / acordar con los stakeholders la lista de los requerimientos.
Asociar a cada requerimiento, su correspondiente documento de especificación.
Especificar a cada ítem en el product backlog el nivel de detalle del requerimiento (especificar la granularidad
categorizada en 5 niveles: Detallada, descrita, contada, bosquejo, idea (consensuar las categorías)).
Especificar la importancia. Se refiere desde el punto de vista de negocio.
Asociar a los requerimientos bien detallados el UAT. Condiciones claras de aceptación.
Establecer por cada ítem, el nivel de estabilidad del requerimiento y su especificación (categorizada, si NO va
a cambiar, si puede cambiar (por ejemplo porque no está claro el requerimiento, o no está bien especificado)
o si es desconocido).
Realzar diagrama de relaciones / dependencia entre los requerimientos (desde su punto de vista funcional).
Estimación de esfuerzo (Por parte del Team).

8.4.3.- SPRINT PLANNING MEETING.

Esta reunión consiste en la selección y planificación de los ítems del sprint a implementar.
Previo a esta reunión DEBE establecerse el tiempo que durará el Sprint. En el tiempo del sprint NO se considera el tiempo
insumido para esta reunión (Sprint planning meeting) ni de las reuniones de Sprint Review y Sprint Retrospective.

PERSONAS AFECTADAS.
Product Owner.
ScrumMaster.
Team.

DURACIÓN
Un (1) día completo.

TAREAS
El product Owner debe haber preparado con antelación el Product Backlog.
Consta de dos partes: seleccionar el backlog tentativo para el sprint y planificarlo.

SELECCIONAR EL BACKLOG PARA EL SPRINT (DURACIÓN ½ DÍA).

Seidor – Propuesta Técnica. 23

 (1) Product Owner y el Team discuten los ítems del Product Backlog. En este punto para cada ítem del product
backlog DEBE tener, como mínimo, especificado su definición y el test de aceptación (UAT).Es deseable
que el requerimiento tenga un nivel de estabilidad y detalle alto).
(2) Product Owner y el Team eligen los ítems tentativos a incluir en el Sprint. Los ítems a incluir, en principio
deben ser más de los que realmente entrarán, respecto a la restricción de tiempo.
(a) El Team acuerda el Sprint backlog candidato.
(b) Product Owner prioriza según importancia.
(c) El team estima y confirma.

PLANIFICAR EL SPRINT (DURACIÓN ½ DÍA.

(3) El team explora cada ítem del Sprint Backlog en mayor detalle.
(4) Para lo cual debe valerse la especificación del requerimiento detallada (o lo más detallada posible).
(5) El team idea estrategias para la construcción de los ítems del sprint backlog.
(6) El team define las tareas de cada ítem del Sprint Backlog y estima las tareas.

Para cada uno de los ítems se definen tareas para su implementación.

Aplicando algún método se estiman las tareas (Es recomendable que cada una de las tareas insuma como máximo 16 hs,
aunque lo óptimo son 8hs). Se realiza una estimación inicial de las tareas y comienza el Sprint.

Caso práctico
Utilizar el método Delphi para realizar la estimación o Contabilizar la cantidad de horas por recurso disponibles para el Sprint.
Es decir contabilizar la cantidad de horas / días disponibles para el proyecto, tener en cuenta si las personas tienen planificado
tomarse vacaciones, licencias, días de examen, etc. o estén afectados a otros proyectos o tareas, por ejemplo reuniones de
ventas semanales. VALIDAR CON PLANIFICACION LA DISPONIBILIDAD DE LOS RECURSOS.

Para la facturación se tomará el escenario promedio resultante de la estimación.

Para la planificación se tomará el escenario optimista de la estimación.

Para cada una de las tareas se realiza una asignación inicial. Para este punto tener en cuenta la disponibilidad del recurso.
Confeccionar un documento para el cliente especificando los ítems que se realizarán en el Sprint, junto a los costos asociados
a cada uno de los ítems. Para los costos, se tomará la suma de los tiempos de cada tarea multiplicado al costo del perfil de
la persona al que se le asignó la tarea.

Se carga el Sprint backlog, asignando el tiempo estimado del escenario óptimo a cada tarea.

Se marca en el Product backlog la iteración en que se realizará el ítem incluido en el Sprint.

Seidor – Propuesta Técnica. 24

 8.4.4.- DAILY MEETING.

Esta reunión se efectúa TODOS los días.

PERSONAS AFECTADAS.

ScrumMaster.
Team.

DURACIÓN.

Típicamente 15 minutos.

TAREAS

Sobre cada una de las tareas, cada miembro responde 3 preguntas:

¿Que realizó el día anterior?

¿A qué se compromete a realizar el día de hoy?
¿Qué necesita saber el equipo?
o Obstáculos que impiden el progreso.
o Necesidad de colaborar o colaboración de otros.
o Descubrimientos y aprendizajes importantes.

Sobre la información que realizó el día anterior, se solicita también cuanto tiempo le insumió, ésta información se transcribe
(se documenta) en el Sprint backlog.

Sobre a qué se compromete a realizar en el día y las necesidades se transcribe en un documento de seguimiento diario.
Las conversaciones adicionales deberán posponerse.

Los No miembros del Team pueden observar pero NO participar.

8.4.5.- SPRINT REVIEW.

Esta reunión se realiza el día posterior a la finalización del sprint. En este momento el equipo tiene la oportunidad de mostrar
su avance al product owner y los usuarios clave (stakeholders).

PERSONAS AFECTADAS.

Product Owner.
Stakeholders.
Seidor – Propuesta Técnica. 25
 ScrumMaster.
Team.

DURACIÓN.

Cerca de medio (½) día.

TAREAS.

El sistema debe ser desplegado en un equipo de QA.

El Team presenta el incremento de producto completado al Product Owner y los Stakeholders. Los ítems
incompletos del product backlog no son presentados. Revisión de las metas del Sprint. Los Stakeholders realizan
comentarios.
Product Owner, stakeholders, y Development Team, discuten y hacen ajustes al Product Backlog.
El Team crea acciones a incluir en el Sprint Backlog para el próximo Sprint y el Product Owner los prioriza.

POR PRODUCTO COMPLE TADO SE ENTIEN DE QUE …

El código está escrito y compilado.

El código superó el test unitario.
El código adhiere al estándar de codificación seleccionado.
El código está “limpio” y refactorizado.
El código se encuentra en el repositorio (check-in) y construido (builds).
Los ítems del backlog fueron testeados funcionalmente.
La instalación y deploy están listas.
La documentación y/o entrenamiento está listo.

8.4.6.- SPRINT RETROSPECTIVE.

Esta reunión se realiza a continuación de la Sprint Review.

PERSONAS AFECTADAS.

ScrumMaster.
Team.
Product Owner (opcional).

DURACIÓN.
Cerca de medio (½) día.

TAREAS.
Cada miembro del Team responde 2 preguntas:
Seidor – Propuesta Técnica. 26
 o ¿Qué fue bien durante el Sprint?
o ¿Qué podemos mejorar para el siguiente Sprint?.
o SAMOLO – Same As, More Of, Less Of.
El ScrumMaster registra y resume las respuestas.
El Team prioriza los puntos de mejora.
Identifican la lista de impedimentos encontrados.

8.5.- ARTEFACTOS.

8.5.1.- VISIÓN.

Este artefacto, representa una “fotografía” del futuro, generalmente a mediano / largo plazo. Establece hacia dónde nos
dirigimos, qué se quiere lograr; sin visión, no podemos enfocar nuestras acciones. La visión es crítica para toda organización,
empresa o equipo, y es necesaria para sobrevivir como organización y le da vitalidad.
Aquí se identifican las metas totales del proyecto, las estrategias para lograrlas y define la inversión y el compromiso de
recursos.

En la práctica este artefacto generalmente es un documento que tiene que estar presente SIEMPRE por todas las
componentes involucrados (Product owner, ScrumMaster y Team).

8.5.2.- PRODUCT BACKLOG.

El product backlog es el corazón del proceso, básicamente es una lista priorizada de requerimientos, features, store users,
etc. Cosas que el cliente quiere, descritas utilizando la terminología del cliente.

8.5.3.- SPRINT BACKLOG.

El sprint backlog está conformado por los ítems del product backlog que fueron seleccionados para que sean desarrollados
en un sprint.

8.6.- ROLES.

8.6.1.- PRODUCT OWNER.

El foco del Product Owner o dueño del producto es el ROI. Ordena el proyecto, Sprint por Sprint, para proporcionar mayor
ROI y valor a la organización.

Decide las features del producto.

Decide fechas y contenido de releases (Sprints).
Es responsable por el ROI del producto.
Prioriza features según el valor del mercado.

Seidor – Propuesta Técnica. 27

 Acepta o rechaza el trabajo realizado.
Define las condiciones de aceptación de cada Requerimiento.

8.6.1.- SCRUMMASTER.

El Scrum Master es el responsable del éxito del proyecto, y él o ella ayuda a aumentar la probabilidad del éxito, ayudando al
product owner a armar un product backlog de mayor valor y ayudar al equipo transformar ese product backlog en funcionalidad.

Se asegura que el equipo actúa óptimamente.

Protege al equipo de “interferencia” externa.
Asegura que se siga el proceso.
Invita a las reuniones (SCRUM, Review,Planning ).
Coordina las reuniones.
Facilitador, quita los impedimentos al team y al product owner.
Focalizado en mantener en movimiento el proceso y asegura que funcione.
Quitar las barreras entre el desarrollo y el cliente así que el cliente conduce directamente el desarrollo. Asegura la
cooperación.
Enseñar al cliente cómo maximizar el ROI y satisfacer sus objetivos con Scrum.
Mejorar la salud del equipo de desarrollo facilitando creatividad y el empowerment.
Mejorar la productividad del equipo del desarrollo de cualquier manera posible.
Mejorar las prácticas de ingeniería y las herramientas, así cada incremento de la funcionalidad es potencialmente
entregable.
Tracking y Reporting.
(a) Informar el estado actual.
(b) Registrar los cambios en planes y por qué.
(c) Analizar y registrar inconvenientes sucedidos y acciones a mejorar.
(d) Gráficos grandes bien visibles y tableros de tareas. (Burn Down and Task Boards).

8.6.2.- EL EQUIPO.

El equipo es responsable de manejarse y tiene la autoridad completa para hacer cualquier cosa a fin de satisfacer la meta del
Sprint dentro de las pautas, de los estándares, y de las convenciones de la organización y de Scrum.

Hasta 10 participantes.
Selecciona los objetivos del SPRINT.
El fin justifica los medios (dentro del proceso).
Organiza su tiempo y su trabajo.
Responsables de su trabajo.
Realiza el DEMO al Product Owner.
El equipo conduce el producto de una perspectiva táctica.
Responsable de las estimaciones de tamaño de los ítems del product backlog.
Confirma los ítems del sprint backlog. Planificacion de las tareas y estimación.
Seidor – Propuesta Técnica. 28
 Toma decisiones de diseño e implementación.
Responsable de los estándares y prácticas.
Se compromete a entregar incrementos de software - y lo entrega.

Utónomo y auto-organizado, pero responsable ante el product owner para entregar según lo prometido.

Seidor – Propuesta Técnica. 29