SISTEMA DE FACTURACION EN JAVA PARA LA FACTURACION DE VENTAS DE LA FABRICA PRODUCTO PAOLITA EN EL MUNICIPIO DE SARAVENA Versión[ 1] Nota: El texto incluido en rectángulos azules y el exhibido en cursiva azul (Estilo=InfoBlue) se incluye con el fin de proporcionar una guía para el llenado de este documento y debe ser eliminado antes de publicar el documento. Un párrafo incorporado después de este estilo será fijado automáticamente al normal (Estilo=InfoBlue). Para personalizar los campos automáticos (campos con fondo gris) en OpenOffice.org Writer, debe seleccionar Archivo>Propiedades y en la pestaña descripción sustituya los campos de Título, Tema y Comentarios por la información apropiada para este documento. Después de cerrar el diálogo, los campos automáticos serán actualizados automáticamente. Para actualizar la numeración del Índice de Contenido haga clic derecho sobre este campo automático y luego clic en Actualizar Índice/Tabla. Vea la ayuda del OpenOffice.org para más información sobre el trabajo con campos. Descripción del Artefacto: Tiene por objetivo documentar todos los requerimientos del sistema, este describe las funciones del sistema, los requerimientos no funcionales, características del diseño, y otros elementos necesarios para proporcionar una descripción completa y comprensiva de los requerimientos para el software a desarrollar. Identificador del documento: <insertar identificador del documento> Especificación de Requerimientos del Software <Nombre del Proyecto> Versión: <x.y.z> Historial de Revisiones Versión Fecha 1 Autor 01/06/2013 Xiomara Rivera Castro <Nombre de la Organización>,<Año> Descripción En el área de producción de la fabrica PRODUCTOS PAOLITA se vio la necesidad de implementar un programa que lleve el control de la salidas y entradas generadas para tener mayor control y poder obtener informes ágilmente de sus ventas, ya sean diarias semanales o mensuales. Pág. 2 de 11 Especificación de Requerimientos del Software <Nombre del Proyecto> Versión: <x.y.z> Índice de Contenido 1 Introducción ..................................................................................................................................................... 4 1.1 Alcance .................................................................................................................................................... 4 1.2 Definiciones, Acrónimos y Abreviaturas .................................................................................................. 4 1.3 Documentos relacionados ....................................................................................................................... 4 2 Casos de Uso .................................................................................................................................................. 4 2.1 Resumen y Actores ................................................................................................................................. 4 2.2 Diagrama ................................................................................................................................................. 5 2.3 Especificaciones de Casos de Uso ......................................................................................................... 5 3 Requerimientos Funcionales ........................................................................................................................... 6 4 Requerimientos No Funcionales ..................................................................................................................... 7 4.1 Usabilidad ................................................................................................................................................ 7 4.2 Confiabilidad ............................................................................................................................................ 7 4.3 Seguridad ................................................................................................................................................ 7 4.4 Eficiencia ................................................................................................................................................. 7 4.5 Mantenimiento y Actualización ................................................................................................................ 8 4.6 Soportabilidad y Operabilidad ................................................................................................................. 8 4.7 Restricción de Diseño ............................................................................................................................. 8 4.8 Requerimientos de Documentación en Línea y de Sistemas de Ayuda ............................................... 8 4.9 Interfaces ................................................................................................................................................. 8 4.9.1 Interfaces de Usuario ...................................................................................................................... 8 4.9.2 Interfaces de Software .................................................................................................................... 8 4.9.3 Interfaces de Hardware ................................................................................................................... 8 4.9.4 Interfaces de Comunicaciones ........................................................................................................ 9 4.10 Aspectos Legales .................................................................................................................................. 9 4.10.1 Políticas de la Organización .......................................................................................................... 9 4.10.2 Contratos con Otras Organizaciones ............................................................................................ 9 4.10.3 Propiedad Intelectual .................................................................................................................... 9 4.11 Estándares Aplicables ......................................................................................................................... 10 <Nombre de la Organización>,<Año> Pág. 3 de 11 Especificación de Requerimientos del Software <Nombre del Proyecto> <Nombre de la Organización>,<Año> Versión: <x.y.z> Pág. 4 de 11 Especificación de Requerimientos del Software <Nombre del Proyecto> Versión: <x.y.z> Especificación de Requerimientos del Software 1 Introducción Los software de facturación han sido de gran utilidad en las empresas ya que facilitan las tareas, economizar recursos además ayudad a la administración o gerencia de estas para tener un mayor control de los procesos administrativos. Con el desarrollo del presente proyecto se lograr que la administración de la fabrica PRODUCTOS PAOLITA tenga sistematizado sus datos e información con el software que ofrece múltiples funciones como son almacenar datos procesar y generar facturas, pagos e informes esto con la ayudada de un motor de base de datos MYSQL y con una programación en JAVA. Propósito Debido al crecimiento de la empresa es necesario sistematizar el área administrativo utilizado las actuales técnicas y tecnologías como herramientas para dar solución a una necesidad, esto será posible mediante la implementación del software diseñado ya que este cumple con los requerimientos del usuario en si este programa realizara funciones que actualmente se llevan manual o con formatos en Microsoft Excel ahorrando recurso (económico y humano). 1.1 Alcance Describir el alcance, mencionar los proyectos asociados y determinar que se ve afectado por este documento. Se proyectara desde junio hasta julio del 2013 Modelo de programa. El desarrollo de la base de datos en MYSQL. Programación en JAVA de las interfaces graficas utilizando SUBLIME TEX 2 En el mes de Agosto hasta octubre. Terminación de la base de datos Crear conectividad de JAVA Y MYSQL Prueba del software con el usuario. 1.2 Definiciones, Acrónimos y Abreviaturas En este apartado se debe mostrar las definiciones de todos los términos, siglas y abreviaciones requeridas para entender este documento, a su vez estas se deben reflejar en el glosario del sistema. MYSQL: JAVA: SUBLIME TEX 2: <Nombre de la Organización>,<Año> Pág. 5 de 11 Especificación de Requerimientos del Software <Nombre del Proyecto> Versión: <x.y.z> Base de datos: INTERFAZ GRAFICA: SOFTWARE: USUARIO: 1.3 Documentos relacionados Para poder visualizar las referencias a otros documentos, se debe de llenar la tabla que se muestra a continuación: Título <título> Fecha <dd/mm/aa> Organización <nombre> Identificador del documento <Id documento> 2 Casos de Uso 2.1 Resumen y Actores Los casos de uso definen de forma verbal y gráfica los requerimientos funcionales del sistema, incluyendo algunos requerimientos no funcionales. Los actores se pueden conseguir en el documento de Visión del Sistema. Se debe llenar la tabla que se muestra a continuación: CODIGO 2.2 CASO DE USO ACTORES PARTICIPANTES Validación de información Administrador Datos del cliente administrador Solicitud Pedidos Cliente Remisión de Pedido Administrador Establecen producto adquirir Administrador y cliente Ingreso de productos Administrador Generar factura Administrador Diagrama En este apartado se deben reflejar los diagramas de casos de uso inicial del sistema. Los diagramas de casos de uso son una representación gráfica de una parte o todos los actores y casos de uso del sistema, incluyendo sus interacciones y estos pueden ser desarrollados en una herramienta de modelado visual. La construcción del Diagrama de Casos de Uso se inicia con la <Nombre de la Organización>,<Año> Pág. 6 de 11 Especificación de Requerimientos del Software <Nombre del Proyecto> Versión: <x.y.z> elaboración del Diagrama de Casos de Uso Inicial, el refinamiento del mismo puede contemplarse en iteraciones posteriores. Modelo de Casos de Uso Descripción: La administración de la fábrica PRODUCTOS PAOLITA en el municipio de Saravena requieren el diseño y la implementación de un sistema de facturación el cual tiene un bosquejo de la siguiente manera: primero: Se validad la información si es cliente y ver historial. Segundo: Datos del cliente si no es cliente se procede a registrar (cedula, nombres y apellidos, dirección, teléfono, correo electrónico, forma de pago (crédito-contado). Tercero: solicitud de pedido (selección de los productos). Cuarto: Remisión del Pedido, Cargue de los productos para la entrega Quinto: Establecen producto adquirir: interactúan realizando el pedido de los productos deseados precios, ref. etc. Sexto: Ingreso de productos (cargue de los productos). Séptimo: Generar factura, digitan los productos deseados cantidad descripción valor unitario, valor total. Validación de la información Administrador <Nombre de la Organización>,<Año> Pág. 7 de 11 Especificación de Requerimientos del Software <Nombre del Proyecto> Versión: <x.y.z> Datos del cliente Administrador Solicitud pedido cliente Establece productos adquirir Cliente <Nombre de la Organización>,<Año> Administrador Pág. 8 de 11 Especificación de Requerimientos del Software <Nombre del Proyecto> Versión: <x.y.z> Ingresa productos Genera Factura Administrador <Nombre de la Organización>,<Año> Pág. 9 de 11 Especificación de Requerimientos del Software <Nombre del Proyecto> 2.3 Versión: <x.y.z> Especificaciones de Casos de Uso En este apartado se debe recoger la especificación completa de cada caso de uso. Esto incluye los campos: nombre, descripción, actores, precondiciones, flujo normal, flujo alternativo, puntos de extensión, entre otros. Se debe elaborar una tabla de especificación por cada caso de uso. Caso de Uso-Código Nombre: Colocar nombre del caso de uso. Descripción: Describir la responsabilidad y el propósito del caso de uso. Requerimiento: Identificar los requerimientos que abarcan a este caso de uso. Precondición: Tiene que ver con las condiciones en la que debe estar el sistema para que se ejecute el caso de uso. Ejemplo: registro y autenticación del cliente. Flujo Normal: En el flujo de casos de uso se describe lo que hace el actor y lo que hace el sistema en respuesta. Se expresa en forma de un diálogo entre actor y sistema. El flujo básico del caso de uso describe lo que sucede dentro del sistema. Este flujo puede ser representado en forma gráfica. Hay que tomar en cuenta que el flujo de un caso de uso, debería tener entre cinco y siete pasos aproximadamente. Actor Sistema Describir cada paso del flujo realizado por un actor. 1. 3. 5. Describir cada paso del flujo realizado por algún recurso del sistema. 2. 4. 6. Flujo Alterno: El flujo alterno se refleja el comportamiento alternativo debido a las irregularidades que ocurren en el flujo de eventos normal. Pueden ser tan largos como sea necesario para describir los eventos asociados al comportamiento alternativo. Actor Describir cada paso realizado por un actor. 1.1 2.1 3.1 Sistema alterno Poscondición: <Nombre de la Organización>,<Año> del flujo Describir cada paso alterno del flujo realizado por algún recurso del sistema. 1.2 2.2 3.2 Listar las condiciones en que se encuentra el sistema después de haberse ejecutado el sistema. Pág. 10 de 11 Especificación de Requerimientos del Software <Nombre del Proyecto> Versión: <x.y.z> Caso de Uso-Código Requerimientos Especiales: Nombrar y describir cualquier requerimiento que no haya sido abarcado por el flujo normal o los alternos. Puntos de Extensión: Se debe mencionar y describir los puntos en los cuales el flujo de eventos se extiende por otros casos de uso. Nota: Cada paso del flujo de los eventos debe ser enumerado, manteniendo una secuencia entre los pasos del flujo realizado por un actor y los pasos del flujo realizado por algún recurso del sistema. 3 Requerimientos Funcionales Los requerimientos funcionales de un sistema describen la funcionalidad o los servicios que se espera que éste provea. En este apartado se debe describir lo que el sistema tendrá que hacer, los factores que afectan al producto y satisfacen los requerimientos. Se debe llenar la siguiente tabla: ID del Requerimiento: Colocar el ID del requerimiento funcional. Nombre del Requerimiento: Colocar el nombre del requerimiento funcional. Identificación del requerimiento: Identificación del requerimiento funcional (con un número o un conjunto de caracteres que debe verse reflejado en el apartado de definición, acrónimos y abreviaturas). Características: Estas características fueron previamente definidas en el documento Visión del Sistema. Estas características son las que generan cada uno de los requerimientos que se expresarán en esta tabla. Aquí se debe de realizar una descripción del requerimiento funcional. Se debe colocar información suficiente de tal manera que sirva de ayuda para el desarrollador del sistema. Cualquier representación gráfica debe ser anexada en este apartado. Atributo: Prioridad Alta /Media Alta / Media / Media Baja / Baja La prioridad es: <colocar una de las opciones> 4 Requerimientos No Funcionales Describa los requerimientos no funcionales para este documento. Los requerimientos no funcionales tienen que ver con las características que de una u otra forma puedan limitar el sistema como son: el rendimiento (en tiempo y espacio), confiabilidad, interfaces, fiabilidad (robustez del sistema, disponibilidad de equipo), mantenimiento, seguridad, portabilidad, estándares, etc. 4.1 Usabilidad En este apartado se debe incluir la lista de todos los requerimientos que afecten la usabilidad. Esto debe incluir: el tiempo que se tomará un usuario en aprender a utilizar el sistema y se podría explicar <Nombre de la Organización>,<Año> Pág. 11 de 11 Especificación de Requerimientos del Software <Nombre del Proyecto> Versión: <x.y.z> por qué debe ser rápido el aprendizaje, los tiempos medibles de tarea para las tareas típicas y los requerimientos para concordar con estándares. 4.2 Confiabilidad Aquí se deben detallar los requerimientos de confiabilidad del sistema. Describa las características de confiabilidad explicando la posibilidad del sistema de realizar las funciones para las que fue diseñado sin presentar fallos. Entre estos requerimientos puede mencionar características como la disponibilidad, el porcentaje de fallas máximo, etc. 4.3 Seguridad Aquí se deben detallar los requerimientos de seguridad del sistema. Esto incluye si el acceso al sistema será controlado con nombres de usuario y contraseñas, que solo los usuarios con privilegios de administrador podrán acceder a las funciones administrativas y los usuarios normales no podrán. 4.4 Eficiencia En este apartado se debe ver reflejado las características de eficiencia del sistema. Se debe especificar: el tiempo de respuesta para una transacción (promedio), capacidad (número de clientes y transacciones), rendimiento del procesamiento (Ej. transacciones por segundo) y cuando el sistema se ha degradado cuál es el modo aceptable de operación. 4.5 Mantenimiento y Actualización En este apartado se debe ver reflejado los requerimientos de mantenimiento y actualización. La capacidad de mantenimiento es la habilidad que se tiene para realizar cambios al producto en el tiempo y la capacidad de actualización es la habilidad que se tiene para entregar las versiones del producto a bajo costo a los clientes con un mínimo de tiempo de descarga. Una característica clave para apoyar este objetivo es la descarga automática de parches o actualizaciones y actualizaciones del equipo del usuario final. También debemos utilizar formatos para archivos de datos que incluyan suficientes metadatos para permitirnos trasformar con seguridad la información existente del usuario durante una actualización. 4.6 Soportabilidad y Operabilidad Especificar los requerimientos de soportabilidad y operabilidad del sistema. La soportabilidad la habilidad de proveer soporte técnico eficiente y a buen precio y la operabilidad es la habilidad que se tiene de hospedar y operar el software como un ASP (Proveedor de Servicios de Aplicaciones). 4.7 Restricción de Diseño En este apartado se debe indicar cualquier limitación de diseño en el sistema que es construido. Por ejemplo: lenguajes de software, requerimientos del proceso de software, uso de herramientas de desarrollo, componentes comprados, etc. 4.8 Requerimientos de Documentación en Línea y de Sistemas de Ayuda En caso de que exista se debe describir los requerimientos, para la documentación en línea del usuario, sistemas de ayuda, ayuda sobre avisos, etc. <Nombre de la Organización>,<Año> Pág. 12 de 11 Especificación de Requerimientos del Software <Nombre del Proyecto> 4.9 Versión: <x.y.z> Interfaces En este apartado se definen las interfaces que debe apoyar la aplicación, como son: las interfaces de usuario, interfaces de software, etc. En caso de que aplique es conveniente hacer referencia a estándares de la aplicación o corporativos. 4.9.1 Interfaces de Usuario Describir las interfaces de usuario que van a hacer ejecutadas por el software. 4.9.2 Interfaces de Software Hay que describir las interfaces de software hacia otros componentes del sistema. Pueden ser: componentes comprados, reutilizados o realizados para subsistemas fuera del alcance de este documento. 4.9.3 Interfaces de Hardware Aquí se describen comentarios de cualquier interfaz de hardware que debe ser apoyada por el software, esto incluye: comportamiento, estructura lógica, etc. 4.9.4 Interfaces de Comunicaciones Se debe definir las interfaces de comunicaciones a los demás sistemas o dispositivos como: redes LAN y dispositivos seriales remotos. 4.10 Aspectos Legales Este punto define las cuestiones legales que pudieran afectar esta entrega. No considerar cuidadosamente estas cuestiones puede poner a la organización de desarrollo en riesgo de una acción legal. Busque consejo profesional si es necesario. 4.10.1 Políticas de la Organización Debe responder la siguiente pregunta: ¿El producto satisface las políticas de la organización (por ejemplo, de privacidad y seguridad)? Sí. Describa cómo se satisfacen cada una de estas políticas. No. Describa los pasos a tomar para hacer que el producto las cumpla. No. No hay políticas que apliquen. 4.10.2 Contratos con Otras Organizaciones Debe responder la siguiente pregunta: ¿Fue algún componente o información producido por otra organización bajo contrato? Sí. Revise los detalles del contrato para derechos de propiedad y licenciamiento. No. No se requiere hacer nada al respecto. 4.10.3 Propiedad Intelectual Componente Dueño Licencia Estado Comentarios Nombre del producto Nosotros Marca Registrada Registro pendiente Base de datos Distribuidor GNU GPL En conformidad, Se limita a 2 cobra cuota estándar procesadores/servidores <Nombre de la Organización>,<Año> debemos usar "(TM)", no "(R)" Pág. 13 de 11 Especificación de Requerimientos del Software <Nombre del Proyecto> Versión: <x.y.z> Dominio público En conformidad BSD En conformidad Indexador de la OS del Proyecto máquina de búsqueda GPL En conformidad Otras librerías BSD En conformidad Patente pendiente En conformidad Imágenes de clip-art Librería controladores sonido Ninguna de de OS del Proyecto OS del Proyecto Patente de algoritmo Nosotros especial 4.11 El indexador correo en un proceso aparte, no hace nuestro código GPL. Búsqueda de patente terminada, aplicación de patente en revisión. Estándares Aplicables En este apartado se debe describir por referencia cualquier estándar aplicable y las secciones específicas de dichos estándares que se apliquen al sistema, como son: estándares de calidad aspectos legales, interoperabilidad, internacionalización, estándares de seguridad de la información, compatibilidad del sistema operativo, etc. <Nombre de la Organización>,<Año> Pág. 14 de 11