documento 14: recomendaciones y

+

FASE 2

DOCUMENTO 14: RECOMENDACIONES Y ESPECIFICACIONES DE SOFTWARE BAJO ESTANDAR JEEE-830 1998

“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

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 14: Recomendaciones y especificaciones de software bajo estándar JEEE-830 1998, detallado.

ÍNDICE 1.-INTRODUCCIÓN................................................................................................1

1.1.-PROPÓSITO ..................................................................................................1 1.2.-ALCANCE ......................................................................................................2 1.3.-DEFINICIONES, ACRÓNIMOS Y ABREVIATURAS ...............................................2 1.4.-REFERENCIAS ...............................................................................................4 1.5.-VISIÓN GENERAL ..........................................................................................5

2.-DESCRIPCIÓN GENERAL...................................................................................6

2.1.-PERSPECTIVA DEL PRODUCTO .......................................................................6 2.1.1.-RELACIÓN CON OTROS SISTEMAS.........................................................6 2.1.2.-INTERFACES DE USUARIO ....................................................................6 2.1.3.-INTERFACES CON OTROS SISTEMAS .....................................................6

2.2.-FUNCIONES DEL PRODUCTO..........................................................................6 2.3.-CARACTERÍSTICAS DE LOS USUARIOS............................................................7 2.4.-RESTRICCIONES............................................................................................7 2.5.-SUPOSICIONES Y DEPENDENCIAS ..................................................................8

3.-REQUISITOS ESPECÍFICOS ..............................................................................9

3.1.-REQUISITOS FUNCIONALES ...........................................................................9 3.1.1.-ADMINISTRACIÓN DEL SISTEMA...........................................................9 3.1.2.-ARTICULACIÓN DE LA PLANIFICACIÓN................................................13 3.1.3.-PLANIFICACIÓN DE PROYECTOS .........................................................17 3.1.4.-PRESUPUESTOS, EJECUCIÓN, SEGUIMIENTO CONTROL Y MONITOREO .19 3.1.5.-INFORMACIÓN GERENCIAL .................................................................20

3.2.-REQUISITOS DE RENDIMIENTO....................................................................21 3.3.-OTROS REQUISITOS....................................................................................21

3.3.1.-FACILIDAD DE USO ............................................................................21 3.3.2.-SEGURIDAD.......................................................................................21


30 de Junio de 2013

FASE 2 DOCUMENTO 14: Recomendaciones y especificaciones de software bajo estándar JEEE-830 1998, detallado 1

D

OC

UM

ENTO

1

4 RREECCOOMMEENNDDAACCIIOONNEESS YY EESSPPEECCIIFFIICCAACCIIOONNEESS DDEE

SSOOFFTTWWAARREE BBAAJJOO EESSTTÁÁNNDDAARR JJEEEEEE--883300 11999988,, DDEETTAALLLLAADDOO

1.-INTRODUCCIÓN

1.1.-PROPÓSITO

El objeto de esta especificación es establecer y definir claramente desde el punto de vista de los destinatarios finales del sistema los requisitos funcionales y no funcionales del Sistema Integral de Gestión para Resultados de Desarrollo (SIGPRD).

Este documento va dirigido a los coordinadores, responsables técnicos y personal

de apoyo y seguimiento del proyecto GpRD en la municipalidad, con intención de servir para trasladarles y comunicarles los conceptos e ideas que guiarán al equipo técnico de desarrollo contratado para la realización del SIGPRD. Servirá así para unificar criterios y ajustar la orientación de los trabajos.

No debe sin embargo tomarse este documento como una especificación formal,

completa e inflexible de las funciones y características del sistema que se va a desarrollar, lo cual puede inducir a graves vicios que afecten al resultado final e incluso comprometer el éxito del proyecto; algo que con frecuencia se observa como consecuencia de la aplicación rígida y ciega de las metodologías de desarrollo tradicionales.

Es nuestra experiencia que los riesgos son menores y los resultados mucho más

satisfactorios al adoptar las ideas y técnicas de las metodologías ágiles de desarrollo. A la luz de estas metodologías, este documento ha de tomarse como una guía y punto de partida para definir el producto que se va a construir, teniendo siempre en cuenta que tanto los desarrolladores como los destinatarios del SIGPRD no disponen todavía de la visión completa ni del conocimiento de cuáles son las características y formas de funcionamiento más adecuadas para el propósito que se desea alcanzar, sino que emprenden ahora un camino de aprendizaje y descubrimiento, durante el cuál deben saber elegir en cada momento la mejor opción, rectificando cuando sea apropiado, con el fin último de construir una herramienta de utilidad real y capacidad para evolucionar con el tiempo.


30 de Junio de 2013


Por otro lado existen otras razones objetivas que nos obligan a matizar el alcance de estas especificaciones. Por una parte, la funcionalidad y forma de operación del sistema están supeditadas a los resultados de otros componentes de la consultoría en la que está inscrito su desarrollo que todavía no están disponibles. Por otro lado, la naturaleza del tipo de sistema a construir no se aviene como la de otros sistemas que realizan funciones más acotadas y conocida a priori a ser especificada de manera rigurosa o medianamente completa sin el aporte adicional de la experiencia del uso.

En definitiva, será esencial orientar el desarrollo de este proyecto desde una

perspectiva “ágil” basada en la implementación incremental de partes del sistema operativas y el aprovechamiento de la experiencia de uso de las mismas, más que en la letra de las especificaciones realizadas sin el beneficio de dicha experiencia.

1.2.-ALCANCE

Se especifican aquí los requisito de software para el “Sistema Integral de Gestión para Resultados de Desarrollo” (SIGPRD), que es una herramienta informática englobada en la consultoría “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” dentro del proyecto (al que denominaremos “Proyecto GPRD” de ahora en adelante) de la Municipalidad de Cuenca.

Se trata de un sistema para hacer posible la aplicación del Modelo de Gestión

para la Articulación de la Planificación desarrollado en el mencionado proyecto, permitiendo el seguimiento de la planificación estratégica de la Corporación Municipal.

1.3.-DEFINICIONES, ACRÓNIMOS Y ABREVIATURAS

Aplicación Web Sistema informático accesible a través de una red mediante

navegadores de internet.

BI Business Intelligence

Herramientas y estrategias para obtener conocimiento a partir

de los datos de una organización (información gerencial)

BSC Balanced Score Card

Véase CMI

CM Corporación Municipal

Conjunto todas las entidades de la Municipalidad de Cuenca,

incluyendo empresas públicas, etc.

CMI Cuadro de Mando Integral

Método para medir las actividades de una organización en

términos de su visión y estrategia

EML Enfoque de Marco Lógico

Herramienta analítica de la GPRD


30 de Junio de 2013


EP Empresa Pública

GIS Sistema de Información Geográfica (siglas en inglés)

GAD Gobierno Autónomo Descentralizado

Google Chrome Programa informático para acceso a páginas web (Navegador)

GPR Gobierno por resultados (sistema informático implantado en

las instituciones nacionales del Ecuador)

GPRD Gestión para resultados en el desarrollo

IE Microsoft Internet Explorer

Internet Explorer Programa informático para acceso a páginas web (Navegador)

Inyección de código Técnica para obtener acceso no autorizado a una aplicación

web y/o manipular su contenido. (Code injection, SQL

injection, CSS Injection, etc.)

Manipulación de sesión Técnica para obtener acceso no autorizado a una aplicación

web (Session Hijacking, Session Fixation)

ME Monitoreo y Evaluación

Metodologías Ágiles Metodologías y prácticas para el desarrollo de software

basadas en un ciclo iterativo e incremental de trabajo.

ML Marco Lógico; véase EML

Mozilla Firefox Programa informático para acceso a páginas web (Navegador)

Opera Programa informático para acceso a páginas web (Navegador)

PAPP Plan Anual de Política Pública

PDYTO Plan de Desarrollo y Ordenación Territorial (entendido aquí

como PDYOT cantonal de Cuenca)

PNBV Plan Nacional del Buen Vivir

POA Plan Operativo Anual

REST Principios para el diseño de servicios web (Representational

state transfer)

Ruby on Rails Tecnología para el desarrollo de aplicaciones y servicios web

Safari Programa informático para acceso a páginas web (Navegador)

SENPLADES Secretaría Nacional de Planificación y Desarrollo

Servicio Web Método de comunicación entre dos dispositivos o sistemas

que emplea los protocolos básicos de internet/www.

SIG Sistema de Información Geográfica (véase GIS)

SIGRPD Sistema Integral de Gestión para Resultados de Desarrollo

SIPeIP Sistema Integrado de Planificación e Inversión Pública

(Sistema informático desarrollado por SENPLADES)


30 de Junio de 2013


SOAP Protocolo para intercambio de información usado por algunos

servicios web

TÉRMINOS ESPECÍFICOS DEL SIGPRD

Entidad Sistema de Información Geográfica (siglas en inglés)

Georreferencia Elemento con ubicación geográfica (divisiones político-

administrativas, etc.)

Persona datos de una persona física o jurídica

Rol conjunto de permisos y restricciones que se pueden aplicar a

las cuentas de usuarios

Territorio Se especifica mediante un conjunto de georreferencias

Usuario datos de una cuenta de acceso al sistema

1.4.-REFERENCIAS Documento 6. TDR PARA LA CONSULTORÍA DEL SOFTWARE DEL

SIGPRD. 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. Abril 2013.

Documento 16. ANÁLISIS DE BENCHMARKING SOBRE MEJORES

EXPERIENCIAS SIMILARES, INCLUYE ANÁLISIS DEL GPRD DEL GOBIERNO CENTRAL (SENPLADES) Y DE LA ASAMBLEA NACIONAL. 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. Abril 2013.

Guía de uso de la Herramienta Operativa GPR. Mayo 2012. e-Strategia

Consulting Group, S.A. de C.V., México. Guía de uso del Observatorio Ejecutivo GPR. Mayo 2012. e-Strategia

Consulting Group, S.A. de C.V., México. Guía de Indicadores. Mayo 2012. e-Strategia Consulting Group, S.A. de C.V.,

México.


30 de Junio de 2013


Sistema Integrado de Planificación e Inversión Pública - Módulo de Inversión Pública. Mayo 2012. Secretaría Nacional de Planificación y Desarrollo, Ecuador.

Sistema Integrado de Planificación e Inversión Pública - Módulo de

Seguimiento a la Inversión Pública. Junio 2012. Secretaría Nacional de Planificación y Desarrollo, Ecuador.

Instructivo del Sistema Integrado de Planificación e Inversión Pública

– Módulo Planificación. Octubre 2012. Secretaría Nacional de Planificación y Desarrollo; Subsecretaría de Planificación Nacional, Territorial y Políticas Públicas, Ecuador.

Manual del Módulo de Seguimiento a la Programación Anual de la

Política Pública. Diciembre 2012. Secretaría Nacional de Planificación y Desarrollo, Ecuador.

1.5.-VISIÓN GENERAL

Este documento está organizado en tres secciones. La presente sección de introducción expone el propósito y sirve de referencia para la comprensión del documento. La segunda sección, descripción general, encuadra el producto y lo define de manera general. La última sección, de requisitos específicos, define con detalle el funcionamiento esperado del sistema desde el punto de vista de sus usuarios.


30 de Junio de 2013


2.-DESCRIPCIÓN GENERAL

2.1.-PERSPECTIVA DEL PRODUCTO 2.1.1.-RELACIÓN CON OTROS SISTEMAS

El SIGPRD es un producto dirigido a la Corporación Municipal de Cuenca. En los casos en que las condiciones tecnológicas y organizativas lo permitan, el

SIGPRD intercambiará información con otros sistemas informáticos de la Corporación Municipal. 2.1.2.-INTERFACES DE USUARIO

Los usuarios registrados del sistema tendrán acceso a sus funciones a través de una dirección de internet (URL) accesible desde sus lugares de trabajo usando navegadores web estándar actualizados como Google Chrome, Mozilla Firefox, Microsoft Internet Explorer, Safari u Opera. 2.1.3.-INTERFACES CON OTROS SISTEMAS

El intercambio de información con otros sistemas se realizará mediante servicios web de otros productos para los que el SIGPRD actuará como cliente y mediante servicios web proporcionados por el SIGPRD. En casos puntuales pueden buscarse otras formas como el intercambio de archivos planos.

2.2.-FUNCIONES DEL PRODUCTO

El SIGPRD ha de ser una herramienta informática que tenga como utilidad el seguimiento de la planificación estratégica de la Corporación Municipal, haciendo posible la aplicación del Modelo de Gestión para la Articulación de la Planificación definido en el proyecto GPRD de la Municipalidad.

El sistema debe permitir la aplicación del Sistema de Indicadores de Seguimiento, Monitoreo y Evaluación de la Gestión también definido por dicho proyecto. Esto implica que debe ser posible la actualización y consulta de estos indicadores.


30 de Junio de 2013


Como propósito subsidiario, el sistema permitirá la rendición de cuentas dictaminada por la Ley de Transparencia posibilitando la publicación la información derivada de su funcionamiento. Para lograr este propósito el SIGPRD proporcionará una de las dos siguientes capacidades, a determinar durante el diseño del sistema:

Proveer información publicable en otras webs o portales mediante servicios

web. Permitir el acceso de la ciudadanía a través de páginas web para consulta

de la información de rendición de cuentas actualizada.

2.3.-CARACTERÍSTICAS DE LOS USUARIOS

El personal de la Corporación Municipal designado para adoptar los roles fijados por el modelo de gestión para administrar y operar el SIGPRD constituirá la base de usuarios registrados del sistema, que tendrán acceso al mismo a través de una dirección de internet (URL) accesible desde sus lugares de trabajo usando navegadores web estándar actualizados como Google Chrome, Mozilla Firefox, Microsoft Internet Explorer, Safari u Opera.

Los usuarios registrados tendrán asignados roles en el sistema que determinen las funciones a las que tienen acceso, las restricciones de acceso a planes, proyectos, etc. en función de su relación con ellos y las operaciones que pueden realizar con ellos.

Se distinguen dos grupos de usuarios: administradores del sistema, y personal administrativo y técnico que recibirán una capacitación específica distinta dada la naturaleza diferente de su relación con el sistema. Los administradores tendrán como misión el mantenimiento del sistema, configuración y otras labores técnicas que precisarán de conocimientos y experiencia informática en el manejo y administración de sistemas y una formación específica para la administración del SIGPRD. El personal administrativo y técnico, destinatario final del sistema precisará de conocimientos técnicos en su área de responsabilidad y de formación tanto sobre el modelo de gestión aplicado como para el uso del SIPGRD.

2.4.-RESTRICCIONES

El sistema impedirá la realización de operaciones por partes de usuarios registrados que por su rol y relación con los elementos gestionados en el sistema (planes, proyectos, unidades operativas, etc.) no tenga la autorización pertinente.


30 de Junio de 2013


La implementación del sistema sistema incorporará todas las medidas de seguridad necesarias para asegurar la confidencialidad de los datos en él almacenados y la protección frente a intentos de acceso no autorizado o de manipulación o alteración del funcionamiento del sistema previsibles, con atención especial a la protección frente a los tipos de ataques a aplicaciones web mediante técnicas bien conocidas como manipulación de sesiones, inyección de código, etc.

2.5.-SUPOSICIONES Y DEPENDENCIAS

Los desarrolladores del SIGPRD contarán con la colaboración de la Dirección Informática de la Municipalidad para facilitar las tareas de desarrollo e implantación del mismo. En particular para la obtención de información sobre los sistemas informáticos operativos en la Corporación Municipal, para disponer de los equipos y software adecuado para la implantación de entornos de pruebas y producción del SIGPRD y para facilitar el acceso remoto a dichos equipos al personal desarrollador.

La municipalidad proporcionará servidores de capacidad adecuada para el alojamiento y ejecución de los componentes del SIGPRD, con sistemas operativos previamente instalados adecuados a los requisitos del SIGPRD y con la conectividad y medidas de seguridad pertinentes.

Los sistemas informáticos que sea necesario poner en comunicación con el SIGPRD contarán con interfaces en forma de servicios web de tipo REST o SOAP bien definidos y documentados, y susceptibles de ser utilizados desde la plataforma del SIGPRD basada en tecnología Ruby on Rails.

La Municipalidad dispondrá del personal con la formación técnica adecuada capaz para la administración y mantenimiento del sistema. Con este fin, el proyecto de desarrollo incluye y prevé la necesaria capacitación específica para los administradores del sistema.


30 de Junio de 2013


3.-REQUISITOS ESPECÍFICOS

3.1.-REQUISITOS FUNCIONALES

La composición y relación entre los módulos del SIGPRD aconseja establecer un orden de prioridad para la implementación, ya que existe una clara dependencia funcional entre ellos que ha quedado manifiesta durante el análisis de requisitos realizado.

Debido a esto se podrán especificar de manera más detallada los requisitos de los módulos que se implementarán en primer lugar, ya que los requisitos de los demás módulos se verán alterados con toda probabilidad en función de la manera en que se implementen los módulos que les dan suporte y sobre todo en función de la experiencia adquirida durante las pruebas de esos primeros módulos.

El orden lógico para el desarrollo de los módulos es el siguiente:

1. Administración del Sistema. 2. Articulación de la planificación. 3. Planificación de Proyectos. 4. Presupuestos, Ejecución, Seguimiento Control y Monitoreo. 5. Información Gerencial.

El grado de detalle posible de esta especificación irá decreciendo conforme la

información sobre las funciones a definir no esté todavía disponible (por depender de componentes de la consultoría actualmente en desarrollo) o por depender de la revisión de los módulos previos que se deberá hacer en función de la experiencia de uso. 3.1.1.-ADMINISTRACIÓN DEL SISTEMA

RF1.1 Para acceder al sistema, los usuarios registrados deberán dirigirse con un navegador de internet actualizado a la dirección de internet (URL) del SIGPRD. La página de entrada les requerirá que introduzcan sus credenciales de acceso (identificador o dirección de correo electrónico y contraseña). Si estas son incorrectas se les mostrará un mensaje y se impedirá que progresen a ninguna otra página del SIGPRD. En caso de ser correcta se dará acceso a la página de inicio del usuario, que podrá estar configurada de manera particular en función del rol asignado al usuario. Se deben tener en cuenta los estándares de administración y seguridad de los sistemas existentes en la Municipalidad.


30 de Junio de 2013


RF1.2 Las funciones de administración del sistema serán accesibles a través de cuenta de usuario marcadas como de “administrador” o con roles asignados que cuenten con funciones de administración. En este último caso el rol podrá especificar qué grupos de funciones de administración son accesibles.

RF1.3 Los usuarios administradores, o cuyo rol permita la administración de usuarios y roles, podrán administrar los roles o perfiles de usuario configurados en el sistema. Para ello tendrán acceso a una sección o página de configuración de roles. Esta página mostrará una lista de los roles ya definidos. Para cada uno de ellos, mediante enlaces o botones de la página permitirá su visualización, modificación o borrado. Además se dispondrá de un enlace o botón que permita la creación de nuevos roles de usuario.

RF1.4 Si un usuario con los permisos pertinentes accede a la página de modificación de un rol existente o de creación de un nuevo rol, se presentarán grupos de “permisos” y “restricciones” que podrán activarse o desactivarse individualmente mediante controles adecuados (de tipo marcador o similar). Los permisos estarán organizados por grupos temáticos. Cada grupo de permisos tendrá una estructura jerárquica, de manera que permisos más particulares puedan estar vinculados a un permiso más general. Por ejemplo, el permiso de administración contendrá permisos específicos de administración de usuarios, administración de planes, etc. Los permisos específicos pueden a su vez contener permisos más específicos. Cuando se asigne un permiso general, se otorgarán automáticamente todos los permisos específicos asociados. Cada grupo de permisos podrá tener también asociadas “restricciones” que limiten la aplicabilidad de los permisos. Por ejemplo, los permisos relacionados con proyectos podrán estar restringidos a los planes que son gestionados por una unidad operativa asociada con el usuario. De esta manera, un usuario con tal restricción en su rol tendrá acceso a las funciones relacionadas con los proyectos especificadas, pero únicamente para aquellos proyectos que cumplan la condición establecida por la restricción. Desde la página de creación o modificación de un rol podrán grabarse o cancelarse las modificaciones que se hayan realizado.

RF1.5 Los usuarios administradores, o cuyo rol permita la administración de usuarios y roles, podrán administrar las cuentas de usuario para acceso al sistema. Para ello tendrán acceso a una sección o página de configuración de usuarios. Esta página mostrará una lista de los usuarios ya definidos. Para cada uno de ellos, mediante enlaces o botones de la página permitirá su visualización, modificación o borrado. Además se dispondrá de un enlace o botón que permita la creación de nuevas cuentas de usuario.


30 de Junio de 2013


RF1.6 Si un usuario con los permisos pertinentes accede a la página de modificación de un usuario existente o de creación de un nuevo usuario, se presentará una pantalla para introducir o modificar los atributos de la cuenta de usuario, entre ellos el identificador, dirección de correo electrónico, contraseña, tipo de usuario (administrador/normal). Además se podrá asignar al usuario uno de los roles previamente definidos. También se podrá vincular la cuenta de usuario con los datos de una persona registrados como se especificará más adelante. Desde la página de creación o modificación de un usuario podrán grabarse o cancelarse las modificaciones que se hayan realizado.

RF1.7 Los usuarios “administradores” dispondrán de una función para acceder utilizando la cuenta de cualquier usuario con objeto de comprobar el funcionamiento del rol asignado al usuario.

RF1.8 El sistema de administración permitirá el registro de direcciones, números de teléfono, etc. de personas y entidades. Para ello se podrán dar de alta registros de “persona” que podrán corresponder bien a personas físicas o jurídicas y que contendrán los datos básicos identificativos (nombre, apellidos) y de contacto (teléfono, móvil, fax, email, dirección, etc.) La información relativa a la ciudad o población de las direcciones registradas se codificará mediante la asignación de provincia, cantón y parroquia. Se determinará la forma de incorporar esta información a partir de las bases de datos operativas en la municipalidad, como puede ser la “tabla de contribuyentes”.

RF1.9 Los usuarios con permisos para ello tendrán acceso a un interfaz de administración análogo al descrito para la administración de usuarios que permita la administración de los datos de personas físicas y jurídicas.

RF1.10. El sistema de administración permitirá la gestión de georreferencias, entendiendo como tales las entidades con ubicación territorial que sirvan de referencia para la localización de otras entidades o datos, como por ejemplo las provincias, cantones, parroquias, sectores de planificación, etc. Con este objeto los usuarios con permisos para ello podrán cargar y gestionar los datos de georreferencias cargados en el sistema y actualizarlos.

RF1.11. El sistema de administración permitirá la configuración de territorios arbitrarios como agregación de georreferencias del mismo tipo. Estos territorios podrán registrarse con un nombre para ser empleado como ámbitos de otras entidades gestionadas por el sistema.


30 de Junio de 2013


RF1.12 El sistema de administración permitirá el registro de entidades que representen a instituciones, organizaciones, empresas, etc. que puedan representar actores involucrados con las funciones del sistema. En particular se podrán registrar los Gobiernos Autónomos Descentralizados y sus secretarías, direcciones y todo tipo de unidades operativas. Al registrar estas entidades se podrá especificar su tipo y nivel de gobierno en el caso de GADs y podrá asignarse la entidad a aquella de la que dependa jerárquicamente.

RF1.13 El sistema de administración permitirá asignar un territorio previamente configurado a las entidades, para representar el ámbito de actuación de la misma.

RF1.14 El sistema de administración permitirá asignar las personas físicas que pertenecen a una entidad vinculándolas con la descripción del cargo que ocupan en la entidad.

RF1.15 El sistema de administración permitirá vincular uno o más registros de persona jurídica con una entidad para representar los datos (direcciones, etc.) correspondientes a la entidad.

RF1.16 El sistema de administración permitirá, para las entidades que

representen a GADs, el registro de las competencias asignadas de acuerdo a la COOTAD y al nivel de gobierno de la entidad.

RF1.17 El sistema de administración permitirá el mantenimiento de tablas

necesarias para el registro de datos financieros y contables: clasificador presupuestario de ingresos y gastos, etc.

RF1.18 El sistema de administración permitirá el acceso a información sobre el

funcionamiento de la aplicación con objeto de facilitar el diagnóstico de problemas. En particular se registrarán datos sobre los errores que ocurran durante el funcionamiento del sistema.

RF1.19 El sistema de administración permitirá configurar el intercambio de datos

con otros sistemas, como pueden ser los financieros. Para ello, los usuarios con el permiso correspondiente podrán realizar la carga de datos a través de archivos Excel (u otro formato que se determine más adecuado) que se incorporarán a la base de datos.

RF1.20 El sistema de administración debe proporcionar un medio de que los

administradores subsanen problemas en los datos ingresados por los usuarios y que debido a las limitaciones de permisos, limitaciones por el flujo operativo, etc. éstos no puedan realizar. Para ello se implementará un interfaz de correcciones de datos.


30 de Junio de 2013


RF1.21 Para administradores y usuarios cuyo rol permita visualizar el mantenimiento de la aplicación, el sistema de administración mostrará la configuración de la aplicación, las versiones del software empleado para la implementación de la aplicación, el espacio ocupado de la base de datos y de las tablas de la aplicación y los flujos de fases tanto de planes como de proyectos estratégicos y operativos.

RF1.22 El sistema de administración permitirá el registro de uno o más cargos a

una persona en el momento de darla de alta en el sistema o bien modificando los datos de una persona ya existente. Para que la asignación de uno o más cargos sea correcta se deberá introducir el nombre del cargo y la entidad en la que cuál ocupa dicho cargo esta persona.

RF1.23 El sistema de administración dará la posibilidad de asignar cuentas de

usuario a una persona. RF1.24 Para el borrado de entidades el sistema comprobará si la entidad a borrar

tiene entidades dependientes o no. En el caso de que haya entidades dependientes de la entidad que deseemos dar de baja, el sistema no permitirá su borrado. En cambio si la entidad no tiene entidades dependientes de ella pero tiene planes o proyectos vinculados a ella, para eliminarla se deberán asignar todos los planes o proyectos que tuviera vinculados a una nueva entidad y una vez hecho esto se podrá eliminar. Por otro lado es posible que la entidad que se desea eliminar no tenga dependencias pero sea actor en proyectos o tenga cargos asociados a personas. Para eliminarla se deberá escoger entre una de estas dos opciones: la primera es reasignar los cargos de las personas y actores a una nueva entidad y borrarla la entidad seleccionada y la segunda es eliminar la entidad sin reasignar los actores de proyectos y cargos de personas, de esta manera se borrará la entidad y a los proyectos y personas se les eliminará el actor o cargo que tenían con la entidad eliminada.

RF1.25 El sistema de administración permitirá la creación, modificación y

eliminación de competencias, así como de GADs y tipos de entidades. RF1.26 El sistema de administración mostrará mediante un mapa las divisiones

político administrativas de Ecuador, es decir, mostrará sus provincias, dentro de una provincia sus cantones y dentro de un cantón sus parroquias.

3.1.2.-ARTICULACIÓN DE LA PLANIFICACIÓN

RF2.1 Los usuarios con permiso para ello tendrán acceso a una sección de planificación para gestionar y aplicar el modelo de gestión de la articulación de la planificación.


30 de Junio de 2013


RF2.2 Desde la sección de planificación, los usuarios podrán acceder a los planes estratégicos registrados en el sistema (PNBV, PDYOT, etc.).

RF2.3 Al acceder a un plan estratégico determinado, el usuario obtendrá

información sobre: La revisión en vigor del plan. El estado del plan (aprobado, en ejecución, finalizado, etc.). Los contenidos del plan (Objetivos, políticas, programas, etc.) Los lineamientos de elementos del plan con otros planes.

RF2.4 Al acceder a un plan estratégico determinado, el usuario podrá consultar

los proyectos definidos en el ámbito del plan si los hubiere. RF2.5 Al acceder a un plan estratégico determinado, el usuario dispondrá de

acceso a diferentes actividades: aprobación, revocación, definición de contenidos, etc. en función de a) la fase en la que se encuentre el plan y b) los permisos otorgados a través del rol asignado a la cuenta del usuario.

RF2.6 La actividad de definición de un plan estratégico permitirá a los usuarios

que puedan acceder a ella la modificación de elementos del plan (objetivos, políticas, programas, proyectos, …), la creación de nuevos elementos, la alineación de elementos dentro del mismo plan y con otros planes.

RF2.7 Los usuarios con permiso para ello podrán acceder a los planes operativos

existentes o crear nuevos planes operativos. Los planes operativos estarán siempre vinculados a un plan estratégico y tendrán un plazo determinado.

RF2.8 Al acceder a un plan operativo determinado, el usuario obtendrá

información sobre: El plazo y denominación del plan. El estado del plan (en programación, en ejecución, etc.

RF2.9 Los usuarios con los permisos correspondientes podrán abrir revisiones de

los planes estratégicos. Las revisiones de los planes podrán tomar elementos estructurales y de contenidos de la revisión previa y podrán definir nuevos elementos estructurales y de contenido. Para ello se dispondrá de un interfaz de configuración de planes.

RF2.10 La actividad de consulta de un plan estratégico en fase de definición

permitirá al usuario que tenga permisos para ello y al usuario administrador visualizar sus datos referentes a código, nombre, descripción, fechas, etc. También será posible visualizar los documentos adjuntos y las divisiones estructurales que contenga, así como sus proyectos. Se podrá visualizar también un historial del plan que consistirá en las distintas fases por las que ha ido pasando.


30 de Junio de 2013


RF2.11 Cuando un plan estratégico esté en actividad de consulta y fase de definición, habrá una serie de operaciones autorizadas para aquellos usuarios que tengan permisos para ello y usuarios administradores. Estas operaciones serán la revocación de la validación del plan, la aprobación de la definición del mismo y eliminación de la revisión. Estas operaciones serán posibles o no dependiendo de si se cumple una serie de circunstancias.

RF2.12 La actividad de definición de un plan estratégico en fase de definición,

permitirá modificar sus datos referentes a fechas, nombre, gestor y observaciones. También se podrá cargar documentos y visualizar, crear, actualizar y eliminar divisiones estructurales y proyectos.

RF2.13 Las operaciones autorizadas para un plan estratégico en fase y actividad

de definición serán aprobar la definición y revocar la validación. Estarán habilitadas o no en función de una serie de condiciones.

RF2.14 Para aprobar la definición de un plan estratégico en fase de definición,

tendrá que tener todos los proyectos del mismo aprobados y con códigos presupuestarios definidos.

RF2.15 Cuando un plan estratégico tenga aprobada la definición, será posible

revocarlo siempre y cuando no se hayan introducido contenidos al mismo. RF2.16 Cuando un plan estratégico tenga aprobada la definición pasará a fase de

ejecución y será posible abrir una nueva revisión y crear un nuevo plan operativo. RF2.17 Cuando estamos abriendo una nueva revisión de un plan estratégico

habrá que introducir una serie de datos (nombre, descripción, observaciones, fecha inicio, fecha límite) y seleccionar qué se desea replicar (configuración, contenidos, proyectos) del plan del cual estamos abriendo una nueva revisión.

RF2.18 Para la creación de un nuevo plan operativo, se deberá aprobar la

definición de un plan estratégico y asignarle un nombre, una descripción, observaciones si las tiene, seleccionar un año de entre los años que duraba el plan estratégico y seleccionar las divisiones estructurales del plan estratégico que queremos tener en el plan operativo.

RF2.19 Sólo se podrá eliminar un plan estratégico u operativo desde la interfaz

de correcciones un usuario administrador.


30 de Junio de 2013


RF2.20 Los planes operativos en actividad consulta y fase de programación, permitirán visualizar sus datos (código, nombre, descripción, gestor, fechas y observaciones), documentos, proyectos y su historial (fases por las que ha pasado). También permitirán realizar dos operaciones, revocar la validación y aprobar la programación del plan.

RF2.21 Para revocar la validación de un plan operativo en fase de programación

y en actividad consulta no tendrá que tener definidos contenidos. Si tiene contenidos definidos no se podrá revocar. Por ello esta operación aparecerá como activa o inactiva en función de si es o no posible realizarla. Si no es posible realizarla indicará con un mensaje al pasar el ratón por el encima el motivo por el que no se puede llevar a cabo esa acción.

RF2.22 Para aprobar la programación de un plan operativo en fase de

programación y en actividad consulta tendrá que tener todos los proyectos aprobados y con códigos presupuestarios asignados. En caso contrario está operación aparecerá como deshabilitada y mostrará un mensaje al pasar el cursor del ratón por encima de ella, el motivo por el que no se puede realizar dicha acción.

RF2.23 Los planes operativos en actividad y fase de programación podrán

seleccionar de un listado de proyectos disponibles los proyectos que van a formar parte del plan operativo. Una vez que estén seleccionados se podrá introducir y modificar información referente a datos del proyecto (fechas), objetivos, hitos, marco lógico, destinatarios, lineamientos, actores, documentos, etc.

RF2.24 Desde la pantalla de programación de un plan operativo en fase de

programación será posible aprobar la programación del plan operativo (sólo si tiene todos los proyectos aprobados), ingresar códigos presupuestarios y abrir proyectos específicos para ese plan.

RF2.25 La aprobación de la programación de un plan operativo, conlleva que el

plan operativo pase a fase de ejecución. RF2.26 La aprobación de la definición de un plan estratégico, conlleva que el

plan estratégico pase a fase de ejecución.


30 de Junio de 2013


3.1.3.-PLANIFICACIÓN DE PROYECTOS

RF3.1 Al acceder a un proyecto de un plan estratégico, el usuario podrá consultar los datos generales del proyecto (denominación, plazos, prioridad, entidad gestora, entidades que actúan como actores, destinatarios/beneficiarios, objetivos generales y específicos, lineamientos, información de marco lógico).

RF3.2 Al acceder a un proyecto de un plan estratégico, si el usuario cuenta con permiso de acceso a datos financieros/presupuestarios podrá consultar la correspondiente información.

RF3.3. Al acceder a un proyecto, si el usuario tiene los permisos adecuados y el plan se encuentra en una fase que lo permita el usuario podrá activar las funciones de edición para modificar los datos descritos anteriormente, o podrá eliminar el proyecto.

RF3.5. Las funciones de edición de la matriz de marco lógico permitirán definir la

jerarquía de fines/propósitos/componentes y actividades junto con la información vinculada de indicadores, metas y supuestos.

RF3.6. Los usuarios con los permisos apropiados podrán vincular documentos y

archivos con los proyectos y otras entidades gestionadas por el sistema. RF3.7. Los proyectos de planes estratégicos tendrán un ciclo de vida compuesto

por fases; los usuarios con los permisos correspondientes dispondrán de funciones de aprobación para realizar la transición de una a otra fase.

RF3.8 Cuando el plan operativo esté en fase de programación y los permisos del

usuario lo permitan, el usuario podrá acceder a las funciones de programación que permiten seleccionar qué proyectos se ejecutarán en el plan.

RF3.9 Desde la pantalla de programación de un Plan Operativo, el usuario podrá

seleccionar aquellos proyectos pendientes de ejecución (o que siendo proyectos plurianuales no estén todavía asignados a ejecución en el plazo del plan operativo en cuestión). Los proyectos disponibles dependerá de la entidad a la que pertenece el usuario y de la entidad que gestiona el plan, de manera que por lo general el personal de, por ejemplo una EP, podrá acceder o gestionar sólo a los proyectos asignado a esa EP).

RF3.10 Al seleccionar un proyecto para su ejecución en un plan operativo, será posible redefinir y modificar algunos de sus elementos y propiedades, como los hitos, presupuesto, financiación, marco lógico, etc.).


30 de Junio de 2013


RF3.11 Desde un plan estratégico en actividad consulta es posible visualizar los contenidos de un proyecto que forma parte del plan. Los contenidos visualizables serán datos (código, denominación, descripción, plazos, responsable, fase, etc.), ámbito, destinatarios, objetivos, lineamientos, actores, marco lógico, historial y documentos. Se podrá visualizar también para los usuarios que tengan permiso para ello, presupuestos y financiamiento.

RF3.12 Desde un plan estratégico en actividad definición será posible modificar

los datos de un proyecto. Datos referentes a descripción, plazos, prioridad, responsable y años de duración. También se podrán modificar, visualizar, crear y eliminar ámbito de un proyecto, destinatarios, objetivos, lineamientos, actores, marco lógico, documentos y para los usuarios con permiso para ello presupuestos y financiamiento.

RF3.13 Desde un plan estratégico en actividad definición será posible aprobar la

definición del proyecto. RF3.14 Desde un plan operativo en actividad de consulta al igual que en los

planes estratégicos, será posible visualizar los contenidos (datos, destinatarios, marco lógico, actores, etc.) de un proyecto.

RF3.15 Desde un plan operativo en actividad programación, se podrá visualizar el

contenido de los proyectos que estén disponibles para ser seleccionados y pasar a ejecución en el plan operativo. Si los proyectos están seleccionados se podrán realizar operaciones de modificación de datos (plazos, fechas) del proyecto y crear, modificar, visualizar y eliminar contenidos (datos, destinatarios, marco lógico, actores, etc.) del proyecto.

RF3.16 Desde la programación de un proyecto será posible aprobar el proyecto,

siempre y cuando tenga todas las actividades del marco lógico con códigos presupuestarios asignados.

RF3.17 El contenido del proyecto estará dividido en fichas (objetivos,

destinatarios, actores, marco lógico, documentos, etc.). En cada ficha se dará la posibilidad de crear, modificar, visualizar o eliminar un actor, o un destinatario, o un objetivo, o etc., dependiendo de en qué ficha nos encontremos. La información ya definida en la ficha aparecerá en forma de lista y para cada uno de los contenidos definidos se podrá visualizar más información del mismo, editar y eliminarlo. Estas operaciones estarán disponibles en las fichas siempre y cuando se tengan permisos para ello y el proyecto esté en una actividad y una fase que así lo permita.


30 de Junio de 2013


RF3.18 El contenido de la ficha marco lógico tendrá además un árbol que mostrará jerárquicamente fines, propósitos, componentes y actividades.

3.1.4.-PRESUPUESTOS, EJECUCIÓN, SEGUIMIENTO CONTROL Y MONITOREO

RF4.1 Los usuarios con permisos para ello y acceso a los proyectos de planes operativos en ejecución podrán acceder a diversas pantallas para la actualización de la información presupuestaria, de avance del proyecto, de seguimiento, etc.

RF4.2 Desde la pantalla de presupuesto/financiera de un proyecto será posible revisar los datos presupuestarios acumulados (a la fecha más reciente disponible) y su evolución por meses.

RF4.3 Desde la pantalla de avance permitirá actualizar la información de avance del proyecto vinculada al cumplimiento de los hitos definidos para el mismo.

RF4.4 Desde la pantalla de seguimiento se podrá actualizar la información de indicadores, metas y supuestos relacionados con la matriz de marco lógico del proyecto.

RF4.5 Desde la pantalla de control y monitoreo será posible consultar la información integrada derivada del estado de avance del plan, cumplimiento presupuestario, estado de metas, etc.

RF4.6 Se dispondrá de un interfaz para la carga de datos presupuestarios en

archivos Excel o similares. RF4.7 Desde la pantalla de avance será posible acceder a los distintos proyectos

en ejecución de un plan operativo aprobado. Una vez estemos visualizando un proyecto, será posible modificar sus fechas de inicio y fin efectivo.

RF4.8 Las operaciones autorizadas desde un proyecto en ejecución en avance

serán cierre (sólo posible si se ha registrado la fecha de finalización del mismo), congelación y cancelación. Estas operaciones solamente las podrán realizar los usuarios autorizados para ello y los administradores.

RF4.9 Las fichas de proyectos que se podrán visualizar cuando tengamos un

proyecto seleccionado en seguimiento serán datos, ámbito, destinatarios, objetivos, lineamientos, marco lógico, actores, hitos, historial, documentos y comentarios.


30 de Junio de 2013


RF4.10 Las fichas de proyectos que se podrán visualizar cuando tengamos un proyecto seleccionado en financiero serán datos, presupuestos, financiamiento y marco lógico. No se podrá modificar ningún dato, solamente visualizar. 3.1.5.-INFORMACIÓN GERENCIAL

RF5.1 Los usuarios con permisos apropiados tendrán acceso al cuadro de mando integral y a otras funciones de Control, Monitoreo y Evaluación a nivel estratégico.

RF5.2 El cuadro de mando integral mostrará de manera visual la síntesis de alto nivel de cumplimiento de metas organizadas por las perspectivas gerenciales del mapa estratégico (ciudadanía / procesos / talento humano / finanzas).

RF5.3 Las funciones de Control, Monitoreo y Evaluación estratégicas darán acceso a reportes que sinteticen la información derivada del cumplimiento de metas, cumplimiento presupuestario y avance de los proyectos a múltiples niveles, incluyendo los niveles de programas, proyectos plurianuales, POA, etc.

RF5.4 El cuadro de mando permitirá a aquellos usuarios con permisos para la evaluación de todas las unidades operativas seleccionar la unidad operativa que se va a evaluar o dejarla en blanco (para evaluarlas todas conjuntamente). Los usuarios restringidos al acceso a una unidad unidad operativa tendrán automáticamente asignada ésta para la evaluación.

RF5.5 EL cuadro de mando permitirá establecer el ámbito de evaluación que se

va a analizar. El ámbito podrá ser un plan operativo o estratégico o bien un componente de un plan (objetivo, programa, proyecto,…).

RF5.6 EL cuadro de mando permitirá establecer filtros de consulta para la

información a analizar. Los filtros incluirán la selección de un periodo de consulta y el aspecto a medir (tipología de indicadores considerados).

RF5.7 El Cuadro de mando presentará vistas de síntesis del ámbito y

condicionantes seleccionados basadas en metas e indicadores. Permitiendo seleccionar indicadores individuales para obtener más información.

RF5.8 EL Cuadro de mando dará acceso a paneles comparativos en los que la

información basada en metas e indicadores se desglosará por perspectivas, aspectos, unidades operativas, etc.


30 de Junio de 2013


RF5.9 El cuadro de mando dará acceso a reportes preconfigurados de situación, avance, evolución, riesgos.

RF5.10 El cuadro de mando dará acceso a informes personalizados basados en

metas e indicadores.

3.2.-REQUISITOS DE RENDIMIENTO

El tiempo de respuesta será suficiente para garantizar una experiencia interactiva satisfactoria por parte de los usuarios. En particular, salvo operaciones que razonablemente requerirán un tiempo extendido, como la generación de reportes, carga y descarga de datos y documentos, etc., el acceso a las pantallas y la operación de los controles del sistema deberían ser lo más inmediatos posibles.

3.3.-OTROS REQUISITOS 3.3.1.-FACILIDAD DE USO

El uso del sistema tiene que ser siempre lo más intuitivo posible y no inducir a la confusión de los usuarios. Para ello se organizará las pantallas y controles de una manera lógica y clara y se complementarán las pantallas con información para el usuario que explique las cuestiones que pudieran resultar más complicadas.

Se prestará especial atención a cuestiones de navegabilidad y a clarificar al usuario su ubicación lógica en el sistema, las actividades que puede realizar en cada momento, tareas asignadas pendientes, etc. 3.3.2.-SEGURIDAD

Los usuarios no podrán acceder en ningún caso a operaciones o datos para los cuales no se les haya otorgado permiso de acceso.

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]

documento 14: recomendaciones y

Documents