DOCUMENTO DISEÑO DE LA BASE DE DATOS

LOGOTIPOS PENDIENTES DE AUTORIZACIÓN

+

30 de Junio de 2013

“FORMULACIÓN, ARTICULACIÓN E IMPLEMENTACIÓN DE UN SISTEMA INTEGRADO Y AUTOMATIZADO DE PLANIFICACIÓN, SEGUIMIENTO Y EVALUACIÓN DE LA GESTIÓN PARA RESULTADOS DE DESARROLLO EN LA CORPORACIÓN MUNICIPAL DE CUENCA”

DOCUMENTO 20: DISEÑO DE LA BASE DE DATOS DEL SIGPRD

DOCUMENTO 21: DISEÑO ARQUITECTÓNICO DEL SIGPRD

DOCUMENTO 22: DISEÑO DE INTERFACES DE USUARIO, ENTRE MÓDULOS DEL SIGPRD, Y CON OTROS SISTEMAS EXTERNOS


+

FASE 2

DOCUMENTO 20: DISEÑO DE LA BASE DE DATOS DEL SIGPRD


30 de Junio de 2013

FORMULACIÓN, ARTICULACIÓN E IMPLEMENTACIÓN DE UN SISTEMA INTEGRADO Y AUTOMATIZADO DE PLANIFICACIÓN, SEGUIMIENTO Y EVALUACIÓN DE LA GESTIÓN PARA RESULTADOS DE DESARROLLO EN LA CORPORACIÓN MUNICIPAL DE CUENCA

30 de Junio de 2013

FASE 2 DOCUMENTO 20: Diseño de la Base de Datos del SIGPRD

ÍNDICE 1.-CONCEPTOS Y CONVENIOS............................................................................ 1

1.1.-TABLAS Y MODELOS................................................................................ 1 1.2.-ENTIDADES QUE VARÍAN EN EL TIEMPO................................................ 2

2.-TABLAS........................................................................................................... 4

2.1.-USUARIOS Y PERMISOS.......................................................................... 4 Tabla: roles Modelo: Rol ................................................................................4 Tabla: usuarios Modelo: Usuario.....................................................................5

2.2.-PERSONAS Y ENTIDADES........................................................................ 5 Tabla: cargos Modelo: Cargo..........................................................................7 Tabla: competencias Modelo: Competencia .....................................................7 Tabla: entidades Modelo: Entidad...................................................................7 Tabla: personas Modelo: Persona ...................................................................7 Tabla: tipos_entidades Modelo: TipoEntidad ....................................................8 Tabla: tipos_gad Modelo: TipoGad..................................................................8

2.3.-GEORREFERENCIAS ................................................................................ 9 Tabla: cantones Modelo: Canton ..................................................................11 Tabla: paises Modelo: Pais ...........................................................................11 Tabla: parroquias Modelo: Parroquia.............................................................11 Tabla: provincias Modelo: Provincia ..............................................................12 Tabla: regiones Modelo: Region ...................................................................12 Tabla: territorios Modelo: Territorio ..............................................................13

2.4.-ALMACÉN DE DATOS ............................................................................. 13 Tabla: cargas_datos Modelo: CargaDatos......................................................15 Tabla: conjuntos_datos Modelo: ConjuntoDatos.............................................15 Tabla: cruces Modelo: Cruce ........................................................................16 Tabla: cruces_dimensiones Modelo: CruceDimension......................................16 Tabla: datos_dimensiones Modelo: DatoDimension ........................................16 Tabla: datos_formatos Modelo: DatoFormato ................................................17 Tabla: datos_referencias_temporales Modelo: DatoReferenciaTemporal...........17 Tabla: datos_referencias_territoriales Modelo: DatoReferenciaTerritorial ..........17 Tabla: datos_secundarios Modelo: DatoSecundario ........................................17 Tabla: dimensiones Modelo: Dimension.........................................................18 Tabla: formatos Modelo: Formato.................................................................18 Tabla: fuentes Modelo: Fuente .....................................................................19 Tabla: parametros_carga Modelo: ParametroCarga ........................................19 Tabla: referencias_temporales Modelo: ReferenciaTemporal ...........................19 Tabla: referencias_territoriales Modelo: ReferenciaTerritorial ..........................20


30 de Junio de 2013


Tabla: responsables_datos Modelo: ResponsableDatos ...................................20 Tabla: valores_codificados Modelo: ValorCodificado .......................................20

2.5.-CONFIGURACIÓN DE LOS PLANES........................................................ 20 Tabla: articulacion_externa Modelo: ArticulacionExterna .................................23 Tabla: articulacion_externa_proyectos Modelo: ArticulacionExternaProyectos ...23 Tabla: articulacion_interna_proyectos Modelo: ArticulacionInternaProyectos ....23 Tabla: estructuras_planes Modelo: EstructuraPlan..........................................23 Tabla: niveles_estructurales Modelo: NivelEstructural .....................................23 Tabla: planes Modelo: Plan ..........................................................................24

2.6.-CONTENIDO DE LOS PLANES ................................................................ 25 Tabla: divisiones_estructurales Modelo: DivisionEstructural.............................25 Tabla: lineamientos_estructurales_externos Modelo: LineamientoEstructuralExterno .........................................................................26 Tabla: lineamientos_estructurales_internos Modelo: LineamientoEstructuralInterno..........................................................................26 Tabla: lineamientos_externos Modelo: LineamientoExterno.............................26 Tabla: lineamientos_internos Modelo: LineamientoInterno..............................26

2.7.-PROYECTOS........................................................................................... 27 Tabla: actores Modelo: Actor........................................................................28 Tabla: ambitos_proyectos Modelo: AmbitoProyecto ........................................28 Tabla: autorizaciones Modelo: Autorizacion ...................................................28 Tabla: desgloses_presupuestos Modelo: DesglosePresupuesto ........................29 Tabla: destinatarios Modelo: Destinatario ......................................................29 Tabla: financiaciones Modelo: Financiacion....................................................29 Tabla: hitos Modelo: Hito.............................................................................29 Tabla: insumos Modelo: Insumo...................................................................30 Tabla: modalidades_ejecucion Modelo: ModalidadEjecucion............................30 Tabla: objetivos_proyectos Modelo: ObjetivoProyecto ....................................30 Tabla: proyectos Modelo: Proyecto ...............................................................31 Tabla: comentarios Modelo: Comentario .......................................................32

2.8.-MATRIZ DE MARCO LÓGICO / INDICADORES ...................................... 32 Tabla: indicadores Modelo: Indicador............................................................34 Tabla: indicadores_datos Modelo: IndicadorDato ...........................................35 Tabla: metas Modelo: Meta..........................................................................35 Tabla: objetivos_indicadores Modelo: ObjetivoIndicador .................................35 Tabla: objetivos_logicos Modelo: ObjetivoLogico............................................35 Tabla: supuestos Modelo: Supuesto..............................................................36 Tabla: verificaciones_metas Modelo: VerificacionMeta ....................................36 Tabla: verificaciones_supuestos Modelo: VerificacionSupuesto ........................36


30 de Junio de 2013


2.9.-GESTIÓN FINANCIERA.......................................................................... 37 Tabla: clasificador_cuentas Modelo: ClasificadorCuentas.................................37 Tabla: codigos_presupuestarios Modelo: CodigoPresupuestario .......................38 Tabla: estados_presupuestarios Modelo: EstadoPresupuestario .......................38

2.10.-OTRAS TABLAS .................................................................................... 39 Tabla: documentos Modelo: Documento........................................................39 Tabla: logged_exceptions Modelo: LoggedException ......................................39


30 de Junio de 2013

FASE 2 DOCUMENTO 20: Diseño de la Base de Datos del SIGPRD 1

DO

CU

MEN

TO

20

DISEÑO DE LA BASE DE DATOS DEL SIGPRD

1.-CONCEPTOS Y CONVENIOS

1.1.-TABLAS Y MODELOS Las tablas de la base de datos tienen nombres en minúsculas y en general denotan la entidad que la tabla representa en plural. A cada tabla le corresponden un “Modelo” que se define mediante una clase en lenguaje Ruby en el código de la aplicación y que especifica de forma declarativa columnas, asociaciones con otros modelos, forma de validación, reglas de negocio, etc. Los nombres de modelo tienen iniciales en mayúsculas y denotan en general un nombre singular.

Todas las claves primarias tienen el nombre “id” y son números enteros (son siempre claves “surrogate” o artificiales que no guardan relación con otros atributos). Las claves foráneas tienen por lo general el nombre de la tabla externa en singular con el sufijo “_id”.

En este documento se presenta el modelo de datos por módulos funcionales, acompañando cada uno de un diagrama del módulo y del listado de tablas y columnas. Los diagramas indican de forma abreviada las columnas de la tabla y las relaciones entre tablas con esta simbología:

Leyenda

Polimorfismo

A i: integer s: string tx: text f: float n: decimal b: boolean g: geometry d: date dt: datetime

B clave foránea de A

1:n

C

n:m

D clave foránea de A

1:1

E

G clave foránea de E ó F

1:n

F

1:n

E

H clave foránea de E ó F

1:1

F

1:1


30 de Junio de 2013


Las relaciones “Polimórficas” consisten en relaciones cuya clave foránea se compone de dos columnas: una que especifica la tabla foránea (con sufijo _type) y otra que especifica la clave primaria (con sufijo _id).

Las relaciones con tablas de otros módulos se indican con líneas grises y las tablas mencionadas mediante óvalos sin mostrar sus columnas.

En los listados se indica la clave primaria en la columna PK y para las claves foráneas se indica la tabla a la que hacen referencia en la columna FK.

Las columnas que tienen valores codificados son en general números enteros y el nombre de columna tiene el sufijo “_id”. Los valores se indican en los listados en la última columna. 1.2.-ENTIDADES QUE VARÍAN EN EL TIEMPO Algunas tablas representan entidades que pueden variar en el tiempo (pero no frecuentemente). Por ejemplo las divisiones político administrativas, clasificaciones estadística, clasificadores presupuestarios, etc.

Para estos casos se ha diseñado un mecanismo mediante el cual cada fila de la tabla representa una ‘iteración’ o revisión de la entidad; cada iteración tiene un periodo de vigencia que puede definirse con detalle de fecha en días. El mecanismo se basa en tres columnas:

identity: es una columna que identifica la entidad que varía con el tiempo. Esta

columna es redundante y coincide normalmente con otra columna o bien se calcula en función de otras, pero existe como columna independiente para simplificar y homogeneizar el tratamiento de estas tablas.

effective_from: Es la fecha (codificada en un entero de forma AAAAMMDD) en que la iteración entra en vigor. El valor especial 0 indica que la iteración se considera vigente en cualquier fecha pasada.

effective_to: Es la fecha en que la iteración deja de estar en vigor; el valor especial 99999999 indica que la iteración es la actualmente vigente.

En rigor una iteración se considera vigente desde la fecha “effective_from” (inclusiva) hasta antes de “effective_to” (exclusiva).


30 de Junio de 2013


Las tablas de este tipo tienen también como las demás una columna id de tipo entero como clave primaria (de la iteración). Normalmente las relaciones con tablas de este tipo se establecen mediante la columna identity y no id; estas claves foráneas usan el sufijo “_identity”. Las entidades representadas en estas tablas puede haber desaparecido: esto ocurren cuando la última iteración tiene una fecha effective_to menor que 99999999.

En la aplicación (en los “Modelos”) se dispone de numerosas funciones para consultar estas tablas y acceder a la última revisión de los elementos, la revisión vigente en una fecha dada, etc.

Las tablas que incorporan este mecanismo son: La divisiones político-administrativas: regiones, provincias, cantones y parroquias.

Los valores de dimensiones discretas de datos e indicadores (valores_codificados).

Los planes.

En el caso de los planes, la iteración inicial contiene la definición original del plan y las siguientes representan las revisiones del plan. 1.3.-VINCULACIÓN DE ELEMENTOS REVISADOS En muchas de las tablas relacionadas con la planificación se cuenta con una columna “modelo_id” que contiene la clave de otra fila de la misma tabla que sirve como modelo (precede) a la entidad representada. El objeto es establecer una continuidad entre entidades como objetivos, programas, ejes, etc. que pueden variar entre revisiones de los planes pero que frecuentemente tienen una continuidad.


30 de Junio de 2013


2.-TABLAS

2.1.-USUARIOS Y PERMISOS

El modelo “Usuario” representa una cuenta de usuario para acceder al sistema. El usuario se puede vincular con un registro de “Persona” que contiene la identificación e información de contacto de quien tiene asignada la cuenta. Cada usuario tiene asignado también un “Rol” que consiste en una colección de permisos y restricciones serializados en una columna de tipo texto.

Tabla: roles Modelo: Rol

columna PK FK tipo comentarios/valores

id Sí integer

nombre character varying(255)

permisos text

created_at timestamp

updated_at timestamp


30 de Junio de 2013


Tabla: usuarios Modelo: Usuario


id Sí integer

rol_id roles integer

persona_id personas integer


email character varying(255)

encrypted_password character varying(255)

reset_password_token character varying(255)

reset_password_sent_at timestamp

remember_created_at timestamp

sign_in_count integer

current_sign_in_at timestamp

last_sign_in_at timestamp

current_sign_in_ip character varying(255)

last_sign_in_ip character varying(255)

failed_attempts integer

unlock_token character varying(255)

locked_at timestamp

admin boolean

last_seen_on timestamp



2.2.-PERSONAS Y ENTIDADES

“Persona” contiene datos identificativos y de contacto de personas y otros organismos (personas físicas y jurídicas).

“Entidad” representa una organización, institución, empresa, así como sus unidades operativas, departamentos, etc. Tiene una estructura jerárquica mediante la columa “parent_id” que permite representar el diagrama de las instituciones. “TipoEntidad” permite definir los tipos de entidades como secretarías, departamentos, empresas, etc. “TipoGAD” representa los diferentes niveles de Gobiernos Autónomos Descentralizados (Provincial, Cantonal, etc.); permite identificar las entidades que corresponden a GADs y las vincula con las competencias asignadas por la COTAD, registradas en el modelo “Competencia”.

La tabla “cargos” establece una relación N:M entre las personas físicas y la entidad a la que pertenecen, junto con el cargo que ocupan en la misma. Existen también una relación


30 de Junio de 2013


N:M (mediante la tabla interna “entidades_personas”) entre las entidades y los datos de persona jurídica correspondientes a las mismas.

Como se verá en otros módulos, la relaciones con entidades/organismos/instituciones/etc. se establecen siempre a través de la tabla “entidades”. Por ejemplo la unidad operativa gestora de un proyecto, los actores involucrados en los proyectos, los datos de los usuarios del sistema…


30 de Junio de 2013


Tabla: cargos Modelo: Cargo


id Sí integer

entidad_id entidades integer


cargo character varying(255)

posicion integer



Tabla: competencias Modelo: Competencia


id Sí integer

descripcion text

articulo text



Tabla: entidades Modelo: Entidad


id Sí integer

tipo_entidad_id tipos_entidades integer

territorio_id territorios integer

parent_id entidades integer


siglas character varying(10)

codigo_presupuestario character varying(255)



Tabla: personas Modelo: Persona


id Sí integer

provincia_identity provincias character varying(2)

canton_identity cantones character varying(4)

parroquia_identity parroquias character


30 de Junio de 2013



varying(6)

tipo_id integer 1=>"Persona física", 2=>"Persona jurídica"

cedula_ruc character varying(255)

nº cédula para personas físicas; ruc para personas jurídicas


nombre de pila / razón social

apellidos character varying(255)

sólo para personas físlicas

tel character varying(255)

movil character varying(255)

fax character varying(255)


direccion character varying(255)

codigo_postal character varying(8)

comentarios text



Tabla: tipos_entidades Modelo: TipoEntidad


id Sí integer

tipo_gad_id tipos_gad integer

descripcion text



Tabla: tipos_gad Modelo: TipoGad


id Sí integer

descripcion text

nivel integer




30 de Junio de 2013


2.3.-GEORREFERENCIAS

Las tablas como provincias, cantones o parroquias representan entidades que sirven de referencia geográfica de los datos. Tiene columnas geográficas (gestionadas con PostGIS) que permiten la representación en mapas de los datos asociados a ellas. Además para soportar la variación en el tiempo de estas referencias sin perder la continuidad en el análisis y representación de la información se emplea el mecanismo de identidades y periodos de vigencia que se describe más arriba.

La tabla “territorios” permite la configuración de territorios arbitrarios compuestos

por la agregación de georreferencias simples. Esta tabla se utiliza para asignar ámbitos territoriales arbitrarios a otras entidades, como los Proyectos.


30 de Junio de 2013



30 de Junio de 2013


Tabla: cantones Modelo: Canton


id Sí integer


identity character varying(4)

effective_from integer

effective_to integer

codigo character varying(4)


termino geometry(MultiPolygon,32717)

termino_simplificado geometry(MultiPolygon,32717)



Tabla: paises Modelo: Pais


id Sí integer


codigo character varying(2) codigo ISO‐3166 de dos carácteres

codigo_3 character varying(3) codigo ISO‐3166 de tres carácteres

codigo_num character varying(3) codigo ISO‐3166 numérico (=id)








Tabla: parroquias Modelo: Parroquia


id Sí integer

canton_identity cantones character varying(4)



tipo_id integer 1=>"Urbana", 2=>"Rural"

termino geometry(MultiPolygon,32717) Delimitación (perímetro)


30 de Junio de 2013









Tabla: provincias Modelo: Provincia


id Sí integer

region_identity regiones character varying(1)










Tabla: regiones Modelo: Region


id Sí integer

pais_identity paises integer











30 de Junio de 2013


Tabla: territorios Modelo: Territorio

columna PK

FK tipo comentarios/valores

id Sí integer

referencia_territorial_componentes_id

referencias_territoriales

integer

descripcion character varying(255)

identities_componentes text



simple character varying(255)

Calculado: en caso de componerse de un único elemento geográfico se guarda a aquí la identidad



2.4.-ALMACÉN DE DATOS Las tablas del almacén de datos registran datos y metadatos empleados en el cálculo de indicadores. Además de las tablas mostradas aquí, que representan principalmente los metadatos del almacén, para cada conjunto de datos registrado en “ConjuntoDatos” y “DatosSecundarios” existirán tablas adicionales cuyo nombre consta del prefijo “datos_” y del código registrado. La tabla “conjuntos_datos” define el contenido de las tablas de datos principales (maestras), y “datos_secundarios” tablas de entidades auxiliares (esclavas). Las columnas de las tablas de datos pueden corresponder a referencias temporales, referencias espaciales, dimensiones o cruces de dimensiones. Los valores de referencias espaciales corresponden a las tablas de georreferencias o bien a posiciones geográficas puntuales dadas por coordenadas. Los valores de dimensiones pueden ser de tipo continuo o discreto, en cuyo caso corresponden a valores de la tabla “valores_codificados”. Tanto las georreferencias como los valores codificados emplean el mecanismo de identidades y periodos de vigencia para permitir la variabilidad en el tiempo. En “CargaDatos” se registran las actualizaciones de datos del almacén realizadas. Esta tabla permite el control del proceso de carga de datos mediante la columna estado que puede tener los valores “en proceso”, “finalizada con error” ó “finalizada con éxito”. Las tablas de datos del almacén están vinculadas a las cargas de datos, lo cual permite eliminar los datos de una carga en caso de detectarse algún problema.


30 de Junio de 2013



30 de Junio de 2013


Tabla: cargas_datos Modelo: CargaDatos


id Sí integer

conjunto_datos_id conjuntos_datos integer

usuario_id usuarios integer


formato_id formatos integer

fecha date

observaciones text

periodo_inicio integer

periodo_fin integer

inicio timestamp

fin timestamp

log text


archivo_file_name character varying(255)

archivo_content_type character varying(255)

archivo_file_size integer

archivo_updated_at timestamp

manual boolean

estado_id integer 1=>"En proceso", 2=>"Error", 3=>"Correcto"

parametros text

Tabla: conjuntos_datos Modelo: ConjuntoDatos


id Sí integer



periodicidad integer

definicion_archivo character varying(255)

definicion_linea integer

observaciones_carga text

advertencias text

tipo_id integer 1=>"Predefinido", 2=>"Simple", 3=>"Interno"


30 de Junio de 2013





Tabla: cruces Modelo: Cruce


id Sí integer



totales boolean



Tabla: cruces_dimensiones Modelo: CruceDimension


id Sí integer

cruce_id cruces integer

dimension_id dimensiones integer

position integer



Tabla: datos_dimensiones Modelo: DatoDimension


id Sí integer

dato_id (dato) integer

dato_type (dato) character varying(255)




position integer

fija boolean

sin_total boolean




30 de Junio de 2013


Tabla: datos_formatos Modelo: DatoFormato


id Sí integer


formato_id formatos integer

position integer



Tabla: datos_referencias_temporales Modelo: DatoReferenciaTemporal


id Sí integer


referencia_temporal_id referencias_temporales integer

position integer



Tabla: datos_referencias_territoriales Modelo: DatoReferenciaTerritorial


id Sí integer


referencia_territorial_id referencias_territoriales integer

position integer



Tabla: datos_secundarios Modelo: DatoSecundario


id Sí integer







30 de Junio de 2013


Tabla: dimensiones Modelo: Dimension


id Sí integer



position integer

aditiva boolean

ndecimales integer



tipo_id integer

1=>"Valores codificados (códigos numéricos)", 2=>"Valores numéricos arbitrarios", 3=>"Valores numéricos enteros arbitrarios", 4=>"Valores textuales arbitrarios", 6=>"Valores lógicos", 7=>"Valores codificados (códigos alfanuméricos)", 8=>"Fecha", 9=>"Hora", 10=>"Fecha y hora"



Tabla: formatos Modelo: Formato


id Sí integer



importacion boolean indica que el formato se soporta para la exportación de cualquier conjunto de datos

exportacion boolean indica que el formato se soporta para la importación de cualquier conjunto de datos






30 de Junio de 2013


Tabla: fuentes Modelo: Fuente


id Sí integer




position integer



Tabla: parametros_carga Modelo: ParametroCarga


id Sí integer



código (clave) del parámetro


descripción del parámetro

tipo_id integer 1=>"Entero", 2=>"Texto", 3=>"Número", 4=>"Lógico", 5=>"Plan"

valor text valor por defecto del parámetro

posicion integer

Tabla: referencias_temporales Modelo: ReferenciaTemporal


id Sí integer



definicion character varying(255) definición de columnas

periodicidad integer





descripcion_plural character varying(255)


30 de Junio de 2013


Tabla: referencias_territoriales Modelo: ReferenciaTerritorial


id Sí integer



descripcion_plural character varying(255)

modelo_referencia character varying(255)

columnas_modelo text columnas de identificación del modelo

definicion text definición de columnas para claves foráneas





Tabla: responsables_datos Modelo: ResponsableDatos


id Sí integer



Tabla: valores_codificados Modelo: ValorCodificado


id Sí integer


position integer








2.5.-CONFIGURACIÓN DE LOS PLANES Se diferencian dos tipos de planes:


30 de Junio de 2013


Planes Estratégicos

Los planes estratégicos pueden contener o no definiciones de proyectos. En caso de tenerlas, son proyectos cuya ejecución se realiza en los planes operativos derivados del plan estratégico; el ciclo de vida de los proyectos estratégicos llega hasta la ejecución, pero esta se desarrolla en planes operativos. Son planes estratégicos el Plan Nacional del Buen Vivir, el Plan Estratégico de Desarrollo y Ordenación Territorial, los Planes Sectoriales o los Planes Estratégicos de las empresas.

Cada plan tiene un código alfanumérico que lo identifica así como a las sucesivas revisiones del mismo plan.

Planes Operativos

Un plan operativo debe estar vinculado a un plan estratégico que sirve de modelo. (Además sus componentes pueden estar lineados con otros planes estratégicos).

Los proyectos de un plan operativo tienen un ciclo de vida completo que incluye la

ejecución, seguimiento, gestión financiera y monitoreo. Son planes operativos los Planes Operativos Anuales (POAs).

El modelo de datos de la planificación está diseñado para permitir que la estructura de los planes y los lineamientos con otros planes puedan ser distintos no sólo entre diferentes planes, sino también variar entre revisiones del mismo plan, sin perder la capacidad de realizar un monitoreo y evaluación a través de las revisiones de los planes.

El módulo de configuración de planes define el esquema o estructura de cada plan. Los “niveles estructurales” son todos los elementos organizativos del plan, como ejes, objetivos, políticas, programas, etc. Hay dos tipos de niveles (identificados por la columna “tipo_id”): los que representan objetivos y los que representa otro tipo de estructuras (divisiones).

La estructura del plan define las posibles relaciones entre niveles estructurales. La tabla “articulación_externa” define las relaciones posibles de lineamiento con otros planes. La tabla “articulación_interna_proyectos” define con qué niveles estructurales del plan si vinculan los proyectos; por lo general los proyectos se agrupan en programas, pero esto pueden cambiarse en la configuración del plan mediante esta tabla. La tabla “articulación_externa_proyectos” define los posibles lineamietos entre proyectos del plan y otros planes.


30 de Junio de 2013



30 de Junio de 2013


Tabla: articulacion_externa Modelo: ArticulacionExterna


id Sí integer

nivel_estructural_padre_id niveles_estructurales integer

nivel_estructural_hijo_id niveles_estructurales integer

multiplicidad_id integer 1=>"Simple", 2=>"Múltiple"

Tabla: articulacion_externa_proyectos Modelo: ArticulacionExternaProyectos


id Sí integer

plan_id planes integer



Tabla: articulacion_interna_proyectos Modelo: ArticulacionInternaProyectos


id Sí integer




Tabla: estructuras_planes Modelo: EstructuraPlan


id Sí integer


nivel_estructural_hijo_id niveles_estructurales integer



Tabla: niveles_estructurales Modelo: NivelEstructural


id Sí integer


modelo_id niveles_estructurales integer


30 de Junio de 2013





nombre_plural character varying(255)

tipo_id integer 1=>"Objetivo", 2=>"División", 3=>"Clasificador"

raiz boolean

clasificador_raiz boolean

rango integer

Tabla: planes Modelo: Plan


id Sí integer


gestor_id entidades integer

plan_estrategico_id planes integer



descripcion text

fecha_aprobacion date

fecha_inicio date debe coincidir con effective_from excepto para la iteración inicial

fecha_limite date si se ha abierto revisión del plan debe coincidir con effective_to

observaciones text

tipo_id integer 1=>"Estratégico", 2=>"Operativo"

fase_id integer 1=>"Configuración", 2=>"Definición", 3=>"Programación", 4=>"Ejecución", 5=>"Revisado", 6=>"Finalizado"

tipo_anual boolean







30 de Junio de 2013


2.6.-CONTENIDO DE LOS PLANES

Las tablas de contenido de los planes contienen los elementos estructurales de los mismos como objetivos, ejes, políticas, etc. (“divisiones_estructurales”), las relaciones entre ellos (“lineamientos_estructurales_internos”), la lineación con otros planes (“lineamientos_estructurales_externos”), la asignación de proyectos a los elementos del plan, por lo general a los programas (lineamientos_internos) y el lineamiento de proyectos con otros planes (lineamientos_externos). Por su complejidad, se muestran las tablas que almacenan la información de los proyectos en otro módulo separado.

Tabla: divisiones_estructurales Modelo: DivisionEstructural


id Sí integer

nivel_estructural_id niveles_estructurales integer

modelo_id divisiones_estructurales integer


descripcion text

abierta boolean sólo para planes específicos y si nivel_estructural.tiene_proyectos?: admite proyectos específicos?


30 de Junio de 2013


Tabla: lineamientos_estructurales_externos Modelo: LineamientoEstructuralExterno


id Sí integer

division_estructural_padre_id divisiones_estructurales integer

division_estructural_hijo_id divisiones_estructurales integer

descripcion text

posicion integer

Tabla: lineamientos_estructurales_internos Modelo: LineamientoEstructuralInterno


id Sí integer

division_estructural_padre_id divisiones_estructurales integer

division_estructural_hijo_id divisiones_estructurales integer

descripcion text

posicion integer

Tabla: lineamientos_externos Modelo: LineamientoExterno


id Sí integer

objetivo_id divisiones_estructurales integer

proyecto_id proyectos integer

posicion integer

Tabla: lineamientos_internos Modelo: LineamientoInterno


id Sí integer

objetivo_id divisiones_estructurales integer


posicion integer


30 de Junio de 2013


2.7.-PROYECTOS

Los proyectos contienen además de sus datos básicos la información de la fase en que se encuentra el proyecto, la vinculación con un gestor, actores, destinatarios, etc. y la información de la matriz de marco lógico para el seguimiento y monitoreo.

El avance de los proyectos se gestiona mediante las fechas de inicio y fin efectivo del proyecto, los hitos (que tienen asignado el porcentaje de avance físico que representan), la información financiera y los indicadores asignados a la matriz de marco lógico.

Además se pueden asignar comentarios fechados para registrar cualquier información adicional sobre la ejecución del proyecto.


30 de Junio de 2013


Tabla: actores Modelo: Actor


id Sí integer



descripcion text



Tabla: ambitos_proyectos Modelo: AmbitoProyecto


id Sí integer



descripcion text



Tabla: autorizaciones Modelo: Autorizacion


id Sí integer

elemento_id (elemento) integer

elemento_type (elemento) character varying(255)


accion character varying(255) sufijo del permiso *_autorizacion_..

fase_anterior_id integer

fase_posterior_id integer

revocacion boolean Autorización inversa




30 de Junio de 2013


Tabla: desgloses_presupuestos Modelo: DesglosePresupuesto


id Sí integer


cantidad numeric(14,2)

descripcion text



position integer

Tabla: destinatarios Modelo: Destinatario


id Sí integer




descripcion text



position integer

Tabla: financiaciones Modelo: Financiacion


id Sí integer



cantidad numeric(15,2)



Tabla: hitos Modelo: Hito


id Sí integer


descripcion text

fecha date fecha fijada (comprometida) para el cumplimiento del hito


30 de Junio de 2013



fecha_estimada date fecha prevista efectivamente

fecha_realizacion date fecha en que se ha realizado el hito (si se ha realizado)

avance_fisico integer Porcentaje de avance (incremental) que representa el cumplimiento del hito



Tabla: insumos Modelo: Insumo


id Sí integer


objetivo_logico_id objetivos_logicos integer

clasificador_cuentas_identity clasificador_cuentas integer

modalidad_ejecucion_id modalidades_ejecucion integer

codigo_presupuestario_id codigos_presupuestarios integer


costo numeric(14,2)

fecha date

Tabla: modalidades_ejecucion Modelo: ModalidadEjecucion


id Sí integer

descripcion text




Tabla: objetivos_proyectos Modelo: ObjetivoProyecto


id Sí integer


descripcion text

tipo_id integer 1=>"General", 2=>"Específico"



posicion integer


30 de Junio de 2013


Tabla: proyectos Modelo: Proyecto


id Sí integer

responsable_id entidades integer

proyecto_estrategico_id proyectos integer


modelo_id proyectos integer

ambito_id territorios integer


denominacion text

descripcion text

prioridad_id integer 1=>"Alta", 2=>"Media", 3=>"Baja"

plazo_inicio integer Año inicial ejecución prevista (proyectos planes estratégicos)

plazo_fin integer Año final ejecución prevista (proyectos planes estratégicos)

fecha_inicio_previsto date Inicio previsto (proyectos planes operativos)

fecha_fin_previsto date Inicio previsto (proyectos planes operativos)

fecha_inicio_efectivo date Fecha en que se ha iniciado la ejecución de manera efectiva

fecha_fin_efectivo date Fecha en que se ha finalizado la ejecución de manera efectiva

fecha_firma date

presupuesto_total numeric(14,2) Presupuesto planeado total en $

tipo_id integer 1=>"Estratégico", 2=>"Operativo"

fase_id integer

1=>"Definición", 2=>"Planificación", 3=>"Ejecución", 4=>"Cierre", 5=>"Completado", 6=>"Cancelado", 7=>"Congelado"

codigo_presupuestario_programa character varying(2)

codigo_presupuestario_subprograma character varying(2)

codigo_presupuestario_proyecto character varying(3)




30 de Junio de 2013


Tabla: comentarios Modelo: Comentario


id Sí integer


texto text

fecha date


updated_at timestamp 2.8.-MATRIZ DE MARCO LÓGICO / INDICADORES

Los datos de marco lógico se vinculan a los proyectos a través de la tabla “objetivo_lógico” que contiene la jerarquía de fines, propósitos, componentes y actividades.

La tabla de indicadores y sus relaciones permite definir de modo flexible tanto indicadores de gestión cuyos valores serán aportados mediante el módulo de seguimiento como indicadores estratégicos que se calculen de manera automatizada usando datos estadísticos captados en el almacén de datos.


30 de Junio de 2013



30 de Junio de 2013


Tabla: indicadores Modelo: Indicador


id Sí integer

parent_id indicadores integer


referencia_territorial_minima_id referencias_territoriales integer

referencia_temporal_minima_id referencias_temporales integer






definicion text

observaciones text

tipo_id integer

1=>"Eficacia", 2=>"Eficiencia", 3=>"Calidad", 4=>"Economía"

metodo_calculo text descripción del método de cálculo (informativa)

ndecimales integer



unidades character varying(255)

unidades_abr character varying(255)

descripcion_valores character varying(255)

forma expandida de las unidades

mapa text

periodicidad integer frecuencia de medición

modulo character varying(255)

parametros text



parent_position integer


30 de Junio de 2013


Tabla: indicadores_datos Modelo: IndicadorDato


id Sí integer

indicador_id indicadores integer

dato_id indicadores integer

position integer



Tabla: metas Modelo: Meta


id Sí integer


objetivo_id (objetivo) integer

objetivo_type (objetivo) character varying(255)


Tabla: objetivos_indicadores Modelo: ObjetivoIndicador


id Sí integer



meta_id metas integer

observaciones text


redundante, para reasignar indicadores predefinidos

Tabla: objetivos_logicos Modelo: ObjetivoLogico


id Sí integer


parent_id objetivos_logicos integer

modelo_id objetivos_logicos integer




30 de Junio de 2013



nivel_logico_id integer 1=>"Fin", 2=>"Propósito", 3=>"Componente", 4=>"Actividad"

Tabla: supuestos Modelo: Supuesto


id Sí integer



descripcion text

probabilidad numeric(4,1)

grado_impacto numeric(4,1)

estado_id integer 1=>"Abierto", 2=>"Ocurrido", 3=>"Cerrado"

fecha_cierre date

Tabla: verificaciones_metas Modelo: VerificacionMeta


id Sí integer

cumplimiento boolean

observaciones text

fecha_inicio date inicio de la situación descrita

fecha_fin date fin de la situación descrita (opcional)

Tabla: verificaciones_supuestos Modelo: VerificacionSupuesto


id Sí integer

cumplimiento boolean

observaciones text

fecha_inicio date inicio de la situación descrita

fecha_fin date fin de la situación descrita (opcional)


30 de Junio de 2013


2.9.-GESTIÓN FINANCIERA

Para cada proyecto se registra la situación financiera mediante el estado presupuestario para fechas que será captado con la periodicidad que se fije. El modelo EstadoPresupuestario registra la información presupuestaria acumulada a una fecha determinada. Los datos del último día del mes se marcan como datos mensuales mediante el campo “mes”, lo que permite realizar eficazmente consultas de la evolución mensual presupuestarioa del un proyecto. Los datos presupuestarios se registran a nivel de partida presupuestaria, que pueden vincularse mediante el código presupuestario con el nivel inferior del los Objetivos Lógicos, es decir, con los “fines” de Marco Lógico.

Tabla: clasificador_cuentas Modelo: ClasificadorCuentas


id Sí integer

parent_id clasificador_cuentas integer



descripcion text





30 de Junio de 2013


Tabla: codigos_presupuestarios Modelo: CodigoPresupuestario


id Sí integer


clasificador_cuentas_identity clasificador_cuentas character varying(255)


ejercicio character varying(4)

programa character varying(2)

subprograma character varying(2)

proyecto character varying(3)

actividad character varying(3)

valor_fijo character varying(2)

organismo character varying(4)

prestamo character varying(4)

funcion character varying(3)

financiamiento character varying(3)

unidad character varying(4)

institucion character varying(3)



Tabla: estados_presupuestarios Modelo: EstadoPresupuestario


id Sí integer



fecha date

asignado_inicial numeric(14,2) Monto asignado inicialmente

codificado numeric(14,2) Presupuesto codificado (SIGEF)

comprometido numeric(14,2) Presupuesto comprometido a la fecha

devengado numeric(14,2) Presupuesto devengado a la fecha

pagado numeric(14,2) Presupuesto pagado a la fecha

mes integer




30 de Junio de 2013


2.10.-OTRAS TABLAS

La tabla “documentos” permite la asignación de archivos (documentos, imágenes, etc.) a planes, proyectos u otras entidades.

La tabla “logged_exceptions” es de uso interno para el mantenimiento de la

aplicación y registra información de los errores que se produzcan.

Tabla: documentos Modelo: Documento


id Sí integer

documentable_id (documentable) integer

documentable_type (documentable) character varying(255)



fecha date

version character varying(255)

titulo character varying(255)

archivo_file_name character varying(255)

archivo_content_type character varying(255)

archivo_file_size integer

archivo_updated_at timestamp



Tabla: logged_exceptions Modelo: LoggedException


id Sí integer

exception_class character varying(255)

controller_name character varying(255)

action_name character varying(255)

message text

backtrace text

environment text

request text



+

FASE 2

DOCUMENTO 21: DISEÑO ARQUITECTÓNICO DEL SIGPRD


30 de Junio de 2013


30 de Junio de 2013

FASE 2 DOCUMENTO 21: Diseño Arquitectónico del SIGPRD

ÍNDICE

1.-ARQUITECTURA DE SISTEMAS DEL SIGPRD.................................................. 1 1.1.-SISTEMA OPERATIVO .....................................................................................1 1.2.-PROCESOS.....................................................................................................1 1.3.-BASE DE DATOS.............................................................................................3 1.4.-ESCENARIO ACTUAL.......................................................................................4 1.5.-ESCENARIO ALTERNATIVO FUTURO ................................................................5

2.-ARQUITECTURA INTERNA DEL SIGPRD......................................................... 6

2.1.-MODELOS......................................................................................................6 2.2.-CONTROLADORES..........................................................................................6 2.3.-VISTAS..........................................................................................................7 2.4.-TAREAS DE SOPORTE.....................................................................................8


30 de Junio de 2013

FASE 2 DOCUMENTO 21: Diseño Arquitectónico del SIGPRD 1

D

OC

UM

ENTO

2

1

DDIISSEEÑÑOO AARRQQUUIITTEECCTTÓÓNNIICCOO DDEELL SSIIGGPPRRDD

1.-ARQUITECTURA DE SISTEMAS DEL SIGPRD El sistema SIGPRD está basado en un aplicación desarrollada en Ruby utilizando

el “framework” Ruby on Rails, que proporciona una arquitectura interna a la aplicación y una organización orientada a su operación como aplicación web. Esta aplicación encapsula toda la lógica y funcionalidad del sistema, tanto las funciones básicas modulares de soporte de GPRD (Gestión para Resultados en el Desarrollo), como la “lógica de negocio” que aplica estas funciones para responder al Modelo de Gestión de la Municipalidad de Cuenca.

1.1.-SISTEMA OPERATIVO Aunque es posible ejecutar la aplicación sobre una variedad de sistemas

operativos, y de hecho en los entornos de desarrollo se emplea Windows y Mac OS X, en producción se empleará Linux para garantizar el máximo rendimiento y fiabilidad del sistema. Esto permite también simplificar el mantenimiento del sistema: las tareas de puesta en marcha en el arranque, copias de seguridad, etc., serán automatizadas con unos sencillos ‘scripts’.

SERVIDOR HTTP

Dado que SIGPRD se trata de un sistema con arquitectura de aplicación web, la

comunicación tanto con usuarios finales (mediante navegadores de internet) como con otros sistemas se realizará a través de los protocolos HTTP y HTTPS. Esto se gestionará mediante software Apache 2, que servirá de interfaz entre el SIGPRD y el exterior.

1.2.-PROCESOS Distintas instancias de la aplicación pueden ejecutarse en paralelo como

procesos del sistema operativo anfitrión. Esto se hará con dos propósitos: permitir la escalabilidad en la respuesta a la demanda de usuarios concurrentes y mantener un tiempo de respuesta ágil derivando la ejecución de tareas costosas (cuya duración sea mayor de unos pocos segundos) a instancias de la aplicación en segundo plano. Entre


30 de Junio de 2013


estos procesos o instancias de la aplicación no existe ninguna forma comunicación inter-procesos salvo el uso de una base de datos común. La base de datos es por tanto la forma de coordinar y compartir información entre las instancias de la aplicación y esto simplifica la gestión de la concurrencia (gracias a las características transaccionales de la base de datos) y permite una mejor escalabilidad.

Cada instancia de la aplicación es ejecutada por el intérprete de Ruby, que es el

auténtico proceso en ejecución en el sistema operativo. El intérprete usado es la versión 1.9 del conocido por MRI; el intérprete canónico desarrollado en C y mantenido por el autor de Ruby, Yukihiro Matsumoto.

El sistema en producción se compondrá de dos tipos de instancias de la

aplicación: las que responden a las peticiones HTTP recibidas por el servidor web (Apache), a las que denominaremos instancias “web”, y las que ejecutan tareas en segundo plano: tareas de “larga duración” como la carga de archivos de datos, etc. En el ámbito de las aplicaciones web, en el que la respuesta al usuario, incluyendo los tiempos de latencia de la red, no debería superar uno o dos segundos para mantener una interactividad aceptable, cualquier tarea que supere esta duración debe evitar ser ejecutada por los procesos conectados al servidor http. A las tareas de segundo plano descritas las denominaremos “workers” ya que llevan a cabo tareas encomendadas desde la aplicación principal. En el caso de SIGPRD se prevé la operación de un único “worker”. Este “worker” permitirá también la realización de tareas periódicas, como la adquisición de datos presupuestarios, o la limpieza de archivos de trabajo y logs.

Para gestionar la coordinación entre las instancias web de la aplicación y el

worker se empleará un mecanismo de colas de tareas mediante una tabla de tareas de la base de datos. Se empleará para ello el componente “Queue Classic”. Esto permite una gran efectividad en recepción de los trabajos ya que se pueden utilizar las características de Listen/Notify de la base de datos para evitar que el proceso “Worker” esté bloqueado mientras comprueba la existencia de nuevos trabajos.

CONTROL Y MONITOREO DE PROCESOS

Dado que el sistema SIGPR se basa en la ejecución concurrente de instancias de

la aplicación de tipo web y de tipo worker, se precisa un sistema, que podríamos considerar como “middleware” o servidor de aplicaciones que se ocupe de controlar la puesta en marcha y parada de estas instancias, y de asegurar su correcto funcionamiento mediante un monitoreo constante de su funcionamiento.


30 de Junio de 2013


El control y monitoreo de las instancias de la aplicación se llevará acabo mediante dos componentes: El módulo Phusion Passenger para Apache y el sistema de monitoreo BluePill basado en Ruby.

Las instancias “web” de la aplicación serán gestionadas por Phusion

Passenger. Se trata éste de un módulo instalable en Apache que maneja de manera automática la puesta en marcha, el monitoreo y la parada de las instancias web en función de la carga de trabajo del sistema y los límites máximos configurados. Se trata este de un sistema muy robusto y de nulo mantenimiento que se adapta a las condiciones de uso de la aplicación y se recupera automáticamente de cualquier error que la aplicación pueda producir. Se ocupa así mismo de repartir la carga de trabajo (las peticiones HTTP recibidas por Apache) de manera óptima.

La instancia “worker” se gestionará de manera independiente a la aplicación web

principal mediante el sistema de monitoreo “BluePill” específico para Ruby. Este sistema permite ser configurado mediante umbrales de consumo de memoria y CPU para detectar posibles fallos en el funcionamiento del “worker” y realizar una recuperación automática parando y volviendo a poner en funcionamiento el proceso.

1.3.-BASE DE DATOS El SIGPRD basa su funcionamiento en el uso de una base de datos única y

centralizada que almacena toda la información necesaria para el funcionamiento del sistema y derivada de su operación. Como servidor de base de datos para gestionar esta base de datos se emplea PostgreSQL con el complemento PostGIS que añade al sistema funciones para el tratamiento de información geográfica. Dado los modestos requerimientos de recursos (memoria, CPU) de PostgreSQL y su fácil mantenimiento, resulta óptimo para ser ejecutado en el mismo servidor de la aplicación, simplificando así la instalación, configuración y mantenimiento del sistema.

MIGRABILIDAD

El framework Ruby on Rails empleado en el desarrollo de la aplicación gestiona el

acceso a la base de datos mediante una capa de abstracción que traduce las operaciones realizadas con los datos al lenguaje SQL específico de la base de datos y que soporta múltiples bases de datos, como PostgreSQL, MySQL, SQLite, Microsfot SQL Server, DB2 u Oracle. Esto permite configurar la aplicación para usar cualquiera de estos servidores.


30 de Junio de 2013


Sin embargo, la aplicación SIGPRD hace uso directo de algunas funciones de PostgreSQL, como ciertas funciones de búsqueda textual. Estas funciones requerirán ser adaptadas para permitir el uso de otras bases de datos.

Además SIGPRD emplea las funciones GIS del módulo PostGIS para dar soporte

a los mapas temáticos interactivos. Estas funciones no se usan directamente, sino a través del módulo RGeo. Actualmente existen adaptadores para que este módulo funcione con PostGIS, MySQL Spatial ó SpatiaLite. Para su empleo con otros sistemas, como Oracle Spatial debe desarrollarse un adaptador específico.

Mediante el desarrollo de este adaptador y del ajuste de las funciones directas de

búsqueda PostgreSQL que se utilizan, sería posible substituir el uso de PostgreSQL por otro servidor de base de datos, como Oracle.

1.4.-ESCENARIO ACTUAL


30 de Junio de 2013


1.5.-ESCENARIO ALTERNATIVO FUTURO Dadas las posibilidades de migración de la base de datos consideradas más

arriba, es posible contemplar un escenario alternativo en el que se podría eliminar el uso del servidor de bases de datos PostgreSQL para emplear en su lugar un servidor Oracle ya disponible y en operación en la Municipalidad. Esto eliminaría la necesidad de mantenimiento (aunque mínimas) de PostgreSQL, aprovecharía las licencias existentes de Oracle y podría simplificar los procesos de copia de seguridad de los datos. Las funciones realizadas por PostGIS se adaptarían para emplear Oracle Spatial en su lugar.

En este escenario la aplicación se configuraría para acceder a un servidor Oracle

externo. El sistema anfitrión de la aplicación quedaría reducido a ejecutar Apache y los sistemas de control y monitoreo. Para que este escenario sea factible es esencial que la comunicación entre el servidor de la aplicación y el servidor Oracle sea de alta velocidad, siendo recomendable que ambos servidores tengan conectividad dentro de la misma LAN.


30 de Junio de 2013


2.-ARQUITECTURA INTERNA DEL SIGPRD

Describiremos ahora la arquitectura interna de la aplicación SIGPRD, es decir el código Ruby basado en Ruby on Rails que constituye los “workers” e instancias “web” en ejecución.

El código de la aplicación SIGPR está organizado en base a la arquitectura MVC

(Model-View-Controller). Esta organización permite mantener de forma diferenciada la funcionalidad que da soporte a la lógica del sistema (en el caso del SIGPRD, el Modelo de Gestión GPRD de la Municipalidad) y las operaciones de acceso a estas funciones tanto en forma de interfaces de usuario como de interfaces con otros sistemas.

Grosso modo, el interfaz del sistema es gestionado por los controladores y vistas,

y la funcionalidad es proporcionada por los modelos.

2.1.-MODELOS

Los modelos en la arquitectura MVC soportada por Ruby on Rails corresponden a entidades del ámbito de la solución: son clases de objetos que representan, en el caso del SIGPRD, conceptos como proyectos, planes, indicadores, etc. Estos modelos son además el interfaz con la base de datos. La mayoría de los modelos se corresponde directamente con tablas del esquema de datos. La lógica específica del Modelo de Gestión aplicado por el SIGPRD está en su mayor parte encapsulada en estos modelos.

Los modelos apoyan su funcionalidad en un núcleo de soporte compuesto de

módulos que proporcionan las funciones genéricas de soporte de la GPRD. Estos módulos contienen funciones generales para soportar modelos de gestión del tipo del implementado por el SIGPRD, pero no contienen la lógica específica del SIGPRD de la Municipalidad de Cuenca.

2.2.-CONTROLADORES

Los controladores gestionan la interacción con usuarios y sistemas externos. Para ello, se encargan de procesar las peticiones HTTP que llegan a través de Apache y preparan las respuestas HTTP que se transmiten a través de dicho servidor.

Los controladores contienen la lógica de interacción de la aplicación de los

usuarios, así como la lógica de los servicios web suministrados por la aplicación.


30 de Junio de 2013


En su funcionamiento, los controladores utilizan a los modelos para acceder a la funcionalidad del SIGPRD y para obtener las entidades de datos que serán presentadas a los usuarios. La presentación de la información a los usuarios, y la interacción a nivel de cliente (navegadores web), es delegada a las vistas, que encapsulan estos aspectos del sistema.

2.3.-VISTAS

Las vistas proporcionan el interfaz de usuario que se ejecuta en los clientes del sistema: los navegadores web. Las vistas están constituidas por plantillas para la generación del código HTML, CSS y JavaScript que los clientes reciben. Contienen una mínima lógica y se limitan a presentar visualmente la información proporcionada por los controladores y a disponer los controles interactivos para acceder a otras funciones del sistema.

Arquitectura MVC del SIGPRD


30 de Junio de 2013


2.4.-TAREAS DE SOPORTE

Además del interfaz web basado en los controladores y vistas, el sistema dispone de un interfaz basado en comandos y tareas automatizadas para dar soporte a las operaciones de desarrollo y mantenimiento. Mediante el uso de los comandos disponibles para desarrollo y mantenimiento (rake, bundle y rails), se ponen en marcha instancias de la aplicación específicas para responder puntualmente a las tareas solicitadas. Estos procesos se mantienen en funcionamiento únicamente durante la ejecución de estas tareas, no de manera permanente.

Estos comandos se ejecutan mediante un terminal conectado al servidor de la

aplicación. En la práctica puede emplearse el comando ssh para establecer una conexión

remota segura que permita el acceso para control, monitoreo, desarrollo o mantenimiento del SIGPRD. RAKE

El comando rake permite la ejecución de tareas programadas dentro de la aplicación.


30 de Junio de 2013


Por ejemplo, algunas de las tareas previstas para mantenimiento de la aplicación son:

Puesta de la aplicación en modo de mantenimiento, en el que se informa a los

usuarios de esta circunstancia y se impide el acceso a las funciones del SIGPRD y cualquier cambio en la base de datos.

Volcado del contenido de la base de datos.

Reinicio del sistema.

Carga manual de datos y actualizaciones de datos del sistema.

Generación de reportes internos de mantenimiento.

Limpieza de logs y archivos temporales.

Control del proceso “worker”.

También se prevé la programación de tareas útiles para las labores de desarrollo, como las siguientes:

Actualización del esquema de la base de datos.

Actualización de componentes de la aplicación.

Actualización de “assets” (código CSS, JavasScript, imágenes).

Generación de reportes para desarrollo. RAILS

El comando Rails tiene utilidad durante el desarrollo del sistema, para la generación automática de código de “andamiaje” y facilitar algunas operaciones de trabajo con Ruby on Rails. BUNDLE

Este comando gestiona los componentes de la aplicación. Estos componentes están modularizados en forma de paquetes denominados “gem”. Bundle gestiona las interdependencias entre módulos y asegura que se prepoduce el mismo esquema de versiones de los componentes en todas las instalaciones de la aplicación.


+

FASE 2

DOCUMENTO 22: DISEÑO DE INTERFACES DE USUARIO, ENTRE MÓDULOS DEL SIGPRD, Y CON OTROS SISTEMAS EXTERNOS


30 de Junio de 2013


30 de Junio de 2013

FASE 2 DOCUMENTO 22: Diseño de interfaces de usuario, entre módulos del SIGPRD, y con otros sistemas externos

ÍNDICE 1.-INTRODUCCIÓN...................................................................................................... 1 2.-INTERFACES DE USUARIO DE ADMINISTRACIÓN.................................................. 1

2.1.-ROLES ............................................................................................................... 1 2.2.-USUARIOS ........................................................................................................ 3 2.3.-PERSONAS ........................................................................................................ 5 2.4.-ENTIDADES....................................................................................................... 7 2.5-TIPO DE ENTIDAD ............................................................................................. 8 2.6.-TIPO GOBIERNO AUTÓNOMO DESCENTRALIZADO.......................................... 9

3.-INTERFACES DE USUARIO DE PLANIFICACIÓN ................................................... 10

3.1.-PLANES ESTRATÉGICOS ................................................................................. 10 3.2.-PLANES OPERATIVOS..................................................................................... 34

4.-ADQUISICIÓN DE DATOS PRESUPUESTARIOS..................................................... 37

4.1.-INTERFAZ INTERACTIVO................................................................................ 37 4.2.-SERVICIO WEB ............................................................................................... 38


30 de Junio de 2013

FASE 2 DOCUMENTO 22: Diseño de interfaces de usuario, entre módulos del SIGPRD, y con otros sistemas externos 1

DO

CU

MEN

TO

22

DDIISSEEÑÑOO DDEE IINNTTEERRFFAACCEESS DDEE UUSSUUAARRIIOO,, EENNTTRREE MMÓÓDDUULLOOSS DDEELL SSIIGGPPRRDD,, YY CCOONN OOTTRROOSS SSIISSTTEEMMAASS EEXXTTEERRNNOOSS

1.-INTRODUCCIÓN

Este documento contiene el diseño preliminar de Interfaces de Usuario y la relación con otros sistemas del SIGPRD.

2.-INTERFACES DE USUARIO DE ADMINISTRACIÓN Desde este menú podemos dar de alta, modificar y borrar datos de roles, usuarios,

personas, entidades, tipos de entidades, territorios y tipos de Gobierno Autonómico Descentralizado.

Todas las interfaces de eliminación de datos tienen en común la solicitud de

confirmación previa de que desea eliminar los datos pertenecientes a un usuario, persona, etc.

A continuación mostramos las distintas interfaces que hacen posible la realización de

las distintas operaciones citadas anteriormente.

2.1.-ROLES

1.-ALTA DE UN ROL

Para dar de alta un nuevo rol es necesario, asignarle un nombre y hacer clic en los distintos permisos que deba tener un usuario concreto de la aplicación. Una vez terminado de diseñar el rol, clicar en “Crear rol” para que sea creado en la base de datos del sistema.


30 de Junio de 2013


2.-MODIFICACIÓN DE UN ROL

Para modificar un rol se debe seleccionar o deseleccionar los distintos permisos que

queramos añadir o quitar y/o cambiar el nombre si así lo deseamos. Una vez hayamos terminado hacer clic en “Actualizar Rol” para guardar los cambios en el sistema.


30 de Junio de 2013


3.-ELIMINACIÓN DE UN ROL

2.2.-USUARIOS

1.-ALTA DE UN NUEVO USUARIO

En esta pantalla debemos rellenar los siguientes campos para la creación de un

nuevo usuario en el sistema:

Nombre. Será el nombre con el que el usuario se autenticará al entrar en la aplicación.

Email. El usuario también puede autenticarse con el email al entrar en la aplicación.

Contraseña. Deberá tener un mínimo de 6 caracteres alfanuméricos. Confirmación de la contraseña. Deberá contener lo mismo que el campo anterior,

contraseña. Si es o no usuario Administrador. Por defecto no será usuario administrador ya

que aparecerá desmarcada la casilla. Rol. Contiene una lista de roles de la cuál debemos elegir uno.


30 de Junio de 2013


Persona. Contiene un buscador de las distintas personas dadas de alta en la aplicación. En este campo del formulario, hay que poner un nombre o parte de él y el buscador mostrará las distintas personas que contienen el valor pasado.

Una vez rellenados los campos, pulsar en el botón “Crear Usuario” y si los datos

introducidos son correctos, el usuario será creado en la base de datos. 2.-MODIFICACIÓN DE UN USUARIO

Permite modificar los datos de un usuario y actualizarlos en la base de datos del sistema. Bastará con cambiarlos y clicar en “Actualizar Usuario”. Si todo va bien, aparecerá un mensaje indicando que los cambios se han realizado con éxito, de lo contrario indicará dónde están los errores.

3.-ELIMINACIÓN DE DATOS DE UN USUARIO


30 de Junio de 2013


2.3.-PERSONAS 1.-ALTA DE DATOS DE PERSONA

En esta pantalla se selecciona si es una persona física o jurídica, se introducen además los siguientes campos:

Nombre de pila. Apellidos. Sólo se introducirá en el caso de que se trate de una persona física. Número de teléfono. Número de móvil. Número de fax. Email. Dirección. Código Postal. Listado desplegable de Provincias, en el que se elegirá una. Listado desplegable de Cantones, en el que se elegirá uno. Listado desplegable de Territorios, en el que se elegirá uno. Posibilidad de introducir Comentarios.

Además de estos campos se puede añadir uno o más cargos a la persona. Es decir,

se puede indicar el cargo o posición que tiene dicha persona en una entidad.


30 de Junio de 2013


Una vez rellenados todos los campos del formulario, hacer clic en “Crear Persona”, para que la persona sea creada en el sistema. 2.-MODIFICACIÓN DE DATOS DE PERSONA

En esta pantalla se pueden modificar los datos que sean necesarios. Una vez realizadas las modificaciones pertinentes, bastará con clicar en “Actualizar Persona” para que los datos referentes a esta persona sean actualizados en la base de datos del sistema.

3.-ELIMINACIÓN DE DATOS DE PERSONA


30 de Junio de 2013


2.4.-ENTIDADES

1.-ALTA DE UNA NUEVA ENTIDAD

Para crear una nueva Entidad hay que rellenar los campos indicados a continuación:

Tipo de entidad. Seleccionar de una lista desplegable un tipo de entidad. Nombre. Escribir un nombre para la nueva entidad. Siglas. Poner siglas si se desea a la nueva entidad. Código presupuestario. Escribir el código presupuestario asignado a dicha entidad. Territorio. Seleccionar de una lista desplegable el territorio al que pertenece. Seleccionar en el árbol si la nueva entidad pertenece a otra ya creada con

anterioridad. Si la entidad tiene personas pertenecientes, crear tantas como tenga, escribiendo

el cargo que ocupa dicha persona en la entidad y seleccionando la persona de la cual se trata.

Si la entidad tiene personas jurídicas, en “seleccione una o más personas”, escribir el nombre de la persona y seleccionar la o las personas que desee.

Una vez introducidos todos los campos requeridos, pulse en “Crear Entidad” y si

todo es correcto aparecerá un mensaje indicando que la entidad ha sido creada con éxito en el sistema. 2.-MODIFICACIÓN DE DATOS DE UNA ENTIDAD

Cambiar los campos que desee y cuando haya terminado hacer clic en “Actualizar Entidad”, para que sean guardados los cambios en el sistema.


30 de Junio de 2013


2.5-TIPO DE ENTIDAD

1.-ALTA DE UN TIPO DE ENTIDAD

Basta con introducir un nombre, seleccionar de una lista desplegable los tipos de

Gobierno Autonómo Descentralizado y clicar en “Crear Tipo de Entidad” para que sea creado en la base de datos.

2.-MODIFICACIÓN DE UN TIPO DE ENTIDAD

Una vez realizados los cambios deseados, bien en la descripción de la entidad o en la selección de tipo de Gobierno Autónomo Descentralizado, pulsar en “Actualizar Tipo de Entidad” para guardar los cambios en la base de datos del sistema.


30 de Junio de 2013


3.-ELIMINACIÓN DE DATOS DE TIPO DE ENTIDAD

2.6.-TIPO GOBIERNO AUTÓNOMO DESCENTRALIZADO

1.-ALTA DE UN TIPO DE GOBIERNO AUTÓNOMO DESCENTRALIZADO

Para crear un nuevo tipo de Gobierno Autónomo Descentralizado introducir una descripción y hacer clic en “Crear Tipo GAD”.

2.-MODIFICACIÓN DE UN GOBIERNO AUTONÓMO DESCENTRALIZADO

Realizar los cambios pertinentes en la descripción y clicar en “Actualizar Tipo GAD”. Si todo va bien se actualizará en la base de datos del sistema, indicando un mensaje de éxito.


30 de Junio de 2013


3.-INTERFACES DE USUARIO DE PLANIFICACIÓN En este menú tenemos dos tipos de planes: estratégicos y operativos.

3.1.-PLANES ESTRATÉGICOS

1.-DATOS DEL PLAN

En la siguiente pantalla podemos modificar los siguientes datos de un plan estratégico: Nombre. Fecha de aprobación. Fecha límite. Gestor del plan. Territorio. Observaciones.

Una vez realizados los cambios deseados, clicar en “Actualizar Plan”, para que los

cambios sean guardados en el sistema.

2.-DOCUMENTOS

Esta pantalla permite cargar y eliminar documentos, así como visualizar los ya

cargados.


30 de Junio de 2013


Para cargar un documento hacer clic en “Cargar documento”, aparecerá la siguiente pantalla en la que habrá que poner una fecha, un título, seleccionar un territorio y elegir el archivo que queremos cargar. Una vez hecho esto, clic en “Crear Documento” para que el nuevo documento sea almacenado en el sistema.

También es posible eliminar un documento, para ello hacer clic en “Sí”. En caso contrario clic en “Cancelar”.

3.-ÁRBOL ESTRUCTURAL

La siguiente ilustración muestra el Árbol Estructural de un plan, así como todos los

elementos en los que está dividido: eje estratégico, objetivo estratégico, objetivo específico, política, programa y proyecto.


30 de Junio de 2013


A continuación mostramos las distintas operaciones a las que se tiene acceso desde Árbol Estructural. 3.1.-Eje Estratégico

En Eje Estratégico podemos realizar operaciones de definición, modificación y eliminación de un eje estratégico.

Definición de un nuevo Eje Estratégico

Introducir un código y descripción y a continuación clic en “Definir Eje Estratégico” para almacenar los nuevos datos en el sistema.

Modificación de un Eje Estratégico

Introducir los cambios deseados y hacer clic en “Grabar cambios” para guardar los

cambios en el sistema.


30 de Junio de 2013


Eliminación de un Eje Estratégico

Al hacer clic en “Sí”, se borrarán el Eje Estratégico seleccionado de la base de datos. Si por el contrario hacemos clic en “Cancelar”, no se borrará.

3.2.-Objetivo Estratégico Definición de un nuevo Objetivo Estratégico

Para definir un nuevo Objetivo Específico introducir un código y una descripción

válida y hacer clic en “Definir Objetivo Estratégico” para guardar los datos en el sistema.


30 de Junio de 2013


Modificación de un nuevo Objetivo Estratégico

Realizar los cambios necesarios en el código o en la descripción y finalmente hacer

clic en “Grabar cambios” para actualizar los datos en la base de datos. Eliminación de un Objetivo Estratégico

3.3.-Objetivo Específico

En esta sección podemos realizar además de la operaciones habituales de creación,

modificación y eliminación de un objetivo específico, linearlos con objetivos de otros planes.

Definición de un nuevo Objetivo Específico


30 de Junio de 2013


Para definir un nuevo Objetivo Específico introducir un código en el campo código y una descripción en “Descripción”. Una vez terminado hacer clic en “Definir Objetivo Específico” para crear el nuevo objetivo específico en el sistema. Modificación de un Objetivo Específico

Realizar los cambios deseados en código y descripción. En la sección de Articulación en el plan, si desea cambiar los lineamientos internos seleccionar uno o más objetivos estratégicos y el eje estratégico de una lista desplegable. Al finalizar pulsar en “Grabar cambios”. Linear un Objetivo Específico

Para linear un Objetivo Específico con objetivos de otros planes, escribir parte del objetivo con que se desee linear. Aparecerá una lista de objetivos que contienen el texto escrito. Seleccione el que desee. En caso de que se haya equivocado en la selección del nuevo objetivo, haga clic en la “x” que aparece delante del nombre y desaparecerá de su selección. Cuando haya finalizado clic en “Grabar cambios” para almacenar la información en el sistema.


30 de Junio de 2013


Eliminación de un Objetivo Específico

3.4.-Política Definición de una nueva Política

Introducir código y descripción y a continuación pulse “Definir Política” para guardar

la nueva política en la base de datos del sistema. Modificación de una Política


30 de Junio de 2013


Introducir los cambios deseados en código, descripción y en objetivo específico seleccionar el o los objetivos específicos deseados.

Eliminación de una Política

3.5.-Programa Definición de un nuevo Programa

Para definir un nuevo programa en nuestro sistema, introducir un código, una descripción y hacer clic en “Definir Programa”.


30 de Junio de 2013


Modificación de un Programa

Introducir los cambios deseados en código, descripción, seleccionar admite proyectos específicos si deben estar admitidos y seleccionar las distintas políticas con las que el plan está articulado. Finalmente clic en “Grabar cambios” para que los datos sean actualizados en el sistema.

Eliminación de un Programa

3.6.-Proyecto


30 de Junio de 2013


Esta interfaz hace posible la creación, visualización, modificación, eliminación y aprobación de un proyecto. Las distintas operaciones posibles quedan explicadas en el apartado 4. Portfolio Proyectos. 4.-PORTFOLIO PROYECTOS

4.1.-Creación de un nuevo Proyecto

Para crear un nuevo proyecto es necesario rellenar una serie de campos: Código. Escribir un código para el proyecto, por ejemplo “01 “. Denominación. Descripción. Prioridad. Seleccionar entre Alta, Baja y Media. Número de años de duración.


30 de Junio de 2013


Responsable del proyecto. Seleccionar de una lista desplegable el responsable del proyecto.

Finalmente, pulsar en “Crear Proyecto” y el proyecto será almacenado en el sistema.

4.2.-Modificación de un Proyecto

Hacer los cambios deseados y clicar en “Actualizar Proyecto”, para actualizar la base

de datos del sistema.

4.3.-Eliminación de un Proyecto


30 de Junio de 2013


4.4.-Visualización de un Proyecto

Es posible visualizar el contenido de un proyecto, haciendo clic en el lugar que indica

la flecha de la ilustración anterior. Los siguientes apartados contienen el contenido de un proyecto:

4.4.1.-DATOS DEL PROYECTO

Contiene los datos del Proyecto, junto con la opción de modificar (ver ilustración apartado 4.2) o borrar el proyecto (ver ilustración 4.3).


30 de Junio de 2013


4.4.2.-ÁMBITO DE UN PROYECTO Creación de un nuevo Ámbito de un Proyecto

Introducir una descripción, seleccionar un territorio de una lista desplegable y clic en “Crear Ámbito Proyecto” para crear un nuevo ámbito de proyecto en el sistema.

Modificación de un Ámbito de un Proyecto

Modificar los campos deseados y clic en “Actualizar Ámbito de Proyecto”, para grabar los cambios en la base de datos del sistema.

Eliminación de un Ámbito de un Proyecto


30 de Junio de 2013


4.4.3.-DESTINATARIOS DE UN PROYECTO Creación de un Nuevo Destinatario

Introducir una descripción, seleccionar una entidad de una lista desplegable de entidades y seleccionar un territorio de una lista desplegable de territorios. Una vez terminado de introducir los datos, clic en “Crear Destinatario” para guardar el nuevo destinatario en el sistema. Modificación de un Destinatario

Modificar los campos deseados y hacer clic en “Actualizar Destinatario” cuando haya

finalizado para almacenar los cambios en el sistema.


30 de Junio de 2013


Eliminación de un destinatario

4.4.4.-OBJETIVOS

Los objetivos están divididos en generales y específicos. A continuación están las

distintas operaciones posibles de cada uno.

Creación de un Objetivo General

Introducir una descripción y para guardar el nuevo objetivo general en el sistema

hacer clic en “Crear Objetivo Proyecto”.

Modificación de un Objetivo General

Modificar la descripción y clic en “Actualizar Objetivo Proyecto” para actualizar los datos del sistema.


30 de Junio de 2013


Eliminación de un Objetivo General

Creación de un Objetivo Específico

Introducir una descripción y para guardar los nuevos datos en el sistema, clic en “Crear Objetivo Proyecto”.

Modificación de un Objetivo Específico

Modificar la descripción y clic en “Actualizar objetivo proyecto” para actualizar los

datos del sistema.

Eliminación de un Objetivo Específico


30 de Junio de 2013


4.4.5.-LINEAMIENTOS

Desde esta interfaz podemos crear, actualizar y eliminar lineamientos. Para crear y actualizar un lineamiento debemos seleccionar de la lista desplegable el

programa con el que deseemos linear el proyecto. Una vez hecho esto, hacer clic en “Grabar cambios” para almacenar la información en el sistema.

Para eliminar un lineamiento hacer clic en la “X” que aparece al final del texto, y

también en “Grabar cambios”.

4.4.6.-ACTORES Creación de un Actor

Para crear un nuevo actor introducir una descripción del actor y seleccionar de una lista desplegable una entidad. Para que los datos sean guardados en el sistema, clic en “Crear Actor”.


30 de Junio de 2013


Modificación de un Actor

Cambiar los campos necesarios y pulsar en “Actualizar Actor” para que los cambios sean guardados en el sistema. Eliminación de un Actor

4.4.7.-PRESUPUESTO

Está dividido en dos tipos de presupuesto, anual y por conceptos. A continuación

presentamos las distintas interfaces que hacen posible crear, modificar y eliminar una línea del presupuesto.

Creación de una línea de Desglose Anual


30 de Junio de 2013


Rellenar los siguientes campos: Monto. Se rellenará con una cantidad. Año. Seleccionar el año de una lista desplegable.

Clic en “Crear Desglose Presupuesto”.

Modificación de una línea de Desglose Anual

Realizar las modificaciones necesarias y clic en “Actualizar Desglose Presupuesto”

para almacenar los cambios en el sistema.

Eliminación de una línea de Desglose Anual

Creación de una línea de Desglose por Concepto


30 de Junio de 2013


Introducir una cantidad en monto y una descripción del concepto de desglose del presupuesto. Al finalizar clic en “Crear Desglose Presupuesto” para almacenar la nueva línea de presupuesto en el proyecto.

Modificación de una línea de Desglose por Concepto

Realizar los cambios oportunos y clic en “Actualizar Desglose Presupuesto” para

almacenar los cambios en la base de datos del sistema.

Eliminación de una línea de Desglose por Concepto

4.4.8.-FINANCIACIÓN Creación de una Financiación

Introducir una cantidad y seleccionar de una lista de entidades una entidad. Finalmente hacer clic en “Crear Financiación” para almacenar la información en el sistema.


30 de Junio de 2013


Modificación de una Financiación

Modificar el campo cantidad y/o entidad, hacer clic en “Actualizar Financiación” para que la información sea actualizada en el sistema. Eliminación de una Financiación

4.4.9.-MARCO LÓGICO

En marco lógico podemos crear, modificar y eliminar un fin, un propósito, un componente y una actividad.

Para crear cualquiera de ellos hay que rellenar los campos código y nombre y hacer

clic en “Grabar” para que los nuevos datos sean almacenados en el sistema. Para modificar un fin, un propósito, un componente o una actividad cambiar el

código y/o el nombre y hacer clic en “Grabar” para actualizar la información en el sistema. Para eliminar al igual que en el resto de pantallas de la aplicación se pide una

confirmación previa de que desea eliminarlo. A continuación mostramos las distintas pantallas que hacen posible realizar dichas

operaciones.


30 de Junio de 2013


Crear, modificar y eliminar un Fin

Crear, modificar y eliminar un Propósito


30 de Junio de 2013


Crear, modificar y eliminar un Componente


30 de Junio de 2013


Crear, modificar y eliminar una Actividad

4.4.10.-HISTORIAL

Muestra las distintas fases por las que ha pasado un proyecto.

4.4.11.-DOCUMENTOS

Permite cargar documentos a un proyecto (ver apartado 2. Documentos).


30 de Junio de 2013


4.5.-Aprobación de un Proyecto

Para aprobar un proyecto, hacer clic en el lugar que indica la flecha. A continuación solicitará confirmación de aprobación del proyecto.

Para aprobar un proyecto hacer clic en “Si”, y en caso contrario hacer clic en “Cancelar”.

3.2.-PLANES OPERATIVOS 1.-DATOS DEL PLAN

En la siguiente pantalla podemos visualizar los datos del plan operativo.


30 de Junio de 2013


2.-DOCUMENTOS

Esta pantalla permite visualizar los documentos cargados en el plan operativo.

3.-PORTFOLIO PROYECTOS

La interfaz de la imagen anterior muestra un listado de proyectos seleccionados para

este plan operativo. Es posible seleccionar un proyecto de una lista de proyectos disponibles para un

plan operativo, como muestra la siguiente imagen.

Una vez seleccionado un proyecto será posible realizar sobre él las mismas

operaciones que muestra el apartado “4.-Portfolio Proyectos de Planes Estratégicos”. Además se podrán definir, modificar y eliminar hitos como se muestra a continuación.


30 de Junio de 2013


3.1.-HITOS Creación de un Hito

Introducir una descripción en el campo “Descripción”, seleccionar una fecha en

“Fecha” y escribir un número que indique el avance físico. Finalmente clic en “Crear Hito” para almacenar el nuevo hito en el sitema. Modificación de un Hito

Cambiar la descripción, la fecha y/o el avance y clic en “Actualizar Hito” para guardar los cambios en el sistema.


30 de Junio de 2013


Eliminación de un Hito

4.-HISTORIAL DEL PLAN Permite visualizar las distintas etapas por las que ha pasado un plan.

4.-ADQUISICIÓN DE DATOS PRESUPUESTARIOS

Para la captación de datos presupuestarios de los proyectos se dispondrá de dos interfaces: uno manual mediante cargas de datos interactivas manuales y otro automatizado mediante un servicio web.

4.1.-INTERFAZ INTERACTIVO

Este se basa en la transferencia de un archivo en formato XLS. Este archivo debe contener en una celda fija (configurable desde la aplicación) la

fecha a la que corresponden los datos. A partir de una fila determinada (también configurable), el resto de las filas deben

contener los siguientes datos por columnas: (la posición de cada columna es configurable).

Partida Presupuestaria Código de la partida presupuestaria al máximo nivel de desagregación (actividad).

Asignado Inicial Presupuesto asignado inicialmente en dólares.

Codificado Presupuesto codificado (resultado de sumar el presupuesto asignado inicialmente con la reforma si la hubiere), en dólares


30 de Junio de 2013


Comprometido Monto comprometido a la fecha, en dólares.

Devengado Monto devengado a la fecha, en dólares.

Pagado Monto pagado a la fecha, en dólares.

El archivo puede contener otros datos antes de la primera fila de saldos

presupuestarios y otras columnas que se ignorarán.

4.2.-SERVICIO WEB El servicio seguirá los convenios REST. La URL de acceso será, en el dominio de la

aplicación:

/planes/id/estados_presupuestarios/

Donde id representa el identificador del plan para el que se va a cargar información presupuestaria.

La información se transmitirá mediante una request HTTP de tipo PUT en formato XML con la siguiente estructura (esquema XSD):

<xs:schema attributeFormDefault="unqualified" elementFormDefault="qualified" xmlns:xs="http://www.w3.org/2001/XMLSchema">

<xs:element name="estado_presupuestario">

<xs:complexType>

<xs:sequence>

<xs:element name="partidas">

<xs:complexType>

<xs:sequence>

<xs:element name="partida" maxOccurs="unbounded" minOccurs="0">

<xs:complexType>

<xs:sequence>

<xs:element type="xs:float" name="asignado_inicial"/>

<xs:element type="xs:float" name="codificado"/>

<xs:element type="xs:float" name="comprometido"/>

<xs:element type="xs:float" name="devengado"/>


30 de Junio de 2013


<xs:element type="xs:float" name="pagado"/>

</xs:sequence>

<xs:attribute type="xs:string" name="codigo" use="optional"/>

</xs:complexType>

</xs:element>

</xs:sequence>

</xs:complexType>

</xs:element>

</xs:sequence>

<xs:attribute type="xs:date" name="fecha"/>

</xs:complexType>

</xs:element>

</xs:schema>

TYM Q Via Interoceanica, km10. ByPass Cumbayá. Edifício PBX +593 2 6001217 CEL +593 8 9557993 Plaza Modena. Web: www.tym-q.com Piso 3. Oficina 16. Cumbayá. Ecuador Email: [email protected].

TYM asociados internacional España Pamplona c/ Cipriano Olaso nº 6 bajo, 31004 tlf: +34 948228579 – fax: +34 948228598 España. Madrid. Paseo Castellana 135 7º Of.611 tlf: 917906753 [email protected] www.tymasociados.com

EIN S.L España. Tudela (Navarra). Av. Zaragoza 76-78, Bajo. Tel. +34 948 82 52 62 / Fax +34 948 411710 CP 31500 www.einsl.com [email protected]

Documents

DOCUMENTO DISEÑO DE LA BASE DE DATOS