UNIVERSIDAD DE COSTA RICA

VICERRECTORÍA DE ACCIÓN SOCIAL

Extensión Docente
Observatorio del Desarrollo

SAEP PitA - SIRZEE

Especificación de requerimientos de software

Elaborado por:

Álvaro Fernández
Javier Vásquez
Carlos Andrés Méndez Rodríguez

Última Actualización 01-02-2012

Versión 01-02-2012

Ciudad Universitaria Rodrigo Facio, 01 febrero del 2012

HISTORIA DE VERSIONES

Fecha Autor Cambios Descripción

Finales 2009 Javier Vásquez Modelos para el Se describe el modelo MAEP

análisis espacial que fue la base del proyecto
de problemas- SAEP PitA SIRZEE. Ver
ODD-MEP-FO_D- sección Documentos
 SIRZEE relacionados ID 1.

2010 Javier Vásquez Requerimientos Es un documento con

Álvaro Fernández del SAEP-PitA en definición de conceptos y
Carlos A. Méndez una versión especificación de
siguiente. requerimientos.

Finales 2010 Javier Vásquez “Minimorum” Requerimientos Mínimos y

Álvaro Fernández Deseables.
Carlos A. Méndez

01-02-2012 Javier Vásquez Este documento La especificación de

Álvaro Fernández (Más actualizado) requerimientos se fue
Carlos A. Méndez desarrollando con base en los
3 documentos anteriores.

CONTENIDOS

PREFACIO
Propósito
Audiencia
Participantes en el desarrollo del diseño conceptual
Documentos relacionados
Siglas y abreviaturas
I INTRODUCCIÓN
Propósito del sistema
Alcance del sistema
 Objetivos y criterios de éxito
Panorama
II REQUERIMIENTOS FUNCIONALES
III REQUERIMIENTOS MÍNIMOS Y DESEABLES PARA EL SAEP SIRZEE
IV REQUERIMIENTOS NO FUNCIONALES
Documentación
Consideraciones de hardware
Características de desempeño
Manejo de errores y condiciones extremas
Cuestiones de calidad
Modificaciones al sistema
Seguridad
Usabilidad e Interfaz de usuario
Seudorequerimientos
Modelos del sistema
Escenarios
Modelo de caso de uso
Modelo de objetos
Interfaz de usuario

COLABORADORES

Participantes en el Desarrollo Conceptual y Especificación de Requerimientos

Muchas personas han formado parte del desarrollo conceptual, educativo y especificación de
requerimientos del SAEP-PitA SIRZEE. A continuación se detallan los participantes y la
organización a las que tales participantes formaban parte en aquel momento.

Académicos participantes

Álvaro Fernández González, Observatorio del Desarrollo (OdD), UCR

Marlen Treviño, SIRZEE, ITCR

Colaboradores institucionales
UCR
Javier Vásquez, Escuela de Computación e Informática (ECCI)
Carlos Andrés Méndez Rodríguez, Escuela de Computación e Informática (ECCI)
Emma Tuk, consultora en gestión de residuos y educación.

ITCR
Andrés Guzmán, SIRZEE
Rocío Quirós: práctica de especialidad, Escuela de Computación, Sede Santa Clara.
Oscar Lopez, SIRZEE

MEP
Andrés Rodríguez, asesor nacional, Programa Nacional de Informática Educativa
Karla Quesada, asesora regional, Programa Nacional de Informática Educativa, Dirección
Regional de Educación de San Carlos.
Walter Mora, Jefe de Asesoría Pedagógica de la Regional de Educación de San Carlos.
Natalia Rojas, profesora de Informática Educativa, Colegio Teodoro Picado, Alajuelita.

PREFACIO

Propósito

Este documento tiene el propósito de especificar los requerimientos funcionales y no

funcionales del sistema informático y sirve como una base contractual entre el cliente y los
desarrolladores de software.

Las pruebas de software (ver documentos Plan de Pruebas de Software y Especificación y

Resultados de los Casos de Prueba) verifican el cumplimiento de estos requerimientos de
software.

Audiencia

Como mencionamos en el propósito, este documento sirve como una base contractual entre el
cliente y los desarrolladores de software.
Documentos relacionados

ID Ref Documento Descripción

1
http://code.google.com Modelos para el Es un documento que
/p/saep- análisis espacial de describe un modelo
pita/downloads/detail? problemas-ODD-MEP- para el análisis espacial
name=Modelos%20par FO_D-SIRZEE de problemas. Utilizado
a%20el%20an%C3%A1li para requerimientos
sis%20espacial%20de% del sistema (SAEP SIR-
20problemas-ODD- ZEE en San Carlos)
MEP-FO_D-
SIRZEE.doc&can=2&q=

2
San Carlos 2010 v2 Requerimientos del
http://code.google.com SAEP-PitA en una
/p/saep- versión siguiente.
pita/downloads/detail?
name=San%20Carlos%2
02010v2.docx&can=2&
q=

3 Pruebas de Sistema del Documenta pruebas de

SAEP-PitA sistema y pilotaje del
SAEP-PitA

Siglas y abreviaturas

CRUD Crear, leer, actualizar y eliminar (Create, Read, Update and Delete).

ECCI Escuela de Ciencias de la Computación e Informática

OdD Observatorio del Desarrollo de la Universidad de Costa Rica, es una unidad

de apoyo a la investigación de la Universidad de Costa Rica, orientada a
consolidar los procesos de reflexión y toma de decisiones brindando acceso
oportuno a información en temas relevantes para el desarrollo nacional.
MOE-GAUR Proyecto “MEJORA DE LA OFERTA EDUCATIVA EN GESTIÓN
AMBIENTAL URBANA Y RURAL: Experiencia piloto interuniversitaria en
Pérez Zeledón” (MOE-GAUR).

El MEP creó en el 2008 un nuevo Departamento de Educación en Salud y

Ambiente, y decretó en 2009 que las Direcciones Regionales de Educación
deben promover la contextualización y pertinencia de la política educativa,
“conciliando el currículum nacional con las particularidades regionales y
locales, con el propósito de convertir cada centro educativo en un espacio
de convivencia y de encuentro con la comunidad, respetuoso de la
diversidad cultural y del medio ambiente, capaz de enfrentar la
discriminación en todas sus manifestaciones” (Decreto Ejecutivo 35513 del
25 de setiembre de 2009).

En este contexto, el proyecto MOE-GAUR, procura crear las condiciones

para que centros educativos públicos y/o privados de la Dirección Regional
de Educación de Pérez Zeledón, incorporen un componente que estimule el
desarrollo de destrezas y habilidades para la participación ciudadana en la
gestión ambiental a escala local (cantonal o distrital). El proyecto se ha
extendido a la Dirección Regional de Educación Grande de Térraba (la cual
abarca los cantones de Buenos Aires de Puntarenas y Osa), por solicitud
expresa de esta dirección regional.

SAEP-PitA Sistema para el Análisis de Problemas - Participate in the Action, consiste

en el desarrollo de un sistema web de información geográfica con un
conjunto de herramientas de proposito general que permitan simular,
experimentar, medir, administrar y analizar problemas contextualmente
situados geográficamente.

Su primera versión se implementó en el segundo semestre del 2010 y

primer semestre del 2011. El nombre SAEP proviene del Modelo para el
Análisis Espacial de Problemas (MAEP) el cual se adjunta en apartado
1.3.3.

SIRZEE Sistema de Información Regional para la Zona Económicamente Especial.

Es un sistema para el fortalecimiento y desarrollo de la pequeña y mediana
empresa y los gobiernos locales de la Región Huetar Norte, Costa Rica.
I INTRODUCCIÓN

El sistema propuesto es una herramienta de propósito general que permite: simular,

experimentar, medir, administrar y analizar problemas contextualmente situados
geográficamente.

El sistema está concebido para ser usado en procesos de toma de decisiones respecto a datos
geolocalizables y en la educación ambiental de estudiantes de octavo año del sistema
educativo costarricense. Sin embargo su concepción de implementación incremental, y su
facilidad de integración le permite crecer en sofisticación y complejidad, permitiendo su uso en
contextos más amplios.

Se buscará tratar el problema del manejo de residuos sólidos, su contexto social, su

administración, etc. que le permitirá al estudiante de secundaria la generación de propuestas,
experimentación y análisis sobre ese tema.

El diseño del Saep se asienta en la Internet y por lo tanto posee las facilidades de
comunicación que brinda esta red. Podrá funcionar tanto auto-contenido localmente en un
computador, como en diálogo dinámico entre usuarios o comunidades de usuarios.

Por ese motivo se propone una primera implementación prototipo en un servidor central,
específicamente en el SIR/ZEE, que garantice la privacidad y seguridad de conexión entre
usuarios.

Lo anterior establece una primera etapa en que se atenderá la región Norte y aquellas
instituciones de esa región que tengan conexión vía Internet.
 Antecedentes

Para la concepción del SAEP han confluido dos intereses, en primera instancia se ha buscado
una manera de fortalecer la percepción de que la informática es una herramienta a disposición
de otras disciplinas, cuya incorporación en las actividades cotidianas depende de las afinidades
y destrezas de los usuarios, así como también se ha procurado fomentar el uso de
herramientas de carácter libre que soporten la toma de decisiones, sea en la gestión pública o
en la docencia.

Esta estrategia parte del supuesto de que si se brinda una capacitación en la acción, el usuario
de la herramienta no solo tendrá una mejor formación, sino que tendrá una mejor actitud hacia
el análisis poliaxial de problemas espaciales y hacia la solución colaborativa de los mismos.

El SAEP se ha diseñado para ser una herramienta útil en el análisis y evaluación de soluciones
de problemas urbanos, que requieren un ambiente donde se puedan simular posibles
escenarios.

Podemos decir que el SAEP viene a complementar otros esfuerzos hechos por universidades,
gobiernos locales y entes privados para el análisis de problemas urbanos, usando para ello
herramientas de análisis y de simulación. Ejemplos de antecedentes se enumeran a
continuación.

● La Universidad de California ha venido trabajando en equipo para simulación

urbana (http://www.ust.ucla.edu/ustweb/ust.html), este es un proyecto a largo plazo
cuyo objetivo principal es la emulación virtual de la ciudad de Los Ángeles, proveyendo
al usuario con imágenes tridimensionales de la misma. El equipo indica que tal
ciudad virtualizada ofrece una innumerable cantidad de usos, entre otros mejorar la
navegabilidad mediante sistemas GPS, así como ayudar en la planificación
arquitectónica y urbana.

● La Universidad Tecnológica de Viena ha seguido las ideas propuestas por

Markelin en 1979 respecto a simular un medio ambiente mediante redes de
sensores (http://publik.tuwien.ac.at/files/pub-ar_2584.pdf) y proveer un mecanismo
endoscópico para evaluar desde lo interno de la ciudad aspectos urbanos y
arquitectónicos. EL ambiente virtual automático que ellos proponen y denominan CAVE
ofrece al igual que PitA (otro idea de la academia, que luego se contemplará), el uso
de reproductores de imágenes sobre una superficie de análisis.

● Diversos investigadores han usado herramientas informáticas para evaluar el

comportamiento simulado de flujos de personas en áreas particulares de una
ciudad, e.g. trabajo de Espina y Rincón en Maracaibo
(http://cumincades.scix.net/data/works/att/sigradi2007_af107.content.pdf)
 ● El MIT también propuso en 1999 el proyecto Urp: A Luminous-Tangible
Workbench for Urban Planning and Design
(http://web.mit.edu/ebj/www/JPER.pdf) que permite evaluar el efecto que
tendrían nuevas infraestructuras en la luminosidad, velocidad y dirección del viento
en una ciudad dinámica.

● La Universidad de Colorado también ha colaborado al proponer el uso de

agentes colaborativos, mediante actores monitoreables, ubicados sobre la
imagen de un mapa que se proyecta sobre una mesa, y que puede combinarrse
con imágenes provenientes de Google Earth, dando así lugar a la teconología
“Participate in the Action” PitA, que se ha usado para planear un sistema de
transporte para el metro de Denver. (http://l3d.cs.colorado.edu/systems/EDC/Pita-
Board/)

● La empresa Maxis ofrece desde fines de los ochentas e inicios de los 90 un juego
denominado “Sim City” que ha tenido mucho éxito entre sus jugadores, pero que
también ha recibido diversas críticas de los planificadores urbanos por delegar
en una sola persona la decisión de las acciones a tomar, sean de un tipo u otro,
e.g. expansión comercial, destrucción de tierras y designación de la vocación del
terreno.

● Otros juegos de simulación ayudan a analizar la problemática de la sostenibilidad en

ciudades verdes, e.g. CityRain

Como puede verse las simulaciones han sido objeto de estudio y de incorporación en juegos
desde los años setentas, pero no es sino a partir de los años noventas en que su uso se
potencia en mayor medida.

De lo documentado anteriormente se tiene que el uso de estos sistemas de planificación

urbana se da en el campo de la prospección, que acorde con el diccionario de la Real
Academia del lenguaje consiste en una “exploración de posibilidades futuras basada en indicios
presentes”. Evaluación de sistemas de transporte, planeación de ayuda a conductores guiados
por GPS, planeación de la arquitectura urbanística y planificación del uso del suelo son algunos
de los campos en la que la misma se usa. En cualquiera de ellos se torna vital contar con datos
que evidencien eventos en el tiempo, porque de lo contrario sería imposible detectar tendencias
y sin ellas difícilmente se podrían explorar las posibilidades futuras. Lo anterior obliga que se de
el registro de hechos junto con el tiempo en que ocurrió o se detectó un evento externo, i.e. si
alguien está interesado en estimar la recaudación futura de impuestos, debe contar con
información histórica sobre la recaudación en cada período

De lo dicho anteriormente se puede concluir que el sistema propuesto se inspira en el contexto

de funcionamiento del sistema PitA, originalmente presentado como sistema de
experimentación donde se podrían asentar experiencias educativas.
La experiencia desarrollada por un grupo anterior de profesionales en informática de la Escuela
de Computación de la UCR, mostró las limitaciones y lo poco práctico del uso de PitA-Boards.
El costo de la plataforma tecnológica, cercano a los 15,000 USD por mesa de trabajo, así como
la dificultad de desplazar este equipo inhibirá a muchas instituciones en usarlo.

Fundamentalmente la conceptuación del sistema PitA está asentada en programación en

Smalltak, un lenguaje pionero en la programación orientado a objetos con más de 20 años de
antigüedad y con poca impronta en el mercado, sea quizás por el hecho de ser interpretado,
sea por la onerosa curva de aprendizaje, o por su poca flexibilidad para reutilizar código.

Estas carencias inhiben la fácil integración de subsistemas, lo mismo que diseños

incrementales y el diálogo con facilidades avanzadas del sistema operativo. Esto produce un
incremento sustancial en el trabajo de modificación funcional de programas.

El sistema PitA no es un sistema integral, sino que toda nueva aplicación debe programarse
completamente, i.e. no se simplificaría la reutilización de solución o modelos ya desarrollados.

Por otro lado, Pita propone la integración con una mesa electrónica donde se sitúan
geográficamente objetos, que representan estructuras u objetos físicos de interacción entre
partes. Estos son componentes electrónicos que deben de implementarse e integrar su
identificación espacialmente en la mesa.

Dicha implementación electrónica es cara, difícil de mantener y su fabricación artesanal

produce la generación de errores o incompatibilidad con los medios de localización.

PitA pretende establecer un medio físico donde se puedan localizar geográficamente objetos, y
definir relaciones entre esos objetos con el medio ambiente, y en conjunto con un proyector
digital establecer una representación geográfica de referencia.

PitA es un sistema poco práctico en el contexto educativo: habría que implementar una mesa y
usar un proyector para dar una localización espacial, además de un sistema computacional de
alto rendimiento por cada centro educativo, o bien procurar comunicar vía Internet con un
sistema que no ofrece esas posibilidades, es decir reprogramarlo para tales efectos.

La propuesta del Saep es la de actualizar conceptualmente la idea general de funcionamiento

de PitA, virtualizando sus funciones. En ese sentido se propone su implementación en
lenguajes y sistemas libres estandarizados de amplio uso en el sistema educativo y académico
internacional y su desarrollo e implementación acorde a las realidades nacionales. Lo anterior
sin menoscabo funcional del sistema, ni de la calidad académica ofreciendo al mismo tiempo
disponibilidad tanto para el educador como para el estudiante.

La conceptuación del Saep se enmarca en las corrientes educativas generales de la

experimentación virtual, con un fuerte componente que liga el estudiante a la realidad,
imponiendo marcos de análisis, medición y experimentación, lo anterior pudiendo guiarse,
evaluarse y monitorearse por un educador.

Alcance del sistema

El sistema está dirigido únicamente para la Zona Económica Especial (SIR-ZEE).

Finalidad del SAEP-PitA SIRZEE

Incorporar el uso de herramientas tecnológicas convencionales para permitir abordar la

solución de problemas comunales referentes a planificación espacial, desde una perspectiva
lúdica y poliaxial, de manera que grupos de personas puedan aportar al análisis / solución del
problema en cuestión empleando enfoques propios de diversas disciplinas.

Misión
Coadyuvar en el análisis de problemas comunales y permitir que usuarios generen propuestas
de solución.

Propósito del Saep

Fomentar el análisis comunitario de problemas, así como el entorno colaborativo para la
solución de los mismos.

El Saep se ha concebido para que satisfaga las siguientes cualidades:

1. permitir el diseño cooperativo entre usuarios.
2. permitir el diseño incremental mediante el anidamiento de conceptos.
3. permitir el diseño iterativo mediante la depuración en el tiempo de los modelos
desarrollados.
4. permitir al usuario asumir diversos roles según se aprecia en la figura #1.
5. estimular el análisis espacial de problemas sociales.
6. permitir el diseño y análisis distribuido.
7. tener la capacidad de manejar diversos conjuntos de datos.
8. posibilitar la asociación de sensores con los modelos de simulación a disposición.
9. facilitar la toma de decisiones.

Se va a permitir que los usuarios trabajen tanto aisladamente como en conjunto, durante la fase
de modelado y la fase de análisis de los datos. Dado que los productos de una fase son
insumos de otras, y que grupos de usuarios pueden participar solo en alguna de dichas fases,
se ha realizado una separación de roles de usuario (como se ve en la figura #1), posibilitando
de esta manera que los usuarios puedan emplear los modelos creados y validados por otros.
Posibles roles de los usuarios son:
1. Modelador de entorno, el usuario que desempeñe este rol se encarga de crear el
ambiente geográfico, i.e. mapa, ubicación de actores, ubicación de canales de
comunicación (carreteras, cuerpos de agua). Específicamente se crearían capas que
luego se pueden visualizar en asocio de otras mediante un servidor de mapas
geográficos, al que se denominará SIG.

2. Sensor ambiental, será aquel encargado de medir tipo y cantidad de datos en el medio
ambiente en un momento dado, e.g. pluviosidad, radiación solar, temperatura, turbidez
de agua, cantidad y tipo de residuos.

3. Creador de componente, será el encargado de crear componentes de datos y

componentes de transformación.

4. Analista, se encarga de alimentar al modelo con los datos, observar su comportamiento

y guardar los datos asociados.

Con respecto a los componentes el usuario puede diseñar e implementar una jerarquía de
categorías que pueden interactuar entre si simplificando y ordenando su manejo.

La interacción entre estos componentes o clases se modela empleando un esquema gráfico y

se apoya en la interfaz de programación de aplicaciones (API )de cada clase.

II REQUERIMIENTOS FUNCIONALES

Despliegue y consulta del mapa de la Región Huetar Norte de Costa Rica.

En su interfaz inicial el sistema debe mostrar un mapa digital. Colocar las siguientes capas de
información geográfica, que pueda seleccionar el usuario: poblados, escuelas, ríos y cuerpos
de agua, tipo y uso de suelos, fauna, flora, clima, situación socioeconómica, etc (ver Plataforma
SIRZEE del ITCR).

Funciones (métricas)

Las métricas son fórmulas que relacionan los atributos de una categoría (Base de datos
SIRZEE).
En la realización de la métrica se pueden incluir números constantes (enteros y decimales).
Las métricas empleadas quedan registradas en el sistema.
Los atributos de una métrica son: Nombre (cadena), descripción (archivo html o pdf),
autorNombre (cadena), autorFecha (cadena), autorURL(cadena).
Permitir operaciones como sumar, multiplicar, dividir, restar, promedio, porcentaje, mínimo y
máximo.

Contenedores - Transformadores

La creación de un contenedor implica la inclusión una lista de insumos (producidos por otros
contenedores o no), una o más funciones de transformación (métricas) y un producto.
El contenedor puede estar compuesto de otros contenedores.
Los contenedores tienen un atributo icono (el icono tiene coordenadas) por lo que pueden ser
espacialmente georeferenciados.
Al hacer click en el icono, deben visualizarse los atributos del componente de transformación
asociado.

Operaciones de métricas y contenedores

Algunas operaciones que los usuarios pueden requerir para administrar las métricas y
contenedores de cada equipo son:

Modificar contenedor, eliminar métrica, modificar métrica, editar (subir) descripción (archivo pdf)
para métrica y contenedor.

Componentes de Datos

Una categoría (Entidad) representa un tipo de dato almacenado en la base de datos del
SIRZEE.
Una categoría puede tener varios atributos. (Las métricas realizan operaciones con los
atributos)
Las categorías y sus atributos son editables sólo por los profesores. Asimismo, el creador de la
categoría debe otorgar el permiso.
La inserción de datos puede realizarse subiendo un archivo de Excel (también requiere
permiso).
El administrador de la base de datos del SIRZEE debe incluir este proyecto en la base de
datos. Es importante que siempre se conozca si un dato pertenece al proyecto o no.
Además, los componentes de datos tienen un atributo “veracidad” que indica si los datos son
reales o no.

Usuarios y equipos

Los permisos del uso del sistema son otorgados a usuarios que pueden ser estudiantes o
profesores.
Un equipo está conformado por al menos un usuario.
Los permisos de modificación de categorías son otorgados únicamente a usuarios (de
profesores).

Buscador

El sistema debe permitir la búsqueda de contenedores y métricas dado un nombre, un

autorNombre, o zona geográfica.

Dirección URL

Es importante una dirección URL concisa, corta, fácil de recordar y que funcione sin el www.

Metadatos

Sería conveniente el uso de etiquetas que describen el contenido del sitio e incorporan
palabras claves que facilitarán a los motores de búsqueda encontrarlo en sus resultados.

Noticias

Debe tener una sección de noticias recientes para dar a conocer componentes (de
transformación y de datos) que los equipos han incorporado.

Formulario de Contacto

Información de contacto (correos, teléfonos, dirección física) de los

de Contacto encargados del mantenimiento del sitio.
Además en caso de existir un encargado de evaluar y aprobar los componentes, se requiere un
formulario para su contacto y envío de documentos.

Guía de usuario

En el menú de ayuda mostrar los objetivos del SAEP, sugerencias para alcanzarlos y una
sección de preguntas frecuentes. Lo ideal es contar con un personaje guía interactivo (con
opción de ocultar-mostrar) que ofrezca sugerencias, pasos o “tips” al usuario.
Foro y Sistema de Comentarios

Asimismo, el componente de transformación tiene como atributo una lista de comentarios. En

vez de tener un blog en un sitio separado, se desea tener la operación de insertar comentario
inmediatamente después de abrir el componente de transformación.

Sistema de Puntuación

Otorgar 100 puntos por la creación de un componente (contenedor o componente de datos).

En el juego, los Componentes de Transformación son beneficiosos o productivos en la
economía de la Región Huetar Norte. Por lo tanto cada 24hrs los equipos pueden reclamar 5
puntos por cada uno que tenga. Para ello, basta con hacer click en el componente. Cuando el
mouse sobre posicione el icono, un title deberá informar al usuario que ya puede reclamar los
puntos.

III REQUERIMIENTOS MÍNIMOS Y DESEABLES PARA EL SAEP-PitA SIRZEE

Indispensables para la funcionalidad del sistema: Ejecución de métricas y contenedores

1. Tener resultados múltiples (Ej: resultado obtenido por distrito).

2. Permitir incluir en la descripción de la métrica y contenedor un archivo PDF.
3. Permitir incluir como atributo nombreAutor/Equipo a la métrica y contenedor (forma
automática).
4. Operadores nuevos: Mín(x,y) y Máx(x,y) así como el uso de paréntesis “( )”
5. No mostrar sub-categorías o temas sino existen atributos para tales.
6. Interrelacionar usuarios con equipos: Un equipo puede tener uno o más usuarios.
7. Al hacer click en el contenedor que salga una opción de mostrar detalles del contenedor. Por
ejemplo ver la descripción, las métricas asociadas y link al documento pdf. Asimismo, al hacer
click en una métrica puede ver sus detalles como la descripción, la fórmula y el link del
documento pdf asociado.

Indispensables para la motivación de estudiantes

1. Noticiero
2. Sistema de puntuación
3. Tener operadores básicos de edición de métricas y contenedores. Los equipos sólo pueden
editar sus propias métricas o contenedores.
4. Comentarios: Equipos pueden ver y comentar contenedores de otros equipos.
5. Facilitar un link para ingreso al sitio más usable.
6. Encargado de evaluación: Revisa si las métricas y contenedores agregados al sitio cumplen
con los requerimientos mínimos. (El resultado de la evaluación final lo puede dar un encargado
de evaluación o mediante un “sistema de mayoría de votos de los profesores”, para esta última
opción habría que crear el usuario tipo profesor).
7. Diferenciar el tipo de usuario estudiante/profesor.

Deseables para su aplicación posterior al pilotaje

1. Operaciones en los contenedores como: editar icono, agregar/editar autorFecha, autorURL,
editar versión, etc.
2. Guía del usuario.
3. Buscador.
4. Formulario de “contáctenos”
5. La edición o inserción de nuevos datos a las capas de datos.
6. Sistema de votos para los contenedores.
7. Sistema donde el usuario puede retroalimentar y votar la funcionalidad y usabilidad del
sistema.
8. “Taller” para la creación de contenedores y métricas anidadas en forma gráfica.

IV REQUERIMIENTOS NO FUNCIONALES

Documentación

El sistema debe ofrecer un manual de usuario para estudiantes y otro para profesores.

El código fuente de los componentes SAEP-PitA (que se estarían instalando en la plataforma

SIRZEE) deben poder ser actualizados, modificados y mejorados en el futuro.

En la medida posible deberá ofrecer archivos de configuración, documentación interna del

código y manuales de consulta para el administrador del sistema.

Consideraciones de hardware

Se estará utilizando computadoras de los centros educativos y del SIRZEE. Las computadoras
con las que se cuenta pueden tener las siguientes características de hardware o mejores:

Procesador 1.5 GHz

Disco duro de 25 GB
RAM 512 MB
Sistema operativo Windows XP

Características de desempeño

Abrir el SAEP-PitA en el explorador de internet, el servicio como la autenticación, el despliegue

del mapa, entre otros no debe sobrepasar los 30 segundos.
Manejo de errores y condiciones extremas

La siguiente imagen muestra que existen categorías y subcategorías que no tienen Tema o
Características a seleccionar. Esto puede ser un poco incómodo para el usuario por lo que se
espera que se maneje estos errores.

Modificaciones al sistema

El código fuente de los componentes SAEP-PitA (que se estarían instalando en la plataforma

SIRZEE) deben poder ser actualizados, modificados y mejorados en el futuro.

En la medida posible deberá ofrecer archivos de configuración, documentación interna del

código y manuales de consulta para el administrador del sistema.

Seguridad

Sólo los usuarios registrados y autenticados podrán crear, editar o eliminar (según
corresponda) documentos. Usuarios no autenticados podrán hacer sólo lectura.

Además, el SAEP-PitA no podrá editar o eliminar datos oficiales de la plataforma SIRZEE. El

usuario del SAEP-PitA deberá reconocer cuáles son los datos oficiales y cuáles no son
oficiales.
Usabilidad e Interfaz de usuario

Utilizar componentes gráficos para la interfaz y un menu de opciones. Además el sistema

contará con Logo, mapa del sitio, contacto, guía al usuario (ayuda), enlaces reconocibles, entre
otros que permitan una fácil comprensión del sistema por el usuario.

Facilitar un link para ingreso al sitio más usable.

Deseables para su aplicación posterior al pilotaje

1. Operaciones en los contenedores como: editar icono, agregar/editar autorFecha,
autorURL, editar versión, etc.
2. Buscador
3. Formulario de “contáctenos”
4. La edición o inserción de nuevos datos a las capas de datos.
5. Sistema de votos para los contenedores.
6. Sistema donde el usuario puede retroalimentar y votar la funcionalidad y usabilidad del
sistema.
7. “Taller” para la creación de contenedores y métricas anidadas en forma gráfica.

Seudorequerimientos

El código fuente de la aplicación SAEP-PitA (que se adaptará a la plataforma SIRZEE) debe

estar disponible.

Hola Marlen

Disculpas por la tardanza con esto; la semana pasada tuve que salir de San José, y además hemos
tenido que hablar mucho con doña Anabelle Ulate, mi directora en el Observatorio, con Minor Cordero
en la VAS y con Javier y Carlos Andrés en la ECCI para madurar una respuesta.

Un requerimiento fundamental de mi directora para continuar con nuestra parte en el proyecto es tener
el código del SIRZEE en php. Minor me dijo que habló la semana antepasada con Oscar López sobre
esto, y que Oscar está de acuerdo.

El otro requerimiento es que Andrés termine lo acordado en enero, ya que es indispensable para la
inducción y prueba piloto que tenemos pendientes con los profesores de informática.

Si ustedes nos pasan el código y Andrés completa lo acordado, nosotros continuaremos

inmediatamente con la inducción y la prueba piloto.

De nuestra parte, sería lo siguiente:

1. Revisar los modelos de transformación y actualizar las guías para el pilotaje, de tal forma
que se acoplen con lo que Andrés programe para la inducción.
2. Organizar la inducción para diciembre o inicio del primer trimestre el año entrante (febrero).
3. Los pasos 1 y 2 dependen y van de la mano con que Andrés complete los requerimientos
 que planteamos en enero pasado.
4. Dar seguimiento y acompañamiento a los docentes durante su pilotaje en el primer trimestre
del 2012 (febrero-abril).
5. Producir un informe final para mayo registrando el desarrollo del pilotaje, con
recomendaciones para el seguimiento.
Hice las consultas respectivas en nuestra Oficina de Administración Financiera y podemos reservar el
presupuesto disponible mediante órdenes de servicios para el pago de estas tareas y productos.

Saludos
Fuente: Álvaro Fernández 25 de octubre de 2011 (por correo)

Modelos del sistema

Interfaz de usuario

Creación de métricas
La siguiente métrica calcula la producción de tinte verde que cada distrito podría tener dado su
cultivo de azul de mata.
Se selecciona en Categoría: distritos, subcategoría: distritos, Tema: distritos y Características:
Producción azul de mata. Luego multiplicamos por 563/63 el cuál es un factor que corresponde
al modelo de transformación de papel reciclado de banano.
Resultado esperado al ejecutar la métrica

operadores requeridos

La imagen siguiente muestra los operadores actuales disponibles:

Dos operadores nuevos importantes que se necesitan son:
Min(x,y)
Ej1: resultado_múltiple = Min(1*Distritos.produccionAzulMata , 0.1*
Distritos.desechosPapel)
R/ Devuelve para cada distrito el valor mínimo de las dos opciones.
Max(x,y)

GLOSARIO

Documento de “Describe por completo al sistema desde el punto de vista de

Especificación de los requerimientos funcionales y no funcionales, y sirve como
Requerimientos de una base contractual entre el cliente y los desarrolladores de
Software software” (Bruege)

Metodología de Desarrollo Según Pressman, es un modelo de proceso de software

Espiral evolutivo que conjuga la naturaleza iterativa de la contrucción
de prototipos con los aspectos controlados y sistemáticos del
modelo en cascada. Proporciona el material para el
desarrollo rápido de versiones incrementales del software.

Modelo de Transformación Un modelo de transformación es un documento que explica

cómo poder transformar un objeto en otro. En el proyecto se
elaboraron cinco modelos que describe cómo transformar
desechos sólidos en productos finales útiles. En estos
documentos se especifican los insumos, la teoría de
sustento, el proceso de transformación, los productos
generados y una aplicación práctica con el software SAEP-
PitA SIRZEE.

Pruebas de Software “A set of activities designed to evaluate the quality of

development or manufactured products” IEEE (Std 610.12-
1990). “El proceso de encontrar errores” Kaner (1999).
“Planning, design, building, maintaining, and executing tests
and test environments. A risk management strategy. Includes
verification and validation activities” Lewis (2009).