GIA Especificación Suplementaria

Transcripción

1 <Company Name> GIA Especificación Suplementaria Versión 1.2

2 Historial de revisiones Fecha Versión Descripción Autor 08/03/ Versión inicial para su aprobación Arturo Valdés Diéguez 18/03/ Revisión del documento José Carlos Castillo 23/03/ Refinamiento del documento Arturo Valdés Diéguez Confidencial <Company Name>, 2010 P 2

3 Tabla de Contenidos 1. Introducción Propósito Alcance Definiciones, Acrónimos y Abreviaturas Referencias 5 2. Funcionalidad Área de visión Gestión de toros Gestión de detección de humanos Gestión de mapas del alamacén Área de sensores Requisitos funcionales 6 3. Usabilidad Utilización Lenguaje 6 4. Confiabilidad 6 5. Restricciones de diseño Rational Rose suite Microsoft office MOBOTIX CAMERAS. Error! Marcador no definido. 5.4 Librería Open Computer Vision Microsoft windows XP Service Pack 2 o superior 7 6. Mantenibilidad 7 7. Rendimiento Tiempos de respuesta Usuarios simultáneos Cámaras IP Red de sensores 7 8. Escalabilidad 7 9. Seguridad <Supportability Requirement One> Error! Marcador no definido. 10. Datos preexistentes <Supportability Requirement One> Error! Marcador no definido. 11. Información histórica de las operaciones Resguardo de datos Backup 8 Confidencial <Company Name>, 2010 P 3

4 12. Disponibilidad Horario crítico Contingencias Componentes comprados Interfaces Interfaces de usuario Interfaces Hardware Interfaces Software Interfaces de comunicación Licencias necesarias Estándares aplicables 9 Confidencial <Company Name>, 2010 P 4

5 Especificación Suplementaria 1. Introducción Este documento de especificación suplementaria describe las características no funcionales de alto nivel a implementarse en el proyecto en términos de necesidades de usuarios finales, capturando todos los requisitos que no han sido incluidos como parte de los casos de uso. 1.1 Propósito El objetivo del documento es especificar los requisitos no funcionales para los demás componentes del grupo de forma que sirva de referencia para la implementación y planificación del proyecto. Dichos requisitos incluyen: requisitos legales o normas, aplicación de estándares, requisitos de calidad del producto, tales como: confiabilidad, desempeño, etc., u otros requisitos de ambiente, tales como: sistema operativo, requisitos de compatibilidad, etc. 1.2 Alcance En este documento se especifican los requisitos no funcionales del proyecto. 1.3 Definiciones, Acrónimos y Abreviaturas Consulte el documento Glosario (GIA-GLO-INI-N&aISMTP), disponible como referencia para todos los artefactos, que amplía la información descrita en este documento. 1.4 Referencias El presente documento hace referencia a los siguientes: GIA-GLO-INI-N&aISMTP. Documento Glosario del Proyecto. Glosario. Contiene las definiciones de los principales términos usados en el proyecto. GIA-VIS-INI-N&aISMTP. Documento de Visión del Proyecto. Recoge, analiza y define las necesidades de alto nivel y las características del sistema, centrándose en la funcionalidad requerida por los participantes del proyecto y los usuarios finales.. Documento de especificación suplementaria del Proyecto. Captura los requisitos no funcionales del sistema, todos aquellos requerimientos que no han sido recogidos en el modelo de casos de uso. Confidencial <Company Name>, 2010 P 5

6 2. Funcionalidad El sistema permitirá a los usuarios continuar con sus operaciones de trabajo en el almacén, controlando sus actividades mediante las funcionalidades ofrecidas por la aplicación desarrollada. Algunos puntos claves son: 2.1 Área de visión Gestión de toros Se encarga de los procesos de identificación, búsqueda, seguimiento y conocimiento del estado del toro, así como el cálculo de trayectorias para recoger o depositar mercancía Gestión de detección de humanos Intervienen procesos de búsqueda de personas dentro del almacén o en las inmediaciones o trayectoria del toro Gestión de mapas del almacén Modelo de representación que refleja reflejar las rutas de los toros dentro del almacén, los objetos y personas que se encuentran actualmente en él. 2.2 Área de sensores TBD por MTP cuando describan los casos de uso. 2.3 Requisitos funcionales Los requisitos funcionales quedan registrados en el documento de visión (GIA-VIS-INI-N&aISMTP) del proyecto y en la especificación de los casos de uso (GIA-USC-INI-N&aISMTP). 3. Usabilidad Al ser un software desarrollado para personas que no tienen por qué mantener una relación directa con el mundo de la informática, el producto software debe ser construido de forma que sea fácil su aprendizaje y utilización, para mejorar la eficiencia en el trabajo diario de los trabajadores del almacén. 3.1 Utilización Deberá ser sencillo, usable, no obstante el usuario dispondrá de una guía de ayuda que intentara solucionar cualquier problema que le pueda surgir. El usuario, por tanto, no necesitará poseer grandes conocimientos de informática para la utilización del software. 3.2 Lenguaje El idioma utilizado será el castellano. Se podría pensar en exhibir la información en otros idiomas aunque hoy por hoy sería una opción de poca utilidad dado el destino de su utilización. 4. Confiabilidad Propiedad que tiene el sistema de realizar las funciones para las que fue diseñado sin fallos. 5. Restricciones de diseño El proyecto se desarrollará bajo el entorno Microsoft Visual Studio 2005, en C++ y el proceso de desarrollo de software, especialmente la parte de documentación, utilizará parte de la metodología RUP. Confidencial <Company Name>, 2010 P 6

7 A continuación se enuncian los requisitos de diseño para el desarrollo de las actividades del proyecto: 5.1 Rational Rose suite Rational Rose es la herramienta CASE comercializada por los desarrolladores de UML. Soporta de forma completa la especificación de UML permitiendo crear un modelo completo que representa el dominio del problema y el sistema software a desarrollar. 5.2 Microsoft office 2007 Empleado en la redacción de los documentos presentados durante el desarrollo del proyecto. 5.3 Librería Open Computer Vision Librería de Intel de visión por computador, de código abierto y gratuita para programadores de C++. Incorpora variedad de métodos de IA. Puede obtenerse desde la siguiente dirección: Microsoft windows XP Service Pack 2 o superior Los requerimientos del desarrollo exigen la utilización de una versión mínima para el sistema operativo sobre el cual se lanzará la aplicación. 6. Mantenibilidad El código deberá estar correctamente estructurado respetando los estándares de código como la identificación y deberá estar comentado para facilitar el mantenimiento del sistema. Esta propiedad de un sistema representa la cantidad de esfuerzo requerida para conservar su funcionamiento normal o para restituirlo una vez se ha presentado un evento de fallo. 7. Rendimiento El sistema debe tener un buen rendimiento ofreciendo a los usuarios toda la funcionalidad que el sistema les ofrece de una forma rápida y eficiente Tiempos de respuesta No hay definiciones sobre estos requerimientos en la presente iteración Usuarios simultáneos El prototipo de GIA considerará el caso inicial de un único toro moviéndose por el área de almacenaje Cámaras IP El rendimiento del sistema dependerá de la velocidad de la red Red de sensores La red WSN posee limitaciones en cuanto al suministro de energía, la capacidad de cómputo de los nodos y el ancho de banda para la comunicación. El uso de antenas direccionales con los lectores RFID, puede redundar en una mala detección de etiquetas o incluso pérdida de algunas lecturas. Las perturbaciones de las señales de radio a causa de la atenuación, la reflexión y los efectos multi-path pueden comprometer la eficacia de la comunicación y reducir el rendimiento de la red WSN. 8. Escalabilidad La escalabilidad es la capacidad de mejorar recursos para ofrecer una mejora en la capacidad de servicio ofrecido. Confidencial <Company Name>, 2010 P 7

8 9. Seguridad 10. Datos preexistentes 11. Información histórica de las operaciones El sistema debe almacenar la información de las operaciones realizadas Resguardo de datos Backup 12. Disponibilidad El sistema deberá encontrarse disponible durante la duración de la jornada de trabajo Horario crítico El horario crítico tiene lugar cuando la concentración de palets en movimiento, toros y trabajadores dentro del almacén alcanza su cota máxima. Tiene lugar en los momentos de entrada (almacenaje) y salida (envíos) de productos. También cuando se decide hacer un cambio de lugar de los objetos almacenados, por ejemplo, cuando se cambian las barricas de una sala a otra por su antigüedad Contingencias Otras consideraciones de diseño relativas a la disponibilidad del sistema. No hay definiciones sobre estos requerimientos en la presente iteración. 13. Componentes comprados 13.1 MOBOTIX CAMERAS Pantallas de visualización en los toros 13.3 BBDD servidor 13.4 Unidad procesamiento de datos 13.5 Dispositivo pasarela 13.6 Red inalámbrica de sensores 14. Interfaces Esta sección define las interfaces soportadas por este sistema y se comentarán las principales interfaces de la aplicación Las interfaces de Software son las definidas con otros subsistemas incluidos en el proceso mientras que las interfaces de comunicación describen las relaciones con sistemas externos. En sucesivas iteraciones se explicará con más detalle las interfaces de usuario empleadas para definir con más detalle a la aplicación. Confidencial <Company Name>, 2010 P 8

9 14.1 Interfaces de usuario 14.2 Interfaces Hardware 14.3 Interfaces Software 14.4 Interfaces de comunicación 15. Licencias necesarias Para el desarrollo de la aplicación no será necesaria la compra de la licencia de ningún producto, ya que la adquisición de las licencias necesarias corre a cargo de la universidad. Por otra parte, la utilización de librerías de código abierto para la ejecución de la misma, tampoco hace necesaria la adquisición de ninguna licencia comercial ni se imponen restricciones de uso. 16. Estándares aplicables Se emplearán metodologías ágiles, con el objetivo de centrarse en el producto software a desarrollar evitando un proceso de desarrollo complejo que limite la propia habilidad del equipo para llevar a cabo el proyecto. Éste enfoque muestra su efectividad en proyectos con requisitos cambiantes manteniendo una alta calidad en el resultado, optando por la adaptabilidad frente a la previsibilidad ante posibles cambios, en comparación con las metodologías tradicionales. Como ya se ha mencionado anteriormente, el proceso de desarrollo del producto se apoyará en la metodología RUP, para la elaboración de algunos de los documentos. En la presente iteración de este documento no se detectaron otros requerimientos de estándares aplicables que sean particulares a este sistema. Confidencial <Company Name>, 2010 P 9