diego andrés casas avellaneda versión...

27
1 Sistema de Monitoreo del Estado Vial Software Requirements Specification Diego Andrés Casas Avellaneda Versión 1.0 SIMEV

Upload: lamhanh

Post on 20-Sep-2018

219 views

Category:

Documents


0 download

TRANSCRIPT

1

Sistema de Monitoreo del Estado Vial

Software

Requirements

Specification

Diego Andrés Casas Avellaneda

Versión 1.0

SIMEV

2

Historial de cambios

Versión Fecha Sección del documento

Descripción de cambios

0.1 9/9/2012 Secciones 1 y 2 Creación de sección 0.2 19/9/2012 Secciones 3 Creación de sección 0.3 23/9/2012 Secciones 1 y 2 Modificación de

sección 1.0 15/10/2012 Secciones 1, 2 y 3 Lanzamiento de

documento

3

Tabla de contenido

Historial de cambios .............................................................................................................................. 2

Tabla de contenido ................................................................................................................................ 3

Tabla de ilustraciones ............................................................................................................................ 5

Tabla de tablas ...................................................................................................................................... 6

1. Introducción .................................................................................................................................. 7

1.1. Propósito ............................................................................................................................... 7

1.2. Alcance .................................................................................................................................. 7

1.3. Definiciones acrónimos y abreviaciones ............................................................................... 7

1.4. Referencias bibliográficas ................................................................................................... 10

1.5. Apreciación global ............................................................................................................... 11

2. Descripción Global....................................................................................................................... 12

2.1. Perspectiva del sistema ....................................................................................................... 12

2.1.1. Interfaces con el sistema ............................................................................................. 12

2.1.2. Interfaces con el usuario ............................................................................................. 12

2.1.3. Interfaces con el hardware.......................................................................................... 16

2.1.4. Interfaces con el software ........................................................................................... 18

2.1.5. Interfaces de comunicación ........................................................................................ 19

2.1.6. Restricciones de memoria ........................................................................................... 19

2.2. Funciones del producto ....................................................................................................... 19

2.2.1. Funciones mayores ...................................................................................................... 19

2.2.2. Presentación ................................................................................................................ 20

2.2.2.2. Casos de uso ............................................................................................................ 20

2.2.2.3. Modelo del dominio ................................................................................................ 21

2.3. Características del usuario .................................................................................................. 23

2.4. Restricciones ....................................................................................................................... 24

3. Gestión de requerimientos ......................................................................................................... 25

3.1. Proceso de construcción de requerimientos ...................................................................... 25

3.1.1. Priorización de requerimientos ................................................................................... 25

4

3.1.1.1. Priorización .............................................................................................................. 26

3.1.1.2. Estado de los requerimientos ................................................................................. 26

5

Tabla de ilustraciones

Ilustración 1 - Teclado ......................................................................................................................... 16

Ilustración 2 - Mouse ........................................................................................................................... 16

Ilustración 3 - Pantalla ......................................................................................................................... 16

Ilustración 4 - Interfaz gráfica ............................................................................................................. 16

Ilustración 5 - Procesador ................................................................................................................... 17

Ilustración 6 - Memoria ....................................................................................................................... 17

Ilustración 7 - Sistema operativo......................................................................................................... 17

Ilustración 8 - Tarjeta de video ............................................................................................................ 17

Ilustración 9 - Tarjeta de red ............................................................................................................... 17

Ilustración 10 - Casos de uso del sistema ............................................................................................ 20

Ilustración 11 - Modelo de dominio del sistema ................................................................................. 21

Ilustración 12 - Características de los usuarios ................................................................................... 23

Ilustración 13 - Estado de un requerimiento ...................................................................................... 27

6

Tabla de tablas

Tabla 1- Definiciones, acrónimos y abreviaciones .............................................................................. 10

Tabla 2 - Interfaces de la aplicación móvil .......................................................................................... 13

Tabla 3 - Interfaces de la aplicación web ............................................................................................ 15

Tabla 4 - Interfaces con el Hardware .................................................................................................. 17

Tabla 5 - Interfaces con el software para el servidor .......................................................................... 18

Tabla 6 - Interfaces con el software para el cliente web .................................................................... 18

Tabla 7 - Interfaces con el software para el cliente móvil .................................................................. 18

Tabla 8- Restricciones del sistema ...................................................................................................... 24

7

1. Introducción

1.1. Propósito

Objetivo del documento:

Especificar las funcionalidades y características que debe cumplir SIMEV (Sistema de

Información y Monitoreo del Estado Vial).

Razón del documento:

El presente documento muestra una descripción completa del comportamiento del sistema a

desarrollar, comunicando de manera precisa los requerimientos, objetivos y suposiciones del

sistema. Es una base para la evaluación del sistema final permite definir si el sistema es

aceptable.

Audiencia:

El documento está dirigido a cualquier persona que quiera conocer las funcionalidades básicas

del sistema, así como sus requerimientos funcionales y no funcionales.

1.2. Alcance

El presente documento abarca los siguientes temas:

Definición de las interfaces y de otros sistemas con los que interactúa el sistema.

Definición de requerimientos funcionales y no funcionales del sistema.

Definición detallada del funcionamiento y propósito del sistema.

1.3. Definiciones acrónimos y abreviaciones

Concepto Definición

Análisis de impacto Es el análisis de reconocimiento de

riesgos tempranos para el desarrollo

8

de los requerimientos y su impacto en

el proyecto

Archivo PDF Es un formato de almacenamiento de

documentos desarrollado por la

empresa Adobe Systems

Cobertura Es el área geográfica en la que se

dispone de un servicio determinado.

Concurrencia Es la capacidad que tiene el sistema

para que desarrolle en paralelo

peticiones de múltiples usuarios.

Conexión Remota Es la capacidad que tiene una

maquina, PC o dispositivo móvil para

compartir información con otra dentro

de una misma red LAN o GPRS

Dependencia Es una aplicación o biblioteca

requerida por otro programa para

poder funcionar correctamente

Diagrama de secuencia Es un diagrama que muestra la

interacción de un conjunto de objetos

a través del tiempo y se modela para

cada caso de uso

Dirección IP Una dirección IP es una etiqueta

numérica que identifica de una manera

lógica y jerárquica a una interfaz de un

dispositivo dentro de una red.

GHz El gigahercio (GHz) es un múltiplo de la

unidad de medida de frecuencia

hercio. En esta unidad se mide el

número de instrucciones del

procesador de una máquina

Hardware Es la parte tangible de un sistema

informático.

Interfaz Conocido también como GUI, es un

programa informático que utiliza un

9

conjunto de imágenes y objetos

gráficos para representar visualmente

las acciones de un sistema

Memoria RAM Es la memoria desde donde el

procesador recibe instrucciones y

guarda datos o resultados

Persistencia Es la capacidad de un sistema para

guardar información en una base de

datos, un archivo de texto, etc.

Priorización Es la asignación de un valor numérico a

un determinado requerimiento para

representar su importancia

Procesador Es el componente que interpreta las

instrucciones contenidas en los

programas y procesa sus datos

Protocolo TCP/IP Es el protocolo que permite que una

maquina o PC se comunique con otra

dentro de una red LAN

Prototipo Es un ejemplar o un primer molde de

un producto en desarrollo

Puerto Es una interfaz para comunicarse con

un programa a través de una red

Requerimiento funcional Define el comportamiento interno de

un sistema, ya sean cálculos,

manipulación de datos, que muestran

como los casos de uso van a ser

llevados a la practica

Requerimiento no funcional Especifica criterios que pueden usarse

para juzgar la operación de un sistema.

No describe las funciones de un

sistema.

Servidor Es una maquina o PC que forma parte

de una red y provee servicios a otras

computadoras denominadas clientes

10

Tabla 1- Definiciones, acrónimos y abreviaciones

1.4. Referencias bibliográficas

[1] Anonymous "IEEE Recommended Practice for Software Requirements Specifications," IEEE Std 830-1998, pp. i, 1998.

[2] R. Rowen, "Software Project Management Under Incomplete and Ambiguous Specifications," IEEE Transactions on Engineering Management, vol. 37, pp. 10-21, 1990.

[3] P. Coad, J. Luca and E. Lefebvre, Java Modeling Color with Uml: Enterprise Components and Process with Cdrom. Prentice Hall PTR, 1999.

[4] Transmilenio S.A., "Transmilenio - Sitio Web," vol. 2012, 2012.

[5] S. Wang, J. Min and B. K. Yi, "Location Based Services for Mobiles: Technology and Standards," vol. 1, 2008.

[6] Y. Natchetoi, V. Kaufman and A. Shapiro, "Service-oriented architecture for mobile applications," in Proceedings of the 1st International Workshop on Software Architectures and Mobility, Leipzig, Germany, 2008, pp. 27-32.

[7] ESRI, "Análisis de clusters," 2009.

[8] V. G. Cerón Bermúdez, "Evaluación y comparación de metodologías VIZIR y PCI sobre el tramo de vía en pavimento flexible y rígido de la vía: Museo Quimbaya-CRQ Armenia Quindío (PR 00+000-PR 02+600).," 2006.

Software Es el equipamiento lógico de un

sistema informático, comprende el

conjunto de componentes lógicos que

hacen posible la realización de tareas

Trazabilidad Es la metodología de describir y seguir

el requerimiento desde su origen hasta

implementación en el sistema

Usuario Es la persona que va a usar el sistema

(Usuario móvil, Usuario Web, Analista

SIG, Jefe de Mantenimiento)

11

[9] L. C. Díaz Chaparro, D. Alvarado and Á. Carrillo, "Diseño de una asignatura basado en aprendizaje activo que separa el análisis y diseño de la programación orientada a objetos " .

[10] R. R. VOLERE, "Volere Specification Requirements," 1999.

[11] R. R. VOLERE, "Volere Prioritisation Spreadsheet," 1999.

1.5. Apreciación global

En el presente documento se podrá encontrar la definición de requerimientos funcionales y no

funcionales del producto, así como la definición de las interfaces que se necesitan para que el

sistema se comunique con el hardware, el software y el usuario final.

Introducción – 1° Parte (Ir a la sección)

o Esta sección se encarga de presentar las razones por las cuales se desarrolla

este documento SRS, su propósito y el alcance del sistema a desarrollar.

o Presenta términos y abreviaciones utilizados en el documento.

o Presenta las referencias y bibliografía consultada para el desarrollo de este

documento.

Descripción Global – 2° Parte (Ir a la sección)

o Esta sección se encarga de especificar los aspectos directamente relacionados

con el sistema a desarrollar y presenta las diferentes interfaces con las que el

sistema interactuará.

Gestión de Requerimientos – 3° Parte (Ir a la sección)

o En esta sección se podrá ver el proceso de definición de los requerimientos. Se

dará una descripción de los procesos de identificación, documentación,

gestión y control de todos los requerimientos.

El estándar que se sigue para la elaboración del SRS es el 830 de 1998 de la IEEE[1].

12

2. Descripción Global

2.1. Perspectiva del sistema SIMEV es un nuevo sistema basado en características específicas según las metodologías de

Diente de Sierra [2] y Diseño Impulsado por Características [3].

SIMEV consiste en una aplicación para Web y para dispositivos móviles la cual soportará como

mínimo un cliente y máximo 100 clientes concurrentes en total. El sistema localizará por medio

de los dispositivos móviles las imperfecciones viales empleando los sensores embebidos para el

caso (GPS, Acelerómetro y Brújula). El sistema también desplegará mapas para análisis de

datos empleando las metodologías Buffer y Cluster, listas de resumen de las imperfecciones y

un mapa general con las imperfecciones localizadas en toda la ciudad y entre las estaciones de

Transmilenio [4].

2.1.1. Interfaces con el sistema

SIMEV interactuará con los sistemas basados en localización [5] de Google Maps y

OpenStreetMaps con el fin de obtener funciones de cartografía, geolocalización y funciones

geométricas especiales en los despliegues visuales de mapas.

2.1.2. Interfaces con el usuario

Los usuarios de SIMEV interactuarán con el sistema a través de la aplicación desplegada en

dispositivos móviles con sistema operativo Android y de la aplicación web que permite

administrar y visualizar la información del sistema. Los mapas de navegación del sistema se

pueden encontrar en los archivos:

Mapa Navegabilidad Móvil.pdf

Estructura Web.pdf

Las interfaces de la aplicación móvil son:

INTERFAZ DESCRIPCIÓN

Menú principal El menú muestra dos botones: Ingreso al sistema (autenticación de usuario) y Registro de usuario (creación de usuario nuevo)

Registro de usuario En el registro aparecen los cuadros de texto para ingresar el usuario y el password con su confirmación para registrar el usuario con el botón Registrar usuario.

Ingreso de Usuario En el ingreso aparecen los cuadros de texto para ingresar el usuario y el password con el botón Ingresar al sistema

13

Menú de capturas En el menú aparecen dos botones: Captura automática de datos y captura de datos manual.

Captura automática En la pantalla de captura aparece la ubicación del dispositivo (latitud, longitud, velocidad, precisión, azimut), captura de movimiento del acelerómetro (aceleraciones en metro por segundo al cuadrado en los ejes x, y, z), el botón activar/desactivar captura y un botón de chequeo de imperfección localizada que cambiará de estado en el momento de localizar una imperfección.

Captura manual En la pantalla de captura aparece la ubicación del dispositivo (latitud, longitud, velocidad, precisión, azimut), captura de movimiento del acelerómetro (aceleraciones en metro por segundo al cuadrado en los ejes x, y, z), la lista desplegable para seleccionar el tipo de imperfección que se está capturando, el botón activar/desactivar captura y un botón de chequeo de imperfección localizada que cambiará de estado en el momento de localizar una imperfección.

Tabla 2 - Interfaces de la aplicación móvil

Las interfaces de la aplicación web son:

INTERFAZ DESCRIPCIÓN

Inicio Se muestra los vínculos al mapa de imperfecciones por fecha y al inicio del sistema. En la parte central de la página se muestra la descripción del proyecto.

Visualizar imperfecciones por fecha Muestra el vínculo para volver a inicio y las cajas de texto para ingresar la fecha (día, mes y año) para generar el mapa con las imperfecciones creadas en el día consultado.

Ingreso de Usuario Muestra el vínculo de regreso al Inicio, las cajas de texto para ingresar el usuario y la contraseña y el vínculo de ingreso.

BackOffice El BackOffice despliega opciones

14

diferentes dependiendo del rol del usuario. Para los usuarios con rol de Analista SIG la aplicación muestra los vínculos a las operaciones:

Visualizar información recolectada.

Análisis de imperfecciones empleando Buffer.

Análisis de imperfecciones empleando Clúster.

Salir del sistema. Para los usuarios con rol de Jefe de Mantenimiento la aplicación muestra los vínculos a las siguientes operaciones:

Visualizar información recolectada.

Visualizar imperfecciones en una estación.

Tabla resumen de imperfecciones viales.

Análisis de Cluster El sistema muestra el vínculo para retornar al BackOffice y las cajas de texto para ingresar las fechas (día, mes, año) entre las que se quieren revisar las mediciones empleando el método Cluster.

Análisis de Buffer El sistema muestra el vínculo para retornar al BackOffice y las cajas de texto para ingresar las fechas (día, mes, año) entre las que se quieren revisar las mediciones empleando el método Buffer.

Visualizar posibles imperfecciones en una estación

El sistema muestra el vínculo para retornar al BackOffice, las cajas de texto para ingresar las fechas (día, mes, año) entre las que se quieren revisar las posibles imperfecciones y una lista desplegable con todas las estaciones del sistema Transmilenio.

Tabla resumen de imperfecciones viales El sistema muestra el vínculo para retornar al BackOffice y las cajas de texto para ingresar las fechas (día, mes, año) entre las que se quieren revisar las imperfecciones viales localizadas.

15

Calificar imperfecciones (Búsqueda) El sistema muestra las cajas de texto para ingresar la fecha (día, mes, año) de búsqueda de las mediciones y la opción para realizar la búsqueda. A continuación muestra una caja de texto donde se ingresa el número de la medición que se desea evaluar y la opción para visualizar la información. A continuación se despliega la interfaz de Calificar imperfección.

Calificar imperfección El sistema muestra los tipos de imperfección del sistema y se le solicita al usuario ingresar el código del tipo de la imperfección en una caja de texto. A continuación se muestra la caja de texto en dónde se debe calificar la imperfección de 1 a 7 (Escala VIZIR), la información de los puntos de medición y el mapa con el análisis clúster de los puntos informados. La interacción termina al calificar la imperfección con el vínculo Calificar imperfección.

Tabla 3 - Interfaces de la aplicación web

16

2.1.3. Interfaces con el hardware

Interfaz Características

Ilustración 1 - Teclado

Teclado

Permite que los usuarios de SIMEV interactúen con las pantallas de la aplicación web según las funcionalidades asignadas a cada uno de sus roles.

Ilustración 2 - Mouse

Mouse

Permite que los usuarios de SIMEV interactúen con todas las pantallas de la aplicación web y accedan a las funcionalidades según su rol.

Ilustración 3 - Pantalla

Pantalla

Permite que los usuarios visualicen la interfaz grafica de la aplicación web de SIMEV.

Ilustración 4 - Interfaz gráfica

Interfaz grafica

La interfaz grafica de SIMEV estará en constante interacción con el usuario. Las pantallas del sistema están definidas en la sección 2.1.2 Interfaces con el usuario.

17

Tabla 4 - Interfaces con el Hardware

Ilustración 5 - Procesador

Procesador

Se debe de tener un procesador de doble núcleo de 32 bits y con velocidad mínima de 1.5Ghz en cada uno para el procesamiento de los datos de SIMEV en el servidor y en el cliente web. Para el cliente móvil se recomienda un procesador de mínimo un núcleo de 32 bits con una velocidad mínima de 400 Mhz.

Ilustración 6 - Memoria

Memoria

Se debe tener como mínimo 2GB disponibles en la memoria principal para soportar la carga en memoria de SIMEV.

Ilustración 7 - Sistema operativo

Sistema operativo

El servidor de aplicaciones puede correr en los sistemas operativos Linux, Mac y Windows. Para la aplicación móvil se debe tener instalado el sistema operativo Android en un Smartphone compatible.

Ilustración 8 - Tarjeta de video

Tarjeta de video

Se debe tener como mínimo una tarjeta de video integrada con 64Mb de memoria para la visualización básica de la interfaz grafica de SIMEV.

Ilustración 9 - Tarjeta de red

Tarjeta de red

Se debe tener como mínimo una tarjeta de red en el cliente y en el servidor para permitir la comunicación en el sistema.

18

2.1.4. Interfaces con el software

Para el correcto funcionamiento del sistema es aconsejable que el servidor cuente con las

siguientes características mínimas de software:

NOMBRE PROPÓSITO VERSIÓN

Microsoft Windows, ó Linux Ubuntu ó Mac OS X

Sistema operativo dónde se ejecutará el servidor de aplicaciones.

Microsoft Windows 7 ó Linux Ubuntu 12.0 ó Mac OS X Mountain Lion

Glassfish Server Open Source Edition

Servidor de aplicaciones con prestaciones de Enterprise Java Beans, Web Services y Facelets. Para ver la especificación de la instalación puede dirigirse a la página de Glassfish.

Glassfish Server Open Source Edition 3.1.2.2

Java Virtual Machine Máquina virtual de Java que empleará el servidor de aplicaciones para ejecutar las unidades de despliegue del sistema.

JRE 7u7

MySQL Community Server Motor de bases de datos que persiste la información del sistema.

MySQL Community Server 5.5.28

Tabla 5 - Interfaces con el software para el servidor

Para el correcto funcionamiento del sistema es aconsejable que el cliente web cuente con

las siguientes características mínimas de software:

NOMBRE PROPÓSITO VERSIÓN

Microsoft Windows, ó Linux Ubuntu ó Mac OS X

Sistema operativo dónde se ejecutará el cliente web.

Microsoft Windows 7 ó Linux Ubuntu 12.0 ó Mac OS X Mountain Lion

Internet Explorer, Google Chrome, Mozilla Firefox, Safari

Navegador web que despliega el contenido de la aplicación web.

Internet Explorer 9 Google Chrome 22.0.9 Mozilla Firefox 16.0.1 Safari 5.1.7

Tabla 6 - Interfaces con el software para el cliente web

Para el correcto funcionamiento del sistema es aconsejable que la aplicación móvil cuente

con las siguientes características mínimas de software:

NOMBRE PROPÓSITO VERSIÓN

Android Sistema operativo dónde se ejecutará el cliente móvil. Para más información del sistema visite la página de Android Developers

Android Gingerbread (API 2.3.3)

Tabla 7 - Interfaces con el software para el cliente móvil

19

2.1.5. Interfaces de comunicación

Protocolo TCP/IP: Se utilizara el protocolo TCP/IP para la comunicación entre el cliente web,

el cliente móvil y el servidor. Sera utilizado este protocolo por su confiabilidad, integridad y

facilidad de uso.

Protocolo HTTP: El Protocolo de Transferencia de Hipertexto ser empleará entre el cliente

web y el servidor para el despliegue de la información del sistema a través del navegador

web.

Protocolo SOAP: El Protocolo de Objeto Simple a Objetos permite la comunicación entre el

servidor y el cliente móvil por medio del intercambio de datos en lenguaje XML. Es un

protocolo estándar empleado en la Arquitectura Orientada a Servicios (SOA). [6]

Puerto 3306: Se utilizara este puerto para que la base de datos MySQL atienda las

peticiones de conexión por medio del Driver J del servidor. El firewall debe tener

configurada una regla para permitir la conexión por este puerto.

2.1.6. Restricciones de memoria

Para la correcta ejecución del servidor se debe tener como mínimo 2 Gb de memoria

principal libre.

Para la correcta ejecución del cliente web se debe tener como mínimo 512 Mb de memoria

principal libre.

Para la correcta ejecución del cliente móvil se debe tener como mínimo 32 Mb de memoria

principal libre.

2.2. Funciones del producto

2.2.1. Funciones mayores

Las funcionalidades principales de SIMEV son:

Realizar la detección de imperfecciones viales empleando los sensores del

smartphone (acelerómetro, GPS, brújula). Las mediciones se referencian

geográficamente y se envían al servidor de aplicaciones empleando el protocolo

SOAP para su procesamiento y almacenamiento.

Analizar la información referenciada geográficamente por medio de los métodos de

buffer (análisis de zonas de influencia) y de cluster (análisis de agrupación de

imperfecciones). [7]

Clasificar imperfecciones viales según la escala de la metodología VIZIR en categoría

B. [8]

20

Consulta de mapas con información de las imperfecciones viales.

Consulta de mapas con información de las mediciones realizadas.

Consulta de mapas con información de las mediciones por estación de

Transmilenio.

2.2.2. Presentación

2.2.2.1. Resumen

En esta sección se presentan los casos de uso del sistema con su

documentación respectiva empleando la plantilla Hacer y Usos del grupo de

investigación ISTAR de la Universidad Javeriana. [9]

2.2.2.2. Casos de uso

Los casos de uso significativos del sistema según el análisis realizado en la

obtención de requerimientos son los siguientes:

Ilustración 10 - Casos de uso del sistema

21

La documentación de los casos de uso del sistema se puede encontrar en el

archivo

http://pegasus.javeriana.edu.co/~CIS1230IS03/documentos/Especificación

ReqCasosdeUsoSIMEV.xlsx

2.2.2.3. Modelo del dominio

En el modelo de dominio se pueden apreciar los conceptos principales del

sistema y la relación entre los mismos. Se hace énfasis en la explicación de

los tipos de usuario (usuario móvil, analista SIG, usuario web y jefe de

mantenimiento), sus respectivos conceptos asociados en el sistema y la

relación de los elementos geográficamente referenciados dentro del

sistema.

Ilustración 11 - Modelo de dominio del sistema

Cada tipo de usuario, a excepción del usuario móvil, genera mapas de

diferente tipo según las necesidades especificadas en los requerimientos

22

del sistema (mapas con marcadores, análisis buffer, análisis clúster, mapas

con metadatos completos).

23

2.3. Características del usuario

Ilustración 12 - Características de los usuarios

Recolector de datos

Descripción:

•Realiza la toma de datos de la malla vial con el dispositivo móvil haciendo diferentes recorridos.

Privilegios:

•Crear usuario móvil

•Crear imperfección vial

•Recolectar datos de forma manual

•Recolectar datos de forma automática

Experiencia técnica

•Uso de dispositivos móviles con sistema operativo Android

Conocimientos adicionales

•Localización de imperfecciones viales.

Analista SIG

Descripción

•Verifica la información suministrada por el Recolector de datos y procesada por el sistema.

Privilegios:

•Creación de imperfecciones

•Clasificación de imperfecciones

•Creación de mapas de análisis

•Análisis clúster

•Análisis buffer

Experiencia técnica

•Uso de la aplicación web

•Uso de internet

Conocimientos adicionales:

•Clasificación de imperfecciones viales

•Uso de herramientas SIG - LBS

Jefe de Mantenimiento

Descripción:

•Visualiza la información procesada del sistema con el fin de comunicar problemas a otras entidades y tomar decisiones sobre mantenimientos viales. Privilegios:

•Ver informe de imperfecciones viales

•Generar mapa de información recolectada

•Generar mapa de imperfecciones por estación

Experiencia técnica:

•Uso de la aplicación web

•Uso de internet

Conocimientos adicionales:

•Conocimiento de la malla vial

Cliente web

Descripción:

•Visualiza la información relevante obtenida por el sistema

Privilegios:

•Generar mapa de imperfecciones por fecha

Experiencia técnica:

•Uso de la aplicación web

•Uso de internet

Conocimientos adicionales:

•Ninguno

24

2.4. Restricciones

RESTRICCIÓN CARACTERISTICAS

Interfaz de usuario El sistema será desarrollado en Español

(Colombia – Latinoamérica)

Implementación El sistema debe ser desarrollado en Java

Enterprise Edition y Android JDK.

SIMEV debe implementar una arquitectura

cliente-servidor.

SIMEV debe tener en cuenta todas las

restricciones de implementación en los

dispositivos móviles.

Persistencia SIMEV contara con un método de persistencia

de los datos geográficamente referenciados y

de los isiarops.

Hardware SIMEV debe ejecutarse sin problemas en un

servicio de cloud computing.

SIMEV debe transmitir datos eficientemente

empleando las redes de comunicación de los

operadores móviles.

Software SIMEV debe ejecutarse en los ambientes descritos en la sección Interfaces con el hardware e Interfaces con el software.

Tabla 8- Restricciones del sistema

25

3. Gestión de requerimientos

3.1. Proceso de construcción de requerimientos

Los requerimientos funcionales nos indican el comportamiento interno del sistema. Estos

requerimientos dan una visión de cómo los casos de uso serán llevados a la práctica. Para

el presente trabajo se tuvieron en cuenta las características del proyecto y las prestaciones

de los dispositivos móviles, los LBS y el servidor de aplicaciones.

Los requerimientos no funcionales se identificaron a partir de las restricciones que de las

plataformas de implementación. Para la construcción de los requerimientos se tuvo en

cuenta la plantilla Hacer y Usos del grupo de investigación ISTAR de la Pontificia

Universidad Javeriana [9].

3.1.1. Priorización de requerimientos

Para la priorización de requerimientos se seleccionó el método de Volere [10] que

plantea los siguientes aspectos:

Costo mínimo de implementación (¿Cuánto costara desarrollar el

requerimiento?)

Valor para el usuario (¿Qué tanto el usuario desea ese requerimiento?)

Tiempo de implementación (¿Qué tanto tiempo tomara desarrollar ese

requerimiento?)

Facilidad de implementación técnica (¿Qué tanta dificultad técnica tiene ese

requerimiento?)

Valor para el proyecto (¿Qué tanto beneficio traerá ese requerimiento al

proyecto?)

Obligaciones con entes externos (¿Qué leyes tiene que obedecer ese

requerimiento?)

26

Cada uno de estos aspectos tiene relacionado un peso de importancia. Una vez

definidos los pesos de los aspectos y los valores de los mismos, se aplica la siguiente

fórmula:

3.1.1.1. Priorización

Se escogieron 5 aspectos fundamentales en el desarrollo del proyecto, cuatro de

ellos están contemplados en la plantilla original de Volere [11] y uno de ellos se

creó con base al desarrollo del sistema. A cada uno de estos aspectos se le asigno

un porcentaje de peso dentro de la priorización del requerimiento.

Los aspectos evaluados son:

Importancia para el proyecto (30% - Modificado)

Importancia para el desarrollador (30% Modificado)

Tiempo de implementación (10% - Por defecto en la plantilla)

Facilidad de implementación (10% - Por defecto en la plantilla)

Relación con otros requerimientos (20% - Modificado)

Al asignarle las prioridades a cada aspecto, la prioridad final del requerimiento es

un número dentro del rango del 1 al 10 (Siendo 1 un requerimiento con baja

prioridad y 10 un requerimiento con alta prioridad)

3.1.1.2. Estado de los requerimientos

Para que la trazabilidad de los requerimientos se lleve a cabo de forma correcta, es

necesario establecer una forma de seguimiento del progreso de los requerimientos.

Además, el estado de un requerimiento nos indica el porcentaje de desarrollo de todo

el producto en general teniendo en cuenta los requerimientos realizados o por realizar.

Para el proyecto se definieron 5 estados en los que puede estar un requerimiento y se

le asignaron porcentajes iguales a cada uno de estos estados, pues se considera que

cada estado es igual de importante al resto.

27

Ilustración 13 - Estado de un requerimiento

Cada una de estas fases tiene un porcentaje de desarrollo del 20%.

Cuando un requerimiento esta analizado, se dice que este tiene un avance del

20%.

Cuando un requerimiento esta en desarrollo, se dice que este tiene un avance del

40%.

Cuando un requerimiento esta implementado, se dice que este tiene un avance del

60%.

Cuando un requerimiento está probado, se dice que este tiene un avance del 80%.

Cuando un requerimiento esta entregado, se dice que este está completamente

implementado y tiene un avance del 100%.

El avance de cada requerimiento está en el documento

http://pegasus.javeriana.edu.co/~CIS1230IS03/documentos/EspecificaciónReqCasosdeUso

SIMEV.xlsx en la hoja de requerimientos.

Analizado: Un requerimiento analizado es un requerimiento que esta completamente identificado y esta debidamente documentado.

En Desarrollo: Un requerimiento en desarrollo es un requerimiento que esta en fase de desarrollo y aun no esta terminado.

Implementado: Un requerimiento implementado es un requerimiento que ya esta codificado pero aun no esta probado.

Probado: Un requerimiento probado es un requerimiento que ya esta codificado y que responde como deberia.

Entregado: Un requerimiento entregado es un requerimiento que ya ha recibido el visto bueno por parte del Directo de Desarrollo.